正在加载，请稍候
Uber 在 92% 工程师使用 AI 编程后按下刹车：每人每月限额 $1,500，因为 AI 成本已六倍增长。本文拆解 AIcoding 商业化的隐藏账单，结合 WAIC 2026 讨论与 Codex 子代理编排实践，给出一套企业 ROI 计算框架。
InfoQ 在 2026 年 8 月 1 日的报道中披露了 Uber 的内部数据。Uber 的 AI 开发生态分四层架构：平台层用 Michelangelo AI 做模型网关，上下文层通过 MCP Gateway 注入内部源代码，专用层部署 Minion 和 Shepherd 等后台 Agent，审查层靠 uReview 和 Code Inbox 把关。92% 的工程师每月使用这些 Agent，Autocover 每月自动生成超过 5,000 个单元测试。
但真正让 Uber 按下刹车的是钱。自 2024 年以来，AI 相关成本增长了六倍。基于 Token 的计费模式下，预算被快速耗尽——到 2026 年初，单个开发者的月度 AI 开销已经触及 $2,000。Uber 没有继续加预算，而是把每人限额砍到 $1,500，同时开始追问一个更本质的问题：AI 生成的代码到底值不值这个价？
Uber 提出的衡量框架是「净代码质量比」——比较 AI 编写代码与人工编写代码在上线后出现热修复的频率。另一个指标是「每个功能的计算效率」，用来评估 Autocover 生成的大量冗余测试是否在长期拖累基础设施。换句话说，Uber 不再问「AI 写了多少代码」，而是问「AI 写的代码上线后修了多少次」。
大多数团队评估 AIcoding 成本时只看 Token 消耗，但实际账单远比这复杂。WAIC 2026 上，优刻得 CTO 王凯和焱融科技 CTO 张文涛在 InfoQ 的对话中拆解了这笔账的结构。
一次普通对话只调用一次模型。但一次 Agent 任务，背后是目标理解 → 任务拆解 → 信息检索 → 工具调用 → 上下文读取 → 记忆存储 → 结果验证的完整链条。任何一个环节偏差，Agent 就重新规划、重新调用，甚至从头执行。模型单价在降，但调用总量和失败重试的成本在涨。
张文涛指出企业最容易漏算的三笔钱：
| 成本类别 | 具体表现 | 为什么容易被忽略 |
|---|---|---|
| 人的时间 | 代码审查、安全检查、结果验收 | "AI 写完了"不等于"可以上线" |
| 结果质量 | AI 生成代码的长期可维护性 | 初期能跑通，半年后没人敢动 |
| 后续维护 | 上下文膨胀、记忆堆积、KV Cache 开销 | 同一任务越跑越贵 |
王凯的总结更直接：「很多时候我们说 AI 贵，贵在我们为了一个自己没有定义清楚的问题，让 AI 不断地尝试，给出无数个答案。」这回到了一个工程管理的本质问题：如果团队没有先定义好「什么算任务成功」，AI 再多尝试也只是在燃烧预算。
成本压力下，AIcoding 社区自己摸出了一套解法。Codex 用户总结了「Sol 当包工头、Luna Max 当工人」的子代理编排模式，2026 年 8 月 2 日在 AI HOT 社区引发热议。类似思路在 Claude Code 的成本压缩实战中也有验证——图片化压缩和调度策略能将月账单压到原来的一半。
具体做法：在 ~/.codex/agents/ 下创建 luna-worker.toml 配置文件，将子代理模型设为 gpt-5.6-luna，reasoning effort 调至 max。Sol（OpenAI 最强也最贵的模型）只负责拆解任务、做架构决策和代码审查；具体的实现、改 bug、跑测试、重构全部委托给 Luna Max。
效果差距有多大？DeepSWE 基准测试显示，gpt-5.6-luna max 的分数与 Sol Medium 咬得很近，但成本差了一个数量级。这相当于用一个 Sol 的钱同时驱动多个 Luna Max 工人。
这套模式的核心思想不是省 Token，而是区分「决策型工作」和「执行型工作」——把昂贵的推理资源用在刀刃上，把标准化体力活交给便宜的模型。对企业落地 AIcoding 而言，这种任务分级思路比单纯限额更可持续。
结合 Uber 的实践和 WAIC 的讨论，企业在全面推广 AIcoding 之前，至少需要回答以下四个问题。以下模板可以直接在团队评审会上使用。如果想知道更多降本路径，可以参考我们之前整理的AIcoding 商业化 2026 三条降本路径。
第一步：定义 AI 替代的具体任务
第二步：算清全口径成本
第三步：设定可比基线
第四步：选择落地路径
优刻得 CTO 王凯在 WAIC 上的提醒值得反复看：「传统企业现有的生产流程，是长期经验、制度和组织协作的结果。如果突然将整个流程交给 Agent，相当于一次性击穿原有的信息化和管理体系。」
不是所有场景都适合引入 AIcoding。以下三种反面模式来自我们实际交付中的反复验证。关于 AIcoding 工具选型本身也是成本控制的一环，Claude Code 多智能体 vs GLM-5.2 开源方案的对比也许能帮你少踩一些坑。
场景一：需求不明确的探索性项目。当客户自己也不知道要什么时，AI 生成的代码越多，返工量越大。Agent 会根据模糊指令不断尝试，每次尝试都烧 Token，但每次输出的代码方向都可能不一致。正确做法是先由人完成需求收敛和架构设计，再让 AI 进入编码阶段。
场景二：强合规行业的核心系统。金融交易引擎、医疗数据处理、工业控制系统——这些场景对代码的可解释性、审计追踪和安全性要求极高。AI 生成代码的「黑箱」特性会显著增加合规审查成本。一位金融科技客户的 CTO 反馈：引入 AIcoding 后，代码产出量确实翻了一倍，但安全审查团队的工时翻了三倍。
场景三：老旧代码库的修补式开发。如果代码库本身缺乏测试覆盖、文档缺失、架构耦合度高，AI 很难理解上下文，生成的代码容易引入隐性 bug。这种场景下，先做代码库治理和测试体系建设，再引入 AIcoding，ROI 反而更高。
贵不贵取决于有没有定义清楚「任务」。Token 单价在持续下降，但如果你让 AI 为一个模糊需求反复生成几十个版本再人工挑选，任何价格都是贵的。Uber 的经验是：先定义净代码质量比，再决定为该任务付多少钱。
Uber 的做法不是禁止使用，而是从「无限制模式」转向「成本治理模式」。$1,500/月对于常规开发任务仍然充裕，真正的约束在于促使工程师思考：这个任务是否真的需要 AI？用 Sol 还是用 Luna Max？——这恰好是 Codex 子代理编排模式的价值所在。
有必要，但门槛低很多。小团队可以先从一个单一任务切入——比如用 AI 生成单元测试——然后对比 AI 引入前后测试覆盖率的变化和工程师时间投入的变化。如果一个月内数字没改善，就说明这个场景不适合或者用法不对。
从 Uber 的数据看，31% 新代码由 AI 生成已经是很高的比例，但仍有 69% 的代码、全部的架构决策和代码审查靠人完成。WAIC 2026 上多位嘉宾的共识是：AIcoding 替代的是「可被明确评价的编码工作」，而非「需要判断力和上下文理解的工程决策」。
我们在为客户落地 AIcoding 工作流的过程中，反复验证了一个规律：AIcoding 商业化的核心不是选哪个模型、买多少 Token，而是团队有没有能力把「写代码」这件事拆成「能交给 AI 做的」和「必须人做的」两部分。拆得越清楚，成本越可控；拆得越模糊，账单越吓人。关于「自研还是外包」这个平行决策，AI 时代下的三个决策框架可能对你有帮助。
有 AIcoding 落地需求或想评估当前团队 ROI，可以查看我们的项目案例或直接联系我们。