LLM 评测设计 Skill：先定评分规则，再谈模型回归门禁
LLM 评估最常见的误区是先收集一堆漂亮示例，再去找分数解释它们。好的评估先明确目标、失败代价和判断标准。
LLM 评估设计 Skill 构建有代表性的数据集、量表和决策阈值，使分数的含义与局限明确。
本文以客服摘要模型为例，说明如何从任务集、评分规则和回归门禁建立可解释的评测。
LLM 评测设计 Skill 用来做什么
LLM 评测设计适合要比较模型版本、建立评测集或设置回归门禁的团队。它先固定任务集和评分尺子，再讨论分数变化，避免每次评测都换一套标准。
先回到源 Skill
这个 Skill 的完整执行规则在 LLM 评测设计 提示词。源目录还包含 3 个评测用例，用于验证输出是否遵守契约。
它要求特别注意：
- 指标必须映射真实任务
- LLM-as-judge 要校准并抽检
- 区分离线质量与线上业务指标
用一份项目材料开始
先把现有材料列出来。缺口可以保留，但状态要说清楚。
| 材料 | 这次填什么 | 缺失时的处理 |
|---|---|---|
| 目标与范围 | 为客服摘要模型设计任务集、评分量表、参考答案、评审流程与回归门禁 | 标出不在本轮判断内的链路 |
| 版本与环境 | 模型版本、任务集版本、评审者配置、随机种子和评测窗口 | 版本漂移时先重建可比基线 |
| 证据 | 评分量表、参考答案、原始输出、人工标注和统计区间 | 没有标注依据时不下质量结论 |
| 决策边界 | 通过阈值、分歧处理、回归门禁和评测 Owner | 说明自动分数与人工复核的关系 |
可以这样调用：
请使用 llm-evaluation-design Skill。
任务：为客服摘要模型设计任务集、评分量表、参考答案、评审流程与回归门禁
输入材料：[版本、链接、日志或报告路径]
范围：[本次包含和排除的对象]
限制：[时间、数据、权限、合规要求]
先审计输入，再按风险和证据强度排序。材料没有证明的内容标为假设，并列出验证方法。LLM 评测设计要先固定评价尺子
| 产物 | 要回答的问题 | 最低证据 |
|---|---|---|
| 任务集 | 覆盖哪些真实任务和失败边界 | 版本化样本、标签和代表性说明 |
| 评分标准 | 什么叫通过、部分通过或失败 | rubric、权重和示例答案 |
| 评审校准 | 人工与自动评分是否一致 | 双评记录、分歧和校准结果 |
| 回归门禁 | 哪些变化会阻断发布 | 基线、阈值和例外审批 |
没有稳定任务集和评分标准时，评测分数无法比较；先标为设计阶段。
在项目里跑一轮
先从一个边界清楚的小回合开始：为客服摘要模型设计任务集、评分量表、参考答案、评审流程与回归门禁。别急着把结果写成报告。先把输入版本、时间窗口和负责人贴到同一处；然后把每个判断连回具体材料；最后只安排一项能改变结论的验证动作。
评测集要覆盖高价值任务、风险样本和失败边界，评分规则必须可复核。这一轮至少要留下可复查的证据索引、仍然成立的假设，以及下一位同事可以直接执行的动作。
进阶使用：把一次分析变成持续机制
每次 LLM 评测设计都保存任务集版本、模型版本、评分规则和评审者。任何一项变化都要记录原因，并重新校准受影响的分数。
三段式 Skill 链
prompt-testing → llm-evaluation-design → llm-testing
| 交接 | 传递内容 | 接收方要检查什么 |
|---|---|---|
| 上游到 llm-evaluation-design | 来源版本、范围、风险、未决项 | 输入是否过期，冲突是否标记 |
| llm-evaluation-design 到下游 | 判断、证据索引、残余风险、待办 | 产物是否可执行，Owner 是否明确 |
| 下游回写 llm-evaluation-design | 执行结果、缺陷、事实变化 | 是否更新基线与回归范围 |
交接时同时传摘要、证据索引和原始材料的位置。这样即使结论出了问题，也能回到来源。
团队门禁
| 门禁 | 检查内容 | 未满足时 |
|---|---|---|
| llm-evaluation-design 输入门禁 | 版本、环境、证据来源和 Owner | 停止生成，列出缺口 |
| llm-evaluation-design 产物门禁 | 关键结论带依据、状态和影响 | 退回补证据 |
| llm-evaluation-design 执行门禁 | 命令、查询或验证路径可复现 | 标记基础设施或测试问题 |
| llm-evaluation-design 决策门禁 | 残余风险有接受人与日期 | 不进入下一阶段 |
容易踩的坑
- 任务集只覆盖容易的问题，模型得分虚高。
- 评分标准含糊，人工评审者各自使用一把尺子。
- 评测集泄漏到提示词或训练数据，结果失去解释力。
- 只比较总分，忽略关键任务和安全类别的回归。
相关 Skill
评测设计先定标准，再连接模型测试和结果留档：
- LLM 测试：执行事实、拒答、稳定性和安全边界检查。
- AI Agent 测试：把多步规划和工具行为纳入评测。
- 测试报告：记录评分输入、版本、结果和证据边界。
交付前复核：把判断落到证据
拿到 Skill 输出后，先核对四件事：输入版本是否明确、范围是否完整、每条结论能否回到证据、下一步由谁执行。缺一项，报告就容易变成漂亮的猜测。
| 项目 | 需要留下 | 缺失时 |
|---|---|---|
| 输入边界 | 版本、环境、时间窗口和本次范围 | 标记假设，不写成事实 |
| 证据索引 | 日志、报告、Trace、截图或命令输出 | 标记 evidence_pending |
| 结论状态 | verified、assumption、blocked 或 pending | 停止扩大结论 |
| 后续动作 | 最小验证命令、负责人和截止时间 | 交付为待办，不进入门禁 |
source_version: [版本或提交]
scope: [本次包含和排除的对象]
evidence: [日志、报告、Trace 或命令输出]
status: pending
owner: [负责人]
next_action: [最小验证动作]分析类 Skill 要保留查询条件和时间窗口；执行类 Skill 要保留命令、退出码和失败产物。人工修改也要记录，否则下一次复核时无法解释结论为何变化。
安装与调用
安装这个 Skill：
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/llm-evaluation-design -g安装后，直接使用上面的 llm-evaluation-design 调用词，并附上本次的真实材料。
常见问题
输入还不完整，能开始吗？
能。先交付受限初版：列出已知事实、假设、缺口和最小验证动作。环境、数据或权限缺失时，不写执行结论。
什么时候需要人工确认？
范围取舍、风险接受、生产操作、数据权限和发布决定必须由对应负责人确认。Skill 负责整理证据与选项，不替团队做授权决定。
先用一份真实材料跑通 LLM 评测设计，并把输入、产物、人工修改和验证证据留在同一条工作链上。这样下一次发生变化时，才有东西可以复用。
参考
- LLM 评测设计 提示词：https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/llm-evaluation-design/prompts/llm-evaluation-design.md
- Awesome QA Skills：LLM 评测设计 Skill 源文件：https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/llm-evaluation-design
- Awesome QA Skills GitHub 项目：https://github.com/naodeng/awesome-qa-skills
- LLM 评测设计 Skill 详情页：https://inaodeng.com/zh-cn/qaskills/llm-evaluation-design/