Zed 推出 Delta：用共享线程替代 PR

从禁用 PR 说起

代码编辑器 Zed 做了一件在开源圈颇为激进的事：它在自己的代码库上关闭了 Pull Request（PR）流程。这不是一次内部实验，而是为一款新产品铺路——Delta，目前处于公开测试阶段。

Zed 团队给出的判断很直接：当 AI 代理（agent）开始大量参与写代码，GitHub 那套以 PR 为核心的评审模型，正在变得不再合身。

为什么 PR 对代理不友好

PR 的设计前提是「人写代码、人审代码」。它假设：

• 一次改动有明确的作者，改动是离散的提交；
• 评审者会阅读 diff、留下评论、批准或要求修改；
• 合并是一个有仪式感的终点。

但当代理参与进来，这些前提开始松动。代理可能持续、小步地改动代码，人类更多是在监督和引导，而不是逐行审批。把这种协作硬塞进 PR 的「提交—评审—合并」流水线里，会产生大量摩擦：评审队列堆积、上下文丢失、反馈回路变长。

Delta 的赌注：共享线程

Delta 的核心思路是用共享线程（shared threads）取代 PR。与其开一个待评审的合并请求，不如让人类和代理在同一个线程里围绕代码变更持续对话。

这意味着协作的重心从「审批一个变更」转向「维护一段上下文」。对开发者来说，实际差别在于：

• 反馈更即时：代理的改动和人的意见在同一处流动，不需要等 PR 走完流程；
• 上下文更连续：线程保留了讨论的历史，而不是散落在多个 PR 评论里；
• 更适配代理节奏：代理可以高频迭代，线程天然容纳这种非线性的推进方式。

对谁有价值

重度使用 AI 编码代理的开发者是第一批受益者。如果你已经习惯让代理改代码、自己只做方向性把关，Delta 的线程模型比 PR 更贴近你的真实工作流。

团队协作场景同样值得关注，尤其是那些评审流程已经因为代理产出量上升而拥堵的团队。把评审从「逐 PR 把关」转向「线程内持续对齐」，可能降低流程负担。

工具链建设者则应留意这个信号：Zed 敢于在自家代码库上停用 PR，说明它对这个方向有真实信心，而不是营销噱头。

实用解读：现在能做什么

Delta 还在公开测试阶段，稳妥的做法是：

1. 先观察，别急着迁移。把 Delta 当作一个需要验证的假设，而非立刻替换现有流程的方案。
2. 在小范围试验线程式协作。挑一个代理参与度高的模块，试试不用 PR、改用共享线程来推进改动。
3. 保留回退路径。GitHub 的 PR 生态成熟，短期内不必全盘放弃，关键是评估线程模型在哪些场景真正省事。

更大的背景

Zed 的举动呼应了一个正在蔓延的判断：GitHub 的协作范式是为人类评审者设计的，而代理时代的协作需要新的原语。Delta 是否成功尚待时间检验，但它提出的问题很实在——当写代码的一方越来越多是代理，我们还需要 PR 吗？