关键研发人员离职前，知识沉淀的范围应当围绕一个判断来组织：接手的人能否独立继续工作。按业务对象盘点，需要覆盖需求与决策、系统与代码、流程与依赖、故障与运维、人员与外部关系、在办事项与风险六类内容；按可复用程度分级后，明确交接人、接收人和验收人，把内容写入可检索的文档与工作项记录，最后以接收人独立完成一次真实任务作为完成标志。交接文档、问答记录和验收结果可以在ONES等协作平台中承载，便于后续检索和状态跟踪。
要点总览（TL;DR）
- 离职知识沉淀按业务对象盘点六类内容：需求与决策、系统与代码、流程与依赖、故障与运维、人员与外部关系、在办事项与风险，每类同时记录显性文档与隐性判断依据。
- 按影响面和接手难度把知识分为必交、应知、可查三级，分级结果决定哪些必须书面化、哪些口头讲解即可，避免平均用力。
- 交接由离职者提供内容、主管定范围与优先级、接收人整理复述并完成实操验收、协作方补充依赖关系，各方交付物提前明确。
- 完成标志是接收人在无离职者提示下独立完成一项真实任务或故障处置，文档写完只是中间状态。
- 常见缺口集中在只交代码不交背景、只写正常流程不写例外、联系人只写姓名不写场景，检查时针对这三点追问可暴露真实完成度。
先定范围：离职交接要沉淀哪几类知识
离职知识沉淀常见的失误，是按“写几份文档”来组织，结果文档数量不少，接手人仍然不知道从哪里开始。更有效的做法是按业务对象盘点：每一项业务对象对应一组需要交接的知识，交接会议上可以逐项勾选、逐项确认接收人。
下面六类清单可以直接用于交接会议。每类都同时包含显性知识和隐性经验，盘点时分开标注，避免只交文档、不交判断依据。
| 知识类别 | 应沉淀内容 | 显性部分 | 隐性部分 |
|---|---|---|---|
| 需求与决策 | 需求来源、方案取舍、被否决的方案及原因、关键评审结论 | 需求文档、评审记录、决策纪要 | 当时的约束条件、各方顾虑、为何选择当前方案 |
| 系统与代码 | 模块职责、核心数据结构、关键代码路径、配置项含义 | 架构说明、代码注释、配置清单 | 哪些代码看似冗余但不能动、历史遗留设计的成因 |
| 流程与依赖 | 关键业务流程、上下游系统接口、调用时序、数据流向 | 流程图、接口文档、依赖清单 | 接口在异常情况下的实际表现、对方系统的响应习惯 |
| 故障与运维 | 历史故障现象、定位过程、处置动作、复发条件 | 工单记录、告警规则、处置手册 | 排查时的直觉判断、容易误判的方向、临时绕行手段 |
| 人员与外部关系 | 对接人、供应商、外部合作方的角色与联系场景 | 联系人清单、对接事项说明 | 沟通风格、什么情况下找谁、非正式协调渠道 |
| 在办事项与风险 | 未完成任务、遗留缺陷、已知风险、待决事项 | 任务列表、风险登记、进度说明 | 风险的真实紧迫程度、可能触发的时间点 |
范围也需要有边界。知识库的访问量、文档更新率等运营指标，以及完整的研发资产配置与基线管理，属于相邻的管理议题，本文只讨论知识如何形成、如何交接、如何验收。盘点时如果发现某类内容已有稳定文档且接收人能够找到，标注“指向已有文档”即可，不必重复撰写。
核心操作步骤：从盘点到验收的五步流程
五步流程适用于离职通知期通常为两到四周的场景。时间更紧时，可以压缩讲解和文档打磨，但不能省略盘点分级和实操验收，这两步决定交接是否真正成立。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、确定范围与时间窗 | 岗位职责说明、在办项目清单、离职日期 | 列出该人员承担的全部业务对象，标注交接优先级，排出每周交接安排 | 交接范围表 | 主管确认范围表，无遗漏业务对象 |
| 二、知识盘点与分级 | 交接范围表、现有文档目录 | 逐项判断影响面与接手难度，标记必交、应知、可查三级 | 分级后的知识清单 | 每项知识都有级别和接收人 |
| 三、文档化与结构化 | 分级清单、已有文档 | 按统一位置和命名规则撰写或补充，每篇包含背景、结论、依据、联系人四个必填字段 | 交接文档集 | 必交项全部有文档，字段完整 |
| 四、讲解与答疑 | 交接文档集 | 安排讲解会，离职者逐项讲解，接收人提问，记录问答并回补文档缺口 | 问答记录、修订后的文档 | 接收人提出的问题都有书面答复 |
| 五、实操验收 | 真实任务或故障场景 | 接收人独立完成一项任务或处置一次故障，验收人观察并记录 | 验收记录 | 接收人在无离职者提示下完成任务 |
分级标准建议写清楚：必交指接手人缺少该知识就无法独立工作，必须书面化并讲解；应知指影响判断质量，需要文档加一次口头说明；可查指已有稳定文档或可自行检索获得，只需给出入口。分级结果决定投入多少时间，避免所有内容平均用力。
文档化的关键是统一结构。每篇交接文档至少回答四个问题：这件事的背景是什么，结论是什么，依据在哪里，出问题找谁。背景和依据正是隐性经验最容易丢失的部分，只写结论的文档在半年后往往无法使用。文档集中存放在团队约定的知识空间中，按业务对象建立页面组并关联对应项目，需求、任务进度与说明文档相互对应，接收人从项目入口就能找到相关材料。ONES Wiki 支持页面组关联项目、文档嵌入任务进度与报表，并记录页面版本，适合承载这类需要长期维护的交接材料；问答记录和验收结果则可以放在对应工作项下，形成可追溯的交接过程。
角色与交付物：谁负责写、谁负责收、谁负责验
知识沉淀容易变成离职者的单方面任务，写多写少全凭自觉。把角色和交付物定清楚，交接才有责任主体。核心分工是：离职者提供内容并对决策背景负责，主管定范围和优先级，接收人负责整理、复述和验收，协作方补充依赖关系。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 离职者 | 提供六类知识内容，参加讲解与答疑，对关键决策的背景和依据负责 | 知识文档初稿、讲解材料、答疑答复 |
| 直接主管 | 确定交接范围与优先级，裁定哪些内容必须书面化，指定接收人和验收人 | 交接范围表、分级结论、验收人指定 |
| 接收人 | 把口头内容整理成可检索文档，复述确认理解，完成实操验收 | 整理后的文档、复述记录、验收记录 |
| 协作方（接口人、运维、测试） | 补充上下游依赖、接口行为、运维操作和联系人场景 | 依赖说明、联系人场景备注 |
接收人承担整理工作这一点值得强调。让接收人用自己的语言重写文档，本身就是一次理解检验；如果接收人只能照抄离职者的原话，说明理解尚未到位。主管的角色是裁定，而不是代写：哪些内容必须书面化、哪些口头讲清即可，由主管结合接手难度拍板，避免交接范围无限扩大或关键内容被跳过。
示例：一个模块负责人的离职知识沉淀
以下为演示情景。某研发人员负责订单模块，同时参与两个在办项目，离职通知期为三周。主管与其确认交接范围后，按六类知识逐项盘点，结果如下。
| 知识类别 | 具体内容 | 分级 | 处理方式 |
|---|---|---|---|
| 需求与决策 | 订单拆单规则的由来，曾评估合并下单方案但未采用 | 必交 | 书面记录背景、备选方案与取舍原因，讲解会重点说明 |
| 系统与代码 | 订单模块架构、状态机设计、两处历史遗留逻辑 | 必交 | 补充架构说明，标注不可改动的代码段及原因 |
| 流程与依赖 | 与库存、支付系统的接口时序，异常返回的实际表现 | 必交 | 更新接口文档，补充异常场景说明 |
| 故障与运维 | 近一年三次线上故障的现象、定位路径与处置动作 | 应知 | 整理故障复盘，口头讲解排查思路 |
| 人员与外部关系 | 支付渠道对接人、库存系统负责人 | 应知 | 联系人清单注明对接场景与沟通习惯 |
| 在办事项与风险 | 两个项目的未完成需求、一个已知性能隐患 | 必交 | 任务逐项转交，风险注明触发条件与观察指标 |
分级上，架构说明、接口异常表现、拆单规则背景属于必交，必须书面化并当面讲解；故障复盘和联系人属于应知，文档加一次讲解即可；订单模块的部署脚本已有运维文档，标注“指向已有文档”，不再重写。
验收环节安排了一次真实任务：接收人独立处理一条订单超时告警，从告警信息定位到库存接口超时，按交接文档中的处置步骤完成降级并恢复。验收人记录了两个问题：接收人对降级开关的生效范围理解有偏差，交接文档中“异常返回的实际表现”一节缺少超时重试次数的说明。这两处当场回补文档，接收人复述确认后才算通过。验收记录连同问答记录归档在对应项目下，后续接手人可以直接查阅。
完成检查：交接是否真的完成的判断标准
文档写完只是中间状态。判断交接是否完成，看接收人能否在没有离职者提示的情况下独立工作。以下检查表可以逐项核对，任一阻断项未通过，交接不应关闭。
| 检查项 | 通过标准 | 是否阻断 |
|---|---|---|
| 文档可检索 | 接收人仅凭关键词就能在知识空间中找到所需内容，包括附件中的信息 | 阻断 |
| 内容可理解 | 关键决策写明了背景与依据，接收人能解释为什么这样做 | 阻断 |
| 实操可复现 | 接收人独立完成至少一项真实任务或故障处置，过程有记录 | 阻断 |
| 风险有归属 | 在办事项、遗留问题、外部联系人均有明确接手人 | 阻断 |
| 问答有回补 | 讲解会提出的问题都已答复并回写文档，无口头悬置事项 | 非阻断，但需限期完成 |
常见缺口集中在三处。只交代码不交背景，接收人知道怎么改，不知道能不能改；只写正常流程不写例外，遇到异常返回时无从判断；联系人只写姓名不写场景，拿到名单也不知道什么时候该找谁。检查时针对这三点各抽一项追问，通常能暴露文档的真实完成度。
交接关闭后，文档仍需保持可维护：接收人在后续处理同类问题时补充新的故障记录和决策说明，让这份材料从一次性交接清单变成团队持续使用的知识资产。ONES Wiki 的页面版本记录和全局搜索能力，可以在这一阶段帮助团队追溯内容变化、快速定位历史说明。
常见问题
离职通知期只有一两周，五步流程来不及全部走完，应该优先保哪几步？
时间紧张时，可以压缩文档打磨和讲解会的轮次，但盘点分级和实操验收两步建议保留。盘点分级决定有限时间投向哪里，跳过它容易把时间花在已有文档的内容上，真正接手困难的部分反而没交。实操验收是判断知识是否转移的唯一可靠方式，省略后文档数量再多也无法确认接收人能独立工作。
具体做法是：范围表只列必交项，应知和可查项标注入口即可；讲解会合并到验收前的答疑环节；验收任务选一项高频、影响面明确的真实工作，例如一次常见告警处置，不必追求覆盖全部场景。
隐性经验很难写成文档，交接时怎么处理才算到位？
隐性经验包括判断依据、踩坑记忆和非正式沟通渠道，这类内容靠文档单独承载效果有限。可行的做法是把它挂到具体场景上：每条隐性经验都对应一个真实发生过的事件或一次具体决策，写清当时的现象、考虑过的选项、最终选择和后续结果。这样接收人读到的是一个可复用的判断过程，而不是一句抽象结论。
讲解会上由接收人针对每个必交项追问“为什么这样做”“什么情况下不适用”，问答记录回写到文档对应段落。接收人用自己的语言复述一遍，能复述出条件和例外，说明理解到位；只能重复原话，说明还需要补充讲解。
接收人本身工作量已经饱和，交接质量如何保证？
接收人投入不足是交接失败的常见原因，靠要求其“抽时间学习”通常无效。主管需要在范围表确认阶段就为接收人预留交接工时，把讲解会、文档整理和实操验收排进其工作计划，而不是作为额外任务叠加。
范围上做减法也有帮助：必交项控制在接收人真正接手工作所必需的最小集合，应知项以文档加一次讲解为主，可查项只给入口。验收任务选择接收人后续本来就要承担的工作，让验收过程同时成为正式接手的第一步，投入不会白费。
交接完成后，这些文档如何避免变成一次性材料？
交接文档要持续可用，关键是让它跟着实际工作更新。接收人在后续处理同类问题时，把新的故障记录、决策说明和例外情况补充到对应页面，而不是另起新文档。文档结构保持背景、结论、依据、联系人四个字段，新增内容按字段归位，半年后仍能读懂。
在协作平台中承载时，页面版本记录可以帮助追溯内容变化，全局搜索让后来者按关键词定位历史说明。ONES Wiki 支持页面版本记录与多类型搜索，附件内容也能检索，适合承载这类需要长期维护的交接材料。
多人共同负责一个模块时，知识沉淀应该由谁主导？
由对该模块整体负责的人主导盘点，其余成员按各自负责的部分提供内容。主导者的职责是保证六类知识没有遗漏、分级口径一致，而不是替所有人写文档。主管在范围表确认时明确每项知识的提供人和接收人，避免出现“大家都以为别人会写”的空档。
如果模块存在多个接收人，按业务对象拆分接收范围，每项知识只对应一个明确接收人，验收也按人分别进行。共同负责的部分，例如跨模块接口，由主导者牵头组织一次联合讲解，接口双方都在场确认。
