先定范围再定单价
怎么拆才有效？把项目拆成诊断、场景开发、系统集成、上线交接、运营支持五段，每段写清交付物与不做什么。范围不清楚时任何单价都无法比较，谈价只能变成博弈，签约后还要反复解释什么算完成。
三种计价单元
人天法适合需求不稳的探索期，阶段法适合边界清晰的交付，场景包法适合可复用程度高的重复需求。同一项目可以混用：探索段按人天，交付段按阶段，复用段按场景包，不必强求统一。
预留项与变更单
把无法量化的接口改造、数据治理、合规评审单列为预留项，约定上限与触发条件。预算在立项时就能覆盖不确定部分，也避免后期以增项名义重谈总价，把技术分歧变成商务纠纷。这条边界要先写进合同。
报价单该有的结构
报价单怎么写？逐项列出人力角色与投入、软件与算力、集成与测试、培训与交接、运维期服务，并注明计量单位与结算周期。结构完整，采购方才做得了同口径比较，而不是只盯着最后一行的总价。
验收责任要落到人
谁负责验收要提前定：业务部门判定场景是否可用，技术部门核对集成与权限，财务核对结算口径，三方各自出具确认意见，避免验收时只有一方签字。范围变更后由原验收人重新确认，责任不会悬空。验收单与付款节点一一对应，节点未通过就不进入下一段付款。
适用与不适用
适合谁
- 有明确业务场景、需要外部交付能力的企业
- 采购或商务需要把报价拆到可比颗粒度
- 项目含多系统集成、需要分阶段验收
不适合谁
- 只想要一个总价、不做范围确认的采购
- 把 AI 项目当标准软件、按功能清单验收的团队
典型场景
某零售企业采购部收到两份报价，一份按人天、一份按阶段。团队先补齐场景清单与验收口径，再把两份报价换算到同一张表：诊断、开发、集成、交接各段的工作量与交付物逐项对齐，据此重谈付款节点，价差收窄。
可执行步骤
- 列出本期要解决的业务问题，并逐条写明哪些需求不在本次的项目范围内
- 把项目切成诊断、开发、集成、交接、运营五段，每段写清交付物与验收人
- 按段选择人天、阶段或场景包计价，避免整包一口价掩盖工作量差异
- 把预留项、变更单价与结算周期单列，写明触发条件与可调整的上限额度
- 用同一张表对比多家报价，逐项标注缺失内容与各自的前提假设条件
常见坑
- 只谈总价不谈范围，签完合同再补需求，工期与预算同时失控，最后只能压缩验收环节与交付范围
- 把探索期的模糊工作量按固定总价包死，双方都不愿先投入，试点容易走过场，结论自然不可信
- 预留项不设上限也不写触发条件，结算时超出立项预算，财务与审计都难以追溯到具体环节
- 报价不含系统集成与上线交接，上线后被迫二次采购，原来的低价变成追加预算的理由，采购部门很难解释
自检与验收清单
- 每段是否写明交付物、完成标准与明确不做什么
- 报价单是否写明计价单元、计量方式与结算周期
- 预留项是否设有上限、触发条件与变更审批流程
- 多家报价能否换算到同一张对比表并补齐假设
常见问题
按人天报价一定比总价贵吗？
不一定。需求稳定时按总价更省管理成本；需求模糊时人天法反而可控，因为工作量可见、可核。关键看范围是否写清、变更如何计价，两种方式也能在同一项目里分段混用。
能不能只买一个场景包？
可以，但场景包的前提是流程与数据接口相对标准。若需要改造多个系统，集成工作量往往超过模型部分，应把集成单独列项评估，再判断场景包是否仍然划算。
计价里要不要含算力费用？
建议单列。算力用量随业务波动，混进开发费会导致后期无法对账；可约定试用期由服务方承担，上线后按实际用量结算，财务对账时也有据可依，争议更少。