# 策展 · X (Twitter) 🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Saito (@SaitoWu) · 平台：X (Twitter) · 日期：2026-04-23

> 原始來源：https://x.com/SaitoWu/article/2046829706692202686

## 中文摘要

GitHub聯合創辦人揭露Git工具設計缺失。

Scott Chacon直言，Git從未以產品設計角度驅動演進，本質是Linux核心團隊的Perl腳本管道命令，後改寫成C，命令幾乎未變，20年來缺乏明確產品願景。

**GitHub與Git核心團隊關係微妙**

Scott回憶，GitHub初起時，Git核心團隊視其為「不太聰明」，因不會寫C語言。後因大量專案遷移至GitHub，漸生「勉強的尊重」。但Linus真實態度是：GitHub僅「不錯的託管商」，他討厭PR和相關機制，將其視為免費託管，反映核心團隊立場：工具能用即可，誰用無關緊要。

**Git如Frankenstein怪物，無設計感**

Git被形容為「Frankenstein」，功能強大卻無設計感。作為開源專案，任何「看起來還行」想法皆被加入，無人定義產品方向，也無人真正說不。這與具產品願景與品味的GitHub截然不同，Git從未擁有此類導向。

**原始Unix哲學的致命折中**

Git設計遵循Unix哲學：每個命令只做一件事，輸出可pipe給下個命令。但從一開始即為折中，既想機器好用，又想人類可讀，結果兩邊皆未做好。Scott直指：「跑git branch，只列分支，無任何UI。」Git解決底層難題如delta壓縮、wire傳輸協議、tree高效讀寫，但使用者體驗從未是目標。

**AI Agent與Git不相容**

Agent每執行命令須查一次status，interactive rebase對其近乎噩夢。Agent需不斷解析Git文本輸出再決策，但Git從未為此設計。更諷刺的是，Agent仍用sed、grep等20年前Unix工具，甚至許多年輕人透過Agent才學會這些。Git未預見此使用模式，導致Agent互動極不順暢。

**向後相容成文化詛咒**

Git幾乎永保向後相容，「先前存在的一切不會移除」。Scott 2009年寫的《Pro Git》第一版命令至今仍適用。這阻礙「Git 3.0 UI重寫」，不僅技術問題，更是文化：無人願break任何功能，也無人有權決定。

**GitButler解決方案：加層注入產品品味**

Scott不推翻Git，而是「加一層」：保留既有資料儲存與傳輸協議，在使用者介面注入產品品味。GitButler可與普通Git自由切換，為drop-in replacement，非全新物種。目標讓Git「終於像個產品」，使用者無需重學。

**核心創新：Virtual Branches（虛擬並行分支）**

相較常見Git Worktree（多份專案副本、手動合併，流程複雜），GitButler讓所有人（人類或Agent）在同一程式庫工作：
- 用virtual branches隔離改動
- 不複製檔案、不生傳統merge conflict
- 使用戶「感覺」在自己分支，底層無真正分叉
- 改動在loop結束或提交時自動合併
這是真正並行協作，而非隔離副本。

**程式碼審查模式已過時**

Scott直批：「你真會從頭讀完PR嗎？」現實多數人僅掃一眼、無明顯問題即approve。PR帶來「commit slop」如「oops」「fix again」「actually fix」，commit message漸失意義。早期mailing list模式更好：patch即artifact，逼人寫清。Agent時代審查轉為自動拉patch、編譯、跑測試、輸出摘要，成「驗證結果」而非盯UI。

**下個超能力：寫作與溝通**

Scott強調：「未來最強工程師是能溝通、能寫作、能描述的人。」AI讓「how」極廉價，約束轉為「why」與「what」。能清晰定義產品、寫好spec者，方能駕馭Agent。許多開發者習慣腦中邏輯、不解釋，在Agent時代成致命弱點。

**多Agent協作正確方式**

反直覺建議：勿同時跑20個Agent，否則管理災難，不知誰做何事、審查成本爆表。更好方式讓Agent在「空閒時間」溝通，如「我在改此檔案，你別動」。這解決inter-team communication老問題，而Agent最擅長此道。

**Metadata比程式碼更重要**

實驗將資訊直接掛版本控制：
- chat transcript
- tool call logs
- 設計規格
讓版本控制記「為什麼」，而非僅「做了什麼」。但現實問題：每個prompt、每次呼叫皆存，資料量爆炸。曾試CRDT記錄每file buffer save，可回17分鐘前任意狀態，技術酷但UI不可用、資訊過載，最終砍掉。結論：能做出≠人類能用。現在用Git內冷門高級primitive（原為Windows/Office級程式庫設計）解決metadata儲存與擷取。

**終極哲學問題：Agent如停止時間的工程師**

Scott提問：若Agent終點是「停止時間」、無限工作、再恢復的頂級工程師，則問題為：
- 你要用它做什麼？
- 如何管理這「凍結時間」？
- 如何判斷結果已足夠好？
以語言學習比喻：即时翻譯（babblefish）已現，但不等真正會語言，无法建深層關係、創業、懂文化。同樣，Agent會強，但「你到底想要什麼」永為人責。

## 標籤

其他, 產業趨勢, GitHub, Git, Linux
