企业如何衡量AI研发的实际价值
AI Coding 研发体系｜第五篇
这一篇进入评估层：当前四篇已经把 AI Coding 放进流程和组织能力以后，企业还需要回答一个更硬的问题：它到底有没有创造真实研发价值。
本篇聚焦六层架构中的评估层。它向上承接流程和组织能力，向下连接治理边界。
AI Coding 推进到一定阶段后，团队很容易进入一个尴尬状态：大家都觉得用了 AI，代码也确实生成得更多了，但很难说清楚它究竟给研发体系带来了多少价值。
有人看采纳率，有人看生成代码行数，有人看工程师每天用了多少次工具。问题是，这些指标只能说明工具被使用了，不能说明研发结果变好了。
企业真正要回答的不是“AI 写了多少代码”，而是：需求交付周期有没有缩短，PR 周期有没有改善，Bug 率有没有上升，Review 打回率有没有变化，验证成本和人机协作成本有没有被算清楚。
评估层的作用，不是证明 AI 很有用，而是让企业知道哪些场景应该扩大，哪些场景应该暂停，哪些风险必须进入治理。
AI Coding 最容易被误判的地方，是把“使用热度”当成“研发价值”。
采纳率高，可能说明工具补全得顺手，也可能说明团队在生成大量低风险样板代码。生成代码多，可能代表效率提升，也可能代表 Review 负担、测试负担和返工负担一起增加。提示词次数多，可能是积极探索，也可能是上下文混乱导致的反复试错。
这些指标不是不能看，而是不能单独看。它们应该作为输入信号，而不是最终结论。
放回六层架构里看，评估层至少要回答五个问题：交付有没有变快，Review 有没有变顺，质量有没有变稳，验证成本有没有被吃回去，人机协作有没有真的变省力。
这五个口径合在一起，才比较接近架构图里“评估层”要回答的问题：AI 写了多少代码不是终点，企业要问的是交付、质量和责任有没有一起变好。
这里的 Intent Efficiency，可以理解成“意图转化效率”：人类一次意图表达，最终转成可合并结果的效率。它不只看 AI 回复得快不快，而是看从任务说明、上下文提供、代码修改、验证通过到人工确认之间，经过了多少轮反馈和返工。
指标一旦进入团队管理，最怕的不是不够精细，而是口径漂移。
比如“需求到合并周期”，到底从需求创建开始算，还是从工程师接手开始算；“Bug 率”是只算线上缺陷，还是把测试阶段发现的问题也算进去；“AI 返工率”是人工要求重做，还是测试失败后的自动修复也算。
不用一开始就把指标做成复杂标准，但至少要让同一个团队在同一段时间里用同一套口径。否则看板会很漂亮，结论却不可比较。
继续用前几篇的订单列表 CSV 导出需求来看。
如果只看工具层，团队可能会记录：AI 生成了导出按钮、CSV 组装逻辑和部分测试。这个记录有用，但不够。
评估层会追问更多问题：这个需求从创建到合并是不是缩短了；PR 准备和 Review 打回有没有减少；AI 第一次输出后需要几轮反馈；权限校验有没有一次通过；旧的订单查询测试有没有被影响；省下的编码时间有没有被验证和解释成本吃掉。
同一个 AI 生成成功的任务，只有进入交付周期、Review 周期、质量返工、验证成本和人机协作五个口径以后，才真正变成可评估的研发价值。
评估层不能只服务管理者，也不能只服务个人复盘。更合适的做法，是把评估拆成任务、团队和组织三层。
任务层看局部成败，团队层看能力变化，组织层看扩大边界。三层混在一起，就容易出现两种误判：个人觉得好用，组织却没有收益；组织要求推广，团队却在返工和 Review 里消耗更多时间。
这里还有一个管理上的坑：把 AI Coding 指标变成个人排名。
一旦团队只奖励采纳率、调用次数或生成代码量，工程师就会自然地把更多任务塞给 AI，甚至把不适合自动化的高风险任务也包装成“AI 参与”。最后看板变漂亮了，真实研发质量反而更难判断。
评估层更应该服务三个决策：哪些任务适合交给 Agent；哪些团队需要补上下文、验证和监督能力；哪些场景已经暴露出权限、审计、成本和发布门禁问题，需要交给治理层处理。
好的 AI Coding 评估体系，不是把人逼着多用 AI，而是帮助团队知道什么时候该用、怎么用、用到什么程度必须停下来治理。
到这里，六层架构里的评估层就接住了前面的流程层和组织能力层：流程告诉 AI 如何进入研发，组织能力告诉人如何监督和协作，评估层则告诉企业这些变化是否真的带来了价值。
如果回到第三篇的能力模型，这一层主要考验的是 L5 AI Engineering Manager 和工程效率团队：他们不是统计谁用 AI 更多，而是把交付周期、Review、质量、验证成本和人机协作效率放进同一套研发管理口径里。
但只要开始评估，就一定会遇到下一组问题：谁可以让 Agent 改哪些代码，哪些任务必须人工验收，成本怎么设预算，日志和审计怎么留，出了问题责任怎么划分。
这些问题已经超出评估本身，会把企业推向治理层：权限、审计、成本和责任边界必须被明确下来。
后续会继续拆 Agent 研发组织的治理边界。做研发管理、工程效率或企业 AI 落地的朋友，可以连起来看。