LLM 评测设计 Skill：先定评分规则，再谈模型回归门禁

AI总结缩略版

这篇文章介绍 llm-evaluation-design Skill——回答一个最容易被忽略的评估问题：分数好看之后，这个分到底能不能拿来比较、能不能拦住发布？

核心理念

LLM 评估最常见的误区是先收集一堆漂亮示例，再去找分数解释它们。正确顺序是先明确目标、失败代价和判断标准。这个 Skill 把任务集、评分量表和决策阈值先固定下来，让分数的含义与局限都写清楚，而不是每次评测都换一把尺子。

它的边界写在报告里：指标必须映射真实任务，LLM-as-judge 要校准并抽检，离线质量与线上业务指标要分开。没有稳定任务集和评分标准时，分数无法比较，只能先标为设计阶段。

先固定评价尺子，再谈分数

四个坑不能踩

• • 任务集只覆盖容易的问题，模型得分虚高。
• • 评分标准含糊，人工评审者各自使用一把尺子。
• • 评测集泄漏到提示词或训练数据，结果失去解释力。
• • 只比较总分，忽略关键任务和安全类别的回归。

把一次分析变成持续机制

每次评测都保存任务集版本、模型版本、评分规则和评审者，任一项变化都记录原因并重新校准受影响的分数。三段式 Skill 链 prompt-testing → llm-evaluation-design → llm-testing，交接时同时传摘要、证据索引和原始材料位置，这样结论出问题也能回到来源。

交付前复核

输入版本是否明确、范围是否完整、每条结论能否回到证据、下一步由谁执行。只有静态检查或历史结果时标 assumption，不能借它支持当前版本的运行结论；人工改报告也要留变更原因。

常见问题

输入不完整也能开始，先交付受限初版：列出已知事实、假设、缺口和最小验证动作，环境或数据缺失时不写执行结论。范围取舍、风险接受、生产操作、数据权限和发布决定必须由对应负责人确认，Skill 只整理证据与选项，不替团队做授权决定。

相关 Skill

• • LLM 测试：执行事实、拒答、稳定性和安全边界检查。
• • AI Agent 测试：把多步规划和工具行为纳入评测。
• • 测试报告：记录评分输入、版本、结果和证据边界。

安装

npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/llm-evaluation-design -g

一句话：这个 Skill 帮你先把评价的尺子钉死——任务集、评分标准、评审校准、回归门禁四件事先固定，每个未覆盖项都带风险和验证动作，让模型版本比较和发布门禁建立在可解释的证据上，而不是一张漂亮的分数截图。

完整版

LLM 评估最常见的误区是先收集一堆漂亮示例，再去找分数解释它们。好的评估先明确目标、失败代价和判断标准。

LLM 评估设计 Skill 构建有代表性的数据集、量表和决策阈值，使分数的含义与局限明确。

本文以客服摘要模型为例，说明如何从任务集、评分规则和回归门禁建立可解释的评测。

LLM 评测设计 Skill 用来做什么

LLM 评测设计适合要比较模型版本、建立评测集或设置回归门禁的团队。它先固定任务集和评分尺子，再讨论分数变化，避免每次评测都换一套标准。

先回到源 Skill

这个 Skill 的完整执行规则在 LLM 评测设计 提示词。源目录还包含 3 个评测用例，用于验证输出是否遵守契约。

它要求特别注意：

• • 指标必须映射真实任务
• • LLM-as-judge 要校准并抽检
• • 区分离线质量与线上业务指标

用一份项目材料开始

先把现有材料列出来。缺口可以保留，但状态要说清楚。

可以这样调用：

请使用 llm-evaluation-design Skill。任务：为客服摘要模型设计任务集、评分量表、参考答案、评审流程与回归门禁输入材料：[版本、链接、日志或报告路径]范围：[本次包含和排除的对象]限制：[时间、数据、权限、合规要求]先审计输入，再按风险和证据强度排序。材料没有证明的内容标为假设，并列出验证方法。

LLM 评测设计要先固定评价尺子

没有稳定任务集和评分标准时，评测分数无法比较；先标为设计阶段。

在项目里跑一轮

先从一个边界清楚的小回合开始：为客服摘要模型设计任务集、评分量表、参考答案、评审流程与回归门禁。别急着把结果写成报告。先把输入版本、时间窗口和负责人贴到同一处；然后把每个判断连回具体材料；最后只安排一项能改变结论的验证动作。

评测集要覆盖高价值任务、风险样本和失败边界，评分规则必须可复核。这一轮至少要留下可复查的证据索引、仍然成立的假设，以及下一位同事可以直接执行的动作。

进阶使用：把一次分析变成持续机制

每次 LLM 评测设计都保存任务集版本、模型版本、评分规则和评审者。任何一项变化都要记录原因，并重新校准受影响的分数。

三段式 Skill 链

prompt-testing → llm-evaluation-design → llm-testing

交接时同时传摘要、证据索引和原始材料的位置。这样即使结论出了问题，也能回到来源。

团队门禁

容易踩的坑

1. 1. 任务集只覆盖容易的问题，模型得分虚高。
2. 2. 评分标准含糊，人工评审者各自使用一把尺子。
3. 3. 评测集泄漏到提示词或训练数据，结果失去解释力。
4. 4. 只比较总分，忽略关键任务和安全类别的回归。

相关 Skill

评测设计先定标准，再连接模型测试和结果留档：

• • LLM 测试：执行事实、拒答、稳定性和安全边界检查。
• • AI Agent 测试：把多步规划和工具行为纳入评测。
• • 测试报告：记录评分输入、版本、结果和证据边界。

交付前复核：把判断落到证据

拿到 Skill 输出后，先核对四件事：输入版本是否明确、范围是否完整、每条结论能否回到证据、下一步由谁执行。缺一项，报告就容易变成漂亮的猜测。

source_version: [版本或提交]scope: [本次包含和排除的对象]evidence: [日志、报告、Trace 或命令输出]status: pendingowner: [负责人]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/

更多

• • 点击阅读原文，获取更多信息
• • 个人网站链接：https://inaodeng.com
• • AI生成测试检测项目：https://github.com/AI-Native-QA-Lab/ai-test-auditor
• • DeepSeek Harness QA 工作台项目：https://github.com/naodeng/dsh-qa
• • 更多AI 测试技能：https://inaodeng.com/zh-cn/qaskills/
• • 更多 测试 百科：https://inaodeng.com/zh-cn/wiki/
• • 更多 AI 百科：https://inaodeng.com/zh-cn/AIWiki/