介紹 DeltaDB：AI 代理時代的版本控制

DeltaDB 將版本控制從快照轉移到操作串流

Zed 正在打造 DeltaDB，以將軟體開發推向超越離散提交的限制。與 Git 不同，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 專屬效用

相反地，一些為非工程師打造工具的開發者認為，對於不遵守嚴格提交規範的人而言，持續的英文討論鏈是表達建構軟體所需「思考鏈」的唯一方式。