代码行数有了更好的宣传噱头
2026 年 6 月 10 日，阅读时长 8 分钟，涉及 #人工智能、#领导力、#生产力 等话题。十五年前，一家 SaaS 公司有两位资深开发者，其中一位写的代码行数比另一位多 40%，但这能说明这位开发者更优秀、对业务影响更大吗？显然不是，人们更关注实际交付内容以及这些交付对客户、收入和可靠性的影响。现在大家明白，代码行数、拉取请求（PR）数量通常不是衡量开发者的好方法。
今年行业大肆宣扬的内容
今年行业里有诸多关于人工智能编写代码数量的宣称：谷歌 75% 的新代码由人工智能生成；Anthropic 约 80% 的合并生产代码由 Claude 编写，且工程师每个季度交付的代码量是原来的 8 倍；OpenAI 约 80% 的代码由人工智能生成；Cursor 每天编写的企业代码超过 1 亿行。这些宣称本质上都是关于数量的，“人工智能编写的代码百分比”不过是换了说法的代码行数。
我们过去关注的是成果
几年前，行业关注重点是不同的指标。GitHub 宣称开发者使用 Copilot 完成任务的速度提高了 55%，这是关于“成果”的宣称，大胆且可验证。而 2026 年的数量宣称不会失败，无论实际情况是否改善，数量指标只有在采用率停滞时才会让人失望，目前采用率在上升。
没人宣扬的真相
问题在于成果证据变得复杂。支持采用人工智能的有力研究是 Cui 等人的研究，近 5000 名开发者参与，任务完成率提高了 26%，初级开发者提升明显。但 GitClear 发现，随着 Copilot 采用率提高，代码变更率上升，重构率下降。METR 研究显示，有经验的开源开发者使用人工智能时速度慢了 19%，却认为自己速度提高了 20%。不过 2026 年 2 月，METR 推翻了之前结论，认为人工智能可能提高开发者工作速度，但无法准确衡量提升幅度。美国国家经济研究局（NBER）调查发现，69% 的公司积极使用人工智能，但约十分之九的公司表示无明显生产力提升，组织层面平均提升约 10%。
人工智能版的虚荣指标
不只是人工智能供应商做这样的宣称。卡内基梅隆大学软件工程研究所（SEI）和埃森哲推出人工智能采用成熟度模型，依据是 95% 的组织没有看到回报。史蒂夫·耶格的“人工智能辅助开发的 8 个级别”根据使用工具和监督程度排名。每个工具供应商都推出成熟度阶梯，最高级别通常是“更多地使用我们的产品”，这些阶梯衡量采用强度并称之为成熟度。Augment 对 219 位工程领导者调查“原生人工智能工程”，得到 219 种不同答案。Anthropic 既宣称“交付的代码量增加了 8 倍”，又有研究表明使用人工智能辅助的开发者对代码理解能力得分降低了 17%，且生产力无统计学显著提升。
我真正在意的原因
这些数字会影响预算、绩效预期和人员编制计划。2 月，杰克·多尔西以人工智能为核心理由，裁掉 Block 超过 40% 的员工（4000 多人），表示小团队用工具能做得更多更好。几周后，Atlassian 裁掉 10% 的员工（约 1600 人），承认人工智能会改变技能组合和岗位数量。多尔西称公司业务强劲，毛利润在增长。当公司说“人工智能提高生产力，所以需要更少的人”时，需要看到证据。企业不应依靠“人工智能编写的代码百分比”等虚荣指标裁员，而应使用个人绩效评估系统找出工作懈怠和不投入的人。
我的观点
不要把作者的话理解为反人工智能，作者认为工程师应每天使用人工智能，要保持好奇心，尝试新工具。但采用只是起点，不是计分板。衡量工程部门创造价值有 DORA 指标、可靠性、有意义的变更率、收入和客户价值等可靠指标，不应为了人工智能虚荣分数抛弃这些。在与供应商洽谈、高管评审或刷领英时，可问“这是一个成果指标，还是一个数量指标？”变革已至，工具很有用，应在工作中以人工智能为先，衡量时采用经过实践检验的方法。
