接手没有文档的旧系统，先建立可核对的资产清单

盘点时区分资产、事实与缺口

先确定接手的是一个项目，还是一组相互依赖的系统

一个官网、后台或小程序可能依赖独立接口、管理端、任务服务和对象存储。按业务入口发现组成部分，比按交来的仓库数量判断范围更可靠。

列出用户如何进入、各角色怎样完成任务，再追踪请求到哪个服务、服务访问什么资源。清单同时记录资产主体、维护人和用途；同名测试系统与生产系统要分开。业务人员说“这个功能没用”也不能马上删除，应核对定时任务、报表和外部合作方是否仍在调用。

• 建立入口、应用、数据、任务与外部接口之间的关系图。
• 为每项资产标注环境、归属、负责人和证据位置。
• 将已核实、待核实、缺失分别标记，避免混成一个清单。

从线上版本反查源码与构建过程

接到源码不等于能维护生产系统。首先确认运行产物对应哪个提交、使用什么构建命令，以及构建时需要哪些工具和私有依赖。

优先查看已有发布记录和构建日志；没有版本标识时，将实际产物、发布时间、代码差异和原团队说明作为交叉证据，保留结论的不确定性。记录版本管理分支、依赖锁文件、生成代码和手动修改过的文件。不要在生产目录直接试编译，使用独立环境验证可复现程度。

构建失败应记录完整步骤与缺失条件，而不是要求接手人员反复猜测。若存在生成文件或付费编译插件，确认生成源、许可证取得方式和后续可用性。线上人工改过的配置和脚本也要核对，它们可能没有进入仓库。

• 保存当前运行产物与版本信息，建立可追溯的接手基线。
• 检查前后端、管理端、脚本和私有组件是否都已交接。
• 记录一次全新环境构建的步骤、失败原因与所需权限。

把运行配置与敏感凭据分开交接

环境清单包括操作系统、运行时、数据库、代理、存储和网络约束；凭据应通过受控方式交接，文档记录名称与获取位置即可。

逐项核对应用实际读取的配置，不只看仓库中的示例文件。可能有配置存在服务管理器、容器平台、控制台或人工脚本里。明确域名、证书、服务器和第三方账号的经营主体与续费责任，敏感值不写入普通文档或源码。测试环境使用独立凭据和脱敏数据，避免复现过程触发真实业务。

• 列出配置项含义、环境差异、保管人和更新方式。
• 验证网络白名单、证书、DNS 与外部服务连通条件。
• 为关键凭据交接保留受控记录，并确认必要的轮换责任。

用真实运行证据发现隐藏接口和后台任务

旧系统依赖可能藏在操作系统定时任务、数据库作业、办公脚本和第三方回调中。只搜索 HTTP 路由无法得到完整关系。

在授权范围内观察服务调用、任务日志和配置，再与代码搜索及负责人访谈核对。采样时间应覆盖业务周期：日常请求看不到月末报表或每周同步。不为追求全量而收集无关个人数据；清单中记录调用方向、用途、触发时机和失败影响，足以支持后续维护判断。

• 检查定时任务、队列消费者、回调入口、文件交换和邮件发送。
• 记录外部服务的联系方、测试方式、限制与故障补救。
• 把尚未覆盖的周期性流程标为待核实，安排再次确认。

依赖清单记录实际使用的版本与关系

直接依赖之外还有传递依赖、系统包、插件和镜像组件。软件物料清单可以帮助盘点，但不能替代实际产物与环境核对。

为组件记录名称、版本、来源、用途和支持状态，区分开发工具与生产运行依赖。版本扫描结果只是线索：缺少记录不代表组件不存在，发现已知漏洞也需进一步核对是否影响当前用法。将无法下载的私有包、已停止维护的插件和有替代成本的组件列入升级风险，而不是接手时同时升级所有依赖。

• 从锁文件、构建结果与运行镜像交叉核对组件清单。
• 标注直接与传递依赖，确认许可证和供应方信息的取得方式。
• 将急需修复与后续改造分开，避免改变接手基线。

以独立复现和缺口确认完成接手验收

交接文档需要被另一名人员实际使用。能按步骤部署隔离环境、定位日志并运行关键业务样例，才证明资料能够支撑接手。

按源码获取、依赖安装、配置注入、服务启动和业务验证执行一次演练，逐项记录可重现结果。缺少源码、第三方平台权限受限或封闭供应商系统无法重建时，应明确只能做到哪一层维护。本文适合有合法接手权限的企业项目；它不要求先了解全部代码，但要求关键风险可见、后续事项有人处理。

清单中的证据尽量指向可访问的仓库提交、配置说明或演练记录，并注明核实日期。后续发现新任务或新接口时更新基线，让接手成果成为持续维护资料，而不是只在交接当天使用的静态附件。

• 让未参与整理的人按文档部署并完成指定业务流程。
• 形成资产清单、关系图、运行手册与未决事项四项交付。
• 对无法复现的部分注明影响、责任方和临时处理方式。

需求讨论中的问题