拒绝“感觉有效”：用数据证明 AI Coding 的真实团队价值【天猫AI Coding实践系列】

链路指标：定位过程瓶颈

核心洞察：知识库被频繁召回但采纳率低？这条知识可能需要优化。四象限分析让我们从「有没有用」进化到「哪条好用、哪条该淘汰」。

离线评测建立了能力基线，但生产环境中的实际表现需要在线数据来验证。链路指标通过埋点采集真实用户的使用行为，追踪 AI Coding 各环节的转化情况。

▐  核心问题：上下文有没有起作用

链路指标要回答的问题很简单：我们费心准备的上下文（知识库、组件文档、SPEC 规范），在 AI 生成代码的过程中，有没有按预期起到正向作用？

如果知识库被频繁调用但最终代码采纳率很低，说明知识库内容可能有问题；如果 Agent 根本没去查知识库就开始写代码，说明 Prompt 引导有问题。链路指标就是要把这些「中间环节」的问题暴露出来。

• 为什么不追踪单条数据的"采纳"

在设计链路指标时，我们最初考虑了一个理想化方案：追踪每条知识/组件是否被 Agent 采纳。经过深入讨论，发现这个方案存在多个工程化难题：

追踪单条知识的"采纳"存在工程难题：知识库返回的是"软内容"，Agent 不一定显式标注引用了哪条；强制标注会影响 Agent 自然输出；也没有对照组做 A/B 测试。

解决思路：既然追踪"采纳"不可行，我们采用关联分析——分析使用了某能力的会话，其采纳率表现如何。具体方法见 4.3 节。

• 整体转化率：调用→命中→采纳

上下文的价值可以用一个简单的漏斗来衡量：

每一级对应不同的问题：

• 调用率低 → Agent 不知道要查资料，Prompt 引导有问题

• 命中率低 → 知识库内容覆盖不足，或者索引质量差

• 采纳率低 → 查到了但不是 Agent 需要的，召回精度有问题

• 定位具体哪条数据有问题

整体转化率只能告诉你"知识库效果不好"，但无法定位具体哪条知识有问题。我们按「使用频率」和「关联采纳率」两个维度，把每条数据分布到散点图上：

高频低效是重点：被频繁召回但采纳率低，优化后影响面最大。阈值用动态中位数，确保随着整体质量提升，仍能识别出相对最需要关注的条目。

▐  各类上下文的效果追踪

AI 生成代码的质量高度依赖上下文供给。我们从四个视角追踪上下文的效果：SPEC 需求规格关注需求描述是否足够清晰，经验沉淀知识库关注踩坑经验有没有被复用，物料组件知识库关注组件用法查到了没有，Skills 工作流关注最佳实践有没有被触发。

• SPEC：技术方案模板规范

SPEC（技术规格说明）是我们预置的技术方案模板。不同类型的需求使用不同的模板：列表页模板适用于标准 CRUD 列表，表单模板适用于配置编辑页，多场景模板适用于复杂业务流程，基础模板适用于通用简单页面。模板的结构化程度直接影响 AI 生成代码的准确度——结构化越强，AI 理解需求越准确。

我们通过最终采纳率反推模板质量：追踪每个模板关联的代码采纳率，识别哪些模板效果好、哪些需要优化。

图中展示了各 SPEC 模板的使用频率和关联采纳率。高频高效的模板（如多场景模板）说明模板设计合理，可以作为标杆推广；高频低效的模板需要针对性优化。

以「基础模板」为例，最初只包含简单的功能描述框架，采纳率明显偏低。分析发现 AI 经常遗漏接口字段映射和状态管理逻辑。我们补充了「数据流转说明」和「状态变更规则」两个必填项后，采纳率显著提升。这说明模板的结构化约束越强，AI 的输出质量越稳定。

• 经验沉淀：团队经验

经验沉淀知识库存储团队积累的踩坑经验、最佳实践、业务规则等——这些是模型无法从公开资料获取的业务独特知识。按内容类型可分为三类：

• 踩坑记录：具体的问题和解决方案（如 tsconfig 配置问题、接口兼容性问题）

• 编码规范：团队约定的代码风格和模式（如状态管理方式、错误处理规范）

• 业务规则：领域特定的逻辑约束（如价格计算规则、权限校验逻辑）

我们通过关联分析评估知识的有效性：命中某条知识后，该会话的代码采纳率如何？用 4.1.3 介绍的散点图分析定位问题。

判断知识质量的核心维度是可操作性——AI 看了能直接用，而不是"知道有这回事但不知道怎么做"。例如：一条「tsconfig 配置」知识召回率高但采纳率偏低。分析发现原文只说「配置 baseUrl 可简化导入』，没说明项目的具体配置方式。补充 paths 映射规则和示例代码后，采纳率显著提升。

零结果查询是知识库缺口的直接信号。我们每周汇总 Top 20 零结果查询，按「出现频次 × 业务影响」优先级排序，作为知识补充的输入——用户在问什么、我们没覆盖什么，一目了然。

• 物料组件：技术文档

物料组件知识库通过 MCP 工具提供三类能力：

• 组件查询：按名称或功能描述检索组件

• API 文档：组件的 Props、事件、插槽说明

• 使用示例：典型场景的代码片段

使用率反映 Agent 是否"知道要查组件文档"。使用率低需要区分两种情况：

• Agent 没调用 MCP：检查 System Prompt 的工具使用引导，或者在离线评测中加入"必须查询组件文档"的行为分要求

• 调用了但命中率低：检查组件命名是否与 Agent 理解一致（例如「日期选择器」在组件库中叫 DatePicker 还是 Calendar），或者组件文档覆盖不足

当前组件库文档的主要缺口在业务组件和近期新增组件。我们定期扫描"调用了 MCP 但返回空结果"的查询日志，作为文档补充的优先级输入。

• Skills：标准流程

Skills 是预置的工作流能力，封装了标准化任务的最佳实践。

当前追踪使用率和采纳率。数据显示，使用 Skills 的会话平均采纳率明显高于普通会话，说明标准化工作流确实能提升生成质量——Skills 本质上是把"专家经验"固化成可复用的流程。

更理想的指标是触发率（符合条件的场景中 Skills 是否被触发）和完成率（触发后是否成功完成）。触发率低说明场景识别不足，完成率低说明工作流设计有问题。这需要单独定制埋点，计划下一版本实现。

▐  链路指标的运营实践

链路指标的核心运营场景是定位上下文供给的薄弱环节。

每周拉取各能力的三级漏斗数据（调用率→命中率→采纳率），重点关注两类异常：

• 调用率低：说明 Agent 不知道要用这个能力。检查 System Prompt 中的工具使用引导是否清晰，或者该能力的触发条件是否过于苛刻。

• 命中率高但采纳率低：说明召回了但不好用。用四象限分析定位具体是哪些知识条目拖了后腿，优先优化"高频低效"象限的内容。

零结果查询的 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 生成代码总行数

我们的数据：下图展示了采纳率分析面板。上半部分是汇总统计（任务数、整体采纳率、代码行数），下半部分是任务明细列表，可以下钻到每个任务查看 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');   // 来自第1次 AI  + function test() {}       // 来自第2次 AI  + 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 的 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 最大的价值。