再见Pull Request！Zed推出Delta，替换Github搞代码协作

不知道大家有没有这种日常体验：改完代码，commit、push，点开GitHub新建PR，贴上描述，@同事过来做Code Review。这套流程我们已经用了十几年，几乎刻进了每个开发者的肌肉记忆里。

但现在AI Agent写代码越来越猛，老的PR流程，开始暴露出不少别扭的地方。最近Zed正式放出了Delta公开Beta版，他们玩得更激进：自己项目仓库直接把Pull Request功能关掉，全程不用PR做开发协作。

先声明：它不是要彻底干掉Git，更不是一个简单编辑器插件，是一套面向人和AI Agent协同编码的多人开发环境。

传统PR模式，遇上AI时代有点水土不服

PR诞生距今已经超过15年，毫无疑问是代码评审的行业标准。整个链路逻辑是：写完代码提交推送 → 生成变更Diff → 别人看快照做评审 → 修改提交再更新PR → 合并进主分支。

放在纯人工写代码的年代，这套体系很好用。但现在大量代码由AI Agent生成，事情就变味了。

我自己日常也经常用Agent改代码，遇到过很真实的痛点： Agent一顿输出，噼里啪啦改完几十上百行。我简单核对一遍，确认没问题就提交，生成一个巨大diff丢进PR。 同事点开PR，只能看到最终的代码结果。Agent中间纠结过哪些方案、放弃了什么写法、为什么选Mutex而不是RwLock，这些思考过程全部消失了，只剩下冷冰冰的最终代码快照。

reviewer拿到一大片改动，只能靠自己猜当时是怎么思考的。实在看不懂，就丢给另一个AI帮忙解读diff。相当于reviewer的AI，要重新还原一遍当初已经走过一遍的推理，纯纯重复劳动。

就算把大PR拆成一堆小分支堆叠，diff是变小了，但产生代码背后的决策上下文依旧丢了。小diff不等于完整背景信息。

为什么reviewer这边的AI，还要费劲去猜你当初是怎么写出这段代码的？

PR这套模式本质是「事后评审」。所有讨论，都是代码写完提交之后，附着在快照diff上面。代码一改，很多行评论直接失效错位。沟通和代码，天生就是两套东西。

Delta

Delta给出的解法很反直觉：协作不需要等到你commit、push代码之后才开始。

核心单元不再是PR，而是Thread（线程）。你和AI Agent的整个对话、一次次修改代码的全过程，全部装在这个Thread里面。

你干活的时候，直接把同事邀请进这个Thread。同事不需要等你提交代码，加入进来就能看到完整的工作树，看到你和Agent的全部聊天记录。

同事能干什么？

• 直接看Agent所有历史输出，明白每一处改动背后的思路；
• 直接去问当初写代码的Agent：你这里为什么选这个锁？
• 就算你下班关机，同事还可以接着这个Thread，让Agent继续往下干活，接力开发。

评审流程也换了模式： 评审者进来之后会拿到一份隔离副本工作树，随便折腾、改代码、调用Agent做实验，完全不会干扰原本的工作内容。发现bug，既可以直接提修改要求，也可以直接叫Agent就地修复。评审阶段产出的修复，可以直接合并回原始Thread，最后再让Agent把变更正式合入主分支。

简单说：想法、编码、评审、合并，全部在同一个Thread里面闭环完成，不用来回切换页面开PR，官方称之为「持续工程 continuous engineering」。

底层DeltaDB：记录commit之间发生的一切，兼容Git

Delta底层存储叫DeltaDB，不是完全从零推翻Git，而是做扩展增强。

Git只保存commit那一刻的代码快照。至于两次提交中间，反复修改、Agent试错、来回调试的中间过程，Git是不会记录的。很多人都说一句很有意思的话：真正的软件开发，发生在两次commit之间。

DeltaDB就专门负责保存commit间隙的全部增量改动，把每一次编辑操作、人类和Agent的对话全部绑定留存。commit依旧保留，作为对外推送、CI构建的检查点；DeltaDB保管那些快照之外完整演进过程。

最重要一点：不用强迫整个团队全体迁移到Delta。

举个例子，Zed主仓库还留在GitHub，社区用户照常提Issue、提交PR。内部开发者可以在Delta里面完成协作，最后还是输出标准Git提交推到GitHub。完全没用过Delta的同事，看到的还是普普通通的Git仓库，毫无感知。新旧两套工作流可以并行。

他们的野望：挑战GitHub的部分工作流

现在不少新项目都说要替代GitHub，大多只是换个界面，底层依旧是分支、commit、diff这套老一套原语。

Zed的思路不一样，他们认为未来软件开发的基础单元应该是Thread线程，而不是PR。PR是他们第一个抛弃的工作流环节。

长远目标，不仅仅替代PR，未来会逐步补齐Git存储、内置CI校验等能力。现阶段，变更正式合并前，依旧可以调用外部CI服务跑流水线，拿检测结果。

当然，现阶段只是公开Beta，很多能力还在路上。他们内部33个人已经关掉PR，靠Delta往main分支合入了570次改动，已经拿来当做日常主力工具。

实际怎么上手？

现在公开Beta版本完全免费。 支持Windows、macOS、Linux客户端，也有网页版不用下载软件，手机浏览器也能查看Thread进度。后续会推出个人和团队付费套餐，但会永久保留免费版本。

下载Delta，拉起Agent，拉上队友进到同一个Thread，就可以体验这套新协作模式。

下面来看看使用Delta的一般流程

一开始你跟AI聊天，让AI写代码

评论AI的做法，让AI沿着你的想法演进

很快AI给出结果，你瞄一眼结果 对于需要使用页面呈现的结果，你也可以让AI给你图形化展示 等一会它也给你了结果 此时感觉还不错，我们就开始吧现在的结果分享给产品经理来看看，点击右上角的Share就可以分享 此时你开始跟产品进入聊天模式 开始一问一答，需要展示的效果也在聊天记录里面，简单直接 可以使用右上角的缩小放大按钮来切换聊天+看代码还是只是看代码 还可以再左上角查看上一轮的AI修改 可以对当前的代码进行AI提问 改完之后，开始让技术经理来code review，点击右上角的眼睛

完了之后，点击submit review里面的approve

然后就拉取刚才通过的更改 接着开始提交到git

用完delta，我并不会觉得PR马上就要彻底消失。

PR之所以十几年屹立不倒，不光是技术好用，也兼顾流程管控、权限、审计、外部开源社区交互。GitHub PR生态沉淀的工具、机器人、工作流，不是短时间能全部替代。

但Delta确实戳中AI时代一个真实痛点：

Agent生成代码太快，大量思考和试错过程在commit瞬间被丢弃，评审只能对着最终结果猜意图。

• ✅ 如果项目重度使用AI Agent开发，团队内部闭环协作，Delta这种线程模式价值很高，完整保留全部上下文；
• 如果面向广大外部开源贡献者，对外交付还是离不开Git与PR作为交互接口。Delta也明确说了可以和PR共存。

最后

这么多年，我们已经习惯了「先提交代码，再开展评审沟通」。Delta反过来尝试把沟通对话本身，当成软件开发一等公民。

未来不见得所有团队都会抛弃PR，但随着Agent大规模介入写代码，类似的协作思路，一定会越来越多出现。

说不定几年之后，我们的开发流程，真的会发生不小的变化。