撰文：Leo
你有沒有想過，編程這件事情可能徹底變了？開發者正在從單純使用 AI 工具，轉向將 AI 視為構建軟件的全新基礎。這不是什麼小調整，而是一場徹底的範式轉變。想想看，那些我們一直習以為常的核心概念——版本控制、分支、代碼審查，甚至"協作"的定義——都在因為 AI agent 驅動的工作流而被重新定義。更讓我震驚的是，我們每天都在用的 Git，其實是一個為 20 年前的郵件列表補丁工作流設計的工具，現在卻要服務於人類開發者和一群 AI agent 同時工作的場景。
這就是為什麼 GitButler 剛剛獲得 1700 萬美元 A 輪融資的消息讓我停下來認真思考。這輪融資由 a16z 領投，Fly Ventures 和 A Capital 繼續跟進。更有意思的是，GitButler 的 CEO Scott Chacon 是 GitHub 的聯合創始人之一，他寫過那本幾乎每個開發者都讀過的《Pro Git》。一個已經在版本控制領域取得巨大成功的人，為什麼要回到創業賽道，重新思考這個看似已經"解決"的問題？他在公告中說得很直白："我們不是在構建一個'更好的 Git'，我們是在構建軟件構建方式的下一代基礎設施。"這句話背後隱藏著對軟件開發未來的深刻洞察。
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 重新實現。這個循環可以非常快速地進行，因為他不需要自己手寫所有的實現代碼。
這種工作方式的美妙之處在於，你可以隨時做"展示和討論"（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 試圖幫助我們回歸的方向。
内容來源：TECHUB NEWS
更多精彩內容，請登陸
財華香港網 (https://www.finet.hk/)
現代電視 (http://www.fintv.com)