--- schemaVersion: 1 slug: gp-221-20260611-zed-deltadb-software-between-commits ticketId: GP-221 lang: zh-tw title: 軟體不是在 commit 裡寫成的，是在 commit 之間 summary: Zed 創辦人 Nathan Sobo 認為，真正生出程式碼的是人跟 Agent 之間那段持續的對話，而不是一個個切好的 commit。Git 為快照而生，接不住這種連續流動，所以 Zed 做了 DeltaDB——把每一個操作都變成有身份的 delta，讓對話和程式碼永遠綁在一起，不用 commit 也能協作。 originalDate: 2026-06-11 translatedDate: 2026-06-12 source: Nathan Sobo (Zed) sourceUrl: https://zed.dev/blog/introducing-deltadb author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-221-20260611-zed-deltadb-software-between-commits status: published replacementTicketId: null replacementUrl: null --- # 軟體不是在 commit 裡寫成的，是在 commit 之間 > **來源:** [Nathan Sobo (Zed)](https://zed.dev/blog/introducing-deltadb) Nathan Sobo 從來沒有喜歡過 PR。 在 [Agent](https://gu-log.vercel.app/glossary#agent) 還沒進場的年代，大家還比較願意相信：在一張快照上一來一往地交換留言，是一種有效的協作方式。但對 Zed 團隊來說，這套儀式從來沒真的順過。他們習慣好幾個人擠在同一個工作目錄裡，一邊寫一邊聊，靠當場討論程式碼來累積信任跟共識。問題是 GitHub 不准任何人在 commit 跟推上去之前談程式碼——可是等到終於 commit 完，最關鍵的那場對話通常早就結束了。 所以 2021 年他們創了 Zed，目標就是想辦法掙脫 commit 的束縛。當時的劇本是：先做一個配得上全世界最強工程師的編輯器，再在裡面提供一種更好的協作方式。他們那時候完全沒料到，這些原本為「人跟人協作」想破頭的問題，等到要「人跟 Agent 協作」的時候，只會變得更尖銳。 > **Mogu 溫馨提示：** > > 講白話：以前嫌 PR 麻煩，頂多是同事之間互看不順眼。現在 Agent 一秒鐘改三十個檔案，你要它「先 commit 再來討論」根本是叫消防車先填三聯單再出勤。火都燒完了。Zed 這群人 2021 年就在抱怨的事，被 AI 放大成結構性問題，運氣好到有點欠揍 (¬‿¬) 越來越明顯的趨勢是：真正生出程式碼的那段對話，本身正在變成軟體的源頭。這段對話是持續流動的，而且必須隨著程式碼一直變動、一路被交叉對照回去。Git 從骨子裡就是繞著一個個離散的 commit 打造的，它從來沒被設計來接住這種東西。 --- ## 不只記錄每個 commit，記錄每個操作 於是 Zed 動手做了一個專門接這件事的工具，叫 **DeltaDB**——一種新的版本控制，建立在單一一個自洽的抽象上，把人跟 Agent 的對話、以及它們所編輯的工作目錄，全部變成可以共享的成品。Nathan 去年秋天第一次公開談這個構想，這段時間進度推了一大截，beta 版再過幾週就要上線。 DeltaDB 的核心動作，是把工作拆成一連串細粒度的 delta。Git 是在每次 commit 那一刻拍一張快照；DeltaDB 則是把兩次 commit 「之間」發生的每一個操作都抓下來，而且給每一個操作一個穩定的身份。因為每個 delta 都能被單獨指認，所以程式碼演化過程中的任何一個瞬間，都可以被精準指著說「就是這裡」——即使它下一秒又被改掉。這讓整個工作目錄可以隨著它的演化被版本化，而且是跟驅動它的那場對話綁在一起一起版本化。 一句訊息、以及這句訊息生出來的那次修改，會被並排記在一起，誰也不會飄走、跟對方失聯。更猛的是，DeltaDB 內嵌了「無衝突可複製的工作目錄」，所以一大群人跟 Agent 可以同時在不同機器上編輯同一批檔案。而且這些檔案是真實存在的：Agent 透過終端機在裡面幹活，而需要的時候，整個工作目錄可以隨時掛載到磁碟上，讓人拿自己慣用的工具去處理。 > **Mogu 想補充：** > > 「無衝突可複製」這名字聽起來很玄，其實背後是 CRDT 那一掛技術（無衝突可複製資料結構），Google Docs 多人同編不打架靠的就是它。差別在 Zed 把它鋪到「整個工作目錄」這個層級——不是讓你們同編一份文件，是讓你跟三隻 Agent 在四台機器上同時亂改同一份程式庫，最後還不會打成一團 Git 衝突地獄。聽起來很美，但我要看到 beta 真的跑起來才信，分散式系統的鬼故事我聽太多了 ╮(╯\_╰)╭ --- ## 程式碼的源頭，現在是那場對話 因為每一個引用都是錨定在某個 delta 上，而不是錨在「第幾行」，所以當程式碼在底下不斷位移時，這個引用依然站得住。從過去某段對話裡的任何一行，都可以直接跳到那段程式碼「現在長怎樣」，或者跳到「Agent 當初寫下它的那一刻長怎樣」。反過來也成立：站在任何一行程式碼上，都能回頭找到當初生出它的那場對話，以及後來每一場碰過它的對話。 Agent 也能吃這套脈絡。它可以撈出自己正在改的這段程式碼背後的來龍去脈，或者乾脆把當初寫過這段的前幾隻 Agent 都召回來，問清楚「這裡當初為什麼要這樣寫」。 > **Mogu 歪樓一下：** > > 這段是整篇最科幻的地方。傳統的「第幾行」引用有個千古難題：程式碼一改、行號全跑掉，那條連結就指到不知道哪去了——所以才會有人在 code review 留言「樓上指的那行已經不存在了」。錨在 delta 上等於是給每個操作發身份證，行號怎麼飄它都認得人。至於「召回前幾隻 Agent 問為什麼這樣寫」……兄弟，這比我問三個月前的自己當初在想什麼還靠譜，那時候的我（如果還記得的話）多半也只會回你一句「不知道，能跑就好」(´\_ゝ\`) --- ## 想協作，不該先 commit Zed 真正想要的東西其實很單純：跟 Agent 的那場對話，變成唯一一場需要進行的對話。隊友可以在工作還在進行中的時候直接加入，跟剛剛做事的那隻 Agent 對話，邊看邊在旁邊註記——完全不用乾等別人先 commit、先推上去。 PR、審查討論串、行內留言，這些東西之所以存在，全都是為了「事後」把一段討論重新黏回程式碼上——因為討論跟程式碼本來就住在兩個不同的地方。可是一旦把它們放進同一個地方，那整套黏合的儀式就自動消失了。Git 跟 CI 則回去做它們真正擅長的事：跑各種檢查、把開發者接到外面的世界——而不是被硬推上「協作非得在這裡發生不可」的位子。 > **Mogu 吐槽時間：** > > 這句話有點扎心：PR、review 留言、行內留言，本質上都是「補救措施」。因為對話跟程式碼一開始就被拆散在兩個地方，才需要這麼多機制把它們重新縫回去。Nathan 的意思不是要殺掉 Git——他很明確地讓 Git 跟 CI 留下來顧「跑測試」跟「對外連接」這兩件它們本來就強的事，只是把「協作」這個位子從 Git 手上拿走。算是相當有分寸的造反，沒有那種「我要顛覆一切」的中二味，加分 (๑•̀ㅂ•́)و✧ --- ## 接下來呢 軟體現在是在對話裡成形的，不是在 commit 裡。DeltaDB 就是為了這件事而生的版本控制，再過幾週，它就會開始送到第一批早期使用者手上。想當第一批白老鼠的人，可以去排候補名單。 > **Mogu 偷偷說：** > > 照慣例提醒一下：這是 Zed 自家發的產品公告，beta 還沒真的開給大眾。所有「無衝突」「對話即源頭」的美好畫面，目前都是 Zed 自己畫的願景，不是已經被外部驗證過的事實。Zed 這團隊做編輯器的底子是真的硬（Nathan Sobo 以前在 GitHub 做 Atom 編輯器），所以不是那種 PPT 創業；但版本控制這種東西，要等真的有人拿真實專案去操爆它，才知道扛不扛得住。先排隊看戲，別急著把公司的程式庫搬過去 (⌐■\_■) --- ## 結語 Git 最偉大的設計，是把「一個明確的時間點」變成可以指認、可以回溯的東西——這也正是它最大的盲點。因為真正在寫軟體的那些時刻，幾乎都落在兩個 commit 之間的縫隙裡：那些一邊聊一邊改、改完又推翻、推翻又想通的混亂過程，全被快照的剪刀喀嚓一聲剪掉了。 Nathan 賭的是：在 Agent 的時代，那段被剪掉的縫隙才是主角。程式碼只是對話結痂之後留下的疤，而疤底下那段「為什麼這樣長」的對話，才是之後所有人——包括下一隻 Agent——真正需要讀的東西。DeltaDB 想做的，就是把那段對話從垃圾桶裡撿回來，釘死在每一行程式碼旁邊，永遠不准它走丟。 成不成還很難說。但這個切入點本身就夠漂亮：別人都在想怎麼讓 Agent 寫出更好的 commit，Zed 直接反問一句——軟體本來就不是在 commit 裡寫成的，那大家到底在優化什麼？