AI 编程落地后，技术团队晨会的内容悄悄从“今天写什么”变成了“今天轮到谁看代码”。机器几秒生成一个功能，PR 队列越排越长——代码 Review 成了新瓶颈。知乎上一个被顶了近百赞的回答说得很直白：只是写代码的速度快了，但审核跟不上，尤其是工业级应用，不仔细审核，哪里敢用啊。这就是“AI 快十倍、人只提效 30%”的由来。知乎
这不只是小团队的烦恼。Claude Code 自己的代码约 90% 由 Claude 编写。Anthropic 的 monorepo 每天落地的变更从 5 月的约 2,500 条涨到 9 月的超过 30,000 条，四个月涨了 12 倍多。知乎知乎
他们给出的解法不是放弃审查，而是把大部分“阅读”交给机器，人只保留 5 类决定：该不该做、高风险代码、日后会被别人照抄的架构、能不能看懂证据、为结果负责。效果也写在博客里：6 到 9 月，合并的 PR 翻了一倍多，被回滚的 PR 占比下降了 40% 以上。看的人少了，错也少了。知乎知乎
另一个共识是把 review 时机前移：PR 提交前，先让 Claude 跑完测试、构建，再起一个 subagent 在没被上下文污染的“fresh context”里审一遍 diff——像拼写检查一样边写边审。但两个 agent 对着跑会停不下来：他们真遇上过作者与 reviewer 一晚互改 50 多轮，git blame 显示，reviewer 反复标记的问题里，大约 59% 在第一轮时就已经在了，很少发现新 bug。于是定了个“3 轮上限”，要求 5 轮以上的 PR 直接降到原来的六分之一。知乎
没有 Anthropic 家底，也能抄这套作业。一位 vLLM 社区 Maintainer（AMD ROCm 团队）把 PR 流程改成了“看板 + 报告”：一个纯静态看板集中管所有 PR 状态、CI 与重试按钮，红的 Job 先和 Main 对比、区分 flaky 再决定一键重试还是人工看日志；再用 Claude Code 跑自己写的 Review Skill 产出中文审查报告。他的纪律很硬：给阻塞性意见必须说得出具体触发输入，说不出来就降级；benchmark 数字找不到来源一律标“未验证”。用上这套工作流后，每个月能 Review 的 PR 从 10 个左右变成 40～80 个不等。但底线只有一句：AI 报告只是 Review 的输入，判断仍由人给出。知乎
第三层：别再只盯代码本身。让同一个模型写完实现再补单测，基本属于自欺欺人——它会照着自己的代码反推断言，覆盖率能刷到九成，一上线遇到没见过的输入就歇菜。真正管用的是把验证对象从“代码”换成“行为”：影子流量让新旧版本同时吃同一份真实线上请求，旧结果给用户，新结果只在后台逐条比对，Uber 重构账户系统、GitHub 用 Scientist 框架都是这个路数。目标也不是 bug free——承认 LLM 代码必然带 bug，让修复速度快过 bug 产生的速度；而这套闭环能不能转，取决于可观测性铺没铺到位。有团队说得实在：先补日志、trace 和指标，而不是再买一个更贵的模型。知乎
最后留给个人一句提醒。那篇工作流文章的评论区，最扎心的问题是：“没理解这套流程到底人在把关吗？”——如果理解也外包出去，半年后你手里只剩“我很高效”的手感，和看不出 AI 错在哪的能力。瓶颈确实从“写”挪到了“看”，而聪明的玩法是让机器去读那些读得快的部分，人坐进那 5 类值回票价的决定里。
