交付物要闭环
至少包含任务定义、评测集与标注规范、可运行原型、评测报告、接管机制说明、风险清单、移交文档。缺任何一项，后续工程化都要重新补，验收也无法证明能力可以迁移，后续团队交接也会出现断档，后续交接也顺。
可复现是底线
同一评测集重跑，结果应落在稳定区间；模型版本、参数、提示词与检索配置都要记录在案。不能复现的结果无法用于决策，也无法在模型升级后判断是否退化，团队也不清楚该相信哪一版结果，判断也更有据。
可解释才可信
每个失败样例要有归因：是知识缺失、检索错、指令不清，还是任务本身不适合模型。归因到类，改进才有方向；只给总分，团队只能反复试提示词，效率很低，想归因也无从下手，最后只能整轮重来，改进也更聚焦。
接管路径要真跑过
人工接管不是设计图，要在原型里走通：什么条件下转人工、转给谁、上下文如何带过去。没跑过的接管路径，上线后一定卡住，而这时用户已经在排队等待，用户体验与团队信任往往也会同时受损，验收也更顺畅。
移交含一次独立复跑
验收会前由客户方人员按文档独立跑一遍评测，交付方只看结果、不现场指导。能独立复跑，才算真正移交；否则换一个人就要重新问一遍，知识仍然留在外部，交接就只剩下形式上的签字确认，交接也更实在。
适用与不适用
适合谁
- 准备把原型结论提交立项会的团队
- 需要向采购与合规说明验证过程的单位
- 计划在原型通过后转工程化落地的项目
不适合谁
- 只需要一次演示给领导看、不做评测的场合
- 没有业务人员参与标注、全靠供应商自评的项目
典型场景
某制造企业的设备故障问答原型验收会上，客户方工程师按移交文档独立复跑评测集，结果与交付方报告差异在两个百分点内；抽查十条失败样例均有归因。会议据此通过验收，并把评测集转为后续回归测试，供后续发布使用。
可执行步骤
- 对照清单逐项核对七类交付物是否齐全、版本是否一致、责任人是否写明
- 由客户方按文档独立复跑评测集，并与交付方报告逐项比对差异，并留痕
- 抽查失败样例，确认每条都有可核查的归因、证据与改进方向，逐条登记，并留档
- 实测人工接管路径，记录触发条件、转交对象、上下文与耗时，便于事后复盘
- 签署验收结论，书面确认遗留风险、责任人与处理时点并归档，抄送双方，并留档
常见坑
- 只看演示视频，不跑评测集，验收变成观感判断，真实风险被整体后移到生产，验收结论也不可信，返工也更贵。
- 评测报告只给总分，没有分类型错误率，问题无法定位，改进只能靠猜也无法验收，验收时无法举证。
- 移交文档缺配置说明，换人后无法复跑，知识留在个人手里，团队接不住，验收也失去意义，责任也没人担。
- 接管路径未演练，上线首周全部转人工，等于没有自动化，效率反而下降，用户也会流失，反而增加负担。
自检与验收清单
- 七类交付物是否齐全、版本一致且有人签收，可核对
- 客户方是否独立复跑过评测集并记录差异，有记录
- 失败样例是否逐条归因、留有证据可查，可抽查，且有证据
- 接管路径是否实测并记录触发条件与耗时，可复现
- 遗留风险是否书面确认责任人与处理时点，有签认
常见问题
评测报告要写多细？
至少到错误类型与样例级别，附输入、输出、期望与判定理由。只给百分比无法复核，也无法在模型升级后对比退化，验收时更说不清问题出在哪，这一点应在验收会上确认，也便于复核。
原型代码需要交付源码吗？
按合同约定。若后续由客户方工程化，建议交付源码与配置；若仅作验证，可交付可运行环境与文档，但评测集与标注规范必须移交，并约定复用范围，避免后续争议，验收时也不会为归属争执。
验收不通过怎么办？
按里程碑约定处理：补测、缩范围或终止。终止时应保留评测集与失败归因，作为下一轮选型的依据，避免同样的坑再踩一次，也便于交代投入，也能保护团队此前的判断，双方都有依据。