交付物：评测集
包括样本来源、抽样规则、标注口径与版本号，接收方应能用它复跑。为什么重要：上线后的回归、模型升级与效果争议，都要回到同一批样本上比较，没有它就无从判断变化来自哪里，也无法向业务解释。
交付物：台账与缺陷
台账记录每条需求对应的测试与结论，缺陷单记录现象、修复与回归。怎么做：按需求编号归档，接收方能顺着编号查到当时的判定依据与修复版本，不必再向原团队逐条确认，交接成本明显下降，也减少反复确认的时间。
交付物：运行手册
写清日常操作、异常处理、人工接管条件与联系人，而不是只写部署步骤。为什么：验收合格只说明当时可用，接管人真正需要的是出问题时按什么顺序处理，以及哪些情况必须停下来找人，这些都要写进手册。
交付物：验收单
明确已验收、未验收与遗留项，以及各项的责任人与复查时间。边界：遗留项不等于免责项，需写清触发条件与处理方式，避免后续以当时已知为由互相推诿，也避免无人跟进，责任要落到具体的人，复查时间要写进台账。
交接会：接手人复跑
交接不是宣读文档，而是接手人在自己环境里复跑关键用例并记录结果。怎么做：把复跑通过作为交接完成标准，原团队只做旁观与答疑，问题当场登记并约定修复责任人，否则不算交接完成，复跑记录作为交付附件。
适用与不适用
适合谁
- 要把系统移交给客户运维或内部运维团队的交付项目
- 人员轮换频繁、文档常断层的组织
- 准备进入长期运营阶段的 AI 应用
不适合谁
- 尚未完成验收、无稳定版本的项目
- 不打算长期运行的一次性活动工具
典型场景
某城投公司的合同审查助手通过验收后移交法务与信息中心。交接会上，法务同事在测试环境复跑了十条典型条款用例，发现两条引用来源失效；项目组当场更新知识库索引并补充运行手册，双方在移交清单上签字，并约定一周内补齐。
可执行步骤
- 整理评测集、抽样规则与标注说明，并随验收材料一并交付并归档。
- 按需求编号归档用例台账，并把缺陷修复与回归记录一并整理归档。
- 编写运行手册，覆盖日常操作、异常处置与人工接管的具体触发条件。
- 在验收单中逐项列明遗留项的责任人、触发条件与复查的具体时间点。
- 交接会上由接手人在自建环境复跑关键用例，并逐条记录结果与问题。
常见坑
- 只交一份结论页，接手人遇到问题无从查起，只能反复回头找原团队，交付变成长期依赖。
- 评测集留在供应方手里，客户无法独立回归，模型升级后失去比较基准，只能凭主观感觉判断好坏。
- 运行手册只写部署步骤，不写异常处置与人工接管条件，出事仍靠原班人马，值班形同虚设。
自检与验收清单
- 评测集是否包含样本来源、标注口径与版本号
- 用例台账与缺陷单是否按需求编号归档并可检索
- 运行手册是否包含异常处置与人工接管的具体条件
- 遗留项是否写明责任人、触发条件与复查时间
- 交接是否以接手人独立复跑关键用例为完成标准
常见问题
客户要求把测试数据全部带走可以吗？
可以按合同与数据安全要求处理，但含个人信息的样本应先脱敏，并明确使用目的与保存期限。边界：客户数据归客户，我方不留存副本；需要在合同中写清交付形式与销毁确认方式。
交接后原团队还要支持多久？
建议约定一段观察期，明确响应范围与响应方式，例如只处理与验收结论相关的疑问。观察期结束后转入常规运维或按新的服务约定执行，避免无限期免费支持拖住双方。
文档用什么形式交付？
版本化、可检索的形式优先，例如仓库中的 Markdown 或客户指定的文档系统。避免只交付截图与聊天记录；PDF 可作为签署版留档，但日常维护应有可编辑源文件，否则半年后就无法更新。