你的编程智能体生成的那些人类已经不再阅读的 PR 描述
一年前,你的团队采用了 PR 描述模板。它包含 ## Summary、## Changes、## Test plan 和一排复选框。审查者非常喜欢它:每个 PR 都有上下文,每个 PR 都有测试计划,每个 PR 都有结构。六个月后,编程助手学会了填写它。现在,每个 PR 依然有 ## Summary、## Changes、## Test plan 和一排复选框 —— 但审查者不再阅读标题以外的内容了。曾经聚焦注意力的格式,现在反而成了“此处不值得关注”的信号。结构比它所承载的信号寿命更长。
这不是代码质量问题。这些 PR 中的代码通常是没问题的。问题在于,撰写描述的行为已经从思考变更的行为中被剥离,而描述正是审查者用来分级处理(triage)其有限注意力的工具。当该工具变得格式统一、措辞合理,且与其他所有 PR 毫无区别时,审查者的注意力分级机制就失效了。曾经用于挖掘异常情况的系统,现在将所有内容摊平成了同样的形状。
2026 年的一项 PR 描述特征研究发现,Claude Code、GitHub Copilot、Cursor 和 Devin 生成的描 述具有一种可识别的共同特征:很少使用多样的标题、公式化的分段,以及一种填满模板却不区分优先级的冗长感。研究将这种特征与较低的可读性评分联系在一起。团队通常会讨论可读性较低的部分;而更危险的部分在于,这种形状也是可预测的,而可预测的输入正是审查者注意力产生习惯化倾向的对象。
习惯化在起作用,而非懒惰
审查者之所以略读助手生成的 PR,并非出于疏忽。他们正在做地球上每一个神经系统在面对重复刺激时都会做的事情:停止向其分配注意力。临床术语称之为“习惯化”(Habituation)。正是这种机制让服务器机房的嗡嗡声在几分钟内从你的意识中消失,也是这种机制让 ICU 护士在那些每班次触发几十次却无任何实际意义的床边警报声中安然入睡。习惯化不是性格缺陷,它是有限注意力应对无限噪音时的必然结果。
在助手普及之前,PR 描述曾是一种低频、高方差的信号。一个审查者每周可能会看到十个描述,每个都由不同的人编写,每个都体现了作者对这次变更中重要事项的判断。有些描述只有两行,有些是长篇大论,有些则特别指出了某一行高风险代码。方差即信号:描述的形状在你阅读 diff 之前就告诉了你一些关于变更的信息。冗长的描述意味着作者认为这次变更很棘手;简短的描述意味着作者认为 diff 本身已经解释得很清楚了。审查者的眼睛学会了通过元层面的形状来进行解析。
助手生成的描述消除了这种方差。每个 PR 都有相同的四 个部分、相同的段落节奏、相同的复选框列表,以及相同的“Test plan”标题后紧跟的三个看似合理的要点。这种形状不再编码作者的判断,因为没有作者的判断参与塑造它。审查者的习惯化发生得比任何人预想的都快:在采用助手后的第三个月,PR 描述在感知上的权重已经变得和 GitHub 导航栏一样——虽然存在,但视而不见。
光环效应是二阶失效
习惯化降低了注意力的底线。光环效应(Halo effect)则降低了怀疑的底线。2026 年 1 月的一项研究发现,AI 生成的 Pull Request 中,即使代码冗余度几乎是人类编写的两倍,审查者给出的负面评价反而更少——表面上的合理性降低了对代码本身的批判性参与。这两种效应相互叠加:审查者停止阅读描述,因为它看起来和所有其他描述一模一样。然后,他们在查看 diff 时已经预设该变更已经过深思熟虑,因为描述听起来很有条理。格式精美的 PR 劫持了它的质量信号通道:它现在发出的信号是“扫一眼并批准”,并不是因为它不好,而是因为它的形状中没有任何东西能将需要仔细检查的变更与不需要的区分开来。
今年一份被广泛引用的行业报告指出,在 AI 采用率高的团队中,PR 审查时间增加了 91%,而合并的 PR 数量增加了 98%。时间和数量都在增加,这意味着单个 PR 的审查强度下降了。其中一部分是真正的效率提升,但很大一部分是审查者凭直觉进行分级处理,因为描述已经不再能辅助他们决策。
PR 描述的真正作用
关于 PR 描述的文献在“一个好的描述应该做什么”上是一致的:它告诉审查者往哪里看。它指出作者不确定的设计决策。它标记出触及代码库中最棘手部分的代码段。它标出 diff 中那些仅靠阅读代码无法理解的部分——那些存在于某人脑海中的约束、上个月的客户事故,或者变更所解决的规范中的歧义。描述是作者对审查者注意力预算的一份“情报”赠礼。
一个刚生成了 600 行 diff 的助手并不具备这些上下文。它可以总结 diff 做了什么,但它无法可靠地告诉审查者作者对哪一部分感到不确定,因为并没有一个对不确定性持有观点的“作者”。它可以列出更改的文件,但列出更改的文件并不是价值所在。助手生成的描述填补了格式,却跳过了功能。阅读它的审查者无法知道该看哪里,因为描述并不是由任何知道该看哪里的人编写的。
这是更深层次的失败:模板是作者和审查者之间关于如何分配注意力的契约。而这份契约的一方却是由一个并不掌握契约所旨在传达的信息的系统签署的。
- https://github.blog/ai-and-ml/generative-ai/agent-pull-requests-are-everywhere-heres-how-to-review-them/
- https://arxiv.org/html/2602.17084v1
- https://www.latent.space/p/reviews-dead
- https://medium.com/@codeandbird/stop-code-review-slop-how-to-review-prs-in-ai-era-9820556b4651
- https://www.codeant.ai/blogs/prevent-ai-code-review-overload
- https://bryanfinster.substack.com/p/ai-broke-your-code-review-heres-how
- https://dev.to/harsh2644/ai-is-quietly-destroying-code-review-and-nobody-is-stopping-it-309p
- https://rbulsing.medium.com/the-rubber-stamp-problem-how-ai-outpaces-the-oversight-it-promises-ff8372752673
- https://jvaneyck.wordpress.com/2026/03/21/comprehension-debt-the-hidden-tax-on-ai-generated-code/
- https://new.signadot.com/blog/traditional-code-review-is-dead-what-comes-next
- https://en.wikipedia.org/wiki/Alarm_fatigue
- https://www.networkworld.com/article/938724/the-science-behind-alert-fatigue-how-to-turn-down-the-noise-so-you-can-hear-the-signal.html
- https://www.gustavwengel.dk/2025/02/19/pr-reviewer-practices.html
