AI 研发提效的另一半:Verification is all you need

过去，编码本身占掉了研发的大量时间。现在 AI 把这段时间压缩了，但需求理解、架构约束、测试验证和线上反馈并没有一起消失。代码来得越快，验证压力越容易集中到后半程。AI 能让一段代码很快跑起来，不等于它能长期维护，更不等于组织的工程能力也随之提升。

讨论中有个观点让我印象很深：低效开发者使用 AI 后，产出质量往往有明显改善；水平较高的开发者获得的边际收益却没那么大，代码腐化还可能提前 6 到 9 个月出现。这未必适用于所有团队，但它提醒了我，单看生成速度和采纳率，很容易把后续成本漏掉。AI 节省下来的时间并不是免费收益，团队还要支付“验证税”。

所以，质量保障不能只在生成结束后接手。更合理的做法是在需求、设计、编码、合并和发布这些节点持续验证，把发现的问题沉淀回规则、测试和知识库。个人修掉一个错误，只解决了这一次；同类错误以后能被自动拦住，才算组织能力真的有了积累。

各家公司讲到 Harness 时，建设方向其实大差不差：大仓套小仓，给 Agent 提供可控的运行环境；把规范、经验和业务知识做成 Skill 入库；再补上代码导航、动态路由和企业级治理。架构图不会相差太远，真正拉开差距的是这些能力有没有进入日常研发流程。

我更关心的是几个关键节点能否守住结果。需求进入编码前，有没有足够明确的上下文和约束；代码生成后，有没有自动化测试、静态分析和评测兜底；准备合并或发布时，质量门禁能否识别回撤风险。Harness 建得多完整并不直接等于有价值，经过验证、可以交付的结果才是。

这件事也不能只靠几个“超级个体”推动。开发者在使用 AI 时修正的问题，需要回流成团队共享的规则。业务负责人则要给流程改造留出明确投入，否则专项建设很容易在交付压力下让位。组织级的提升，来自“生成、验证、修正、沉淀”这个循环真正转起来。

AI 研发效能不能只看用了多少人、写了多少代码，也不能只看工具采纳率。很多经典指标都可以增加 token 维度，比如单位需求消耗多少 token、每次有效合并对应多少 token、返工和回撤消耗了多少 token。token 不是价值本身，但它让 AI 成本有了更细的观察刻度。

同时还要看节省出来的时间去了哪里。如果只是让人短暂空出来，ROI 很难成立；如果这些时间重新投入到更多业务交付、质量改进或工程资产建设里，收益才真正发生。吞吐量、交付周期、线上质量与 token 成本需要放在一起看，否则很容易得到一个局部漂亮、整体失真的结论。

这次参会之后，我对 AI 研发效能的关注点更明确了。让 Agent 写得更快只完成了一半，另一半工作是扩大验证范围、守住关键节点，并把每次人工修正变成下一次生成时可以复用的约束。

生成能力会越来越普及，单纯比拼生成速度的意义也会下降。能否建立稳定、可度量、能持续回流的验证体系，决定了 AI 带来的效率能不能变成长期工程能力

推荐阅读