AI 真的会杀死 Pull Request 吗?

AI 真的会杀死 Pull Request 吗？

这两天，海外 AI 圈里有个很抓人的标题：

RIP Pull Requests (2005–2026)

看到这种标题，第一反应当然会觉得有点夸张。

Pull Request 怎么会死？

它几乎是过去二十年软件协作的基础设施之一：开发者写完代码，发起 PR，同事 review，改完再合并。

这一套流程不只是工具习惯，几乎已经成了现代软件工程的“礼仪”和“制度”。

但问题就在这里：

AI 的出现，改的从来不是某一个按钮，而是按钮背后的分工逻辑。

如果一个模型已经不只是“补全代码”，而是能在本地理解上下文、调用工具、读文档、跑测试、修改代码、记住你的偏好，甚至自己发现问题再修掉——

那 PR 这件事，就真的开始变味了。

Pull Request 之所以重要，不是因为它优雅，而是因为人不够快

很多人把 PR 理解成“协作规范”。

但更底层一点看，它其实是一种组织补丁机制。

因为人写代码会出错，

因为多人协作会失真，

因为提交到主分支的风险很高，

所以需要一个中间层，让另一个人来检查：

这段代码有没有 bug
有没有破坏风格一致性
有没有引入安全问题
有没有偏离需求

也就是说，PR 的核心价值，从来不是“开个页面讨论几句”，

而是：它承担了质量控制和责任转移。

在没有 AI 的时代，这是很自然的。

因为机器不会理解业务，也不会自己验证结果，所以只能靠人来 review。

但现在这个前提开始动摇了。

当 AI 不只是写代码，而是开始接管“自检”环节

最近 OpenAI 更新 Codex 的方向就很有意思。

它已经不是单纯的代码生成器了，而是在往一个完整 agent 工作台推：

能用电脑、能浏览、能记忆、能接插件。

这意味着什么？

意味着模型开始从“帮你写一段代码”，

走向“帮你完成一个任务闭环”。

这一步的意义非常大。

因为一旦 AI 不只是写，还能：

读仓库上下文
理解已有约束
跑测试
根据报错继续修
对结果做初步验证

那它就在吞掉原本属于 PR 的一部分功能。

注意，这里最关键的不是“AI 写得更快”，

而是AI 开始自己承担一部分 review 前的纠错成本。

以前开发流程像这样：

开发者写代码 → 提交 PR → 人工 review → 改 → 合并

以后越来越像这样：

开发者描述目标与约束 → AI 完成实现并自测 → AI 做第一轮静态/逻辑检查 → 人类只 review 高风险差异 → 合并

你会发现，PR 没有立刻消失。

但它的含义已经变了。

它不再是“让另一个工程师逐行替你找错”，

而更像是“一个最终的治理和批准节点”。

真正要被削弱的，不是 PR 这个界面，而是“人工逐行 review 的中心地位”

这才是很多人没想清楚的地方。

大家一看到“PR 要死了”，就会下意识反驳：

不可能，代码总得 review。

对，代码当然还要 review。

但 review 的对象、方式和重心，可能已经不是过去那一套了。

过去的 review 很大程度上是在做低层工作：

拼写和命名对不对
逻辑有没有明显漏洞
测试有没有漏
代码风格齐不齐

这些事情，本质上都适合被机器接手。

而且不是未来适合，是现在就已经越来越适合。

所以接下来真正变化的，不是“还要不要 review”，

而是：

人类 review 的内容，会从代码细节，往约束、架构、风险和业务判断上移。

也就是说，未来最值钱的工程师，不一定是最会在 PR 里抓小毛病的人。

而是最会定义：

这次改动到底要解决什么问题
哪些约束不能破
哪些风险必须被拦住
什么叫“通过”，什么叫“不能上线”

这其实很像软件协作的一次重心迁移。

从“人亲自做每一步检查”，变成“人设计检查系统，让系统先替自己做大部分低层判断”。

这也是为什么 Latent 这种讨论值得看

像 Latent Space 这类内容的价值，不在于它标题抓眼球。

而在于它会逼你意识到：

AI 改写软件开发，不只是让程序员多一个助手，

而是在动整个协作系统的默认结构。

以前大家总把 AI coding 当成一个效率工具问题：

“写代码快一点”“改 bug 快一点”“少写样板代码”。

但真正大的变化从来不是效率提升 20%，

而是**组织流程被重新切分**。

谁负责生成？

谁负责验证？

谁负责批准？

谁来定义边界？

谁来对错误负责？

这些问题一旦被重写，PR 就不再只是一个工程界面，

而会变成一个时代分界点：

它代表的，是“人工协作时代的软件质量控制方式”。

所以当人们说“RIP Pull Requests”的时候，真正想说的其实不是“GitHub 上那个按钮没了”。

而是：

过去那种默认依赖人类逐步接力的软件生产方式，开始不再是最优解。

对公司、工程团队和创作者来说，这意味着什么？

如果你是公司管理者，这意味着你不能再只把 AI coding 看成“给工程师配个更强编辑器”。

你真正要思考的是：

现有研发流程里，哪些环节可以被 agent 化，哪些必须保留人类批准权。

如果你是工程团队负责人，这意味着你以后搭流程时，重点可能不是“review 更仔细一点”，

而是“怎么把测试、静态检查、回归验证、风险分级做成自动闭环”。

如果你是开发者，这意味着你的竞争力会慢慢从“我手写代码很熟练”，

转向“我能不能定义好任务、约束、验证标准，并且知道什么时候信 AI，什么时候不信”。

如果你是内容创作者，尤其是写 AI 和科技行业的人，

这件事更值得关注。

因为它透露出一个非常清晰的信号：

AI 对行业的改变，已经从“生成内容”进入“重构协作制度”。

这比任何一次模型榜单变化都更值得写。

最后一句

所以，Pull Request 会死吗？

我觉得不会，至少不会字面意义上死。

但它会被降级。

它会从“协作核心环节”，

慢慢变成“治理链条里的最后一道确认动作”。

真正正在崛起的，不是“没有 PR 的世界”，

而是一个新范式：

AI 负责生成与初步验证，人类负责定义边界、审查高风险决策，并为最终结果背书。

这才是“RIP Pull Requests”这句话真正刺中的地方。

一句话结论

AI 不会让 PR 立刻消失，但会让“人工逐行 review”失去过去那种无可替代的中心地位。

如果你喜欢这版味道，我下一步就能继续两种做法：

一种是我把它再打磨成更像正式公众号可发版；

另一种是我再从这轮扫描里换一个题，给你做第二篇样稿。