Aider 與 Paul Gauthier：三十年資歷換來的一句話——AI 最終要跟 Git 說話

1995 年，Paul Gauthier 在 UC Berkeley 的博士研究室裡，寫出了一個讓當時所有人都覺得瘋狂的東西：把搜尋引擎跑在一大堆普通電腦上，而不是一台昂貴的超級電腦。

這個叫做 Inktomi 的系統，後來成為 Yahoo、AOL、微軟必應的搜尋基礎設施，服務了當時全球大多數的搜尋流量。

三十年後，他做了 Aider。

不是因為他需要證明什麼，而是因為他花了三十年在系統工程的核心工作，然後在 2023 年看著所有 AI coding 工具出現，然後覺得：它們都搞錯了一件最重要的事。

AI coding 工具最終必須跟 Git 說話。

• 為什麼你需要認識 Paul Gauthier？
• Paul Gauthier 是誰？
  • Inktomi：網際網路第一個分散式搜尋引擎
  • 從搜尋引擎到 Groupon，再到 IKEA
• Aider 的核心哲學：AI 必須跟 Git 說話
  • 所有人都做錯的一件事
• 三個核心設計
  • 1. Git-First：每次修改都是一個有意義的 Commit
  • 2. Repo Map：理解整個 Codebase，不只是你開的檔案
  • 3. Architect Mode：讓貴的模型想，讓便宜的模型做
• 執行流程架構圖
• SWE-bench 上的成績
• Aider vs 這個系列的其他工具
• 實用建議：三個起步行動
  • 步驟 1：先用 /add 告訴 Aider 你要改哪些檔案
  • 步驟 2：Architect Mode 用在跨檔案的架構修改
  • 步驟 3：定期用 /commit 整理工作
• 我的反思
• 參考資料 (References)

為什麼你需要認識 Paul Gauthier？

這個系列裡，我們寫過：

• 幾個週末打造 OpenClaw 的 Peter Steinberger
• 一個週末打造 GPT-Engineer 的 Anton Osika

Paul Gauthier 不一樣——他不是在週末做實驗，他是在三十年的系統工程積累之後，非常清楚地做了一個工程上正確的決定。

Aider 的設計不是創業者的直覺，而是一個資深工程師對「好的工具應該長什麼樣子」的深刻判斷。

Paul Gauthier 是誰？

Inktomi：網際網路第一個分散式搜尋引擎

Paul Gauthier 在達爾豪斯大學（Dalhousie）取得電腦科學學士（1994），然後到 UC Berkeley 做博士研究，方向是電腦叢集（Computer Clustering）。

他的研究問題是：能不能用一堆普通硬體，做出比超級電腦更快的搜尋系統？

答案是可以——而且他把這個研究成果直接變成了一家公司：Inktomi。

Inktomi 是 1990 年代末、2000 年代初最重要的搜尋基礎設施之一：

• Yahoo、AOL、MSN 的搜尋引擎後端都跑在 Inktomi 上
• 它是商業界第一個以分散式記憶體平行運算為基礎的搜尋引擎
• Gauthier 是共同創辦人兼 CTO，親手從零設計整套系統

這段經歷給了他一個工程師的核心本能：規模、可靠性、系統設計，比任何酷炫的功能都重要。

從搜尋引擎到 Groupon，再到 IKEA

Inktomi 之後，Gauthier 的職涯繼續往後走：

• Ludic Labs：共同創辦人，本地搜尋新創，被 Groupon 收購
• Groupon CTO：帶領全球最大團購平台的技術團隊
• Geomagical Labs：VP of Engineering，開發手機 AR 室內設計技術
• 2021 年，Geomagical Labs 被 IKEA 收購——讓消費者用手機在自己家裡預覽 IKEA 家具的技術，就是他們做的

然後，2023 年 4 月，他做了一個決定：不加入任何公司，自己一個人從頭打造 Aider。

沒有共同創辦人，沒有 VC，沒有辦公室。只有一個資深工程師，一個清晰的問題意識，和三十年的系統工程直覺。

Aider 的核心哲學：AI 必須跟 Git 說話

所有人都做錯的一件事

2023 年初，AI coding 工具開始爆發。Gauthier 仔細看了所有的工具，發現了一個共同問題：

它們都把 Git 當成可選功能，而不是核心架構。

Chat 介面幫你生成程式碼？好，但你怎麼知道它改了哪些檔案？你怎麼回滾？你怎麼跟隊友共享？

Gauthier 的判斷很清晰：一個工程師的工作，最終的記錄就是 Git commit。如果 AI 幫你改的程式碼，沒有乾淨地進 Git，那它幫你做的事情從工程的角度來說是不存在的。

Aider 從第一行程式碼開始，就把「每次修改都是一個 atomic git commit」設計進核心。不是附加功能，而是架構的基礎。

三個核心設計

1. Git-First：每次修改都是一個有意義的 Commit

Aider 的基本操作：你在終端機裡告訴它要做什麼，它修改程式碼，然後自動提交一個有描述性訊息的 git commit。

$ aider --model claude-3-5-sonnet

> 幫我把 user_service.py 裡的密碼儲存從明文改成 bcrypt 加密

Aider 思考中...
→ 讀取 user_service.py
→ 識別所有密碼儲存相關的函數
→ 生成修改方案
→ 套用 diff
→ git commit: "refactor: replace plaintext password with bcrypt hashing in UserService"

Changes committed: abc1234

如果你的工作目錄有未提交的修改，Aider 會先請你提交，確保它的修改和你的修改永遠不會混在同一個 commit 裡。

這個設計讓你永遠知道：哪些是我寫的，哪些是 AI 改的，隨時可以分開審查或回滾。

2. Repo Map：理解整個 Codebase，不只是你開的檔案

大多數 AI coding 工具的弱點是：你給它一個檔案，它就只看那個檔案。它不知道這個函數在別的地方被怎麼呼叫，它不知道這個類別繼承了什麼，它不知道你改了這裡會不會影響其他地方。

Aider 的 Repo Map 解決了這個問題：它在對話開始前，先掃描整個 repo 的結構——所有檔案、所有類別、所有函數定義、所有它們之間的呼叫關係——然後把這個「地圖」帶進 LLM 的上下文。

Repo Map 的內容（精簡版）：

src/
  auth/
    user_service.py
      class UserService:
        def create_user(email, password) → User
        def verify_password(plain, hashed) → bool
        def get_user_by_email(email) → Optional[User]
  api/
    routes.py
      → calls UserService.create_user at line 45
      → calls UserService.verify_password at line 67

有了這個地圖，AI 修改 create_user 的時候，就知道 routes.py 裡有地方呼叫它，就知道要一起確認介面是否還相容。

3. Architect Mode：讓貴的模型想，讓便宜的模型做

這是 Aider 最獨特的設計之一，也是它在 SWE-bench 上表現亮眼的核心原因。

傳統方式的問題：

用一個強大（但昂貴）的模型做所有事——規劃架構、生成程式碼、格式化輸出——大量的 token 花在了「執行」而不是「思考」上。

Architect Mode 的解法：

把工作拆成兩個步驟，交給兩個不同的模型：

用戶需求：「重構 auth 模組，改用 JWT，移除 Session」

Step 1 — Planner（昂貴的模型，如 Claude Opus / o1）：
  思考：哪些檔案要改？改動的邏輯是什麼？
  輸出：修改計畫（自然語言）

Step 2 — Editor（便宜的模型，如 Claude Haiku / GPT-4o-mini）：
  輸入：修改計畫 + 相關檔案
  輸出：具體的 diff（程式碼修改）

這個設計讓 Aider 在處理架構層級的修改時，品質比單一模型更好，成本比全程用強模型更低。

執行流程架構圖

SWE-bench 上的成績

Aider 在 SWE-bench 上的表現，曾多次登上排行榜頂端：

• SWE-bench Lite：26.3%（曾為 SOTA）
• SWE-bench 完整版：18.9%（曾為 SOTA）

值得注意的是：Aider 達到這個成績，用的是 Architect Mode + 公開可用的 LLM——不是自己訓練的特殊模型，不是封閉系統，而是任何人都可以自己跑的開放架構。

Aider vs 這個系列的其他工具

Aider 在「AI 寫程式」這個大分類裡，定位最接近真實的工程師工作流程：

簡單記：GPT-Engineer 從白紙開始，OpenHands 解決既有問題，MetaGPT 模擬公司，Aider 就是你每天工作的方式——只是多了一個會寫程式的 pair programmer 坐在旁邊。

實用建議：三個起步行動

步驟 1：先用 /add 告訴 Aider 你要改哪些檔案

Aider 的 Repo Map 很強，但你知道自己要改哪裡。在開始對話前，用 /add 指令明確加入相關檔案，讓 AI 把精力集中在對的地方。

/add src/auth/user_service.py src/api/routes.py

步驟 2：Architect Mode 用在跨檔案的架構修改

簡單的單檔修改，直接跑就好。涉及多個檔案、有架構層級決策（例如：換掉整個認證機制、重構資料模型、API 改版）時，開啟 Architect Mode 的品質提升最明顯。

aider --architect --model claude-opus-4 --editor-model claude-haiku-4

步驟 3：定期用 /commit 整理工作

Aider 會自動 commit 它的修改，但你自己的修改還是要手動管理。養成習慣：每完成一個邏輯單元，用 /commit 整理一次，讓 Git 歷史保持乾淨可讀。

我的反思

讀完 Paul Gauthier 的故事，我發現這個系列裡的創辦人可以分成兩種：

一種是年輕的快速啟動者——Peter Steinberger、Anton Osika，週末做出一個東西，病毒擴散，融資，獨角獸。

另一種是深厚積累的系統建造者——吳成林（十億用戶規模的騰訊），錢忱（清華 NLP 多年研究），而 Paul Gauthier，是三十年系統架構積累的直接輸出。

從 Inktomi（分散式搜尋）到 Groupon（大規模電商基礎設施）到 Geomagical（AR 電腦視覺），他處理的每一個問題，核心都是同一件事：如何設計一個系統，讓它在複雜、規模化、需要多人協作的環境下，仍然可靠、可審查、可維護。

Aider 的 Git-First 設計，就是這三十年積累的直接答案。

其他工具問的是：「AI 能生成什麼？」 Gauthier 問的是：「AI 生成的東西，要怎麼安全地進入我的工程系統？」

這個問題的答案，是 Git commit。

當然，每次修改都是 commit 這件事，不只是工程習慣，它背後還有一個更深的主張：AI 輔助開發，必須是可觀測的、可審查的、可回滾的。 不是因為我們不相信 AI，而是因為好的工程實踐本來就這樣要求——無論誰寫的程式碼，都應該是這樣的。

回到這個系列的脈絡：Anton Osika 讓不會寫程式的人能做軟體，吳成林讓 AI 遵循軟體公司的 SOP，錢忱讓 AI 學會開會——而 Paul Gauthier 的貢獻，是確保：

無論 AI 幫你做了什麼，你永遠清楚地知道它做了什麼，隨時可以撤回。

這不是最性感的功能，但它是讓 AI 工具真正被信任、真正進入工程師日常工作流的那道門。

參考資料 (References)

官方資源

• Aider 官網
• Aider GitHub（Aider-AI/aider）

延伸閱讀

• Paul Gauthier — Dalhousie University Profile
• Aider SWE-bench SOTA 報告

推薦影片