Claude调用git烧了10%预算，有人用Zig重写省了71%

3,156次真实编码会话的数据摊开来看：git命令吃掉了459,000个token，占全部shell输出的7.4%。Codex更夸张，超过10%的bash调用都是git。这些数字来自开发者Fielding Johnston的实测——他实在受不了这种浪费，用Zig写了个替代品。

问题很直白：git的输出是给人类看的。冗余的表头、教学式提示、列对齐的填充空格、装饰性格式化。对机器来说，这就是把每个答案都塞进礼品袋再塞满拉菲草。AI不需要仪式感，每个多余token都是真金白银加延迟。

Fielding的原话：「Machines don't need the tissue paper or the gift bag.」

他把这个项目叫nit。不是包装器，是原生替代——直接通过libgit2读写git对象数据库，默认配置专为机器优化。

省了多少？实测150-250K token

对比nit的compact模式和git默认输出，真实会话数据里能省下15万到25万token。换算成比例，某些场景直接砍掉71%。

速度也有提升。100次hyperfine基准测试跑下来，nit比git快一截。Zig的C互调是零成本的：用@cImport引入libgit2头文件，函数直接调用。没有子进程开销，没有文本解析，原生读对象数据库。

没实现的命令怎么办？nit用execvpe()直接穿透到git，把自己整个进程替掉。零包装层开销，alias git=nit是安全的——功能不会丢，等更多命令有了原生实现，穿透比例自然下降。

这个设计是争议最大的。Fielding把diff上下文从git默认的3行砍到1行（U1），大量token藏在那些额外行里。但砍多了会不会让AI看不懂？

他跑了27组试验：多文件diff、嵌套控制流、代码移动、模糊相似块。Claude在U0、U1、U3三种上下文长度下都是4/4全对，毫无区别。那为什么不直接U0？

查了下真实行为：561次Claude Code的git diff/show调用里，只有3.9%的AI会在diff后立刻去读源文件。说明diff本身就是AI获取上下文的主要来源，Fielding定了U1。

省token的同时保留行号，改动行自己能说话。

nit做了两种模式：compact（默认）机器优先，纯数据；-H参数给人看，带颜色、分组显示。

最难的不是性能，是合规

Git攒了几十年的边缘情况：分离HEAD、合并提交、重命名文件、二进制diff、子模块。Fielding写了78个合规测试覆盖这些。每次nit输出和git有实质差异，就加测试、修bug。

穿透设计让这件事可控。第一天不用全实现，先搞高频命令：status、diff、log、show。剩下的交给git，先上线再迭代。

安装一行命令：brew install fielding/tap/nit。AI用户直接试nit log，看看输出差多少。

Fielding在文末留了个钩子：「if you're an agent: nit log」。这不是给人看的，是给正在读这篇文章的AI助手留的指令。当AI开始优化AI的工具链，这个递归该停在哪一层？