跳转至

高德 AI 资产度量与评价体系：三层评估模型 + 离线采集 + 人工反馈闭环

📊 Level ⭐⭐⭐ | 10.6KB

高德 AI 资产度量与评价体系

高德技术（信息业务中心）提出的 AI 资产度量与评价体系，核心命题：不以"AI 产出了多少"为度量核心，而以"人的投入减少了多少"为度量核心。

核心价值公式

AI 资产价值 = 任务成功率提升 + 自主完成率提升 - 人工介入次数 - 人工介入时间 - 返工次数 - 手动接管率 - 错误恢复成本

三类资产差异化评估： - Skill：少解释流程 + 少纠偏 + 稳定复用标准做法 - MCP：少手动操作 + 少工具错误 + 可靠完成外部动作 - 知识库：少查资料 + 少事实纠错 + 回答更有依据

三层评估模型

层 回答 核心指标
结果层（Outcome） "好不好" 任务成功率、自主完成率、人工介入时间/次数、返工率
过程层（Process） "为什么" Skill 遵守度/选择精度、MCP 成功率/参数正确率、知识库命中率/排序质量
证据层（Evidence） "能不能信" 消息证据 ID、置信度、unknown rate、人工反馈

三层之间逻辑严格：结果做决策，过程做改进，证据做校准。没有证据的结果指标，只是一个可能误导决策的数字。

关键反直觉发现

基于 100 个 OpenCode 会话、5914 个项目的首轮分析：

  • 安装量最高的 Skill 不一定最有价值——有些 Skill 的真正贡献是让 AI 少犯错，而非让 AI 多调用
  • websearch MCP 调用 28 次（最多）但质量分仅 59；ast_grep MCP 仅 5 次但质量分 82
  • codebase-structure Skill 显式加载 11 次但隐式影响 91 次——AI 在未显式加载时仍遵循 Skill 指令中的编码规范
  • 平均质量分 76（良好级别），但 websearch 的"高调用-低质量"暴露了产出指标和价值指标的逆向关系

设计原则

  1. 从价值反推指标，而非从数据反推价值。调了多少次 ≠ 有没有效，装了多少个 ≠ 用了多少
  2. 以"任务"而非"调用"为评估单元。单次调用成功不代表结果被用户接受
  3. 计数类不用 LLM，判断类必须输出证据和理由。低置信度时通过 bounded context escalation 扩展上下文
  4. 最难衡量的资产可能最有价值——它让 AI 少犯错，而不是让 AI 多调用

技术架构

四阶段采集策略：Phase 1 CLI 历史会话 → Phase 2 插件级实时 → Phase 3 MCP Proxy → Phase 4 任务级实时评估。当前 Phase 1 用最小成本回答"这套指标有没有信号"。

质量分析 Pipeline：prepare_messages → clean_evidence → segment_interactions → detect_skill_usage → count/judge quality → aggregate

人工反馈闭环：case → 人工审核 → 标注样本 → prompt/rubric candidate → 离线 replay → 人工批准 → active version。prompt/rubric 变更必须经离线 replay 和人工批准。

与业界方案的区别

GitHub Copilot（acceptance rate）、Cursor（tab completion/agent task completion）、Devin（autonomous completion rate）的共同失真边界：度量"AI 产出了多少"而非"人的投入减少了多少"。高德体系以"人工介入时间/次数"为北极星指标。

深度分析

北极星指标：为什么度量"人的介入"而不是"AI 的产出"

度量口径本身就是行为指令：团队会朝被计数的方向优化。acceptance rate 只统计 AI 输出是否被点采纳，不追采纳之后用户修 bug 花掉的时间；token 数度量的是消耗而非节省。高德把北极星收束到"人工介入次数 / 时间"，因为它把返工、纠偏、手动接管、错误恢复折进同一个量，直接对应"人的投入减少了多少"。

副作用必须承认：从不被触发的资产不会增加介入次数，单看介入指标会奖励"不作为"。这正是公式必须同时保留"任务成功率提升 + 自主完成率提升"的原因——正向项回答"做成了没有"，负向项回答"代价是多少"，缺一半指标就能被刷。

同一套公式，三类资产，三种失败模式

公式只有一个，但落到 Skill / MCP / 知识库上，"哪个负项在起作用"完全不同：Skill 的典型失败是"被选中却没被遵守"，故过程层看遵守度与选择精度；MCP 失败于"调用了但参数错、工具报错"，看成功率与参数正确率；知识库失败于"检索到了但排序不对、事实有误"，看命中率与排序质量。

因此三类资产统一打分再排行会误导：三者削减的负项不同（Skill 减解释与纠偏，MCP 减手动操作与工具错误，知识库减查资料与事实纠错），可比性只存在于"同一负项在采用前后的变化"里。过程指标必须跟着负项走，否则测到的是资产形态，不是价值。

证据层：把数字变成可被反驳的判断

三层模型的闭环是"结果做决策、过程做改进、证据做校准"，三者不可互替：结果层给数回答"要不要投入"，过程层回答"哪一环断了"，证据层回答"这个数凭什么可信"。没有证据层，结果指标只是孤立数字——websearch MCP 调用 28 次像是使用率冠军，直到 59 分的质量分把它还原成"最常被反复重试"；codebase-structure 显式加载 11 次像是无人使用，直到 91 次隐式影响暴露其收益来自规范约束而非调用次数。

所以"没有证据的结果指标会误导决策"在这是工程约束而非修辞：计数类走确定性统计、不交给 LLM；判断类必须输出证据与理由；低置信度时经 bounded context escalation 扩展上下文再下结论，看不清就输出 unknown。宁可承认没看见过程，也不把弱推断包装成强结论——这与 LLM 可观测性四层模型、生产级 Harness 可观测性 的分层留痕同源。

反直觉发现与采集路线：先证伪指标，再投资采集

"高调用低质量 / 低调用高质量"的方法论含义是：调用量是行为指标，不是价值指标。高调用可能意味着反复重试（websearch 28 次 vs ast_grep 5 次，质量分 59 对 82），显式加载也不等于真实影响范围（11 次 vs 91 次）。任何以使用量为核心的度量都会系统性惩罚"低摩擦、高约束"的资产——其价值恰在"没发生的事"：少犯的错、少走的弯路。这类价值天然不可计数，只能由过程层遵守度和结果层介入下降间接推断，与 Langfuse 的评测反直觉发现 属同一类系统性偏差。

四阶段路线（CLI 历史会话 → 插件级实时 → MCP Proxy → 任务级）是成本递增的排序赌注：Phase 1 用已有 CLI 日志回答"这套指标有没有信号"；只有粗粒度数据已能区分资产，Phase 2–4 的投入才谈得上回报。若最便宜的一期都看不出差异，说明指标选错或资产无可测收益，加装 Proxy 只会放大误差。业界失真边界相同：Copilot 的 acceptance rate、Cursor 完成率、Devin 的 autonomous completion rate 都在度量"AI 产出了多少"，盲区是"产出被接受 ≠ 人的投入减少"，可对照 Agent 评测：从指标到闭环。

实践启示

  1. 先写口径，再谈指标——把"人工介入次数/时间"落成可执行定义：什么算一次介入、跨会话是否累计、纠偏与返工如何记账，口径含糊，团队就会往好算的方向优化。
  2. 为每类资产预先声明它要削减的负项——Skill 减解释与纠偏，MCP 减手动操作与工具错误，知识库减查资料与事实纠错；评估表跟着负项设计，而非跟着调用量排行。
  3. 用质量分给使用量排行榜做交叉验证——裁撤或加投入前至少补一次质量分；低调用高质量的资产（如 ast_grep）通常比高调用低质量的资产（如 websearch）更值得保留。
  4. 禁止把弱推断包装成强结论——允许系统输出 confidence 与 unknown，把证据摊开给人看；不敢说"没看见过程"的报告，价值低于其成本。
  5. prompt/rubric 变更永不自动上线——须经离线 replay + 人工批准才成为 active version，否则度量系统自身会被指标化，优化的是分数而非价值。
  6. 把度量反过来用在度量者身上——同一公式可评估 agent harness、skill 库与知识库本身：它们究竟让人少介入几次、少返工几轮，才是该被回答的问题。

关联

→ 原文存档