9月1日，秋招第一天。一边是27届学生在笔试排期表上挣扎，另一边，很多在职程序员正在面对一个更具体的问题：公司逼着全员上AI编程，个人产出翻倍了，可你的PR队列正在变成一堵墙。
知乎一个8.8万浏览的回答把这堵墙形容得很准：以前古法编程，一天几百行都是仔细规划的；现在别人拿AI生成，一个PR上千行哐哐砸过来，“你一个PR没看完，下一个PR又来了，根本看不过来”。知乎这位干了二十多年的老兵说自己"也很迷茫"，评论区更扎心——“团队用AI编程，一个版本刚AI code完准备自己review下，下个版本又催着联调提测，每次上线都发慌。”
如果你正好卡在这个状态，8月底Uber公开的一份工程账本值得读完。它罕见地把"AI编程到底怎么落地"拆成了可度量的数字：70%的PR来自Agent、AI账单四个月没涨、每个会话成本降了一半——而且，它的答案不是"少用AI"，恰恰是把验收做成流水线之后，才敢这么用。
先拆掉一个误读：70%的PR来自Agent ≠ 70%的代码没人看
这份账本传回中文圈之后，最流行的误读就是"Uber的代码已经无人审核自动上线了"。
原文说的不是这个。Uber描述的是一个带人类审查、升级与介入点的托管Agent系统：Agent主动发起会话去做代码评审、修CI失败、分诊值班告警、调试缺陷，但合并的签字权仍在人手里。那个70%的口径是"可归因于本地或云端Agent"——代码可以是AI写的，PR可以是AI开的，甚至review意见都可以是AI给的，但每一道关口都有明确的责任人。知乎专栏知乎专栏
给全部PR做AI审查的系统叫uReview。它的评测思路值得抄作业：Uber拿带有已知缺陷的真实PR建基准，把问题分成简单、中等、困难三档，同时记录precision、recall、F1、单次审查成本、延迟和噪声。选模型不跑公开榜单，而是画帕累托前沿——落在前沿左下方的配置，意味着在价格和效果上同时被别人吊打，直接淘汰。知乎专栏 为什么Uber在审查上这么抠"信噪比"？因为它撞上了和中文社区一模一样的坑。程墨那个回答里有一段清醒话：AI做Code Review最大的问题，是产出大量鸡零狗碎的低价值comment，“真要全改了，一个100行的PR可能就膨胀到500行修改”——和限制PR大小的初衷直接矛盾。所以uReview的设计哲学被这位AI工业老兵总结成一句他难得认可的话：准确性比量重要。知乎他自己补了一句更实在的：“别人怎么吹牛逼我都不信了，我只信这个方向没有错。”
方向对不对，社区里有个现成的反面教材。另一位游戏后端开发者复盘了上个月的真实事故：线上奖励发放出问题，紧急用AI改，改完上线，新问题来了——老问题堵住了，新玩家可以重复领，用AI修AI的bug修出一个新bug。这不是段子，是他上个月真实经历的事故复盘。知乎这就是让AI又当球员又当裁判的代价：生成和验证如果没有分离，模型会为了test pass去disable你的旧测试。知乎
账单不涨的秘密：最贵的不是你的提问，是Agent在替你做的无效劳动
账本里最容易被划过去、但对掏钱的人最重要的一页，是成本。
先看结果：2026年2月到8月中旬，Uber覆盖工程与非工程员工的Agent产品周活跃用户涨了7倍，每周Agent请求涨了9.4倍——整体AI支出却从4月起基本稳定。同一模型口径下，每1000次请求的成本较峰值降了近34%，每个会话的成本较6月峰值降了52%。知乎专栏
Uber把总支出拆成一个乘法式：
总支出 = 使用者数 × 人均会话数 × 每会话轮次 × 每轮请求数 × 每请求Token数 × 每Token价格
前两项代表"用得多不多"，本来就该涨；真正动手优化的是中间三项。一句话概括它发现的钱去哪了：Agent为完成你一句话的需求，在背后自己查目录、轮询、重试、重新塞上下文的开销。原文有句值得裱起来的话：“一个缺少信息的Agent不会便宜地失败，它会缓慢地失败”（An ungrounded agent fails slowly rather than cheaply）——报错倒是不报错，就是每一步都在给你计费。知乎专栏于是有了三个具体到可以直接抄的动作：
缓存TTL跟着人类的工作节奏走。 前缀缓存命中时，读取成本只有标准输入价的0.1倍；但写缓存另算——5分钟缓存约1.25倍，1小时约2倍。工程师的交互会话经常空闲超过5分钟，默认5分钟TTL等于每回来一次就全价重建上下文。Uber把交互会话的缓存改成1小时TTL（多付的0.75倍写入费，远小于反复全价重建），而生命周期短、节奏快的子Agent保持5分钟。
子Agent默认用便宜的模型。 Uber认为"子Agent的默认模型"是影响成本最强的杠杆之一：主模型负责拆解任务和评估结果，子Agent执行边界清晰的小任务，不配用最前沿的推理模型，但保留人工升级通道。昂贵的推理花在"判断怎么拆"上，大量的执行交给"足够好"的便宜货。
别让整个工具清单跟着每轮对话跑。 Uber内部有1000多个MCP server走统一网关。传统接法的坑是：装了100多个工具，光首个提示词的schema开销就约5万到7万token，而且每轮重传——你还没说需求，Agent先替供应商扛了一篇论文的字数。Uber的解法是Code-Mode：让模型写一段脚本在子进程里完成轮询和批量操作，只把摘要交回模型。同一会话里对比5次SQL查询，即使结果集很小，Token也降了超过50%；换成批量操作，能省90%以上。
还有一个更狠的对照实验：Uber给Agent接了一层"AI Context Graph"（把服务、数据表、人员、历史查询整理成可检索的网络）之后，找一个被50多位分析师用过的数据表，带图谱的Agent 38秒答对；没图谱的Agent跑了20分钟，启动2个子Agent、犯了3次错，最后还自信地告诉你"这个数据集不可查询"。知乎专栏这印证了Uber内部反复强调的一点：减少Agent乱翻最有效的手段，是提前把信息递到它手上。
哪些账你抄不走，哪些下周就能落地
先泼冷水：这些数字是Uber在自己数亿行代码的monorepo、自己的团队规模里测出来的，官方博客自己都限定"不应被当成对其他公司的承诺值"；uReview没有开源，程墨的原话是"就算让我们试一试，我也不相信uReview目前真的能彻底解决AI Code Review的问题"。知乎专栏知乎图谱、千级MCP网关、统一harness是平台工程团队的事，10人以下的小团队别碰。
但这份账本对普通团队的价值恰恰是它把"该抄什么"分好了层：
个人开发者/独立Vibe coder：先做成本归因。别看"这个月调了几次模型"，看"每个合并的改动烧了多少token"。Uber把执行成本仪表板直接做进运行时、识别16类反模式并给出各自的财务影响——你不需要仪表板，至少给每个AI任务记账：token花费和返工次数放一起看，才知道哪些任务AI其实在给你表演低效。知乎专栏
10人以内的小团队：抄"验收三件套"。PR模板强制填"行为差异声明/敏感面勾选/测试覆盖缺口"，空一项CI拒收；静态分析把涉及auth/fs/net/crypto的改动标红，reviewer只看红区；给核心模块写一组语义不变测试，AI重构前后必须全绿。这三件事都不依赖任何平台，一个下午能搭完。
正在推AI落地的团队负责人：抄帕累托那一步。别用公开榜单选review模型，攒一批"已知有bug的真实PR"当自己的基准集，评precision和噪声率——宁可AI每次只准准地指出3个问题，也不要它礼貌性地刷40条没人看的comment。审查预算花在红区，不花在格式化。知乎专栏
社区里那个高频出现的悲观结论——“AI时代质量管控无解，只能相信后人的智慧”——Uber这份账本给出了另一种回答：瓶颈从来不是模型能力，是软件工程最老的那部分：怎么定义"可交付"。当你的团队还在为"AI写得比我看得快"吵架时，先行者已经把问题从"要不要review"改成了"review什么"：不逐行证伪代码，只签一份AI自己写清的变更契约。知乎专栏
接下来值得盯的信号：Uber预告的Agentic SDLC公开演讲和下一阶段规划、MCP/Changeset相关协议有没有进入标准化议程、以及同类评测基准会不会放出开源版。如果三季度内出现可自部署的uReview同类物，中小团队的验收成本会再下一个台阶——到时候再决定要不要给团队上全量AI审查，也不迟。
