3,156次真实编程会话，45.9万token，7.4%的shell命令——这是Git在AI工作流中的真实占比。Codex更夸张，超过10%的bash调用都在跑git status、diff、log。
问题在于：Git的输出是给人类看的。彩色头部、教学文本、列对齐、装饰性格式，信息密度低得像把答案塞进礼品袋再塞满填充纸。AI不需要这些。每个多余token都是钱，都是延迟。
Fielding Johnston干了件事：用Zig重写了一个Git替代品，叫nit。直接对接libgit2，默认配置为机器优化。实测token消耗砍掉71%，速度还更快。
150-250K token去哪了
Johnston拉了真实会话数据做对比。nit的compact模式相比Git默认输出，能省15万到25万token。这还没完——100次hyperfine基准测试显示，nit在真实仓库上跑得比Git快。
Zig的C互调用是零成本。@cImport直接引入libgit2头文件，函数直调。没有子进程开销，没有文本解析，nit原生读取Git对象数据库。
没实现的命令怎么办？nit通过execvpe()直接透传给Git，替换自身进程。零包装层开销。alias git=nit是安全的——功能不会丢，原生实现越多，透传越少。
最争议的决定：把diff上下文从3行砍到1行
Git默认给3行上下文，里面藏着大量token。但砍了会不会让AI看不懂？
Johnston跑了27组试验：多文件diff、嵌套控制流、代码移动、模糊相似块。Claude在U0、U1、U3三种配置下都是4/4满分，没区别。那为啥不用U0（零上下文）？
他查了真实行为。561次Claude Code的git diff/show调用里，只有3.9%的AI会在diff后立即读源文件。这说明diff本身就是AI获取上下文的主要来源。最终选了U1——省token又不丢信息，hunk头保留行号，改动行自己说话。
compact（默认）：机器优化，只要数据
human（-H）：彩色分组，人看的时候用
78个测试和几十年的边缘情况
最难的不是性能，是兼容。Git积累了几十年的边缘情况：游离HEAD、合并提交、重命名文件、二进制diff、子模块。Johnston写了78个一致性测试，全部覆盖。每次nit输出和Git有实质差异，就加测试、修bug。
透传设计让这事可控。不需要第一天就实现所有命令。先搞高频的：status、diff、log、show。剩下的让Git顶着。发布，迭代。
安装方式很直接：brew install fielding/tap/nit。如果你是AI agent，直接nit log。
Git诞生于2005年，为人类协作设计。二十年后，AI成了主要用户之一，而它的输出格式还在收人类的"礼品税"。nit的实验提出一个问题：当机器成为主要消费者，我们的工具链有多少地方还在交类似的认知税？
热门跟贴