70% 代码是 AI 写的，Uber 的账没涨，你的呢
Hello，我是飞飞。
上个月我写过一篇，讲 Uber 四个月烧光了 2026 一整年的 AI 编码预算，CTO 一次两小时个人 demo 就烧掉 1200 美元 token，Bloomberg 说公司给工具设了每人每月 1500 美元的上限，超了要审批。我当时的结论是：那杆秤，Uber 设在了它的财务系统里，我设在自己脑子里。
今天这条新闻，结结实实打了我一下。
Uber 自己发了一篇工程博客，标题叫《Running a Software Factory Efficiently at Uber Scale》，8 月底发的。里面说：现在全公司超过 70% 的内部代码修改（pull request），已经由本地或云端的 AI agent 完成；工程师建了 3600 多个 agent skill，每天执行三万多回。从 2 月到 8 月，每周的 agent 请求量涨了 9.4 倍，可总 AI 支出自 4 月起基本稳住。它还把每 1000 次请求的成本较峰值压低了约 34%，单次会话成本较 6 月峰值降了 52%。
同一个公司，两个月。上个月还在为花钱太多设上限，这个月变成怎么用都算得平。变的不只是那几个数字，是它算账的方式。
上次它烧光了预算
先把 6 月那笔账说清。Uber 去年底给大约 5000 个工程师铺开了 Claude Code 和 Cursor，还搞了个内部排行榜，按谁用得多给团队排名。采用率冲过 84%，结果到 4 月，全年的钱就花完了。CTO 亲口说，他一次两小时的演示，就烧掉 1200 美元的 token。后来 Bloomberg 报道，公司给这些 agentic 工具设了每人每月 1500 美元的上限，超了要审批。
我写那篇的时候，COO 在播客里说了句大实话：这么多 token 砸下去，并没有变成对乘客和司机更有用的东西。说实话，我把它当成了一个注脚：AI 这东西能让人效率翻倍，也能让账单翻倍，看它落在谁手里。
这次它让 AI 写七成
先纠一个容易误读的地方。Uber 说 70%，用的是「归因于」这个词：这些 pull request 由本地或云端 agent 产出，但博客里同时强调，进度里带人工评审和升级路径。托管 agent 干的那些活，代码评审、CI 自修复、端到端 PR、on-call 排障、debug，都有人盯着、有人兜底。所以不是 70% 的代码无人审自动合上，是 agent 驱动、人还握着质量那关。这么一比反而更可信。Uber 说的是「AI 把活干到八九成，人把最后的定夺和兜底握住」，至于「AI 替了人」，它没这么讲。
我也得诚实：这些数字都是 Uber 自己报的，没有第三方审计。那句「成本稳住了」，是用「固定一个模型做对照」算出来的，总账直接相减得不出这个数。所以别当铁证，当成一个大厂在真实规模下趟出来的路径。
成本被拆成六项
真正让我坐起来的不是那个 70%。是那套成本方程。
Uber 把一次 agent 会话的总支出，拆成六项相乘：用户数，乘以每人会话数，乘以每会话轮次，乘以每轮请求数，乘以每请求 token 数，乘以每 token 单价。
前两项是采用度，它巴不得越涨越好。最后一项是模型定价，那是市场说了算。真正能下手优化的，是中间那三项：轮次、请求、token。而这中间三项，说的其实是同一件事，就是 agent 为了帮你干活，自己多烧掉的那些东西。
最烧钱的是哪一项
它下手的每一处，都打在这中间三项上。
子 agent 干的活，默认派给更弱更便宜的模型，主模型只负责拆解和评估，省下的是「轮次」里最贵的那一档。交互会话的 prompt cache，从 5 分钟改成 1 小时：工程师经常挂机超过 5 分钟，缓存一失效，前情就得重新按全价再烧一遍。一百多个 MCP 工具，以前每次开一个会话就把几万 token 的工具清单全塞进上下文，它改成让模型走 shell 调 CLI、按需搜索加载工具，把「token」这一项砍下一大块。还有 code-mode 批处理，把轮询放进了子进程，只把摘要回给模型。
它甚至给 agent 建了一张上下文图，24M 节点、80M 边，跨 30 多个内部系统，让 agent 少瞎找。因为在一个几亿行的仓库里，agent 大半时间都在找路，写码只占一小截。
看明白了吗。它省的那些钱，几乎处处都打在「agent 替自己多干的活」上，跟「用更便宜的模型」关系不大。替自己多看几遍前情、替自己多绕几个弯、替自己把用不上的工具全背在背上。
这让我想起我那套流水线。我心疼的是每次调 Opus 的那一下，却从没数过另一笔。它把一个用不上的 skill 描述带进来、把三小时前的旧上下文重新传一遍，这些加起来到底是多少钱。
我自己的账该补两笔
看到这里，我心里咯噔一下，因为我的省，从来只在一处使劲。
我的做法是「过秤」：让 agent 动正经活之前，先掂量这活配不配用最贵的 Opus，还是切个便宜模型对付。批量改文档、跑脚本这种杂活，我手动降档。我的尺子是「这活错一点代价 × 一天跑几次 × 单价」。说白了，我一直在拧的，是那六项里最末端那一项，单价，外加一点次数。中间的轮次、每轮 token，agent 替自己多烧的，我压根没动过，甚至连想都没想过。
可在我的流水线上，这笔钱是真存在的，而且不止一笔。
我光写文章这条流水线就挂着一堆 skill，每个背后调哪档模型我都得盯着。有一回没盯住，一个 Haiku 就能干的活悄悄爬到了贵档上，那个月额度漏得莫名其妙，我过了好一阵才反应回来。还有一次贪快，让同一个会话连撑了六个钟头，它到后面开始重复生成我早写过的函数，还顺手把旧逻辑改错了。这两件事，靠「切便宜模型」那条老路根本管不着，因为它们就是「轮次」和「token」这两项在偷偷涨。
我自己也干过几乎一样的事。前阵子我批量改二十个 frontmatter 字段，手一滑差点点成 Opus，反应过来赶紧切回便宜档。那一瞬间我明白，我管成本靠的全是自己的注意力，一秒不看就漏。Uber 不是这样，它把「该用哪档模型」写进了默认配置，让工程师不用想就落在对的档上。
更早我还记过一笔：我那套自动化的后台任务，心跳、标题、摘要这些，占了隐性消耗的三成；skill 目录越堆越胖，三十个 skill 的描述就吃掉五六千 token。这些都不在「我用哪档模型」的账上，可每一笔都在 Uber 那六个乘数里。
所以这次的结论，对我不是「Uber 好牛」。我把账算窄了。我一直以为 AI 的成本是省出来的，靠的是克制，少用、用便宜。Uber 告诉我是压出来的，靠的是把 agent 替自己烧的那部分，一项一项按下去。
回到 6 月那句话。我那时说，那杆秤，Uber 设在了它的财务系统里，我设在自己脑子里。现在看，Uber 那杆秤从没在「省」这个字上发力，它在「算」。它把自己那六项摆出来，一项一项往下砍。我这杆秤，还停在「哪个模型不值得用」上，压根没算过「agent 替自己多烧的」那两笔，是可以压的。
这周我打算挑流水线上最高频的一个 skill，照它那几个杠杆试一遍。把纯机械的子任务切给便宜模型，把喂进上下文的前情压一压，把用不上的工具从会话里拿出去，盯着这个月额度看到底降多少。
你呢。你手里的 AI 账，是跟我一样盯着「用哪档最划算」，还是已经算到「它替自己多干了多少」那一层了？评论区聊聊，我想看看是不是只有我一个人，占了两个月便宜，一直没往那层想过。