为啥提效仍然没效？

当前企业界对AI研发提效的状态，可以用一句话概括：人人都说有效，个个都在推进，结果却差强人意。从高层到一线开发，从战略会到周报，AI提效已经成了标配议题。各家都在汇报“代码生成率提升X%”“需求响应时间缩短Y%”——数据好看，汇报有料。但转到经营视角，综合评估下来，真实感受却是三个字：没效。具体表现为三“没”：没降成本，研发团队规模未见缩减，人力成本依然高企；没增收入，合同额、回款率、客户续约率没有因为AI的引入而显著变化；没加速度，从项目启动到验收交付的整体周期，并未明显缩短。数字指标在局部改善，经营结果却纹丝不动。这中间的断层，到底卡在哪里？

先做一个基本判断：如果是标准化的产品开发场景，以新的feature不断设计发布为主体演进产品生命周期——从需求、设计、编码、评审、测试全流程闭环的AI研发方案，应该是可以明显加速的。但问题是，大多数行业软件企业的现实，并非如此。这类企业——包括很多经典的“产品公司”——当下的核心经营命题根本不是“用提效去拿更多合同”，而是更紧迫的一件事：快速交付现有合同，拿到有效收入。而现有合同的交付，无论产品型交付还是项目型交付，都卡在两个关键难点上。一是大量定制开发，几乎每个合同、每个客户都有；二是大量交付与运行问题需要解决。

对交付与运行问题，绝大多数是客户现场发现的漏出Bug，主要包括代码问题、业务逻辑与设计问题，以及数据问题。这其中有相当一部分是在客户现实数据环境中才发生的，数据量级、数据特征、数据质量与测试环境完全不是一回事，而AI直接解决这类问题效果受限可想而知。同时，对这些问题的解决，是要在一个庞大的旧代码资产基础上进行，其中最关键的环节是找到代码中问题相关部分，以及分析及定位，纯写代码的工作量占比并不多。大模型再强，也不了解庞大的旧资产；同时，对占主体的真实数据环境问题，大模型更加不了解，能起的作用当然很有限。所以这部分目前通过上述全流程研发提效方案效果不明显是可想而知的。

对定制开发问题，同样也是要在庞大的旧资产之上进行，大模型再强，也不了解庞大的旧资产，所以这部分目前AI效果不明显也是可想而知的。

除上述两大难点外，还有第三、四、五三个结构性阻力。

第三是版本多而杂乱。历史原因导致几乎每个客户都有一个“特定版本”。这些版本与产品研发主干（Trunk）的差异巨大，且差异程度各不相同。一个Bug修复或一个新Feature，究竟要合入哪些版本？影响范围是什么？关联关系如何？根本是一团乱账。旧代码资产的状况更是雪上加霜：缺乏注释，尤其缺乏业务语义的注释，大模型能理解技术逻辑但读不懂业务逻辑；长期修补导致代码庞杂纷乱；有时为了尽快改问题或图省事，同一段代码多处拷贝复制的现象层出不穷；接口设计、出入参定义复杂度极高，合理性存疑。人为复杂度高，既是旧代码版本的写照，也是大模型难以介入的根本障碍。

第四是流程复杂，环节繁多。技术上的复杂度，还要叠加流程上的复杂度。先不说企业内部研发流程，就是现场客户对接、开发与问题处理，在很多情况下，有反映需要处理的形式事务，甚至比实际开发、交付花的精力都多很多。

第五个是测试覆盖率不足。AI提效有没有效，最终靠测试来保证——这是基本逻辑。但一个残酷的现实是：在AI到来之前，测试覆盖这件事本身就漏洞百出。这里说的“覆盖率”远不止代码覆盖率，更重要的是场景覆盖——业务流程的各种分支和异常场景是否覆盖到；数据覆盖——不同类型、不同量级、不同质量的数据是否覆盖到；环境覆盖——不同部署环境、不同客户配置下的表现。现实情况是，很多测试用例在设计时就会不自觉地“依从研发意图”，而非真正从需求与业务出发。同时对技术架构和业务逻辑的全面深入理解，在测试环节一直是稀缺品。AI来了之后，目前能做到的，充其量是在“原来漏洞百出的基础上，增加了根据需求和设计自动生成测试用例的环节”。这远远不够——它没有解决测试覆盖的根本问题，只是让原来低效的环节变得高效了一些。

五个结构性卡点叠加，提效没效在现阶段几乎是必然结果。

有没有解决方案呢？

这里认为，主要的方案是2+N，即2个核心，与N个技术提升点。其中两个核心是现阶段到相当一段时间解决现实问题，产生显性提效实效的重中之重。

第一个核心是：要有好的模型可用。这一点看似废话，实则是最现实的瓶颈。实践经验证明：上面提到的诸多问题——旧资产上的定制开发，问题定位、分析与解决——如果用上了足够强的模型，成功率会有明显提升，甚至质的飞跃。强模型在“不了解旧资产”的情况下，凭借更强的推理能力和上下文理解能力，也能给出比弱模型精准得多的判断。但“有好模型可用”这件事，在很多企业里并不容易实现：算力不足，私有化部署大模型需要GPU资源，成本高、周期长；信创合规，国产化要求限制了某些模型的选择。在无模型可用或只能用弱模型的情况下，提效本身就缺乏基础工具，结果可想而知。

第二个核心是：模型友好的旧资产治理。如果把“好模型”比作一台高性能发动机，那“旧资产治理”就是给这台发动机铺设高速公路。核心工作是建立结构化的旧资产地图，将代码资产与业务、功能资产有效关联。具体而言：建立代码模块与业务功能的映射关系；梳理接口文档、数据字典、业务规则文档，并与代码建立可追溯的链接；为关键模块补充业务语义注释而非仅仅是技术注释；形成可被AI检索和理解的资产知识库。在模型能力不足时，好的资产表达是决定效果的关键因素——它弥补了模型“不了解旧资产”的短板。而在模型能力很强时，好的资产表达依然是关键的增效因素——让模型少走弯路、精准定位。这一项工作是“提效”从口号走向实效的关键工程。

在两个核心的基础上，N个工程技术提升点同样不可或缺。

一是Bug与Feature的关联版本AI自动检测。版本混乱的问题，可以通过AI自动分析代码变更与Bug修复的关联关系，识别影响范围，自动推荐需要合入的版本列表。这是一个技术可达、见效较快的能力建设。

二是现场问题的AI辅助代码定位与分析。针对客户现场发现的漏出Bug，由AI进行问题定位——结合上述代码资产地图，再充分利用日志分析、异常堆栈、代码分析等手段，自动圈定问题可能的代码区域，减少人工排查时间。这项能力与内部产品研发过程的技术方法类似，已有部分企业取得初步成效，值得持续深入与精化。

三是场景数据的AI Mock。针对测试环境与真实数据环境脱节的问题，利用AI自动生成覆盖真实业务场景、边界场景、异常数据、大流量场景的模拟数据，提升测试覆盖的真实性和有效性。

四是各复杂流程面向AI的简化，各不同流程之间面向AI的平滑串接（如钉钉、腾讯与效能平台等），以大大降低繁琐事务性工作带来的瓶颈，让AI能够自动触发审批、自动填充表单、自动更新状态——把事务性工作的瓶颈大幅降低，让人真正聚焦在创造性工作上。

五是通过建立自动迭代流程与指标驱动AI生成测试覆盖率的提升。建立自动化的测试生成-执行-分析-补充的闭环流程，用覆盖率指标驱动AI持续补充测试用例。这一步解决的是“在漏洞百出的旧状态上做增量改进”的问题，不求一步到位，但要持续优化。

实事求是地说：上述五个工程技术点做好，特别是两个核心打牢，或许能解决现阶段行业企业研发提效重心问题的90%。但这90%是针对“可解决问题的比例”，而非收入端实效的直接倍数——收入端的提升涉及多个环节，最终实效能有多少百分点，目前难以精确预估。但哪怕是5%、10%的实际收入端提升，在企业经营层面，也已经是相当可观的成果了。

但有一句话需要牢记：行百里者半九十。做到上述工作，意味着你在工程实践上已经走在了前面——解决了当前最痛、最实的问题，从“无效”进入“有效”的阶段。但这还不足以满足同行业技术先进性的要求。要做到真正领先或保持前沿，还需要持续进行先进技术的攻关。这些先进攻关可能带来的实效并不显著——在90%的基础上再提升1%、百分之零点几，甚至在某些维度上没有直接收益——但它们决定的是长期竞争力。具体方向包括但不限于：Agent Harness Engineering，多智能体协同框架的设计与优化，让不同Agent高效配合；全过程记忆与自反馈闭环的Agent持续优化，让Agent能够记住历史决策、从执行结果中自我学习、持续改进，而非每次都从头开始；可信安全评审，AI生成代码的安全漏洞检测、合规性审查、可解释性输出，确保AI生成的代码可信、可审、可维护。这些前瞻性技术攻关，是保证企业在AI研发效能领域一直走在甚至引领前沿的关键储备。

“为啥提效没效？”这个问题的答案，并不在AI技术本身——AI的能力是真实的，局部提效的数据也是真实的。问题在于：行业软件企业的研发效能在根本上受制于起码上述五个结构性的卡点，而这些卡点很多情况下并非AI直接能力范畴内的问题。破局的关键，不在于追问“AI还能做什么”，而在于扎实地做好两件事：让好模型可用，把旧资产治理好——让AI和存量资产之间建立起有效的连接。在此基础上，逐项攻克工程技术细节，同时在关键前沿领域保持技术储备。AI提效，不是一蹴而就的魔法，而是一场从基建到应用、从工程到前沿的系统性工程。方向对了，扎实推进，提效终将有效。