介绍 DeltaDB：面向 AI 代理时代的版本控制

DeltaDB 将版本控制从快照转向操作流

Zed 正在构建 DeltaDB，以将软件开发超越离散提交的限制。与 Git 在特定时间点捕获代码快照不同，DeltaDB 记录一条连续的细粒度“增量”流——对工作树执行的每一次操作。此方法使系统能够为每一次更改分配稳定的标识，从而让开发者能够在代码演进的任何时刻引用其确切状态。

此架构转变专为 AI 辅助编码时代而设计。通过实时记录操作，DeltaDB 确保推动代码更改的对话与编辑本身并列存储，防止意图（对话）与实现（代码）之间产生偏离。

将对话整合作为第一类真相来源

DeltaDB 将人类与 AI 代理之间的对话视为软件的主要来源。由于引用锚定在特定的增量上，而非易变的行号，随着代码的持续演进，历史上下文得以保留。

关键能力包括：

• 双向导航：开发者可以从过去对话中的某行跳转到该代码的当前状态，或相反地，找到生成特定代码行的具体对话及其后续编辑。
• 代理上下文：AI 代理可以访问完整的增量历史，通过审阅之前接触该代码的代理和人类，了解代码背后的“原因”。
• 实时协作：多个用户和代理可以在不同机器上同时编辑同一文件，使用无冲突的复制工作树。这些工作树仍以真实文件形式保存在磁盘上，可供外部终端工具使用。

消除 Pull Request 的“仪式感”

通过在单一位置统一讨论与代码，DeltaDB 旨在消除传统 Pull Request 和审查线程的需求。在当前基于 Git 的工作流中，PR 用于在工作已提交并推送后重新将讨论关联到代码。DeltaDB 打算让与代理的对话成为唯一必要的交流，使团队成员能够加入实时进行中的工作、与代理互动，并实时注释更改。

在此模型下，Git 和持续集成（CI）被归于其原有优势：运行自动检查并管理与更广泛生态系统的最终衔接，而非作为协作的主要场所。

社区观点与技术批评

DeltaDB 的发布在开发者中引发了关于“中间”代码价值以及专业软件工程本质的激烈讨论。

“混乱中间” 的价值

许多开发者认为提交之间的工作是一锅“混乱的试错汤”，不应被保留。批评者指出，提交是对为何进行更改的精心叙述，而每一次操作的流仅是对如何发生的记录。

“我在提交之间写的代码是我的思考过程。我通过写代码、删除再重新写来思考。提交中发布的代码是为了让他人理解……我不希望我的思考被序列化、版本控制并公开可见。”

对监控与噪声的担忧

一些贡献者担心捕获每一次按键可能导致对开发者的监控。另一些人则认为，生成的历史将充斥着“垃圾”——死路和错误，给未来的维护者带来负担。

“保存每一次更改和每一条代理信息会让所有这些垃圾保留下来。”

与现有系统的比较

技术反驳指出，类似功能可以通过现有工具实现：

• Git 优化：一些用户指出，频繁的自动提交结合 git merge --no-ff 和 --first-parent 可以提供细粒度历史与干净顶层提交的类似平衡。
• 企业先例：有人指出，Google 的 Piper/CitC 系统多年来一直使用高粒度历史。
• 替代上下文：一些开发者更倾向于使用“上下文层级”（源文件旁的实时 Markdown 文档），而不是使用聊天日志数据库来规范意图。

AI 特定的实用性

相反，一些为非工程师构建工具的开发者认为，对于不遵循严格提交规范的人来说，持续的英文讨论链是表示构建软件所需“思考链”的唯一方式。