Zed 用 Delta 彻底取代 Pull Requests

Replacing Pull Requests with Delta

▲ 148vquemener101 HN 评论区
Zed 用 Delta 彻底取代 Pull Requests

我们正式推出 Delta 的公开测试版，这是一个专为与 AI 代理协作而生的多人编程环境。上周，我们做出了一个大胆决定：在 Delta 自己的仓库中彻底禁用 Pull Requests，转而完全在 Delta 内部进行构建和协作。与依赖提交和推送的传统工作流不同，Delta 允许你直接将队友邀请到与代理的对话线程中。队友可以看到相同的 worktrees 并在自己的机器上操作，甚至能继续你未完成的代理对话。我们不再让队友的代理去猜测你的决策过程，而是通过 DeltaDB 保留代码演变的完整上下文，实现真正的持续工程化。

Pull requests 是 GitHub 工作流中我们率先抛弃的部分，取而代之的是 Delta thread 以及我们称之为持续工程化的工作方式。
阅读原文 →HN 评论区RSS

HN 评论区

101
  1. ch71r22

    听起来它没有任何 CI 或合并门禁（merge gating）解决方案。这看起来并不能替代 Pull Requests —— 仅仅是一种分享编辑历史的方式。

    我不买账那种说法，即能够追溯导致某行代码的初始 LLM 提示词就能实质性地加速审查。那不过是更高级的 git blame 罢了。审查者仍需自己理解代码。更高级的 git blame 对此并无太大帮助。

    仅仅查看 PR 的最终版本，而不包含所有中间历史，可能反而更好，因为它不会用开发过程中那些半生不熟的思路和假设来分散你的注意力。你只需专注于结果。

    这东西确实有些酷点，但我并不确信它真的有用。我更不确信它能替代 Pull Requests。GitHub 确实不完美，但我觉得这并没有真正解决 GitHub 存在的问题。

  2. pipes

    我第一反应是，这是否意味着，除了和我自己的 agent 对话时感到的职业倦怠外，我现在还得去消费并理解我队友与 agent 的对话？这比一个好的 PR 描述好在哪里？好的 PR 描述能提炼已完成的工作并解释其必要性。

  3. emerongi

    我赞赏 Zed 的创新。

    我喜欢视频中展示的 workflow，虽然我对其中的协作部分不太感冒。我想看到的是同事打磨好的成果，而不是那些杂乱无章的中间过程。不过，显而易见的是，如果你作为审查者拥有这条对话线程，它可以缩短反馈循环——你不必再问同事“为什么这么做？”，然后等待他们把问题转给他们的 AI，你可以自己直接操作，只留下真正重要的评论。有人会说这会剥夺学习机会，这在一定程度上是对的，但这仅仅意味着我们需要以不同的方式培训初级工程师。也许培训不再通过 PR 评论进行，而是转向简短的电话会议或办公室闲聊。这其实挺不错的。

    有一些负面评论，但事实是这个行业正在发生变化，Zed 作为一家公司必须抓住这一机遇。他们需要赚钱，指望传统的代码编辑器在未来还能盈利无异于自杀。

    他们带来的创新令人兴奋且新颖，尽管我不确定最终结果会如何。

  4. zndbzbz

    这看起来是对当前 PR 流程的一个很酷的增强，但从根本上说，我看不出有什么办法能绕过阅读代码这一环节？审查应该以阅读代码为核心进行优化。Agents 使得创建人类可读的逻辑工作块变得非常容易，这些工作块易于理解且可测试。你作为开发者的工作，就是让你的队友（以及未来的自己）轻松理解你的改动在做什么——毕竟我们都知道，Claude 能用 1000 个字说清的事，10 个字就够了。

    另一方面，我合作过的那些高效团队其实并不需要 PR 审查。工作在实际发生前就已经讨论过了，所以等到 PR 审查时，基本只是走个过场（rubber stamp）。Agents 并没有改变这一点——除非你根本不读代码。PR 审查主要是为了让新加入的开发人员快速上手。信任能让你跑得飞快。

    > 但代码背后的决策仍需审查。较小的 diff 无法提供这种上下文

    也许这部分看起来不对劲？是的，它们确实能提供。你在优化 PR 以节省审查者时间时，会写出这个小改动旨在达成的目标。这可能只是文字、一个文档链接、一个原型链接等等。

  5. kettlez

    我已经使用 Delta 的 beta 版几周了，用它来进行审查比直接在 PR 上审查有了巨大的提升。能够跳进队友的对话线程，查看某样东西是如何被创建出来的背景，并能就此提问，这非常好。产品目前还有一些粗糙的地方，但他们前进的方向相当有趣。

  6. tyingq

    它会暴露我所有的“天哪 Claude，你到底为什么要那样做？现在就回滚，改成 x”吗？

    也就是说，它是否会修剪掉那些通向最终结果的无意义路径？很难想象他们实际能审查到什么。

  7. FinnLobsien

    我认为朴素的 PR 绝对不适用于这个软件时代。

    它过去代表的是已完成的工作，意味着“这就是我解决这个工程挑战的方式”。

    团队成员通常能回答关于该 PR 的问题，解释为什么选择这种方式而不是其他方式，说明被弃用的方案等。

    但现在，很多推理过程都发生在 AI 编程 agent 中。因此，即使做出了方案选择，提交 PR 的人类往往对每个权衡和每行代码的理解深度都不如从前。

    这一点（加上瞬间生成海量代码的便捷性）使得每个 PR 的意义都降低了。

    我不确定我是否想看同事的 AI 聊天记录（谁有时间看那些？），但很高兴看到创新正在发生。

  8. Robdel12

    天哪，我就是不想看别人的 LLM 对话。那些不是产物，改动才是。这就像把你的 Slack 聊天记录附在队友的“PR”后面一样。

同日更多故事

2026-09-18