做交付这么多年，我以为报价这件事已经不会难住我了。直到接了第一个 AI 项目。
那次我很自信地按人天报了价，做下来发现：人是省了，token 花了不少，更要命的是验收阶段来回扯了三轮——客户觉得「它回答得不够聪明」，我说「你当初没定义什么叫聪明」。最后项目是收尾了，但利润薄得像纸。
从那以后我改了做法。这篇讲的是改了什么，以及为什么。
一、AI 项目和传统项目的三个不同
| 维度 | 传统开发 | AI 项目 |
|---|---|---|
| 成本结构 | 几乎全是人天 | 人天 + 持续的 token 成本 |
| 产出确定性 | 功能做出来就是做出来了 | 效果好不好是连续的，没有做完的那一刻 |
| 依赖方 | 你和需求方 | 你、需求方、以及一个你控制不了的第三方模型 |
第三条最容易被忽略：模型厂商改一次版本、调一次价，你的项目行为就可能变。这件事你必须在最开始就跟客户讲明白，否则后面所有的锅都是你的。
二、先给需求分型
报价前先做一件事：判断这个需求属于哪一类。风险差别很大，报价方式也应该不一样。
| 类型 | 典型需求 | 风险 | 怎么报 |
|---|---|---|---|
| A. 套壳与集成 | 接一个现成的模型做对话、摘要、翻译、客服问答 | 低 | 可以按人天报，边界清晰 |
| B. 业务流程嵌入 | 把模型塞进现有流程：工单分类、合同提取、报表解读 | 中 | 人天 + 效果达标条款，分期 |
| C. 自主决策 | 让 agent 自己跑流程，比如自动处理退款、自动派单 | 高 | 建议先做付费 PoC，别一口价 |
C 类尤其要说清楚：这类项目的难点不在开发，在和甲方一起把「什么叫对」定义清楚。这个阶段没法一口价，因为谁都不知道要来回多少轮。我的做法是单独报一个「概念验证」的价，做完再谈正式开发。
三、报价：把这几项算进去
AI 项目容易漏掉的成本，按我踩过的坑排：
- token 成本。这个要按最坏情况估，不是按理想情况。一个用户一次问答可能不贵，但一个 agent 在后台反复读文件、重试、思考，消耗能到几十倍。按你预估的三到五倍留余量。
- 峰值成本。别忘了有峰谷价差的厂商，白天是最贵的时段。如果你的批量任务能排到夜间，成本直接减半——这个要在设计阶段就定下来。
- 评测成本。做评测集、跑评测、反复调，这部分工时非常可观，而且很多客户不认为这是「应该付费的开发」。要单独列出来。
- 调模型的工时。提示词迭代、切分策略调整、召回优化——这些看不见界面变化，但很花时间。
- 模型变更的维护成本。版本锁定能规避一部分，但长期项目总会有升级需求。按年维护报，或者明确「首次交付不含后续模型适配」。
- 兜底方案的成本。降级、转人工、规则兜底，这些是必须的工程件，不是可选项。
报价单上我现在的做法是把 token 成本单独列一行，并注明「按当前价格与预估用量估算，实际以用量结算」。这样客户知道这不是你乱加价，也避免后期涨价时说不清。
四、工期：不确定性在哪
AI 项目的工期估算，最容易翻车的地方是你按「实现」估，实际时间花在「调优」上。
一个典型 AI 项目的真实时间分布（我的经验值）：
需求澄清与「什么叫对」的定义 25% ← 最容易被低估
数据整理、切分、评测集 20% ← 客户常以为不用做
功能实现 20% ← 这部分其实最快
调优循环（提示词/召回/参数） 25% ← 最不可预测
工程件（超时/降级/限流/审计） 10% ← 不做就等着出事所以我的做法是：把调优部分单独报一个区间，并明确「超出部分按人天另计」。不然你就会陷入「说好两周，做了两个月，还不好意思加钱」的境地。
另外提醒一句：工期里一定要留出让客户参与的时间。定义「什么叫对」这件事，必须甲方出人，你代替不了。如果甲方配合不了，那这个项目就不该接。
五、验收：最容易扯皮的地方，要提前写死
「它不够聪明」是最难处理的一类反馈，因为它不可证伪。解决办法只有一个：在开工前就把验收标准写成可以打勾的条目。
验收标准模板（写进合同附件）
一、功能范围
1. 支持以下 N 类问题：___（明确列出）
2. 不支持：___（明确列出，越具体越好）
二、效果指标（用评测集跑，不少于 XX 条）
1. 召回准确率 ≥ __%（应命中的文档被命中）
2. 答案可用率 ≥ __%（人工判定为可直接使用）
3. 反面用例拒绝率 ≥ __%（不该答的问题必须说不知道）
三、性能指标
1. 首字节响应 ≤ __ 秒（P95）
2. 完整响应 ≤ __ 秒（P95）
四、可用性
1. 模型不可用时的降级行为：___
2. 数据不出境 / 不用于训练：___（合规要求写清楚）
五、评测方式
1. 评测集由双方共同确认，共 XX 条
2. 以评测集跑分作为验收依据，不以主观感受为准这里面最有价值的是第二条和第五条：把「效果好不好」变成「评测集跑分」，并且评测集双方共同确认。这一条能救你于水火。
而第一条里「不支持」那一栏往往比「支持」更重要——提前说清楚它做不了什么，比事后解释为什么做不了，省事一百倍。
六、风险清单（和甲方讲清楚，也写进合同）
- 幻觉。模型会生成看起来合理但不正确的回答。涉及医疗、法律、金融、以及任何会产生实际后果的场景，必须有人审环节，不能全自动。
- 数据出境。客户数据能不能进公有云模型，这是合同问题不是技术问题。提前确认，必要时走私有化或境内服务。
- 第三方变更。模型厂商调价、下线、改行为，都不由你控制。写清楚这种情况下的处理方式和责任边界。
- 效果不达预期。这一条必须提前说：AI 项目的效果上限受限于数据质量和场景本身的确定性。数据烂、需求模糊，再强的模型也做不好。
- 用量超预期。用户一旦觉得好用，用量可能远超预估。成本闸门和用量告警是交付的一部分，不是附加服务。
七、我的建议：从一个小口子开始
如果你和我一样是接单做交付的，我的建议是：别接第一个项目就做全流程 agent。找一个客户已有的、痛感明确的、边界清晰的小场景——比如工单自动分类、合同关键信息提取、报表自动解读——做一个两周能上线的小东西。
原因有三：这类场景效果容易量化；出问题代价小；做成了客户自己会提出下一步。而一上来做大的，多半会陷在「什么叫对」的泥潭里。
最后一句实话：AI 项目里最贵的不是模型，是「把需求说清楚」这件事。你在这上面多花的时间，会以十倍的方式省回来。
备忘
- AI 项目三个不同：成本含持续 token、效果是连续的没有「做完」那一刻、依赖你控制不了的第三方模型。
- 需求分型：A 套壳集成（可一口价）、B 业务流程嵌入（人天+效果条款，分期）、C 自主决策（先做付费 PoC）。
- 报价必算六项：token 成本（按预估 3-5 倍留余量）、峰值成本（批量排夜间可减半）、评测工时（单独列）、调模型工时、模型变更维护、兜底方案。
- token 成本在报价单上单独列一行，注明按当前价与预估用量估算。
- 工期真实分布：需求澄清 25% / 数据与评测集 20% / 功能实现 20% / 调优 25% / 工程件 10%。调优部分单独报区间，超出按人天另计。
- 工期要留客户参与时间；甲方配合不了就不该接。
- 验收模板五块：功能范围（「不支持」比「支持」更重要）、效果指标（召回/可用率/反面用例拒绝率）、性能指标（P95 首字节与完整响应）、可用性（降级行为、数据不出境）、评测方式（以评测集跑分为准，不以主观感受为准）。
- 风险清单：幻觉（高风险场景必须有人审）、数据出境（合同问题）、第三方变更、效果不达预期、用量超预期（成本闸门是交付的一部分）。
- 建议：从小场景起步（工单分类、合同提取、报表解读），两周能上线；别一上来做全流程 agent。
- 最贵的不是模型，是「把需求说清楚」。
一起聊聊