Zed 上周做了一件事：把自己仓库的 PR 关掉了。团队日常开发全部搬进一个叫 Delta 的新功能里完成。这不是概念演示，是真实团队已经在跑的流程。

试用者 Viking 记录了自己的体验。他的判断很直接：PR 这套合并代码的方式，对 Agent 已经非常不友好。

问题出在 diff 上

AI 写代码又快又多，一次改动就是一大坨。打开 PR 面对海量 diff，人很难看进去。更麻烦的是，当时和 AI 怎么讨论的、为什么这么改，这些信息在 PR 里看不到。

结果就是评审只剩下结果，过程丢了。改动越大，丢失的上下文越多。

Delta 换了个思路：开发一个功能，就开一个 thread。

边聊边改，队友随时进来

在 thread 里，人和 Agent 围绕同一份代码边聊边改。队友可以随时进入同一个房间，看到同一份正在修改的代码，类似多人实时在线协作。

代码改好之后，再开一个子 review thread。这个子 thread 带着原来的对话上下文，也带着一份隔离副本。评审、修改、再合回，全程带着上下文进行，同样支持多人协作。

中间还加了一层 DeltaDB，记录两个 commit 之间发生了什么。增量改动、人或者 Agent 的消息，都随着 thread 留下来，代码演化的流程被完整保留。

为什么值得关注

PR 诞生于人类写代码的时代，它的假设是改动量可控、评审者能读完 diff。Agent 把这个假设打破了：改动量不再可控，讨论过程也不再发生在 PR 里。

Delta 的做法是把讨论和代码放回同一个容器。评审者看到的不只是最终 diff，还有这段代码是怎么一步步变成现在这样的。

Viking 把这种工作流叫做 continuous engineering。使用方式上，可以用 Zed 订阅、ChatGPT 或 Grok 订阅，也可以 BYOK。

一家公司关掉自己的 PR 系统，用自家产品跑日常开发，这个动作本身比功能说明更有说服力。至于这套流程能不能推广到更多团队，还得看后续。