我从来不是 pull request 的忠实拥护者。
在 agent 出现之前，我们还比较容易相信：围绕快照交换评论的这套仪式，是协作开发软件的一种有效方式。但它其实从来没有真正适合 Zed 团队。我们经常在同一个 worktree 里一起工作，一边写代码一边讨论代码，从而建立信任和共同理解。GitHub 不允许你在提交和推送之前讨论代码；但到了那个时候，我们最重要的对话通常早就结束了。
所以在 2021 年，我们创办 Zed，就是为了摆脱 commit 的限制。我们的计划是先打造一款配得上世界顶尖开发者的编辑器，再在其中提供一种更好的协作方式。当时我们并没有预见到：那些我们多年来在人与人协作语境下思考的问题，会在与 agent 协作时变得更加重要。
越来越多时候，生成代码的那段对话，正在成为软件真正的源头。那段对话是连续展开的，而且必须随着代码变化不断与代码相互参照。以离散 commit 为中心组织起来的 Git，从来不是为支持这种工作方式而设计的。
所以我们正在构建一个能支持它的东西。我们称之为 DeltaDB：一种新型版本控制，建立在单一而连贯的抽象之上，把你与 agent 的对话，以及它们编辑的 worktree，转化为共享 artifact。自从去年秋天我第一次谈到它以来，我们已经取得了大量进展；随着 beta 版本 将在几周内准备就绪，我很期待能分享更多我们即将发布的内容。
记录每一次操作，而不只是每一次提交
DeltaDB 会把你的工作拆分成一条细粒度 delta 流。Git 在每次 commit 时捕获一个快照；而 DeltaDB 会捕获两次 commit 之间的每一次操作，并为每一次操作赋予稳定身份。因为每个 delta 都可以被单独寻址，你就能指向代码演进过程中任意时刻的状态，即使代码仍在继续变化。这让我们可以在 worktree 演进的同时，对它以及驱动它的对话一起做版本管理。
一条消息和它产生的编辑会被并排记录，因此二者不会彼此漂移。由于 DeltaDB 内嵌了无冲突复制的 worktree，多个人和多个 agent 可以跨不同机器同时编辑同一批文件。这些文件是真实存在的：agent 通过终端在其中工作；当你想在上面使用自己的工具时，也可以随时把整个 worktree 挂载到磁盘上。
源代码现在也是源对话
因为每个引用都锚定到 delta，而不是某个行号，所以即使底下的代码移动了，引用仍然成立。从过去对话中的任意一行，你都可以跳转到那段代码现在的样子，或者跳转到 agent 当时写下它的那一刻。从任意一行代码出发，你也可以找到产生它的那段对话，以及此后所有触碰过它的对话。
Agent 也能利用这些信息。它们可以拿到正在修改代码背后的上下文，也可以召集之前处理过这段代码的 agent，询问为什么当初要这样写。
协作不应该以提交为前提
我们真正追求的东西很简单：你与 agent 的对话，应该成为你唯一需要进行的对话。队友可以在工作仍在发生时加入进来，直接和完成这项工作的 agent 交流，并一边推进一边标注，而不必先等你 commit 和 push。
Pull request、review thread 和行内评论之所以存在，是因为讨论和代码原本处在不同地方，所以事后必须把讨论重新贴回代码上。把它们放在同一个地方，这套仪式就会消失。Git 和 CI 继续承担它们擅长的工作：运行检查、把你连接到外部世界；而不是被迫成为协作发生的场所。
接下来会怎样
软件现在是在对话中成形，而不是在 commit 中成形。DeltaDB 正是为此而生的版本控制；再过几周，我们会开始把它交到早期用户手中。
如果你想成为第一批试用者之一，可以加入候补名单。
相关文章
看看 Zed 团队发布的类似博客文章。
正在寻找更好的编辑器？
你现在就可以在 macOS、Windows 或 Linux 上试用 Zed。立即下载！
我们正在招聘！
如果你对我们博客中讨论的话题充满热情，欢迎考虑加入我们的团队，一起交付软件开发的未来。