Uber 给 AI 工具设限后,技术团队该醒醒了

今天看到 Uber 给 AI 编程工具设限，我脑子里第一句话不是“连 Uber 都嫌贵了”。

我想到的是公司里很常见的一个画面：某个团队突然开始猛推 AI 编程，群里每天都有人晒 Claude Code、Cursor、Codex 帮自己改了多少文件，排行榜里谁的 token 用得多，谁看起来就更像先进生产力。

一开始挺爽。

以前半天才能整理完的接口迁移，现在 Agent 跑一会儿就给出 diff。以前写测试要硬着头皮补边界，现在 prompt 一扔，它能先铺一版。以前改一个老模块，要先读半小时上下文，现在它能帮你把调用链拎出来。

问题是，爽归爽，账单也是真的。

TechCrunch 和 Los Angeles Times 都报道了这件事：Uber 给 Claude Code、Cursor 这类 agentic coding 工具设了限制，每个员工、每个工具每月 1500 美元 token 预算；员工有看板能看自己的用量，超额要申请。更早之前，Uber CTO 说公司 4 个月就用完了全年 AI 预算。

这事最有意思的地方不是 1500 美元多不多。

而是一个大公司开始承认：AI 编程工具进入日常以后，不能只鼓励大家“尽量多用”，还得问一句，它到底交付了什么。

工程团队很容易迷信一个东西：可量化指标。

以前是提交次数、代码行数、故事点、PR 数量。现在轮到 token 了。

谁用得多，谁看起来就更积极。哪个组消耗高，哪个组好像就在拥抱 AI。甚至还有一种奇怪的气氛：你不用 AI，就是落后；你用得少，就是效率还没打开。

但 token 用量和真实产出之间，隔着很厚一层。

一个 Agent 可能花很多 token 帮你探索方案，最后没有一行代码能合并。它可能连续重试，把测试改绿了，却顺手把断言改松。它也可能帮你写出一大段看起来完整的实现，review 时才发现业务边界没理解对。

这些都算使用量。

但不一定算价值。

我不是说 AI 编程没用。恰恰相反，我现在很多工作都会用它，尤其是读陌生代码、整理变更影响、生成测试骨架、写迁移脚本第一版。

可越是好用，越不能把使用量当成绩。

因为团队一旦把“多用 AI”变成目标，大家就会自然优化这个目标。以前 KPI 看代码行数，有人就会写更多行。现在看 token，有人就会让 Agent 干更多事，哪怕这些事最后只是把 review 成本挪给了同事。

AI 编程工具的费用，经常不是按“一个需求”来的。

它是按模型调用、上下文长度、多轮对话、工具执行、重试次数来的。一个任务边界不清楚，Agent 就会不断绕圈。

比如你给它一句：“帮我优化一下这个模块。”

这句话在人类同事那里都很危险，给 Agent 更危险。它不知道优化的是性能、可读性、架构边界，还是只是把 lint 清一下。它可能先读一堆文件，再提出方案，再改一版，再跑测试，再发现测试环境缺依赖，再继续修。

这一圈下来，钱花了，时间也花了，最后你还得问：这个 PR 到底解决了哪个问题？

所以我现在更愿意把 AI 任务切小。

不是“优化模块”，而是“读这三个文件，列出缓存穿透风险，不要改代码”。

不是“帮我重构支付流程”，而是“基于当前测试，补 5 个失败样本，先只生成测试用例”。

不是“把这个需求做完”，而是“根据这个 issue，找出最小改动路径，列出受影响接口和需要跑的测试”。

任务越清楚，AI 越像工具。

任务越模糊，AI 越像一个很勤快但可能乱花钱的实习生。

Uber 这种公司烧穿预算，还能立刻补上看板、限额、审批流程。

小团队不行。

你可能就是十来个人，几个开发共用一堆 AI 账号。大家一开始觉得每月几百美元没什么，和人力比起来太便宜了。可真放开以后，Agent 任务、代码索引、长上下文、图片、日志分析、自动修复全接上，账单会涨得很快。

更麻烦的是，小团队通常没有专门的人算这笔账。

产品只看到功能快了。开发只感觉写代码轻松了。老板只听到“AI 能提效”。月底账单来了，大家才开始补一句：这东西到底省了谁的时间？

我建议小团队别一上来搞大而全。

先挑三类任务。

第一类，重复且低风险。比如生成测试骨架、整理接口文档、补充类型定义、做代码说明。错了也容易发现，回滚成本低。

第二类，有明确验收。比如某个 lint 规则迁移、某批老 API 替换、某个页面的埋点字段核对。做完能跑检查，不靠感觉判断。

第三类，能减少等待。比如值班时先整理日志、把错误样本分组、把最近变更和异常时间线对齐。它不直接改生产，但能让人更快进入状态。

不要先让它碰“开放式大任务”。

开放式大任务最容易烧 token，也最容易产出一堆需要人收拾的半成品。

我觉得 Uber 这次的信号不是“少用 AI”。

更像是提醒所有团队：AI 工具预算应该像云资源、CI 资源、日志存储一样，进入工程治理。

最少要有四个东西。

第一，用量看板。谁用、哪个工具用、什么任务用、峰值在哪里，要能看见。没有看板，就只能靠月底账单复盘。

第二，任务标签。AI 花在 bug 修复、测试生成、需求开发、文档整理、线上排障上的比例应该分开看。否则所有 token 混在一起，根本不知道钱花在哪。

第三，产出对照。不是精确到每一分钱都算 ROI，但至少要知道这些 AI 任务有没有减少返工、缩短 lead time、提高测试覆盖、降低值班排查时间。

第四，超额审批。不是为了卡大家，而是为了让高成本任务先停下来想一想：是不是上下文太大？是不是模型选贵了？是不是该拆任务？是不是该换成本地模型或低成本模型先筛一层？

这些东西听起来不酷。

但工程里真正救命的，往往就是这些不酷的表和开关。

现在很多团队对 AI 的态度有点矛盾。

一边说要提效，一边又不好意思承认自己还没量清楚效果。

一边让大家多用，一边又没有定义哪些任务适合用，哪些任务必须人工 review，哪些任务不能让 Agent 自己跑。

最后就容易变成面子工程。

周会上说本周 AI 使用量增长了多少，PR 描述里写“由 AI 辅助完成”，内部分享里展示 prompt 技巧。但线上 bug、需求延期、review 堆积、测试缺口，并没有明显改善。

如果是这样，那就不是 AI 编程的问题。

是团队管理问题。

我更愿意看到的汇报是这样：

这个月 AI 帮我们把 30 个老接口补了测试，回归时间从 2 天降到半天。

这个月 AI 帮值班同学整理了 18 次日志时间线，平均定位时间少了 20 分钟。

这个月 AI 生成的代码有 12% 在 review 中被整体退回，主要原因是业务边界理解错，下个月我们收窄任务模板。

这才是工程团队该看的东西。

不是“我们用了多少 AI”，而是“AI 帮我们把哪段流程变稳了”。

Uber 给 AI 编程工具设限，不代表 AI 编程不行。

我反而觉得这说明它真的进入日常了。

一个工具只有被大量使用，才会开始暴露预算、权限、审批、质量和责任问题。没人用的时候，所有讨论都停在 demo。

但进入日常以后，大家就不能继续用 demo 时代的眼光看它。

AI 编程不是免费的聪明同事。它是一个会消耗预算、会放大流程问题、会把模糊任务变成昂贵试错的工程工具。

我的判断很简单：

该用，甚至应该认真用。

但别再用“用得多”证明先进。

从今天开始，把 AI 工具当成生产资源管理：设预算、分任务、留日志、看产出、做复盘。能带来交付质量和真实速度的地方，多投。只能制造热闹和返工的地方，赶紧收。

技术团队最怕的不是 AI 工具太贵。

最怕的是钱花出去了，大家只记得 token 很多，却没人说得清用户到底多拿到了什么。