预算分三段
试点、建设、运营三段分开列预算，各自设上限与放量条件。为什么：三段的花钱节奏与风险不同，混在一起会导致试点没做完就大额采购。怎么做：每段写明交付物与判断标准，上一段未达标不进入下一段。
评测先行
先建评测集，再谈采购与规模。怎么做：从真实业务里抽题，覆盖常见、难例与边界三类，确定评分人与评分口径；评测集要能复跑，模型或提示词调整后重新测试，才能比较差异，也才能在续约时作为依据。
合同写清运维与退出
运维响应、知识更新责任、数据导出格式与过渡期支持，都要写进合同。为什么：缺少这些条款，更换供应商时知识与配置难以迁移。边界：合同条款由客户方法务审核确认，实施方提供技术说明，避免交付后扯皮。
季度复评与停止条件
给每个场景设停止条件，例如连续两个月未达验收指标、使用率持续低于约定水平，或复核成本持续高企。怎么做：复评会由业务、技术与财务参加，按数据决定继续、调整或停止，结论书面留档并同步给预算审批人。
决策权在客户方
预算、采购与上线决策由客户方按内部制度审批，外部服务方只提供材料与建议。为什么写这条：责任边界不清会在出问题时互相推诿。怎么做：在项目确认单中列明审批人与决策节点，避免出现口头授权。
适用与不适用
适合谁
- 准备启动或扩大 AI 投入的企业
- 需要向管理层提交投入方案的项目负责人
- 采购与法务参与 AI 合同的团队
不适合谁
- 只做个人工具试用、不涉及预算审批的岗位
典型场景
某工程企业年初拿到一笔 AI 预算，业务部门希望一次性采购平台。项目组按清单执行：先划出试点预算做两个场景评测，评测通过后再进建设段，合同里补上知识更新与数据导出条款。半年后复评，一个场景继续放量，另一个按停止条件收缩，预算转投评测与运维。
可执行步骤
- 把预算拆成试点、建设、运营三段，分别设定金额上限与放量条件。
- 从真实业务抽题建评测集，事先确定评分人、评分口径与复跑频率。
- 在合同中写入运维响应时限、知识更新责任与数据导出格式条款，逐条确认。
- 为每个场景设定可量化的停止条件，并固定复评时间点与参加人员。
- 季度复评按数据决定继续、调整或停止，结论书面留档并告知审批人。
常见坑
- 预算不分段，试点还没完成就采购平台，后续调整空间被彻底锁死，只能将就使用，难以挽回。
- 评测集由供应商提供，题目偏向模型强项，验收结论明显失真，团队却以为已达标，问题被推到上线后。
- 合同未约定知识更新责任，制度改版后回答过期，无人负责修复，用户流失、投诉增加，口碑受损。
- 没有停止条件，效果不佳的场景长期占用预算与人力，拖累其他项目推进，也很难向管理层解释。
自检与验收清单
- 预算是否分为试点、建设、运营三段并各设上限
- 评测集是否来自真实业务，并由客户方逐条确认
- 合同是否含运维、知识更新与数据导出格式条款
- 每个场景是否设定停止条件与固定复评时间点
- 审批人与决策节点是否写入项目确认单并可查
常见问题
三段预算的比例怎么定？
没有固定比例，取决于场景复杂度与数据条件。可行做法是试点段先给足做两到三个场景验证的资源，建设段按通过评测的场景逐个立项，运营段按用量预估。比例每季度按实际消耗调整。
评测集要多少题才够？
看覆盖而非绝对数量。常见问题、难例与边界情况都要有，且每个类别有明确判定标准；题目要来自真实业务并由业务方确认。数量不足时优先补难例，而不是重复常见题凑数。
停止条件会不会让团队不敢投入？
明确的停止条件反而降低决策压力，因为它把失败定义成可预期的结果而非追责事件。关键是把条件写在与业务共同确认的文档里，复评时按数据说话，而不是按印象判断。