Commit 之间的空白：为什么 Git 正在失去对 AI 的表达力
2026 年 8 月 5 日，由 Atom 创作者 Nathan Sobo 带领的 Zed 团队正式开放 DeltaDB 的 Early Access 排队。这套被称为「操作级版本控制」的系统在 Hacker News 上线当天便引发热烈讨论，收获 442 分与 233 条评论。
Git 诞生于人类手动撰写代码、通过补丁和 PR（Pull Request）同步变更的时代。人类开发者每次执行 git commit 都伴随着手动梳理代码逻辑和撰写提交信息的管理成本。因此，Git 的原子单位被设计为提交（commit）快照，两次提交之间的修改过程通常被折叠忽略。
当 AI Agent 成为主要的代码生产者时，这一假设遭遇了工程挑战。自动生成代码的过程包含大量的局部迭代与连续推演，但在传统 VCS（Version Control System，版本控制系统）中，两次提交之间的数百行变更往往被直接打包覆盖。所有的思考脉络、调试提示词与上下文历史在提交时被抹去。
传统的 Code Review 机制在这种模式下显得日益笨拙。PR 说明、Review 讨论线程与行内评论本质上都是事后将讨论内容补贴回静态代码快照。当代码经历多次重构后，事后记录的评论往往会与代码实际行号发生漂移和脱节。
图：DeltaDB 官方架构理念示意。来源：images.zed.dev
细粒度 Delta 与对话绑定：把存储原语下沉到编辑级
为了解决版本控制与上下文断层的问题，DeltaDB 重新设计了代码变更的存储原语。系统不再依赖全局 commit 快照，而是实时记录 commit 之间的每一次微观编辑操作（delta）。
每个 delta 都拥有稳定的唯一标识符（stable identity）。即使目标文件经历了大规模重构或代码行号上下偏移，指向该 delta 的引用依然能保持精确寻址。这种寻址粒度允许开发者与工具追踪代码演化历史中的任意微观瞬间。
更核心的突破在于将 Agent 对话与代码编辑同录于同一存储结构中。用户发送给 Agent 的提示词以及 Agent 生成的代码修改被并行保存，两者从底层存储上绑定在一起。从代码历史的任意一行，开发者都能直接跳转到产生该行的 Agent 对话上下文；从任意一条对话，也能准确锁定其修改的具体代码片段。
这种同构存储改变了多人的协同模式。队友不需要等待完整的 commit 提交或分支推送，而是可以直接共享对话线程（thread）。协同者能够中途加入正在运行的 Agent 任务，实时观察代码生成并实施在线批注，这把以往分布式异步提交的等待成本降到了毫秒级的实时对话层面。
实时无冲突工作树：从单机暂存到分布式 CRDT
在多 Agent 与多开发者并发作业的场景中，传统的 Git 索引与暂存区机制极易产生频繁的合并冲突。DeltaDB 在底层嵌入了无冲突复制工作树（CRDT Worktrees，Conflict-free Replicated Data Types）。
CRDT 允许分布在不同机器上的本地 Agent 与人类开发者在各自的文件系统中并发修改同一批文件，同时保证数据结构的最终一致性。开发者可以将整套工作树挂载到本地磁盘，Agent 也可以通过终端在真实的文件系统上执行编译、测试与修改命令。
在并发修改过程中，所有的编辑动作被解析为图结构上的增量更新。Agent 在执行长程重构任务的同时，人类开发者可以在另一端继续修正函数细节，系统会在后台自动收敛两端的变更。
这种将 CRDT 引入底层工作树的尝试，将版本控制从单机文件快照的比对提升到了实时分布式状态同步的范畴。 它使得 Agent 可以在真实的本地开发环境中自由探索，而不会破坏全队的协同基线。
图：DeltaDB Early Access 排队界面。来源：api.everydev.ai 存档
补充还是替代：社区关于性能与工作流的辩论
针对 DeltaDB 提出的操作级版本控制方案，Hacker News 社区展开了激烈的辩论，焦点集中于工程适用边界与性能开销。
支持观点认为，在 Zed 推出 Parallel Agents 等并行智能体功能的背景下，细粒度跟踪是解决代码追溯难题的必然选择。当多个 Agent 同时在不同模块生成代码时，传统提交日志无法厘清不同 Agent 的推理假设，而 DeltaDB 提供的对话锚定能力使团队能够随时召回历史 Agent 并查询代码的撰写动机。
质疑观点则提出了对系统工程负担的顾虑。细粒度记录每一次键盘敲击与 Agent 增量输出，会导致版本库的数据量呈指数级增长。在千万行代码级别的超大型工程中，维持 CRDT 状态树的内存占用与实时同步延迟将面临严峻考验。同时，部分开发者提出，过度细致的操作历史可能引入大量无效的中间态噪点，反而增加了代码审计的筛选成本。
针对这些争议，Zed 官方在架构设计上做出了折中取舍。DeltaDB 并未计划直接取代现有的 Git 生态与 CI 检查流程。Git 依然负责连接外部部署、管理发布分支与运行自动化流水线，而 DeltaDB 则接管 commit 内部、开发过程中的实时协同与上下文绑定。
这种双轨并行机制降低了团队迁移的心理门槛。项目不需要放弃原有的 Git 检查标准，便能在本地开发阶段享受操作级追溯与 Agent 协同优势。
当版本控制的主语变成对话
版本控制工具的演进历史，始终映射着开发生产力的主导者转变。从 CVS、SVN 的集中式锁机制，到 Git 的分布式快照模型，每一次架构跃迁都回应了新的协作密度需求。
当 AI Agent 承担起绝大部分的代码编写工作，代码演化的中心不再是写出的静态结果，而是促成这一结果的对话与推理推演。Git 将讨论留在 PR 页面、将代码留在 commit 中的模式，已经难以适应智能体高频迭代的技术现实。
DeltaDB 的探索证明，代码与对话可以共享同一个底层数据模型。当编辑操作与生成它的 Agent 线程实现原生融合时，版本控制的主语便完成了从提交快照到对话轨迹的切换。无论该项目最终能否在生态上取代传统的开发工具，这一存储原语的重构都为 AI 时代的软件工程提供了清晰的示范。
参考链接：
- Zed 官方博客《Software Is Made Between Commits》
- Hacker News 讨论帖子 #49187256
