代码的真正来源是代码本身，还是产生代码的那段对话？Zed团队在官方博客上发表了一篇文章，宣布正在开发一个名为DeltaDB的新版本控制系统——这个系统的核心理念是：代码变更应该与产生这段变更的对话绑定在一起，而非仅仅依赖于Git的提交快照。

https://zed.dev/deltadb

Git的局限性：从快照到操作记录

Zed的联合创始人Nathan Sobo在文章中指出了传统版本控制系统的一个根本性问题：Git的提交机制是基于快照的，而非操作流。每次提交记录的是"文件在某个时刻的状态"，而不是"在这个时刻发生了什么操作"。这种模型在面对现代协作场景时显得过于笨重——你需要等待提交、等待审核、等待合并，然后才能继续推进工作。

这个问题的本质在于：Git设计于一个代码审查是可选的、实时协作是罕见奢侈品的时代。而今天，AI智能体可以随时修改代码，团队成员可以实时看到彼此的改动，传统的"提交-审核-合并"流程正在成为效率的瓶颈。

DeltaDB的设计思路：操作优先，对话绑定

DeltaDB的核心设计理念有两点：细粒度操作记录，以及代码变更与对话的绑定。

第一，DeltaDB记录每一个操作，而非每一个快照。这意味着你可以在任何时刻回溯到文件的任意状态，并同时看到产生那次变更的上下文——谁在什么时间做了什么改动、为什么做这个改动。第二，每次代码变更都与产生它的对话绑定在一起。当你查看一个代码片段的历史时，你不仅能看到它是如何演变的，还能直接看到当时团队成员或AI智能体讨论了哪些问题、做出了哪些决策。

这种设计让"指向历史中的任意时刻，然后直接跳转到相关的讨论"成为可能。传统的代码审查需要单独开启一个PR流程、等待评论、记录反馈，而DeltaDB将这些对话与代码变更本身视为同一事件的两面。

实时协作与AI智能体的兼容性

DeltaDB的另一个重要特性是支持实时协作。团队成员和AI智能体可以在同一个工作树上同时工作，无需等待提交和推送。这与Git的分支模型形成了鲜明对比——在Git中，你需要处理合并冲突、解决版本差异，而在DeltaDB中，所有操作都是持续的、增量式的，不存在"版本分叉"的概念。

这意味着AI智能体可以真正融入开发流程，而不是作为"偶尔被调用的工具"存在。当AI智能体可以实时看到代码库的变化、参与到正在进行的讨论中时，它的工作方式将从"响应人类指令"转变为"与人类共同演进代码"。

Beta即将发布

Zed团队表示，DeltaDB的Beta版本预计将在几周内发布，感兴趣的用户可以在 zed.dev/deltadb 加入等待列表。Git和CI系统仍然有用——它们提供了检查、外部集成等能力——但协作的核心将转移到持续演进的工作树上，而非提交历史中。

这是一个关于"代码与对话关系"的重新思考。在AI时代，代码的来源不再是一个黑箱——每一行代码背后都有一个可以被追溯的决策过程。DeltaDB试图让这个决策过程变得可见、可检索，而这也许是版本控制在下个时代应有的形态。

参考来源：https://zed.dev/blog/introducing-deltadb