廣東
代碼的真正來源是代碼本身，還是產生代碼的那段對話？Zed團隊在官方博客上發表了一篇文章，宣布正在開發一個名為DeltaDB的新版本控制系統，其核心理念是：代碼變更應該與產生這段變更的對話綁定在一起，而非僅僅依賴于Git的提交快照。
https://zed.dev/deltadb
Git的局限性：從快照到操作記錄
Zed的聯合創始人Nathan Sobo在文章中指出了傳統版本控制系統的一個根本性問題：Git的提交機制是基于快照的，而非操作流。每次提交記錄的是"文件在某個時刻的狀態"，而不是"在這個時刻發生了什么操作"。這種模型在面對現代協作場景時顯得過于笨重——你需要等待提交、等待審核、等待合并，然后才能繼續推進工作。
這個問題的本質在于：Git設計于一個代碼審查是可選的、實時協作是罕見奢侈品的時代。而今天，AI智能體可以隨時修改代碼，團隊成員可以實時看到彼此的改動，傳統的"提交-審核-合并"流程正在成為效率的瓶頸。
DeltaDB的設計思路：操作優先，對話綁定
DeltaDB的核心設計理念有兩點：細粒度操作記錄，以及代碼變更與對話的綁定。
第一，DeltaDB記錄每一個操作，而非每一個快照。這意味著你可以在任何時刻回溯到文件的任意狀態，并同時看到產生那次變更的上下文——誰在什么時間做了什么改動、為什么做這個改動。第二，每次代碼變更都與產生它的對話綁定在一起。當你查看一個代碼片段的歷史時，你不僅能看到它是如何演變的，還能直接看到當時團隊成員或AI智能體討論了哪些問題、做出了哪些決策。
這種設計讓"指向歷史中的任意時刻，然后直接跳轉到相關的討論"成為可能。傳統的代碼審查需要單獨開啟一個PR流程、等待評論、記錄反饋，而DeltaDB將這些對話與代碼變更本身視為同一事件的兩面。
實時協作與AI智能體的兼容性
DeltaDB的另一個重要特性是支持實時協作。團隊成員和AI智能體可以在同一個工作樹上同時工作，無需等待提交和推送。這與Git的分支模型形成了鮮明對比——在Git中，你需要處理合并沖突、解決版本差異，而在DeltaDB中，所有操作都是持續的、增量式的，不存在"版本分叉"的概念。
這意味著AI智能體可以真正融入開發流程，而不是作為"偶爾被調用的工具"存在。當AI智能體可以實時看到代碼庫的變化、參與到正在進行的討論中時，它的工作方式將從"響應人類指令"轉變為"與人類共同演進代碼"。
Beta即將發布
Zed團隊表示，DeltaDB的Beta版本預計將在幾周內發布，感興趣的用戶可以在 zed.dev/deltadb 加入等待列表。Git和CI系統仍然有用——它們提供了檢查、外部集成等能力——但協作的核心將轉移到持續演進的工作樹上，而非提交歷史中。
這是一個關于"代碼與對話關系"的重新思考。在AI時代，代碼的來源不再是一個黑箱——每一行代碼背后都有一個可以被追溯的決策過程。DeltaDB試圖讓這個決策過程變得可見、可檢索，而這也許是版本控制在下個時代應有的形態。
參考來源
? https://zed.dev/blog/introducing-deltadb
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
