PR已死？AI编程让代码评审成瓶颈，34倍代码量如何应对

当AI智能体涌入软件开发流程，代码生成速度飙升，但一个被忽视的环节正在崩溃：代码评审。一项覆盖718家企业、70万开发者的研究显示，AI编程工具让代码提交量增长约30%，但最终部署量几乎没变，而拉取请求（Pull Request，简称PR）到合并的时间却暴涨49%，从约7天延长到超过10天。更直观的例子来自Anthropic：其每日代码变更量从2500次激增至超过3万次，增幅超10倍。面对如此海量的代码，人工评审早已不堪重负。有开发者甚至宣布关闭PR功能，只接受想法而非代码。PR真的要被淘汰了吗？

AI编程提升代码产量，却卡在评审环节

这份尚未经过同行评议的预印本研究，由哈佛大学的Fiona Chen和James Tretton主导，数据来自工程效能平台Jellyfish，覆盖2021年至2026年间的718家软件企业。研究者对比了AI工具引入前后的工程指标，发现代码生成环节确实效率大增：代码行数增加30%，提交次数增加20%，PR数量增加23%。然而，Jira中记录的任务完成量却没有显著变化。问题出在哪里？

关键在于，从PR创建到合并的周期被拉长了49%。这意味着，虽然写代码变快了，但代码进入主分支前的“审核关”成了新的堵点。研究指出，多数团队仍要求资深工程师进行最终批准，而AI生成的代码往往需要更仔细的审查。一个典型案例是，某团队中一位资深工程师原本每周检查一次初级开发者的代码，AI引入后不得不每天检查，并最终被要求审批所有变更。这位资深工程师成了流程中的“人肉瓶颈”。

预印本（Preprint） 是指尚未经过同行评议、但已公开在预印本平台（如arXiv、SSRN）上的学术论文。它的优点是发布速度快，能让研究者抢先分享最新发现；缺点是未经独立专家审核，结论的可靠性需要读者自行判断。本文引用的哈佛研究即属此类，因此其“PR合并时间延长49%”等结论应视为初步证据，而非定论。读者在参考时，宜结合更多同行评议文献或行业报告交叉验证。

拉取请求（Pull Request，PR） 是GitHub、GitLab等代码托管平台的核心协作机制。开发者完成代码修改后，发起PR请求将分支合并到主分支，其他成员可逐行评论、提出修改意见，通过后由有权限者批准合并。PR不仅是代码合并的技术手段，也承载了代码审查、知识分享和变更记录的功能，因此常被视为代码质量的“守门人”。

当AI批量生成PR，人类评审员何去何从

AI不仅增加了代码量，还改变了PR的性质。过去，提交PR的人至少需要理解代码，这本身构成一道质量过滤网。如今，任何人都可以指挥AI智能体生成大量代码，几秒钟内开出PR，而提交者可能根本没读过AI写了什么。这导致评审员面对的是机器生成的、可能毫无意义的代码洪流。

Anthropic的案例极具代表性：每日代码变更从2500次跃升至超过3万次。试想，如果每次变更都对应一个PR，评审团队如何消化？现实是，很多PR可能被草率批准或直接忽略，代码质量风险陡增。更讽刺的是，部分场景下已经出现“AI生成代码、AI评审代码”的闭环，人类反而被边缘化。

AI智能体（AI Agent） 是指能够自主规划、调用工具并执行多步任务的AI系统。在编程场景中，智能体可读取需求、编写代码、运行测试甚至自动提交PR，而人类只需给出自然语言指令。这与传统的代码补全工具（如早期Copilot）有本质区别：后者是“人写为主、AI辅助”，前者则可能“AI写为主、人只下指令”。这正是PR性质改变的根源——提交者可能从未逐行阅读过AI生成的代码，评审员面对的代码洪流缺乏人类理解作为前置过滤。

激进实验：关闭PR，只接受“想法”

面对这种困境，一位在AI智能体领域知名的开发者（据视频提及名为Huntley）采取了极端做法：在他的GitHub项目中关闭PR功能，只保留讨论区。他的逻辑很直接：评审机器生成的PR价值很低，他真正需要的是“想法”。如果有人提出好点子，他自己调用AI智能体几分钟就能实现，无需接受外部代码。

他以一个具体需求为例：用PR阻止Git的强制推送。他直接写了一个Nix配置文件，将修改应用到本地、Docker和测试环境，全程无需fork或他人批准。这种做法也触及了开源界的旧伤：项目维护者常被道德绑架，被要求无偿接受并维护他人提交的PR。而“remix”模式让想法自由流动，互不亏欠。

Nix 是一个声明式的包管理与系统配置工具，通过纯函数式的配置文件描述整个软件环境，确保本地、容器和测试环境的一致性。文中开发者用Nix配置文件实现“阻止Git强制推送”的需求，正是利用Nix可复现、跨环境一致的特点：写一份配置，即可在本地、Docker和测试环境中应用相同修改，无需他人提交PR。这解释了为何他自信“几分钟就能实现想法”——Nix降低了环境搭建与部署的边际成本，使个人维护者绕开外部代码贡献成为可能。

巨型项目能承受“去PR化”吗？

这种个人项目上的实验，放到大型开源项目上则显得危险。像Linux或React这样影响数百万用户的项目，依赖严格的官方评审来保证安全与稳定。如果每个人都基于自己的想法做“remix”，生态将分裂成无数版本，用户该信任哪一个？谁又能保证某个版本没有植入恶意代码？

视频作者也承认，评审并不会消失，只是转移了位置：从项目名称的背书，转移到用户选择版本时的判断。但这对普通用户而言，门槛太高。因此，更现实的路径可能是PR流程的进化，而非简单废除。例如，利用AI辅助评审、自动化测试和更细粒度的权限控制，将人类精力集中在高风险变更上。

结语：PR不会消失，但必须重塑

AI编程工具带来的效率提升是真实的，但瓶颈转移也是真实的。PR作为代码质量的守门人，其形式可能需要改变，但核心目标——确保代码可靠、安全——不会改变。对于个人项目，关闭PR或许可行；对于严肃的团队和大型开源项目，更务实的做法是重新设计评审流程，让AI承担更多机械性检查，人类专注于架构与逻辑。否则，代码量的洪水只会冲垮评审的堤坝。

你准备好迎接没有PR的未来了吗？