GitHub 负责人说 PR 不该是必选项：Agent 起草的 PR 半年从 17% 涨到 40%

Pull Request 大概是过去十五年里最成功的协作发明之一：改代码先开分支，提 PR，等人审，合并。它把「谁能改什么」变成了可追溯的记录。但当写第一版代码的人从人类变成 Agent，这套流程的前提开始松动。GitHub 自己的负责人，已经不在所有项目里使用 PR 了。

一分钟速览

• GitHub 负责人 Jay Parikh 认为 PR 不应成为所有开发者必须遵循的流程，个人实验项目可以跳过。
• GitHub 数据显示，截至今年 9 月，平台超过 40% 的 Pull Request 由 Coding Agent 起草首版，今年 3 月这一比例仅为 17%。
• 半年内 Agent 发起的 PR 数量增长约 6 倍。
• Parikh 提出 Copilot Harness 与 Copilot Fusion 分工：前者接入模型与工具并编排流程，后者按任务选模型。

40% 这个数字意味着什么

半年从 17% 涨到 40%，接近 2.4 倍，对应绝对量约 6 倍增长。也就是说，GitHub 上如今每五个 PR 里有两个的第一版代码不是人写的。审查者的角色随之改变：过去审的是「同事的思路对不对」，现在更多是「Agent 有没有理解需求、有没有引入看不见的副作用」。

这两种审查消耗的注意力完全不同。人手写的代码通常有惯性，风格、边界处理、错误处理都能从上下文推断；Agent 写的代码可能整体漂亮，却在某个异常分支上悄悄改变行为。审查成本并没有因为 AI 写代码而下降，只是从「写」转移到了「读」。

PR 不是银弹，也不该是教条

Parikh 的表态并不是要废掉 PR。他区分的是场景：大型企业离不开代码审查、权限管理与变更记录；而个人用来验证想法的项目，开分支、提 PR、等人 review 纯属自找麻烦，直接改代码继续开发更合理。他的主张是让这些机制变成可配置，而不是由平台替所有开发者决定默认值。

这个观点其实呼应了社区里较早的讨论。有开发者提出 PR 或许会走向终结，理由是在 Agent 可以随时生成、随时回滚的环境里，「合并」这个动作的意义被削弱了。Parikh 的回应更温和：GitHub 会跟着开发范式调整平台，如果某项功能对部分用户不再有用，就让它可选。

多模型协作的真实成本

访谈里另一个具体问题是模型选择。不同任务的算力需求差异很大：改个文案只需要快而便宜的模型，复杂调试和架构调整才需要强推理，甚至多个模型接力。GitHub 的方案是把选择权部分交给系统——Copilot Harness 负责接入模型与工具、编排开发过程，Copilot Fusion 根据任务挑模型。

Parikh 也承认代价：更多模型参与意味着更多调用、更长耗时、更高的 AI 积分消耗。这与前面 Scout 那类专用小模型的思路殊途同归——真正难的不是让 AI 写代码，而是在质量、速度、成本之间找到可接受的平衡点。

别指望 AI 把维护成本也省掉

访谈中还有一个被很多人忽略的提醒。既然 AI 能快速生成代码，团队能否用它重写大量开源依赖，以降低供应链风险？Parikh 的回答是：即使 AI 能替你重写，后续维护工作也不会凭空消失。重写只是把「依赖别人」换成了「自己养」，代码行数变少了，责任变多了。

这大概是这轮 AI 编程热潮里最需要被重复的一句话。工具把写代码的边际成本压到接近零，但理解系统、承担后果、长期维护的成本并没有跟着下降。PR 流程会不会消失可以再讨论，审查这件事本身，短期内还找不到替代品。