AI编程成本应看交付成果而非token消耗

驱动中国11月4日消息，据《麻省理工科技评论》报道，AI编程智能体在执行开发任务时，单次任务消耗的token可达基础聊天提示的10至50倍。报道认为，企业评估AI编程投入时，不应只盯着token用量，而应转向衡量实际交付的软件成果，例如按「每个已合并拉取请求成本」计算投入产出。

智能体编程与普通问答不同。开发者交给AI一个编码任务后，系统通常会进行规划、生成代码、运行测试，并反复修正错误。越有用的智能体往往调用次数越多。在按token计费的模式下，创造较高价值的工作流也可能带来较高成本。报道提到，财务压力已经出现：优步(Uber)在扩大使用Claude Code后，据报道其2026年全年AI预算在4月即已耗尽；GitHub Copilot从固定价格转向按量积分；高德纳(Gartner)预测，到2028年AI编程token成本将超过开发者平均薪资。

面对成本压力，常见做法是设置用量上限、限制席位数量，或要求开发者在启动智能体前经过审批。但报道指出，一刀切的限制可能压缩真正交付价值的工作流，也会把管理目标放在错误指标上。每token成本衡量的是消耗，而不是结果；有些支出来自重试、失控循环等浪费，有些支出则对应软件交付工作。单纯计量工具无法区分两者，支出上限同样难以区分。

报道提出，更合理的指标是「每个已合并拉取请求成本」，即把AI辅助开发总成本除以通过评审并合并的变更数量。同时，还应追踪返工和缺陷情况，避免较低成本的变更掩盖质量下降。如果随着AI使用量增加，这一成本下降且质量不受影响，说明开发者正在把更多消耗转化为可用软件。核心问题不是使用了多少token，而是投入最终产出了多少完成工作。

要改善这一关系，报道认为需要两项变化：把昂贵推理留给必要任务，并降低常规工作成本。智能体编程并不需要每一步都使用最强模型。对于复杂规划和新型推理，可使用前沿模型；在政策要求下，也可使用本地部署的旗舰模型。对于代码生成、测试创建、重复重构等适合的工作，可路由到企业自行运营的开放权重模型。网关可按任务复杂度、数据敏感性、成本和延迟进行请求路由，使高级推理只在值得的场景使用，而不是让整个工作流都按高级价格计费。

开放权重模型让这种分工更具可行性。软件工程基准显示，部分领先开放权重模型可在某些任务上接近前沿模型表现，但这并不意味着它们在所有代码仓库和工作流中等价。报道建议，在分配生产任务前，应使用企业自有代码、测试和验收标准评估候选模型。与此同时，企业还需要决定由谁拥有算力。租用推理时，每次调用都会增加账单；自有容量时，大部分成本在前期已经投入，随着使用量增长，每次额外调用会变得更便宜。按token定价会让重度使用成本上升，而自有容量在团队使用增加时可能更高效。

不过，自有容量并非没有成本，电力、运维、维护和折旧都需要纳入计算，关键指标是每个已合并拉取请求的全成本。报道还指出，自有容量会带来一项通常不出现在账单上的价值：对敏感代码的控制。当代码生成和测试在本地运行时，专有代码可以留在企业内部，只有经过批准的规划提示和受治理的例外请求，才通过企业控制的网关发送到外部模型。这有助于打开安全要求通常阻碍采用的敏感代码仓库，也被视为潜在收益较大的场景。

报道以慧与(HPE)为例称，其混合AI平台将150多个内部应用的常规工作负载路由到本地运行的开放权重模型，其中包括HPE Private Cloud AI，结果是token成本下降30%至50%。这一案例显示，企业正在从单纯控制token消耗，转向以交付质量、成本效率和代码安全边界来重新衡量AI编程投入。