GitHub前創始人拿了a16z的1700萬美元，做Agent時代的Git

你有沒有想過，編程這件事情可能徹底變了？開發者正在從單純使用AI工具，轉向將AI視為構建軟件的全新基礎。這不是什么小調整，而是一場徹底的范式轉變。想想看，那些我們一直習以為常的核心概念——版本控制、分支、代碼審查，甚至"協作"的定義——都在因為AI agent驅動的工作流而被重新定義。更讓我震驚的是，我們每天都在用的Git，其實是一個為20年前的郵件列表補丁工作流設計的工具，現在卻要服務于人類開發者和一群AI agent同時工作的場景。

這就是為什么GitButler剛剛獲得1700萬美元A輪融資的消息讓我停下來認真思考。這輪融資由a16z領投，Fly Ventures和A Capital繼續跟進。更有意思的是，GitButler的CEO Scott Chacon是GitHub的聯合創始人之一，他寫過那本幾乎每個開發者都讀過的《Pro Git》。一個已經在版本控制領域取得巨大成功的人，為什么要回到創業賽道，重新思考這個看似已經"解決"的問題？他在公告中說得很直白："我們不是在構建一個'更好的Git'，我們是在構建軟件構建方式的下一代基礎設施。"這句話背后隱藏著對軟件開發未來的深刻洞察。

PS：我的出海新書已經上架了，我特意申請了公眾號讀者專屬的優惠鏈接，可以享受半價折扣，歡迎感興趣的朋友購買。

同時我還特地建立了實名制的讀者群，我會在群里定期解答一些問題和開展線上線下活動，歡迎購書的朋友實名制入群，大家一塊交流，共同出海！

Git的20年困局：為郵件列表設計的工具

我發現很多人并不了解Git的歷史背景。Git最初是Linux內核團隊在2005年創建的，它的設計哲學深深植根于Unix傳統。Scott在訪談中提到了一個有趣的細節：Git的核心團隊從來沒打算做一個用戶友好的界面。他們遵循Unix哲學，構建了一系列底層的"管道命令"，每個命令做一件簡單的事情，然后你可以用Perl腳本把它們串起來，做任何你想做的事情。這種設計思想在當時非常合理，因為他們假設只有Linux核心團隊這樣的技術專家會使用這個工具。

后來發生的事情大家都知道了。有個叫Pasquy的開發者寫了一些Perl腳本，給Git包裝了一個統一的用戶界面，也就是我們現在用的CLI命令。這些腳本變得越來越流行，最終被合并到Git核心中，成為了所謂的"瓷器層"（porcelain）。有意思的是，這些命令從2005、2006年以來基本沒有大的變化。它們最初是用Perl寫的，后來被重寫成C，但核心邏輯和用戶界面幾乎保持原樣。Scott說他在2009年寫《Pro Git》第一版時描述的那些命令，現在依然可以完全照搬使用。

這種穩定性在某種程度上是好事。Git團隊非常重視向后兼容性，他們不愿意移除任何已存在的功能，擔心會破壞現有工作流。但這也帶來了一個根本問題：Git被設計時的核心假設，已經跟現在的軟件開發實踐嚴重脫節了。Git是為了通過郵件列表發送補丁而設計的。那個時代，開發者會在本地做一些修改，生成一個補丁文件，通過郵件發送給維護者，維護者審查后決定是否接受。整個流程是異步的、基于文本的、單線程的。

而現在呢？我們有持續集成、持續部署，有分布式團隊實時協作，有代碼審查工具，有各種自動化測試和部署流水線。更重要的是，現在有AI agent在大規模地寫代碼。Scott提到一個讓我印象深刻的觀察：我們現在正在教一群AI agent使用一個為郵件列表補丁設計的工具。這種錯位感，就像是讓一輛特斯拉走在為馬車設計的道路上。

Git的Unix哲學設計帶來了另一個問題：它試圖用一套接口同時服務計算機和人類。如果你運行"git branch"，默認情況下你只會得到一個分支列表，沒有任何用戶界面。這是因為Git需要確保這個命令的輸出既可以被人類閱讀，也可以被其他程序解析。這種妥協導致了一個結果：Git對人類來說不夠友好，對計算機程序來說也不夠優化。雖然有些命令提供了"--porcelain"選項來輸出機器可讀的格式，但這不是標準做法，很多命令根本沒有這個選項。

AI Agent時代的新挑戰：一個工作目錄已經不夠用了

當AI開始大規模參與編程時，Git的局限性變得更加明顯。我自己最近也在嘗試使用多個AI agent同時工作，發現Git的基本設計假設——一個開發者、一個分支、一個線性工作流——已經完全不適用了。現代開發者不是線性工作的。你可能同時運行多個agent，一個在修復UI bug，另一個在優化數據庫查詢，第三個在更新文檔。但Git的索引系統在這種并行編輯下會崩潰，因為它假設你本地的工作副本代表的是對代碼庫的單一、原子性的修改。

傳統的解決方案是使用worktree，也就是為每個并行任務創建代碼庫的多個副本。但這帶來了新問題。如果你有五個agent同時工作，你就需要五個完整的工作目錄副本。雖然Git在存儲層面做了優化，但這仍然意味著大量的文件復制和磁盤空間占用。更重要的是，這些agent之間是完全隔離的，它們看不到彼此在做什么，直到它們各自完成并嘗試合并時才會發現沖突。到那時候，解決沖突的成本已經非常高了。

GitButler提出的解決方案是并行分支（parallel branches）。這是一個讓我眼前一亮的設計。并行分支就像普通分支，但你可以同時打開多個。你可以獲得worktree的好處（邏輯隔離），但不需要復制所有文件。所有的agent都在同一個工作目錄中操作，但它們的修改被分配到不同的虛擬分支中。Scott在訪談中描述了一個讓我印象深刻的場景：他們讓兩個agent同時工作，這兩個agent都想編輯同一個文件，但修改方式不兼容。結果是什么？一個agent自動把它的分支堆疊在另一個agent的分支之上，然后繼續工作，提交到它自己的堆疊部分。這種智能的沖突處理，在傳統Git工作流中幾乎不可能實現。

我特別欣賞GitButler團隊的一個實驗，雖然最終他們沒有采用。他們曾經嘗試讓多個agent之間有一個聊天頻道，讓它們可以互相溝通正在做什么。Scott說這個功能看起來超級酷，他們可以看到agent之間的對話，非常想把它發布出去。但經過大量測試后，他們發現這個功能其實沒有幫助。Agent會自己發現有其他人在修改某個文件，會自動推斷原因，然后調整自己的工作策略。它們不需要顯式的通信，因為通信本身帶來了開銷，反而讓整個過程變慢了。這個發現本身就很有啟發性：我們不能簡單地把人類的協作模式套用到agent身上，agent有自己的工作方式。

重新設計用戶界面：為人類、為agent、為腳本

GitButler最近發布的CLI工具引起了我很大的興趣。這不是一個簡單的Git包裝器，而是從根本上重新思考了命令行工具應該如何設計。Scott提到了一個有趣的觀察：大約80%的開發者仍然使用命令行工具來操作Git，即使有各種GUI工具存在。原因很簡單——大多數Git GUI只是把Git命令包裝了一層圖形界面，并沒有增加太多功能，反而讓操作變慢了。如果你知道要運行什么命令，直接敲命令往往更快。

但GitButler的CLI不一樣。它針對不同的使用場景提供了不同的輸出格式。如果你直接運行命令，它會給你優化過的、人類可讀的輸出，包括提示和建議。如果你加上"--json"參數，它會給你結構化的JSON數據，方便腳本解析。他們甚至在考慮添加"--markdown"選項，專門為agent優化輸出格式，因為markdown格式更容易被注入到agent的上下文中。

更有意思的是，他們通過實際觀察agent的行為來優化工具設計。他們發現，雖然提供了"--json"選項，但agent其實更喜歡使用人類可讀的輸出，然后自己通過管道傳給jq或寫Python腳本來提取需要的信息。另一個發現是，agent在運行任何修改性命令后，幾乎總是會立即運行"git status"查看狀態。所以GitButler團隊直接在所有修改性命令中添加了"--status-after"選項，執行完操作后自動顯示狀態。這種設計在傳統Unix哲學中是不會做的，對腳本編程也不太適合，但對agent來說卻是完美的。

他們還在探索如何通過輸出給agent提供更多上下文信息。比如，在命令輸出中包含"如果你想做這個，運行這個命令"的提示。這不是給人類看的，因為人類會覺得啰嗦，但對agent來說，這種額外的上下文可以幫助它更快地決定下一步該做什么。Scott說這是一個非常有趣的UX問題，因為我們必須把agent當作一種新的"用戶畫像"來對待，而它的需求和行為模式跟人類完全不同。

軟件開發的本質變化：從寫代碼到寫規格說明

在訪談中，Scott提到了一個讓我深思的觀點：未來最優秀的軟件工程師，可能不是那些代碼寫得最好的人，而是那些最會溝通、最會寫作、最會描述的人。這聽起來可能有點反直覺，畢竟我們很多人當初選擇編程就是因為可以跟機器打交道，而不是跟人打交道。但仔細想想，這個趨勢是完全合理的。

當AI agent可以高效地生成代碼時，瓶頸不再是實現細節，而是你能不能清楚地描述你想要什么。Scott分享了他自己的工作流程：他現在大部分時間都在寫規格說明，詳細描述一個功能應該如何工作。每當有一個設計決策需要做時，他就讓AI根據規格說明實現，然后測試結果。如果有問題，他就回去修改規格說明，告訴AI重新實現。這個循環可以非?？焖俚剡M行，因為他不需要自己手寫所有的實現代碼。

這種工作方式的美妙之處在于，你可以隨時做"展示和討論"（show and tell）。傳統上，如果你想驗證一個想法，你需要寫一個詳細的技術文檔，然后說服團隊成員閱讀并提供反饋。但文檔再詳細，也不如一個可以運行的原型直觀。現在，你可以快速生成一個原型，讓團隊成員實際體驗，然后基于反饋迅速迭代。這大大加快了從想法到驗證的周期。

但這也帶來了新的挑戰。團隊協作的瓶頸從"能不能實現這個功能"變成了"我們能不能就想要什么達成共識"。Scott說，很多開發者，特別是那些自認為很聰明的開發者，覺得他們不需要解釋自己在做什么，代碼本身就是最好的文檔。但在AI時代，這種態度行不通了。你必須能夠清晰地表達你的意圖，能夠寫出讓團隊成員和AI都能理解的規格說明。寫作能力，成為了新的超級能力。

這讓我想到代碼審查的未來。Scott提出了一個尖銳的問題：如果你誠實地問大多數軟件工程師，在做代碼審查時，你真的會仔細讀完整個PR嗎？會逐行思考邏輯嗎？會把代碼拉到本地測試嗎？還是只是粗略瀏覽一下，確認看起來沒有明顯問題，然后就批準了？大多數人會選擇后者。這不是因為開發者不負責任，而是因為徹底的代碼審查成本太高，而收益往往不夠明顯。

AI agent在這方面可能會改變游戲規則。Agent非常擅長仔細審查每一行代碼，運行測試，檢查潛在問題。它們不會累，不會厭煩，可以保持一致的審查標準。這樣，人類審查者就可以專注于高層次的問題：這個改動是否符合產品方向？是否解決了用戶的真實需求？架構設計是否合理？而具體的實現細節、語法問題、潛在bug，可以交給AI來檢查。

PR和Issue：20年沒變的協作模式該進化了

GitHub的Pull Request機制已經成為開源協作的標準模式，但Scott認為這個模式存在根本性問題。PR是基于分支的審查，不是基于補丁的審查。這導致了大量的"提交垃圾"——那些"哎呀，修復了一個小bug"、"忘記添加這個文件了"之類的提交信息。因為在PR模式下，重要的是整個分支，而不是單個提交。所以沒人真正關心提交信息的質量，PR描述才是關鍵，而PR描述并不存儲在Git歷史中，合并后通常就丟失了。

在郵件列表時代，這不是問題。每個補丁都有一個精心編寫的提交信息，因為那就是你的PR描述。審查是基于補丁的，補丁的質量和提交信息的質量直接相關。但在GitHub時代，我們失去了這種約束。Scott認為，未來的代碼審查應該回歸到基于補丁的模式，但要結合現代工具的優勢。審查應該是本地的，你可以實際運行代碼、測試功能。Agent可以幫你運行各種測試，標記潛在問題，你只需要關注那些真正需要人類判斷的部分。

還有一個有趣的觀點是關于團隊間溝通的。Scott說，軟件開發中一直做得不好的事情是團隊間的實時溝通。如果你在修改某個文件，我也在修改同一個文件，我們通常要到最后合并時才會發現沖突，然后其中一個人要承擔100%的合并工作。但如果我們能夠實時知道對方在做什么呢？對人類來說，這種實時溝通的開銷可能太大，會打斷工作流程。但對agent來說，這不是問題。Agent可以用它們的空閑時間互相溝通，了解團隊中其他人（或其他agent）在做什么，提前發現潛在沖突，或者主動調整工作策略避免沖突。

GitButler正在探索的元數據系統也很有意思。他們想要能夠把對話記錄、agent的思考過程、相關的上下文信息附加到提交或分支上。Git目前對這種元數據的支持非常有限。這些信息可能非常有價值，可以幫助理解為什么做出某個決策，代碼背后的思考過程是什么。但這也帶來了一個大數據問題。Scott提到，即使只是保存文本，這些元數據的規模也會快速膨脹。他們不得不利用Git中一些大型倉庫（如Chrome或Microsoft Office團隊使用的）的技術，來處理這種規模的數據。

我對這場變革的思考

看完GitButler的故事和Scott的訪談，我有一些深刻的感受。軟件開發正在經歷一場根本性的范式轉變，而版本控制系統作為軟件開發的基礎設施，必須隨之演進。Git的設計理念在20年前是先進的，但現在已經成為限制。我們需要的不是"更好的Git"，而是為現代工作流和AI時代重新設計的基礎設施。

讓我特別有共鳴的是Scott關于"邏輯終點"的思考。他說，在做語言學習創業時，很多人看到實時翻譯技術就說語言學習已死。但他反駁說，即使有完美的翻譯器，雙方都需要戴著翻譯器，而且這種溝通體驗遠不如直接用同一種語言交流。他曾經在日本帶著翻譯工作了一周，翻譯很優秀，但這種體驗仍然不好，你不會想用這種方式建立深度關系或開展復雜合作。對于編程也是一樣。AI agent變得再強大，它們也不能完全替代人類的判斷、創造力和溝通能力。

關于GitHub的未來，我覺得Scott的觀點很中肯。GitHub最大的優勢是用戶基數，最大的劣勢是作為大公司很難快速轉向。現在整個行業都在探索什么是"下一個GitHub"，但Scott指出，這個問題本身可能問錯了。GitHub本身就不是任何東西的"下一個"，它創造了一種全新的協作模式。同樣，未來可能會出現一種完全不同的、我們現在還想象不到的協作模式。

我認為GitButler的價值不僅在于它提供的具體功能，更在于它代表的思考方式。他們在質疑那些我們習以為常的假設：為什么一次只能在一個分支上工作？為什么提交必須是線性的？為什么agent和人類要使用同樣的界面？為什么協作必須通過PR和issue進行？這種從第一性原理出發的思考，正是我們在這個快速變化的時代最需要的。

我也意識到，作為開發者，我們需要培養新的技能。寫清晰的規格說明、有效地溝通想法、理解AI agent的工作方式——這些可能比單純的編碼能力更重要。這對很多開發者來說可能是個挑戰，特別是那些選擇編程就是為了避免跟人打交道的人。但這也是一個機會，讓我們從低層次的實現細節中解放出來，專注于更有創造性的工作：定義問題、設計解決方案、做出權衡決策。

GitButler的1700萬美元融資只是一個開始。我相信未來幾年，我們會看到更多重新思考軟件開發基礎設施的嘗試。版本控制、代碼審查、項目管理、測試、部署——這些工具都是在AI之前的時代設計的，都需要重新審視。那些能夠率先適應新范式的開發者和團隊，將在這場變革中獲得巨大優勢。

最終，軟件開發會變成一個更加關注溝通、協作和決策的工作，而不是關注語法和實現細節。這聽起來可能讓一些傳統程序員不安，但我認為這是一件好事。它讓編程變得更加接近解決問題的本質，而不是被技術細節所困擾。當我們不再需要記住復雜的Git命令，不再需要手動解決合并沖突，不再需要花大量時間寫重復性代碼時，我們就可以把精力投入到真正重要的事情上：理解用戶需求、設計優雅的解決方案、創造有價值的產品。這才是軟件開發的核心，也是GitButler試圖幫助我們回歸的方向。

結尾

也歡迎大家留言討論，分享你的觀點！

覺得內容不錯的朋友能夠幫忙右下角點個贊，分享一下。您的每次分享，都是在激勵我不斷產出更好的內容。

歡迎關注深思圈，一起探索更大的世界。

- END -

兩個“特別坑”的AI產品創業方向，你知道嗎

速度將成為AI時代唯一的護城河

a16z重磅預測：Vibe coding贏者通吃？錯了，垂直專業化才是未來