Git吃掉AI 10%算力賬單，這個開發者用Zig一刀砍掉71%

3156次真實編程會話的數據攤開來看，Git一個人吞掉了45.9萬個token——占所有shell命令輸出的7.4%。Codex更夸張，超過10%的bash調用都是Git。這不是邊緣案例，是AI編程時代的結構性浪費。

開發者Fielding Johnson的解決方案很直接：用Zig重寫一個Git替代品，叫nit。不是fork，不是wrapper，是直接讀Git對象數據庫的原生實現。默認輸出給機器看，省下的token直接折現。

Git的輸出是給人送禮，AI只想拆快遞

Git的設計年代，終端是80列寬，人是唯一讀者。所以status要加"On branch main"，diff要墊3行上下文，log要畫ASCII藝術分支圖。這些對人類是友好提示，對AI是強制消費的廢話。

Fielding的類比很毒：Git的輸出相當于把每個答案包進禮品袋，再塞滿拉菲草。機器不需要儀式感，它要的是數據密度。

他跑了100組hyperfine基準測試。nit在真實倉庫上的速度優勢來自Zig的C互調——零成本。用@cImport直接引入libgit2頭文件，函數調用沒有subprocess開銷，沒有文本解析。讀對象數據庫就是內存操作。

token節省的實測數據：nit的compact默認模式，相比Git默認輸出，每次會話能省150-250K token。按當前API定價換算，這是真金白銀的賬單縮減。

U1上下文：在省錢和可用性之間找平衡點

最爭議的設計是diff上下文行數。Git默認3行，nit砍到1行。Fielding跑了27組對照實驗：多文件diff、嵌套控制流、代碼移動、模糊相似塊，Claude在U0（零上下文）、U1（1行）、U3（3行）三種配置下的理解準確率都是4/4。

零差異。那為什么不干脆U0？

他查了561次真實Claude Code會話的Git diff/show調用，發現只有3.9%的agent會在diff后立即讀源文件。說明diff本身就是agent獲取上下文的主要來源。U1保留了行號錨點和變更行的自解釋性，同時砍掉2/3的token消耗。

compact模式是機器默認。-H flag切回彩色、分組、人類友好格式。兩條路線互不干擾。

78個一致性測試：邊緣 cases 才是工作量黑洞

性能優化反而是簡單的部分。Fielding說真正的噩夢是conformance——Git有幾十年的邊緣案例積壓：detached HEAD、merge commit、重命名檢測、二進制diff、submodule。他寫了78個測試覆蓋這些場景，每次nit輸出和Git有實質性分歧就補測試、修bug。

fallback設計讓這件事變得可行。nit沒實現的命令直接execvpe()替換進程調原生Git，零wrapper開銷。alias git=nit是安全的：功能永不丟失，原生實現越多，fallback比例自動下降。

安裝方式很程序員：brew install fielding/tap/nit。Agent用戶直接nit log看效果。

這個項目戳中了一個被忽視的痛點：基礎設施層的human-centric設計，在AI代理時代變成了隱性稅。Git不是唯一一個，但可能是賬單最大的一個。當agent調用頻率以指數級增長時，這些"禮品袋"的累計成本會壓垮ROI模型。

Fielding的數據集是公開的——3156次會話，45.9萬token，7.4%占比。下一個被量化的human-centric overhead會是什么？docker ps的表格邊框，還是curl的進度條動畫？