一个 Skill 能完成任务，不代表它带来了增量价值。
模型本来就可能直接生成一份看起来不错的测试方案。如果只运行使用 Skill 的版本，然后看到结果完整，就容易把“模型本来就能做到”误写成“Skill 让结果更好”。基准测试要把这两个问题分开：模型本来会做，还是 Skill 让它做得更好。
评测通过不等于带来增量价值
评测主要回答：这个用例的行为是否符合预期。基准测试进一步追问：在任务、模型、智能体和运行环境都相同的情况下，不使用 Skill 与使用 Skill 的结果有什么差异？
相同的任务
相同的模型
相同的智能体
相同的运行环境
不使用 Skill
对比
使用 Skill如果同时更换模型、提示词、工具和上下文，最后的差异就很难归因于 Skill。结果也许更好，也许只是换了一个更强的模型。
用 functional-testing 举例说明基线
任务：为电商结账和优惠券流程设计功能测试。
不使用 Skill 时，输出可能已经覆盖正常支付和一个无效优惠券场景。使用 Skill 后，可能会额外识别角色权限、数据条件、边界规则、集成点，以及输入中没有定义的支付失败路径。
这里要比较的不是字数，而是关键行为覆盖：
| 指标 | 要看什么 |
|---|---|
| 任务成功 | 是否完成了任务目标 |
| 关键行为覆盖 | 是否覆盖关键业务和风险行为 |
| 问题发现召回率 | 已知问题或缺口被识别了多少 |
| 无依据声明率 | 是否补造了事实、字段或根因 |
| 完整性 | 重要输入、场景和限制是否被保留 |
| 令牌数 / 延迟 / 工具调用 | 质量提升增加了多少成本 |
一个更长的输出不一定更有价值；如果新增内容全是没有证据的细节，可能反而是异常增量。
基准测试用例的基本结构
id: functional-testing-benchmark-001
skill: functional-testing
type: benchmark
variants:
- without_skill
- with_skill
controls:
same_task: true
same_model: true
same_agent: true
same_environment: true
metrics:
- task_success
- critical_coverage
- unsupported_claims
- tokens
- latency这个结构不要求所有指标都必须量化，但需要说清比较条件和指标定义。否则团队只能凭印象比较两份结果。
留意 Skill 带来的负面影响
Skill 也可能让结果变差：输出更长、令牌消耗更多、响应更慢，还可能让模型过度分析或编造规则。
因此，基准测试不能只展示 Skill 表现更好的用例。至少要记录：
- 质量提升；
- 成本增加；
- 没有明显变化；
- 质量下降或成本不值得。
可以用下面的概念公式表示 Skill 带来的增益：
Skill 增益 = 结果（使用 Skill）- 结果（不使用 Skill）但不要急着把所有维度压成一个分数。质量、成本、稳定性和覆盖之间往往存在真实取舍。
基线也需要设计
糟糕的基线会让 Skill 看起来格外有效。基线至少要说明：
- 由谁或哪个系统执行；
- 使用什么提示词或默认上下文；
- 是否允许使用参考资料和工具；
- 输入和输出格式是什么；
- 评估者如何判断成功；
- 是否执行多次以及如何处理波动。
如果基线只让模型自由回答，使用 Skill 的版本却拿到了完整的项目材料，这样的比较就没有控制好条件。
多次运行与结果解读
大语言模型的输出并不固定。重要的基准测试可以记录：
样本数 n
通过率
pass@k
均值 / 中位数
方差
置信区间样本不足时不要写出过度精确的结论。三次运行能帮助发现明显不稳定，但不能支撑复杂统计声明。
基准测试、回归测试与质量声明
这三者经常被混为一谈：
| 工作 | 比较对象 | 能回答的问题 |
|---|---|---|
| 基准测试 | 不使用 Skill / 使用 Skill | Skill 是否带来增益 |
| 回归测试 | 旧版本 / 当前版本 | 变更是否破坏了原有行为 |
| 质量声明 | 证据集 / 声明 | 当前证据能支持哪些说法 |
基准测试通过，不代表新版本没有回归；回归测试通过，也不代表 Skill 比基线更有效。
把结果写进质量画像
一份有用的报告不能只写“基准测试通过”，还要说明：
Skill: functional-testing
基准测试状态：PARTIAL
证据级别：E3 运行时
对照条件：相同任务、模型、智能体和运行环境
观察结果：部分用例的关键行为覆盖有所提升
成本：观察到令牌消耗和延迟增加
限制：样本量较小；未进行跨智能体比较
下一步：扩展代表性用例后再作广泛结论这类结果可能很有价值，但仍不能据此声称“所有任务都会变好”。
一次基准测试结果能支持什么
只有在关键变量保持稳定时，基准测试结果才能支持相应的声明。比较不使用 Skill 和使用 Skill 时，尽量保持任务、模型、运行环境和评估规则一致。如果两组条件中有一组更换了提示词、增加了上下文，或使用了更宽松的评判器，结果描述的就是实验条件的整体差异，不能单独归因于 Skill。
问题要问得更具体。例如，使用 Skill 时发现了更多关键风险，但消耗的令牌也更多。这可以支持“在当前条件下提高了风险覆盖”的结论，却不能证明成本更低、响应更快或整体表现更好。应分别记录各项指标，再通过质量画像呈现这些取舍。
基线发生变化时也要单独记录。如果基线提示词、任务集或评估者发生变化，旧结果可能就不能直接比较。应把基线版本和结果放在一起；在解释明显的提升或回归之前，先用一组固定的锚点用例重新评测。
安装与调用
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en --skill functional-testing调用时明确要做对照实验：
请使用 functional-testing Skill，针对同一份结账需求设计一组基准测试。
分别说明不使用 Skill 和使用 Skill 时的运行条件。
评估指标：关键风险覆盖、无依据声明、任务成功、令牌数和延迟。
不要更换模型、运行环境或任务后，再把结果差异归因于 Skill。两个实际问题
如果不使用 Skill 已经达到 100% 覆盖，Skill 还有价值吗？
可能没有，也可能是评测太简单。需要检查是否遗漏了高风险行为、指标是否只检查格式，以及 Skill 是否在效率、可维护性或一致性方面带来其他价值。
基准测试结果不好，应该立刻修改 Skill 吗？
先区分 Skill 本身的问题、评测设计的问题、基础设施问题和原因未知的情况。如果把不公平的基线当成 Skill 问题，后续优化就会跑偏。