黄奕彬

外部精选

Replace PRs with Delta – Now in Public Beta

本文来自外部来源,不是黄奕彬的原创文章。本站提供原文入口,并在采集端生成 AI 结构化摘要、解读与中文翻译(如有),一切以原文为准。

阅读原文(zed.dev)
来源
Zed Blog ↗
作者 / 署名
Nathan Sobo、Nathan Sobo
发布日期
本站收录时间
原文域名
zed.dev

以上时间均为北京时间;来源更新时间由来源提供,不代表首次发布时间。

结构化摘要 AI 生成

背景与问题

背景与问题:AI agent 正在大量生成代码,但协作工具没有跟上。pull request 作为 GitHub 引入 15 年多以来的标准审查方式,在 agent 产出大量代码的背景下,待审 diff 急剧膨胀(原文用 mushroomed)。

拆分分支栈只能缓解导航问题,代码背后的决策上下文仍然缺失,审查者的 agent 只能重新拼凑作者早已想清楚的决定。文章面向需要审查 agent 产出代码的开发者与团队。

方法或内容

内容与做法:Zed 团队发布 Delta 公开测试版——一个与 agent 共同编码并审查其产出的多人环境,并宣布上周已在 Delta 自身仓库禁用 pull request,完全在 Delta 内开发协作。

文章包含:1. Delta 工作方式(邀请队友进入与 agent 的对话线程、共享 worktree);2. 无 PR 的代码审查(review subthread);3. 技术基础 DeltaDB(兼容 Git);4. 与 GitHub 共存的迁移路径;5. continuous engineering 愿景与公测获取方式(macOS、Linux、Windows、Web、移动浏览器)。

文中提及 Richard Feldman 演示了一个端到端流程。

关键发现 / 结果

关键结果与变更点:

  • 数据:禁用 PR 后,33 名成员已向 main 落地 570 个变更(自报数据)。
  • 定价:公测期间免费;将推出个人与团队付费计划;承诺永远有免费版本。
  • 技术机制:DeltaDB 扩展 Git 的 content-based versioning,基于 delta 的增量版本记录 commit 之间的编辑及人类与 agent 的消息;commit 仍是 push、pull、build 的检查点,DeltaDB 保留检查点之间的工作。
  • 审查机制:每次 review 获得父线程 worktree 的隔离副本;审查中的修复可在落地前并入父线程。
  • 共存:zed-industries/zed 暂留 GitHub,鼓励贡献者在 PR 旁分享 Delta 线程;不打开 Delta 的队友看到普通 Git 仓库。
  • CI:agent 目前可调用现有 CI provider 触发运行并在落地前查看结果。

结论与意义

结论与意义:作者主张 threads 将成为软件开发新的基本单元,最佳建模方式是 deltas;pull request 是被放弃的第一部分 GitHub 工作流,替代品是 Delta thread 及 continuous engineering——想法、实现、审查、落地发生在同一处。

适用边界:作者明言 Delta 仍在形成中,最受关注的部分能力尚未完成;也未承诺立即替代 GitHub.com,其他工作流的替代方案(始于 DeltaDB 的 Git 存储)仍在构建中。

AI 解读 AI 生成

方法:按「时空变量」分析(时间 / 空间 / 变量,严格区分包含、相关与因果),对象包括原文作者、署名人员与关键技术及其实际原理;结论用「元反空」(元思考、反思考、空思考、综合)整理。

时间:何时发生,现在是否仍成立

时间:来源日期为 2026年9月16日(UTC 2026-09-16T00:00:00,即北京时间 2026-09-16 08:00)。文中『今天』指启动公开测试,『上周』指在自家仓库禁用 PR,『过去一周以来』未出现其他时间锚点。

现在是否仍成立:平台支持、DeltaDB 机制等产品事实短期内可能仍成立;但『公测期间免费』『即将推出付费计划』『最重要的能力还在前方』均为时效性声明,当前实际状态原文未说明,可能已变化。

空间:谁的环境 / 场景

适用场景与形态:

  • 桌面端:macOS、Linux、Windows 可下载使用。
  • Web:无需下载,可直接在浏览器使用;移动浏览器可跟进线程。
  • 用户:与 agent 协作写代码并需要他人审查的开发者与团队。
  • 兼容形态:不必整团队迁移;未使用 Delta 的队友看到普通 Git 仓库,可继续经 GitHub 提交变更。
  • 部署细节(自托管/云端等)与具体版本号原文未说明。

变量:实际改变了什么

相对此前实际改变的内容:

  • 协作不再依赖 commit 与 push,改为直接邀请队友进入与 agent 的对话线程;队友看到相同 worktree 并可在自己机器上操作,作者下线后队友可继续与 agent 工作。
  • 用 Delta thread 取代 pull request;review subthread 提供父线程 worktree 的隔离副本。
  • 自家仓库已禁用 PR(流程性变更)。
  • 行为数据:33 人、570 个变更(自报数据)。
  • 价格变量:公测免费;付费计划『即将』推出,具体价格原文未说明。

区分:包含 ≠ 相关 ≠ 因果

区分:

  • 包含:Delta thread 内包含想法、实现、审查、落地四阶段——原文陈述它们发生在同一处,属流程设计,不是因果证明。
  • 相关/归因:『agent 生成大量代码』与『diff 膨胀』被作者作因果式归因,但原文未提供量化因果证据,属作者判断。
  • 明确因果(技术机制层面):DeltaDB 记录 commit 间的 delta,因此保留检查点之间的工作——这是设计性描述。
  • 计划而非结果:付费计划、内容寻址构建把 CI 式验证带入线程等均为路线图陈述,非已发生事实。

对象:作者/署名与关键技术原理

对象:署名仅依据结构化作者字段,为 Nathan Sobo(该字段中名字重复出现两次)。关键技术及原文描述的原理:

  • Delta thread:与 agent 的对话线程作为协作单元;邀请队友后其可见相同 worktree 并在本地机器操作;队友可向同一 agent 提问(例如为何选 Mutex 而非 RwLock)。
  • DeltaDB:扩展 Git 的 content-based versioning,引入基于 delta 的增量版本;记录 commit 之间的编辑与人类/agent 消息;commit 仍是 push、pull、build 的检查点。
  • review subthread:审查获得父线程 worktree 的隔离副本,可用 agent 探索与试改而不影响原工作。
  • CI 集成:agent 可用现有 CI provider 触发运行并在落地前查看结果。

元反空综合结论

元反空综合:

  • 元:这篇内容本质在解决『agent 时代代码审查的上下文丢失』问题——diff 膨胀使审查者看不到代码背后的决策,Delta 用线程+delta 保存并共享该上下文,并试图重新定义协作基本单元。
  • 反:最可能失效或有边界的主张——『threads 将成为新的基本单元』是愿景性判断;公测免费与付费计划随时点变化;33人/570变更是自身团队的自报数据,无独立验证;作者自认最受关注的能力还在前方,成熟度有限;与 GitHub 共存的混合流程的协调成本原文未讨论。
  • 空:去掉宣传叙事后剩下的必要事实——Delta 公测已发布,覆盖三桌面平台+Web+移动浏览器;基于 DeltaDB,兼容 Git;已在自家仓库停用 PR;提供 review subthread 与 worktree 隔离副本;未来将收费且保留免费版。
  • 综合结论:这是一份产品发布公告,技术机制与平台支持构成可核实的事实层,效果与行业判断构成未经独立验证的主张层;对 agent 密集且审查负担重的团队具有试用价值,但应按公测成熟度设定期望。

中文译文 AI 生成

今天,我们正式推出 Delta 公开测试版——一个用于与 agent 一起编写代码并评审其构建成果的多人环境。我们打造 Delta,是因为 agent 已经从根本上改变了我们编写软件的方式,但我们的协作工具没有跟上。

上周,我们跨过了一个关键里程碑:我们在 Delta 自身的仓库上禁用了 pull request。我们如今完全在 Delta 内部构建和协作开发 Delta。

Delta 与传统工作流的不同之处在于,协作并不依赖于提交和推送代码。你可以直接把队友邀请进你与 agent 的对话中。当有人加入你的 thread 时,他们看到的是与你相同的 worktree,并且可以在自己的机器上使用这些 worktree。

队友可以问同一个 agent,你为什么选择了 Mutex 而不是 RwLock。如果你下线了,他们可以接着你中断的地方继续与 agent 协作。

从今天起,任何人都可以下载适用于 macOS、Linux 或 Windows 的 Delta,也可以在网页上直接使用而无需下载任何东西,还可以在移动浏览器中随时随地跟进 thread。

Richard Feldman 演示了 Delta 中的一段端到端流程:修复一个 issue、获得队友的评审,然后将其合并。

无需 pull request 的代码评审

自 GitHub 在 15 年多前引入 pull request 以来,它已成为请队友评审代码库变更的标准方式。但随着 agent 生成的代码量巨大,我们互相请求评审的 diff 已经急剧膨胀。

把一个大的 diff 拆分到一叠分支中可以让导航更容易,但代码背后的决策仍然需要评审。更小的 diff 提供不了这些背景。评审者可能会把你的 diff 喂给另一个 agent 来帮助理解,但那个 agent 不得不重新拼凑你早已反复推敲过的决策。

为什么你队友的 agent 必须去猜测你是如何走到这一步的?

在 Delta 中,你可以邀请任何人从你中断的地方接手一条 thread,或者创建一个专门的评审子 thread。评审会引导你浏览分支上的变更,并可以访问原始 agent 的上下文。

每条评审都会获得父 thread worktree 的一份隔离副本,因此你和队友可以使用 agent 探索代码、尝试改动,而不会干扰原有工作。

如果评审者发现了问题,他们可以要求修改,或者与 agent 协作自行修复。评审期间完成的修复,可以在你让 agent 落地变更之前并入父 thread。

一段简短演示:在 Delta 中做出变更并获得评审。

构建于 DeltaDB,兼容 Git

Delta 构建于 DeltaDB 之上。DeltaDB 在 Git 基于内容的版本管理之上,扩展了基于 delta 的增量版本。它在 commit 之间记录编辑,并同时记录来自人类和 agent 的消息,从而保留代码在整条 thread 中的演进过程。

commit 仍然是你 push、pull 以及进行构建所依赖的检查点。DeltaDB 保留了这些检查点之间的工作。

你不必把整个团队都迁移到 Delta 才能使用它。

例如,zed-industries/zed 目前仍将留在 GitHub 上,因为我们的社区正是在那里发现 issue 并提交变更的。我们鼓励 Zed 的贡献者在提交 pull request 的同时分享 Delta thread。

贡献者可以在 Delta 中协同工作,同时继续通过 GitHub 提交变更,而那些从未打开过 Delta 的队友看到的仍是一个正常的 Git 仓库。

关注我们取代 GitHub.com 的征程

眼下似乎所有人都在竞相取代 GitHub。大多数竞争者承诺的,只是在同样的旧有原语——分支、commit 和 diff——之上提供更好的可用性。

我们相信,thread 将成为软件开发的新基本单元,而对其状态建模的最佳方式就是 delta。

Pull request 是我们正在告别的 GitHub 工作流中的第一部分。取而代之的是 Delta thread,以及随之而来的一种我们称之为持续工程(continuous engineering)的工作方式。这个行业已经让集成实现了持续化,随后是交付,而软件工程的其他环节仍然以批次方式进行。

在一条 Delta thread 中,想法、实现、评审以及变更的落地都可以在同一个地方完成。

对于把开发者带到 GitHub.com 的其他工作流,我们正在构建更好的替代方案,首先是 DeltaDB 中的 Git 存储。从长远来看,基于内容的构建可以把 CI 式的验证直接带入 thread。目前,agent 可以通过现有的 CI 提供商触发一次运行,并在落地变更前检查结果。

试用公开测试版

感谢数以千计申请早期访问并帮助我们发现 Delta 粗糙之处的人。Delta 正在成形,一些我们最关心的能力还在前方(在此关注我们接下来在构建什么)。但它已经成为我们的日常主力:自关闭 pull request 以来,我们 33 个人已向 main 落地了 570 项变更。

在公开测试期间,Delta 免费。我们很快将为个人和团队推出付费方案。Delta 将永远有免费版本。

下载 Delta,启动一个 agent,邀请一位队友进入 thread,感受这份魔力。我们很乐意听听你的使用体验。

相关文章

看看 Zed 团队的其他类似博客。

在找更好的编辑器吗?

今天你就可以在 macOS、Windows 或 Linux 上试用 Zed。立即下载!

我们正在招聘!

如果你对我们博客所涉及的话题充满热情,请考虑加入我们的团队,帮助我们交付软件开发的未来。

展开原文提取正文(采集端自动提取,可能有缺失)

Today, we're launching the public beta of Delta, a multiplayer environment for coding with agents and reviewing what they build. We're building Delta because agents have fundamentally changed the way we write software, but our collaborative tooling isn't keeping up. Last week, we crossed a key milestone: we disabled pull requests on Delta's own repository. We now build and collaborate on Delta entirely within Delta.

What makes Delta different from traditional workflows is that collaboration doesn't depend on committing and pushing code. You invite teammates directly into your conversations with agents. When someone joins your thread, they see the same worktrees you do and can work with them on their own machine. Teammates can ask the same agent why you chose a Mutex instead of an RwLock. If you log off, they can keep working with the agent where you left off. Starting today, anyone can download Delta for macOS, Linux, or Windows, use it on the web without downloading anything, and keep up with threads from a mobile browser on the go. Richard Feldman walks through an end-to-end flow in Delta: fixing an issue, getting a teammate's review, and merging it. Code review without pull requests Since GitHub introduced pull requests over 15 years ago, they've become the standard way to ask teammates to review changes to your codebase. But with agents generating so much code, the diffs we're asking each other to review have mushroomed. Splitting a big diff across a stack of branches can make it easier to navigate, but the decisions behind the code still need review. Smaller diffs don't supply that context. A reviewer may feed your diff into another agent to help understand it, but that agent has to piece together decisions you already worked through. Why should your teammate's agent have to guess how you got there? In Delta, you can invite anyone to pick up a thread where you left off, or create a dedicated review subthread. A review guides you through your branch's changes with access to the original agent's context. Each review gets its own isolated copy of the parent thread's worktrees, so you and your teammates can use agents to explore the code and try changes without disrupting the original work. If a reviewer spots a problem, they can request a revision or work with an agent to fix it themselves. Fixes made during review can be incorporated into the parent thread before you ask the agent to land the change. A short walkthrough of making a change and getting reviews, in Delta. Built on DeltaDB, compatible with Git Delta is built on DeltaDB, which extends Git's content-based versioning with incremental versions based on deltas. It records edits between commits alongside messages from humans and agents, preserving how the code evolved throughout a thread. A commit remains the checkpoint you push, pull, and build from. DeltaDB retains the work between those checkpoints. You don't have to move your whole team into Delta to use it. For example, zed-industries/zed will remain on GitHub for now because it's where our community finds issues and submits changes. We're encouraging Zed contributors to share Delta threads alongside their pull requests. Contributors can work together in Delta while continuing to submit changes through GitHub, and teammates who never open Delta still see a normal Git repository. Follow our quest to replace GitHub.com It seems like everyone is in a race to replace GitHub right now. Most contenders promise better uptime on top of the same old primitives: branches, commits, and diffs. We believe that threads will be the new fundamental unit of software development, and the best way to model their state is with deltas. Pull requests are the first part of the GitHub workflow we're leaving behind. In their place is the Delta thread, and with it a way of working we call continuous engineering. The industry made integration continuous, then delivery, while the rest of software engineering still happened in batches. In a Delta thread, the idea, implementation, review, and landing of the changes can all happen in the same place. We're building better alternatives for the other workflows that bring developers to GitHub.com, starting with Git storage in DeltaDB. Longer term, content-based builds could bring CI-style verification directly into the thread. For now, an agent can trigger a run with an existing CI provider and check the results before landing the change. Try the public beta Thank you to the thousands of people who requested early access and helped us find Delta's rough edges. Delta is forming, and some of the capabilities we care most about are ahead (follow what we're building next here). But it's already our daily driver: 33 of us have landed 570 changes to main since we turned off pull requests. During the public beta, Delta is free. We'll introduce paid plans soon for individuals and teams. There will always be a free version of Delta. Download Delta, kick off an agent, invite a teammate into the thread, and feel the magic. We'd love to hear how it goes.Related PostsCheck out similar blogs from the Zed team.Looking for a better editor? You can try Zed today on macOS, Windows, or Linux. Download now!We are hiring! If you're passionate about the topics we cover on our blog, please consider joining our team to help us ship the future of software development.

原文入口

阅读原文(zed.dev)

原文将在新窗口打开。收录时间不是内容更新时间;正文、译文与解读的版权归原作者/来源所有,本站仅作个人阅读辅助并保留原文入口;页面时间均为北京时间。

作者/署名来自原文结构化字段(Atom/RSS/HTML meta/JSON-LD;GitHub release 显示的是发布者账号),未经模型补充。

了解来源批准与收录规则