P43 · 第五章开篇

为什么要讲评测

前面我们现场手搓了 3 个 Skill —— 数据查询、售楼问数、销售达成报告。做出来不算完：怎么证明它们真的有用、真的比不用强？

没有评测，Agent 只是一个 Demo。评测才是把它从"看着能跑"变成"敢交付"的那道关。

01

理念

用什么标准评？不只是"准不准"，更要看"好不好"。

02

方法

怎么分层评？指标设计 + 三层金字塔。

03

数据集

拿什么评？评测集决定产品出厂质量。

P44 · 评测理念

理念转变：LLM as Judge → Agent as Judge

《Skill 评测：LLM-as-Judge 到 Agent-as-Judge》

以好坏为衡量：业务指标必须以"好不好"打分，既含业务指标，也含技术指标。

评测体系三件套：指标设计 + 评测集设计 + 评测工具设计，缺一不可。

综合评估：程序化评测（确定性、可重复）+ 大模型评测（主观质量）双轨并行。

引入 Sub-Agent：让 Agent 自己跑测试、自己判分 —— 评测从单次打分升级为自动化流程。

LLM-as-Judge 只看"这一句答得对不对"；Agent-as-Judge 看"整个任务做得好不好" —— 评测主体也要会干活。

P45 · 指标设计

评测指标设计：红线 + 质量层

红线层 · 一票否决

不过线，质量层再高都没有意义。

数据准确率 100% 不造数据不靠检索 / 记忆作答

质量层 · 综合回答质量

任务完成度业务

事实准确性业务

业务诉求覆盖业务

证据可追溯技术

边界与风险技术

业务表达表达

《评测指标设计：成本问数》

P46 · 评测分层

评测设计的三层金字塔

参考传统测试金字塔 —— Agent 评测同样分三层，越往下越确定、越频繁。

L3

E2E

端到端 · 真实环境

L2

Skill 测试

单 Skill 独立拆解

L1

单测

CLI 层基础验证

单测：针对 CLI 层做基础验证 —— 子命令、参数、JSON schema 是否稳定。

Skill 测试：一个业务 2–3 个 Skill，Mock CLI 输出，单个 Skill 独立拆解。如控制价审核把"指标分析"和"清单组价"拆开，7–8 步长链路简化为 1–2 步。

E2E：① CC 环境用 Sub-Agent 大规模提问，评估工具调用与用户回复；② 真实浏览器窗口测试，用 Browser Use / Codex 校验回复样式、排版、文字。

底层覆盖广、跑得勤、最确定；顶层最接近真实但成本高 —— 分层才跑得起、也信得过。

P47 · 评测数据集

评测集：决定出厂质量

《评测数据集设计：成本问数》· 17 种子场景 / 102 案例 / L1–L4 分层

行业参考：法律、医疗都靠高质量数据集 —— 医疗有基于几十个国家医生临床对话整理的人工数据集。

就是竞争力：不管做成本 / 租赁 / 售楼，最好的评测集本身就是核心竞争力。

能力可证明：同一评测集，我们打 95、友商打 90 —— 高下立判，不靠嘴说。

同一评测集 · 一把尺子量到底

95

我们的 Skill

vs

90

友商

P48 · 落地方法

评测怎么落地：CC 会话 JSONL 当数据源

评测要靠客观指标，不靠主观感觉。Claude Code 把每次会话流水自动落成 JSONL —— 这是一份现成的评测数据源。

STEP 01

固化测试剧本

把标准任务写成可重复执行的剧本。

→

STEP 02

跑完导 JSONL

CC 自动记录整段会话流水。

→

STEP 03

写提取脚本

从 JSONL 解析出结构化字段。

→

STEP 04

落客观指标

输出可对比、可追溯的报表。

效率指标

实际用时 · token 消耗 · Bash 调用次数

质量指标

错误率 · 临时补丁次数 · 读源码次数

两个底线

可重复 —— 同剧本能复跑；可追溯 —— 每个数字回得到原始会话。

把"我觉得变好了"换成"用时 79m→15m、错误率 11%→0%" —— 数字才有说服力。