再谈AI研发提效

关于软件开发提效，前面已经聊过一些，这里就不再赘述，本文结合实际落地进程，把几个关键环节再细说一说。

首先，以存量系统为主的软件密集型企业，与完全从 0 到 1 开始的组织，重心与策略还是有所不同的。从启动到相当长一段时间内，AI研发提效的重心，不只落在某几个纵向的技术点上，而应该首先落在横向的平台型全流程打通与资产治理（生成、使用与维护）上。在此基础上，需求、设计、测试等环节的技术点才能真正发挥作用。

企业的第一要务不是追某个先进技术点，而是把以平台型工具（可称研发工作台）为核心的全流程先打通，并且和企业原有的效能平台、测试平台顺畅接起来；依托平台型工具和 Agents，加上设计、出码、Review、自测自动往复的 Loop 这些常用工作流模板，用门控驱动研发活动的AI全流程运转。这件事的优先级之所以靠前，是因为它是“乘数”而不是“加数”：需求、设计、出码、评审、测试这些环节，任何一环单点的AI提效，都可能被上下游的断点淹没——出码环节省下的一小时，可能在流程流转、数据对齐上又花回去；反过来，全流程一旦打通，任何一环的小幅提升都会被放大。

统一研发工作台还有一个重点设计就是驱动从“人到事”到“事找人”模式的真正落地。以前这种说法也不是没有过，但靠人自觉或者传统流程是很难落地的。现在，平台型工具通过简单的消息提醒（如钉钉消息）与硬约束设置，在需求分派、需求/设计/代码/测试评审、必要的人工确认点等等，主动驱动人参与。想象一个全新的研发情景：产品正在吃饭时，收到需求来临/人工协助分派提醒，要求多久内处理，后续重复提醒并按规则分类警告/上报；研发正在开会时，收到设计/代码评审提醒；测试正在路上，收到要求对测试用例手工补充确认数据提醒……。这样，靠传统流程与人自觉的工作方式，转变成人是AI自主环节上的参与者。有可能这种模式刚开始时，人在工作流中的时间占比比机器更大，但仅模式转变这一条，就可以得到极大的提效效果，即“自主运转的AI型流程”。

统一研发工作台，还可以设置各种固定的工作流模板，把全流程AI，AI占比为主的流程，人占比为主的流程，要人参与的节点与约束，“出码—>自测—>Review—>修改-->再测”的自动Loop，都设置成常用工作流，需求来临时，自动分流到不同工作流自主执行。

平台统一之后，紧接着是资产治理。实际上，初期统一平台的作用并不是所谓的多Agents协同与拟人化员工，而是资产统一沉淀与使用、工作流与门控的载体。把代码和文档资产一点点梳理成 MD 文档，包括需求、设计文档和对应的 Skills，大家应该已经比较熟悉。而这里更值得注意的，是代码逆向地图这类资产的生成与消费。它的作用主要有两点：一是建立业务描述与代码位置之间的准确联系；二是做代码影响分析——甚至能扩展到对哪些系统、哪些版本、哪些补丁的影响。这个能力，在研发、问题排查、测试用例生成甚至需求等环节，都是底层支撑。

平台全流程打通、资产治理到位的同时，还需要关注几个关键环节上的先进技术加强。

先看需求（产品）环节，其中AI生成需求质量的提升是关键。除了产品业务知识与技能的准确、全面、可用之外，合理利用研发环节的技术资产也是值得尝试与验证的方案。在很多现实情况下，仅仅需求质量提升一项就可以明显提效。

再看研发环节。先看出码，这里有一个常见的误区：把AI研发提效等同于AI出码率，一上来就盯“AI写了多少行代码”。这个指标不能说没用，但对现阶段的规模型企业来说，出码并不是唯一重点，甚至对一部分场景来说，并不是最重要的那个——需求、设计、测试用例的生成与执行、问题排查、CodeReview，每一个环节的AI增强都能提效。

而且，出码恰恰是最需要谨慎的环节。举几个现实的例子。有的资深工程师，对代码和系统整体极为熟悉，在不少情况下，他写出来的代码质效会高于AI（当然也可以用AI辅助写代码）——他不光知道主要改哪里，还清楚别的模块哪里受影响、别的系统哪里受影响、哪些版本哪些补丁有牵连。在AI积累到足够的知识经验之前，人可能质效更高，为什么一定要强制全流程AI出码？再比如，有些关键系统，AI出码量不大时，强制人通过 diff 检查确认倒也可行；可一旦是关键业务系统的 Feature 级别需求，AI出码量又较大，人对代码又不完全掌握，后续出了问题AI自己解决不了，反而可能成为棘手的问题。还有一种情况，即便AI出码量不大，但为了这少量出码，人写提示词、检查结果花的时间，可能比直接手写还长，那还值不值得强制？类似的情况还有很多。因此，起码一段时间内各类场景的出码规则需要仔细斟酌，一是需求的任务拆分要细致合理，二是增量代码与任务必须可追溯，三是必须有明确的分类分流规则——哪类需求让AI出码、哪类需求允许人写、哪需求AI出码人来审、伪码的地位与出码规则是什么，先期不应一刀切。这类分流规则，下面谈测试用例生成时同样适用。同时，对核心交易系统，要通过研发工作台自动化工作流的节点提醒人在必要环节的参与及硬约束，包括充分利用伪码的作用，保障人对“出码可控可知”。

不过，市面上很多大厂，包括知名互联网厂商，公开宣传中都在用AI出码率作为衡量指标，这不得不让人认真考虑：它是不是行业通用规则？但尚不清楚的是：端到端提效了吗？是不是正因为如此才实现了全流程提效？这些数据来自哪些系统与场景，是核心业务系统吗？或许，需要配套研发模式的彻底改变、把人释放出来，才能达到该环节应有的目标，而这可能恰恰是很多企业下一阶段的目标。

而与出码不同，需求、设计、测试用例这些环节，在启动阶段倒是可以追求AI覆盖得尽可能全面。

出码之外，研发环节还要关注CodeReview、代码影响分析、自测等门控卡点的先进技术增强。

再来看测试环节。现实中存在很多类似的情况：AI测试用例生成比例不小，但采纳率不高、自动化执行率不高。甚至很多团队连测试用例采纳率的统计都难以做到——包括一次交互通过率、多次交互通过率这类对衡量改进比较有效的过程指标在内。那么，正如前面所说，测试与出码不同，倒是可以制定AI生成与自动化执行用例可高尽高的目标，追求能AI尽AI，但相当长一段时间内，同样要按场景对AI的使用水平分类分流。一是，人对相关情况非常熟悉时，教AI生成用例、再人工检查，未必比人直接写快；二是，从用例生成、检查到自动执行，端到端全部由AI搞定的情况也真实存在。所以测试环节的AI自动化水平不能只有一个统一档位，而要和出码一样，有一套结合实际的分类分流规则——什么场景全自动、什么场景AI生成人审、什么场景干脆人写。

在此基础上，还要关注测试相似用例召回、测试影响用例召回、增量测试造数等方面的先进技术增强。

把上面平台、需求、研发、测试环节综合起来看，可以得出一个判断：在以存量系统为主的规模型软件密集型企业里，相当长一段时间内，AI研发提效的主体会是两种大模式并存、按需求分流的局面。一种模式是一两个人加一组Agents（即“1 + 1 + N”），把某些需求从头到尾全流程自动跑完，只在关键节点需要人确认。这类需求的全部或大部分环节，人都可以不在场，属于AI原生模式，就是靠迭代的人来释放人力。另一种模式则是传统项目组模式——各环节仍以人为主，与平台、Agents 和流程配合交互。这类需求中AI本质上起的是辅助和加速作用，而非替代人。相当长一段时间内，第二种模式可能是主流，但随着AI使用的深入，第一种模式的占比会逐渐增大。当然，这两种模式实质上是“以AI为主”和“以人为主”两个笼统大类的抽象，在实际操作中，都需要细分为与具体需求类型对应的、不同级别的自动化水平。现阶段的关键，是把“哪个需求走哪条路”的分流判断做清楚——也就是建立分类分流规则。