92% 工程师都在用 AI 后，Uber 开始给 AI “限额”了

事件核心：发生了什么

Uber 在近期披露的“零增长技术栈”（Zero Growth Stack）战略中，公布了其 AI 基础设施与开发效率的最新平衡方案。这一方案分为两条线：一条是基础设施层，通过 Go 运行时优化、动态垃圾回收控制等手段降低算力开销——其自研的 GOGCTunner 库能根据 cgroup 内存限制和实时对象使用情况动态调整 GOGC 参数，已在 30 个关键服务中回收约 70,000 个 CPU 核心；另一条是 AI 辅助编码层，Uber 围绕 Michelangelo AI 模型网关、MCP Gateway 上下文注入、Minion 和 Shepherd 后台 Agent、uReview 与 Code Inbox 审查工具构建了完整开发链路。

目前公开信息显示，Uber 内部已有 92% 的工程师每月使用 AI Agent，31% 的新代码由 AI 编写，Autocover 工具每月生成超过 5,000 个单元测试。但 AI 的快速采用也带来显著财务压力：自 2024 年以来，AI 相关成本增长六倍，基于 Token 的计费模式导致预算快速耗尽，单个开发者月度成本在 2026 年初达到 2,000 美元。为此，Uber 已转向成本治理模式，将每位开发者的 AI 使用额度限制在 1,500 美元以内，并开始引入“净代码质量比”（对比 AI 代码与人工代码上线后热修复频率）及“每个功能的计算效率”等细粒度指标，评估 AI 生成代码的实际投入产出。

为什么重要

Uber 的案例揭示了一个行业正在集体面对的问题：AI 编程工具在效率上的收益是真实的，但算力和 Token 开销同样是真实的。此前许多企业推行“无限制 AI 接入”以抢占效率红利，Uber 的转向表明，当 AI 编码渗透率进入高位后，成本治理会从财务问题演变为工程架构问题——企业需要重新设计资源分配机制、代码审查标准和容量规划方式。

更深层的信号在于，Uber 用动态运行时优化替代静态配置的思路，提供了一条区别于“堆算力”的路径：不是无限扩容来满足 AI 负载，而是通过系统性地压缩非必要开销来容纳 AI 带来的额外计算需求。这种方法论对于关注 AI 基础设施成本的平台型公司具有直接参考价值。

对用户/开发者/创作者的影响

对开发者而言，Uber 设限 1,500 美元的信号意味着 AI 辅助编码的“无限供给”阶段正在结束。企业内部可能会从鼓励多写 AI 代码，转向要求开发者判断“哪些代码值得交给 AI”，并逐步引入针对冗余测试、低质量 AI 产出的审查标准。使用各厂商 AI 编程工具的团队，需要建立自己的成本核算与质量追踪机制。

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。

对依赖 API 调用的大模型应用开发者来说，Uber 的 GOGCTunner 和运行时调优思路说明：在模型能力和调用价格之外，工程侧的算力利用率改进仍有巨大空间。普通用户层面，Uber 将 AI 成本与功能交付挂钩的尝试，可能会让产品团队更倾向于把算力投入到用户可感知的功能上，而不是无差别地嵌入 AI 能力。

值得关注的后续

首先，Uber 是否会开源 GOGCTunner 或分享更多动态资源调优的工程经验——如果开源，将为 Go 生态的高内存服务治理带来直接可用的工具。其次，“净代码质量比”等评估指标能否被更多大厂采纳，形成新的 AI 编程 ROI 衡量标准。最后，Uber 的成本上限政策是否会传导至其 AI 供应商（如模型 API 厂商），推动更细粒度的计费方式或缓存方案出现，是值得跟踪的产业信号。

来源：InfoQ CN