Hacker News 让代码审查接受审判。AI 让瓶颈再也无法被忽视
Hacker News 本周揭示了一个尖锐矛盾：AI 生成代码的速度更快了，但资深工程师审查变更的速度依然受限于人工效率。这场讨论源于 Thoughtworks CTO Rachel Laycock 的观点：团队应停止将拉取请求视为软件开发的核心。
她的立场不止是自动化重复检查那么简单。Laycock 希望团队将设计判断、知识共享和架构讨论前移到开发流程中。人工审查仍会保留，但仅用于其价值足以抵消延迟成本的变更。
这使她与另一种更保守的 AI 审查策略形成对立。该策略在利用自动化筛除常规工作、识别风险的同时，保留人工批准环节。双方都看到了不堪重负的审查队列，但对于团队应修复这条队列，还是让许多变更不再进入其中，意见相左。
Hacker News 的讨论始于一道失衡的公式
AI 提高了代码产出，却没有增加合格审查者的注意力。
这场争议在故事登上 Hacker News 之前就已开始。开发者智能公司 DX 的 Brian Houck 认为，AI 暴露了原本就承受压力的审查流程中的弱点。
他的担忧基于软件生产方式中可量化的变化。Meta 于 2026 年发布的一项 RADAR study 显示，每个人工合并 diff 中的重要代码行数同比增长 105.9%。每位开发者的 diff 量增长了 51%。
该论文将超过 80% 的增长归因于智能体式 AI。在这里，智能体式系统指能够在有限人工干预下完成多步骤编码任务的系统。
DX 的另一项研究考察了 2026 年第二季度的 400 多家组织。其 AI code analysis 估计，51.9% 的编码工作由 AI 完成，且未经大幅人工改写。
这一数字来自自报数据，因此不应被视为对每一行生成代码的精确测量。DX 将其表述为对委托给 AI 的编码工作量的估计。
同一分析发现，拉取请求的中位规模在 2025 年 7 月至 2026 年 6 月期间从 44 行增至 72 行。这意味着一年内增长了约 64%。
这些变化形成了不利的比例：代码到达得更快，单个审查单元变得更大，而具备相关系统知识的工程师数量仍然有限。
AI 编程工具可以将实现时间从数小时压缩至数分钟。但它们无法自动赋予审查者评估陌生架构决策所需的上下文。
由此产生的队列不只是一个小麻烦。延迟审查会打断作者的工作，迫使审查者重新找回上下文，也拉大了决策与纠正之间的距离。
Houck 认为，团队应保护人工审查，因为它同时承担多种功能。审查可以发现缺陷、传播知识、培养工程师，并建立集体责任。
Laycock 接受这些目标。她于 9 月 2 日发布的 code review argument 则质疑，拉取请求是否应承担这些任务。
她的核心问题很简单：为什么要等到实现完成后，才讨论最重要的决策？
这一问题将熟悉的生产力抱怨转化为流程挑战。问题不再只是 AI 产出的代码过多，更深层的问题在于团队将人工判断放在何处。
拉取请求通常出现在某人已经选定方案、完成实现并准备将变更集成之后。审查者是在若干重要选择已经固化后才介入。
此时，质疑设计在社交和经济层面都代价高昂。审查者可以要求修改，但大规模变更意味着要舍弃已完成的工作。
这种结构鼓励人们评论局部细节，而不是讨论根本性的替代方案。团队可能会争论命名、格式和小型逻辑选择，却因惯性接受更大的设计决策。
Hacker News 的讨论之所以重要，是因为它揭示了两种不同的审查定义。一种将审查视为必需的检查步骤。另一种则将其视为协作推理的一个可能场所。
这一差异塑造了每一种拟议解决方案。
拉取请求成了装载过多问题的容器
现代代码审查承载的职责，远超一个异步检查点原本应承担的范围。
代码审查起初是一项质量实践，但团队逐渐赋予它更广泛的职责。如今，一个拉取请求可以同时充当缺陷筛查、安全关卡、辅导环节和架构记录。
它还可能作为合规证据、相邻团队的通知系统，以及集体所有权的最终体现。任何一项功能失效，都会促使团队增加一名审查者或一项检查。
长期以来，研究都表明，审查带来的结果不止于发现缺陷。Microsoft 的一项 modern review study 观察了 17 名开发者，并对 570 条审查评论进行了分类。
研究人员还调查了 165 名管理者和 873 名程序员。他们发现，与缺陷有关的评论仅占实际审查活动中相对较小的一部分。
开发者通过审查来理解变更、探索替代方案、共享知识，并维持对队友工作的了解。上下文和对变更的理解，是高效审查的核心。
这些益处真实存在，但并不能证明拉取请求是最好的交付机制。它只能说明，组织目前依赖审查来完成哪些事情。
Laycock 的反转思路正是从这里开始。她认为，有价值的反馈应更接近它所影响的决策。
替代方案应在某一种方案被完整实现之前讨论。架构边界应在生成代码将某项决策扩散到数十个文件之前达成一致。
知识传递应发生在资深工程师推演问题的过程中。初级工程师从观察权衡如何展开中学到的，比事后阅读完成的 diff 更多。
结对编程提供了一条路径。两名工程师在处理同一任务时共享决策、实现上下文和即时反馈。
群体编程将这种模式扩展到团队。在任何人编写代码，或提示智能体编写代码之前，集体设计会议也能实现类似目标。
这些方法需要时间，但代码审查同样消耗时间。区别在于组织何时支付这项成本，以及对话是否仍能以较低成本改变设计。
自动化检查应处理确定性问题。格式、lint 违规、已知的易受攻击依赖项和可复现的测试失败，很少需要稀缺的高级判断。
适应度函数可以将架构约束编码为可执行测试。适应度函数会持续检查系统是否保留预期的架构属性。
例如，团队可以禁止一个服务导入另一个服务的私有组件。该检查会在审查者收到变更之前运行。
静态分析可以在不执行程序的情况下检测已定义的缺陷模式。安全扫描器可以识别已知弱点、暴露的密钥和依赖风险。
这些系统都不能消除工程判断。它们移除可预测的工作，让人类能够专注于模糊性、系统行为和业务后果。
这种方法也改变了工程团队记录的内容。拉取请求评论很有用，但在数百项已合并变更中，数月后很难重新拼凑出来。
重要的设计推理应存在于持久、可搜索的记录中。团队可以根据设计文档、技术讨论和本地项目材料构建 engineering knowledge base。
目标并不是为了文档本身而增加文档，而是保存未来维护者在事故、迁移和重新设计期间所需的意图。
如果拉取请求是这些意图唯一存在的地方，自动化可能会在改善交付指标的同时，无意中抹去组织的记忆。
真正的对立是普遍审查与例外审查
核心选择在于：每项变更是否都值得人工检查，还是仅检查跨越明确风险阈值的变更。
Laycock 并不主张结束代码审查。她主张按例外进行审查。
在这一模式下，团队会识别哪些情形必须由另一位资深人员检查实现。根本性的架构变更仍然是明确的候选对象。
跨越敏感安全边界的变更应获得人工关注。关键系统内不熟悉的修改，以及潜在影响范围很大的变更，也应如此。
不确定性本身也可以触发审查。如果作者或团队缺乏信心，这一信号就应足以请求另一位知情人士提供视角。
常规且边界明确的变更则会走不同路径。自动化测试、静态分析、政策检查和明确的架构规则会在集成前建立信心。
这直接挑战了普遍审查。许多组织要求每个拉取请求都必须获得批准，无论风险、新颖性或复杂性如何。
普遍审查提供了一项简单政策。它易于解释、衡量，并可通过代码仓库设置执行。
然而，政策层面的简单性可能会给审查者带来不加区分的需求。依赖项更新和新的授权模型都会进入同一条宽泛队列。
团队往往通过非正式的优先级排序来补偿。小变更获得快速批准，而困难变更则等待少数真正理解它们的人。
这种模式可能退化为仪式。审查者在表面检查后批准常规工作，因为队列要求速度。
绿色勾选仍然存在，但其信息价值会下降。强制批准并不能保证审查者理解了变更。
例外审查要求更好的风险分类。团队必须定义哪些系统、文件、变更类型和行为信号值得更严格的审查。
他们也必须接受：被归类为常规的变更仍可能引入错误。没有任何阈值能够消除风险。
Meta 的 RADAR 系统展示了这种模式在相当大规模下的一种实现。RADAR 是 Risk Aware Diff Auto Review 的缩写。
该系统使用资格门槛、静态启发式规则、机器学习风险评分、大型语言模型审查和确定性验证。只有符合条件的低风险变更才能通过自动化流程完成合并。
根据 Meta 的研究，RADAR 审查了超过 535,000 个 diff，并合并了超过 331,000 个。其作者报告称，符合资格的自动化变更具有更低的回滚率和生产事故率。
研究称，经 RADAR 审查的 diff 的回滚率是非 RADAR diff 的三分之一。其报告的生产事故率则仅为后者的五十分之一。
这些比较需要谨慎解读。RADAR 有意选择低至中等风险的变更，而对照组包含了更困难、风险更高的工作。
因此，较低的事故率并不能证明：对于等效变更，自动化比人工审查更安全。它们只能说明，受约束的自动化能够处理一类经过筛选的人群，并取得较为有利的观测结果。
这种区别至关重要。仅对异常情况进行审查，只有在资格规则能够可靠识别常规工作时才会奏效。
团队不能照搬这一亮眼结论，用不受限制的 AI 审查者取代广泛的人工审批。Meta 的部署依赖多重控制措施、丰富的内部遥测数据，以及经过精细校准的阈值。
规模较小的组织可能没有足够的历史数据来估算变更风险。它们的系统也可能拥有更少的自动化测试，或更弱的运营信号。
最重要的启示并不是每家公司都需要自己的 RADAR，而是选择性自动化需要明确边界和证据支撑。
将判断前移，会改变谁在承受压力
资深工程师仍然是瓶颈，但他们的工作会从检查输出转向塑造决策。
普遍审查将压力集中在实现工作的末端。作者等待，审查者切换上下文，变更在熟悉系统的维护者面前不断堆积。
仅对异常情况进行审查，则会将部分压力前移。资深工程师必须参与设计讨论、定义边界，并改进自动化控制措施。
这并不是凭空获得的产能，而是产能的另一种使用方式。
当早期协作能够防止返工、形成可复用的约束时，这种转变才会有效。一条架构规则可以指导许多未来变更，无需反复解释。
如果每项任务都要进行冗长的设计会议，它就会失败。将判断前移不应把轻量级变更变成委员会决策。
团队需要与风险相称的实践方式。一个小型、熟悉的变更，可能只需要清晰的意图说明和通过的检查。
一个新的数据模型可能需要一次简短的设计讨论。跨系统的授权变更则可能需要更广泛的审查和明确的威胁分析。
这种比例把握比统一的审批规则更难。它要求工程领导者理解系统，并建立可信的风险分类。
它也改变了对个人贡献者的预期。作者需要在实现前解释意图，而不只是事后描述已完成的文件。
审查者则需要尽早质疑假设。他们不能依赖最终的 pull request 来挽救一个不清晰的设计。
管理者还面临另一个压力点。当生成式输出增加审查负担和长期复杂性时，吞吐量指标仍可能奖励代码产出。
统计完成的 pull request 可能掩盖转移给维护者的成本。衡量生成代码行数则可能让过度实现看起来很有成效。
AI 在这里带来了特殊的诱惑。工具可能生成超出问题所需的代码，尤其是在提示词只指定结果、却没有架构约束时。
更大的变更更难审查、测试和回滚。它们也会为细微的不一致性创造更多暴露面。
因此，相关的生产力单位不是生成的代码，而是团队依然能够理解和运营的、安全交付的能力。
Microsoft 在 2025 年发布的开发者工作周研究调查了 484 名软件开发者。研究发现，理想与实际工作分配之间的差距越大，生产力和满意度越低。
该研究并未主张仅对异常情况进行审查。但它确实强化了这样一种认识：将开发者时间从他们认为有价值的工作中抽离，是有代价的。
减少重复审查可能有所帮助，但前提是组织将注意力重新投入设计、测试和共同理解。否则，它们只是在为更多代码生产腾出空间。
工具供应商同样面临压力。一个产出更多评论的 AI 审查者，可能增加活动量，却未改善决策质量。
有用的系统必须区分确定性的发现与不确定的建议。它们应说明一项变更为何看似存在风险，并提供人类可以审查的证据。
它们还应保留问责机制。团队需要知道运行了哪些自动检查、哪些发现被忽略，以及谁接受了剩余风险。
没有可追溯推理的 AI 批准，只是另一种队列捷径。它保留了审查的表象，却削弱了其治理功能。
最大的风险，是没有人真正完全理解的软件
当系统增长速度超过团队共同心智模型的形成速度时，更快的集成就会变得危险。
Houck 最有力的反对意见涉及认知债务和意图债务。当软件扩张速度快于负责团队的理解能力时，认知债务便会出现。
当人们逐渐失去架构和实现决策背后的原因时，意图债务便会产生。系统仍在运行，但其设计依据已变得难以追溯。
传统技术债务描述的是让未来变更更困难的妥协。认知债务和意图债务则关注系统行为与人类理解之间不断扩大的差距。
强制审查对此类差距提供了一些保护。阅读队友的变更可以传播认知，并让工程师接触不熟悉的组件。
但这种保护并不完整。一位忙碌的审查者可以在未形成对受影响系统持久理解的情况下批准变更。
大型 AI 生成的 diff 会使问题更加严重。逐行阅读代码，并不能保证审查者理解更广泛的意图或涌现行为。
Laycock 认为，工程师需要理解系统，而不只是理解 diff。这句话概括了反对原封不动保留审查流程的最有力理由。
diff 是文本变更的呈现方式。它不会自动展示运行时依赖、运营后果，或设计背后被放弃的替代方案。
不过，早期协作同样不能保证系统理解。团队可能召开设计会议，却没有留下任何持久记录。
结对编程可能将知识集中在两个人而非一个人身上，却未能将其传播到整个团队。自动化架构检查也可能完美地执行过时的假设。
因此，仅对异常情况进行审查还需要配套保障措施。团队必须保留设计意图、轮换运营责任，并在事故发生后重新审视风险规则。
他们应测试工程师能否在不咨询原作者的情况下解释关键流程。他们还应考察较新的工程师是否获得了对重要决策的有意义接触。
运营所有权之所以重要，是因为生产系统会揭示代码审查无法呈现的关系。应对故障的工程师会了解哪些边界可靠、哪些假设会崩塌。
共同承担值班责任可以分散这种学习。事故后分析可以将个人发现转化为组织知识。
仓库历史仍然有用，但它无法承担全部负担。设计决策应连接需求、约束、替代方案和预期运营行为。
这为 Laycock 的提议构成了一项审慎的检验。如果团队取消常规人工审查，却未加强这些实践，知识流失可能会更快。
即时指标依然可能看起来不错。合并时间会缩短，队列长度会减少，生成的工作会更快进入生产环境。
损害会在之后显现。一次故障、安全调查、员工离职或重大重构，都会暴露缺失的上下文。
这种延迟反馈使认知债务难以管理。组织可以轻易衡量审查延迟，但共同理解难以归结为仪表盘上的单一数字。
代理信号可以提供帮助。团队可以追踪事故期间变更需要原作者介入的频率，或有多少关键组件只有一位了解其细节的维护者。
他们可以考察架构决策是否容易发现，以及审查者是否在质疑实质内容，而非机械式批准。
他们还可以在自动化变更引发故障后进行复盘。目的应是重新校准阈值，而非责怪信任了流程的工程师。
安全的结论比任一极端观点都更有限。强制审查并非充分保护，但取消它也并不自动代表进步。
关键问题在于，替代方案能否在实现之前、期间和之后建立更强的理解。
AI 审查应引导注意力，而非模仿批准
最可信的近期系统，是利用自动化分流风险，同时让人类继续对重要变更负责。
这一立场介于普遍人工审查与不受限制的自动化批准之间。它也为无法立即重新设计工作流程的团队提供了务实的过渡路径。
首先，确定性工具应在人类进入流程之前完成工作。格式化、lint、测试执行、依赖策略和已知安全检查都应属于自动化环节。
其次，AI 可以总结一项变更的目的和受影响区域。它可以识别异常的依赖路径、缺失的测试，以及与既有模式不一致之处。
这些发现应作为证据，而非结论。系统应展示不确定性，并让合格的工程师能够质疑其推理。
第三，风险规则应决定审查路径。涉及安全、架构、影响范围大或不熟悉的变更，应接受审慎的人类审查。
当测试和保障措施提供足够信心时，常规变更可以走更轻量的路径。团队应逐步引入这一流程，并监控结果。
第四，组织应重新安排学习活动，而非假定学习会自动发生。设计会议、结对协作、运营实践和书面决策必须补上常规审查过去所提供的知识。
这一平衡模型更接近 Meta 的做法，而非通用 AI 审查者。RADAR 并非只是询问一个模型代码是否看起来可以接受。
它通过多层机制缩小了适用范围。这种架构承认，单靠语言模型无法可靠地代表生产风险。
这种区别在商业上很重要。许多产品可以在 pull request 上生成评论，但评论数量是一个糟糕的成功指标。
有用的审查者应减少低价值检查，同时增加对重要决策的关注。它还应避免用推测性的发现淹没开发者。
误报会消耗自动化承诺节省的同一种稀缺注意力。反复出现的低质量警告会训练开发者忽略系统。
漏报则带来另一种危险。自动化批准可能制造超出系统实际证据的信心。
因此，团队应针对具体类别评估 AI 审查。他们需要分别获得安全问题、逻辑错误、架构违规和测试缺口的性能数据。
他们还应比较相似的变更。来自预先筛选的低风险 diff 的结果，不能支撑全面取代人工审查的说法。
即使系统自动合并常规变更，人类问责仍然重要。必须有人负责适用资格政策及其运营后果。
这位负责人不必批准每一个 diff。但他们必须确保阈值、例外情况和事故反馈始终相互关联。
正在形成的设计不太像人工队友，而更像空中交通管制员。它将注意力引向人类判断最具价值的情形。
这一角色比假装复现每条人工审查评论的 AI 代理更具可扩展性。它也让这种权衡清晰可见。
三个信号将表明代码审查是否真的在改变
下一阶段将由审查质量、系统理解，以及受控自动化所提供的证据决定。
第一个信号是，组织是否会公布有关自动化低风险变更的可比结果。Meta 已提供了异常详尽的部署数据，但其选择效应仍然值得重视。
其他工程组织也应披露适用资格标准、回滚率、事故情况和审查延迟。可行时，它们应将 AI 生成的变更与人工编写的工作区分开来。
如果多次部署在可比风险组中展现出稳定结果，那么按例外进行审查的做法将获得支持。如果表现依赖于狭窄的内部条件，那么广泛采用就应保持谨慎。
第二个信号是，团队在减少审查后是否衡量对系统的理解。仅凭更快的合并速度，无法验证 Laycock 的论点。
管理者应关注知识集中度、事故恢复、架构漂移，以及对原始作者的依赖程度。他们还应追踪初级工程师是否仍能接触到有意义的技术推理。
如果吞吐量提升的同时系统理解保持稳定，那么将判断前移的理由会更充分。若所有权缺口不断扩大，则表明审查移除的不只是形式流程。
第三个信号是，代码仓库平台和 AI 编程产品如何表达风险。一个通用的批准按钮无法表达选择性自动化所需的置信度层级。
有用的平台将说明某项变更为何符合自动处理条件。它们会保留模型发现、确定性检查、策略决策和人工覆盖记录。
它们还可能将规划工件与生成的变更关联起来。这种关联能让审查者检视意图和约束，而不是从代码中重新推断。
如果工具以评论数量或自动批准量作为竞争指标，行业将用合成审查者复制现有瓶颈。如果它们能够透明地分配注意力，流程才可能真正改变。
Hacker News 上的讨论并未证明代码审查已经过时。它证明的是，随着 AI 产能增长，以同一种方式审查每项变更已不再具备可扩展性。
Laycock 的提议之所以有说服力，是因为它挑战的是判断的放置位置，而不只是判断速度。Houck 的异议依然至关重要，因为审查一直承载着隐性的组织价值。
最终胜出的模式，将在不迫使高级工程师检查不断扩张的常规代码洪流的前提下，保留这些价值。它将自动化可预测的检查，并提升不确定决策的优先级。
工程团队应从一个实际问题开始：哪些变更确实需要另一位人类的判断？又有什么证据支持这种区分？
诚实地回答这个问题，将揭示当前审查策略是在保护软件，还是仅仅在维护一种熟悉的仪式。
