多家 AI 编程工具和科技公司正在把“AI 写了多少代码”放到台前。Google 称 75% 的新代码由 AI 生成，Anthropic 称约 80% 合并进生产环境的代码由 Claude 编写，OpenAI 也出现过约 80% 的说法，Cursor 的宣传口径则是企业每天生成超过 1 亿行代码。

这些数字说明 AI 编程已经进入主流开发流程，但它们不能直接证明工程效率提升。软件行业花了二十多年才把“代码行数多就是好工程师”的旧账翻过去，如今同一套指标换成 AI 口径重新登场，风险在于企业可能用采用率、代码量和成熟度等级，替代对交付结果、代码质量和客户价值的衡量。

代码行数换成 AI 占比，指标更大但更难证伪

早期 GitHub Copilot 的代表性说法是“开发者完成任务快 55%”。这个主张可以被质疑，但它至少指向结果：同一任务是否更快完成。现在的宣传重心变成了体量指标，数字更醒目，含义却更窄。

公司或产品对外口径更能说明什么不能直接说明什么
Google75% 新代码由 AI 生成AI 工具在内部开发中使用广交付是否更快、更稳
Anthropic约 80% 生产代码由 Claude 编写，工程师季度代码量提升Claude 深度进入开发流程代码理解和维护成本是否下降
OpenAI约 80% 代码由 AI 生成团队高度依赖 AI 辅助开发者是否可替代
Cursor企业每日生成 1 亿行以上代码产品使用规模扩大代码是否产生业务价值

体量指标不是没有价值。采购负责人可以用它判断工具渗透率，团队负责人也能看出员工是否愿意使用新工具。但它不是绩效表。代码写得更多，可能是更快交付，也可能是更多返工、更高审查压力和更重的维护负担。

研究证据不支持简单的效率神话

关于 AI 编程的证据正在变复杂。Cui 等研究覆盖近 5000 名开发者，显示任务完成量提升 26%，初级开发者收益更大。这支持“AI 能提高部分开发效率”的判断。

另一组结果给出了相反提醒。GitClear 分析指出，Copilot 使用加深后代码 churn 上升、重构下降，意味着团队可能在写更多短期变更，却减少了长期维护动作。Anthropic 自己的研究也显示，AI 辅助开发者对刚交付代码的理解得分低 17%，且没有统计显著的生产率提升。

METR 的案例更能说明测量难度。它早期研究曾发现有经验的开源开发者在熟悉代码库中使用 AI 反而慢 19%，但 2026 年后续更新改为认为可能出现提速，只是误差很大，原有实验设计也难继续使用：开发者不愿不用 AI，代理式工作也很难准确自报耗时。

公司层面同样不能高估。NBER 对约 6000 名高管的调查显示，69% 企业已经主动使用 AI，但约九成没有看到可衡量的生产率影响。行业里更稳妥的估计，是组织收益大致在 10% 左右。这个幅度有商业意义，却远不到“开发者不再需要”的程度。

技术管理者该把预算和裁员依据拉回结果

真正受影响的是工程管理者和采购团队。AI 编程工具已经不再是试用玩具，GitHub Copilot、Claude Code、Cursor、OpenAI Codex 类产品正在进入统一工具链、培训预算和绩效讨论。问题不是要不要用，而是用什么证明它有效。

Block 和 Atlassian 的案例让风险更具体。Jack Dorsey 在 Block 大幅裁员时把 AI 工具作为“小团队做更多事”的核心论据之一；Atlassian 裁员约 10% 时也承认 AI 改变所需技能和岗位数量。原文同时提醒，至少有公司称业务仍强劲，不能把这些调整简单写成财务恶化，也不能只凭 AI 采用率或代码量证明人员冗余。

更合理的做法是把 AI 当作工作起点，而不是业绩终点。工程团队仍应看 DORA 指标、故障率、交付周期、重构质量、客户留存、收入贡献。接下来最该观察的，不是哪家公司宣布 90% 代码由 AI 写成，而是这些团队是否用更少返工、更少事故和更快产品迭代证明了这件事。

AI 编程已经值得日常使用。把它纳入预算也合理。但如果供应商报告和内部 OKR 只剩下 token、代码行数、AI 代码占比，管理层看到的只是热闹，不是生产力。