Zed 用 Delta 彻底取代 Pull Requests
Replacing Pull Requests with Delta
我们正式推出 Delta 的公开测试版，这是一个专为与 AI 代理协作而生的多人编程环境。上周，我们做出了一个大胆决定：在 Delta 自己的仓库中彻底禁用 Pull Requests，转而完全在 Delta 内部进行构建和协作。与依赖提交和推送的传统工作流不同，Delta 允许你直接将队友邀请到与代理的对话线程中。队友可以看到相同的 worktrees 并在自己的机器上操作，甚至能继续你未完成的代理对话。我们不再让队友的代理去猜测你的决策过程，而是通过 DeltaDB 保留代码演变的完整上下文，实现真正的持续工程化。
Pull requests 是 GitHub 工作流中我们率先抛弃的部分，取而代之的是 Delta thread 以及我们称之为持续工程化的工作方式。
HN 评论区
52- the__alchemist
我对他们的编辑器和 GPUI 已经彻底失去信心了——Zed，你本是我们唯一的希望！他们现在满脑子都是 AI。我原本以为这篇文章会讲一个通用的 git 替代品，结果它讲的是那种在我看来毫无逻辑的、以 LLM 为中心的编程方式，因为它人为地划出了一条人类编写的代码和 LLM 编写的代码之间的界限，而这条界限在现实中根本不存在。
他们的主打产品 Zed 编辑器对我来说（以及其他许多人）根本无法使用，因为它在处理磁盘文件同步时管理得一团糟——当发生外部编辑时，编辑器会保留过时的状态，除非你关闭并重新打开该特定文件（甚至连重新打开编辑器本身都无法同步）。这存在你的更改被静默覆盖或发生冲突的重大风险。有趣的是，当文件被异步修改时，这种风险反而增加了，而对我来说，这种情况大多是由拉取操作或 LLM 编辑引起的！
这不禁让人要问：“如果编程方式已经改变到我们需要使用以 LLM 为中心的源代码控制工具，那为什么 LLM 无法修复我们软件中那些有闭式解的严重 bug？”
- pipes
我第一个念头是，这是否意味着除了我自己与 agent 对话时感到的倦怠之外，现在我还得尝试去消费并理解我队友与 agent 的对话？这比一个好的 PR 描述好在哪里？好的 PR 描述能提炼已完成的工作并解释其必要性。
- kettlez
我已经使用了 Delta 的测试版几周了，用它来进行审查比直接在 PR 上审查有了巨大的提升。能够跳进队友的对话线程，查看某项功能是如何创建的上下文，并能够就此提出问题，这非常好。产品目前还有些粗糙的地方，但他们前进的方向相当有趣。
- tyingq
它会暴露我所有的“天哪 Claude，你究竟为什么要那么做？现在立刻回滚，改成做 x”吗？
也就是说，它是否会剪除那些对最终结果没有意义的路径？很难想象他们实际审查到的是什么。
- zndbzbz
这看起来像是当前 PR 流程的一个很酷的增强，但根本上我认为无论如何还是得读代码？审查应该以此为优化目标。Agent 让创建人类可消化的、易于理解和测试的逻辑工作块变得非常容易。作为开发者，你的工作是让你的队友（以及未来的自己）轻松理解你的更改在做什么——因为大家都知道，Claude 能用 10 个字说清楚的事，它非要用 1000 个字。
另一方面，我合作过的高绩效团队其实并不需要 PR 审查。工作在执行前就已经讨论过了，所以等到 PR 审查环节时，往往只是走个过场。Agent 并没有改变这一点——除非你根本不看代码。PR 审查主要是为了让新开发者跟上节奏。信任能让你跑得飞快。
> 但代码背后的决策仍需审查。较小的 diff 无法提供这种上下文
也许正是这一点让人觉得不对劲？不，它们确实能提供。你在优化 PR 以节省审查者时间时，会写出这个小改动旨在达成的目标。这可能只是纯文本、一个文档链接、一个原型链接等等。