為什麼有人要重寫 Git？這個專門給 AI Agent 用的版本控制工具值得關注
重新設計 Git，這次為了 AI Agent — 談 token 效率的重要性
最近看到一個有趣的專案 Nit，開發者用 Zig 重新實作了 Git，專門為 AI Agent 優化，號稱能節省 71% 的 token 使用量。老實說第一眼看到這個數字，我是有點懷疑的 — 真的需要為了 AI Agent 重寫整個 Git 嗎？但仔細想想，這背後其實反映了一個很重要的趨勢：傳統工具跟 AI 的互動方式根本不是為彼此設計的。
問題核心：Git 輸出太囉嗦
傳統 Git 指令的輸出是設計給人看的，充滿了各種提示訊息、formatting 和冗餘資訊。比如 git log 會顯示完整的 commit hash、author、date、message，還有一堆空行跟分隔線。對人類來說這很友善，但對 AI Agent 來說就是 token 殺手。
想像一下，當 AI Agent 需要查看專案歷史或分析程式碼變更時，每次都要處理這些冗餘資訊。以一個中型專案來說，git log --oneline -10 的輸出可能就要消耗幾十個 token，而 AI 真正需要的可能只是 commit hash 和 message。
Nit 的解決方案
Nit 的核心想法很簡單：重新設計輸出格式，讓 AI Agent 能更有效率地處理。具體做了幾件事：
精簡輸出格式 — 移除人類友善但 AI 不需要的格式化元素，直接給結構化的資料。比如用 JSON 或是更簡潔的格式，而不是 Git 那種充滿空白跟裝飾的輸出。
智慧預設值 — Git 很多指令的預設行為對 AI Agent 來說不太適用。比如 git diff 預設會顯示完整的 context，但 AI 可能只需要變更的行數統計。
減少互動式提示 — Git 有很多互動式的確認提示，對 AI Agent 來說就是額外的複雜度。Nit 針對自動化場景優化了這些行為。
為什麼 token 效率這麼重要？
這裡要提到 AI Agent 的運作模式。不像我們寫程式時手動執行指令，AI Agent 經常需要連續執行多個 Git 操作來理解專案狀態。每個指令的輸出都會被納入 context window，累積起來就很可觀。
而且 AI Agent 的 token 成本是實際的錢。如果一個 Agent 每天要處理幾十個 repository，每次都因為冗餘的 Git 輸出浪費 token，長期下來成本差異會很明顯。71% 的節省聽起來誇張，但考慮到 Git 輸出的冗餘程度，其實不意外。
這個方向值得關注嗎？
我覺得 Nit 這個專案的價值不在於它是否會取代 Git，而在於它提出了一個重要問題：現有工具是否適合 AI Agent 使用？
答案很明顯是否定的。我們現在看到的大部分 CLI 工具都是為人類設計的，充滿了友善的提示、彩色輸出、progress bar 這些東西。但 AI Agent 不需要這些，它們需要的是結構化、精簡、可預測的輸出。
類似的問題其實到處都有。想想 npm install 的輸出有多囉嗦，或是 docker build 時那一堆 layer 資訊。對 AI Agent 來說這些都是 noise。
實際應用場景
這種針對 AI 優化的工具，最有價值的場景應該是 code assistant 和自動化工作流程。比如：
- AI code review bot 需要快速掃描 commit history
- 自動化部署系統需要檢查程式碼變更
- AI pair programming 工具需要理解專案結構
在這些場景下，token 效率直接影響響應速度和運作成本。
未來趨勢
Nit 可能只是個開始。我預期會看到更多「AI-first」版本的傳統工具，不只是 CLI 工具，連 API 設計都會考慮 AI consumption 的需求。
比如 GitHub API 現在很多 response 包含大量的 metadata，但 AI Agent 可能只需要核心資料。未來可能會有專門的 AI-optimized API endpoint，提供更精簡的回應格式。
當然，這也帶來一個問題：工具生態系統會不會因為 AI 的需求而分裂？人類友善的版本跟 AI 優化的版本並存，還是會有新的標準出現？
目前看起來，Nit 這類專案更像是過渡期的解決方案。長遠來說，可能是在現有工具上加入 --ai-format 這類選項，而不是完全重寫一套。但不管怎樣，這個方向是有意義的 — AI Agent 的普及確實需要工具生態系統的配合。
Waiting7777
前端工程師的 AI 實戰紀錄
這篇文章對你有幫助嗎？
每週一篇 — 前端工程師的 AI 轉型筆記
從前端到 AI Agent，把複雜的東西拆清楚，寄到你的信箱。
