交付验收成本合同
AI 项目最容易吵的三件事：验收、Token 成本、回款
阅读约 3 分钟零七零六科技
先说结论
AI 项目吵起来，很少是因为技术做不出来，多半是因为三件事没写清楚：什么算验收通过、用量的钱谁承担、什么时候付。
这三件事都可以在签约前用一页纸定下来，成本极低，但绝大多数项目是等吵起来才补。
验收：功能上线 ≠ 业务变化
行业里最常见的验收写法是「系统上线并完成培训」。它的问题不在表述，在于它没有指向结果。
| 维度 | 按功能验收 | 按业务结果验收 |
|---|---|---|
| 验收物 | 系统可登录、功能可点击 | 一段真实业务在系统里跑完 |
| 谁判断 | 项目组 | 一线使用者 + 业务负责人 |
| 失败处理 | 修 Bug | 先回退到原流程，再决定是否继续投入 |
| 尾款条件 | 上线即付 | 连续运行一段时间且指标达标 |
| 三个月后 | 没人用也不违约 | 无人使用即为未达标 |
按结果验收并不是要把风险全压给交付方，而是把「谁用、怎么用、用到什么程度」提前摆到桌面上。
一份可执行的验收定义，通常包含四个要素：
- 基线：现在的数字，实测，不是估算；
- 动作：谁在什么时候用它做什么，一周几次；
- 标准：达到什么算通过，达不到怎么处理；
- 退出：什么情况下双方可以停止，已交付部分如何结算。
Token 成本：钱花在哪，得先说清
大模型类项目的成本结构与软件项目不同，它有一条随用量增长的变动成本。
一线交付里最常出现的争议是：试用期用量算谁的、上线后超量怎么计、模型升级导致的成本变化谁承担（来源：阿里校友 AI 联盟与 FDE 落地实践纪要，2026-10-27）。
比较务实的做法是三条：
- 试用期定额：约定一个额度，超出部分由提出方确认后继续；
- 上线后按量计：把单价与计费口径写进合同附件，而不是口头约定；
- 成本上限：给单次任务设一个成本上限，超了就降级到更便宜的方案或转人工。
第三条经常被忽略，但它决定了系统在流量翻倍时会不会变成负担。
回款与客户选择
回款风险往往在签约那一刻就决定了，只是当时看不出来。几个值得警惕的信号：
- 需求在签约前反复变化，且每次都扩大范围；
- 决策人始终不出现，对接人「回去汇报」；
- 预算来源不明确（「先做，钱再申请」）；
- 期望里包含「做出效果再付」。
这些不是道德判断，是项目风险信号。面对它们，比降价更有效的是缩小范围：先做一个 2–4 周能验收的小场景，跑通了再谈扩展。
签约前写进 SOW 的六条
我们在合同附件里固定放这六条，能省掉后面大半争执：
- 基线数据：现状指标由谁提供、什么时候锁定；
- 验收动作：具体到「谁、什么时候、做什么、几次」；
- 成本归属：试用期与上线后的用量分别怎么算；
- 变更机制：需求变更如何计价、如何影响工期；
- 退出条件：什么情况下停止，已交付部分如何结算；
- 数据归属：训练与评估用到的数据归谁、能不能复用。
六条里最难谈的通常是第 6 条，但在制造与外贸场景里它最不能省——工艺参数与客户名单的归属，一旦含糊，后面所有讨论都会变成猜疑。
一个提醒
把验收写成「业务结果」，不等于承诺效果。两者区别在于：前者约定「怎么判断」，后者承诺「一定达到」。
我们更愿意在诊断阶段就把判断方式谈清楚——如果判断方式谈不拢，说明双方对这件事的理解还没对齐，此时签约只是把分歧往后推。
延伸阅读：
本文为交付方法讨论，不构成合同建议；具体条款以双方签署的合同与 SOW 为准。