AI 提速背后：研发效能的深层瓶颈

编写代码、补充测试的速度提升了，设计文档、日志分析也变快了，AI 赋予的个人效率增益，技术同仁们感同身受。然而，个人效能显著跃升后，团队整体产出却未同步跟进，部分团队甚至出现倒退。

代码产量激增，但甄别代码是否契合业务需求、能否合并至主干却愈发棘手；

测试用例数量膨胀，可核心风险点是否真正覆盖，无人能给出确切答案；

方案设计加速，但面对需求变更、非功能指标、业务影响评估及上线后稳定性保障，底气反而不足。

这三类现象并非孤立存在。它们共同指向一个结构性矛盾：AI 加速了软件研发价值流中每个环节的“生产操作”，但各环节的“决策判断”仍依赖人工的速率与经验。

方案产出更迅速，是否覆盖真实业务约束、是否遗漏非功能风险，依旧仰仗个人经验；

代码编写更快捷，能否合并、是否引入耦合、是否触碰架构红线，仍需人工审查；

测试用例生成更高效，是否触及真实风险边界、覆盖率是否虚高，难以甄别；

发布编排更迅速，安全性如何、依赖项是否准确、回滚路径是否经测试，还得运维人工复核；

线上故障发生时，AI 虽能快速输出分析结论，但诊断是否可靠、根因是否找准、修复是否引发新问题，最终仍需人工兜底。

产出端全面提速，判断端却仍维持人工速度。这正是局部提效无法转化为整体提效的根本原因。价值流是一条完整流水线，只要任一环节的决策滞后，整条链的流速即被阻塞。AI 加速越猛的环节，下游的决策压力积压越重。

这些现象与问题，正是重新审视研发效能的起点。

DORA 2025 年报告追踪了类似议题：采用 AI 的团队，软件交付吞吐量反而降低、不稳定性上升。报告由此得出一个结论：**决定 AI 影响力的并非工具本身，而是其嵌入的组织系统。**DORA 的观点直白：**AI 既是镜子，也是放大器**：在高度协同的组织中，AI 放大价值流动；在碎片化的组织中，AI 将痛点暴露得更为刺眼。现代质量管理之父威廉·爱德华兹·戴明曾言：“糟糕的系统总会战胜优秀的个人。”

坚实的平台、清晰的流程、顺畅的团队协作，在此类组织中，AI 将放大既有工程能力。反之，若流程混乱、信息割裂、质量保障与反馈机制薄弱，AI 带来的局部提速很快会被组织内耗抵消殆尽。

这便将问题引回研发效能：效能绝非仅指交付速度。团队推进效能建设，固然希望需求流转更顺畅、重复劳动更少；但同时也需让质量问题更早浮现，让发布与运行更稳健，让工程改进最终回归业务成果。归根结底，是为了更快、更稳、更好地交付业务价值。

AI 并未颠覆研发效能的目标。它仅极大加速了价值流中每个生产动作。后果是：这些动作背后的决策、验证与反馈压力，被整体向前推移：并非仅压在某环节，而是沿设计→编码→测试→发布→运维→复盘全链条同步挤压。

传统研发效能中经典的黄金三角：**实践、平台、度量**。它揭示了研发效能问题无法靠单点工具解决。

上图引用自 参考资料 1

实践回答“团队该如何做”，平台回答“这些做法如何被稳定支撑并规模化复用”，度量回答“我们究竟改进了什么，又卡在哪里”。三者相互依存促进：优良实践沉淀至平台，如将发布规范、测试策略、质量门禁转化为可复用能力；平台在承载流程同时留存数据，助团队洞察交付、质量、稳定性及协作中的问题；度量再将洞察反馈至实践，促成下一轮调整。

将黄金三角置于 AI 场景审视，压力分布已变。此处最易被放大的，是局部提速与整体效能间的落差。团队交付的，从来不是代码、测试建议与分析结论的简单堆砌。

过往的平台与流程，多围绕人主导的工程协作设计：需求理解是否透彻，变更风险是否明晰，测试结果能否支撑发布，事故结论是否有据可查，最终皆回归团队判断。平台承载流程、沉淀数据、暴露瓶颈，再引导团队利用这些信息持续优化。

当 AI 深度介入这些环节，情况开始不同。AI 带来的不仅是更快的局部产出，还包括更多候选方案、候选代码、测试建议、分析结论，以及更早进入链路的工程判断。于是，原本至关重要的质量门禁、可靠性验证与效能度量，均面临新挑战。

DORA 2025 年报告也印证了这点：唯有平台质量较高时，AI 方能对组织绩效产生正向推动。报告将平台称为 AI 的“倍增器”。

但过往的验证体系由人驱动：方案对错靠评审经验，代码能否合并靠架构师心中不成文规则，测试有效性靠系统直觉，发布安全性靠逐项检查清单。判断标准分散于不同个体脑中，靠口耳相传，靠评审会上的一句“此处不妥”。AI 大规模介入后，这套体系已跟不上 AI 的产出速率。

若平台仅能承载流程，无法承载判断，则尚未准备好成为 AI 的倍增器。

报告归纳了决定 AI 影响力的三项组织条件：数据是否就绪，工程纪律是否到位，平台与立场是否稳固。全部落脚点在于团队与组织层面，AI 工具本身不决定结果。

若平台仍停留在流程承载与活动统计层面，便难以支撑此类变革。AI 带来更丰富的产出，判断依据、验证方式与度量对象也必须随之调整。缺乏足够上下文与验证，质量与可靠性无从谈起；质量无法保障，可持续交付业务价值亦将落空。

原有的研发效能黄金三角依然有效。但当 AI 介入工程决策环节，传统效能面临的问题已变：不仅是流程如何流动，还包括上下文是否充足、判断是否有据、风险如何验证、反馈能否闭环。见下图：

实践需落脚于工作方式——人与 AI 如何协同理解问题、准备证据、做出权衡，也成为实践的一部分。

平台依旧关键，但上下文、验证、反馈与治理边界不可各自为战。效能度量亦需变革：除效率外，还需回答判断是否更精准、风险是否更早暴露、经验是否融入下次决策。

我并非要给黄金三角贴上 AI 标签，而是 AI 的采用使研发效能面对的问题本质发生了变化。我们必须关注：工程现场是否被有效组织，判断是否有据可依，风险是否经验证，反馈是否形成闭环。

先界定一下“工程认知”，此处并非指团队“懂不懂工程”，而是指工程现场的判断依据是否被组织起来、能否被复用。其与“工程能力”的区别在于：能力是个体的、隐性的、随人流动的；认知是团队的、显性的、可沉淀传递的。一位架构师脑中有 50 条架构红线，这是能力；这 50 条红线转化为每次方案评审自动检查的规则，这才是认知。

举一个典型案例：

某支付服务刚发布，转化率下滑，接口延迟升高，告警频发。此时团队启动应急响应，并非缺乏工具：发布记录在平台，监控图表在系统，工单有人跟进，代码仓库可查近期变更。问题在于，这些信息常分散于不同系统：

谁能将此次需求变更、对应代码、依赖拓扑、链路指标、用户影响、历史事故及回滚方案整合至同一判断场景？

谁能告知团队当前最应怀疑哪类风险，而非在一堆相似告警中反复翻找？

谁又能在事后将此次判断中真正有价值的经验留存，而非下次换批人重新摸索？

团队缺少的不是一个更会回答问题的助手，而是一套将工程现场组织为判断的能力。这正是我更愿将 AI 时代的研发效能理解为“工程认知”问题的原因。

要破解此矛盾，不能靠每个环节单独增人加时。真正的出路在于：将判断标准从人脑移出，转化为结构化、可执行的原则与规则，让 AI 自身参与判断。

这并非主张用 AI 替代人的判断。而是指：方案生成时，是否有显式架构原则进行检查？代码提交时，是否有可执行边界规则进行验证？测试生成时，是否有风险覆盖标准进行衡量？发布执行时，是否有安全约束进行拦截？事故复盘时，是否有诊断框架进行校准？

过去散落于各团队与个人的隐性知识，在 AI 引入后必须显式化、规则化、可自动化，方能追赶 AI 的产出速度。人需从“逐条做判断”转变为“定义什么是对的”。这便是接下来要探讨的工程认知：它非虚词，至少落在五件事上：

这五条流并非并列，而是一条链：上下文滋养决策，决策驱动执行，执行触发验证，验证沉淀为学习，学习反哺丰富上下文。

回到前述支付系统案例。同样的事故现场，五条流缺位与到位，差异显而易见：

这便是“工程认知”在事故现场的具体意涵。并非让 AI 替人拍板，而是让每次判断皆有上下文可依、有验证可查、有经验可复用。

这五条流应贯穿需求、设计、编码、测试、发布、运维、复盘等工程效能全生命周期。每一轮迭代，都应运行这五条流。

回到文章开篇之问：个人提效了，为何团队未跟上？因为 AI 加速的是生产动作，而非判断能力。若判断能否跟上、经验能否传递、风险能否早发现等问题未解，个人效率越高，团队效率被卡住的风险越大。

认知是道，平台是术，AI 只是器。问题不在于 AI 是否有用，而在于我们是否为其准备好一个能承载并放大其价值的工程体系。做好此事，团队方能不止“流程跑得更快”，而是“判断做得更好”。

AI 时代的研发效能，并非将黄金三角替换为一组 AI 工具。一旦 AI 开始参与工程决策，实践、平台与度量需共同回答新问题。

下一篇我们将直接切入最实际的问题：

AI 应如何融入工程体系，才不会将每一次不确定的建议转化为生产风险？