AI 写的 PR 描述正在毁掉代码审查：一位技术负责人的禁令与反思

Simon Willison 的博客上引用了一段来自 Cloudflare Workers 技术负责人 Kenton Varda 的话：他对团队中 AI 编写的 PR 描述、提交信息和工单内容下达了“暂停令”。原因是，这些 AI 生成的描述“比没用还糟”。这听起来有些反直觉——在 AI 辅助编程工具大行其道的今天，为何一位资深技术管理者要主动给 AI 泼冷水？

其实，Kenton 的吐槽点非常精准：AI 撰写的变更描述极尽所能地描绘代码细节，比如修改了哪几行、函数名是什么、逻辑分支如何展开，但这些信息，审查者看一眼 diff 就能明白。真正让他头疼的是，描述中缺失了“高层框架”——为什么要做这个改动？它遵循了怎样的设计思路？它如何融入更大的系统架构？换句话说，AI 给了审查者一堆唾手可得的表面信息，却屏蔽了最需要人类智力判断的抽象语境。

这揭示了一个深层次的缺陷：当前的 AI 仍然是一个“基于代码的统计模型”，而非“理解工程的智能体”。它的训练数据绝大部分是代码本身和简短的代码注释，但高质量的 PR 描述、设计文档、架构决策记录（ADR）这类充满业务逻辑和权衡的文本，在互联网上占比极低。因此，AI 在生成文字时，更容易复现它见惯的模式——详细的、面向实现的解释，而不是它少见甚至未见过的、需要综合业务和技术的高层次总结。

我们可以用一个比喻来理解：你招了一个新员工，他没有参与项目背景、产品逻辑和架构讨论，只埋头看了一遍代码仓库，然后让他写一份“本周工作总结”。他可能会这样写：“我修改了 user.js 里的第 52 行，把 if (age > 18) 改成了 if (age >= 18)，还重构了 order.js 里的两个函数。”这总结错了吗？没错。但对团队而言，这就是信息垃圾。你真正想知道的是：“为了修复未成年人年龄判定边界值的问题，我对用户年龄校验逻辑做了对齐，并顺便解耦了下单流程，为后续的促销规则扩展做准备。”

Kenton 的禁令，其实是在提醒整个行业：AI 辅助编程正从“狂热试用期”步入“理性工具化”阶段。我们不再满足于“AI 能写代码”这件事本身，而是开始审视“AI 写的代码和文字，到底是在提升团队效率，还是在制造新的认知负担？”一个被很多人忽略的真相是：软件开发中最困难的部分，从来不是敲代码，而是沟通。代码是给人读的，变更描述是给人看的，架构设计最终要转化为团队共识。当 AI 介入这些人类协作的环节时，如果不能理解目标、对齐认知，那么它产出的自动化内容，反而会让信息密度下降、沟通成本上升。

那么，开发者们能从中得到什么启发呢？首先，学会给 AI 分派合适的任务：那些重复性的、模板化的、重细节轻语境的工作——比如生成单元测试骨架、编写函数注释、提取重复代码——让 AI 做；而那些需要抽象思维、大局观和人际对齐的事情——比如撰写 PR 描述、设计系统架构、编写决策记录——最好还是由人主导，AI 最多扮演助手角色，提供参考草稿。其次，在团队中建立关于 AI 使用的“节奏感”：不是能用就一定要用，有时候关掉 AI，自己静下心来理清思路，反而效率更高。

最后，让我们回到那句“比没用还糟”。它之所以糟，不是因为 AI 做错了什么，而是因为它制造了一种“有信息量”的假象。当审查者看到一篇洋洋洒洒的 PR 描述时，本能地会认为其中已经包含了所有关键信息，从而放松审查的警惕性。而真正重要的设计意图却因为缺失而被忽略，这可能是 AI 带入工程流程的最大风险。在通往智能软件开发的道路上，我们或许需要先学会一件事情：警惕那些看似智能，实则无味的自动化。

原文地址: Quoting Kenton Varda