软件诞生于 Commit 之间：聊聊 Zed 的 DeltaDB

2026 年 6 月，Zed 团队发布了一篇长文，正式介绍了他们正在构建的东西------DeltaDB，一个面向 AI 时代的全新版本控制系统。同月，基于 DeltaDB 的 Delta 多人协作环境开始向私有 beta 用户发放邀请。值得仔细读一遍，不是因为"又一个版本控制系统"本身有多吸引人，而是因为它点出了一个我们每天都在经历、却很少被正视的问题。

Git 已经跟不上了

先说一个场景。你在跟 AI agent 对话，它帮你重构了一个函数。你看了看效果不错，但中间它改了几版------第一版有个边界 case 没处理，你指出之后它又调了一次，最后才到现在的样子。你满意了，commit 了。

两周后，另一个同事问："这个函数的边界处理逻辑为什么是这样写的？"

你看了一眼 commit message，写了个"refactor"。你努力回忆当时的对话，但 chat 窗口早就翻不到了。那个"为什么"，丢了。

Zed 的 CEO Nathan Sobo 在一次访谈里用了个说法：Git 记录的是你创建的产物的检查点，但两个检查点之间的过程------被放弃的编辑、被撤回的 prompt、agent 的转向、所有那些细小的决策------是暗物质。那些暗物质应该也被版本化，但 Git 做不到。

Git 的设计前提是：代码的变化发生在 commit 的节点上，commit 之间的过程不重要。这在纯人力的时代是合理的------人写代码是一个连续的过程，commit 是一个有意识的断点，你把一段完整的思考打包成一个快照。

但现在情况变了。AI agent 可以在几十秒内改写一个函数，中间的每一轮对话都包含决策的理由。而 commit 把这些理由压缩成了一行 message，信息丢失是必然的。

Sobo 在文章里用了个比喻：用 commit 来做实时协作，就像用传真机聊天。

DeltaDB 的核心设计理念：事件源数据库

要理解 DeltaDB，首先要放下"版本控制系统"这个框架。Sobo 在 Hanselminutes 播客里说得更准确：DeltaDB 本质上是一个编程行为的事件源数据库（event-sourced database）。

它像 Git 一样存储一个有向无环图（DAG），但不同的是：Git 的 DAG 里每个节点是一个 commit 快照，DeltaDB 的 DAG 里每个节点是一个具体发生的事件------一次编辑、一条对话消息、一次 prompt。所有的事情都被记录下来，然后被索引。

这个索引是关键。索引的存在意味着你可以从任意方向进行查找：从某一行代码出发，找到创建它的对话和修改过它的所有对话；从某条对话消息出发，跳转到它触碰到的代码位置。这就是 DeltaDB 的核心承诺：对话和代码之间的双向可追溯性。

再补充一个容易被忽略的细节：消息和它产生的编辑是并列存储的（side by side），所以它们永远不会互相漂移。在 Git 的世界里，commit message 和 commit diff 之间天然存在分离------message 可能被改写、可能被省略、可能在 rebase 时丢失。在 DeltaDB 里，消息和编辑是同一事件的两个面。

四大核心功能

Zed 在 DeltaDB 的早期访问页面上列出了四个具体能力，值得逐一展开。

1. 回退到任意一次编辑（Rewind to any edit）

Git 可以让你回到任意一个 commit，但不能回到 commit 之间的任意状态。DeltaDB 可以。

它把每个操作都赋予了一个稳定的标识符。这意味着你可以看到 agent 在重构过程中的中间状态------比如它第一次尝试某个方案时的样子，即使后来它意识到方向不对并撤回了。这些"暗物质"不再是不可见的，它们被完整地记录下来。

实际场景：你让 agent 实现一个排序算法，它先写了冒泡排序，你提示效率太低，它改成了快速排序，你又要求稳定排序，最后它用了归并排序。在 DeltaDB 里，你可以看到这三版的全貌，以及每一版对应的对话。在 Git 里，你只看到最后一版的 diff。

2. 追踪代码到对话（Trace code to conversation）

这是 DeltaDB 最有差异化的一点，也是它在现有工具里没有任何等价物的地方。

从任何一行代码出发，你能找到创建或修改过它的所有对话。从任何一条对话消息出发，你能跳转到它影响的代码位置。这不只是单向的"谁改了这段代码"，而是双向的"这段代码为什么是这样"。

DeltaDB 里还有一个叫 Portals 的功能。当你在阅读 agent 对话的转录记录时，对话中出现的任何代码引用都可以作为一个入口点（portal）------你点击它，就能跳转到 agent 在引用那一刻的代码状态。不是代码现在的样子，而是 agent 在那一刻看到的样子。这个细节看似不大，但实际使用中非常关键，因为代码的上下文决定了 agent 的推理是否合理。

支撑这一切的是 DeltaDB 的字符级永久链接（character-level permalinks）。Git 的引用基于行号------"第 42 行"------但代码一旦重构，行号就变了，所有引用都断掉。DeltaDB 的引用锚定的是 delta（操作），而不是行号。它能追踪一个字符从被创建到被移动、被修改、被删除的完整因果链。代码怎么变，引用都跟着走。你半年前标记的一段讨论，今天打开仍然精准定位到对应的逻辑。

3. 在任意时刻分支（Branch at any moment）

DeltaDB 虚拟化了工作树（virtualized worktree）。传统版本控制里，checkout 一个分支意味着把文件系统的状态切换到某个快照。DeltaDB 把这个过程虚拟化了一层------工作树不再是物理的文件系统状态，而是一个可以根据需要重组的视图。

这意味着：

创建新的 agent 分支几乎是零成本的。不需要复制整个仓库，不需要额外的磁盘空间。
历史中的任意一点都可以作为分支点，包括 agent 运行过程中的中间状态。不只是 commit 可以做 branch point，任何一个 delta 都可以。
你可以并行跑多个 agent，每个在各自的虚拟工作树上操作。开发者审查每个 agent 的输出流，比较结果，合并最优方案。被淘汰的方案也保留在历史中，与评估对话相关联。

当然，虚拟化的工作树也可以随时挂载到真实的磁盘上，让本地工具直接操作文件。文件是真实的，agent 通过终端在其中工作，只是版本化的层面被 DeltaDB 接管了。

Sobo 从一开始就公开表达过对 pull request 的反感。PR 的模型是：你写完代码，commit，push，开 PR，等 review。这个流程里，reviewer 看到的是结果，看不到过程。

DeltaDB 的协作模型完全不同：同事可以在你的工作还在进行中时就加入进来。他们可以看到 agent 的完整对话历史，可以直接跟 agent 对话来理解当前的上下文，也可以在对话中添加注释。不需要等你 commit，不需要等你 push。

这种模型对 AI 时代特别有意义。过去 code review 的问题是 reviewer 不理解作者的意图。现在 agent 参与了编码过程，intent 被完整地记录在对话里------reviewer 不仅可以阅读这些对话，还可以直接跟对话里的 agent 继续交流。

底层技术：CRDT 与 Git 的关系

DeltaDB 使用 CRDT（无冲突可复制数据类型）来增量记录和同步变化。CRDT 的核心保证是：多个参与者可以独立修改数据，最终合并时不需要协调，按任意顺序合并都能收敛到一致的状态。

在 DeltaDB 的架构里，CRDT 的载体是可复制的工作树------多个人和 agent 可以在不同机器上同时编辑同一个文件，变更通过 CRDT 自动合并，不会产生冲突标记。

粒度方面，DeltaDB 的 CRDT 操作达到了字符级别。GitHub 上的一个 Discussion 里有人对此提出质疑：单个按键不是一个有意义的变更，它会产生噪声化的历史和语义上断开的中间状态（比如输入了一半的 fucntion 和别人的编辑在同一行上合并）。这个批评有道理，但 Zed 的角度是：字符级粒度是为了实现上面提到的字符级永久链接------你能精确追踪一个代码片段在任意时间点的状态，而不只是某个 commit 之间的近似。

关键的一点是：DeltaDB 不替代 Git，而是与 Git 互操作。 Git 和 CI 仍然负责运行检查、做最终快照。DeltaDB 处理的是 commit 之间的连续协作层。你可以把 DeltaDB 理解为 Git 的一个补充层------它记录 Git 不记录的东西。

Delta：从数据库到产品

2026 年 6 月，Zed 不仅发布了 DeltaDB 的技术介绍，还正式推出了 Delta------一个基于 DeltaDB 的多人编码与审查环境。

Delta 的定位是：你和 agent 一起编码，然后审查 agent 产出的东西。它不是"把代码交给 agent 然后等结果"，而是一个让你全程参与、实时观察 agent 工作过程的环境。第一批私有 beta 邀请在公告当天就开始发放。

这意味着 DeltaDB 不再是停留在博客文章里的概念，它已经在被包装成一个可使用的产品形态。

更大的图景

DeltaDB 和 Delta 是 Zed 更大愿景的两块拼图。这个愿景可以概括为：IDE 不再是编辑代码的工具，而是协作的平台。

Sobo 的说法是：源码现在就是源对话（source code is now source conversation）。 这句话的含义比它看起来更深。如果软件是在对话中成型的------跟队友讨论、跟自己推理、跟 AI agent 来回迭代------那么真正定义软件的"源"不是代码文件，而是那个对话。代码只是对话的产物。DeltaDB 做的事情就是把对话提升到跟代码同等重要的地位。

Zed 在 2025 年底拿到了 Sequoia 领投的 3200 万美元 B 轮融资。融资公告里的措辞很明确：这笔钱用于建设 DeltaDB 和围绕它的协作体系。

值得质疑的地方

DeltaDB 在 Hacker News 上的讨论超过 300 条评论，反对意见集中在几个方向：

存储膨胀。 记录每一次操作，而不是只在 commit 时记录快照，意味着数据量呈数量级增长。一个 agent 在重构过程中可能产生几百次编辑，每次编辑都带有关联的对话元数据。Zed 在公告中没有讨论这个问题的解决方案------数据增长怎么处理？是否需要压缩策略？旧 delta 是否需要归档或删除？

字符级粒度是否过度。 如前面提到的，单个字符的变更在代码层面可能没有意义。如果每个 keystroke 都被记录，历史会极其嘈杂。需要有个合理的粒度来平衡精确性和实用性。

过度工程化。 很多人质疑：Git 不够用了吗？Jujutsu（jj）已经在朝操作级别的方向走了。为什么要造一个新的版本控制系统，而不是在现有系统上做增量改进？

CRDT 在代码层面的可行性。 代码的合并不是简单的数据合并。Mike Freedman 在 LinkedIn 上写了一段很到位的分析：在数据层面，CRDT 合并是一致的；在代码层面，结果往往是编译不过的。编译失败的"无冲突状态"比有冲突更危险，因为你不会意识到出了问题。不过他也指出：当 CRDT 合并的产物由 AI agent 来修复而非人类手动解决时，这个算法规则可发生变化------agent 可以自动编译、跑测试、发现问题、修复问题，形成一个闭环。

隐私和数据安全。 对话和代码的永久绑定意味着所有的 prompt、agent 的推理过程都被记录。这些数据存在哪里？谁可以访问？会不会被用于模型训练？这些都是开发者会关心的问题，而 Zed 目前还没有给出清晰的答案。

缺乏技术文档。 截至公告发布，DeltaDB 没有公开的 CLI、没有开放的技术文档、没有公开的 API 规范。它目前只能通过 Zed 编辑器来使用。这意味着你被绑定到了 Zed 的生态。

最后的判断

DeltaDB 做的事情，本质上是把版本控制的时间分辨率从"commit 级别"提升到了"操作级别"。在纯人力编程的时代，这个提升的意义有限------人一次有意义的编辑和一次 commit 之间的距离本来就不大。但在 AI agent 参与编程的时代，一次 agent 运行过程中可能包含数十次编辑、多轮对话、几个方向的尝试和回退。这些过程信息如果丢失，就等于丢掉了代码的上下文。

DeltaDB 的价值不在于"比 Git 更强"，而在于它记录了 Git 不记录的东西。两者的关系是互补而非替代。

但所有的新抽象都需要回答一个基本问题：引入的复杂度是否带来了足够大的收益？对于个人开发者来说，DeltaDB 的承诺是清楚的------你的每一次对话都不会丢失上下文。对于团队来说，价值在于 code review 方式的根本改变------从"审查最终结果"变成了"参与整个过程"。这个改变是否足够大，值得学习一个新的版本控制模型，只有时间能回答。

软件诞生于 commit 之间------这句话不只是个口号。在 AI agent 参与开发的这个时代，commit 之间的过程，才是真正重要的部分。

软件诞生于 Commit 之间：聊聊 Zed 的 DeltaDB