一、交付物清单要逐项写明

（一）模型与权重

包含最终模型的权重文件、结构说明与推理所需配置。权重文件的格式与版本要注明，并提供一份可直接运行的推理示例。

（二）数据与来源说明

训练所用数据的来源、规模、处理方式要形成说明，涉及外部数据时还要注明授权范围。这既是验收依据，也是后续合规审查的材料。

（三）文档清单

训练说明、评测报告、部署手册、已知限制，这四份文档缺一不可。尤其是已知限制，写清楚能减少后续很多误解。

二、验收指标分三类

1. 效果指标

在双方确认的评测集上达到约定的分数或幅度。评测集的构成、规模与评测方式要在合作开始前固定，中途更换会让结果失去意义。

2. 性能指标

包括单条请求的时延、单位时间内的处理量、以及所需资源规格。性能指标要结合真实流量特征来定，而不是只看峰值。

3. 稳定性指标

连续运行时长、错误率、异常情况下的表现。短期跑通不等于长期稳定，这一项需要约定观察窗口。

三、验收流程与时间安排

流程按下面三步走比较清晰：

① 交付前先做一次预验收，用约定评测集跑一遍，发现问题留出修改时间。

② 正式验收时双方同时在场，按清单逐项核对并记录结果。

③ 验收通过之后设置观察期，观察期内出现的问题由服务方负责处理。

四、权属与保密

（一）成果归属

模型权重、训练过程中产生的中间成果、以及针对特定数据微调后的版本，归属要逐项约定，不能笼统写一句。

（二）数据保密

提供给他方的数据如何保管、能否用于其他项目、合作结束后如何处理，都要写明确。

（三）二次使用

服务方能否把积累的经验用于其他客户，尤其是通用能力的部分，这一条往往最容易产生分歧。

五、交付之后的维护

（一）问题响应

上线后发现效果或性能问题，响应时限与处理方式要约定清楚，并指定对接人。

（二）版本迭代

后续需要重新训练或升级时，是否另行计费、周期多长，提前约定比临时协商顺畅。

（三）交接与文档

服务方退出时要完成知识交接，包括环境配置、评测方式与历史记录，减少留下无法维护的成果。

六、常见争议与对策

（一）评测集分歧

双方对评测集代表性有不同看法时，可以额外准备一份第三方抽样集作为补充，减少主观判断的影响。

（二）环境差异

服务方环境中的表现与自有环境不一致，通常源于依赖版本或硬件差异。约定统一的验证环境能减少这类争议。

（三）效果退化的责任

1. 上线一段时间后效果下降，是数据分布变化还是模型本身问题，需要在合同中约定判断方式与处理流程。

2. 效果未达标时的处理方式要提前约定，是继续迭代、部分退款还是终止合作，写清楚能减少纠纷。

3. 上线之后的效果监控要与业务指标挂钩，技术指标达标不等于业务价值达成，两者都要跟踪。

4. 模型的限制说明同样重要，知道它在哪些情况下会失效，比只看分数更实用。

5. 对效果的预期要留有弹性，模型能力存在边界，把边界写清楚比承诺过高更负责。

（四）评测与验收

1. 评测集的构成最好由双方共同确认，并在合作期内冻结，中途变更会让前后结果无法比较。

2. 评测集之外准备一份抽查样本，用于验证对方是否针对评测集做了过度优化。

3. 交付的模型要在自有环境上重新跑一遍评测，不要直接采信对方提供的结果，这一步能发现环境差异带来的问题。

4. 交付的模型要在自有环境完整复现，包括评测结果与部署流程，这是验收的必要环节。

5. 需求描述要具体到可判定，含糊的表述会让双方对完成标准产生不同理解。

6. 数据提供的格式与质量要提前确认，数据问题是导致进度延误的常见原因。

7. 验收文档的模板要提前准备，临时编写的清单容易遗漏关键项，也不利于双方对齐。

（五）交付节奏与过程管理

1. 合同中应当约定中间成果的交付节奏，而不是只在最后一次性交付；交付的时间节点要分阶段设置，每个阶段都有可检查的产出，分阶段验收能及时发现方向偏差。

2. 过程中的关键节点要有可演示的产出，让进展可见，也便于及时发现方向偏差。

3. 沟通机制要写清：多久同步一次、以什么形式、谁是决策人，这能减少大量等待与误解。

4. 过程中的沟通记录要定期整理，尤其是需求变更与确认，减少事后各执一词。

5. 合作期间的变更要书面确认，包括需求调整与时间调整，减少影响最终的验收判定。

6. 服务方提出的方案要理解其取舍，不理解就接受，后期调整时代价往往更高。

7. 服务方的人员投入要写进合同，投入人数与资历直接影响交付质量，口头承诺并不可靠。

8. 服务方使用的工具与数据来源应当披露，尤其是涉及第三方内容时，这关系到后续的合规审查。

（六）风险控制与结算

1. 观察期内建议保留一定比例的费用，待稳定运行后再结清，这是常见的风险对冲做法。

2. 结算节点建议与验收节点绑定，验收通过之后再支付对应款项，是常见的风险控制方式。

3. 合作开始前做一次小规模试点，用真实需求验证对方的交付能力，比看案例更有说服力。

4. 自有团队要保留核心能力，全部外包会导致后续无法自主迭代，风险很高。

（七）知识转移与归档

1. 验收之后的知识转移要留出时间，包括代码走查与问题答疑，这一步不能压缩。

2. 交付的模型与评测结果可归档到天翼云存储，按项目分目录，便于后续对比与追溯。

3. 合作中产生的数据与文档要一并归档，这些资料在后续维护时同样重要。

4. 自有环境上的验证任务可放在天翼云主机上执行，与生产隔离，既安全又不影响线上服务。

5. 合作经验要沉淀为内部文档，包括选型标准与验收模板，下次合作可以直接复用。

6. 合作结束后做一次评估，记录交付质量、沟通效率与问题处理，作为后续选型的依据。

7. 服务方的内部评审意见值得索取，它能反映交付过程中发现的问题与权衡过程。

结语：把"做成什么样算完成"提前写清楚，是合作顺利的前提。交付物、验收指标、验收流程三件事缺一不可，而且都要量化到可以当场判定的程度。权属与保密条款在合作开始前就要谈定，事后补充往往代价很高。验收通过之后的维护安排同样要写清，否则模型上线之后遇到问题就无人负责。