正在加载，请稍候
Uber 用智能体接管 70% 代码 PR、AI 账单零增长；Meta 换来的却是安全事故增加 40%、工程师救火多 70%。同一波模型，为什么结果差这么多？答案在接入方式与工程治理。
2026 年 8 月，两份 AI 编程账本先后公开。Uber 说全公司 70% 的代码 PR 已由智能体接管，调用量半年涨近 10 倍，总 AI 账单却一分没涨，单次会话成本降了 52%。Meta 那边则是另一个数字：安全事故增加 40%，工程师救火时间多 70%。同一个市场、同一波模型，结果差到像两家公司活在两个世界。差别不在模型，在接入方式。
Uber 的技术长文讲的是怎么把软件工程变成一条受控流水线：审代码、修挂掉的 CI、分诊报警全部交给专职智能体，人退到"抽查质检"的位置，每天跑 3 万多次流水线任务。最狠的是账本拆法——用量可以疯涨，零价值的废 token 必须抹掉。
Meta 的"OT 项目"走的是另一条路：用智能体直接替代员工。按路透社看到的内部规划，最激进方案要把部分团队砍掉 60% 人力，公司员工总数预计减少 25%。第一轮裁员 5 月 20 日落地，裁了约 10% 的人。结果代码变更量同比暴涨 220%，真正转化为新功能、触达用户的变更只增了 36%——大部分代码是噪音。更糟的是智能体执行了"人类几乎不可能实施的大规模破坏性操作"，重大事故同比增加 40%，留下的工程师救火时间多了 70%，内部士气从 74% 掉到 55%。扎克伯格 7 月终于松口：至少过去四个月，智能体技术轨迹没有像预期那样加速。这类事故有多容易被低估，可以参考我们站内关于部署自主智能体前必过的三道安全闸门的拆解。
两份数据放在一起看，结论很直白：AI 编程的产能红利真实存在，但它不是自动兑现的。Uber 把智能体当成需要治理的流水线，Meta 把智能体当成更快的人，两种心智带来两种结果。
小红书 AI Coding 总架构师郑鑫祺在 AICon 上的演讲也指向同一件事。他观察到一个普遍现象：AI 大幅提高了代码生成速度，需求从提出到上线的周期却没有同步缩短，研发人员也没有因此变得更轻松。AI 生成的代码可能不符合设计规范，界面看似正常、进生产就暴露安全问题，代码能跑但不满足仓库和工程体系要求。省下来的编码时间，最后又消耗在检查、提测、修复、反复沟通甚至推翻重做上。
他把企业级 AI Coding 的问题归成三类：AI 不了解企业资产，生成结果不符合研发与设计规范；用户记忆、业务知识与任务上下文散在不同平台，形不成完整理解；需求到交付的链路没有贯通，原子化 Skill 和工具相互冲突，难以稳定协作。他的方案是做一个打通需求共创、设计、编码与交付的平台，让上下文沿着整条链路流动，而不是把 AI 塞进研发流程的某个格子。
这条观察和我们自己交付 AI 项目时看到的一致。代码生成只是研发链路的一小段，前面的需求对齐、中间的企业规范、后面的审查与上线，哪一个环节断掉，编码省下的时间都会被加倍还回去。蓝曜炬辉做 AI 应用开发时，最常被客户问的不是"模型能不能写代码"，而是"写出来的东西怎么进我们的仓库、过我们的规范、不出安全事故"。
Uber 的账本里没有魔法，只有五个可对照执行的治理点。我把它们和 Meta 的反面列在一起看：
| 治理点 | Uber 的做法 | Meta 的反面 |
|---|---|---|
| 模型路由 | 规划用顶级模型，搬砖子任务切轻量模型 | 所有环节都上最强能力，成本与失控同步放大 |
| 上下文缓存 | 缓存从 5 分钟改 1 小时，40 万 token 强制摘要压缩 | 每个会话重新灌全量历史，token 成倍浪费 |
| 工具接入 | 1000 多个内部工具走网关，按需搜索挂载 | 开局就灌入海量工具定义，上下文被说明书占满 |
| 交互模式 | SQL 与批处理交给模型自己写脚本跑，只交回结果 | 一问一答式轮询，无效 ping-pong 消耗大量 token |
| 知识底座 | 2400 万节点知识图谱，38 秒定位（原来翻代码 20 分钟） | 智能体没有企业地图，盲搜乱撞 |
Meta 的失败还多了一层组织因素：AI 生成代码 + AI 审查代码，同时信任与安全团队因抽调流失约一半人。5 月 30 日 Instagram 的零认证密码重置事故，直接诱因就是这条链上没有人兜底。智能体能力分布极不均衡，让它在不该独立的位置上独立，代价比它省下的编码时间高一个数量级。审查环节怎么对待大段 AI 输出，AI 提交 1721 行 diff 后审查者为什么直接关了 PR那篇文章给了很具体的现场判断。
2400 万节点知识图谱不是谁都能建的，但 Uber 的治理思路可以降级复制。我们给客户做改造时，建议的顺序是这样的：
反例也值得写出来：别先裁人，别先把智能体放进生产链路的审核环节。Meta 用一年时间证明了"先替代、后治理"的路径会反噬——事故、救火、士气三条线同时恶化，最后还得取消第二轮裁员。我们建议先拿一个 2 到 4 周的小模块试点，把上面三件事做扎实，再谈规模。
2026 年的现实是：模型能力还在涨，但企业之间的差距已经不在模型本身。把 AI 当"更快的人"，会得到 Meta 的 40%；把 AI 当"需要治理的流水线"，才能拿到 Uber 的 70%。对绝大多数团队来说，真正稀缺的不是更强的编码能力，而是把编码能力接进既有工程体系的控制手段——成本、上下文、工具、知识、组织边界，哪一个缺位，产能红利就会从缺口漏掉。投入产出账怎么算，我们之前写过一篇AIcoding 商业化的投入产出拆解，可以作为配套参考。
如果你正在评估团队的 AI 编程改造，别从换工具开始，先从链路审计开始。把当前工程链路里的缓存策略、模型调用、工具接入三件事整理出来，交给蓝曜炬辉的工程师做一次接入评估——我们基于你的真实代码库给出改造顺序，而不是先卖一堆概念。评估入口在官网 www.lanyaoai.com 的联系页。
能，但只在链路完整时。Uber 用 70% 的 PR 接管理证了编码侧提速可行；小红书 Muse 的实践则说明，需求对齐、规范、审查这些链路断点会重新吃掉编码省下的时间。交付加速是系统工程的结果，不是代码生成速度的结果。
五个杠杆：规划与执行分用不同档次的模型、上下文缓存从 5 分钟延长到 1 小时并强制摘要压缩、1000 多个内部工具走网关按需挂载、批处理交给模型自己跑脚本省掉轮询、用知识图谱减少盲搜。单次会话成本因此降了 52%，总量涨了近 10 倍但总账单未涨。
代码量暴涨但有效变更只增 36%，事故增 40%、救火多 70%、士气跌到 55%。根因是先把智能体当人力替代品、先裁人后治理，且让 AI 生成代码和 AI 审查代码同链运转而安全团队流失一半，没有人兜底。扎克伯格最终承认智能体技术轨迹没有按预期加速。
先做一个 2 到 4 周的小模块试点，依次做三件事：缓存与摘要、模型路由、工具网关。试点期间用人盯住审查环节，等成本与质量指标稳定后再扩大范围。不要一上来就动组织架构。
短期不会，而且激进替代的代价已经被 Meta 量化。更现实的走向是角色重构：人从实现转向判断、监督与品味，智能体承担执行。工程师的核心价值从"写代码"变成"定义什么值得写、什么能上线"。