综合得分 = 结果分 × 0.75 + 行为分 × 0.25。
关于权重的几点说明：
首先，这个权重是我们在特定业务场景下通过实验校准得出的，不是放之四海皆准的「最佳配置」。不同团队应该根据自己的业务特点调整——如果你的场景更看重「稳定可复现」（比如金融、医疗），行为分权重可以提高到 30-40%；如果场景更看重「快速出结果」且容错空间大，可以降到 15-20%。
其次，为什么我们选择 25% 而不是更高或更低？我们测试了 80/20、70/30、75/25 三种配置，观察了两个指标：区分度（能否有效区分「碰巧正确」和「稳定正确」的 Agent）和一致性（多次评测结果是否稳定）。75/25 在我们的数据集上达到了最佳平衡——行为分太低则「碰巧正确」的用例无法被识别，太高则会过度惩罚「结果正确但路径不同」的合理实现。
最后，行为分的核心价值不在于「惩罚』，而在于预测稳定性。一个不查资料却答对的 Agent，在简单场景下可能表现良好，但复杂场景下出错概率会显著上升。行为分本质上是对「工作方式健康度」的量化评估——它不是要说「不查资料就是错」，而是要说「查资料的 Agent 在复杂场景下更可靠」。这个逻辑类似于招聘时看候选人的解题思路，而不只是看最终答案。
▐ 评测实践与调优应用
有了复杂度矩阵和量化评分模型，接下来展示离线评测的实际应用。
当前数据集包含 60 个用例，覆盖 9 个象限的典型类型，每个用例都经过人工审核，质量优先于数量。
可信度保障：人工抽检（LLM 评分与人工复核一致性 > 90%）、多模型交叉验证、版本基线对比、轨迹存档复盘。
评测结果按复杂度矩阵聚合，形成能力热力图：
热力图揭示 AI 的能力边界：绿色推荐区得分 85+ 分，适合 AI 独立完成；黄色调试区需要多轮调整；红色挑战区超出 AI 有效辅助边界。
调优案例：早期 L2-C2 象限（有联动 + 组件文档不完善）只有 55 分。分析失败用例发现问题集中在"表单联动"类需求。针对性优化 SPEC 模板（增加联动规则表、联动流程图）+ Prompt 优化 + 知识库补充后，L2-C2 从 55 分提升到 70 分。
这就是离线评测的典型闭环：热力图定位短板 → 分析失败用例 → 针对性调优 → 评测验证效果。
但离线评测有天然局限：评测环境不等于生产环境。所以还需要在线数据验证实际表现——这就是下一章的链路指标。
链路指标：定位过程瓶颈
核心洞察：知识库被频繁召回但采纳率低？这条知识可能需要优化。四象限分析让我们从「有没有用」进化到「哪条好用、哪条该淘汰」。
离线评测建立了能力基线，但生产环境中的实际表现需要在线数据来验证。链路指标通过埋点采集真实用户的使用行为，追踪 AI Coding 各环节的转化情况。
▐ 核心问题：上下文有没有起作用
链路指标要回答的问题很简单：我们费心准备的上下文（知识库、组件文档、SPEC 规范），在 AI 生成代码的过程中，有没有按预期起到正向作用？
如果知识库被频繁调用但最终代码采纳率很低，说明知识库内容可能有问题；如果 Agent 根本没去查知识库就开始写代码，说明 Prompt 引导有问题。链路指标就是要把这些「中间环节」的问题暴露出来。
在设计链路指标时，我们最初考虑了一个理想化方案：追踪每条知识/组件是否被 Agent 采纳。经过深入讨论，发现这个方案存在多个工程化难题：
追踪单条知识的"采纳"存在工程难题：知识库返回的是"软内容"，Agent 不一定显式标注引用了哪条；强制标注会影响 Agent 自然输出；也没有对照组做 A/B 测试。
解决思路：既然追踪"采纳"不可行，我们采用关联分析——分析使用了某能力的会话，其采纳率表现如何。具体方法见 4.3 节。
上下文的价值可以用一个简单的漏斗来衡量：
每一级对应不同的问题：
整体转化率只能告诉你"知识库效果不好"，但无法定位具体哪条知识有问题。我们按「使用频率」和「关联采纳率」两个维度，把每条数据分布到散点图上：
高频低效是重点：被频繁召回但采纳率低，优化后影响面最大。阈值用动态中位数，确保随着整体质量提升，仍能识别出相对最需要关注的条目。
▐ 各类上下文的效果追踪
AI 生成代码的质量高度依赖上下文供给。我们从四个视角追踪上下文的效果：SPEC 需求规格关注需求描述是否足够清晰，经验沉淀知识库关注踩坑经验有没有被复用，物料组件知识库关注组件用法查到了没有，Skills 工作流关注最佳实践有没有被触发。
SPEC（技术规格说明）是我们预置的技术方案模板。不同类型的需求使用不同的模板：列表页模板适用于标准 CRUD 列表，表单模板适用于配置编辑页，多场景模板适用于复杂业务流程，基础模板适用于通用简单页面。模板的结构化程度直接影响 AI 生成代码的准确度——结构化越强，AI 理解需求越准确。
我们通过最终采纳率反推模板质量：追踪每个模板关联的代码采纳率，识别哪些模板效果好、哪些需要优化。
图中展示了各 SPEC 模板的使用频率和关联采纳率。高频高效的模板（如多场景模板）说明模板设计合理，可以作为标杆推广；高频低效的模板需要针对性优化。
以「基础模板」为例，最初只包含简单的功能描述框架，采纳率明显偏低。分析发现 AI 经常遗漏接口字段映射和状态管理逻辑。我们补充了「数据流转说明」和「状态变更规则」两个必填项后，采纳率显著提升。这说明模板的结构化约束越强，AI 的输出质量越稳定。
经验沉淀知识库存储团队积累的踩坑经验、最佳实践、业务规则等——这些是模型无法从公开资料获取的业务独特知识。按内容类型可分为三类：
踩坑记录：具体的问题和解决方案（如 tsconfig 配置问题、接口兼容性问题）
编码规范：团队约定的代码风格和模式（如状态管理方式、错误处理规范）
业务规则：领域特定的逻辑约束（如价格计算规则、权限校验逻辑）
我们通过关联分析评估知识的有效性：命中某条知识后，该会话的代码采纳率如何？用 4.1.3 介绍的散点图分析定位问题。
判断知识质量的核心维度是可操作性——AI 看了能直接用，而不是"知道有这回事但不知道怎么做"。例如：一条「tsconfig 配置」知识召回率高但采纳率偏低。分析发现原文只说「配置 baseUrl 可简化导入』，没说明项目的具体配置方式。补充 paths 映射规则和示例代码后，采纳率显著提升。
零结果查询是知识库缺口的直接信号。我们每周汇总 Top 20 零结果查询，按「出现频次 × 业务影响」优先级排序，作为知识补充的输入——用户在问什么、我们没覆盖什么，一目了然。
物料组件知识库通过 MCP 工具提供三类能力：
组件查询：按名称或功能描述检索组件
API 文档：组件的 Props、事件、插槽说明
使用示例：典型场景的代码片段
使用率反映 Agent 是否"知道要查组件文档"。使用率低需要区分两种情况：
当前组件库文档的主要缺口在业务组件和近期新增组件。我们定期扫描"调用了 MCP 但返回空结果"的查询日志，作为文档补充的优先级输入。
Skills 是预置的工作流能力，封装了标准化任务的最佳实践。
当前追踪使用率和采纳率。数据显示，使用 Skills 的会话平均采纳率明显高于普通会话，说明标准化工作流确实能提升生成质量——Skills 本质上是把"专家经验"固化成可复用的流程。
更理想的指标是触发率（符合条件的场景中 Skills 是否被触发）和完成率（触发后是否成功完成）。触发率低说明场景识别不足，完成率低说明工作流设计有问题。这需要单独定制埋点，计划下一版本实现。
▐ 链路指标的运营实践
链路指标的核心运营场景是定位上下文供给的薄弱环节。
每周拉取各能力的三级漏斗数据（调用率→命中率→采纳率），重点关注两类异常：
零结果查询的 Top 20 列表是知识库扩展的直接输入——用户在问什么、我们没覆盖什么，一目了然。
链路指标告诉我们"各环节有没有被用好"，但老板最关心的问题是"最终效果怎么样"。下一章我们将介绍结果指标——用需求覆盖率和代码采纳率来直接回答这个问题。
结果指标：验证调优效果
核心洞察：「接受补全」不等于「代码有用」——我们把追踪终点从 IDE 延伸到代码合并，用「最终上线的代码中有多少来自 AI」来衡量真实价值。
链路指标告诉我们"各环节有没有被用好"，但老板最关心的是"最终效果怎么样"。结果指标直接回答这个问题——需要将 AI 生成任务与业务需求进行跨系统关联。
▐ 数据关联基础
结果指标的计算依赖于跨系统数据关联：将 AI 生成任务与业务需求进行匹配。
核心设计是以 ( repo_project, branch ) 作为关联键，将 AI 编码平台的任务数据与内部迭代/需求系统打通。数据流程：AI 出码完成后实时上报 Diff → 发布记录 T+1 同步 → 定时任务匹配计算采纳率。
有了这套关联机制，就可以计算各项结果指标了。
▐ 需求覆盖率
定义：AI 参与的需求占总需求的比例。
需求覆盖率 = 关联 AI 任务的需求数 / 总需求数
我们的数据：下图展示了各业务域的需求覆盖情况，按业务域聚合显示总需求数、AI 参与需求数和覆盖率。
支持下钻到具体需求列表，查看每个需求的上线状态、关联的 AI 任务实例、会话数和 Token 成本消耗：
为什么重要：覆盖率反映 AI 工具的渗透程度。如果只有 10% 的需求用了 AI，说明大多数场景还没被覆盖，可能是工具不好用、或者适用场景有限。
代码采纳率 = AI 生成代码被上线的行数 / AI 生成代码总行数
我们的数据：下图展示了采纳率分析面板。上半部分是汇总统计（任务数、整体采纳率、代码行数），下半部分是任务明细列表，可以下钻到每个任务查看 AI 生成代码与最终上线代码的 Diff 对比。
为什么重要：采纳率是 AI 产出质量的核心指标。生成了一堆代码但都被删掉重写，说明 AI 没帮上忙。
计算难点：AI 生成的代码和最终上线的代码存在格式差异（空格、引号、分号），直接比对会误判。我们采用规范化比对算法——先对两边代码做预处理（去除注释、合并空白、统一引号和分号风格），再进行逐行比对。这是纯工程化实现，不依赖 AI，计算速度在毫秒级。
Merge Commit 识别机制：用户的发布记录中保存的 repo_commit_id 通常是最后一次提交的 commit。要获取完整的代码变更，需要找到该 commit 之后的 Merge Commit——它包含了从功能分支合并到主分支的所有变更。系统通过 GitLab API 获取 commit 历史，定位用户的 commit 后，向后查找第一个标题包含"Merge commit"的提交。
多次出码场景处理：用户可能在同一分支多次使用 AI 生成代码。例如：
第1次出码（10:00）：+ console.log('step1');第2次出码（11:00）：+ function test() {}最终发布（14:00）： + console.log('step1'); + function test() {} + const x = 1;
计算采纳率时，系统会将同一 (repo_project, branch) 下的所有 AI Diff 记录合并后再与 Merge Commit Diff 比对，确保不遗漏任何一次出码的贡献。上例中：AI 新增行 2 行，CR 新增行 3 行，被采纳 2 行，采纳率 = 66.67%。
▐ Token 成本追踪
定义：单需求关联的 Token 消耗总量。
为什么重要：Token 成本是 AI Coding 的主要投入，追踪成本可以评估 AI 投入的 ROI，验证 Prompt 优化、知识库完善等运营策略的实际效果。
多维度聚合统计：基于统一网关的底层调用，我们实现了 Token 消耗的多维度聚合统计，支持从 Task、迭代、需求等层级查看成本分布：
聚合维度 |
数据来源 |
应用场景 |
Task 维度 |
单次 AI 对话的 Token 消耗 |
分析单次对话的效率 |
迭代维度 |
关联到该迭代的所有 Task Token 总和 |
评估迭代级的 AI 投入 |
需求维度 |
关联到该需求的所有 Task Token 总和 |
评估需求级的 AI 成本 |
聚合策略采用「允许重复计算」模式：每个迭代或需求独立聚合其关联 Task 的 Token 总和。由于存在多对多关系（一个 Task 可能关联多个需求），各维度的汇总值不等于实际总消耗，但这种设计更符合业务分析的需要——产品经理关心的是「这个需求花了多少 Token」，而不是「这个 Token 被几个需求共享」。
应用价值：
趋势分析：观察单需求成本是否呈下降趋势，验证运营策略效果；
异常识别：结合采纳率数据，识别「高消耗低采纳」的异常模式，针对性改进；
ROI 评估：计算 Token 成本与需求交付价值的比值，评估 AI 投入产出比。
下图展示了按需求维度聚合的 Token 消耗明细。每行代表一个需求，显示关联的仓库、需求描述、负责人和 Token 消耗量，支持按消耗量排序快速定位高成本需求。
▐ 其他辅助指标
除了核心的覆盖率、采纳率和 Token 成本，我们还追踪一些辅助指标：
交付效率：单需求平均交付时间，可通过迭代系统的时间戳粗略推算。由于影响因素较多（需求复杂度、开发者经验等），不作为核心追踪指标。
代码质量：上线后的 bug 率、返工率。全栈模式下，后端工程师完成前端需求后会进行完整的自测验证，质量通常优于前后端分离交付的模式。作为滞后指标，需要较长时间积累数据。
总结与展望
从"我觉得有效"到"数据证明有效"，是 AI Coding 从个人工具走向团队基础设施的关键一步。
做这套体系的过程中，有几个认知转变让我印象深刻：
从"证明有效"到"定位问题"。最初我们只想回答老板的问题："效果怎么样？"但做着做着发现，真正的价值不是那个最终的采纳率数字，而是当采纳率不理想时，能够快速定位是知识库没召回、是 Agent 没查资料、还是生成的代码本身有问题。能诊断，比能证明更重要。
从"评结果"到"评过程"。业界的评测基准几乎都只看最终代码对不对，但我们发现一个反直觉的现象：有些 Agent 代码写对了，但完全没查文档——这种"碰巧正确"比"稳定正确"更危险。所以我们的离线评测加入了行为分，不仅评代码，还评 Agent 有没有"查对资料"。
从"个人感知"到"团队共识"。个人用 AI 写代码，改了 Prompt 感觉顺畅一点，这种"感觉"无法在团队层面形成共识。但当你有了评测基线，"换个模型效果如何""加条知识提升多少"就变成了可讨论、可决策的问题。数据让团队能够对齐认知。
当然，这套体系还有明显的局限：LLM 评分存在主观性，数据集规模有限，行为追踪维度不够丰富。但我们相信方向是对的——未来会探索自动化用例生成、更丰富的链路指标、以及将这套评测方法开放为可复用的通用框架。
回到开头的问题：如何证明 AI Coding 的真实价值？
数据不会说谎。当你能用数据清晰地回答"效果到底怎么样"时，你就有了持续投入的底气，也有了推广复制的基础。
但这套度量体系真正揭示的，是一个更深层的认知：AI Coding 的本质不是"买个工具提效"，而是一场知识资产的治理革命。
当你开始追踪知识库的召回率和采纳率，你就开始认真对待每一条文档的质量；当你开始评估 SPEC 的转化效果，你就开始把需求规范当作可运营的资产；当你开始分析 Prompt 的行为得分，你就开始把最佳实践沉淀为可复用的团队能力。
文档、SPEC、Prompt——这些曾经散落在各处的"软资产"，在度量体系的照射下，都成为可度量、可迭代、可复用的团队资产。这才是 AI Coding 带来的真正变革：不是 AI 替代了谁，而是团队的知识终于有了积累和复利的可能。
度量不是为了考核工程师，而是为了赋能。通过这套体系，我们将工程师从重复劳动中解放出来的过程可视化了——这才是 AI Coding 最大的价值。
粤ICP备14082021号
免费POC，
零成本试错
