衡量工程生产力从未如此困难，这都多亏了AI！

# 衡量工程生产力从未如此困难 来源：https://leaddev.com/reporting/measuring-engineering-productivity-is-harder-than-ever 你本月还有**1**篇文章可读，之后需要注册（https://leaddev.com/register）一个免费的 LeadDev.com 账户。 预计阅读时间：11 分钟 **关键要点：** - AI 并没有**打破生产力**——它打破了我们**用来衡量生产力的代理指标**。 - **活动与业务价值正在脱节**。最有价值的工程工作越来越难以在传统仪表盘中显现。 - 将你的指标分为活动指标和成果指标。**大多数仪表盘在计算错误的东西**。 --- 衡量工程生产力（https://leaddev.com/reporting/its-time-to-rethink-how-we-measure-engineering-productivity）从来都不简单，而AI让它变得更加困难（https://leaddev.com/ai/the-struggle-to-prove-ai-productivity-gains）。在 OpenAI，重度依赖 Codex 的工程师打开的 Pull Request 数量比不依赖的同事多出约 70%——而且差距还在扩大，据 OpenAI API 平台工程负责人 Sherwin Wu（https://www.linkedin.com/in/sherwinwu1）称。 单独看这个数字作为生产力指标（https://leaddev.com/reporting/introducing-engineering-metrics-your-organization），你会得出结论：这些重度Codex（https://leaddev.com/ai/openais-5-codex-here）用户是你最好的工程师。这个结论可能是对的，但也可能完全相反。仅凭这一数字无法告诉你答案。这正是如今摆在每一位工程领导者桌面上的问题。 季度业务回顾曾经很简单。工程领导者（https://leaddev.com/the-engineering-leadership-report-2026/）会打开他们的仪表盘，查看熟悉的指标，如 Pull Request 数量、提交次数和故事点速度，然后与上一季度进行比较。没有任何单一指标能捕捉到软件工程的全貌，但放在一起，它们能描绘出一幅合理的团队表现图景。如今，这幅图景正在变得模糊。 然而，其他所有信息却讲述着不同的故事：团队交付了更多面向客户的功能，事故减少了，工程师花在重复实现上的时间减少了，客户更满意了，发布依然可预测。 ## 升级你的收件箱。 每周获取工程洞察，助你提升领导力。 那么，领导者应该相信哪种现实版本？两种观点都没错。它们衡量的是不同的东西。 多年来，提交次数、Pull Request、故事点和部署频率一直作为生产力的代理指标。它们从不完美，但大致能追踪软件是如何构建的：工程师编写代码、审查代码、测试代码、交付代码。随着工作的演变，指标也随之演变。 AI 并没有打破工程生产力。它打破了我们用来衡量生产力的代理指标。Stack Overflow 的2025年开发者调查（https://survey.stackoverflow.co/2025/ai）发现，84% 的开发者现在使用或计划使用AI工具（https://leaddev.com/ai/best-ai-coding-assistants），高于前一年的 76%。然而，只有 52% 的人表示这些工具确实提高了他们的生产力，并且对 AI 生成输出的信任度随着采用率的上升反而下降了。 采用率和价值已经在个体开发者层面脱钩，而不仅仅是在大多数企业 AI 调查追踪的组织层面。 软件工程正处于这一转变的中心。编码助手（https://leaddev.com/ai/your-ai-coding-tools-buying-checklist-for-2026）只是第一步。现在，团队正在试验能够以越来越大的自主性规划、实现、测试和完善软件的智能体系统。 工程师花在直接生成代码上的时间越来越少，而花在审查 AI 生成的变更、定义架构意图、设置护栏以及改进最初生成软件的工作流程上的时间越来越多。 工作变化的速度快于为衡量它而构建的指标。这并不意味着生产力无法衡量——而是意味着领导者需要重新思考，当最高价值的贡献在传统仪表盘中越来越不可见时，生产力应该是什么样子。 ## 工程生产力从来都不容易衡量 AI 制造了一种错觉，好像衡量突然变得困难了。实际上，软件工程（https://leaddev.com/ai/how-ai-will-change-software-engineering）几十年来一直抵制简单的衡量。 与制造业或销售不同，工程是知识工作——创造性的、协作的、依赖上下文的。两名工程师在同样时间内处理不同问题，可能会产生数量差异巨大的代码，但交付的价值却相当。 因此，行业循环使用各种代理指标，而每一种都以略有偏差的方式奖励某些行为： - **代码行数**奖励的是数量，而非判断力。那些简化系统或自动化重复性工作的工程师，在此指标下看起来效率低下。 - **提交次数**同样有缺陷。一位资深工程师在排查一个分布式系统 bug 时，可能几天只产生少量提交，而常规的界面更改却能产生数十个提交，与交付的价值毫无关系。 - **故事点**原本是为规划而建，而非绩效评估，一旦组织开始将速度视为评分而非估算，它就会失效。 即使是当今最受推崇的指标也需要上下文来解释。DORA 指标（https://dora.dev/）——部署频率、变更前置时间、变更失败率和恢复时间——是交付系统性能的行业基准。它们对个体开发者生产力的说明有限。这并非缺陷，而是有意为之。 DORA（https://leaddev.com/reporting/are-dora-metrics-right-your-team）衡量的是交付系统是否表现良好。SPACE 框架（https://queue.acm.org/detail.cfm?id=3454124），由 Nicole Forsgren 和同事于 2021 年提出，衡量的是开发者和团队在满意度与幸福感、性能、活动、沟通与协作、效率与流程等方面的有效工作。Forsgren 的核心论点是，生产力本质上是多维的，不能简化为提交次数或代码行数这样的单一指标。 这两个框架相互补充，共同提供的图景远比单纯的活动指标要丰富。 一位资深工程师指导（https://leaddev.com/management/how-be-effective-mentor）初级工程师、简化架构或预防生产事故，可能在 Git 历史中几乎不留下痕迹，但这些工作往往比数百次提交创造更多的长期价值。传统指标从来就不是为捕捉这些而设计的。它们只是反映了软件主要靠手工生产的时代。那个假设现在正在瓦解。 ## AI 在改变指标之前就改变了工作 关于 AI 的讨论大多集中在速度上——编码助手生成样板代码、搭建服务、自动化重复性任务。这些收益是真实的，但它们是故事中最无趣的部分。 更大的变化不是工程师写代码更快了，而是他们把时间花在了完全不同类型的工程工作上：审查 AI 生成的实现、比较设计方案、完善规格和约束、验证安全性和合规性、评估生成的测试、改进提示词和工作流程、以及做出决定接下来构建什么的架构决策。 OpenAI 自己的工程组织就是一个有用的前后对比案例。Wu 曾表示，OpenAI 95% 的工程师（https://www.lennysnewsletter.com/p/engineers-are-becoming-sorcerers）都日常使用 Codex，几乎所有合入的 Pull Request 都会先经过 AI 审查。与此同时，人类审查员从阅读几乎每一行代码，转变为只浏览小得多的部分，捕捉模型遗漏的内容，而不是自己重新推导改动。有些工程师现在同时运行 10 到 20 个 AI 编码线程。 如果天真地阅读，OpenAI 的仪表盘显示：Pull Request 增加 70%，审查时间减少——巨大的生产力胜利。仔细阅读，它传达的信息更狭窄：这些工程师变得更擅长指导和检查 AI 输出了。这到底有没有价值，完全取决于指标无法看到的那种判断力。 真正决定 70% 的额外 Pull Request 是否优质的工作——决定构建什么、捕捉看似正确但实际错误的变更、知道何时该信任模型何时不该——发生在指标的上游。 颇具讽刺意味的是，AI 提供的杠杆越大，随之产生的工作就越不可见。一次尖锐的架构审查可以避免数月的返工。一份范围得当的规格说明可以让 AI 生成数千行生产级代码。一个设计良好的评估框架可以提升组织中所有 AI 生成变更的质量。这些都不会出现在提交次数中。 问题不再是“我们的开发者有多高效？”它正在变成：我们如何衡量一个人类与 AI 越来越多地作为单一交付系统运作的工程组织？ ## 更多类似内容 ## 从产品工程师到工厂工程师 Warp 的 CEO Zach Lloyd（https://www.linkedin.com/in/zachlloyd/）捕捉到了这一转变，他认为（https://www.warp.dev/blog/we-are-now-factory-engineers-not-product-engineers）工程师正在变成“工厂工程师”而非“产品工程师”。这意味着价值越来越来自于改进生产软件的系统，而不是手动交付每个功能。成功的衡量标准是工厂运行得有多好，而不是某个工程师写了多少代码。 AI 编码智能体公司 Factory 的 CEO Matan Grinberg（https://www.linkedin.com/in/matan-grinberg/）在与McKinsey（https://www.mckinsey.com/capabilities/mckinsey-technology/our-insights/paving-the-road-for-ai-agents-interview-with-factory-ceo-matan-grinberg）的对话中提出了类似的观点。他将 AI 智能体比作“泥路上的法拉利”——只有当组织在底层工程基础（包括文档、测试覆盖率、CI/CD 和可观测性）上进行了投资时，这些强大工具才能交付价值。 那些永远不会作为功能交付出现的、不引人注目的基础设施工作。随之而来的是角色界限的模糊——当下的问题不再是某行代码是谁写的，而是谁拥有了客户成果。 这并不是工程经历的第一次身份转变。DevOps 自动化了交付管道。站点可靠性工程用设计好的可靠性取代了灭火。平台工程用共享能力取代了一次性的基础设施工作。智能体 AI 延续了相同的模式。工程师现在设计工作流程、定义护栏、验证 AI 输出，并持续改进生成软件的系统。 ## 当活动不再代表价值时 提交次数、Pull Request、关闭的工单和故事点仍然是活动的有用信号。但它们正变得越来越弱的价值信号。 Laura Tacho（https://www.linkedin.com/in/lauratacho/）曾研究过工程组织如何实际衡量 AI 的影响，她在大规模上遇到了这个问题。她在为《The Pragmatic Engineer》（https://newsletter.pragmaticengineer.com/p/how-tech-companies-measure-the-impact-of-ai）撰写的客座文章中研究了包括 Google、GitHub、Dropbox、Microsoft、Atlassian 和 Booking.com 在内的 18 家公司，发现仅靠 Pull Request 数量就不断地误导人们。而那些做对了的公司，会在信任活动数字之前先将其与质量检查配对： - Dropbox 发现经常使用 AI 的工程师提交的 Pull Request 多 20%，但他们只在报告这个数字的同时附上变更失败率，而该比率下降而非上升了。 - Webflow 发现 Pull Request 数量的增长并非均匀分布。在公司任职三年或以上的工程师推动了约 20% 的实际吞吐量增长，而较新的员工几乎没有变化。 - Microsoft 则追踪更上游的东西——“糟糕开发者日”（Bad Developer Days），一个与产出完全无关的摩擦指标。 正如 CircleCI 的 Shelly Stuart 在 Tacho 的研究中所说，产出指标（https://leaddev.com/reporting/metrics-dont-tell-whole-story）显示正在发生什么，而开发者体验数据告诉你这到底是否可持续。 同样的模式也普遍出现在各个团队中。当 AI 释放了实现时间时，强大的团队很少只是用额外的产能来交付更多功能。他们会减少技术债务、现代化遗留系统、并承担过去与功能交付竞争的运维工作。一个只读活动指标的仪表盘会将其记录为减速。而这通常是相反的：对组织长期交付能力的投资。 这就是为什么生产力越来越难以衡量的真正原因（https://leaddev.com/reporting/its-time-to-rethink-how-we-measure-engineering-productivity）——不是因为 AI 让它无法衡量，而是因为可见的活动和业务价值正在脱节。值得追问的问题正在从“谁产生了最多的代码？”转变为“谁最大程度地改进了系统？” ## 衡量真正重要的东西 解决办法不是一套新的虚荣指标。计算 AI 生成的代码行数或追踪提示词使用量，只会以新的形式重现旧问题——活动，而非影响力。相反，领导者应该评估整个工程系统是否在更好地交付客户价值。 DORA 的 2025 年报告给出了一个有用的起点清单。其AI能力模型（https://dora.dev/dora-report-2025/）列出了决定 AI 采用是带来复合收益还是适得其反的七项组织能力： - 清晰、沟通到位的 AI 政策。 - 健康的数据生态系统。 - AI 可访问的内部数据。 - 强大的版本控制纪律。 - 小批量工作。 - 以用户为中心。 - 高质量的内部平台。 这些都不是可以截图放到董事会汇报中的指标；它们更接近于成熟度审计，并且比发明另一个仪表盘是更可行的起点。 除了这份清单，三个转变会有所帮助： ### 个人产出 → 团队成果 软件从来都是一项团队运动，但自主开发系统让个人视角变得极具误导性。一个写代码更少的团队可能正在交付更多价值，因为工程师将时间花在了架构、技术债务和平台能力上。DORA 的交付指标（https://leaddev.com/ai/the-8-software-engineering-metrics-ai-broke）在这里仍然有用，不是作为个人的评分卡，而是作为系统表现如何的解读。 ### 活动 → 业务价值 随着 AI 降低了实现成本，优势来自于解决正确的问题，而不是产生更多的问题。客户是否采用了所构建的东西？可靠性是否在改善？工程师是否花更少的时间在重复性工作上，而花更多时间在复杂问题上？这些问题不会取代工程指标，而是赋予指标以意义。 ### 努力 → 杠杆 一名构建可重用工作流程、自动化测试管道或为 AI 智能体编写可靠护栏的工程师，可能几乎不显示可见代码，却能提升数十名同事的产出。这在员工级和首席级工程师身上一直如此，AI 智能体只是将这个原则进一步沿组织层级下推。那种杠杆就是生产力，即使它从未出现在提交图中。 这一切都不能孤立运作。Dropbox 的纪律是例外，而非常态。 Cortex 的2026年AI时代工程基准报告（https://www.cortex.io/post/ai-is-making-engineering-faster-but-not-better-state-of-ai-benchmark-2026）——基于对 50 多位工程领导者的调查以及多个组织的实际开发指标——发现了同样的 Pull Request 数量与质量分裂在整个行业中普遍存在，但缺少了让 Dropbox 的数据变得可信的那种配对。