Git 作為 Claude Code 的外接大腦：超越 MEMORY.md 的記憶架構

一個朋友在社群丟了一句話：「Git 不只對人類有幫助，對 Claude Code 一樣有幫助。人類用 git 時的好習慣，在 Claude Code 一樣是好習慣。」

我第一個反應是：「我有 Memory.md 啊，夠用吧？」

試了兩週後發現，這兩個東西解決的根本是不同的問題。

記憶不是只有兩層

我原本以為 AI Agent 的記憶就兩個選擇：context window 不夠就開 Memory.md 來補。Memory.md 寫太多就… 想辦法精簡？

實際上 Claude Code 自己就有三層記憶，再加上 Git 是第四層：

前三層是 Anthropic 自己建的。第四層是 Git 一直都在，只是多數人沒有刻意當成 AI 的記憶工具來用。

這個分層的關鍵不是資訊的「種類」，而是查詢頻率：

• 每次都要看 → CLAUDE.md
• 每次自動帶入（但你不用管） → Session Memory
• 偶爾需要深入 → Auto Memory topic files
• 需要的時候再查 → Git

Anthropic 的 best practices 對 CLAUDE.md 的建議很直接：控制在 200 行以內，每一行都問自己「拿掉這行會讓 Claude 犯錯嗎？」如果不會，就刪掉。經常變動的資訊（比如專案進度）不該放這裡。

那 Git 在這個架構裡扮演什麼角色？

Session Memory 已經會自動摘要上次做了什麼，Auto Memory 會記住踩過的坑。Git 還有什麼用？

差別在於 granularity 和 queryability。

Session Memory 是摘要——它告訴你「昨天在做登入功能」。但如果你想知道「登入功能的 token refresh 邏輯為什麼用固定等待而不是 exponential backoff」，Session Memory 沒有這個細節。Git blame 有。

Auto Memory 記的是「學到的通用教訓」。Git 記的是「這個具體的檔案、這一行、在這個時間點、為了這個原因被改成這樣」。

用白話講：Session Memory 和 Auto Memory 是筆記，Git 是完整的監視錄影。你不會每天回放監視錄影，但出事的時候它是唯一能告訴你真相的東西。

我怎麼用的：四個模式

commit message 作為壓縮摘要

我在 CLAUDE.md 加了一條：commit message 要寫清楚做了什麼、為什麼。

結果是下一個 session 跑一下 git log --oneline -15，15 行就能看到最近的完整脈絡。AI 自己寫的 log 比我口頭描述更準——帶 timestamp、帶影響的檔案範圍、是完成當下的理解，不是隔天的模糊回憶。

要說明的是：「每個小改動都 commit」並不是什麼業界共識。Anthropic 的 best practices 把 commit 放在 explore → plan → implement 流程的最後一步。學術上也有不同看法——Lore 這篇論文（arXiv 2603.15566）主張 commit 應該更少但更重，每個 commit 帶完整的決策脈絡（為什麼選 A 不選 B、有什麼限制）。

我自己的做法介於兩者之間：不是每改一行就 commit，但一個邏輯完整的變更做完就 commit。這是個人偏好，不是最佳實踐。

commit 前先 git diff 自己看一遍

Claude Code 有時候會很有信心地說「改好了」，但實際上沒落地。幻覺不只出現在回答問題時，改檔案的時候一樣會。

我的 Pre-Commit Checklist 裡有一條：commit 前先跑 git diff，自己審查自己的修改。

這個習慣抓到過幾次：改了 A 檔忘了同步 B 檔、以為刪了某行但其實沒刪、加了新 dependency 但沒更新 build 設定。

說穿了就是讓它先寫，寫完再回頭檢查。驗證比生成容易，不管對人還是對 AI 都一樣。

git blame 挖歷史決策

有一次我看到一段 retry logic，backoff 參數很奇怪，直覺就是「改成標準的 exponential backoff 就好」。

但 git blame 拉出來一看，三個月前的 commit message 寫著：「API 限流規則是 429 後固定等 5 秒，不是指數退避」。

如果沒有 Git，這段 code 就會被「修好」然後真的壞掉。這種大大小小的設計決策，Session Memory 不會記、Auto Memory 不會記、Memory.md 不可能全部列出來。但 Git 裡面都有——前提是你當初有寫 commit message。

git blame src/auth/token-manager.ts
git show abc1234 -s

git worktree 平行跑多個 agent

同時開兩個 Claude Code session 在不同方案上工作，互不干擾：

git worktree add ../myproject-experiment -b experiment/approach-A
cd ../myproject-experiment && claude

主 branch 完全不動。實驗爆了就刪目錄，成功就 merge 回來。

這個模式不是我發明的——VILA-Lab 分析 Claude Code 架構的論文（arXiv 2604.14228）發現，Claude Code 內部處理複雜任務時就是在獨立的 git worktree 裡跑 sub-agent。Letta 的 Context Repository 系統也用同樣的模式。

一個附帶發現：Pre-commit hook

跟記憶無關，但用 Git 之後順便得到的好處。

有了 Git 的復原能力，AI 確實會更敢改。Pre-commit hook 跑 lint 和 type-check，沒過就不讓 commit：

# .git/hooks/pre-commit 或用 husky
npm run lint
npm run type-check
npm run test -- --bail

不過有個坑：hook 太慢的話（超過 30 秒），Claude Code 會想辦法跳過它（--no-verify）。hook 盡量壓在 10 秒以內。

分工整理

用了一段時間之後，我的分工大概是這樣：

CLAUDE.md（穩定、精簡、每次載入）：

• Build 指令、test 指令
• 程式碼風格規則
• 不能踩的地雷
• 架構決策（當前的，不是歷史的）

Auto Memory（讓 Claude 自己管）：

• 踩過的坑和學到的教訓
• Debug 模式和解法
• 專案特有的 pattern

Session Memory（不用管，自動運作）：

• 上次 session 的摘要

Git（需要時再查）：

• 「上次做到哪了」→ git log
• 「那個 bug 怎麼修的」→ git log -S "keyword"
• 「這段 code 為什麼長這樣」→ git blame
• 「第三版的方案跟現在差在哪」→ git diff

判斷標準：如果這筆資訊你每個 session 都要看，就往上放（CLAUDE.md）。如果偶爾才需要，就往下放（Git）。放錯層的代價是：放太上面浪費 context，放太下面查不到。

這個方向有沒有人在認真研究？

有。而且不只一組人。

幾個值得追蹤的：

• Lore（arXiv 2603.15566）— 把 git commit message 改造成結構化的知識協定，讓 AI 能從 commit history 裡查出「為什麼選 A 不選 B」
• Git Context Controller（arXiv 2508.00031）— 用 git 操作（commit, branch, merge）來組織 agent 的記憶，在 SWE-Bench 上拿到 48% 的解題率
• Letta Context Repository（blog）— 用 git-backed 檔案系統作為 agent 的共享記憶，sub-agent 在獨立 worktree 工作
• DiffMem（GitHub）— 把對話式 AI 的記憶當成 git repo 管理，當前狀態是可編輯檔案，歷史在 commit graph 裡

這些系統的共同結論：把「當前狀態」和「歷史紀錄」分開管理是對的，Git 天生適合做後者。

後記

Git 是 2005 年的東西，Linus Torvalds 為了管 Linux kernel 寫的。二十年後它多了一個新用途：幫不斷失憶的 AI 記住自己做過什麼。

Torvalds 大概沒想過這個 use case。

但「完整歷史 + 精準查詢 + 任意復原」這三個特性，剛好就是 AI agent 最需要的。也許這就是好工具的特質——設計時解決一個問題，但好的抽象會在完全不同的場景被重新發現。