你有沒有想過，編程這件事情可能徹底變了？開發(fā)者正在從單純使用AI工具，轉(zhuǎn)向?qū)I視為構(gòu)建軟件的全新基礎(chǔ)。這不是什么小調(diào)整，而是一場徹底的范式轉(zhuǎn)變。想想看，那些我們一直習(xí)以為常的核心概念——版本控制、分支、代碼審查，甚至"協(xié)作"的定義——都在因?yàn)锳I agent驅(qū)動的工作流而被重新定義。更讓我震驚的是，我們每天都在用的Git，其實(shí)是一個為20年前的郵件列表補(bǔ)丁工作流設(shè)計(jì)的工具，現(xiàn)在卻要服務(wù)于人類開發(fā)者和一群AI agent同時工作的場景。

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

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

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

Git的20年困局：為郵件列表設(shè)計(jì)的工具

我發(fā)現(xiàn)很多人并不了解Git的歷史背景。Git最初是Linux內(nèi)核團(tuán)隊(duì)在2005年創(chuàng)建的，它的設(shè)計(jì)哲學(xué)深深植根于Unix傳統(tǒng)。Scott在訪談中提到了一個有趣的細(xì)節(jié)：Git的核心團(tuán)隊(duì)從來沒打算做一個用戶友好的界面。他們遵循Unix哲學(xué)，構(gòu)建了一系列底層的"管道命令"，每個命令做一件簡單的事情，然后你可以用Perl腳本把它們串起來，做任何你想做的事情。這種設(shè)計(jì)思想在當(dāng)時非常合理，因?yàn)樗麄兗僭O(shè)只有Linux核心團(tuán)隊(duì)這樣的技術(shù)專家會使用這個工具。

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

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

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

Git的Unix哲學(xué)設(shè)計(jì)帶來了另一個問題：它試圖用一套接口同時服務(wù)計(jì)算機(jī)和人類。如果你運(yùn)行"git branch"，默認(rèn)情況下你只會得到一個分支列表，沒有任何用戶界面。這是因?yàn)镚it需要確保這個命令的輸出既可以被人類閱讀，也可以被其他程序解析。這種妥協(xié)導(dǎo)致了一個結(jié)果：Git對人類來說不夠友好，對計(jì)算機(jī)程序來說也不夠優(yōu)化。雖然有些命令提供了"--porcelain"選項(xiàng)來輸出機(jī)器可讀的格式，但這不是標(biāo)準(zhǔn)做法，很多命令根本沒有這個選項(xiàng)。

AI Agent時代的新挑戰(zhàn)：一個工作目錄已經(jīng)不夠用了

當(dāng)AI開始大規(guī)模參與編程時，Git的局限性變得更加明顯。我自己最近也在嘗試使用多個AI agent同時工作，發(fā)現(xiàn)Git的基本設(shè)計(jì)假設(shè)——一個開發(fā)者、一個分支、一個線性工作流——已經(jīng)完全不適用了?，F(xiàn)代開發(fā)者不是線性工作的。你可能同時運(yùn)行多個agent，一個在修復(fù)UI bug，另一個在優(yōu)化數(shù)據(jù)庫查詢，第三個在更新文檔。但Git的索引系統(tǒng)在這種并行編輯下會崩潰，因?yàn)樗僭O(shè)你本地的工作副本代表的是對代碼庫的單一、原子性的修改。

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

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

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

重新設(shè)計(jì)用戶界面：為人類、為agent、為腳本

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

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

更有意思的是，他們通過實(shí)際觀察agent的行為來優(yōu)化工具設(shè)計(jì)。他們發(fā)現(xiàn)，雖然提供了"--json"選項(xiàng)，但agent其實(shí)更喜歡使用人類可讀的輸出，然后自己通過管道傳給jq或?qū)慞ython腳本來提取需要的信息。另一個發(fā)現(xiàn)是，agent在運(yùn)行任何修改性命令后，幾乎總是會立即運(yùn)行"git status"查看狀態(tài)。所以GitButler團(tuán)隊(duì)直接在所有修改性命令中添加了"--status-after"選項(xiàng)，執(zhí)行完操作后自動顯示狀態(tài)。這種設(shè)計(jì)在傳統(tǒng)Unix哲學(xué)中是不會做的，對腳本編程也不太適合，但對agent來說卻是完美的。

他們還在探索如何通過輸出給agent提供更多上下文信息。比如，在命令輸出中包含"如果你想做這個，運(yùn)行這個命令"的提示。這不是給人類看的，因?yàn)槿祟悤X得啰嗦，但對agent來說，這種額外的上下文可以幫助它更快地決定下一步該做什么。Scott說這是一個非常有趣的UX問題，因?yàn)槲覀儽仨毎補(bǔ)gent當(dāng)作一種新的"用戶畫像"來對待，而它的需求和行為模式跟人類完全不同。

軟件開發(fā)的本質(zhì)變化：從寫代碼到寫規(guī)格說明

在訪談中，Scott提到了一個讓我深思的觀點(diǎn)：未來最優(yōu)秀的軟件工程師，可能不是那些代碼寫得最好的人，而是那些最會溝通、最會寫作、最會描述的人。這聽起來可能有點(diǎn)反直覺，畢竟我們很多人當(dāng)初選擇編程就是因?yàn)榭梢愿鷻C(jī)器打交道，而不是跟人打交道。但仔細(xì)想想，這個趨勢是完全合理的。

當(dāng)AI agent可以高效地生成代碼時，瓶頸不再是實(shí)現(xiàn)細(xì)節(jié)，而是你能不能清楚地描述你想要什么。Scott分享了他自己的工作流程：他現(xiàn)在大部分時間都在寫規(guī)格說明，詳細(xì)描述一個功能應(yīng)該如何工作。每當(dāng)有一個設(shè)計(jì)決策需要做時，他就讓AI根據(jù)規(guī)格說明實(shí)現(xiàn)，然后測試結(jié)果。如果有問題，他就回去修改規(guī)格說明，告訴AI重新實(shí)現(xiàn)。這個循環(huán)可以非?？焖俚剡M(jìn)行，因?yàn)樗恍枰约菏謱懰械膶?shí)現(xiàn)代碼。

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

但這也帶來了新的挑戰(zhàn)。團(tuán)隊(duì)協(xié)作的瓶頸從"能不能實(shí)現(xiàn)這個功能"變成了"我們能不能就想要什么達(dá)成共識"。Scott說，很多開發(fā)者，特別是那些自認(rèn)為很聰明的開發(fā)者，覺得他們不需要解釋自己在做什么，代碼本身就是最好的文檔。但在AI時代，這種態(tài)度行不通了。你必須能夠清晰地表達(dá)你的意圖，能夠?qū)懗鲎寛F(tuán)隊(duì)成員和AI都能理解的規(guī)格說明。寫作能力，成為了新的超級能力。

這讓我想到代碼審查的未來。Scott提出了一個尖銳的問題：如果你誠實(shí)地問大多數(shù)軟件工程師，在做代碼審查時，你真的會仔細(xì)讀完整個PR嗎？會逐行思考邏輯嗎？會把代碼拉到本地測試嗎？還是只是粗略瀏覽一下，確認(rèn)看起來沒有明顯問題，然后就批準(zhǔn)了？大多數(shù)人會選擇后者。這不是因?yàn)殚_發(fā)者不負(fù)責(zé)任，而是因?yàn)閺氐椎拇a審查成本太高，而收益往往不夠明顯。

AI agent在這方面可能會改變游戲規(guī)則。Agent非常擅長仔細(xì)審查每一行代碼，運(yùn)行測試，檢查潛在問題。它們不會累，不會厭煩，可以保持一致的審查標(biāo)準(zhǔn)。這樣，人類審查者就可以專注于高層次的問題：這個改動是否符合產(chǎn)品方向？是否解決了用戶的真實(shí)需求？架構(gòu)設(shè)計(jì)是否合理？而具體的實(shí)現(xiàn)細(xì)節(jié)、語法問題、潛在bug，可以交給AI來檢查。

PR和Issue：20年沒變的協(xié)作模式該進(jìn)化了

GitHub的Pull Request機(jī)制已經(jīng)成為開源協(xié)作的標(biāo)準(zhǔn)模式，但Scott認(rèn)為這個模式存在根本性問題。PR是基于分支的審查，不是基于補(bǔ)丁的審查。這導(dǎo)致了大量的"提交垃圾"——那些"哎呀，修復(fù)了一個小bug"、"忘記添加這個文件了"之類的提交信息。因?yàn)樵赑R模式下，重要的是整個分支，而不是單個提交。所以沒人真正關(guān)心提交信息的質(zhì)量，PR描述才是關(guān)鍵，而PR描述并不存儲在Git歷史中，合并后通常就丟失了。

在郵件列表時代，這不是問題。每個補(bǔ)丁都有一個精心編寫的提交信息，因?yàn)槟蔷褪悄愕腜R描述。審查是基于補(bǔ)丁的，補(bǔ)丁的質(zhì)量和提交信息的質(zhì)量直接相關(guān)。但在GitHub時代，我們失去了這種約束。Scott認(rèn)為，未來的代碼審查應(yīng)該回歸到基于補(bǔ)丁的模式，但要結(jié)合現(xiàn)代工具的優(yōu)勢。審查應(yīng)該是本地的，你可以實(shí)際運(yùn)行代碼、測試功能。Agent可以幫你運(yùn)行各種測試，標(biāo)記潛在問題，你只需要關(guān)注那些真正需要人類判斷的部分。

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

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

我對這場變革的思考

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

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

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

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

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

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

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

結(jié)尾

也歡迎大家留言討論，分享你的觀點(diǎn)！

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

歡迎關(guān)注深思圈，一起探索更大的世界。

- END -

兩個“特別坑”的AI產(chǎn)品創(chuàng)業(yè)方向，你知道嗎

速度將成為AI時代唯一的護(hù)城河

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