接手旧项目时，我更想留下的是“当时为什么这么做”

接手旧项目，我最怕交接时觉得听懂了，第二天改代码却卡住：这个判断能删吗，那个任务为什么凌晨跑？代码还能慢慢读，散落在口头解释里的背景，反而很容易漏掉。

项目能跑起来，只完成了交接的一部分

目录结构有人讲，历史原因却很容易略过

如果让我接手一个维护了几年的后台，我当然会先关心环境怎么搭、入口在哪里、队列怎么启动。

但这些步骤完成之后，真正让我犹豫的，往往是一些看上去“不太合理”的地方。

比如两个方法做着差不多的事情，一张表保留了好几个含义接近的状态，还有一个已经没有页面入口的接口，仍然不能删除。

第一次看到时，很容易想顺手整理一下。可这些代码背后，也许还连着旧客户端、外部回调，或者某个不能一次性迁移的业务流程。

我希望交接时能把这些原因一起留下。否则接手的人迟早还得把同样的问题问一遍。

“这里先别动”，最好再追问一句

交接里有句话特别常见：“这块暂时别动。”

我听到之后，会想继续问：是因为测试不足，还是仍有业务依赖？如果必须修改，要先找谁确认？

这几种情况对应的处理方式并不一样。

如果只是把“别动”记进文档，它可能会在项目里留上好几年。后来的人不敢碰，也说不清为什么。原本一个有条件的提醒，慢慢变成了默认规则。

所以我更愿意把限制写完整一点：目前谁在使用、什么情况下会触发、解除限制还缺哪一步。暂时问不清，也明确标注待确认。

交接时，我不想一直低头追着打字

现场先听明白，文字可以稍后整理

一边看同事切文件，一边听业务解释，再一边记笔记，确实容易顾此失彼。

我可能刚写下一个任务名称，对方已经跳到了异常处理。等我重新抬头，屏幕上又换了一个目录。

对于允许录制和上传的交接材料，可以借助 Audio Transcription 先生成文字底稿。它目前是免费的，支持上传音视频文件，也能粘贴支持的链接进行转录，生成的文本可以继续修改。

这样安排，我在现场就能多花一点注意力追问。遇到没理解的地方及时停下来，比会后对着一句缩写反复猜要好。

涉及内部代码、客户信息和账号配置的材料，我会先按团队要求确认处理方式，录制时也尽量避开密钥和真实用户数据。

说话人和时间戳，能帮我找回一句话的上下文

一场交接如果有开发、测试和业务同事参加，同一个问题可能会得到不同角度的回答。

开发说的是实现方式，测试补充的是已知现象，业务解释的则可能是某个特殊客户的要求。

工具提供说话人标签和时间戳，可以辅助区分这些发言，再回到原始录音核对。不过标签本身不等于真实姓名，我仍然需要确认谁说了什么。

我尤其会回听带着条件的句子。比如“只有旧订单走这个逻辑”和“订单都走这个逻辑”，整理时漏掉两个字，理解就变了。

整理交接记录，我会把几类内容分开

当前行为、历史原因和后续计划，别混成一段

口头交接经常会在时间线上来回切换。

前一分钟还在讲线上怎么运行，后一分钟就说到去年遇到的问题，接着又讨论下个月准备重构的方案。如果直接照着转录顺序整理，很容易把计划中的事情写成已经完成。

我会给这些内容分别找位置：

这样做不复杂，但第二个人再看文档时，至少能分清哪些可以依赖，哪些还需要查证。

AI 摘要帮忙归类，结论仍要逐项确认

交接内容比较长时，AI 摘要可以先帮我梳理一遍。我会把要求写得具体一些：

请按当前实现、历史原因、已知限制、后续计划和待确认事项整理。保留“可能”“暂时”“仅在某种情况下”等限定，不要把建议写成已完成事项，也不要推测负责人和截止时间。

生成之后，我会对照转录检查，再把关键内容与代码、配置或工单核对。

比如摘要里出现“已停用”，我就需要确认原话到底是“已经停用”，还是“准备停用”。这类词看着不起眼，却会影响后续操作。

文档里留着几个明确的问号并不丢人。把不确定的事情写得非常肯定，才会给接手的人添麻烦。

有操作演示的交接，画面也得保留

文字记录解释，录屏记录具体位置

后台操作、部署步骤和故障排查，光听声音往往不够。

同事说“先把这个关掉”，我需要知道具体是哪个开关，以及关掉之后页面会出现什么变化。

对于带讲解的录屏，可以用视频转文字工具整理其中的口头说明，再结合时间戳回看操作位置。文字方便查找讨论内容，画面则用来确认按钮、文件和执行结果。

这里也有边界：屏幕上出现了一段命令，对方没有念出来，语音转录就不会自动把它完整记录下来。命令、路径和参数，仍然要从项目或演示画面中核实。

我希望记录能跟着第一次实际操作更新

交接结束后，我不会急着把文档标成“完成”。

第一次在测试环境里跑任务、处理一条异常数据，或者走一遍发布流程时，我通常还会发现缺少的前提：某个权限没开，一个服务需要先启动，或者示例文件已经过期。

这些发现应该补回交接记录里。

整理好的文本可以导出成文档，再放进团队已有的知识库。原始材料按权限保留，日常查阅的版本则围绕具体操作来写，避免每次打开都要翻完整场讨论。

我希望下一位接手的人能少猜一点

文档不用很长，但要能顺着往下查

我理想中的交接记录，不需要把每个类都解释一遍。

更实用的是，看到一个任务名称，能知道它负责什么；遇到一条特殊判断，能找到保留它的原因；准备修改某个流程时，能知道需要先核对哪些依赖。

有些信息适合写在代码注释里，有些适合放在操作文档里，还有一些暂时只能留在待确认事项中。转录材料提供了整理的起点，之后仍然要把内容放到合适的位置。

接手之后补上的那一句，往往最有用

如果让我选一个最值得坚持的小动作，我会选：每次解决一个交接时没讲清楚的问题，就顺手补一句说明。

不用另开一篇长文，也不必等到有空再统一整理。刚确认的事情最容易写准确，拖上一周，又得重新翻记录。

我想留下的，是下一次有人问“这里为什么这么写”时，能找到的一段具体解释。最好还有适用范围、相关位置，以及哪些地方尚未验证。

这样等我把项目交给别人时，就不用再指着屏幕说：“这块有点历史原因，下次有时间再讲。”

本作品采用《CC 协议》，转载必须注明作者和本文链接