这篇解决的问题是：FDE 一个人扛着客户关系、系统细节和一堆没写下来的隐性经验，人一走，系统照转但没人知道为什么转得起来。
最值得拿走的是「隐性知识显性化」那一组检查项：为什么这段提示词这么写、线上抖动时先查哪里、客户对哪句话敏感——这些不交接就彻底消失的东西，比代码和文档难补得多。最容易出现误用是把交接做成文档搬家：把知识库链接甩过去就算完成，接收方三个月后才发现链接里的内容早就过时了。
相比站内的度量与生命周期内容，这篇的增量在「交接的完整边界」——从密钥归属到信任链的移交清单。国内语境要叠加的是：交接常与人员流动周期绑死，建议把季度交接自查做成例行机制，降低对个体自觉的依赖。
读完后做一件事：假设明天你从当前项目消失，把会最先瘫痪的三样东西写下来，本周内把它们的文档补齐。
—— FDEChina编辑部 · 实战派
FDE 项目有个残酷的特点：一个工程师往往同时是客户最信任的对话者、系统最细节的掌握者和全部隐性经验的唯一载体。交接做得好不好，不体现在离职手续上，而体现在三个月后——客户报障时知道找谁、系统抖动时有人知道先查哪里、下一次迭代时不至于把当初踩过的坑重新踩一遍。这份清单共十四条检查项，分四组，可勾选执行，适用于人员轮换、项目移交给客户团队或交付给后续同事三种场景。交接的准备工作应与项目生命周期同步推进，而不是离职前一周的突击；移交物中的评测集与脚本部分，以评测基线建设和PoC 验收清单的产出为基础。
第一组：文档与知识——让没参与过的人能接手
- □ 系统设计文档为最新版本：架构图、模块职责、关键设计决策及其理由（为什么选 A 不选 B）齐全，文档里没有指向失效链接或已废弃系统的描述。
- □ 全部提示词、模型参数、工作流配置已纳入版本管理并附变更说明：每个关键改动能查到「什么时候改的、为什么改、改完指标变化多少」。
- □ 隐性排查经验已写下来：线上抖动时按什么顺序排查、哪几类报错其实是同一个根因、哪些告警可以延后处理，形成一页「故障应对速查」。
- □ 已知问题与技术债清单已移交：当前明确做不到的事、绕过方案、后续建议方向逐条列出，接收方不需要靠踩坑来重新发现它们。
第二组：系统与运维——机器层面不依赖任何人
- □ 全部密钥、账号、证书已完成归属转移或轮换：没有任何线上资源仍绑定在个人账号上，转移记录（转了什么、何时转的、确认人）留档。
- □ 部署与回滚流程可由他人独立执行：接收方在交接期内完整跑通过一次部署和一次回滚，操作文档按此实测修订过。
- □ 监控与告警的值班归属明确：告警发到谁、升级路径是什么、各条告警的响应时效约定，全部更新为接收方信息并实测送达。
- □ 数据访问权限按最小够用原则重新确认：离职或轮换人员不再拥有生产数据的访问权，客户方对权限现状有书面的知悉与确认。
第三组：客户与关系——信任链也要移交
- □ 客户关系地图已移交：客户方各干系人的角色、关注点、沟通偏好与历史敏感点（哪些承诺在什么背景下做出）形成一页纸，关键干系人由新旧双方共同当面引荐。
- □ 当前对外承诺与边界已同步给接收方：已承诺的功能与指标、明确不做的事项、进行中的变更请求逐项交代，避免新接手的人无意间推翻旧承诺。
- □ 服务节奏有过渡安排：客户习惯了的问题响应方式（周会、日报、即时群）在交接期内由双方并行维持至少一个周期，由新人主导、旧人旁观。
第四组：风险与确认——交接完成要有依据
- □ 进行中的风险项逐条移交：每个未关闭的风险（依赖方拖期、指标临界、客户方组织变动）附现状、已采取的动作与下一步建议，接收方逐条确认理解。
- □ 交接验收标准已执行：接收方独立完成一次端到端的关键操作（复现一个典型故障并处理、跑一遍评测回归），以「做出来」而非「听懂了」作为交接完成的判据。
- □ 交接完成经三方确认：移交人、接收人、客户方或项目干系人对交接清单逐项确认，遗留项标注责任人与期限，存档备查。
使用说明
这份清单最常见的失败用法是离职前一周打开。文档、配置这些有形资产突击一周尚能补个大概，但第三组的信任链和第一组的隐性经验，靠突击根本写不出来——它们需要在平时就以「随时可交接」的状态存在。所以推荐的节奏是：项目过半时第一次过清单，把缺口记下来排进日常；此后每个季度例行自查一次；正式启动交接时第三次过清单，只处理增量。如果你所在团队有多个并行项目，把季度自查固化成制度，比依赖个体自觉可靠得多。
另一条使用要点：交接完成的判据是「接收方能做出来」，不是「移交方讲过了」。验收环节安排的端到端实操（第二组最后一条与第四组第二条）是整份清单里最能防患于未然的两条——很多交接在纸面上完美，第一个线上故障就暴露出接收方从未独立执行过任何操作。交接后的效果持续观察，可结合交付质量度量的指标看趋势是否平稳；团队层面的知识沉淀与轮岗机制设计，参见FDE 知识指南。