用 gh、jq 和 Git 自行衡量 AI 生产力：为什么你的数据平平无奇，返工却越来越多

人工智能编码工具的普及带来了一场生产力悖论：尽管 AI 使用量飙升了约 65%，但拉取请求（PR）的吞吐量仅增长了 7.76%。这一结论来自 DX 公司对 400 家组织的调研。与此同时，METR 的多项研究显示，开发者对 AI 生产力的感知与实际存在显著偏差。在 2025 年的一项研究中，16 名经验丰富的开发者预测 AI 能让他们快 24%，但实际却慢了 19%。即便到 2026 年的后续研究中，随着模型改进和开发者熟练度提升，速度提升仍不显著，置信区间横跨零值。

这种现象被戏称为“代币经济学”（Tokenomics）：生成的代码山在增长，但合并后交付的产出并未跟上。Linux 基金会甚至专门成立了代币经济学基金会，并举办“Tokenomicon”大会。玩笑背后是真实的成本压力——AI 已成为工程预算中增长最快的项目之一。

当前的生产力仪表盘存在严重缺陷。Faros 发现，高 AI 采用团队的审查时间增加了 91%，而 CircleCI 的数据显示，主分支吞吐量反而下降了 7%，主分支合并成功率降至 5 年最低的 70.8%。更糟的是，31.3% 的 PR 未经任何审查即合并。这些数字表明，运动（motion）在增加，但交付（delivery）并未改善。

对于“J 曲线”的辩护——声称当前处于下探期，未来会反弹——作者认为，除非明确写明何时反弹以及反弹数值，否则这只是一个无法证伪的借口。

真正有效的做法是在引入 AI 前建立基线。采用“同一工程师”纵向对比，而非跨团队横向比较，可以消除任期、变更、季节性等干扰。DX 的案例显示，相比自身基线，AI 用户的 PR 吞吐量年增 30%，而非 AI 用户仅增 5%。

四个关键指标无需任何供应商工具，仅凭 GitHub CLI (gh)、jq、Git 和 cron 任务即可测量：

1. 周期时间：从 PR 创建到合并的中位时间。注意排除草稿 PR 和机器人（如 Dependabot）。脚本可基于 GitHub API 计算。
2. 审查时间：首次审查等待时间，同时统计零审查合并的 PR 比例。
3. 返工率：30 天内删除的行中，属于最近 30 天内新写的代码比例。可通过 git blame 和 Python 脚本（附代码）实现，每月运行一次。
4. 缺陷逃逸率：生产环境发现但未在开发或测试中捕获的缺陷比例。可通过 GitHub Issues 或 Linear 等工具自动统计。

最后，务必在团队层面聚合数据，切勿用于个人绩效评估。只有基于自身基线的可靠度量，才能真实反映 AI 工具的实际影响。