日期：2026-09-04
主题：在 AI 时代幸存于代码评审：当每个 PR 都变成 6k 行，人还怎么审得动？
原文：在 AI 时代幸存于代码评审：当每个 PR 都变成 6k 行，人还怎么审得动？
来源：Lobsters
领域：🏗️ 系统工程
AI 编程普及之后，代码的"产量"被指数级放大了。一个很直观的现象是：同事一个个都成了"AI 重度用户"，送到评审手里的 Pull Request，平均有六千行左右的 diff。而业界早就有一个共识——哪怕比这个小一个数量级的 PR，都已经大到没人能真正审得动了。
这绝不是个别人在发牢骚。九月四号，Lobsters 上有人发帖《在 AI 时代幸存于代码评审》，被顶进了高热度讨论区。发帖人说他还在坚持"人类应该理解自己构建的系统"，所以不太想用 AI 来代劳评审；但同事已经全部 AI 化，每个 PR 都变成六千行，他只能无奈地抛出一个问题：有没有人找到了能扛住这场风暴的策略，组织的也好，个人的也好？
这场讨论把一个问题摆到台面上：当代码变得又便宜、又海量，评审它的人，该如何自处？
先理解一个基本事实：代码评审真正的工作，并不只是抓 bug。
Rust 项目也在八月初做了一件很相关的事——它采纳了一份 LLM 政策。政策文章里有一段话特别点题："评审的大部分工作不是抓 bug，而是判断方向对不对、这个 PR 是不是个好主意。换句话说，评审是由一个个决策构成的。"
代码只是这条决策链里最小、某种程度上也最不重要的一环。作者有没有理解自己在写什么、打算怎么让它演化、凭什么选择这个形态——这些才是评审真正关心的。可当你收到一个六千行的 diff，你能看到的只有代码，而它恰恰是最不重要的部分。
更麻烦的是，AI 把"成品等于付出"的信号也破坏了。过去一个打磨漂亮、测试齐全的 PR，意味着背后有人在时间、努力和理解上投了钱。现在这个信号不再可靠：PR 漂亮，不代表作者投入；作者"polished"，不代表他理解代码；如果是自主 Agent 生成的，背后甚至根本没有"人"。连"这个 PR 预示着作者会长期留下来"这条，也随着写代码的门槛暴跌而失效了。
Rust 那篇文章把它总结成三个问题，几乎就是这场讨论的技术注脚：
这里藏着一个反直觉的结构：代码变得越来越便宜，评审却变得越来越贵。生成一个六千行的 PR 只要几分钟，可要审它、理解它、判断它值不值得合入，可能要花上几小时。成本并没有因为 AI 而消失，只是从"写"这一侧，整体挪到了"审"这一侧——而"审"，恰好是最依赖人类判断、最没法外包的环节。
这场讨论里有个数字值得留意：当时 rust-lang/rust 有整整一千二百八十一个打开的 PR。这并不意味着"没人写"，恰恰相反——是写的人太多、愿意审的人太少。文章把这形容为向评审"连珠炮式地开火"，会给他们造成很高的心智负担。当每个 PR 都冲到六千行，这个负担就被放到了极限。
Lobsters 评论则印证了评审者的真实痛苦。有人说，LLM 生成的解释文本本身就难以跟进：一个长度检查"gates"了数组访问，一个测试"pins"了某种行为，满屏生僻术语，句子结构也成障碍，经常要反复读很多遍才看得懂。
// 一段典型的、AI 生成的代码评审意见
"这个 length check 现在 gates 了底层的 array access，
建议用一个 named constant 把 magic number pin 起来，
这样 behavior 会更 explicit。"
更让人心累的是人的条件反射。只要 LLM 标出某个问题，大家就倾向于要求"把它清理干净"；可 LLM 自己并不一致——有时候坚持用命名常量，有时候又无所谓。于是"照 AI 意见清理"变成一件很讽刺的事，最终演变成狗追尾巴式的循环消耗。
应对思路大体分成组织和个人两层。
组织最常用的一招，是给 PR 大小设硬性上限。评论区一位朋友说，他们公司规定 PR 的 diff 不能超过四百行（移动代码这类例外），而且这条规矩对 AI 写的、人写的代码一视同仁，"两者没有区别"。在他看来，AI 评审可以充当第一遍粗筛、帮人类省点时间，但"AI 工具说到底只是工具，代码和决策的责任仍然在人"，"AI 没有能力判断一份代码够不够格上线"。
Rust 的做法则更进了一步，把原本的"狂野西部"式管理变成一份公开政策。它点名了四类受影响的人：评审或主持 PR 的人、提交 LLM 生成代码的人、用 LLM 发现 issue 再贴到仓库的人、以及直接引用 LLM 言论来写 issue 或评论的人。政策的一个关键价值是透明——新贡献者一开始就清楚边界在哪，不会莫名其妙地被关掉 PR；评审者也能指着条款，给出一个"可落地、可引用"的理由来关闭不合规的 PR。
值得强调的是，这份政策并不是要封杀 LLM。它只针对 rust-lang/rust 这一个仓库的贡献流程，并且作者明写了"这不是 Rust 对 LLM 的官方立场"。它的目标不是把 AI 挡在门外，而是保住社区那条不成文的契约：当我们审一个 PR，默认是在跟一个想做到最好的真人对话。所以真正被划红线的，不是用 AI 写代码，而是用 AI 掩盖"作者到底有没有想清楚"这件事。政策真正要的是披露与意图——让审的人知道哪些代码来自 LLM，更要让他相信，背后仍然是一个懂得自己改了什么、并愿意为之负责的人。
过去那段"没人管"的日子里，出现过不少荒诞场景：有人把危险的 MIR 优化当作自己的第一个 PR 塞进来；有人在 PR 描述里写一句 Verification: git diff --check，仿佛这就算验证过了。这些恰恰是公开政策想要终结的"信号污染"。
到了个人层面，答案就有些无奈了。Lobsters 里有人坦然承认"我也有这个问题，但我没有策略"；也有人干脆选择退出——只审别人点名要自己审的 PR，并坦白迟早会变成"扫一眼、表面提两句意见就通过"。他说自己讨厌这样，但"得保住 sanity"。
但在这片"保全自己"的共识里，也有人仍在坚持。反复被强调的一点是：AI 生成的解释再花哨，也要让作者亲口讲清楚他的意图；因为代码生产的速度可以交给机器，可"有没有理解、方向对不对"这件事，机器替不了。这恰好呼应了 Rust 的那句话——我们要的不是机器把意见再复述一遍，而是"你的想法"，哪怕那只是一个人在努力像人一样思考。
如果把这场讨论里的声音排成一条线，一端是"用规则挡住海量 PR"的组织约束，中间是"只把 AI 当第一遍粗筛"的折中，另一端是"干脆退出评审"的个人止损。它们指向的是同一件事：AI 时代真正需要被保护的不再是"写代码的自由"，而是"理解与判断的余地"。当海量又漂亮的代码涌来，能顶住的人，靠的并不是更快的阅读，而是更清醒的边界——知道什么必须亲眼看，什么可以放心交给机器。
这场讨论真正触到的，是一个结构性矛盾：AI 把"生产代码"的能力放大了十倍、百倍，却没有放大人类"理解与决策"的能力。于是评审从"审代码写得好不好"，悄悄变成了"审作者有没有真正想清楚"——而后者，恰恰是六千行 diff 无法传递的东西。
当代码的边际成本趋近于零，最稀缺的不再是代码本身，而是判断力、方向感、以及对系统全貌的理解。组织用规则和公开政策来兜底，个人靠坚持与自知来保全。短期的办法是立规矩，长期的办法是重建"作者理解"这件事的信用体系——让代码可以快速生成，但让"想清楚了"依然值得被看见。我们也许无法阻止 AI 涌进每一个 PR，但至少可以守住那条底线：代码可以交给机器，理解必须留给人。