把这 3 个测试 Skill 装进 OpenClaw：本地目录、安装、验证与排错

上一篇我们把一个完整的 AI 测试工作流拆成了 3 个 Skill：

sqa-prd-review
sqa-test-design
sqa-test-case-gen

分别对应：

Skill	作用
sqa-prd-review	需求评审问题生成与收敛
sqa-test-design	测试点设计、收敛与可入库筛选
sqa-test-case-gen	正式用例生成、自检与修正版输出

这篇继续往下走，不再讲“为什么要做 Skill”，而是讲：

怎么把这 3 个测试 Skill 放进 OpenClaw 的本地工作区，并完成一轮验证。

这篇会更偏实操，包括：

创建目录
→ 写 SKILL.md
→ 放入 rules 规则库
→ 准备 examples 样例
→ 在 OpenClaw 中加载验证
→ 观察输出
→ 修正 Skill
→ 常见问题排查

目标不是一次性做成完美 Skill，而是先完成一个最小可用版本。

---

一、先明确：这次不是全局安装，而是本地验证

在真正安装到 OpenClaw 全局 Skill 之前，我更建议先做“本地实验版”。

原因很简单：

1. Skill 还没经过充分验证；
2. 触发条件可能过宽；
3. 输出可能过长；
4. 规则可能不够稳定；
5. 还需要用真实 PRD 做 Eval；
6. 不适合一上来就进入正式工作流。

所以这篇的目标是：

先在 openclaw-sqa-lab 中做本地 Skill 实验，验证它是否真的有用。

建议目录：

~/openclaw-sqa-lab/
├── AGENTS.md
├── rules/
├── examples/
├── outputs/
└── skills/
    ├── sqa-prd-review/
    ├── sqa-test-design/
    └── sqa-test-case-gen/

---

二、创建本地 Skill 目录

进入实验目录：

cd ~/openclaw-sqa-lab

创建 3 个 Skill 目录：

mkdir -p skills/sqa-prd-review
mkdir -p skills/sqa-test-design
mkdir -p skills/sqa-test-case-gen

查看目录：

find skills -maxdepth 2 -type d | sort

预期结果：

skills
skills/sqa-prd-review
skills/sqa-test-case-gen
skills/sqa-test-design

这一步只是准备目录，还没有真正写 Skill。

---

三、准备共用规则库

3 个 Skill 不建议各自重复写一大堆规则。

更好的方式是把共用规则放到 rules/ 目录：

rules/
├── testcase-quality-rules.md
├── boundary-value-rules.md
├── state-machine-rules.md
├── multi-platform-rules.md
├── export-test-rules.md
└── ai-output-review-rules.md

每个 Skill 只引用需要的规则。

例如：

Skill	重点引用规则
sqa-prd-review	状态机、导出、多端、质量规则
sqa-test-design	边界值、状态机、导出、多端
sqa-test-case-gen	用例质量、自检、导出、多端、状态机

这样做的好处是：

Skill 负责流程，rules 负责判断标准。

这比把所有内容都塞进 SKILL.md 更清晰，也更容易维护。

---

四、写第一个 Skill：sqa-prd-review

先创建 skills/sqa-prd-review/SKILL.md：

cat > skills/sqa-prd-review/SKILL.md <<'EOF'
# SQA PRD Review Skill

## 名称

sqa-prd-review

## 作用

当用户提供 PRD、需求说明、会议纪要或产品规则，并要求进行需求评审、评审问题生成、待确认项整理或测试风险识别时，使用本 Skill。

## 不适用场景

如果用户没有提供具体 PRD 或需求文本，不触发本 Skill。
如果用户只是询问测试方法论，不触发本 Skill。
如果用户只是要求润色、翻译、总结普通文本，不触发本 Skill。

## 工作原则

1. 不要替产品回答问题。
2. 不要编造 PRD 中没有的规则。
3. 不明确内容必须标记为“待确认”。
4. 只提出会影响测试范围、用例设计、上线风险的问题。
5. 不要直接生成测试点或测试用例。
6. 明显超出当前 PRD 的问题放入扩展风险。
7. 核心必须确认问题建议控制在 5～7 个。
8. 输出必须表格化。

## 参考规则

执行时参考：

- rules/testcase-quality-rules.md
- rules/state-machine-rules.md
- rules/export-test-rules.md
- rules/multi-platform-rules.md

如 PRD 与规则库冲突，以 PRD 原文和用户确认结果为准。

## 执行流程

### 1. 需求摘要

提取：

| 项目 | 内容 |
|---|---|
| 需求名称 | 从 PRD 中提取 |
| 核心变更 | 用 1～3 句话概括 |
| 涉及端/系统 | PC、H5、移动端、后台、导出等 |
| 关键规则 | 金额、权限、状态、流程等 |
| 明确待确认项 | PRD 原文中已标注待确认的内容 |

### 2. 生成评审问题

按以下维度生成问题：

- 业务规则
- 边界值
- 权限角色
- 状态流转
- 异常流程
- 数据一致性
- 多端兼容
- 导出影响
- 历史数据和在途数据
- 通知和外部系统影响

每个问题必须说明：

- 为什么需要确认；
- 不确认的风险。

### 3. 问题收敛

将问题分为：

- 核心必须确认；
- 建议确认；
- 扩展风险。

## 输出格式

### 一、需求摘要

| 项目 | 内容 |
|---|---|

### 二、按维度分类的问题表

| 编号 | 维度 | 问题 | 为什么需要确认 | 不确认的风险 |
|---|---|---|---|---|

### 三、评审问题收敛

| 分类 | 问题 | 原问题编号 | 优先级 | 保留原因 | 后续动作 |
|---|---|---|---|---|---|

### 四、评审会上优先提问的 5 个问题

| 优先级 | 问题 | 理由 |
|---|---|---|

## 输出长度控制

如果评审问题超过 15 条，分批输出。
每批结束后提示：“本批输出完毕，回复继续输出下一批。”
EOF

这个 Skill 的目标很清楚：

只负责需求评审，不负责测试点和用例。

---

五、写第二个 Skill：sqa-test-design

创建 skills/sqa-test-design/SKILL.md：

cat > skills/sqa-test-design/SKILL.md <<'EOF'
# SQA Test Design Skill

## 名称

sqa-test-design

## 作用

当用户已经提供 PRD、评审问题、评审问题收敛结果或人工确认后的需求规则，并要求生成测试点、测试范围、测试点收敛或可入库筛选时，使用本 Skill。

## 不适用场景

如果没有具体 PRD、评审问题或确认后的需求规则，不直接执行本 Skill。
如果用户要求直接生成正式测试用例，应提示先完成测试点设计和可入库筛选。

## 工作原则

1. 只生成测试点，不直接生成正式测试用例。
2. 不明确内容必须标记“依赖确认=是”。
3. 不要把“业务重要”直接等同于“可生成正式用例”。
4. PRD 已明确的规则可进入“核心已确认”。
5. PRD 未明确但业务重要的规则进入“核心待确认”。
6. 当前范围外或非功能类问题进入“扩展风险”。
7. 测试点超过 20 条时必须分批输出。
8. 用户人工纠偏优先级高于模型原判断。

## 参考规则

执行时参考：

- rules/boundary-value-rules.md
- rules/state-machine-rules.md
- rules/export-test-rules.md
- rules/multi-platform-rules.md
- rules/testcase-quality-rules.md

## 执行流程

### 1. 测试点设计

基于 PRD 和评审问题生成测试点。

输出字段：

| 编号 | 测试维度 | 测试点 | 来源 | 优先级 | 是否依赖确认 | 说明 |
|---|---|---|---|---|---|---|

### 2. 测试点收敛

将测试点分为：

- 核心已确认；
- 核心待确认；
- 扩展风险。

要求：

1. 合并重复或相近测试点。
2. 核心已确认建议控制在 10～15 条。
3. 对待确认项说明阻塞的确认问题。
4. 对扩展风险说明处理建议。

### 3. 可入库用例筛选

逐条判断核心已确认测试点是否真的可以生成正式用例。

判断标准：

| 判断项 | 要求 |
|---|---|
| 规则是否明确 | 能对应 PRD 原文或用户确认结果 |
| 预期是否可验证 | 可通过页面、状态、数据、日志、文件验证 |
| 是否包含待确认内容 | 如包含，不得进入正式用例 |
| 是否存在 AI 推断 | 如存在，必须转为待确认 |

## 输出格式

### 一、测试点设计

| 编号 | 测试维度 | 测试点 | 来源 | 优先级 | 是否依赖确认 | 说明 |
|---|---|---|---|---|---|---|

### 二、测试点收敛

| 分类 | 测试维度 | 收敛后的测试点 | 来源测试点 | 优先级 | 是否依赖确认 | 保留原因 |
|---|---|---|---|---|---|---|

### 三、可入库用例筛选

| 分类 | 测试维度 | 测试点 | 是否可生成正式用例 | 原因 | 下一步动作 |
|---|---|---|---|---|---|

### 四、汇总统计

| 分类 | 数量 | P0 | P1 | P2 | 是否可立即生成用例 |
|---|---:|---:|---:|---:|---|

## 核心红线

1. PRD 使用 ≤、<、> 明确边界时，应识别边界归属。
2. PRD 未说明金额精度时，不得默认小数。
3. PRD 只写“需财务复审”时，只能生成“包含财务复审节点”测试点，不假设完整链路。
4. PRD 未说明终态时，不生成审批通过终态测试点。
5. PRD 只写“导出受影响”时，只生成导出基础回归，字段明细进入待确认。
6. PRD 只写“影响 PC/H5”时，不推断两端完全一致。
7. PRD 标注“待确认”时，不进入核心已确认。

## 输出长度控制

如果测试点超过 20 条，分批输出。
每批结束后提示：“本批输出完毕，回复继续输出下一批。”
EOF

这个 Skill 的重点是：

不急着写用例，先判断哪些测试点能入库。

---

六、写第三个 Skill：sqa-test-case-gen

创建 skills/sqa-test-case-gen/SKILL.md：

cat > skills/sqa-test-case-gen/SKILL.md <<'EOF'
# SQA Test Case Generation Skill

## 名称

sqa-test-case-gen

## 作用

当用户已经提供核心已确认测试点、可入库用例筛选结果或明确的需求规则，并要求生成正式测试用例、用例自检或修正版用例时，使用本 Skill。

## 不适用场景

如果没有“核心已确认”或可入库测试点，不直接生成正式用例。
应提示用户先执行 sqa-test-design 完成可入库筛选。

## 工作原则

1. 只基于“核心已确认”测试点生成正式用例。
2. 不为“核心待确认”和“扩展风险”生成正式用例。
3. 待确认内容必须单独输出为清单。
4. 用例步骤必须可执行。
5. 预期结果必须可验证。
6. 不允许补充 PRD 中没有的规则。
7. 不允许写“流程结束”“终审”“已完成”“字段取值”等未确认结论。
8. 多端用例要收敛，不机械复制。
9. 正式用例生成后必须执行自检。
10. 自检后必须输出修正版用例或修改建议。

## 参考规则

执行时参考：

- rules/testcase-quality-rules.md
- rules/state-machine-rules.md
- rules/export-test-rules.md
- rules/multi-platform-rules.md
- rules/ai-output-review-rules.md

## 执行流程

### 1. 正式测试用例生成

输出字段：

| 用例编号 | 用例标题 | 前置条件 | 操作步骤 | 预期结果 | 优先级 | 来源测试点 |
|---|---|---|---|---|---|---|

要求：

1. 每条用例必须能对应一个核心已确认测试点。
2. 前置条件必须明确角色、数据、状态。
3. 操作步骤必须可执行。
4. 预期结果必须可观察或可验证。
5. 待确认问题不生成正式用例。

### 2. 用例自检

生成正式用例后，必须执行自检。

自检项：

1. 是否把待确认问题写成确定性用例；
2. 是否存在 PRD 中没有明确说明的预期；
3. 是否出现“流程结束”“终审”“字段取值”等未确认结论；
4. PC/H5 是否机械重复；
5. 预期结果是否可验证；
6. 是否遗漏待确认问题清单；
7. 是否存在需求外编造；
8. 是否存在可合并的重复用例；
9. 是否将待确认功能生成正式用例；
10. 导出相关用例是否写入未确认字段明细。

### 3. 修正输出

基于自检结果输出修正版正式用例。

输出内容：

- 修正后的正式用例清单；
- 用例数量统计；
- P0/P1/P2 数量；
- 仍需产品确认的问题清单；
- 是否可进入人工评审或用例入库。

## 核心红线

| 场景 | 禁止写法 | 正确写法 |
|---|---|---|
| 审批通过终态未确认 | 流程结束、已完成、终审通过 | 标记为待确认 |
| 财务复审完整链未确认 | 部门负责人 + 财务复审两层 | 仅验证包含财务复审节点 |
| 导出字段未确认 | 包含审批状态、审批人、审批时间字段 | 导出可用、文件可打开、记录数量一致 |
| PC/H5 一致性未确认 | 状态与 PC 端一致 | 本端状态正确展示 |
| UI 交互未确认 | 页面跳转、弹窗、Toast | 只验证状态或数据结果 |
| 驳回信息未确认 | 驳回原因、驳回人、驳回时间展示正确 | 只验证状态为已驳回 |
| 待确认功能 | 生成正式用例 | 输出到待确认清单 |

## 输出长度控制

如果正式用例超过 10 条，分批输出。
每批结束后提示：“本批输出完毕，回复继续输出下一批。”

## 输出格式

### 一、正式测试用例

| 用例编号 | 用例标题 | 前置条件 | 操作步骤 | 预期结果 | 优先级 | 来源测试点 |
|---|---|---|---|---|---|---|

### 二、待确认问题清单

| 编号 | 待确认问题 | 阻塞用例范围 | 优先级 |
|---|---|---|---|

### 三、用例自检报告

| 检查项 | 结果 | 发现问题数 |
|---|---|---:|

### 四、修正后的最终版用例

| 用例编号 | 用例标题 | 前置条件 | 操作步骤 | 预期结果 | 优先级 | 来源测试点 |
|---|---|---|---|---|---|---|

### 五、最终判定

| 判定项 | 结论 |
|---|---|
| 是否可进入人工评审 | 是/否 |
| 是否可入库 | 是/修改后可入库/否 |
| 仍需产品确认问题数 | 数量 |
| 正式用例数量 | 数量 |
EOF

这第三个 Skill 的重点是：

不只是生成用例，而是生成后必须自检。

---

七、检查 3 个 Skill 文件

执行：

find skills -maxdepth 2 -type f | sort

预期输出：

skills/sqa-prd-review/SKILL.md
skills/sqa-test-case-gen/SKILL.md
skills/sqa-test-design/SKILL.md

再查看每个文件：

cat skills/sqa-prd-review/SKILL.md
cat skills/sqa-test-design/SKILL.md
cat skills/sqa-test-case-gen/SKILL.md

如果内容正常，说明本地 Skill 草案已经准备好了。

---

八、把 Skill 加入 AGENTS.md 的索引

为了让 OpenClaw 知道这 3 个 Skill 的用途，可以在 AGENTS.md 里追加一段说明：

cat >> AGENTS.md <<'EOF'

## 本地测试 Skill 草案

当前工作区包含 3 个本地测试 Skill 草案：

1. skills/sqa-prd-review/SKILL.md
   - 用于需求评审问题生成和收敛；
   - 不生成测试点和测试用例。

2. skills/sqa-test-design/SKILL.md
   - 用于测试点设计、测试点收敛和可入库用例筛选；
   - 不直接生成正式测试用例。

3. skills/sqa-test-case-gen/SKILL.md
   - 用于基于核心已确认测试点生成正式用例；
   - 必须执行用例自检并输出修正版。

使用原则：
- 先评审，再测试点，再用例；
- 不要跨步生成；
- 用户可以从任意阶段开始，但必须检查输入是否满足该阶段要求。
EOF

然后查看：

tail -80 AGENTS.md

这一步相当于给 OpenClaw 建了一个本地 Skill 索引。

---

九、准备验证用 PRD

如果前面已经有 examples/reimbursement-prd.md，可以继续用。

没有的话可以创建：

cat > examples/reimbursement-prd.md <<'EOF'
# PRD：报销审批规则优化

1. 普通员工可提交本人报销申请。
2. 报销金额 ≤ 5000 元时，仅直属上级审批。
3. 5000 元 < 报销金额 ≤ 20000 元时，需部门负责人审批。
4. 报销金额 > 20000 元时，需财务复审。
5. 提交后申请状态变为“审批中”。
6. 审批中可撤回，撤回后状态回到“草稿”。
7. 任一节点驳回后，状态变为“已驳回”，申请人可修改后重新提交。
8. 是否支持批量导入报销单，待产品确认。
9. 本次改动影响 PC 端、H5 端和报销数据导出。
EOF

---

十、在 OpenClaw 中验证第一个 Skill

打开 Dashboard：

http://127.0.0.1:18789/

输入：

请参考当前工作区的 skills/sqa-prd-review/SKILL.md，对下面 PRD 执行需求评审问题生成和收敛。

要求：
1. 不要生成测试点；
2. 不要生成测试用例；
3. 输出需求摘要、评审问题表、问题收敛和评审会上优先提问的 5 个问题；
4. 不明确内容必须标记为待确认；
5. 不要替产品回答问题。

PRD 如下：
【粘贴 examples/reimbursement-prd.md 内容】

观察输出是否满足：

检查项	合格标准
是否只输出评审问题	是
是否没有生成用例	是
是否识别批量导入待确认	是
是否识别审批终态缺失	是
是否识别导出字段待确认	是
是否输出优先 5 问	是

---

十一、验证第二个 Skill

基于第一步输出，继续输入：

请参考当前工作区的 skills/sqa-test-design/SKILL.md，基于上一步评审结果执行测试点设计、测试点收敛和可入库用例筛选。

要求：
1. 不要生成正式测试用例；
2. 每个测试点必须标记是否依赖确认；
3. 将测试点分为核心已确认、核心待确认、扩展风险；
4. 对可入库测试点逐条说明是否可生成正式用例；
5. 不要把“需财务复审”推断成完整审批链；
6. 不要把“导出受影响”推断成字段明细；
7. 不要把“影响 PC/H5”推断成两端完全一致。

观察输出是否满足：

检查项	合格标准
是否正确识别金额边界	5000 属于第一档，20000 属于第二档
是否把 >20000 限制为包含财务复审节点	是
是否把导出字段放入待确认	是
是否生成核心已确认 / 核心待确认 / 扩展风险	是
是否没有生成正式用例	是

---

十二、验证第三个 Skill

基于第二步输出，继续输入：

请参考当前工作区的 skills/sqa-test-case-gen/SKILL.md，基于上一步“核心已确认”测试点生成正式测试用例，并执行用例自检和修正版输出。

要求：
1. 只基于核心已确认测试点生成正式用例；
2. 不为核心待确认和扩展风险生成用例；
3. 不写审批通过后的“流程结束”“终审”“已完成”；
4. 不生成导出字段明细校验；
5. 不生成批量导入正式用例；
6. 金额 >20000 只验证包含财务复审节点；
7. 生成后必须自检。

观察输出是否满足：

检查项	合格标准
是否只生成核心已确认用例	是
是否包含用例自检	是
是否没有写终审/流程结束	是
是否没有写导出字段明细	是
是否没有写批量导入用例	是
是否输出修正版或修改建议	是

---

十三、常见问题 1：OpenClaw 不读取本地文件

如果你发现 OpenClaw 没有读取 skills/.../SKILL.md，可以先不要纠结自动读取机制，直接手工加载：

cat skills/sqa-prd-review/SKILL.md

把输出复制到 Dashboard 里，然后再输入 PRD。

本地验证阶段，手工加载是可以接受的。

等 Skill 稳定后，再考虑真正安装或放到 OpenClaw Skill 目录。

---

十四、常见问题 2：输出又被截断

如果测试点或用例太多，可以追加：

请不要一次输出完整大表。
请先输出摘要统计，然后每批最多输出 15 条。
每批结束后等待我回复“继续”。

或者：

刚才输出在 TP-032 附近被截断了。
请不要重复前面的内容，从 TP-032 开始继续输出。

这个问题很常见，尤其是测试点超过 40 条时。

所以在 Skill 里提前写“输出长度控制”很有必要。

---

十五、常见问题 3：AI 仍然过度推断

如果它又写出：

金额 >20000 时，部门负责人审批后进入财务复审。

你就追加：

请修正：PRD 只写“金额 >20000 元时，需财务复审”，未说明完整审批链。
因此只能验证“包含财务复审节点”，不得写部门负责人 + 财务复审两层。
请重新输出相关测试点或用例。

如果它又写导出字段：

导出包含审批状态、审批人、审批时间字段。

追加：

请修正：PRD 只写“报销数据导出受影响”，未提供字段清单。
字段明细必须进入待确认清单，正式用例只能验证导出可用性和记录数量一致性。

这些纠偏内容后续要沉淀回 rules 目录。

---

十六、常见问题 4：Skill 太容易触发

如果你发现它一看到“PRD”就开始跑评审，可以在 SKILL.md 里加强触发规则：

如果用户只是粘贴需求但未说明任务意图，先询问：
“你希望我做需求评审、测试点设计，还是正式用例生成？”
不得自动开始完整流程。

对于测试类 Skill，我建议使用“确认式触发”。

宁愿多问一句，也不要误跑一堆表格。

---

十七、验证结果怎么记录？

每次验证建议保存到 outputs/：

outputs/
├── 01-prd-review-output.md
├── 02-test-design-output.md
├── 03-case-gen-output.md
├── 04-self-check-output.md
└── 05-final-cases-output.md

这样后面可以对比：

版本	变化
v1	初版 Skill 输出
v2	增加规则后输出
v3	增加自检后输出

如果你不保存过程，很难判断 Skill 是否真的变好了。

---

十八、什么时候可以正式安装？

我建议满足下面条件后，再考虑正式安装：

条件	标准
触发稳定	不误触发，不漏触发
输出稳定	字段结构基本固定
规则有效	不再明显过度推断
自检有效	能发现至少部分自身问题
样例通过	至少 3 个 PRD 样例通过
人工纠偏减少	同类错误不反复出现

不要因为一个样例成功就安装。

Skill 的价值在“稳定复用”，不是“跑通一次”。

---

十九、小结

这篇我们做的事情很具体：

创建 3 个 Skill 目录
→ 写 3 个 SKILL.md
→ 在 AGENTS.md 中建立索引
→ 准备示例 PRD
→ 在 Dashboard 中逐个验证
→ 观察输出问题
→ 用 rules 反向修正 Skill

这就是把 Skill 从“设计稿”推进到“可验证版本”的过程。

这 3 个 Skill 的边界分别是：

sqa-prd-review：只问问题
sqa-test-design：只做测试点和可入库筛选
sqa-test-case-gen：只生成用例、自检和修正

它们串起来，就是完整的 AI 测试设计工作流。

但最关键的仍然不是 Skill 文件本身，而是这套迭代方式：

写 Skill
→ 用真实 PRD 验证
→ 发现问题
→ 更新规则
→ 修正 Skill
→ 再验证

测试工程师做 Skill，不应该追求“一次写完”。

更合理的目标是：

让每一次 AI 犯错，都变成下一版 Skill 的规则。

这样 OpenClaw 才能从“能回答问题”，逐步变成“能稳定参与测试工作流”。