核心同事离职，三个月后没人敢动他写的那套东西。不是看不懂代码，是看不懂为什么是这样：那个重试为什么是三次、那张表为什么不能加索引、那个补偿任务为什么每天凌晨跑而不是实时跑。代码还在，判据没了，于是所有人绕着它走。交接真正要转移的不是文档，是在什么条件下该做什么决定。

---

1. 交接资产的四种形态与各自的流失速度

形态	载体	典型衰减	谁最容易接手
代码注释	源码内	一次重构就会丢，几周内失效	接手写代码的人
设计文档	Wiki / 文档库	半年后与实现脱节，无人敢信	做架构决策的人
运行手册	Runbook	变更一次就过期，通常最先腐坏	值班与运维
决策记录	ADR / 会议结论	衰减最慢，但最少人写	后来做同类取舍的人

四种形态的衰减速度与"写它的成本"成正比：注释最便宜所以最容易被删，决策记录最贵所以最少人留下——而它恰恰是唯一能解释"为什么不是另一种方案"的东西。

2. 知识随人走的三个机制

机制	表现	对应解法
隐性知识	"这个参数别动，动了会出问题"，但说不出为什么	强制写成判据 + 失效条件，不接受"经验之谈"
口头约定	上下游靠一句"有事找我"维持，没有书面边界	落成接口账：谁承诺什么、违约怎么发现
私有脚本	只在某人 ~/bin 里，进程靠它重启	收编进仓库，或明确写"废弃且不承担责任"

三个机制的共同点是：它们都在"没有摩擦"的时候不产生成本。摩擦只在人走之后出现，所以交接的难点不是写，是让当事人相信现在就该写。

3. 交接清单的必要条目

// handover/checklist.md（骨架，按系统规模裁剪，不要删条目只标 N/A）
─── 系统边界 ───
入口 / 出口 / 依赖方 / 被依赖方（逐条给地址与负责人）
─── 不可动部分 ───
不能改的：表结构、对外字段、时序假设、部署顺序，各附失效后果
─── 已知坑 ───
现象 → 触发条件 → 临时处置 → 永久解法（没有永久解法的写"待定 + 风险"）
─── 外部联系人 ───
供应商 / 甲方技术 / 内部平台 owner，注明响应时限
─── 临时绕过 ───
绕过的是什么约束、为什么当时绕、什么条件下必须收回

条目	为什么必须留	缺失后的典型后果
系统边界	接手人要知道改这里会不会牵动别人	一次自认为局部的改动打挂上游
不可动部分	约束是历史代价换来的，不是偏好	第二个季度就被"优化"掉
已知坑	坑的价值等于踩坑的成本	同一坑重踩一遍，通常更贵
外部联系人	组织外的人不会因为交接而知道交接	故障时找不到能拍板的人
临时绕过	绕过是有期限的债	临时方案变成永久架构

4. 时间窗：两周不够的原因

两周只够"讲一遍"，不够"做一遍"。判断交接是否够用，看的不是讲了多久，而是接收方独立完成过几次原始负责人不在场的操作。

// 交接时间窗的经验配比（按系统耦合度上下浮动，不是硬指标）
─── T-8 周 ─── 接收方旁观：跟着做，只记录不操作
─── T-6 周 ─── 接收方操作、原负责人旁观：允许现场纠正
─── T-4 周 ─── 接收方独立操作，原负责人只看结果：暴露判断力缺口
─── T-2 周 ─── 接收方带第三人，验证"他能讲给别人"
─── T-0    ─── 原负责人只保留联系方式，不再保留审批权

最后一行最容易被跳过：人还在，审批权就还在，接收方永远不会真正承担判断责任。

5. 接收方的验证方式

验证不是"你能不能维护"，是"你能独立做一次小改动，并解释为什么这样做"。

验证项	通过标准	常见假通过
独立改动	无需提问完成一次真实小改动并上线	改动是照着原负责人的步骤抄的
判据复述	能说出该改动的约束与放弃的方案	只会复述结论，说不出被否的选项
故障演练	人为制造一次已知故障，能定位到根因	靠日志关键词命中，不知机理
边界测试	能指出"这个改动在什么条件下会失效"	认为改动没有失效条件

判据复述这一项最能区分"记住了"和"接住了"。要求接受方说出被否掉的方案及其否决理由，说不出来就是没接住。

// 判据缺口的三种探针：选一条做，不要三条都做（会变成考试）
─── 1) 反向提问 ─── "把超时从 3s 改到 30s，最先坏的是哪一段"
─── 2) 变更推演 ─── 给一份未评审的改动单，要求 10 分钟内说出该拒还是该收
─── 3) 故障复现 ─── 注入一个已知故障，看他先查判据还是先翻日志

三条探针测的是同一件事：他手里有没有可供推理的约束。先翻日志的人不一定差，但如果连"该看哪一类日志"都要问，说明边界没接住。

6. 文档化的成本与收益分界

不是所有知识都值得写。写作成本大致与"需要解释的因果链长度"成正比，收益与"被独立重问的次数"成正比。

情形	建议	理由
一次性脚本、已废弃入口	只写一行"已废弃 + 替代物"	详细文档的读者是零
高频改动、多人触碰的模块	必须写，且随改动更新	每次改动都会有人重问
稳定五年不动的基础库	写决策记录，不写操作手册	操作没人看，取舍会被反复质疑
复杂但只被一个人用的内部工具	收编或废弃，不写文档	文档救不了单人依赖

分界线可以压成一句：会被第二个人独立重问的东西才值得写；其余的交接收编、废弃或重写，都比写文档便宜。

7. 私有脚本与本地工具的处置

// 找出"只存在于某人机器上"的运维资产
─── 1) 谁的 crontab 里有生产任务 ───
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
─── 2) 仓库外仍在被引用的脚本 ───
grep -rl --exclude-dir=.git '/home/[a-z]*/bin/' /etc /opt /usr/local 2>/dev/null
─── 3) 判断引用是否还活着：看最近访问时间 ───
find /home -path '*/bin/*' -type f -mtime -90 2>/dev/null

处置只有两个合法结论：收编（进仓库、加参数校验、写 owner）或明确遗弃（从 crontab 摘掉、留一行说明替代路径）。第三个选项"先留着，以后再说"等于把债务记在一个已经离职的人名下。

8. 定期重写，而不是归档

组织记忆需要重述，不是存档。存档的文档会与实现脱节，重述的文档会带着当前的理解。

// 季度重述议程（60 分钟，只做三件事）
─── 1) 复述 ─── 让现 owner 不看旧文档，讲一遍这个系统的三个关键取舍
─── 2) 对账 ─── 与旧文档比对，差异处标注"实现变了"还是"理解错了"
─── 3) 重写 ─── 只重写差异部分，旧文档保留版本号，不覆盖

差异处标注"理解错了"比"实现变了"更有价值：前者说明当时的判据没传下来，后者只是文档旧了。

9. 度量

指标	口径	说明
接收方独立操作成功率	无求助完成的变更 / 总变更	低于半数说明交接只是"讲过"
问题追溯时长	从提问到找到能回答的人或文档	上升说明联系人清单已失效
交接清单完整度	已填条目 / 应填条目（含 N/A 标注）	只统计有 N/A 理由的项，空着不算
私有资产残留数	仓库外仍被生产引用的脚本数	应单调下降，不下降就是在积累单点
二次求助率	同一问题被第二个人重新问的次数	高说明该写而未写

度量只挑两个用。指标多到需要专人统计时，它就从交接工具变成了汇报材料：问题追溯时长最灵敏，它一升就说明某条链路已经断了；私有资产残留数最能防复发，因为它不随人走。其余指标在有争议时再取。

10. 排错：交接做完了仍然出问题

现象	更可能的原因	处理
文档齐全但没人看	文档按"系统结构"组织，不按"任务"组织	改成"要做 X 时读哪一节"的入口式目录
接手人反复问同一类问题	判据没写，只写了步骤	补"为什么不那样做"的一段
变更后故障率上升	不可动部分没被标出	补约束清单，并在评审模板里加一项
交接后半年系统冻结	接收方只有维护权没有决策权	交出审批权，而不是只交出代码
老员工仍被频繁咨询	时间窗内没做"第三人复述"	补一次带第三人的演练

11. 边界

场景	判断	理由
岗位轮换频繁（半年一轮）	建制度化交接模板，不搞个案交接	个案交接的成本摊不薄，模板可以复用
系统 3 个月内下线	投入压到最低：只留边界、联系人与停服步骤	判据的收益期短于写作成本
单人维护的探索性项目	只留"如何重来一遍"的最小记录	判据还在演化，写死会误导
外包交付、无内部 owner	交接对象是合同，不是文档	判据在乙方手里，要的是可验收条款
团队规模小于三人	全员共享上下文，交接退化为同步会议	转述损耗低于文档成本

12. 自测

1. 你负责的系统里，有哪三个决定是"说不出为什么、但没人敢改"的？
2. 交接清单的五类条目中，你现在能立刻填出几类？
3. 为什么两周的交接通常只完成了"讲一遍"？
4. 接收方通过验证的最低标准是什么，为什么不是"能维护"？
5. 一个只被一个人使用的内部脚本，收编和遗弃各要付什么代价？
6. 季度重述时发现文档与实现不一致，先判断哪一种差异？