代码行数找到了更好的宣传者

# 代码行数找到了更好的公关 来源：https://curlewis.co.nz/posts/lines-of-code-got-a-better-publicist/ 那是十五年前的事了（耐心点，我从90年代末就在这个行业了，我的好故事大多都是这么开头的），你所在的一家SaaS公司有两位高级开发人员。其中一位写的代码行数比另一位多40%。那位开发人员就更优秀吗？对业务的影响更大吗？另一位是不是该更新简历了？ 当然不是。你真正想了解的是实际*交付*了什么，它对客户、收入和可靠性有什么影响。代码行数、PR数量……我们花了二十年时间才明白这些是衡量开发人员的典型错误方法，以至于如今提出这些指标会显得可笑。 所以……今年行业在公告牌上贴出的是这样的内容： - 谷歌：75% 的新代码是 AI 生成的（https://www.fastcompany.com/91531519/google-ceo-says-75-of-the-companys-code-is-ai-generated） - Anthropic：大约 80% 合并后的生产代码由 Claude 编写（https://venturebeat.com/technology/anthropic-says-80-of-its-new-production-code-is-now-authored-by-claude-how-your-enterprise-can-keep-up），工程师每季度交付的代码量“提升了8倍” - OpenAI：也大约是 80%（https://thenextweb.com/news/openai-brockman-80-percent-code-ai-productivity-claim） - Cursor：“每天有超过1亿行企业代码由AI编写”（https://research.contrary.com/company/cursor） 每一个都是数量型宣称。“AI 编写的代码百分比”只是代码行数换了个更好的公关。（我编辑这篇草稿时的怀疑态度让我指出，所有这些公司都是某种 AI 供应商，这绝非巧合，因此推广采用率对它们来说*相当*重要。） ### 我们过去宣称的是成果 往回倒几年，那时的头条数字不仅在规模上不同，在性质上也不同。GitHub 的标志性宣称是，使用 Copilot 后开发人员完成任务的速度*加快了55%*（https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/）。你可以对那项研究说三道四（很多人确实这么做了），但这是一个*成果*宣称。大胆、可证伪、关乎价值。如果它错了，你可以证明它错了。 而2026年的宣称则无法失败。这正是它们的聪明之处：“我们75%的代码是AI编写的”可能是真的，而且还会继续上升，无论事情是否真的有所改善（交付速度更快、事故更少、客户更满意等等）。数量指标只有在采用率停滞时才会令人失望，而采用率恰恰是大多数人认为真实存在的事情。📈 因此，宣称越来越大，但内容却越来越少。这中间发生了什么？ ### 没人放在公告牌上的部分 成果证据变得复杂了，这就是发生的事情。 最支持采用的结果仍然是 Cui 等人（https://pubsonline.informs.org/doi/10.1287/mnsc.2025.00535）的研究；近5000名开发者，任务完成率提高了26%，初级开发者收益最大。这基本没有争议。但随后 GitClear（https://www.gitclear.com/coding_on_copilot_data_shows_ais_downward_pressure_on_code_quality）显示，随着 Copilot 采用率的加深，代码更迭率上升，重构率下降。接着 METR（https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/）进行了一项被许多人引用的研究：经验丰富的开源开发者在自己的代码库中使用 AI 后，速度反而慢了19%，同时却相信自己快了20%。 但是！且慢……在2026年2月，METR 实际上收回了这一结论（https://metr.org/blog/2026-02-24-uplift-update/）：他们的后续估算转变为*加速*（误差范围大到可以骑着一辆带边箱的 Moto Guzzi 穿行而过！），并且他们完全放弃了原来的研究设计——因为开发者现在拒绝*不*使用 AI 工作，也无法可靠地自我报告在代理性工作上花费的时间。他们最新立场是：在2026年，AI 可能会加快开发者的速度，但我们再也无法清晰地测量具体加速了多少。 与此同时，在公司层面，一项对约6000名高管的 NBER 调查（https://www.nber.org/papers/w34836）发现，69%的公司正在积极使用 AI，但大约十分之九的公司报告称没有可测量的生产力影响。跨研究的共识大约在10%的组织级收益。这并非微不足道！仍然非常有用！但是，也远非“不再需要开发者”的领域。 而且，如果你是一个仍然引用“慢19%”的怀疑者，那你也在选择性引用。研究不断更新；行业只是改变了它衡量的对象。 ### 虚荣指标，现在换上了AI的马甲 公平地说，这不仅仅是 AI 供应商的宣称。卡内基梅隆大学的 SEI 和埃森哲在几天前推出了一个 AI 采用成熟度模型（https://newsroom.accenture.com/news/2026/accenture-and-the-carnegie-mellon-university-software-engineering-institute-launch-ai-adoption-maturity-model-to-help-organizations-scale-ai-with-predictable-outcomes）：五个级别，八个维度，并且基于“95%的组织未见回报”这一统计数据进行了营销。Steve Yegge 的“AI 辅助开发的8个级别”（https://www.augmentcode.com/guides/steve-yegge-8-levels-ai-assisted-development）则根据你运行哪些工具以及给予多少监督来进行排名。而每个工具供应商现在都推出一个成熟度阶梯，其最高一层通常是“多使用我们的产品”。这些阶梯衡量的是采用强度，却称之为成熟度。同样的替换，换了更漂亮的包装。 我在整个主题中最喜欢的数据点：Augment 调查了219位工程领导者，并请他们定义“AI 原生工程”（https://www.augmentcode.com/resources/state-of-ai-native-engineering-2026）。他们得到了219个不同的答案。🫠 蜘蛛侠互指 meme而同时持有绳子两端奖项的得主是 Anthropic，他们既提出了“交付代码量提升8倍”的宣称，又发布了一项年度最严谨的研究之一：一项随机对照试验发现，AI 辅助的开发人员在理解*他们刚刚交付的代码*方面的得分低了17%（https://www.anthropic.com/research/AI-assistance-coding-skills），并且没有统计学上显著的生产力提升。我每天都使用 Claude（它推荐了我为这篇文章阅读的一半链接，所以我很清楚其中的讽刺意味）。这些产品确实非常出色，他们的研究团队在更新，而营销团队在统计数量。这两件事同时成立，而这正是重点。 ### 我为什么在乎 因为这些数字并非装饰性的。它们影响着预算、绩效预期和人员编制计划。今年2月，Jack Dorsey 以 AI 作为明确的核心论点，裁掉了 Block 超过40%的员工（https://fortune.com/2026/02/27/jack-dorsey-block-40-percent-layoff-ai-intelligence-tools-smaller-team/）（4000多人）：“一个显著更小的团队，使用我们正在构建的工具，可以做得更多、更好。”几周后，Atlassian 裁员10%（约1600人）（https://www.theregister.com/2026/03/11/atlassian_layoffs/），同时承认“假装AI不改变我们所需的技能组合或所需岗位数量是不诚实的”。还有一个让我在意的关键细节：Dorsey 在同一份公告中说，业务强劲，毛利润正在增长。 当一家公司说“AI 让每个人都更有效率，所以我们需要的员工更少”时，我希望看到证据——而我不认为这种证据今天存在。请告诉我，你的员工中有百分之多少是真正闲置的（甚至只是未充分利用），因为工作现在可以由更少的人完成。即便如此：我从未见过一家产品或SaaS公司没有无穷无尽的产品路线图。如果你几乎一夜之间免费获得了人手增加，为什么不利用它来更快地向客户交付更多价值呢？这应该会体现在月活跃用户数、转化率、收入上。而选择裁员告诉我，生产力宣称是在为早已因其他原因（过度招聘、投资者压力，随便你选）做出的决定做公关。 看，每个企业都有一些冗余，我能接受因效率提升而进行的精简，这在行业每次变革中都会真正发生。但当精简发生时，请尽量使用你已经运行的个体绩效系统，那些能发现谁在摸鱼、谁在懈怠的系统。而不是使用Token数量，不是“AI编写的代码百分比”或某人在成熟度阶梯上的等级。如果你的选择证据是虚荣指标，那么你的选择就是穿上口红的风险。 ### 我的立场 正如我在之前的文章中（https://curlewis.co.nz/posts/calibrating-on-capability-not-activity/）所说，请不要将此理解为反AI。我认为每个工程师*都应该*每天使用AI。叫它AI优先、AI精通，随便你怎么叫。保持好奇心，尝试新工具，测试最新模型。不这样做是愚蠢的。我看过这个行业吸收高级语言、IDE、自动补全、敏捷开发和DevOps的过程，总有一些顽固的守旧者怀念在X出现并毁掉一切之前的“美好旧时光”。守旧者最终还是会跟上（通常如此）。这次的不同在于速度：你可以将“上云”推迟一两年还能生存。而面对AI，你也许只有几个月的时间。我们的工作方式已经改变，而且据我所知，不会再变回去了。 但采用率只是*起点*，而不是计分板。我们早就知道如何衡量工程交付是否有效：DORA指标、可靠性、有意义的变更率，以及最终的营收和客户价值。这些都是经过实战检验的老东西。为什么我们要抛弃这一切，去追求扯淡的AI虚荣分数呢？（我在这篇文章中可能有很多地方是错的，但我不认为这一点错了。） 所以，请将这个问题偷偷带入你的下一次供应商推介、高管评审或领英信息流中：**那是成果，还是数量？**你会发现，当你问出这个问题时，许多立场或声明会迅速崩解。 变革已经到来，工具也很好。令人抱有希望的是，我们早就知道如何衡量重要的事情（而这些都不算在Token里）。 在工作方式上保持AI优先，但在衡量方式上保持实战检验。 干杯，Dave