夜雨聆风银行智能研发十讲 09：从代码采纳率到 AI 合规入库率，真正要看的是可控价值
有批评建议期待评论区留言
AI Coding 不能靠热闹管理，调用量再高，也不等于研发能力真的变强
CIO 最关心的，是 AI 参与的代码有没有走完审查、测试、合并、安全放行和生产验证这些关键环节
指标的本质，要从衡量个人体感升级为衡量工程结果
只看活跃度和调用次数，AI Coding 很容易变成一场昂贵的内部运动
30 秒
读懂这一讲
这一讲谈智能研发的“管理仪表盘”。
很多银行已经把 AI Coding 推进到真实研发现场：账号开了，插件装了，培训做了，调用量起来了，生成代码行数也有了。热闹之后，CIO 会开始追问更实在的问题：研发周期缩短了吗，测试覆盖提升了吗，安全风险前移了吗，版本问题提前暴露了吗，生产故障下降了吗，组织经验沉淀了吗，单位任务成本降下来了吗。
头部银行的智能研发实践已经给出一个清楚方向：AI Coding 不能只放在插件、代码补全和个人效率里看，它正在被放进智能研发平台、模型底座、知识资产、场景工程和组织运营里一起管理。指标体系也要随之升级，从“有没有用 AI”，走向“AI 产出了多少可控价值”。
中国金融行业还有一个非常现实的变量：大量研发组织并非纯自有团队，而是由自有人员、不同级别开发外包、测试外包、驻场支持团队共同构成。AI Coding 进入以后，指标体系还要回答一个更具体的问题：AI 到底是在提升“自有 + 外包 + 测试 + Agent”的组合效率，还是把更多 review、返工、安全和责任压力推回给自有团队。
这套仪表盘至少要覆盖三层：第一层是 CIO 看价值，第二层是开发中心看流程，第三层是一线团队看行动。所有指标最终都要回答一个问题：AI Coding 到底在制造热闹，还是在改善研发体系。
01
先看全景：
智能研发指标金字塔
银行做 AI Coding，最容易陷入“指标很多、看不清重点”的问题。调用量、采纳率、生成行数、活跃人数、测试覆盖率、安全阻断数、版本风险数、知识命中率、Token 成本，每个数字都有道理，放在一起却容易变成一张厚报表。
CIO 真正需要的是一张金字塔式仪表盘。
最上层是战略价值指标，回答管理层最关心的问题：研发周期有没有缩短，生产问题有没有下降，故障恢复时间有没有改善，AI 合规入库率有没有提升，单位任务成本有没有下降。这个层面不需要过多细节，但必须能反映投入产出。
中间层是工程过程指标，回答开发中心最关心的问题：AI 参与的代码有没有进入主干和版本，单测覆盖率有没有提升，代码复核检出率有没有改善，安全门禁有没有提前拦截风险，版本问题有没有在投产窗口前暴露出来。这个层面决定 AI Coding 能否进入真实研发流程。
底层是一线行动指标，回答团队每天要改什么：哪些场景采纳率高，哪些任务人工修正多，哪些上下文经常缺失，哪些工具调用失败，哪些知识命中不准，哪些安全扫描反复不过，哪些外包交付经常返工，哪些测试用例看起来很多却发现不了关键缺陷。这个层面决定工具、知识、流程和人员能力如何持续改进。
这三层连起来，AI Coding 才能从“工具使用统计”进入“研发生产管理”。
02
警惕表面繁荣
从流量思维转向价值思维
很多机构在 AI Coding 推广初期，最关注调用量和生成代码行数。这些指标容易统计，汇报也好看。多少人开通了账号，多少人每天使用，生成了多少代码，覆盖了多少项目组，这些数字很容易让组织产生一种“已经跑起来了”的感觉。
但对银行 CIO 来说，这些只是第一层信号。调用量高，最多说明工具被频繁使用；生成代码多，只能说明 AI 参与了编码过程。代码进入主干和版本之后，还要继续接受测试、安全、交付和生产运行的验证。一个团队可能每天都在问 AI，但问的都是低价值问题；一个工具可能生成了大量代码，最后被开发人员大幅修改甚至废弃；一个智能体可能被频繁调用，却没有进入测试、交付、安全和运维这些关键流程。
银行科技体系最怕热闹的空转。AI Coding 看起来很活跃，内部培训很多，工具调用很多，生成代码很多，但真实研发问题没有减少。需求澄清仍然慢，设计质量仍然不稳，测试压力更大，交付风险仍然后置，安全扫描问题更多，生产故障没有下降，知识沉淀也没有改善。这样的 AI Coding，最多说明工具试用成功，还不能说明智能研发成功。
大型银行做智能研发，指标体系不能停在前端热闹指标上。更有价值的指标往往出现在后半段：设计阶段提前检出了多少问题，单测覆盖率有没有提升，代码复核检出率有没有改善，安全门禁阻断了多少高危风险，交付阶段提前发现了多少版本问题，运维侧是否缩短了故障定位时间。只有把这些指标连起来，管理层才能判断 AI Coding 是否真正改善了研发体系。
03
CIO 真正关心的六张账
智能研发指标可以很多，但 CIO 不会被被指标清单淹没。他们关心的第一张管理仪表盘，是先盯住六张账。
第一张账，是 AI 参与的代码有没有合规入库。AI 写了多少代码并不关键，关键是这些代码有没有经过人工审核、测试验证、安全门禁，并最终进入代码库、主干和版本。
第二张账，是 AI 生成代码的缺陷密度有没有下降。AI 参与的代码越多，越要看每千行代码中的缺陷、安全问题、返工和后续修复次数。AI 产出增加以后，质量没有同步改善，研发体系会承受更大的后续压力。
第三张账，是安全风险有没有提前拦截。安全问题出现在编码现场、提交前、流水线、投产前，管理意义完全不同。越早发现，处理成本越低，对生产的影响越小。
第四张账，是版本问题有没有提前发现。环境差异、依赖冲突、脚本遗漏、接口影响、配置不一致，到了投产窗口才暴露，风险已经很高。AI 参与交付之后，版本问题提前发现数应该成为开发中心非常重要的指标。
第五张账，是生产问题和故障恢复时间有没有改善。AI Coding 最终要接受生产环境检验。生产问题下降、故障定位加快、MTTR 下降，这些指标才接近管理层真正关心的结果。
第六张账，是单位任务成本有没有下降。AI Coding 小范围试点效果好，不代表大规模推广可持续。模型调用、算力、知识检索、人工修正、平台维护，都要进入成本视角。长期看，CIO 要盯住的是单位价值成本，而不是单纯的调用成本。
这六张账连起来，才能判断 AI Coding 是工具试用，还是正在走向研发生产力。
04
从产品视角
还要补五类指标
站在 AI Coding 产品负责人视角看，智能研发不会只看最终结果，还要看产品漏斗和工程可观测性。银行判断一个 AI Coding 工具是否成熟，也不能只看它会不会生成代码，还要看它能不能进入任务、上下文、工具、规则和审计体系。
第一类是任务完成率。AI 接到一个明确任务后，有多少任务能走到可 review 状态。一个任务从需求描述开始，经过计划生成、代码修改、测试执行、扫描检查、PR 提交、人工 review，最终进入合并或退回。每一层掉得太多，都说明产品体验、上下文质量、工具调用、模型能力或流程集成存在问题。
第二类是证据完整率。AI 交付结果时，有没有附带测试结果、终端日志、扫描结果、变更说明和引用依据。银行研发需要可验证、可审计、可追责的结果。AI 只给一段代码，review 成本会很高；AI 同时交付证据，开发人员、测试人员、安全人员和审计人员才有基础判断它是否可用。
第三类是工具调用成功率。Agentic Coding 的价值很大程度来自工具调用。AI 能不能读对文件，能不能改对文件，能不能跑通测试，能不能正确调用扫描工具，能不能稳定触发流水线，能不能把失败日志转成下一步动作，这些都需要指标。工具调用成功率、命令执行失败率、测试执行成功率、MCP 调用成功率、工具权限拦截率、工具调用平均耗时、工具调用后人工修正率，都应该进入产品仪表盘。
第四类是上下文与规则生效率。企业级 AI Coding 产品越来越强调项目上下文、企业知识库、Rules、Skills、MCP、代码图谱和项目知识图谱。银行不能只看有没有知识库，还要看知识和规则有没有真正进入生成过程。项目上下文覆盖率、上下文复用率、规则生效率、Skills 有效率、企业知识库调用有效率，这些指标比“知识库有多少文档”更接近 AI IDE 的真实能力。
第五类是企业后台可观测性。大型银行需要统一管理不同部门、项目、岗位、入口、模型和工具调用。管理员能不能看到受控工具链覆盖率，能不能配置权限、规则、知识库、模型路由和审计策略，能不能把指标导出到行内研发效能平台，决定了 AI Coding 能不能从个人工具进入组织管理。
这些产品指标能帮助银行判断：AI Coding 工具只是装在开发人员电脑上的插件，还是已经成为可管理、可审计、可运营的企业级研发平台。
05
覆盖率与活跃度
只是入场券
覆盖率和活跃度是智能研发的入门指标，必须看，但不能停在这里。
覆盖率回答“AI Coding 有没有进入研发体系”。比如覆盖了多少研发人员，覆盖了多少部门，覆盖了多少应用，覆盖了多少语言栈，覆盖了多少项目组，覆盖了多少研发阶段。对大型银行来说，覆盖率还有一个特殊含义：总部研发、分行科技、外包团队、驻场团队、测试团队、运维团队、架构团队，是否都在同一套受控工具体系内，避免各自使用不同外部工具带来的数据、代码和审计风险。
但对严肃金融机构还要增加一个更适合金融的指标：
受控工具链覆盖率 = 在统一 AI Coding 平台内发生的研发任务数 / 全部 AI 相关研发任务数。
这个指标比“多少人用了 AI”更关键。它回答的不是工具有没有普及，而是研发活动是否发生在统一模型入口、统一 IDE 插件、统一权限体系和统一审计留痕之内。
活跃度回答“大家有没有真的在用”。比如日活、周活、月活，人均调用次数，人均使用时长，连续使用天数，插件启用率，智能体调用次数，AI IDE 使用频率，代码问答次数，测试生成次数，交付分析次数，安全扫描解释次数，运维日志分析次数。
这些指标在推广初期很有用。一个工具没有人用，后面所有价值都谈不上。但 CIO 心里清楚，覆盖率和活跃度只能证明工具进入了现场。至于价值有没有进入流程，还要看后面的工程结果。
把覆盖率和活跃度当成最终目标，AI Coding 很容易变成一场内部运动。大家都在用，报表很好看，工程结果没有改变。管理层真正要看的，是活跃之后发生了什么：采纳有没有提升，入库有没有发生，测试有没有变强，安全有没有前移，交付有没有改善，生产有没有更稳。
06
代码采纳率
衡量 AI 建议的体感
代码采纳率是 AI Coding 最常见、也最容易理解的指标之一。它回答的问题是：AI 生成的代码，有多少被开发人员采纳了。
表面看，这个指标很直接。AI 给出一段代码建议，开发人员接受了，就是采纳；开发人员拒绝了，就是未采纳。代码补全、函数生成、单测生成、修复建议，都可以计算采纳率。但在银行智能研发场景里，粗口径的采纳率很容易误导判断。
采纳率至少要拆成几类。直接采纳，说明模型、上下文、规约与当前任务比较匹配；修改后采纳，说明 AI 生成结果有参考价值，但仍需要开发人员加工；废弃，说明 AI 生成结果没有进入后续工程流程，问题可能出在任务定义、上下文、知识调用、规约约束或模型能力上。
还要区分不同场景。代码补全采纳率、单测生成采纳率、注释生成采纳率、缺陷修复采纳率、重构建议采纳率、安全修复采纳率，含义完全不同。代码补全采纳率高，不代表安全修复建议可靠；单测生成采纳率高，也不代表核心交易逻辑可以放心交给 AI 改。
更关键的是采纳后的质量。AI 生成代码被采纳，并不代表它没有问题。有些代码被开发人员接受，是因为看起来合理；后续测试发现漏洞，安全扫描发现问题，评审发现逻辑缺陷。这时，单纯采纳率高反而可能说明团队对 AI 过度信任。
更合理的口径应该是：
有效采纳率 = 被采纳并通过测试、扫描、评审的 AI 代码 / AI 生成代码总量。
这个指标比简单采纳率更有价值，它把“开发人员觉得可用”推进到了“工程上真的可用”。
还可以补一个产品侧指标：委派深度。开发人员只是让 AI 解释代码，还是愿意让它生成计划、修改多文件、运行测试、提交 PR。委派深度越高，产品信任越强；委派深度长期停留在问答和补全，说明 AI Coding 还没有真正进入工程任务。
07
AI 合规入库率
从个人体感进入工程结果
代码采纳率衡量的是开发人员是否接受 AI，AI 合规入库率衡量的是 AI 参与的代码是否真正进入代码库，并完成必要的工程校验。
这个指标更接近工程结果。银行研发不会在编辑器里结束，而是在代码合并、分支管理、测试验证、安全扫描和版本交付中完成。AI 代码被采纳到本地，不代表它能合并；合并到分支，不代表它能进入主干；进入主干，不代表它能进入版本；进入版本，也不代表它能稳定运行。
AI 入库率至少要分层看。AI 参与生成并提交的代码，占总提交代码的比例；AI 参与生成并进入主干的代码，占总入库代码的比例；AI 参与生成并进入版本的代码，占总版本代码的比例；AI 参与生成并通过安全扫描、测试验证、人工 review 的代码，占 AI 入库代码的比例。
更适合金融机构的口径是：
AI 合规入库率 = AI 参与生成、经过人工审核、通过测试和安全门禁、成功合并入库的代码量 / 总入库代码量。
这个指标开始接近智能研发的真实价值。它说明 AI 写出的内容已经穿过研发流程，参与了可控工程结果的产生。
AI 合规入库率最好不要只看一个总数，还要拆成漏斗。建议数、采纳数、代码变更数、PR 数、测试通过数、安全通过数、review 通过数、合并数、版本发布数、上线后问题数，每一层都能暴露不同问题。生成很多、PR 很少，可能说明生成质量或开发者信任不足；PR 很多、测试失败很多，可能说明质量不稳；测试通过、安全失败多，可能说明规约和安全上下文不足；合并很多、生产问题多，可能说明后链路验证不充分。
AI 合规入库率也不能单独代表成功。代码入库只是进入研发流水线，还不能直接等同于生产价值。后面还要看测试质量、安全质量、交付质量和生产质量。CIO 要警惕一种情况：AI 入库率上升了，缺陷率也上升了，回滚率也上升了，生产事故也上升了。这说明 AI 只是更快地把风险送进了代码库。
从代码采纳率走到 AI 合规入库率，指标开始从个人体感进入工程结果。这个变化很关键。采纳率代表开发人员觉得好用，合规入库率代表研发体系接得住。
08
质量指标
写得对，比写得快更重要
AI Coding 必须追求“写得对、测得住”。银行研发关注的不是代码产生速度，而是代码进入系统后的质量稳定性。
质量指标可以分为几类。
第一类是测试覆盖指标，比如单测覆盖率、接口测试覆盖率、回归测试覆盖率、核心路径覆盖率、边界条件覆盖率、AI 生成测试案例采纳率、AI 生成测试案例有效率。AI Coding 只生成代码，没有同步提升测试覆盖，风险会向后传导。AI 能帮助补齐单测、识别边界、生成回归案例，质量出口才会变强。
第二类是缺陷发现指标，比如代码评审检出率、测试缺陷检出率、设计阶段问题检出率、AI 参与复核检出率、AI 辅助测试发现缺陷数、AI 生成代码缺陷密度。这里特别要注意 AI 生成代码缺陷密度，也就是每千行 AI 参与代码中出现多少缺陷。这个指标能判断 AI 是在降低缺陷，还是制造新的隐性问题。
第三类是返工指标，比如 AI 代码人工修改比例、AI 生成结果被废弃比例、AI 生成代码后续修复次数、需求返工率、设计返工率、测试返工率。很多时候，AI 看似提高了编码速度，但后续返工增加，整体效率未必提高。
第四类是可维护性指标，比如圈复杂度变化、重复代码变化、规范违规数、技术债新增量、代码可读性评分、重构建议采纳后缺陷变化。AI Coding 最容易被低估的风险，是生成大量“能跑但不好维护”的代码。银行系统生命周期长，短期快不等于长期好。
还有一类非常值得管理层重视：设计阶段指标。大型银行的研发质量问题，很多并不是代码阶段才出现，而是在需求理解、概要设计、接口设计、数据设计、权限设计阶段就埋下了隐患。设计阶段问题检出数、设计复核检出率、需求缺陷前移率、接口影响分析命中率，可以帮助 CIO 判断 AI 是否把风险提前暴露出来。
对复杂任务，还可以增加计划质量指标。AI 不宜直接进入代码修改，应先生成可 review 的实施计划。计划是否能准确识别影响文件、接口依赖、测试范围、安全风险和回退方案，本身就应该成为指标。计划通过率越高，说明 AI 对代码库和工程上下文理解越稳；计划反复被退回，则说明上下文、知识库或任务拆解能力还不够。
质量指标要回答的问题很朴素：AI 参与以后，研发质量有没有更稳定，代码量之外的缺陷、返工、技术债有没有下降。
09
安全指标
AI 必须进入门禁和审计体系
安全指标不是安全部门自己的事情，它决定 AI Coding 能不能进入生产级研发体系。
安全指标至少有五类。
第一类是安全问题前移指标。比如编码阶段安全问题发现率、提交前风险拦截率、AI 生成代码安全问题占比、开发阶段修复率。这类指标回答的是：安全问题有没有在更早阶段被发现。
第二类是安全门禁指标。比如高危漏洞阻断数、敏感信息泄露拦截数、开源风险阻断数、禁止依赖引入次数、投产前未关闭安全问题数量。这类指标回答的是：关键安全闸门有没有守住。
第三类是 AI 特有安全指标。比如 AI 生成代码安全问题密度、AI 修复建议复核通过率、Agent 越权动作拦截率、模型上下文脱敏合规率、AI 生成依赖开源合规通过率。这类指标回答的是：AI 本身有没有被安全体系管住。
第四类是安全修复回路指标。比如漏洞平均修复时长、修复建议采纳率、自动修复成功率、复核通过率、同类问题复发率。这类指标回答的是：安全问题有没有更快处理完，并且减少重复发生。
第五类是生产安全指标。比如生产安全事件数量、高风险变更拦截率、漏洞引发生产问题数量、安全事件复盘规则回流率。这类指标回答的是：安全治理有没有真正影响生产稳定性。
对 CIO 来说，AI Coding 的安全指标不能只看“扫出了多少漏洞”。更关键的是：哪些风险被提前拦住了，哪些安全经验回流成了规则，哪些 AI 行为被有效管住了。
10
交付指标
投产窗口前暴露问题
才是真改善
智能研发最终要影响交付。AI Coding 再热闹，如果只是开发环节的局部改进，对管理层的意义仍然有限。
交付指标首先要看周期，比如需求到开发完成的周期、开发完成到测试通过的周期、测试通过到交付完成的周期、版本准备时间、投产材料准备时间、流水线失败修复时间、从缺陷发现到修复合并的周期。这些指标能回答 AI 是否缩短了研发节拍。
金融机构还要看风险是否前移。比如持续集成问题定位准确率、版本风险提前识别数、环境差异提前识别率、投产材料一致性校验通过率、投产前风险清单命中率、回退方案完整率、上线后验证清单执行率。这些指标能回答 AI 是否帮助交付团队更早发现问题。
这里有一个很关键的管理指标：版本问题提前发现数。对开发中心负责人来说，交付指标里最有价值的，不是投产材料自动生成了多少，而是版本问题有没有更早被发现，环境差异、依赖冲突、脚本遗漏、接口影响有没有在投产窗口前暴露出来。
还要看交付结果，比如上线成功率、投产问题数量、版本回滚率、上线后缺陷数、紧急修复次数、灰度验证通过率。AI Coding 如果缩短了开发时间，却提高了上线后问题数量，管理层不能把它当成成功。
一个比较适合 CIO 的综合指标是：
AI 参与版本健康度 = AI 代码比例 + 测试通过率 + 安全通过率 + 投产成功率 + 上线后问题下降率。
这个指标不是简单公式，而是一种管理思路：AI 参与越深，越要看版本整体是否健康。单看 AI 比例，很容易把风险误当成进步。
11
运维指标
生产稳定性会检验前面所有指标
AI Coding 最终要接受生产环境的检验。生产不稳，前面所有效率指标都会打折扣。
运维指标要看几个层面。
第一，故障发现和定位指标，比如告警降噪率、故障定位准确率、根因分析耗时、历史案例命中率、运维智能体建议采纳率。它们回答的是：AI 是否帮助运维人员更快找到问题。
第二，恢复效率指标，比如 MTTR 下降率、故障恢复时间、应急处置建议采纳率、回滚决策耗时、故障影响面收敛时间。它们回答的是：AI 是否帮助生产系统更快恢复。
第三，变更关联指标，比如故障与近期变更自动关联准确率、上线版本引发故障比例、AI 参与代码引发故障比例、变更风险提前识别率。它们回答的是：AI 参与研发后，生产变更风险有没有得到控制。
第四，复盘回流指标，比如故障复盘自动生成率、复盘知识采纳率、故障知识回流率、同类故障复发率。它们回答的是：生产问题有没有成为下一次研发的知识资产。
银行 CIO 最终要看的，不是“AI 运维回答了多少问题”，而是故障是不是更少了，定位是不是更快了，恢复是不是更稳了，同类问题是不是更少复发了。
12
知识指标
AI 写代码时
是否带着本行经验
智能研发的护城河是知识工程。到了指标体系里，就必须回答一个问题：知识工程有没有真的让 AI 更懂本行研发现场。
知识指标可以分几类。
第一类是知识覆盖指标，比如 RepoWiki 覆盖率、核心应用知识覆盖率、接口文档覆盖率、公共组件知识覆盖率、规约库覆盖率、历史故障案例覆盖率、测试案例知识覆盖率、投产知识覆盖率。这些指标回答的是：知识资产有没有被盘出来。
第二类是知识质量指标，比如知识更新及时率、知识重复率、知识过期率、人工审核通过率、知识可信度评分、知识引用准确率。这些指标回答的是：知识是否可靠。
第三类是知识调用指标，比如知识命中率、有效引用率、AI 回答中知识引用占比、代码生成时规约引用率、测试生成时历史缺陷引用率、运维分析时历史故障命中率。这些指标回答的是：知识有没有被 AI 真正用起来。
第四类是知识回流指标，比如代码评审意见回流率、测试缺陷回流率、投产问题回流率、生产故障回流率、安全事件回流率、规则更新回路完成率。这些指标回答的是：研发过程有没有反哺组织记忆。
知识指标还要补一层产品化口径。对 AI IDE 和编程智能体来说，知识指标不能只看知识库文档数量，还要看项目上下文有没有被结构化。核心项目是否建立了代码结构、依赖关系、接口关系和关键模块视图；AI 执行任务时是否能复用这些上下文；重复扫描、重复检索、重复喂上下文的比例有没有下降。项目上下文覆盖率、上下文复用率、Token 节省率，应该成为知识和成本指标的一部分。
企业知识库和规则库也不能只看建设规模。AI 生成代码时是否引用了企业规约，生成测试时是否引用了历史缺陷，生成修复方案时是否引用了安全规则，调用自定义指令和 Skills 后是否减少了人工修正，这些指标比“知识库有多少文档”更能说明 AI 是否真正理解本行研发现场。
智能研发的知识资产也不只是 Wiki 和向量库，还包括高质量金融代码语料、应用文档、接口规范、测试案例、历史缺陷、版本风险点、代码评审意见、指导手册和种子用户实践。CIO 要看的不是知识库有多大，而是这些资产有没有被 AI 在真实任务中正确调用，并在评审、测试、交付和运维中形成反馈。
CIO 重点要看一个指标：
有效知识命中率 = AI 在真实研发任务中引用正确知识并被人工确认有效的次数 / AI 触发知识检索的总次数。
这个指标比“知识库有多少文档”更重要。未来智能研发的核心，不是谁存了更多知识，而是谁能在正确任务、正确时刻，给 AI 注入正确知识。
13
组织指标：人有没有升级
AI Coding 不只改变工具，也会改变人。指标体系如果只看代码和流程，不看人的变化，就会漏掉智能研发最关键的组织问题。
组织指标首先要看使用分层。哪些人是高频有效使用者，哪些人只是偶尔使用，哪些人不用，哪些人用得多但产出低，哪些人用得少但价值高。不能简单把高频使用当成优秀，不同岗位任务不同，关键要看使用质量。
其次，要看岗位能力变化。开发人员是否从纯编码转向任务拆解、代码审查、系统集成和风险判断；测试人员是否从执行案例转向测试设计和质量出口；交付人员是否从材料整理转向版本风险管理；运维人员是否从日志排查转向故障推理和知识沉淀；安全人员是否从事后扫描转向规则建设和门禁运营。
第三，要看专家经验是否被放大。AI Coding 的一个重要价值，是让高手的经验通过规约、模板、Skills、知识库和审查机制扩散到更多团队。如果专家经验仍然停留在少数人脑子里，AI 只是个人工具；如果专家经验开始变成组织资产，AI 才真正进入组织能力建设。
第四，要看培训和认证效果。参加过 AI Coding 培训的人，和没有参加过的人，在采纳率、入库率、缺陷率、安全问题密度、交付质量上是否有差异。培训不能只看人数和课时，要看行为改变和结果改变。
还要看人工接管率。AI 执行任务时，哪些环节必须由开发人员接手，哪些环节需要架构师确认，哪些环节触发安全或交付人员介入。人工接管率过高，说明 Agent 还没有真正融入工程流程；人工接管率过低，也要结合安全拦截率和缺陷密度一起看，避免把必要的人工责任弱化掉。
组织运营指标也要进入仪表盘。种子用户数量、实战培训后有效采纳率提升、周活跃有效用户占比、岗位智能体覆盖率、优秀实践复用次数，这些指标能说明智能研发有没有从少数人尝鲜，走向组织级运营。
组织指标要回答的问题很清楚：AI 有没有让人从执行者升级为责任承接者。AI 写得越多，人如果只是忙着补救、返工、救火，那就说明复杂度被推给了后链路；AI 如果让人有更多时间做设计、审查、判断和沉淀，组织能力才开始升级。
14
组织结构指标
自有人员、分级外包
与 AI 的组合效率
中国金融机构的研发组织，长期以来不是单纯的自有研发体系，而是由自有开发人员、不同级别外包开发人员、测试外包人员、驻场支持人员共同构成。很多银行内部，自有人员与外包人员接近 1:1，在部分项目上外包比例更高。外包人员还会分为初级、中级、高级，测试外包也有功能测试、自动化测试、性能测试、回归测试、现场测试支持等不同类型。AI Coding 进入以后，真正要重新计量的，不是某一个开发人员的效率，而是“自有人员、分级外包、测试外包、AI 工具链”组成的新型研发单元。
过去银行管理外包，主要看人头、工时、交付数量、缺陷率和项目验收。AI 介入以后，这些指标不够用了。初级外包借助 AI 可能写出更多代码，但这些代码是否符合规约、是否能通过测试和安全门禁、是否增加自有人员 review 压力，需要单独计量。中级外包借助 AI 可能承担更多模块开发，但要看一次通过率和返工率。高级外包借助 AI 可能承担方案设计、复杂改造和技术支撑，也要看其经验是否沉淀为银行自己的知识资产。测试外包借助 AI 可以生成更多测试用例和脚本，但关键指标不是用例数量，而是缺陷检出率、有效用例率和生产缺陷漏出率。
这里至少要设置四类指标。
第一类是外包分级效率指标。初级、中级、高级外包不能放在一个池子里看。初级外包应重点看 AI 辅助后的任务完成率、返工率、规约违规率、人工 review 耗时；中级外包应重点看模块交付一次通过率、AI 合规入库率、缺陷密度、单测补齐率；高级外包应重点看复杂任务承接能力、方案质量、关键问题解决率、知识沉淀贡献。这样才能判断 AI 到底是在提升外包交付能力，还是在放大不同层级人员之间的质量差异。
第二类是测试外包质量指标。测试外包人员使用 AI 后，不能只看生成了多少测试用例，而要看有效测试用例率、缺陷检出密度、核心路径覆盖率、边界场景覆盖率、自动化脚本通过率、回归测试复用率、生产缺陷漏出率。大量测试工作过去靠人海战术，AI 进入以后，测试外包的价值应从“执行更多案例”转向“更早发现高价值缺陷”。
第三类是自有人员审查负担指标。AI 和外包如果只提高了产出速度，却让自有人员花更多时间做 review、返工、解释问题和兜底责任，对银行并不是真正提效。可以增加一个指标：
自有人员审查负担率 = 自有人员用于复核 AI / 外包产出的时间 / 自有人员总研发管理时间。
这个指标很有现场感。外包人员和 AI 产出越多，自有人员的审查压力可能越大。成熟的智能研发体系，应该让自有人员把更多时间放在架构、设计、风险判断、关键问题处理和知识沉淀上，而不是被大量低质量代码和测试结果拖住。
第四类是分级人力成本与交付质量指标。不同级别外包价格不同，AI 介入后，要看单位需求综合成本，而不是单纯看某类人力便宜。可以设置：
单位需求综合成本 = 自有人员投入成本 + 外包人员投入成本 + AI 资源成本 + review 成本 + 返工成本 + 缺陷修复成本。
这个指标比“人天单价”更真实。低级别外包单价低，但返工、缺陷、安全问题和审查成本高，综合成本未必低；高级外包单价高，但复杂任务一次通过率高、返工少、知识沉淀好，综合成本可能更优。AI 的价值，也要放在这张总账里看。
AI Coding 进入银行以后，外包管理要从“按人头买产能”，转向“按角色、级别、质量、成本和知识沉淀管理交付结果”。自有人员、初级外包、中级外包、高级外包、测试外包和 AI 工具链，需要放在同一张管理仪表盘里看。这样 CIO 才能判断，AI 到底是在降低综合交付成本，还是把更多隐性成本推到了自有团队、测试团队和生产环境。
15
成本指标
单位价值成本有没有下降
CIO 非常重视看成本。智能研发不能只谈价值，也要看投入产出。AI Coding 如果小范围试点很好，一扩大就算力成本暴涨、响应延迟变长、上下文费用过高、运维压力变大，就很难规模化。
成本指标至少包括模型调用成本、Token 消耗、算力使用率、平均响应时间、任务平均完成成本、不同模型路由成本、缓存命中率、知识检索成本、Agent 执行成本、失败任务重试成本。
其中有几个指标特别重要。单任务成本，要看生成一个单测、修复一个漏洞、完成一次交付分析、定位一次故障平均花多少钱。模型路由效率，要看简单任务是否错用了昂贵模型，复杂任务是否用了能力不足的模型。Token 有效率，要看知识切片是否精准，是否把大量无效上下文塞进模型。
成本指标还要看部署形态。API 调用启动快，但要持续关注调用成本、数据出域、审计留痕、供应商依赖和响应稳定性；私有化部署前期投入更高，但在数据安全、权限控制、审计追溯和高频调用场景中，更容易形成长期可控的成本结构。大型银行通常不会只用一种形态，而会根据任务敏感度、调用频率、上下文长度和响应时延，形成混合模型路由。低风险、低敏感任务可以走轻量模型，高敏感、高频、高审计要求的任务，应进入更受控的内部环境。
还要看多模型路由准确率。代码补全、注释生成、单测生成、代码解释、缺陷修复、安全修复、复杂重构、生产故障分析，对模型能力、上下文长度、响应时延和数据安全要求不同。CIO 要看的不是“用了哪个模型”，而是任务是否被路由到合适的模型和环境。
模型路由准确率 = 按任务风险、复杂度、成本、时延要求匹配到合适模型的任务数 / 总任务数。
成本指标不能只看模型调用成本，还要看需求交付成本。一个需求从开发到测试、从测试到投产、从投产到稳定运行，AI 介入以后人力成本、等待成本、返工成本和故障恢复成本有没有下降，才是 CIO 更关心的投入产出。
CIO 要看一个核心问题：AI Coding 的单位价值成本是否持续下降。随着使用规模扩大，单任务成本下降、响应更稳定、有效产出增加，说明体系在成熟；越用越贵、越用越慢、越用越乱，说明智能研发的工程底座还没有搭好。
16
防止指标变成新的形式主义
银行体系做指标，很容易做得非常完整，但完整不等于有效。智能研发指标体系也有这个风险：指标越来越多，报表越来越厚，会议越来越频繁，一线却没有真正改善。
要避免形式主义，必须坚持三个原则。
第一，指标必须能驱动行动。一个指标出来以后，要能回答“接下来该改什么”。某个指标连续几个月没有变化，团队也没有根据它调整工具、流程、培训、模型、知识库或门禁规则，这个指标就应该从核心仪表盘上降级，甚至移除。
第二，指标必须能追溯来源。AI 入库率怎么算，AI 代码如何标记，哪些代码算 AI 参与，哪些算人工重写，安全问题如何归因，知识命中如何确认，这些口径必须统一。否则不同团队各算各的，最后指标失真。
第三，指标必须能防止行为扭曲。只考核生成代码量，团队可能会鼓励多生成；只考核采纳率，开发人员可能会降低审查标准；只考核活跃度，大家可能为了完成指标频繁调用低价值任务。智能研发指标必须设计得足够平衡，让团队追求真实价值，而不是追求好看数据。
还有两点很关键。
第一，数据最好从工具链自动产生。所有 AI 参与的代码、测试、文档、修复建议和交付分析，都应该在工具链中留下 Metadata。哪些代码由 AI 生成，哪些代码由 AI 修改，哪些建议被人工采纳，哪些建议被否决，哪些内容通过了测试和门禁，都要能从 IDE、Git、PR、流水线和审计记录中自动追溯。指标最好是系统跑出来的，不要靠团队手工填出来。
第二，指标口径要跨入口统一。开发人员可能在 IDE 插件里补代码，在 CLI 里委派任务，在代码评审里调用智能评审，在企业知识库里问答，在流水线里触发自动修复。如果这些入口各算各的，管理层会看到一堆割裂数字。智能研发指标要能跨 IDE、CLI、PR、流水线、知识库和 Agent 平台统一归集，避免重复计算和遗漏计算。
好指标的价值，在于帮助组织看清问题、调整行为、持续改进，而不是让团队围着数字转。
17
失败原因分布
比失败率更有价值
产品迭代和研发管理最需要失败分类。AI 任务失败以后，管理层不能只看到“失败了”，还要知道失败在哪里。
常见失败原因包括：上下文不足，知识命中错误，工具调用失败，权限被拦截，测试未通过，安全扫描未通过，人工 review 否决，性能或兼容性问题，业务逻辑理解错误，生产运行风险过高。
失败原因分清楚以后，产品和研发管理才能对症调整。上下文不足，就要补项目知识图谱和 RepoWiki；知识命中错误，就要重新做知识切片和审核；工具调用失败，就要优化 MCP 工具、权限和执行环境；测试失败多，就要加强计划生成和测试策略；安全扫描失败多，就要把安全规约前置到生成阶段；人工 review 否决多，就要看任务拆解、代码风格、规约匹配和开发者信任。
失败分类比失败率更有价值。失败率告诉管理者出了多少问题，失败原因分布告诉管理者下一步该改哪里。
18
总结
从工具接入走向生产级能力
AI Coding 进入银行研发以后，最容易出现两种极端。一种是过度乐观，看到生成代码多、使用人数多，就认为智能研发成功了；另一种是过度谨慎，看到 AI 有错误、有风险，就不敢让它进入更深流程。成熟的做法，是用指标体系把它管起来。
指标体系不是为了做报表，而是为了让 CIO 看清三件事：AI 到底有没有提高研发效率，AI 到底有没有改善工程质量，AI 到底有没有降低生产风险。
从代码采纳率到 AI 合规入库率，从单测覆盖率到安全问题密度，从知识命中率到生产事故下降率，从工具调用成功率到单位价值成本，再到自有人员、分级外包、测试外包与 AI 的组合效率，这些指标共同构成智能研发的管理仪表盘。没有这套仪表盘，AI Coding 很容易靠热情推进、靠感觉判断、靠个别案例证明；有了这套仪表盘，银行才有可能把 AI Coding 从试点工具，推进到生产级研发能力。
AI Coding 的第九讲，希望从“会不会写代码”，转向“能不能被稳定管理”。建立一套可衡量、可追溯、可改进的指标体系之后，AI Coding 才能从个人助手升级为生产级研发能力。
