作者 / 来源：中智凯灵 / AiDD

——从 AiDD 上海站看 AI 研发效能度量的新标尺

▼

在第 9 届 AI+研发数字峰会（AiDD 2026 上海站）上，很多分享并没有停留在“AI 能不能帮工程师多写代码”这一层。

更反复出现的问题是：当 AI Coding 工具逐渐普及以后，为什么代码写得更多，需求到上线的周期却没有明显缩短？为什么个人处理任务更快，跨团队协同依旧堵在原处？为什么 Demo 阶段很顺，进入真实交付后返工、评审、测试和线上风险反而一起变多？

这类问题的共同指向很清楚：AI 研发提效不是单纯的代码生成问题，而是组织交付问题。一个团队是否真的从 AI 中获得效能收益，不只取决于出码率、代码行数和工具活跃人数，也不只取决于单个工程师能不能更快完成任务。它更取决于需求是否更清楚、链路是否更顺畅、质量风险是否更早暴露、业务结果是否更稳定，以及项目经验能不能沉淀为下一次可复用的能力。

词元无限技术专家鲁奕志在《AI 驱动研发交付闭环，释放组织级效能》中提到一个值得警惕的现象：AI Coding 工具让个人效率明显提升，但组织交付仍可能原地踏步。这个判断放在研发效能度量上尤其关键。一个组织可以很快看到代码生成量、出码率和工具活跃度上涨，但如果这些数字没有进入端到端交付闭环，就很难证明 AI 真正带来了可验证、可治理、可持续的组织收益。

图 1：鲁奕志《AI 驱动研发交付闭环，释放组织级效能》：管理层关注点从“能生成多少代码”转向“能确保多少交付结果”（PPT 第 27 页）

因此，衡量 AI 研发提效之前，企业真正需要先问清楚的，不是“AI 写了多少代码”，而是下面 7 个更接近交付现场的问题。

▍个人变快以后，组织真的变快了吗？

研发管理里最容易被误读的指标，是单点速度。

代码生成快了，确实有价值；测试用例生成快了，也有价值；文档、注释、脚本和排查步骤被 AI 承担，同样能释放工程师时间。但如果这些变化只发生在个人工作台上，组织层面的收益未必会同步出现。

词元无限技术专家鲁奕志在《AI 驱动研发交付闭环，释放组织级效能》中提出了一个很典型的现象：AI Coding 工具几乎普及到每位程序员后，个人效率明显提升，但组织层面的交付速度并不一定同步改善，项目延期和质量问题仍然存在。

这个判断很关键。研发交付不是单个工程师写代码的速度之和，而是一条由需求澄清、方案设计、任务拆解、开发实现、测试验证、评审发布和线上反馈组成的链路。AI 如果只加速其中一个节点，却没有打通上下游，局部速度反而可能把问题更快推到下一个环节。

所以，AI 研发提效的第一个度量变化，是从“某个节点快了多少”转向“端到端链路是否真的变短”。需求到开发启动的时间有没有下降？等待和交接有没有减少？返工是否变少？风险是否更早被发现？这些指标比代码行数更接近组织真实收益。

图 2：鲁奕志《AI 驱动研发交付闭环，释放组织级效能》：从需求到开发启动 5 天压缩至 1 天，说明 AI 提效要看链路断点是否被补上（PPT 第 25 页）

▍出码率能说明什么，又不能说明什么？

这并不是说过程指标不重要。

去哪儿旅行基础架构负责人、技术总监李佳奇在《去哪儿旅行L3 AI Coding 的研发平台与 Skills 实践》中，分享了规模化 AI Coding 落地中的数据体系建设。对于一个数百人规模的业务研发团队来说，出码率、自动化水平、研发效率、覆盖需求数等指标，是组织判断 AI 是否真正进入研发现场的基础数据。

没有这些数据，管理层很难知道工具是否被采用、哪些团队走得更快、哪些场景适合自动化、哪些能力已经形成复用基础。换句话说，出码率是必要的观测点，但它不应该被误认为最终答案。

危险在于，组织一旦把出码率当成唯一目标，就很容易出现新的效能幻觉：AI 生成了更多代码，但这些代码是否对应真实需求？是否通过测试？是否减少人工Review 负担？是否降低缺陷逃逸？是否缩短上线周期？如果这些问题没有答案，代码越多，管理层越可能只是在统计“更快制造出来的中间产物”。

更合理的方式，是把过程指标放进一条指标链里看：工具覆盖人数和活跃使用率说明 AI 有没有进入现场；出码率和需求覆盖率说明 AI 参与了多少研发活动；交付周期、缺陷逃逸率、返工率和业务结果，才说明这些活动是否产生了真实收益。

图 3：李佳奇《去哪儿旅行 L3 AI Coding 的研发平台与 Skills 实践》：出码率、代码量、覆盖人数属于过程指标，最终仍要回到研发效率和业务价值（PPT 第 8 页）

▍Agent 参与越深，协作系统是否被重新度量？

AI 研发提效的难点，还在于 AI 的角色正在变化。

快手 AI Coding 专家周鸿轩在《从 Copilot 到 Agent：开发提效与范式跃迁》中梳理了一个行业演进路径：从代码补全、代码问答，到 Coding Agent、Agent Harness，再到 Agent Teams。每进入一个阶段，AI 改变的都不只是某个按钮或某段代码，而是人与工具、人与人、Agent 与流程之间的协作关系。

在 Copilot 阶段，组织主要衡量个人是否写得更快；到了 Coding Agent 阶段，就要衡量 Agent 是否能独立完成一类任务；再往 Agent Teams 演进，问题会变成团队能否让多个 Agent 稳定参与真实交付。

这时，单纯统计生成量就不够了。组织需要看到任务完成率、人工介入次数、上下文恢复能力、并行任务吞吐、跨角色协同成本、异步执行成功率、异常回滚次数。因为提效对象已经不再是“人机一次对话”，而是人、Agent、流程和平台共同组成的协作系统。

这也是为什么很多团队在早期会觉得 AI 很快，但扩到组织层面后又变慢。不是模型突然变弱，而是协作系统没有被重新设计，也没有被正确度量。工具可以让个体变快，体系才能让组织变快。

图 4：周鸿轩《从 Copilot 到Agent：开发提效与范式跃迁》：从增强个体到重构个体之间的协作关系，Agent 参与越深越需要度量协作系统（PPT 第 24 页）

▍需求和意图质量，有没有成为前置指标？

AI 写代码越快，需求问题越不能被推迟。

在传统研发里，需求表达不清会带来返工；在 AI 参与研发以后，这个问题会被放大。因为 AI 可以很快给出一个看似完整的实现，也可以很快把错误理解扩散到代码、测试、文档和流程里。

网易 CodeWave 智能开发平台架构师赵雨森在《从 Vibe Coding 到 Spec Driven 网易智企智能化软件工厂的思考和实践》中提到，Vibe Coding 降低了开发门槛，但也带来 AI 生成发散、技术栈不受控、代码难以维护等问题。要让 AI Coding 进入企业级大规模应用，就需要Spec Driven、需求 EARS 化、Benchmark评测和 AI 提效量化标准。

兴云数科资深需求 AI 教练郑涛在《意图驱动交付：Agent 时代从交付系统到交付价值的实践》中进一步提出，代码生成效率瓶颈正在消失，新的挑战是如何让系统持续对齐业务意图。业务意图、解决方案意图和验证意图，不再只是文档里的描述，而要成为可执行、可追踪、可验证的数字化资产。

这给 AI 研发提效带来一个重要提醒：需求质量本身也应该被度量。需求澄清周期、规格变更成本、意图一致性、验收准则完备度、需求到测试的可追踪性，都不只是过程管理细节，而是 AI 能否减少返工、稳定交付的前置指标。

如果需求和意图没有被度量，团队可能只会看到开发环节变快，却看不到返工在后面悄悄增加。

图 5：赵雨森《从 Vibe Coding 到 Spec Driven 网易智企智能化软件工厂的思考和实践》：从自然语言走向形式化约束的可靠路径，需求质量成为 AI 研发提效的前置指标（PPT 第 31 页）

▍没有质量护栏，提效还可信吗？

AI 研发提效还有一个更容易被低估的问题：速度和质量之间的关系变了。

过去，团队可以把很多质量问题交给固定规则、测试用例、CI/CD和上线监控来兜底。到了 Agent 时代，问题更复杂。Agent的输出可能语义上看起来正确，却偏离业务目标；链路状态可能全绿，用户体验却持续变差；一次任务成功，不代表换一组上下文仍然成功。

小红书资深工程师林能源在《从跑分到护栏：AI Agent 可观测和质量保障体系》中指出，Agent 落地瓶颈正在从“能不能跑”转向“能不能评估”。传统软件主要依靠单元测试和 CI/CD 保障质量，而 Agent 系统需要全链路观测、持续评估和决策治理。

这意味着，AI 研发提效不能只度量产出速度，还必须度量质量和风险。比如风险拦截能力、质量 Gate 通过率、线上离线评估覆盖率、Good Case / Bad Case 回流率、决策链路可观测性、异常归因时长、人工评审负担、缺陷逃逸率和线上事故率。

真正可信的提效，不是“更快把代码推上去”，而是“更快且更早知道哪里不该推”。如果没有评估、观测、回归和兜底机制，AI 可能只是把风险更快送到生产环境。

图 6：林能源《从跑分到护栏：AI Agent 可观测和质量保障体系》：离线评估与在线评估双轨并行，Bad Case 回流构成质量护栏闭环（PPT 第 28 页）

▍AI 有没有从一次任务变成组织资产？

很多 AI 提效只停留在一次任务里。

某个工程师用 AI 解决了一个问题，某个团队用 Agent 跑通了一次流程，某个项目靠提示词完成了一次交付。这些都值得记录，但如果经验只留在个人电脑、聊天记录或临时脚本里，下一次项目仍然可能从零开始。

从 AiDD 上海站多场分享可以看到，组织正在把 AI 研发能力从一次性使用推进到资产化：知识库让上下文可调用，记忆工程让经验可延续，Skills让最佳实践可执行，评测集让质量可回归，Bad Case 让失败可复盘。

因此，AI 研发提效还要衡量一类更长期的指标：结构化上下文沉淀量、可复用 Spec / Intent / Skills 数量、知识库命中率、Skill 复用率、Agent 成功案例沉淀率、Bad Case 回流率、评测集增长率、规则和护栏更新频次。

这类指标短期不一定像出码率那样显眼，却决定了组织能不能形成复利。一个团队真正从 AI 中获得长期收益，不是因为每次都能多写一点代码，而是因为每次交付之后，都有一部分经验留下来，成为下一次更快、更稳、更可控的起点。

图 7：郑涛《意图驱动交付：Agent 时代从交付系统到交付价值的实践》：效率、质量与组织能力共同构成交付结果，Skill 资产是规模化推广的基础（PPT 第 40 页）

▍一个更完整的 AI 研发提效指标框架

把这些线索合在一起，可以得到一套更适合管理层使用的AI 研发提效度量框架。

第一类，是 AI 渗透与能力成熟度指标。它回答“AI 是否真正进入研发现场”，包括工具覆盖人数、活跃使用率、出码率、需求覆盖率、自动化水平、Skills 数量和复用率。

第二类，是端到端流动效率指标。它回答“组织交付链路是否真的变短”，包括需求到开发启动周期、需求到上线周期、任务吞吐、等待时间、跨角色交接次数、人工断点数量和返工率。

第三类，是质量与风险指标。它回答“提效是否以牺牲质量为代价”，包括缺陷逃逸率、测试覆盖率、自动化测试生成率、质量 Gate 通过率、线上事故率、风险提前发现率和回归验证成本。

第四类，是业务价值与交付确定性指标。它回答“AI 是否帮助组织更稳定地产生业务结果”，包括按期交付率、业务需求达成率、从想法到验证的周期、业务指标改善、项目收口稳定性和交付结果可验证性。

第五类，是组织资产与持续进化指标。它回答“AI 能力是否变成了组织资产”，包括结构化上下文、可复用 Spec / Intent / Skills、知识库质量、Bad Case 回流、评测集增长和经验复用效果。

这五类指标不是让企业一下子建立一个庞大报表系统。更现实的做法，是先选一条关键研发链路，明确当前最想改善的是周期、质量、成本、体验还是知识沉淀，再把对应指标连成一条从过程到结果的证据链。

图 8：面向管理层的 AI 研发提效五类指标框架

▍结语：AI 研发提效，是把局部速度变成组织能力

AI 研发提效最容易被讲成一个速度故事：写代码更快、生成测试更快、总结文档更快、定位问题更快。

但企业真正需要的，不是单点速度，而是可验证的组织能力。一个组织是否真的从 AI 中获得效能收益，不在于它采购了多少工具，也不在于单个工程师每天多生成多少代码，而在于它是否把 AI 嵌入需求、设计、开发、测试、评估和运维的完整链路，是否让上下文持续流动、风险提前暴露、经验持续沉淀。

所以，AI 研发提效的度量体系，应该从“看起来更快”走向“确实交付得更好”。代码量、出码率、活跃人数可以作为入口，但不能作为终点。真正的终点，是交付周期更短、质量更稳定、业务结果更明确、组织资产更厚、下一次项目更容易成功。

别再只看写了多少代码。AI 研发提效真正要量的，是组织能不能更稳定地把想法变成价值。