Zed 编辑器团队发布了新项目——DeltaDB，一个在 git commit 之间记录每一次编辑操作的版本控制系统。目前处于 Early Access 阶段。

DeltaDB 的核心思路直接写在 landing page 最显眼的位置：「Software is made between commits」——软件是在 commit 之间写出来的。git 只记录了你提交的最终状态，但真正的工作过程——打字、删改、试错、agent 对话——都在 commit 之间的空隙里丢失了。

DeltaDB 要做的就是把这段空隙补上。

回退到任何一次编辑：DeltaDB 捕获 commit 之间的每一次操作，给每个操作一个稳定的标识。你可以回退到代码演化过程中的任何一个时刻，不只是某个 commit 点。

代码追溯对话：每个改动都链接到产生它的 agent 对话。从任何一行代码可以找到对应的对话，从对话的任意一条消息可以跳到它改动的代码。对于 AI 辅助编程的场景，这个能力可能是关键差异——当 agent 给你写了一堆代码，你不用靠记忆去回想"这段代码是哪个 prompt 生成的"。

任意时刻分支：DeltaDB 虚拟化了 worktree，创建新的 agent 分支几乎是零成本的。历史上的任何一点都是合法的分支点，包括 agent 还在工作的中间状态。

分享线程而非 PR：队友可以在工作还在进行中就加入，跟工作的 agent 对话，边看边标注，不需要等你 commit 和 push。这改变了代码协作的粒度——从"review 一个 PR"变成了"参与一个进行中的创作过程"。

问题来了，这真的是又一个"工程师玩具"吗？

DeltaDB 的定位很明确：它不是要取代 git，而是填补 git 没覆盖的那段空白——commit 之间的工作过程。在 AI agent 越来越参与代码生成的背景下，这个切入点有它的合理性。

当 agent 生成了 200 行代码，你接受了其中 150 行，手动改了 30 行，拒绝了 20 行——这个过程在 git 历史里只有一个 commit："agent 辅助实现了某个功能"。DeltaDB 试图让这段过程可追溯、可协作、可回退。

而且，Zed 团队不只是做了个花哨的 demo。Nathan Sobo（Zed 联合创始人）和团队在过去几年里确实把 Zed 从一个"快但功能不全"的编辑器做成了越来越多人日常使用的工具。他们的技术判断力不应该被简单地归为"工程师在玩"。

不过，剩下的问题也很现实：DeltaDB 作为一个独立产品，还是作为一个 Zed 的功能？如果它只能和 Zed 一起用，那它的受众就是 Zed 用户。如果它是一个独立的版本控制系统，那它需要说服开发者放弃 git 的生态——这几乎不可能。

更可能的方向是，DeltaDB 最终成为 Zed 内部的一个功能层，在你的 git repo 之上运行，记录和关联你的工作过程。这样你不需要放弃 git，但多了一个"时间机器"。

参考来源：

• DeltaDB 官网