要给一个 AI 功能从 0 做效果评测，本指南把 效果评测体系 的五步法/四步走、Prompt测试与Agent测试 的两类对象、AI评测打分方法 的确定性/生成性打分、Badcase分析方法论 的归因闭环，整合成一套可直接落地的执行流程 + 标准化报告模板。
一句话心法（来自 效果评测体系）：没有度量，就没有改进；没有评测，就没有好产品。评测不是"上线前测一次"，是贯穿产品全生命周期的基础设施。
适用场景
| 适合 | 不适合 |
|---|---|
| 新 AI 功能上线前要量化"能不能用、哪里不好" | 纯前端改造、无 AI 输出 → 走常规 QA |
| 改 Prompt / 换模型后判断"变好还是变坏" | 验证模型"能不能做"的可行性摸底 → 用 POC验证操作指南 |
| 上线后持续监控、防止模型悄悄退化 | 多模型比价选型 → 用 模型选型报告操作指南 |
核心原则：每次只动一个变量（模型/Prompt/数据），否则不知道是哪个改动起作用。
步骤总览
| 步骤 | 名称 | 核心问题 | 主要产出 | 负责人 / 时长 |
|---|---|---|---|---|
| 1 | 分对象定指标 | 评谁？什么算达标？ | 测试对象分层 + 分层指标 + 红线 | PM 主导 / 0.5 天 |
| 2 | 建评测集 | 用什么样本来评？ | 锁定版本的评测集 | PM 主导 / 2-3 天 |
| 3 | 设计打分 | 怎么打分？ | 评分表（确定性 / 生成性） | PM + 技术 / 0.5 天 |
| 4 | 跑评测 | 结果如何？ | 评测结果矩阵 | 技术主导 / 1 天 |
| 5 | 看 Badcase | 错在哪？是系统问题吗？ | 归因清单 + 修复计划 | PM 主导 / 1 天 |
| 6 | 出报告 | 能不能上线？ | 标准化评测报告 | PM / 0.5 天 |
前置准备
- 业务目标已明确（这个 AI 功能解决什么用户问题、什么算"做得好"由业务倒推）
- 业务方对接人已对齐（评测集标注、人工打分需业务方背书）
- 评测执行入口已备齐（被测模型/Agent 的 API key 或调用脚本）
- 团队四角色就位（来自 效果评测体系）：PM 定目标与标准、Operator 提供真实场景、Server RD 接技术类 Badcase、QA 主导评测体系搭建
第一步：分对象定指标
1.1 先分清评测对象（来自 Prompt测试与Agent测试）
不要笼统说"这个 AI 准不准"，先判断卡在哪一层：
| 对象 | 问的问题 | 四个评测维度 |
|---|---|---|
| Prompt 测试 | 模型听懂了吗？ | 精确性 / 鲁棒性 / 安全性 / 格式遵从 |
| Agent 测试 | 事办成了吗？ | 任务完成度 / 工具使用 / 多轮能力 / 响应效率 |
一条业务链路常要分层叠加。把流程画成环节表，逐环节标层级与侧重点：
| 环节 | 层级（Prompt/Agent） | 评测侧重点 |
| 意图识别 | Prompt | 意图准确率、鲁棒性 |
| 槽位抽取 | Prompt | 关键字段召回率、格式稳定性 |
| 规则校验/工具调用 | Agent | 条件判断正确性、参数正确、异常处理 |
| 多轮澄清 | Agent | 澄清策略合理性、多轮稳定性 |
| ... | | |
意图/抽取这类"听懂"问题归 Prompt 层，规则/调用/多轮这类"办成"问题归 Agent 层。
1.2 定分层指标 + 红线
- 北极星指标：能代表业务价值的核心指标，避免被"准确率"这种单一技术指标绑架
- 分层指标：性能层 / 效果层 / 体验层 / 业务层
- 红线：哪些指标跌破要立即回滚/告警，提前定好
- 业务方背书：什么算"达标"必须有业务方书面签字
检查项
- 评测对象已分层（Prompt 层 / Agent 层 / 二者叠加）
- 每层四维度的侧重点已标注
- 北极星指标 + 分层指标清单已定
- 红线（回滚阈值）已定，业务方对"达标"已签字
第二步：建评测集
评测集是评测体系的根，必须由 PM 牵头、业务方共建。它是资产不是一次性数据——要像管代码一样版本化（V1.0/V2.0），锁版本后跑多版本对比时不能动。
2.1 五大构建原则（来自 效果评测体系）
| 原则 | 含义 |
|---|---|
| 覆盖性 | 覆盖不同难度/句式/干扰/核心与边缘场景 |
| 真实性 | 优先真实用户数据或高仿真合成 |
| 可标注性 | 每条都有明确预期输出或评估标准 |
| 规模 | 满足统计显著性 |
| 平衡性 | 各类别样本均衡，避免数据倾斜 |
2.2 样本来源（四类）
| 来源 | 重点采集对象 |
|---|---|
| 线上用户日志 | 尤其是用户改了 AI 输出、或重复提交的 case |
| 历史 BadCase | 被投诉的问题、算法标记的异常、用户差评 |
| 边界 Case | 人工构造的难题——矛盾需求、极端脏数据、极小众场景 |
| AI 生成初始样本 | 让 AI 生成候选，但必须人工筛选，不能直接用 |
2.3 样本数量与配比
- POC 阶段约 100 条够用；正式产品扩到 1000+ 满足统计显著性
- 常规题 + 陷阱题（陷阱题决定上限，暴露模型在边界情况的真实能力）
- 各类别样本均衡，按真实业务高频场景配比
2.4 评测集模板（可复制）
| 题号 | 评测对象层（Prompt/Agent） | 维度 | 输入 | 业务方标注的预期输出/评估标准 | 难度（常规/陷阱） | 测试目的 |
| 001 | Prompt | 精确性 | ... | ... | 常规 | ... |
| 002 | Prompt | 鲁棒性 | （错别字/繁简混用/表情）... | ... | 陷阱 | ... |
| 003 | Agent | 任务完成度 | ... | ... | 常规 | ... |
| ... |
检查项
- 样本来自四类来源（不只线上正例）
- 常规 + 陷阱题配比合理，陷阱题已覆盖边界场景
- 每条都有业务方标注的预期输出/评估标准
- 评测集已打 tag、锁版本，可溯源
第三步：设计打分
第一个决策点（来自 AI评测打分方法）：每个评测点先问"有没有标准答案"。
| 任务类型 | 判别 | 打分方法 |
|---|---|---|
| 确定性任务 | 输出有唯一/有限正确答案（如意图识别） | 预期值直接对比，算准确率/召回/F1/格式一致性 |
| 生成性任务 | 输出开放多样、无固定范式（如生图、文案） | 引入评估器多维加权打分 |
3.1 确定性任务评分表（可复制）
| 题号 | 输入 | 标准答案 | 模型输出 | 是否匹配(✓/✗) | 错误类型 |
| 001 | ... | product_agent | product_agent | ✓ | - |
| ... |
汇总：准确率 = 匹配数 / 总数；分类任务另算召回 / F1；格式题另算格式一致率
3.2 生成性任务评分表（可复制）
无标准答案时，把主观"好坏"拆成多个可判维度，各给权重，综合得分 = Σ（维度得分 × 维度权重）。维度与权重本质是"把业务价值翻译成可打的分"，必须 PM 主导。
| 维度 | 权重 | 0 分（不可用） | 1 分（勉强） | 2 分（可用） | 3 分（惊艳） |
| 维度1 | __% | ... | ... | ... | ... |
| 维度2 | __% | ... | ... | ... | ... |
| 维度3 | __% | ... | ... | ... | ... |
（合规/安全为一票否决项，不进加权，命中直接判不通过）
打分执行表：
| 题号 | 维度1得分 | 维度2得分 | 维度3得分 | 加权总分 | 一票否决命中? |
| 001 | 2 | 3 | 2 | ... | 否 |
| ... |
- 生成性任务每条至少 3 人独立打分（PM + 业务方 + 内容/设计专员），取均值或多数票，标准差 < 1
- 评估器（维度 + 打分标准）必须团队共识、版本统一；调整评估器时新旧版本都跑一遍校准分差
3.3 选评判者：金字塔配比（来自 效果评测体系）
| 评判者 | 配比 | 适用 |
|---|---|---|
| 自动评测 | 70% | 确定性任务、可程序计算的客观对错 |
| 模型评测 LLM-as-Judge | 25% | 生成性任务的主观质量，比人工快 100 倍 |
| 人工评测 | 5% | 创意/审美等机器难评维度 |
检查项
- 每个评测点已判定确定性 / 生成性
- 确定性任务有对比脚本；生成性任务有 0-3 分明确定义的评分表
- 生成性任务设了一票否决项
- 评估器版本已统一锁定
- 自动/模型/人工评判者按金字塔配比分配
第四步：跑评测
多版本对比，看趋势而非单点。两种对比视角都用"同一把固定的尺"（同一评测集 + 同一评估器）：
| 视角 | 操作 | 目的 |
|---|---|---|
| 横向对比 | 同一时间、同一评测集，比不同模型/方案（A/B/C） | 选优 |
| 纵向对比 | 同一评测集，比同一模型的不同版本（线上版 vs 待发布版） | 验迭代，是能否上线的核心依据 |
需要相对排序时用对比法（来自 AI评测打分方法）：
- GSB（Good/Same/Bad）：A 与 B 对比三档，快速大批量判优劣
- SBS（Side-By-Side）：六档（A 更好/A 好一些/B 更好/B 好一些/一样好/一样差），精细区分"明显好"与"略好"
结果矩阵模板（可复制）
| 题号 | 维度 | 版本/模型A | 版本/模型B | 结论 |
| 001 | 准确率 | ✓ | ✗ | ... |
| 002 | 加权分 | 2.4 | 2.8 | B 更优 |
| ... |
| 汇总 | 各指标对照红线 | ... | ... | 是否达上线标准 |
检查项
- 用同一评测集 + 同一评估器跑完全量
- 横向（选型）或纵向（版本回归）对比矩阵已填
- 各指标已对照第一步红线
- 相对排序场景已用 GSB/SBS
第五步：看 Badcase
跑完后错的那批 case 是"金矿"。Badcase 是信号不是作业——价值在暴露系统性问题，不是逐条喂答案。按 Badcase分析方法论 三步走。
5.1 收集 & 分类（找规律）
| 错误case | 可复现(是/偶发) | 错误类型(答反/模糊) | 输入特征共性 | 题目类型(常规/陷阱) |
| 001 | 是 | 答反 | 光线暗 | 常规 |
| ... |
5.2 归因到根本原因
| 归因类别 | 占比 | 典型表现 | 验证方法 | 责任人 |
| 模型能力问题 | __% | 换 Prompt 和数据仍答错 | 同问题测多模型对比 | Server RD |
| Prompt 设计问题 | __% | 调 Prompt 后答对 | A/B 不同 Prompt 版本 | Server RD |
| 检索召回问题 | __% | 相关文档未召回/召回无关 | 查检索日志、手动替换 query | Server RD |
| Agent 行动问题 | __% | 任务执行失败/出错 | 核查数据源、复查工具调用 | Server RD |
| 评测集/标注问题 | __% | "正确答案"本身标错 | 复核标注 | PM/QA |
| 任务定义歧义 | __% | 人工审核也分歧 | 重审任务边界 | PM |
| 数据缺失 | __% | 底层没有对应知识/字段 | 查知识库覆盖 | PM 补文档 |
5.3 对症修复（每次只动一个变量）
- Prompt 没说清 → 补规则、加约束、加 few-shot（把规律提炼成规则或示例，不是单条喂答案）
- 模型能力不够 → 换模型，重跑评测集对比
- 标注错了 → 修正评测集，重新计算
- 任务定义模糊 → 重新定义任务边界
- 修复后必须回归验证，确保问题真正解决（发现→记录→归因→解决→验证 闭环）
检查项
- Badcase 已分类找规律（可复现/类型/输入共性/题型）
- 已归因到根因类别并标占比、责任人
- 修复方案每次只动一个变量
- 修复后已回归验证
第六步：出报告
把技术报告翻译成业务方能看懂的"现在能用 / 不能用 / 风险在哪"。标准化评测报告模板（来自 效果评测体系）：
# 效果评测报告：[功能名称]
## 1. 实验背景
- 目标：□版本验证（纵向） □方案选型（横向）
- 决策影响范围：____
- 北极星指标 / 红线：____
## 2. 实验设计
- 评测对象分层：____（Prompt 层 / Agent 层）
- 对比的版本/方案：____
- 评测集版本：V__（规模 __ 条，常规/陷阱配比 __）
- 评估器版本：V__（确定性对比 / 生成性加权维度）
## 3. 核心结论
开门见山用数据说话：是否达上线标准
- 关键指标：____（红线 ____）
- 结论：□达标可上线 □不达标需修复 □部分达标
## 4. 详细数据对比
[结果矩阵：横向/纵向]
## 5. Bad Case 分析
- 典型失败案例：____
- 根因占比：____
- 解决方案 + 责任人 + 时间：____
## 6. 下一步
- 修复方案：____（每次只动一个变量）
- 下轮评测计划：____（再评时间）
- 上线灰度方案：____（接 [灰度发布](/notes/AI%E4%BA%A7%E5%93%81/%E6%A6%82%E5%BF%B5/%E7%81%B0%E5%BA%A6%E5%8F%91%E5%B8%83/)）
检查项
- 报告含实验背景/设计/核心结论/详细数据/Badcase/下一步六部分
- 核心结论开门见山，对照红线给"能/不能上线"
- Badcase 含典型案例 + 根因 + 解决方案
- 已交付业务方
常见坑
| 坑 | 后果 | 规避 |
|---|---|---|
| 笼统评"这个 AI 准不准" | 不知道卡在听不懂还是办不成 | 先分 Prompt 层 / Agent 层 |
| 评测集每次临时凑 | 不同版本结果没可比性 | 版本化锁定，像管代码一样管 |
| 评测集只有正例 | 上线后陷阱场景翻车 | 陷阱题必含，决定上限 |
| 生成性任务单人打分 | 数据有偏见 | ≥3 人独立打分，标准差 < 1 |
| 评估器口径不统一 | 同数据两个相反结论 | 评估器版本统一，调整时校准分差 |
| 看到一两条错就改 Prompt | 数据被污染，迭代失控 | 攒够 Badcase 再分类归因 |
| 一次改多个变量 | 不知道哪个起作用 | 每次只动一个变量 |
| 评了就完，不闭环 | Badcase 反复出现 | 修复后回归验证 |
完成检查清单
开评前：
- 评测对象已分层，分层指标 + 红线已定、业务方签字
- 评测集来自四类来源、含陷阱题、每条有预期答案、已锁版本
- 每个评测点已判定确定性/生成性，评分表 + 评估器版本就位
评完时：
- 用同一评测集 + 评估器跑完，对比矩阵对照红线
- Badcase 已分类归因、标责任人、修复后回归验证
- 标准化评测报告六部分完整，已交付业务方
相关页面
→ 效果评测体系（五要素/五步法/四步走/评测集五原则/团队四角色） → Prompt测试与Agent测试（两类对象 + 各四维度 + 分层评测） → AI评测打分方法（确定性 vs 生成性 + 评估器加权 + GSB/SBS） → Badcase分析方法论（归因表 + 回流闭环）