运行手册要能照着做
手册的验收标准是：一个没参与项目的人，按步骤能在半小时内完成一次日常操作和一次降级操作。怎么写才算够：每步要有入口、判断条件与失败后的下一步，不能出现按需处理这类句子。
版本台账要能回溯
记录每次模型、提示词、知识库与接口变更的时间、内容、发起人与回退点。为什么重要：出问题时最先要回答的是最近改了什么，没有台账就只能靠人回忆，排查时间从十分钟拉长到半天。
评测集与口径一起交
只交一批样本不交判定口径，接手人无法判断新版本是好是坏。为什么口径要一起交：口径随意变动，历史对比全部失效。做法是样本、判定规则、标注人与修订记录打包，并约定修改权限。
接口契约写清失败分支
契约不能只写正常返回，要写超时、限流、字段缺失、权限不足时的表现与重试策略。为什么这里最常出事：多数线上事故发生在失败分支没人设计，系统给出半截结果，比直接报错更难发现。
交接要有人签字验收
交接完成以接手人独立操作一次并复述关键判断为标志，由双方负责人签字。为什么必须设这个动作：没有验收的交接往往三个月后才发现缺章少页，届时原团队已解散，补文档成本高出数倍。
适用与不适用
适合谁
- 要把系统移交给客户运维或内部团队的项目
- 人员流动较快、需要知识留存的团队
- 多期建设、后续由其他团队接手的情形
不适合谁
- 一次性试验、用完即弃的原型验证
- 仍由原团队长期运维且无移交计划的系统
典型场景
某能源集团把合同审查助手移交给法务部与信息中心共同运维。交付方在移交前两周组织两次跟岗，让接手人独立完成一次知识库更新和一次版本回退；文档里补上了此前缺失的限流处理说明。移交会上双方按清单逐项确认，遗留的两处文档缺口约定一个月内补齐。
可执行步骤
- 按七类文档逐项列出清单，标注责任人、完成时间与最后验收确认人
- 先写运行手册与降级步骤，用跟岗方式验证新人能否照着独立完成一次
- 把版本台账、评测集与判定口径打包交接，同时明确谁有权修改口径
- 补全接口契约里的失败分支，逐条确认超时、限流与重试的处理策略
- 组织一次独立操作验收，由接手人复述关键判断，双方负责人在场签字
常见坑
- 文档只写结论不写判断依据，接手人遇到变体场景就不敢动，凡事回头问原团队，交接等于没做。
- 运行手册停留在半年前的界面与流程，接手人照做失败两次后彻底弃用文档，知识又回到个人身上。
- 接口契约没写失败分支，异常时系统返回半截结果，业务方以为成功，错误数据流进下游报表。
- 交接没有签字验收，三个月后才发现缺章少页，原团队已解散，也没人说得清当时的设计意图。
自检与验收清单
- 七类文档是否齐全，且各有验收人与完成时间
- 运行手册是否经未参与项目的人跟岗验证可照做
- 版本台账是否记录每次变更的内容、发起人与回退点
- 接口契约是否覆盖超时、限流、字段缺失与重试策略
- 交接是否以接手人独立操作一次并签字确认为完成标志
常见问题
文档写到多细才算够？
以接手人能独立完成日常操作与一次降级为准，不以页数衡量。判断方法是让没参与项目的人照着做一遍，卡住的地方就是要补的地方；这比按模板逐项填充更能暴露真实缺口，也更快收敛。
运维一定要客户自己做吗？
不一定。可以由交付方代为运维，但知识必须留在客户侧，包括版本台账、评测口径与故障处置记录。全托管的代价是更换供应商时几乎从零开始，这一点在合同的知识归属条款里应提前写清。
交接后原团队还要支持多久？
常见做法是设一到三个月的过渡期，期间原团队按约定响应级别提供支持，逐步把问题处置转给接手方。过渡期结束前应完成一次真实故障的联合处置，否则接手方只是看过文档，没有实战经验。