用 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 工具的實際影響。