2026 年 8 月，Zed 的创始人 Nathan Sobo 在一个beta 公告里写下了一句后来被反复引用的话："软件是在提交之间产生的。"（Software is made between commits.） 这句话听起来像句正确的废话，直到你把它放进现实：一个 Agent 在三小时内改了 11 个文件、试错了 4 次、中途推翻了自己两次方案，最后交给你一个 diff。Git 会忠实记下这个 diff，以及你事后补写的那句 "fix: refactor payment flow"------然后，那三小时里真正发生的一切，蒸发了。这篇文章想讲清楚一件事：当代码的产生方式从"人敲键盘"变成"人和 Agent 对话"，版本控制要管的对象，已经从代码本身变成了产生代码的那个过程。这不是换个工具的问题，是软件工程最底层的数据模型要改一次。
一、三条隐含假设，正在被逐条击穿
Git 生于 2005 年，为的是管理 Linux 内核------几百个人类高手，通过邮件列表异步交换补丁。这个出身决定了它的数据模型带着三条从未被写进文档的隐含假设。二十年来这三条假设一直成立，所以没人觉得它们是假设。
假设一：一次提交 = 一个值得记录的逻辑单元。
这个假设成立的前提是"人写代码很慢"。人类花四十分钟才能凑出一个自洽的改动，这四十分钟的心理活动天然就是一次压缩：你脑子里试错了十次，手上只留下最后一次。提交因此天然是"深思熟虑的结果"。而 Agent 不慢。它能在一分钟内给出三版实现，其中两版被它自己丢掉。当产生成本趋近于零，"深思熟虑的结果"这个单位就失去了意义------因为过程不再被压缩，过程本身就是产品。
假设二：写提交信息的人，知道自己在干什么。
Git 依赖作者事后用一句话解释意图。这在人写代码的年代勉强够用，因为写代码的人就是做决定的人。但当代码由 Agent 生成、由人来"验收"时，链条断成了两截：做决定的是模型和提示词，写提交信息的是那个只看了 diff 的人。 他用自然语言复述的，是他对最终产物的理解，而不是产生这个产物的真实原因。这两者之间的差距，就是后来所有人花三小时考古的那片黑暗。
假设三：关于代码的讨论，发生在代码之外，事后再挂回去。
Pull Request、review thread、行内评论------这套东西的存在，本身就证明了讨论和代码分居两地。Zed 的原话说得很难听但很准："PR、review 线程和行内评论之所以存在，是为了在事后把讨论重新贴回代码上，因为讨论和代码原本住在两个地方。把它们放到同一个地方，这套仪式就消失了。"
|------|---------------------------|----------------------|
| | Git 的世界观 | Agent 时代的现实 |
| 变更单位 | 一次提交 = 一个逻辑单元 | 一次会话 = 几十次试错 + 若干次推翻 |
| 意图来源 | 作者本人，事后写提交信息 | 模型 + 提示词，作者只是验收者 |
| 讨论位置 | 代码之外（PR / review / issue） | 对话就是产生代码的现场 |
| 历史粒度 | 提交处的快照 | 提交之间的每一次编辑 |
| 引用锚点 | 行号 / 提交哈希 | 需要能跟着代码移动的稳定身份 |
| 协作节奏 | 异步、离散、以提交为界 | 连续、实时、人和 Agent 同时在场 |
三条假设不是被削弱，是被击穿。而击穿它们的不是某个新工具，是代码的生产方式变了。
二、数据：审查这道闸门，正在被冲垮
在谈"怎么办"之前，先看清楚问题有多硬。
Faros AI 在 2026 年的 "Acceleration Whiplash"（加速的鞭打）报告里，追踪了 22,000 名开发者、1,255 个团队两年的遥测数据，给出一组互相打架的数字：
|-------------------|-----------------|
| 指标 | 高 AI 采用团队的变化 |
| 人均完成任务数 | +21% |
| 合并的 PR 数 | +98% |
| PR 审查耗时 | +91% |
| PR 平均体积 | +154% |
| 人均 Bug 数 | +9% |
| 代码churn（两周内被改写比例） | 3.1% → 5.7% |
前两行是厂商 PPT 的第三页。后四行是真实发生的工程系统。
更刺眼的是最后那个 churn：从 3.1% 涨到 5.7%，意味着大量以 AI 速度生产出来的代码，在两周内就被作者或审查者自己重写了一遍。你没有交付两倍的软件，你把同一份软件写了两遍。
LinearB 的 2026 基准报告用了更大的样本------42 个国家、4,800 个团队、810 万个 PR，结论更不客气：AI 生成的 PR 平均含 10.83 个问题，人工写的是 6.45 个（1.7 倍）；严重问题 +40%，逻辑错误 +75%，可读性问题翻三倍；接受率 32.7%，而人工代码是 84.4%。
三分之二的 AI 生成 PR 被拒或废弃。这不是"更快交付"，这是以空前的速度制造废料。
还有那笔隐藏税：资深工程师审查每条 AI 建议平均花 4.3 分钟，人工代码是 1.2 分钟------3.6 倍。而你的资深工程师并没有因此多出 98% 的时间。结果就是 31% 的 PR 在几乎没有实质审查的情况下被合并，组织的免疫系统开始失灵。
CircleCI 的《2026 软件交付现状》（2,800 万+ 工作流）从另一个单位测到了同一件事：特性分支吞吐中位数 +15%，主干分支吞吐中位数 −7%。 写得更多，交付得更少。
2.1 行业主流药方是"给审查加 AI"，但这剂药下错了层
面对这道堵塞的闸门，绝大多数团队的第一反应是：让 AI 也来审查。这条路确实有效，值得尊重------Cloudflare 的内部 AI 审查系统是公开案例里做得最扎实的：按 diff 体积、文件数、是否触碰安全敏感路径，把合并请求分成 trivial / lite / full 三级；trivial（约 ≤10 行）走薄审，full 才上完整专家面板。他们用一个月跑出了 5,169 个仓库、48,095 个合并请求、131,246 次审查，中位耗时 3 分 39 秒，平均成本约 1.19 美元，break-glass 人工兜底占 0.6%。
这组数字说明三件事：分级是对的、 AI 审查可以规模化、成本可以压到很低。但它同时暴露了一个更根本的问题------Cloudflare 这套系统优化的是"如何更快地判断最终产物对不对"，它读的依然是那个已经冷却的 diff。
再快的审查者，面对的也只是一份被剥离了上下文的成品。它能告诉你这行代码有越权风险，它没法告诉你 Agent 为什么放弃了上一个更安全的写法------因为那个信息从来没被写进任何地方。
于是我们看到一个荒诞的局面：生成侧的上下文越来越丰富（Agent 有几万 token 的推理轨迹），审查侧的上下文却越来越贫瘠（只剩一个 diff）。 中间那道信息断层，才是审查耗时增长 91% 的真正来源。加派人手、加派 AI 去读同一个贫瘠的 diff，都是在同一层里打转。
最后一根钉子：Faros 在公司层面发现，AI 采用率与交付效率之间，没有统计上显著的相关性。 个人提速 21%，组织原地不动。增益在到达客户之前，全部蒸发在审查队列里。
用阿姆达尔定律的话说：生成这一环被加速了 20 倍，而它根本不是瓶颈。瓶颈是"有人愿意为这次合并署名"。
三、技术解剖：DeltaDB 到底动了哪一层
2026 年 6 月 11 日 Zed 公开了 DeltaDB，8 月 12 日 Delta 应用进入私有 beta。它是当前对这个问题最彻底的回答，值得逐层拆开看。
3.1 从"快照"到"操作流"
Git 在每次提交处存一张快照，中间发生的一切不进历史。DeltaDB 反过来：它把工作拆成一条细粒度的 delta 流，每一次编辑操作都被记录下来，并被赋予一个稳定的身份（stable identity）。
差别不在于"记得更细"，而在于可寻址性 。Git 里的历史是"第 N 次提交时的状态"，你不能指着"第 7 次编辑之后、第 8 次编辑之前"的那个瞬间------那个瞬间从未存在过。而在 DeltaDB 里，每一个 delta 都能被单独索引，于是你可以在代码持续演进的同时，指向它演化过程中的任意一刻。
一句话对比：Git 是家庭相册，每次聚会拍一张摆拍照，两次快门之间发生的一切永久丢失；DeltaDB 是角落里那台从没关过的监控。
3.2 锚点：行号是坐标，delta 是身份
这一条最容易被滑过去，却是日常体验里最要命的。
传统 review 里，评论挂在"文件 F 的第 214 行"。问题是行号是一种会被下一次编辑作废的坐标系。你打开一个六天前的 review 线程，发现所有评论都指向了空白------这个场景每个工程师都经历过。
Delta 的做法是：评论挂在 delta 上，不挂在行号上。Zed 的原话是------"因为每个引用都锚定在 delta 上而不是行号上，它能在代码从下面移动时存活下来。"
由此得到双向可追溯：从对话里的任意一行，你可以跳到这段代码此刻的样子，也可以跳到 Agent 写下它的那一瞬间；反过来，从任意一行代码，你可以找到产生它的那段对话，以及此后触碰过它的每一段对话。
3.3 为什么是 CRDT，而不是 OT
要让多人、多 Agent 在不同机器上同时编辑同一份代码并保证收敛，历史上只有两条路。
OT（Operational Transformation）：收到远端操作时，先把它"转换"一下，以反映并发发生的变化。概念简单，但定义一个正确且高性能的转换函数极难------这是一整个计算机科学子学科。
CRDT（无冲突复制数据类型） ：不去转换操作，而是把数据结构设计成并发操作天然可交换。Zed 在 2017 年先试过 OT，最终选了 CRDT，理由是它更强大也更直觉。
关键手法是：把编辑表达为逻辑位置 而非绝对偏移。朴素想法是"在文本 68, 之后插入"------但这行不通，因为 68, 可能出现多次，也可能被并发删除。所以真正的做法是给每一个字符片段一个稳定的逻辑标识（Zed 用 copy-on-write B 树索引这些片段，避免线性扫描）。
这套机制原本是为 Google Docs 式的协同编辑设计的。DeltaDB 的洞察在于：让多人同时编辑不冲突的同一个原语，也正是给你提供历史的那个原语。 复制和版本控制，在底层是同一件事的两面。
3.4 对话进版本库，但 Git 照旧
这里有个关键的工程克制：Delta 不是 Git 的替代品，它是 Git 漏掉那一层的补丁。
- DeltaDB 与你已有的 Git 仓库协同工作，每一次编辑和对话都记录在提交之间；
- 你照常
commit、照常push，没装 Delta 的同事看到的仍然是一个正常的 Git 仓库；
- 每个参与者本地都有一份真实的代码副本（worktree），实时同步------不是共享光标的托管工作区，而是被复制的工作树；
- 云端 runner：合上笔记本，Agent 继续跑，对话和代码与线程保持同步；
- 浏览器端是同一个 Rust 应用编译到 WebAssembly + WebGL，不是 HTML 做的阉割版；
- 文件和 Agent 编辑的都是真实文件，你随时可以把整个 worktree 挂载到磁盘上用自己的工具处理。
这个"叠加而非替换"的姿态，是它比历史上所有 Git 挑战者更有可能活下来的原因。
3.5 ACP：别让这件事被锁在一家公司里
如果这套能力只能绑在 Zed 自己的 Agent 上，它就只是又一个围墙花园。桥接用的是 ACP（Agent Client Protocol）------一个把任意编辑器接到任意 Agent 的开放协议，Apache 2.0，Zed 于 2025 年 8 月发起，目前约 4,000 star，官方 SDK 覆盖 Rust、TypeScript、Python、Java、Kotlin。
截至 2026 年 8 月中旬的公开目录统计：37 个 Agent、31 个桌面/Web 客户端、13 个编辑器/IDE、6 个 CLI/TUI 已实现 ACP，包括 Codex CLI、Gemini CLI、GitHub Copilot、Cursor、Cline、Goose、OpenCode、OpenHands、Kimi CLI、Junie 等。Delta 首个接入的第三方 harness 是 Claude Code------你在终端里照常用 Claude Code，会话实时同步进 Delta 线程，同事能看到对话和代码一起演化，就地评论，随时接手。
协议先行的意义在于：就算 Delta 这个产品失败了，"编辑器 × Agent"的乘法适配成本被压成加法这件事，已经不可逆。
3.6 一天的推演：从"考古"到"追问"
抽象机制讲完了，把它落到一个具体的周二下午，差别才看得清。
旧流程。 你的同事让 Agent 重构支付模块，中途改了主意两次，最后提交一个 800 行的 PR。你在 GitHub 上打开它，看到 47 个文件变更、一句 "refactor: unify payment flow"。你想问"为什么这里放弃了原来的幂等键方案"，但写这个决定的不是你同事，是模型在第三步的一个判断，而这个判断在提交时就被丢掉了。你只能读代码猜。猜不出来就在行内留个评论，等第二天。如果这时代码又改了一版，你那条挂在 214 行的评论就此悬空，指向一片空白。三天后，这段代码带着一个没人说得清的理由进了主干。
Delta 流程。 同事把那个线程链接甩给你。你打开它，看到的是对话和代码并排在一起的那个下午 ------Agent 的第四步提出用幂等键，第六步自己发现跨服务调用会破坏顺序性，于是改成了去重表；同事在第九步插了一句"这里的重试必须幂等"，Agent 据此又调整了一版。你在第六步那个位置点一下，光标落在 Agent 当时的推理段落上，直接问它："为什么不用幂等键？"它答得出来，因为它还在这个线程里，还持有当初那套上下文。你满意了，就地留个评论------这条评论挂在那个 delta 上，此后代码再怎么移动，它都跟着走。
两个流程的最终产物可能一模一样。差别在于：前者你花了四十分钟做考古，后者你花了四分钟做追问。 而那三十六分钟的差值，乘以一个团队每周的 PR 数，就是 Faros 测到的那 91%。
四、这不是第一次：补丁理论的三十年轮回
如果把视野拉开，"Git 的数据模型不够用"这个判断一点都不新。这是一场打了三十年的仗。
Darcs（2003） 是第一个认真尝试的：不存快照，存补丁，用补丁代数（patch theory）推导合并。它的洞见是对的------如果两个补丁改的是不相干的地方，应用顺序就不该影响结果。但它死在了指数级的最坏情况上：某些合并序列会让计算量爆炸。这是"理论上优雅、工程上崩塌"的经典案例。
Pijul（2015，Rust） 是精神上的继承人。它被描述为"文件的最小通用化：以字节的插入和删除为两种操作的 CRDT"。补丁可交换，于是 rebase 天然干净、cherry-pick 不产生幻影冲突、历史是变更的偏序而非线性的叙事。它至今活着，但生态远小于 Git。
Git 达到的是一个极强的"局部最优"。 Hacker News 上有段评价很公道："Git 达到了'足够好'这个令人难以置信的局部最优......它的递归和 ORT 合并策略复杂归复杂，但远远'足够好'，背后有大量的工程智慧。" 一个补丁语言的拥护者在同一帖里承认：杀手级特性其实是 cherry-pick------在 Git 里它制造出一堆身份全异的新提交，是糟糕合并的最大来源之一；而在补丁代数里它是原生操作。
Jujutsu（jj，2019 起，现由 Google 全职开发） 走出第三条路：不推翻 Git 的数据模型，把 Git 当存储后端，改用户模型 。工作副本即提交（没有暂存区、没有 stash）、操作日志让一切可撤销、冲突是一等对象可以带着走、修改父提交后所有后代自动 rebase。它已在 Google 内部生产使用，GitHub 星标 3 万+，甚至反过来影响了 Git 本身------Git 2.54 实验性的 git history 命令和可插拔对象数据库，都带着 jj 的影子。
|---------------|-------------------------|------------------|--------------------|---------------|
| 路线 | 数据模型 | 核心主张 | 对"过程"的态度 | 处境 |
| Git | 提交处快照 + DAG | 状态可靠、内容寻址、够快 | 不记录提交之间的过程 | 事实标准 |
| Darcs / Pijul | 补丁代数（可交换） | 合并是数学问题不是启发式 | 记录变更而非状态，但不记录"为什么" | 小众但活着 |
| Jujutsu | Git 后端 + 新用户模型 | 消除暂存区、冲突一等、操作可撤销 | 记录操作历史，可回放撤销 | Google 在用，生态薄 |
| DeltaDB | op-based CRDT 的 delta 流 | 对话与代码同为一个共享产物 | 把对话本身当作过程的载体 | 私有 beta |
看出区别了吗？前面三条路线争的都是**"怎么合并更好"** 。只有 DeltaDB 这一条的驱动力完全不同------它要解决的不是合并，是**"这段代码的意图是什么"** 。补丁理论家们想要更好的代数，Zed 想要的是把那场对话留下来。
这是三十年来第一次，版本控制的改进目标从"变更如何组合"转向了"意图如何留存"。
五、反方意见：这些质疑必须摆上桌
任何声称"Git 不够用了"的方案，都必须挨过最狠的那一轮质疑。Hacker News 上的真实反对意见，一条都不该被略过。
质疑一：全量留痕 = 职场监控？
Delta 记录每一次编辑和每一句话，而且是永久的。开发者习惯了提交之前的探索------死胡同、半成品、愚蠢的尝试------都留在本机。现在这些东西被序列化、同步、可能上传云端。
更麻烦的是，截至本文写作时，Delta 官方对定价、加密方式、数据留存期限、删除机制只字未提 。HN 上已经有人把这种细粒度历史直接比作 bossware："提示词质量"会不会变成一项绩效考核指标？事故复盘会不会变成回放你和 Agent 的私聊？ 这些不是阴谋论，是任何企业级工具上线前必须回答的问题。Zed 还没回答。
质疑二：实时多人编辑是不是伪需求？
不少开发者的真实感受是：编程本质上是单人活动，pair programming 和 live share 是 niches 且累人。如果 Delta 的价值主要建立在"大家一起实时编辑"上，它可能押错了注。更温和也更可信的说法是：Delta 真正的价值是异步的共享上下文，而不是同步编辑。
质疑三：保存整段对话，不如写一份 ADR？
这是最锋利的一击。对话是冗长、游移、充满废弃分支的；而 ADR、设计文档、规格说明是经过蒸馏的。把原始对话存档，会不会反而挤掉写文档的动力？ 有人担心 LLM 生成的文档会变成"冗长的时间线"而不是干净的规格。
这个质疑击中了要害，但击不倒命题：对话和规格不是替代关系，是证据和结论的关系。 你需要 ADR 来回答"决定是什么"，你同样需要过程来回答"当时为什么不选另一条路"------而后者恰恰是 ADR 永远写不出来的东西。理想结构是：对话是可回溯的底层证据，规格是从中蒸馏出来的顶层结论，两者互相锚定。
质疑四：Git + 频繁提交，或者 jj 的快照，够不够用？
相当多的人说：我从没需要过这个粒度的历史，勤快点提交就行了，或者用 jj 的自动快照。这是合理的。但要注意区分：jj 记录的是"仓库操作"（你做了什么），DeltaDB 记录的是"编辑操作 + 产生它的对话"（你为什么这么做）。 前者能让你撤销，后者能让你理解。这两件事的差距，就是"我把改动回滚了"和"我知道当初为什么这么写"的差距。
质疑五：Zed 自己是不是重心跑偏了？
一批老用户在抱怨编辑器本身的 bug、LSP 稳定性、SSH/WSL 支持还没修好，就去做 VCS 这种量级的基建；还有人把这一切归因于 VC 压力------纯编辑器难变现，AI 工作流好卖，以及担心未来许可变更、无法自托管。这些担忧都成立，且不会因为产品做得好而自动消失。
我的判断：DeltaDB 的这个命题是对的，Delta 这个产品还远未证明自己。 命题和产品要分开看。就算 Zed 明天关门，"把对话和代码一起版本化"这件事，也会由别人做出来------因为驱动它的不是某家公司的战略，是代码生产方式的改变。
六、如果过程真的被完整记住，软件工程会变成什么样
假设这套东西真的成了。往远看一步，有四件事会变。
第一，代码考古变成意图检索。 今天新人想搞懂一段三年前的代码，靠的是猜、问人、翻 issue。将来他可以直接问："这段代码是哪次对话产生的？当时为什么不用 B 方案？"------而且能得到带证据的回答。Zed 描述得更进一步：新的 Agent 可以"召集"之前写过这段代码的 Agent，问它为什么这么写。 这听起来荒诞，但它解决的是软件工程最贵的一个成本：知识只存在于已经离职的人脑子里。
第二，审计的单位从"代码"变成"决定"。 在金融、医疗、航空这些受监管行业，合规审查的对象一直是代码和配置。当代码由 Agent 大量生成，真正需要被审计的是产生这个改动的推理链条。过程日志会成为新的合规资产------也会成为新的法律风险（你的 Agent 说过什么，可能要在法庭上被读出来）。
第三，训练数据的新矿。 Agent 的决策轨迹------它试错了什么、为什么推翻自己、人类在哪一步插手纠正------是比最终代码珍贵得多的训练信号。这也是为什么"这些数据归谁、能不能被拿去训练"会成为下一个战场。你在 Delta 线程里的每一次纠偏，都可能在给下一代模型当老师。
第四，也是必须说清楚的风险：意图的通货膨胀。 当所有过程都被记录，噪音会淹没信号。一次 Agent 会话可能产生几百次编辑、几万 token 的推理，全量留存的边际价值递减得很快。真正稀缺的不是存储，是从过程里蒸馏出结论的能力------这恰恰又回到了规格、ADR、测试用例这些"老"东西上。工具能帮你留下过程，但把过程变成知识，仍然只能靠人。
七、程序员的位置：从"写清楚代码"到"写清楚为什么"
回到开头那个场景：Agent 改了 11 个文件，你面前是一个 diff。
在旧世界里，你的工作是读懂这个 diff。在新世界里，你的工作变成了另一件事------判断产生这个 diff 的那个过程值不值得信任。
这两件事需要的不是同一种能力。读 diff 靠的是代码能力；判断过程靠的是理解意图、识别错误前提、在 Agent 走偏的第七步而不是第四十七步叫停 。所以过去的 2026 年才会出现那个反直觉的数据：资深工程师审查 AI 代码的单位时间是人工代码的 3.6 倍，而整体交付速度纹丝不动。不是人不努力，是这套工具把最稀缺的注意力放在了最不产生信息的地方------放在了已经冷却的产物上，而不是还热着的意图上。
版本控制从"管代码"走向"管意图"，是这个错位的一次系统性修正。它不会让审查变轻松，但它会让审查变得有信息可依------你不用再从 diff 里考古意图，你可以直接问。
Git 不会消失，就像它逼走了 Darcs、逼退了 Mercurial 之后依然站在那里。但 Git 之上的那一层，正在被重新发明。
二十年前我们把"改了什么"交给了机器，现在我们把"为什么改"也交出去了。真正的分水岭不在于你还能不能手写那几行代码，而在于------当机器把所有的"怎么做的"都做完，你还能不能说清楚"为什么"。
说不清楚的人，审查的是别人的决定；说得清楚的人，定义的是别人的上下文。
主要事实来源：Zed 官方博客《Software Is Made Between Commits》(2026-06-11) 与《Introducing Delta》(2026-08-12)、《How CRDTs make multiplayer text editing part of Zed's DNA》；Faros AI《Acceleration Whiplash》2026（22,000 开发者 / 1,255 团队）；LinearB 2026 软件工程基准（810 万 PR / 4,800 团队 / 42 国）；CircleCI《2026 软件交付现状》（2,800 万+ 工作流）；Agent Client Protocol 公开目录（2026-08 统计）；Hacker News 关于 DeltaDB 与 Delta 的讨论 threads；Jujutsu 项目仓库与 changelog。