每天几千个 PR 被提交到仓库里。其中越来越多的代码是 AI 写的。谁在看？
阿里的向邦宇在 QCon 2025 上海站的分享里，把 Vibe Coding 工具在阿里内部的真实使用现状摊开了讲——高频用户每天提交 560 行代码，TOP 10 用户吃掉了 80% 的 Token，调试时间反而增加了 30%-50%。这些数字比任何产品宣传都诚实。
我看完这篇分享后，想聊的不是 Vibe Coding 有多好用，而是它背后一个被忽略的结构性问题：当代码产出速度超过人类审查能力时，工程质量的底线在哪？
Vibe Coding 的四种形态与一个共同短板
向邦宇把当前 Vibe Coding 工具分成四类：Native IDE（Cursor、Trae、Qoder）、IDE 插件（Aone Copilot）、Web Agent（异步容器执行）、CLI 工具（Claude Code）。
分类很清晰，但他们有个共同盲区——这四类工具都在优化"生成"，没有一个在优化"审查"。
Cursor 帮你写代码，Claude Code 帮你改代码，Web Agent 帮你跑任务。但代码写完之后的 Code Review？还是那个老流程：提 PR，等人看，人来批。
问题是，当 AI 一天能写出过去一周的代码量，Review 的人还是那几个。产出增长了 N 倍，审查能力没变。这个剪刀差会越来越大。
AI 自洽问题：自己出题自己改卷
向邦宇提到一个被低估的问题：AI 的自洽性。
让 AI 同时写代码和单元测试，测试通过率 100%，但逻辑是错的。AI 在用自己的逻辑验证自己的逻辑，学生自己出题自己改卷，当然不会挂科。
小团队还好办，人来 Review 就行。但放大到阿里那种体量，每天成千上万行 AI 生成的代码，谁来当外部裁判？
斯坦福的研究数据：AI 生成代码中注入类漏洞占比 45%。这些代码正在进入生产环境。
每天几千个 PR，Code Review 怎么做？
Linux 内核、Kubernetes、大型 monorepo——这些项目早就面对过海量 PR 的审查问题。它们的机制值得拆解：
分层审查，不做全量人审。Linux 内核用 maintainer 分层制度，每个子系统有自己的维护者，PR 先过子系统 maintainer，再到上层。不是所有代码都让 Linus 看。这种树形结构天然适合 AI 增强——底层筛选交给机器，人只处理高风险变更。
自动化守门员。CI/CD 是第一道防线，lint、单测、集成测试、安全扫描，能过滤掉大部分低级错误。但 AI 的 bug 往往不是低级错误——逻辑层面"看起来对但实际上错"，传统 CI 抓不住。
对抗性审查。用另一个 AI 来审查 AI 的代码。关键在于：审查 Agent 和生成 Agent 不能共享上下文。写代码的知道"我想做什么"，审代码的只看"代码做了什么"。两个视角碰撞，才能撕开自洽的逻辑漏洞。
变更影响分析。向邦宇提到一个真实需求：一次发布是否会引发其他系统的故障。过去人做不到逐行审查跨系统影响，Agent 可以。但前提是 Agent 得理解系统拓扑，不只是代码本身。Repo Wiki 和 Deep Wiki 开始流行，就是在给 AI 建系统级的认知地图。
模板化是捷径，也是天花板
把成功完成的垂直任务抽象成模板，用户选模板后任务完成率提升到 95%。数字好看，但有天花板。
模板化解决的是已知问题的重复执行。JDK 升级、NPM 包升级、SDK 版本迁移——模式固定，边界清晰，交给工具没问题。
但软件工程中真正值钱的工作——架构决策、系统设计、新场景探索——没法模板化。工具只在模板化场景下好用，天花板就是一个高级脚手架。
Manus 1.5 提出"Agent 即工具"的概念，把深度调研、代码审查这类子任务封装成可调用的 Agent。这比模板灵活，但也带来了新问题：Agent 之间的协调成本。当一个主 Agent 调用五六个子 Agent，每个子 Agent 消耗百万级 Token，总成本会指数级上升。
国产模型替代的真实代价
文章里提到阿里已经把所有国外模型替换为国产模型。成本策略可以理解，但向邦宇也坦言了四个问题：死循环、格式遵循差、指令遗忘、缺乏全局规划。
四个问题指向同一件事：国产模型在 Agent 场景下的可靠性还不够。
对话场景，模型输出一次就结束。Agent 场景不一样，模型要连续输出几十轮，每一轮都得格式一致、指令遵从、记住上下文。对"纪律性"要求极高。阿里用主备切换、死循环检测、格式修复来弥补，但说白了是在用工程补丁填模型能力的坑。
我的判断：补丁策略在当前阶段务实，但 6-12 个月后如果国产模型在 Agent 场景的原生能力没跟上，补丁的维护成本会失控。
未来 12 个月会发生什么
基于向邦宇的分享和我自己的观察，做几个判断：
Code Review 会成为下一个主战场。生成侧已经卷得差不多了，谁先解决 AI 代码的可信审查问题，谁拿下一个增长点。GitHub Copilot 在做 AI Code Review，但还是浅层 lint 级别。真正有价值的是语义级审查——理解业务逻辑，判断代码是否符合系统设计意图。
多 Agent 协作会取代单 Agent 长链。单个 Agent 跑几十轮对话、消耗百万 Token 去解决一个复杂任务，这条路走不通。成本太高，可靠性太差。未来的模式更可能是：一个 Orchestrator Agent 做任务分解，多个专精 Agent 并行执行子任务，结果汇总后由 Review Agent 做交叉验证。
IDE 和 CLI 的边界会模糊。向邦宇提到用户在 IDE、CLI、Web Agent 之间切换的痛苦。12 个月内，主流工具大概率会实现上下文互通——IDE 里开始的任务，无缝交给 CLI Agent 继续，Web 界面看进度。Claude Code 的 Session 机制已经在朝这个方向走。
安全问题会真正爆发一次。Cursor 删除本地代码、Claude Code 被劫持探测内网漏洞——目前还是小范围事件。但 Vibe Coding 工具在企业内网拿到的权限越来越多：读写代码、执行命令、访问服务。一次真正的安全事件只是时间问题。事后，所有工具都会被强制加上沙箱和权限管控。
一个实际建议
如果你的团队已经在用 Vibe Coding 工具，做一件事：给 AI 生成的代码单独标记来源，Code Review 时用不同的审查标准。
人写的代码，Review 重点是设计意图和可维护性。AI 写的代码，Review 重点是边界条件、安全漏洞和与存量代码的一致性。两套标准，一个流程。今天就能做，不用等工具。
560 行代码，5 分钟生成。谁来花 2 小时审？这个问题不会因为 AI 更强而消失，只会因为没人在意而恶化。
本文基于向邦宇在 QCon 2025 上海站的分享《Vibe Coding 在代码生成与协作中的实践与思考》展开，结合个人在 AI 编程工具使用中的观察撰写。