> For the complete documentation index, see [llms.txt](https://zhouhao4221.gitbook.io/haiqing-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zhouhao4221.gitbook.io/haiqing-docs/04-prompt/skill-testing.md).

# AI Skill 测试：概率性系统的验收方法

## 1. 为什么不能套用传统测试思路

传统单元测试的前提是：相同输入产生相同输出。这个前提在 Skill 上不成立。

Skill 是概率性的：同一输入在不同运行、不同模型版本、不同上下文长度下，都可能产生不同输出。这意味着：

* 不能靠精确字符串匹配来验收
* 不能用一次通过来证明"这个 Skill 是好的"
* 不能在模型升级后假设行为不变

Skill 的测试目标不是"验证输出等于期望值"，而是**验证输出落在可接受范围内，且这个范围在持续时间和模型变更中保持稳定**。

***

## 2. 测什么

### 2.1 结构正确性

输出是否符合预期的格式和 Schema。这是最容易自动化的一层。

* JSON 字段是否完整
* 必要章节是否存在
* 长度是否在合理范围内

结构错误是硬性失败，可以自动拦截并触发重试。

### 2.2 语义正确性

输出是否在语义上符合预期。这是最难的一层，也是最重要的一层。

问题在于：**对于生成类 Skill，"正确"没有唯一答案。**

可操作的定义方式：

| 方法                      | 适用场景                          | 局限                  |
| ----------------------- | ----------------------------- | ------------------- |
| **评分标准（Rubric）**        | 有明确评估维度时（如：逻辑完整性、覆盖范围、是否符合约束） | 需要人工定义标准，不同评估者可能不一致 |
| **黄金样本比较**              | 有已知好输出作为参照时                   | 样本需要人工维护，可能随时间过时    |
| **AI 评审（LLM-as-Judge）** | 快速批量评估，或无法人工逐一审查时             | 评审模型本身可能有偏差，需要校准    |
| **人工评审**                | 关键 Skill 的首次验收或重大变更后          | 成本高，不适合高频回归         |

对于每个 Skill，应在上线前明确：**用哪种方法定义语义正确性，验收门槛是什么。**

### 2.3 稳定性

相同输入下，多次运行的输出是否一致到可接受的程度。

不要求输出完全相同，但要求：

* 核心结论不矛盾
* 关键字段不随机翻转
* 输出质量不出现大幅波动

测量方式：同一输入运行 N 次，对比输出之间的语义相似度或评分方差。

### 2.4 跨模型版本回归

模型升级后（如从 claude-sonnet-4-5 升级到 claude-sonnet-4-6），Skill 行为可能悄悄变化。

这类退化的特征是：**没有报错，输出看起来合理，但质量或行为方向偏移了。**

应对方式：

* 为每个关键 Skill 维护一组**基准测试集**（输入 + 期望的质量评分范围）
* 模型升级前后各跑一次，对比评分分布
* 差异超过阈值时，视为需要人工评审的回归，而不是自动通过

***

## 3. 测试频率

| 触发条件            | 测试范围                |
| --------------- | ------------------- |
| Skill Prompt 修改 | 该 Skill 全部基准测试集     |
| 模型版本升级          | 所有关键 Skill 的基准测试集   |
| 上游 Skill 行为变更   | 依赖该 Skill 的下游 Skill |
| 定期（如每月）         | 核心工作流端到端抽样验收        |

不需要在每次代码提交时运行所有 Skill 测试——成本不合理。但需要在**任何可能影响 Skill 行为的变更**后运行。

***

## 4. 验收门槛怎么定

没有适用所有场景的统一门槛。按 Skill 的风险等级分类：

| 风险等级    | 描述                       | 建议验收方式                              |
| ------- | ------------------------ | ----------------------------------- |
| **高风险** | 输出直接影响生产决策（如需求验收标准、架构建议） | 人工评审 + 评分标准，首次上线必须人工签字              |
| **中风险** | 输出影响开发流程（如代码生成、测试用例生成）   | LLM-as-Judge + 人工抽样，每次 Prompt 变更后回归 |
| **低风险** | 格式转换、文档生成等辅助性任务          | 结构验证 + 稳定性测试，异常时人工检查                |

> 验收门槛的核心问题：如果这个 Skill 在不被人工检查的情况下产出错误，最坏的后果是什么？根据这个后果决定门槛。

***

## 5. AI 评审（LLM-as-Judge）的注意事项

用模型来评估另一个模型的输出，是高效但需要谨慎使用的方法。

**适合用的场景**：

* 批量评估，人工无法逐一审查
* 评估维度明确，可以写成清晰的评分提示
* 作为初筛，人工重点复查低分样本

**不适合用的场景**：

* 评估高度专业的领域知识（评审模型的领域能力不一定足够）
* 首次建立验收基准（此时没有参照，评审模型的判断不可靠）
* 评审结果直接触发自动化操作（中间没有人工审查）

**校准方式**：取一批人工已评分的样本，让评审模型打分，对比两者差异。差异过大时调整评审提示，而不是直接信任模型评分。

***

## 6. 最小可行测试实践

如果从零开始，最小可行的测试体系是：

1. **为每个 Skill 准备 3-5 个代表性输入**，覆盖正常情况和边界情况
2. **人工评审一次**，记录每个输入的"可接受输出范围"（不必精确，但要明确哪些是不可接受的）
3. **写结构验证**，自动拦截格式错误
4. **建立回归基准**：记录当前输出的评分，模型升级后对比

这四步不需要复杂工具，但能覆盖最常见的退化场景。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://zhouhao4221.gitbook.io/haiqing-docs/04-prompt/skill-testing.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.