AI 软件开发外包的 Token 成本如何影响项目计价？

作者：袖梨 2026-09-13

AI 软件开发外包中的 Token 成本会改变项目报价结构，但通常不应直接替代人天费用。合理报价应拆成实施人力、模型调用、第三方服务、测试返工、甲方协作和风险准备金，并在合同中明确模型、计量口径、额度上限、超额审批与验收责任。Token 单价只是其中一个变量；如果只按 Token 加价，甲方无法判断消耗是否来自有效交付、低效重试还是供应商自己的工具选择。

先区分开发期与运行期 Token

开发期 Token 用于需求分析、代码生成、仓库检索、测试、调试和文档编写，通常属于交付成本。运行期 Token 来自上线后的对话、检索、工作流和后台任务，属于持续运营成本。两者的用量驱动因素、责任主体和预算周期不同，不能合并成一个模糊的“AI 服务费”。

成本项	主要驱动因素	合同处理
开发期模型调用	仓库规模、任务轮次、上下文和测试日志	纳入交付报价或设阶段额度
运行期模型调用	用户量、请求频率、输入输出长度	按月预算并单独结算
返工 Token	需求变更、缺陷、模型失败和重复探索	按责任归属分摊
人工成本	设计、审查、测试、部署和项目管理	按里程碑或工时计价

Token 如何进入报价公式

按量模型通常区分普通输入、缓存输入、缓存写入、输出与推理用量，长上下文或批处理还可能使用不同价格。外包商应提交可核对的计算口径，而不是只报一个总 Token 数。

模型费用 = Σ（各类 Token 数 × 对应单价）
项目总价 = 实施人力 + 模型费用 + 第三方服务
         + 测试返工 + 甲方协作 + 风险准备金

模型费用还应标注币种、回了、供应渠道、计价日期和税费。通过订阅或聚合渠道取得的折扣，不代表公开 API 的固定价格；供应商若收取管理加价，应把模型原始成本与服务费分列。

三种计价模式如何受影响

固定总价

固定价便于控制预算，但供应商会为 Token 波动、模型失败和需求不确定性预留风险。适合范围明确、验收标准稳定的项目。合同应写明包含的模型调用额度，以及需求变更和第三方价格调整何时触发重新报价。

工时计价

工时价适合探索性项目，但不能把模型等待、无效重试和内部学习全部转嫁给甲方。应同时报告工时、Token、交付物和验收结果，让甲方判断资源投入是否产生进展。

混合计价

常见做法是核心范围采用固定里程碑价，超出范围的变更按工时计价，运行期模型费用按实际用量结算。混合模式必须定义边界，避免同一工作既计入固定价，又以工时或 Token 再次收费。

报价单应提供哪些用量数据

至少按项目、环境、阶段和模型记录输入、缓存、输出、请求次数、失败次数与费用。开发测试、验收环境和生产环境应使用不同的项目标识或密钥，避免把供应商其他项目的消耗混入。

还需要关联可验证结果，例如完成的需求、合并的变更、通过的测试和关闭的缺陷。单纯追求低 Token 可能造成遗漏，消耗较高也不证明工作有效。更合理的比较指标是每个通过验收功能的总成本，包括失败运行和人工返工。

返工费用应由谁承担

如果甲方改变范围、补充此前未说明的业务规则，新增人力和模型调用可以进入变更单。若返工来自供应商未遵循已确认规格、缺少基本测试或选择了不合适的模型与工作流，则不应自动转为甲方的超额 Token 费用。

模型输出具有不确定性，但这不等于供应商可以免除工程责任。外包方仍需负责代码审查、测试、依赖安全、数据保护和部署验证。合同应把“模型建议”与“可验收交付”分开，只有后者才能作为付款依据。

合同中的关键条款

锁定或列出允许使用的模型、版本和供应渠道，并规定变更通知。
定义普通输入、缓存、输出、推理与第三方工具费用的计量口径。
为每个里程碑设置包含额度、软预警线和不得自动突破的硬上限。
超额调用前提交原因、剩余工作、最新预测和甲方书面批准。
明确需求变更、供应商缺陷、环境故障和模型失败的责任归属。
约定用量日志、源代码、提示与业务数据的所有权和保留期限。
以功能、性能、安全和测试结果验收，不以 Token 数或代码行数验收。

如何设置预算与预警

项目启动时按需求、设计、开发、测试和发布阶段建立 P50 与 P90 预算。P50 用于正常排期，P90 用于风险预留。达到阶段预算的七成或八成时触发预警，要求供应商解释消耗增长和完成度；接近硬上限时暂停非关键调用，先完成状态总结与人工评审。

预算需要随事实更新。需求范围扩大、模型价格调整、测试环境失效或发现跨系统依赖时，应通过变更单重估剩余阶段，而不是事后修改原始基线。保留每次预测与实际值，才能评估供应商的估算能力。

评估报价是否合理

比较供应商时，要求各方在同一需求说明、数据范围和验收条件下报价。不能只比较每百万 Token 单价，还要比较模型选择、缓存策略、成功率、人工审查、测试覆盖、缺陷责任期和上线支持。

PoC 阶段可以选择一至两个代表性功能，记录首次通过率、总 Token、人工工时、返工次数和最终缺陷。若某方案模型费用低但需要大量人工修复，其项目总成本未必更低。若供应商拒绝提供可审计的用量口径，只承诺一个夸张的节省比例，应视为报价风险。

运行期费用不能遗漏

交付价较低并不代表系统生命周期成本低。上线后，用户数量、对话长度、检索文档、代理工具调用和失败重试会持续产生费用。合同或运维协议应明确日月预算、限流、缓存、模型降级、异常循环停止和告警。

同时保留退出方案：模型或渠道更换时，业务数据、提示模板、评测集和调用接口应能够迁移。把所有逻辑绑定到单一供应商的私有能力，可能在未来形成比 Token 更高的迁移成本。

结论

Token 成本让 AI 软件外包从单纯的人天报价变成可变资源与工程责任并存的计价问题。最佳做法不是按 Token 越用越付，而是分开开发期和运行期成本，以阶段额度、可审计日志、超额审批、责任归属和结果验收约束波动。把模型费用放回完整项目总成本中比较，才能避免重复收费，也能让甲乙双方对范围、风险和长期运营形成可执行的共识。