Discussion: 新闻晚报
当开发者把一段编程任务交给 AI 智能体，它不会只回答一次：先规划步骤，再生成代码，接着运行测试，发现报错后推翻重写。据 MIT Technology Review 于 2026 年 11 月 2 日刊发的行业分析（由 HPE 提供、非该刊编辑部撰写），单次任务的 token 消耗可达普通对话提示词的 10 至 50 倍，AI 编程成本的核算方式因此被迫改写：按 token 计费的旧账本，正在把最有价值的工作流记成最贵的那一行。
网红八卦智能体写代码，账单为何成倍膨胀
传统聊天是一次问答，成本曲线平缓；智能体是一条循环流水线。它要读取仓库、拆解需求、生成补丁、跑单元测试，失败后再来一轮。任务越有用，调用次数越多，账单也就越陡。在按 token 计价的前提下，价值创造与费用支出被绑在同一根曲线上，报告直言：「创造价值最多的工作流，也可能变成最昂贵的工作流。」压力已经出现在财务表上。Gartner 在 2026 年 6 月 24 日发布的预测显示，到 2028 年，AI 编程的 token 成本将超过开发者的平均薪资。路透社此前报道称，Uber 在扩大 Claude Code 的使用范围后，据称于 2026 年 4 月就用完了全年 AI 预算；GitHub Copilot 也已从固定月费转向按量计费的 credits 模式。三家信号指向同一件事：用量增长不可逆，计价方式必须升级。
网红翻车一刀切的配额，压掉的是产出而非浪费
面对账单，企业最直觉的反应是设上限：限制席位、限制调用、上线前层层审批。但报告提醒，这种全面限额会连带掐断真正在交付价值的工作流，而且优化的是错误的数字——每 token 成本衡量的是消耗，不是结果。
直播翻车支出里确实有浪费：失败重试、死循环、无意义的上下文膨胀。可支出里也有真正的工作：写代码、补测试、跑回归、把功能送上线。一个只统计流量的电表，分不清厂房里是在生产还是在漏电，成本上限同样分不清。报告写道：「问题不在于用了多少 token，而在于这笔投入产出多少完成的工作。」换言之，管控的对象应当是单位交付的成本，而不是绝对消耗量。
主播八卦换一把尺子：用「每个合并请求成本」衡量 AI 编程
更合适的指标是每个合并请求的成本（cost per merged pull request）：把 AI 辅助开发的总成本，除以通过代码评审并成功合并的变更数量。它把花费直接接到产出上，同时必须并行跟踪返工率与缺陷数，否则「更便宜的变更」可能只是把质量问题藏进了下一轮迭代。判断逻辑很清晰：如果 AI 使用量上升，而每个合并请求的成本下降、质量不退化，说明企业正在把更多消耗转化为可用软件；反之，加量只是在给返工付费。
明星翻车| 衡量指标 | 实际衡量的是什么 | 主要盲区 |
|---|
| --- | --- | --- |
|---|
| 每 token 成本 | 消耗量 | 无法区分浪费与真实产出 |
|---|
| 每席位许可成本 | 人头数 | 完全掩盖重度用户的支出 |
|---|
| 每活跃开发者成本 | 人均支出 | 与软件是否交付脱节 |
|---|
| 每合并请求成本 | 通过评审并合并的成果 | 需配合缺陷率与返工率解读 |
|---|
改善这道等式需要两个动作：把昂贵推理留给真正需要的任务，同时压低日常重复工作的单价。
模型分层与网关路由：把最强模型留给最难的一步
智能体编程并不意味着每一步都要调用最强模型。困难的任务规划、新颖的推理链路，值得动用前沿模型；在合规要求高的场景，则使用本地部署的旗舰模型。而代码生成、测试用例编写、反复重构这类高频工作，可以路由到企业自己运维的开源权重模型。中间的调度层是网关：按任务复杂度、数据敏感度、成本与延迟分配请求，让高价推理只出现在配得上它的时刻，而不是给整条工作流贴上高价标签。报告把这套原则概括为一句话：「衡量例外，而非整个工作负载。」开源权重模型让这种切分越来越可行——软件工程基准显示，领先的开源模型在某些任务上已逼近前沿水平，但这不等于在任意代码库与工作流上都等效。上线前，必须用企业自己的代码、测试与验收标准做实测。
自建算力与混合架构：用量越大，单位成本越低
第二个决定是谁拥有算力。租用推理时，每一次调用都写进账单；自建容量时，成本大部分前置为固定资产，调用越多，单次摊销越低。但拥有并不免费：电力、运维、维护、折旧都要计入，真正有意义的数字仍是「满载成本除以合并请求数」。自建还带来一项不会出现在发票上的收益：代码主权。当代码生成与测试留在本地，专有代码不出企业边界，只有经过批准的规划提示词与受管控的例外请求，才通过企业自控的网关发送给外部模型。这正好打开了那些因安全顾虑而迟迟无法落地 AI 的敏感仓库——往往也是收益最大的地方。据该分析披露，HPE 内部的混合 AI 平台已把 150 多个内部应用的日常负载路由到本地运行的开源权重模型（包括 HPE Private Cloud AI），token 成本下降 30% 至 50%。
| 关键数字 | 含义 |
|---|
| --- | --- |
|---|
| 10–50 倍 | 智能体单任务相对普通提示词的 token 消耗倍数 |
|---|
| 2028 年 | Gartner 预测 AI 编程成本超过开发者平均薪资的年份 |
|---|
| 450 倍 | 同一许可下最重度用户相对最轻用户的消耗差距 |
|---|
| 4.4 倍 | 重度用户从少数扩至半数员工时，月支出的增幅 |
|---|
| 30%–50% | HPE 混合架构下 token 成本的下降区间 |
|---|
谁在烧 token：5% 的重度用户决定账单
数据反复证明，驱动支出的不是许可数量，而是使用强度：消耗最高的 5% 用户贡献了大部分用量，最重度用户在相同许可下的消耗约为最轻用户的 450 倍。如果重度用户从少数派扩展到全体员工的一半，即便人头不变，月度支出也可能上涨约 4.4 倍。这正是必须测量的原因——平均值会把重度用户藏起来。HPE 建议客户同步跟踪两个指标：一是每活跃开发者成本，避免被全体许可的平均数掩盖；二是每合并请求成本，把 AI 支出与真正上线的软件挂钩。做法是先在现有架构上取得两项基线，再让一个完整开发周期跑在自建容量上；若随用量上升，两项指标没有改善，那么维持现有模式反而是更优解。
FAQ：企业最关心的两个成本问题
Q1：按 token 计费与自建算力，哪种更便宜？
A1： 取决于用量形态。低频或波动大的需求适合 API，无需为闲置基础设施占用资本；持续、可预测的高频需求才让自建划算。多数企业最终会走向混合：困难或间歇性任务用前沿模型 API，重复性负载放在自有容量上，由受管控的网关决定哪些数据可以出企业边界。
Q2：如何判断 AI 编程投入是否真的划算？
A2： 不要只看 token 单价或席位费用。把总成本除以通过评审并合并的变更数，得到每个合并请求成本，同时监控缺陷率与返工率；再叠加每活跃开发者成本观察重度用户的影响。两项指标同时向好，才说明消耗正在转化为交付。
对大多数企业而言，真正的分岔口不是用不用 AI 编程，而是用量增长最终呈现为一张更大的可变成本账单，还是更多运行在自有容量上的软件。以配额压制采用速度的公司，会把成本管住，也会把产出管住。
Related Threads - 最新消息
AI 编程成本正被智能体的 10 至 50 倍 token 消耗推高。别再用配额压制用量：改用每个合并请求成本与每活跃开发者成本，配合模型分层与自建推理，衡量真实交付回报。
