Zed 的 Delta 进入公开测试：他们把自己仓库的 Pull Request 关掉了

Zed 发布了 Delta 的公开测试版，一个把「和智能体一起写代码、并评审它们的产出」放进同一个多人环境的产品。最有说服力的动作是：上一周他们关掉了 Delta 自己仓库的 Pull Request，现在完全在 Delta 里开发和协作。它的协作不依赖提交与推送——你把队友直接邀请进与智能体的对话里，对方能看到同一批 worktree，并在自己机器上继续工作，也可以直接问同一个智能体「为什么这里用 Mutex 而不是 RwLock」；你下线后，队友能接着在原来的位置继续。评审被组织成专门的子线程，带着原始智能体的上下文引导你看完分支改动，每个评审拿到父线程 worktree 的隔离副本。底座是 DeltaDB，与 Git 兼容，提供 macOS、Linux、Windows 客户端与网页版，也能用移动浏览器跟进线程。官方的理由是：智能体生成的代码量上来了，需要互相评审的 diff 越滚越大，把大 diff 拆成栈式分支只是让导航更容易，评审真正需要的是决策背后的上下文。

他们先关掉了自己的 PR

Zed 发布 Delta 的公开测试版，并给出一个很有说服力的动作：上一周，他们把 Delta 自己仓库的 Pull Request 关掉了。现在这个项目完全在 Delta 里开发和协作，官方的说法是「Pull Requests are seriously turned off」。

为什么要动这个沿用 15 年的默认约定？他们的理由很直接：智能体生成代码的量已经上来了，我们要互相评审的 diff 越滚越大；把大 diff 拆成栈式分支只是让导航更容易，而评审真正需要的是决策背后的上下文，更小的 diff 提供不了。你也可以把 diff 丢给另一个智能体帮忙理解，但那个智能体得自己拼出你已经想清楚的决策——你的队友的智能体为什么要重新猜一遍。

协作不再以提交为边界

Delta 的做法是把队友直接邀请进与智能体的对话。加入线程后，对方看到的是同一批 worktree，可以在自己机器上继续操作；即使你下线，他们也能接着和智能体往下做。评审被组织成专门的子线程，带着原始智能体的上下文引导你看完分支改动，每个评审还拿到父线程 worktree 的隔离副本，方便你和队友各自用智能体继续处理。

底座是 DeltaDB，与 Git 兼容，客户端覆盖 macOS、Linux、Windows，也提供网页版与用移动浏览器跟进线程的方式。换句话说，它没有要求你放弃 Git，只是把协作发生的层面从「提交与推送之后」挪到了「对话与工作树之中」。

值得先试的三件事

先在一个小仓库、一条线程上跑通完整流程：修一个 issue、请队友评审、合并，确认团队的评审习惯能不能接受「上下文优先于 diff」；
把评审的隔离副本用起来：在评审线程里做实验性改动不会污染主工作树，这一点比传统分支更省心；
确认落地边界：协作依赖会话与工作树共享，团队要不要把敏感仓库放进来、如何做权限划分，需要先定规则再铺开。

需要客观看待的是，这套流程成立的前提是队友愿意进入你的会话，以及团队接受「评审单元从 diff 变成线程」。对已经在用智能体批量产出的团队，这个交换大概率划算；对以人工小步提交为主的团队，迁移收益要自己算。