31 篇博文 含有标签「code-review」

一年前，你的团队采用了 PR 描述模板。它包含 ## Summary、## Changes、## Test plan 和一排复选框。审查者非常喜欢它：每个 PR 都有上下文，每个 PR 都有测试计划，每个 PR 都有结构。六个月后，编程助手学会了填写它。现在，每个 PR 依然有 ## Summary、## Changes、## Test plan 和一排复选框 —— 但审查者不再阅读标题以外的内容了。曾经聚焦注意力的格式，现在反而成了“此处不值得关注”的信号。结构比它所承载的信号寿命更长。

这不是代码质量问题。这些 PR 中的代码通常是没问题的。问题在于，撰写描述的行为已经从思考变更的行为中被剥离，而描述正是审查者用来分级处理（triage）其有限注意力的工具。当该工具变得格式统一、措辞合理，且与其他所有 PR 毫无区别时，审查者的注意力分级机制就失效了。曾经用于挖掘异常情况的系统，现在将所有内容摊平成了同样的形状。

我合作的一个支付团队的高级工程师曾给我讲过一个故事，我认为每一个运行编程 Agent（AI 代理）的团队最终都会经历。他们的代码库有一个 Result<T, E> 封装器——这是自研的，位于单个 core/result.ts 文件中，在该服务的约两百处调用点被使用。新代码被要求在每一个可能失败的函数中传递 Result；而 throw 则保留给真正意料之外的状态。这并非由 lint 规则强制执行。这就是他们的“方言”。

在使用编程 Agent 交付六个月后，他们审计了 Agent 合并的 diff（差异）。大约三分之一的新函数完全忽略了 Result。Agent 选择了 try/catch，返回了 T | null，抛出了带有描述性消息的 Error 子类——在某些设想的代码库中，这些选择中的每一个都是正确的。但在当前这个代码库中，没有一个是正确的。代码通过了类型检查。测试通过了。审阅者批准了它，因为每一行看起来都没有错。但 Agent 修改的文件不再与它旁边的文件保持一致，团队在自己的服务内部悄然滋生出了第二种“方言”。

这就是我想谈论的故障模式：不是 Bug，不是幻觉，也不是违反了 lint 规则——而是惯用法漂移 (Idiomatic Drift)。Agent 交付的代码可以编译、运行并通过测试，但其风格并非你的代码库所使用的。随着合并次数的增加，代码库会分化为 Agent 风格区和人类风格区，而代价会体现在任何仪表盘都无法监控的地方。

二十年来，软件工程的瓶颈一直是写代码。我们优化了 IDE、自动补全、重构工具和各种框架，让"打字"变得更便宜。我们赢了。可现在瓶颈往下游挪了一步：写代码很便宜，读代码却很贵。PR 机器人可以并行启动十次实现尝试，在你早上喝完咖啡之前就把十个 Pull Request 砸到你的仓库里。你的审查者做不到这一点。

AI 辅助的软件交付，速率限制器已经不再是模型的每秒 token 数，而是你每天能投入多少双"人眼"去看 diff。当这些眼睛被压垮，系统不会优雅地降级——它会开始盖橡皮图章。代码带着 LGTM 🚀 被合入，没有人真正读过。一名资深工程师批准了一份由 AI 写、又被另一个 AI 工具审查过的补丁，三周后一个数据不一致的 bug 吃掉了某个人四十个小时的人生。表面上的正确不等于系统层面的正确，绿色的流水线不等于"我理解了"。

你的编码 Agent 完成了任务。Diff 很小,测试全绿,Lint 干净,而 PR 正文从头到尾只有一句话:"修复 X 模块中的 bug。"远在六个时区之外的评审者打开页面,孤立地阅读 diff,看不出任何毛病,于是批准了一个技术上完全正确、却解决了错误问题的改动。代码合入。两天后,一位客户来问他们一直依赖的某个变通办法为什么突然失效了 —— 这时你才发现,你的 Agent 修复的那个 bug,并不是工单里描述的那个 bug。

代码没问题。评审者很尽责。Agent 也严格按照吩咐做事。问题出在他们之间的那个交付物 —— pull request —— 它丢失了一切本可避免这次失误的信息。

一个 PR（合并请求）进入了你的评审队列。Diff 显示系统提示词（system prompt）中修改了三个词：Output strictly valid JSON 变成了 Always respond using clean, parseable JSON。这看起来就像是一次文案润色。你快速浏览了一下，CI 检查勾标是绿色的，于是你点击了批准。总耗时：90 秒。

六个小时后，下游解析器开始拒绝带有尾随逗号和缺失字段的响应。结构化输出的错误率从接近零飙升至两位数，一个创收工作流陷入停滞。Diff 中没有任何迹象预示到这一点。Diff 中也不 可能 预示到这一点，因为 Diff 衡量的是错误的东西。

这就是评审提示词变更的核心问题：提示词 Diff 的大小完全无法说明其影响范围的大小。三五个词的修改与三段话的重写都只是文本，而文本 Diff 以相同的视觉权重呈现它们，就像对待任何其他编辑一样。但提示词并不是 描述 行为的文本 —— 它是 导致 行为的文本，而一次编辑所产生的因果爆炸半径在你评审的产物中是不可见的。

在 2026 年的代码审查（Code Review）讨论串中，最昂贵的一句话莫过于“这是 Agent 这么写的”。这并非因为它本身是错的——有时它确实没错——而是因为它终止了本该由此开启的对话。审查者输入一个问题，作者直接引用模型的推理作为回复，讨论在任何人真正开始争论这项变更之前就结束了。反对一个自信且谈吐得体的模型的社交成本，已经悄然高过了合并一个隐蔽 Bug 的成本，而大多数团队在未来两个季度内都无法在指标中察觉到这种权衡。

这不是一个关于 AI 写代码好坏的故事。它会写代码，其中有些还写得不错。这是一个关于当编写代码的摩擦消失时，质量关卡（Quality Gate）会发生什么的故事。审查速度上升，缺陷率也随之同步上升，而这种关联并不明显，因为没有人在追踪审查耗时与缺陷时会关联作者的类别。曾经是代码库品味核心的资深工程师，在一个悄然转向“模型盲从”的文化中，变成了孤独的坚持者。

翻开任何一个运行了一年的生产系统提示词（system prompt）的 git blame，你都会发现一些工程团队不愿承认的事实：这个文件有三个作者，而他们对“变更”的定义各不相同。上个月重构指令块的工程师将提交记录标为“无功能变更，仅为了清晰起见重新排序”。每季度读一次该文件的产品经理会这样描述同样的差异：“你改写了语气——客户会察觉到的”。运行回归测试套件的 ML 工程师会说：“你搞坏了第三个少样本示例（few-shot example），从那以后评估结果（eval）就一直变红了”。

这三者都是正确的。提示词同时具备代码、规范和超参数的属性。任何长期交付 AI 功能的团队都会发现，该文件的提交历史是一场缓慢进行的三方署名权争议，CODEOWNERS 无法捕捉到这一点，diff 查看器也无法体现出来。

在过去的二十年里，制约理论（Theory of Constraints）在软件交付中的答案始终如一：瓶颈在于编写代码。我们围绕这一假设构建了一切——结对编程、IDE 自动补全、更快的 CI、更小的微服务，所有这些都是为了让更多的代码通过固定宽度的审阅管道。接着，编程 Agent 出现了，管道的生产端拓宽了 5–10 倍，而审阅管道的宽度却纹丝不动。一位过去每周提交 3 个 PR 的资深工程师，现在正监督着一群在一个下午就能提交 30 个 PR 的智能体。团队的交付速度不再取决于编写代码的速度，而是取决于人类阅读代码的速度。

这并非未来的问题。据测量，在某些样本中，PR 审阅时间的中位数同比增长了 441%，并且在未经任何审阅的情况下就被合并的 PR 增加了 31%——这并非出于政策规定，而是因为审阅者已经放弃了跟上进度。Stripe 每周交付超过一千个由 Agent 生成的 PR。在一项基准测试中，特性分支（feature-branch）的吞吐量同比增长了 59%，而主分支（main-branch）的吞吐量却下降了 7%——代码正在被编写，但没有被发布，因为它们卡在了审阅环节。

当同一个模型负责编写需求、实现代码并编写用于验证正确性的断言时，“所有测试通过”不再是功能正常工作的证据，而仅仅证明了模型是内部一致的。这是两回事，而这种区别正是编写测试的初衷。

我们通常对测试套件的理解是，它们提供了“第二意见”。作者带着一种对需求的心理模型编写代码，而测试编写者则带着略有不同的心理模型编写断言。这两个模型不一致的地方，往往就是 Bug 潜伏之处。这种说法的前提是测试编写者与代码作者拥有不同的认知视角。如果去掉了视角的差异，测试套件就不再携带关于正确性的任何独立信息——它只携带关于一致性的信息。

周二下午，一个只有六行代码的系统提示词（system prompt）编辑出现在了一个 Pull Request (PR) 中。Diff 只是普通的英文。两位评审者扫了一眼新的措辞，觉得读起来更自然，于是点击了批准。PR 在不到一分钟内合并。到了周五，客服开始收到关于智能体的工单：它突然拒绝总结超过一定长度的文档，不再引用来源，并莫名其妙地在每句回复开头都加上 “Certainly!” —— 这种行为没人要求过，Diff 中也无法预见。

当一个花了十年时间学习如何评审代码的团队，在面对提示词这一产物时，竟然退化到了第一周的水平，结果就是这样。Diff 看起来 毫无害处，因为它读起来像英语，而人类正是用眼睛来审阅英语的。让代码评审发挥作用的规范 —— 运行测试、检查影响范围、对 “小改动” 保持适当的怀疑 —— 并没有悄然转化。措辞变好了，但行为变差了，直到用户发现之前，没人注意到。

你的代码评审正在优化错误的目标。当 AI 智能体（agent）贡献了你大部分的代码提交（commits）时，评审局部正确性——这个函数的功能是否如其所述？——就像是通过检查笔迹来给数学考试评分一样。机器已经通过了你的代码检查工具（linter），运行了你的测试套件，并按照规范格式化了输出。它所引入的 Bug 并不是行内（line-by-line）评审所能捕捉到的那种 Bug。

一项针对 GitHub Pull Request 的大规模研究发现，AI 协同编写的 PR 包含的缺陷是纯人工 PR 的 1.7 倍——其中包含多出 75% 的逻辑和正确性问题、2.74 倍的安全漏洞以及 3 倍的可读性问题。这并不是因为代码看起来有问题，而是因为它在错误的地方做了错误的事情，且对系统的其他部分持有错误的假设。这些恰恰是为捕捉拼写错误和风格违规而优化的传统代码评审所无法发现的故障模式。

当生产环境出现故障时，工程师们首先会想到 git blame。提交哈希值指向 PR，PR 指向作者，而作者则指向上下文——Slack 讨论串、设计文档，或者是记住了代码初衷的那个大脑。这条链路是团队排查事故、进行安全审计以及积累机构知识的方式。它假设每一行代码都有一个理解自己在做什么的人类作者。

AI 已经悄然打破了这一假设。目前约 46% 的代码由 AI 生成，在 Java 团队中，这一比例甚至超过了 60%。这些代码中的大部分都不携带任何有意义的溯源元数据。git blame 链条依然在运转——只是现在它终止于一名开发者，他们接受了一个可能并未完全理解的建议，而且没有记录提示词、模型版本或 AI 拒绝的备选方案。