AI代码审查正在杀死开发者
我打开一个PR，代码看起来很干净，我通过AI来帮助我审查它，但我仍然不完全知道我是审查了它还是只是浏览了一个摘要。
这是诚实的版本。不是那个我告诉你我有一个整洁的过程和一个贴在显示器上的清单的版本。
现实是，我在一个几个人的团队中，管理着不同仓库中的几个不同的数字属性。有时是完全不同的技术堆栈。
我打开的每一个PR都是一个冷启动。
我们没有一个所有人都生活在一个代码库中。我们有好几个，其中大多数都不是新的。
我们维护的很多东西是遗留的、有点单体的，在团队一半的人加入之前就已经构建了。没有测试或代码检查规则，这是如果你今天从头开始会想要的那种基线。
所以当一个PR到达时，无论是AI生成的还是不是，很少有"哦，我知道这个文件，我知道它为什么存在"的运行先机。我几乎每次都是从头开始重建上下文。
当我引入AI来帮助审查它时，这并没有消除工作。它增加了一个步骤😬
为什么？因为现在我正在阅读AI标记的内容，交叉检查我是否同意，并在某些内容看起来不对或我认为它遗漏了什么时来回反复。
它仍然需要时间。它只是把时间移到了其他地方。
如果这些听起来很熟悉，你就是许多非常现实问题的受害者之一。
0、这不是倦怠。这是决策疲劳。
Stack Overflow的2026年5月分析去掉了废话，说编码代理正在给每个人带来决策疲劳。我发现这比"倦怠"更准确，因为它指出了真正改变的东西。
AI让编写代码变得极其"容易"，但它并没有消除思考。它只是把它移到了其他地方。
哪里？到代码编写之后的所有阶段，比如审查、验证、架构和部署。这些现在承担了以前分散在整个过程中的认知负荷。
嘿！ 花点时间想想这个。你不是因为工作做得不好而变慢了。你变慢是因为工作在你不知不觉中改变了形状。
1、决策疲劳背后的数据
代理AI PR等待审查者接手的时间是非辅助PR的5.3倍，源自超过800万个拉取请求。这意味着有人打开标签页的时间更长5.3倍；它不是审查时间。
你能感受到空气中的恐惧吗？
更重要的是，根据Sonar的2026年开发者调查，96%的开发者表示他们不信任AI生成的代码，但46%进入生产环境的新代码是AI生成的。
这告诉你，你的代码库中几乎一半是在怀疑下被审查的，通常没有时间真正坐下来处理这种怀疑。
注意： 如果你注意到PR在你甚至打开它们之前就在你的队列中停留更长时间，这不是个人生产力失败。它正在行业范围的数据中显示出来，虽然安慰很小，但我会接受它😅
这是有原因的。开发者并不是随机地联合起来反对AI。
显然，糟糕的代码很容易被拒绝。你看到它，你标记它，你继续前进。
AI生成的代码很少明显糟糕，这就是为什么它更难。
"几乎正确，但不完全"的输出是当今开发者的最大挫折，因为你无法通过模式匹配来绕过它。你必须真正深入挖掘。
2、为什么代码审查在结构上变得困难，而不仅仅是更忙
想想代课老师为一个他们从未见过的班级批改一堆论文， versus 一个老师批改他们整个学期教过的学生的论文的区别。
普通老师已经知道这个孩子总是过度解释他们的论文，或者那个孩子在结论上挣扎但证据很扎实。他们是在有上下文的情况下评分。
但代课老师没有这些。每篇论文都是一次冷读，他们必须仅从页面中重建对学生的感觉。
这就是AI编写PR的实际转变💁♀️
当队友打开一个PR时，你通常有一些共享的上下文。你在计划对话中。你知道他们的习惯。或者你可能已经知道他们在为什么权衡而苦恼。
然而，当AI代理打开PR时，这些都不存在。你每次都是代课老师。你仅从差异和描述中重建意图（它被告知了什么，它考虑了什么，它没有看到什么）。
这种重建现在是真正的工作。它不再是阅读语法，而是重建意图。
3、现在还有人真正阅读AI生成的代码吗？
网上正在进行一个更尖锐、更激烈的版本的对话，我认为这是实际上最让人们担心的部分。我自己也包括在内。
担忧是这样的：当AI生成PR的大部分内容，而优先级是完成审查并回到"真正的工作"时，现在还有人真正阅读代码吗？
或者审查悄悄变成了浏览AI生成的摘要并盖章通过？
4、诚实的真相（以及它的代价）
阅读需要时间。在PR以倍数到达的环境中，因为代理可以比任何一个人吸收它们的速度更快地产生它们，"仔细阅读每一行"不是免费的建议。
它有一个严重的代价，这正是首先造成瓶颈的原因。
审查者根本无法跟上数量，所以代码在未读的情况下合并，这就是新的常态。
这甚至发生在拥有成熟、纪律严明的工程实践的团队中。好的流程并没有保护他们，因为数量到达的速度比流程建立用来吸收的速度更快。
但阅读甚至不是整个问题。阅读代码与理解代码不同，而这个差距就是真正风险所在。
5、你自己的推理技能发生了什么
我不断在网上遇到资深工程师，那些在这个领域有15到20年经验的人，说他们自己的推理正在改变。听到这个很可怕。
更可怕的是，我甚至在给它起名字之前就在自己身上认识到了它😞
当你从编写代码中退后一步，把大部分时间花在指导AI和审查它交回的内容上时，你是在代码之上的一层操作。
你不是在编写它。所以你不是在练习它。
PR接PR，审查接审查，我正在吸收AI倾向于产生的任何模式，而没有自己建立那种肌肉的摩擦。
我在发生时没有注意到它。我后来注意到了，就在同一周，我发现自己接受了一个PR中的模式，因为它"看起来正确"，而不是因为我实际上追踪了为什么它是正确的。
这不仅仅是人们的一种感觉。根据2026年的一项研究，在学习新的异步库时依赖AI帮助的开发者在编码理解测试中的得分比没有依赖AI的开发者低近两个字母等级。最受影响的是他们的调试能力，这正是你捕捉AI错误所需要的技能。
我越依赖AI来审查AI，我就越不实际练习我需要的技能来首先捕捉问题。
6、实际上让我担心的写作类比
我为THT做很多写作，有一个版本几乎可以完美地映射到内容创作上。我打赌你听说过它👇
你用AI起草，使用语音指南和具体指令，有一段时间它保持你的风格。但你越多地接触它的输出而不是自己产生自己的输出，那个输出就开始塑造你所追求的东西。
你停止引导风格，开始吸收它。
代码没有太大不同。审查越多地成为你与代码库的主要接触点，那个代码库就越开始听起来像AI倾向于产生的东西。它不再是你团队自己会选择的东西。
注意 👀
这不是停止使用AI进行审查的论点。这是一个论点，当审查成为你与代码的主要互动形式而不是几种形式之一时，你确切地知道你在交易什么。
7、实际上该怎么办
这些都不是通过更努力地阅读或试图个人意志力让自己成为更好的审查者来解决的。
它需要结构。
如果你和你的团队在2026年处理这些，这是一些建议（其中许多我自己已经实施或正在考虑）。
8、你不需要全职PR审查者。你需要分层审查。
当审查成为瓶颈时，本能是认为你需要一个专门的人，他们的整个工作就是审查PR。
我前一段时间是这么认为的🥲
但在实践中，这行不通。
处理得好的团队实际上正在做分层、基于风险的审查。
不是每个PR都得到相同深度的审查。副本调整和对身份验证流程的更改不是相同的审查，将它们视为相同正是让人们精疲力竭的原因。
一个我看到有效的框架是：
- 阻止关键问题
- 警告中等问题
- 建议次要问题
不是每次都以最大强度审查所有内容。当AI审查者标记多个问题时，这很容易做到。使用你的判断。
如果你是为团队设置审查过程的人，而不仅仅是自己进行审查，这就是真正的决策点。
定义什么对你的系统算作高风险（身份验证、支付、数据迁移，任何涉及遗留系统且没有人完全理解的东西）。让较低风险的更改通过较轻的审查。
还有一个建议：堆叠差异。不是一次性让一个2,000行的PR落地，而是将工作分解成一系列较小的、相关的PR，随提交随提交。
这样，一个"活动源"功能就变成了：
- 一个200行的PR用于API规范
- 一旦批准，另一个PR用于服务器逻辑
- 一个PR用于UI
现在，我知道，这听起来像是更多的开销，在某种意义上它确实是，因为有更多的PR需要打开和合并。
但一个300行的PR你实际上可以在脑海中处理，胜过一个2,000行的PR你因为精疲力竭而浏览。
提示： 如果你的团队被巨大的AI生成PR淹没，在假设你需要更多人之前，试试堆叠差异。
上下文优先，而不是差异优先
在打开差异之前，阅读工单或PR描述以了解意图。
你不仅仅是在问：这段代码能工作吗？
你是在问：这段代码做了真正需要的事情吗？
跳过这一步正是你最终成为盲目评分的代课老师的方式。
提示 📍
如果你没有利用它但碰巧使用Jira和GitHub（谁不是呢），那么知道你可以链接两者。因此，在提交中引用Jira工单（这是好的做法；请挑战自己写好的、简洁的提交）会自动链接到工单本身。没有借口不审查工单。
9、测试优先，当它们存在时
如果PR包含测试，在实现之前阅读它们。它们是通往代码应该做什么的真相的最快途径。
然而，如果你的代码库还没有强大的测试覆盖率（如果你像我一样管理遗留系统，它可能没有），这是一个值得标记的差距。
如果没有东西可以依靠，你就不能依靠测试优先审查。
注意 ⚠️
编写相关测试是另一件用AI相对容易做的事情。我不会告诉你不要这样做。但我确实想强调理解这些测试在做什么以及它们证明了什么的重要性，以及每个测试背后的意图是什么。已经有多起案例证明，编写测试用例的AI会以一种方式编写它，以便它通过，因为这是他们完成任务的要求之一。
10、给AI一个角色，而不仅仅是一个请求
"审查这段代码"会给你一个通用的通过。基于角色的提示会给你更尖锐的东西，因为它迫使模型具体一点，有点对抗性，而不仅仅是随和。
这个改编版本接近我实际使用的内容：
你是这个团队的首席架构师。审查这个PR，就像你将是三个月后在生产中调试它的人一样。
1. 这段代码做了什么没有在任何地方声明的假设？
2. 在负载、错误输入或网络超时下，这会在哪里失败？
3. 测试是在证明行为，还是仅仅证明函数存在？
4. 你会因为什么阻止这个PR？不是风格，
而是实际风险。
你可以根据你项目的具体情况进行调整，我强烈建议将其设置为一个一致的工作流，在整个团队中统一使用。
提示 🔥
每个PR保持一个AI会话。将你自己的日常工作、多个审查和不相关的问题混合到同一个线程中会使模型工作的上下文变得模糊，结果你会得到更模糊的答案。就像我同时谈论熊猫、WebMCP中继、学习普通话同时审查希腊语，以及我是否想夏天染金发一样🙈
11、AI代码审查仍然需要你的地方
AI审查AI编写的代码可能会有相同的盲点。
如果模型在生成代码时遗漏了什么，类似的模型在审查代码时可能会再次遗漏它。
这不是跳过这个工作流的理由。这是一个理由，让你对任何涉及安全、架构或你不完全理解的系统的最终决定牢牢掌握在人类手中。
使用AI来过滤噪音（格式化、明显的不一致、总结一个大的差异），并把你自己的注意力放在它无法为你做出的判断上。
12、结束语
我在开头描述的不知所措并不是我做错了的标志。它就是审查现在的样子，对于许多在不熟悉的、遗留的、多仓库系统中工作而没有干净基线可以依靠的团队来说。
这不是个人差距。
这只是当数量超过你继承的流程时发生的事情。
如果你从这里尝试一件事，那就是分层部分。停止给每个PR相同的审查深度，无论它涉及什么。
这种转变比任何提示或工具都更能解决不知所措的问题。我这段时间一直在本能地这样做，只是为了保持理智；它产生了巨大的差异。
我们都在处理决策疲劳，但我们都可以通过在我们可以的地方制定一些标准，然后做人类不喜欢做但确实擅长的事情来互相帮助：做出决策。
你的审查积压现在实际上是什么样子？你们团队中有人在决定哪些PR值得深入阅读，还是仍然是先到先审？
我就说到这里。直到下次THT。
再见。
原文链接：Why AI Code Review Is Now Secretly Killing Developers
汇智网翻译整理，转载请标明出处