Skill Creator 不是帮你写一个 SKILL.md，而是把经验变成可复用能力

最近连续做了几轮 OpenClaw、Codex、Claude Code 相关实践后，我越来越觉得：

Skill Creator 真正有价值的地方，不是“帮你生成一个技能文件”，而是帮你把一次性的经验，沉淀成可复用、可测试、可迭代的能力。

很多人第一次接触 Skill Creator，容易把它理解成：

我描述一个需求，它帮我生成一个 SKILL.md。

这当然是它的一部分价值。

但如果只停留在这里，Skill Creator 很容易变成“Prompt 生成器”。

真正更有价值的用法应该是：

一次成功经验
→ 抽象成流程
→ 写成 Skill
→ 设计触发条件
→ 增加质量约束
→ 准备测试样例
→ 做 Eval
→ 根据失败样例 Improve
→ 最后形成稳定能力

这篇文章就结合 OpenClaw、Codex、Claude Code 这类主流 Agent 工具的使用思路，聊聊：

如何用 Skill Creator 把测试工程师的经验，沉淀成一套可复用的测试工作流能力。

---

一、为什么需要 Skill，而不是只写 Prompt？

很多人用 AI 工具时，最常见的方式是不断写 Prompt。

比如测试场景里，我们可能会写：

请根据下面 PRD 生成测试用例。
请考虑边界值、异常流程、权限、多端和导出。
请输出表格。
请不要遗漏风险。

这种方式有用，但不稳定。

因为 Prompt 更像一次性任务说明。

这次写得很详细，AI 输出可能不错。
下次换一个需求，AI 又可能犯同样的错误：

• 把待确认项写成正式用例；
• 把 PRD 没说的规则补全；
• 把“导出受影响”理解成新增字段；
• 把“影响 PC/H5”理解成两端完全一致；
• 把“需财务复审”理解成完整审批链；
• 写出“流程结束”“终审通过”等未确认终态。

于是你只能继续补 Prompt：

不要编造。
不要写待确认项。
不要写流程结束。
不要假设字段。
不要复制多端用例。

这会变成一个很累的循环：

AI 犯错
→ 人工补一句 Prompt
→ 这次修好了
→ 下次又犯类似错误
→ 再补 Prompt

Skill 要解决的不是“这一次怎么问”，而是：

把稳定的流程、规则、模板和检查项封装起来，让 AI 下次遇到同类任务时自动复用。

Prompt 是临时指令。
Skill 是可复用能力。
Skill Creator 的价值，就是把经验从 Prompt 提升到 Skill。

---

二、主流工具给我们的启发：Skill 是一个“小型工作系统”

从 Codex 和 Claude Code 的思路看，Skill 通常不只是几句提示词。

一个更成熟的 Skill，至少应该包含这几类内容：

skill-name/
├── SKILL.md
├── references/
├── scripts/
├── assets/
└── examples/

其中：

内容	作用
SKILL.md	描述 Skill 的触发场景、工作流程、规则和输出格式
references/	放规则文档、流程说明、业务知识、模板说明
scripts/	放可执行脚本，例如格式检查、文件转换、数据校验
assets/	放模板、样例文件、图表资源
examples/	放输入输出样例，用于测试 Skill 是否稳定

也就是说，Skill 不是一个“更长的 Prompt”。

它更像一个轻量级工作包。

对于测试工程师来说，一个好的测试 Skill 不应该只是：

帮我生成测试用例。

而应该包含：

• 需求评审规则；
• 测试点设计流程；
• 用例质量规则；
• 待确认项处理规则；
• 输出模板；
• 自检清单；
• 示例 PRD；
• 示例输出；
• 失败样例；
• 修正策略。

这才是真正可复用的能力。

---

三、Skill Creator 应该怎么用？

我建议把 Skill Creator 当成一个“技能产品经理”，而不是简单的文件生成器。

一个比较稳的流程是：

Create：先生成 Skill 初稿
Eval：用真实样例测试 Skill
Improve：根据失败结果修改 Skill
Benchmark：用多组样例看稳定性

这四步非常重要。

很多人只做了第一步：

Create：生成一个 SKILL.md。

然后就觉得 Skill 做完了。

但这其实只是开始。

真正决定 Skill 质量的是后面三步：

• 它在真实 PRD 上会不会乱推断？
• 它会不会误触发？
• 它会不会输出过长被截断？
• 它会不会把待确认内容写成正式用例？
• 它会不会忽略自检？
• 它能不能在不同需求上稳定工作？

所以我更推荐这样的工作方式：

不要问：能不能帮我生成一个 Skill？
而要问：能不能帮我设计、测试、改进一个 Skill？

这才是 Skill Creator 的正确打开方式。

---

四、一个真实例子：把测试用例生成拆成 3 个 Skill

前面我用 OpenClaw 跑过一个完整测试流程：

输入 PRD
→ 生成需求评审问题
→ 收敛评审问题
→ 生成测试点
→ 测试点收敛
→ 可入库用例筛选
→ 正式用例生成
→ 用例自检
→ 输出修正版用例

一开始我想把它做成一个大 Skill。

但实践后发现，一个 Skill 包含 8 个步骤太重了。

问题主要有三个：

1. 输出太长，容易截断；
2. 中间需要人工纠偏，不适合一口气跑完；
3. 每个阶段的交付物不同，放在一起反而不清晰。

所以最终我把它拆成了 3 个 Skill：

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

分别对应：

Skill	负责内容	输出
sqa-prd-review	需求评审问题生成与收敛	评审问题、待确认问题、优先提问
sqa-test-design	测试点设计、收敛、可入库筛选	测试点矩阵、核心已确认、核心待确认
sqa-test-case-gen	正式用例生成、自检、修正	正式用例、待确认清单、自检报告

这比一个大而全的 Skill 更适合落地。

因为真实测试工作本来也是分阶段的：

先评审需求
再设计测试点
最后生成和评审用例

Skill 的边界应该贴近真实工作，而不是为了“一步到位”强行塞在一起。

---

五、Skill Creator 第一步：先说清楚它要解决什么问题

在让 Skill Creator 生成 Skill 之前，最好先写清楚 5 件事：

1. 这个 Skill 解决什么问题？
2. 它什么时候触发？
3. 它什么时候不触发？
4. 它的输入和输出是什么？
5. 它有哪些红线？

以 sqa-prd-review 为例，不要只说：

帮我做一个需求评审 Skill。

更好的描述是：

请帮我设计一个 SQA PRD Review Skill。

目标：
当用户提供 PRD、需求说明、会议纪要或产品规则时，帮助测试工程师生成需求评审问题，并对问题进行收敛。

触发场景：
- 用户要求需求评审；
- 用户要求生成评审问题；
- 用户要求整理待确认项；
- 用户要求识别上线风险。

不触发场景：
- 没有具体 PRD 或需求文本；
- 用户只是询问测试方法论；
- 用户只是要求润色文字。

输出：
- 需求摘要；
- 按维度分类的问题表；
- 核心必须确认问题；
- 建议确认问题；
- 扩展风险；
- 评审会上优先提问的 5 个问题。

红线：
- 不要替产品回答问题；
- 不要编造 PRD 中没有的规则；
- 不要直接生成测试用例；
- 不明确内容必须标记为待确认。

这样生成出来的 Skill 会比一句话描述稳定得多。

---

六、Skill Creator 第二步：触发条件要收紧

很多 Skill 不稳定，不是因为执行流程写得差，而是触发条件太宽。

比如：

当用户说“帮我分析这个需求”时触发。

这个触发条件看似合理，但实际有风险。

因为“分析需求”可能有很多含义：

• 产品视角分析；
• 技术实现分析；
• 测试评审分析；
• 排期分析；
• 竞品分析；
• 文案润色。

如果 Skill 自动触发，可能做错方向。

更稳的写法是：

当用户提供具体 PRD/需求文本，并明确要求“需求评审”“评审问题”“待确认项”“测试风险”时触发。

如果用户提供需求文本但未明确意图，先询问：
“你希望我做需求评审、测试点设计，还是直接生成用例？”

这就是“确认式触发”。

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

因为测试输出一旦进入文档或平台，影响会比较大。
宁可多问一句，也不要自动跑错流程。

---

七、Skill Creator 第三步：红线比流程更重要

很多 Skill 写得很长，流程很完整，但缺少红线。

比如：

1. 阅读 PRD；
2. 生成测试点；
3. 生成测试用例；
4. 输出表格。

看起来没问题，但它没有告诉 AI 什么不能做。

对于测试 Skill 来说，红线非常关键。

我建议每个测试 Skill 都写这些红线：

## 核心红线

1. 不要编造 PRD 中没有的规则。
2. 不明确内容必须标记为“待确认”。
3. 不要用行业常识填补 PRD 空白。
4. 待确认内容不得生成正式测试用例。
5. 不要写“流程结束”“终审”“已完成”等未确认终态。
6. 不要把“导出受影响”理解成“新增字段”。
7. 不要把“影响 PC/H5”理解成“两端完全一致”。
8. 不要推断 UI 交互方式，例如页面跳转、弹窗、Toast。
9. 预期结果必须可验证。
10. 生成正式用例后必须自检。

流程决定 AI 做什么。
红线决定 AI 不该做什么。

而在测试工作里，“不该做什么”往往比“做什么”更重要。

---

八、Skill Creator 第四步：输出模板要短而稳定

一个常见错误是，在 Skill 里写太多输出模板。

比如一个 Skill 同时要求输出：

• 需求摘要；
• 问题表；
• 测试点表；
• 收敛表；
• 用例表；
• 自检报告；
• 修正版用例；
• 统计表；
• 风险表；
• 总结表。

这会导致输出非常长，也容易截断。

更好的方式是按 Skill 边界拆分输出。

比如 sqa-prd-review 只输出：

## 一、需求摘要

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

## 二、评审问题表

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

## 三、问题收敛

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

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

sqa-test-design 只输出：

## 一、测试点设计

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

## 二、测试点收敛

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

## 三、可入库用例筛选

sqa-test-case-gen 只输出：

## 一、正式测试用例

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

## 二、用例自检报告

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

## 四、待确认问题清单

一个 Skill 的输出越稳定，后续越容易复制到 Excel、测试平台、文档或周报里。

---

九、Skill Creator 第五步：必须准备测试样例

一个 Skill 能不能用，不是看它写得多漂亮，而是看它能不能通过测试样例。

所以 Skill Creator 生成 Skill 后，下一步不是直接安装，而是准备测试样例。

以需求评审 Skill 为例，至少准备 3 类样例：

样例 1：规则明确型需求

金额 ≤5000 直属上级审批；
5000<金额≤20000 部门负责人审批；
金额>20000 财务复审。

验证点：

• 能识别 5000 属于第一档；
• 能识别 20000 属于第二档；
• 不把边界误判为待确认。

样例 2：规则缺失型需求

金额>20000时需财务复审；
导出受影响；
影响PC和H5。

验证点：

• 不推断完整审批链；
• 不推断导出字段；
• 不推断两端一致。

样例 3：待确认项型需求

批量导入是否支持，待产品确认。

验证点：

• 不生成批量导入正式用例；
• 将其放入待确认清单。

只有这些样例都通过，Skill 才算初步可用。

---

十、Skill Creator 第六步：Eval 比 Create 更重要

创建 Skill 只是第一步。

更关键的是 Eval。

Eval 要看什么？

我建议从 8 个维度检查：

检查项	判断标准
是否误触发	没有具体 PRD 时是否乱启动
是否漏触发	明确需求评审时是否启动
是否编造规则	是否补 PRD 没写的内容
是否处理待确认	是否把待确认项单独列出
是否输出过长	是否能分批输出
是否表格稳定	字段是否固定
是否有自检	生成用例后是否主动自检
是否能接受人工纠偏	用户纠偏后是否能修正结果

比如一个测试 Skill 如果在 Eval 中出现：

PRD：导出受影响。
输出：导出文件包含审批状态字段。

这就说明 Skill 需要 Improve。

应该补一条规则：

“导出受影响”不等于新增字段；字段清单未确认时，只能做基础导出回归。

这就是 Eval 的意义：

不是证明 Skill 没问题，而是逼出 Skill 的问题。

---

十一、Skill Creator 第七步：Improve 要基于失败样例

很多人优化 Skill 时，喜欢凭感觉改。

比如：

再强调一下不要编造。
再强调一下要谨慎。
再强调一下输出准确。

这种改法效果有限。

更好的方式是基于失败样例改。

例如失败样例是：

PRD 只写“影响 PC 和 H5”，Skill 输出“H5 状态与 PC 端一致”。

那就应该新增规则：

## 多端规则

如果 PRD 只写影响 PC/H5，不得默认两端完全一致。

错误：
- H5 状态展示与 PC 端一致。

正确：
- H5 状态正确展示为审批中、草稿、已驳回。
- PC/H5 是否存在端差异，进入待确认清单。

再比如失败样例是：

Skill 写了页面跳转。

那就新增规则：

## UI 交互规则

除非 PRD 或设计稿明确，不得写页面跳转、弹窗、Toast 等交互方式。
应验证最终状态或数据结果。

这种 Improve 才是真正有效的。

---

十二、Skill Creator 第八步：Benchmark 看稳定性

如果只是一个样例跑通，不代表 Skill 稳定。

Benchmark 要做的是：

用多组不同类型的需求，验证 Skill 是否都能稳定输出。

比如测试类 Skill 可以准备 5 组需求：

样例	验证点
金额审批规则	边界值、审批链、状态流转
权限控制需求	角色、越权、数据可见性
导出报表需求	字段、格式、权限、数量一致
多端改造需求	PC/H5/iOS/Android 端收敛
AI 功能需求	模型输出、工具调用、失败兜底、自检

每组都跑一遍，看它是否稳定满足：

• 不编造；
• 不乱推断；
• 能分清已确认和待确认；
• 能输出固定表格；
• 能做收敛；
• 能自检。

如果 5 组都表现稳定，这个 Skill 才适合正式安装或团队内推广。

---

十三、一个适合测试工程师的 Skill Creator 流程

我建议测试工程师用 Skill Creator 时，按这个流程走：

第一步：写清楚任务边界
第二步：生成 Skill 初稿
第三步：准备 3～5 个真实样例
第四步：执行 Eval
第五步：记录失败样例
第六步：把失败样例转成规则
第七步：Improve Skill
第八步：再次 Eval
第九步：多样例 Benchmark
第十步：再考虑安装或推广

这比“生成一个 SKILL.md 就完事”靠谱得多。

---

十四、一个可直接复制的 Skill Creator 提示词

下面是我建议的 Skill Creator Prompt：

请帮我设计一个用于测试工程师的 Skill。

Skill 名称：
sqa-prd-review

目标：
当用户提供 PRD、需求说明或会议纪要时，帮助测试工程师生成需求评审问题，并对问题进行收敛。

触发场景：
1. 用户提供具体 PRD/需求文本；
2. 用户明确要求需求评审、评审问题、待确认项、测试风险分析。

不触发场景：
1. 用户没有提供具体需求文本；
2. 用户只是询问测试方法论；
3. 用户只是润色文档或翻译。

执行流程：
1. 提取需求摘要；
2. 按业务规则、边界值、权限角色、状态流转、异常流程、数据一致性、多端、导出、兼容回归分类生成评审问题；
3. 每个问题说明为什么需要确认和不确认的风险；
4. 合并重复问题；
5. 输出核心必须确认、建议确认、扩展风险；
6. 输出评审会上优先提问的 5 个问题。

质量红线：
1. 不要替产品回答问题；
2. 不要编造 PRD 中没有的规则；
3. 不明确内容必须标记为待确认；
4. 不要直接生成测试用例；
5. PRD 只写“需某节点审批”时，不得推断完整审批链；
6. PRD 只写“导出受影响”时，不得推断字段清单；
7. PRD 只写“影响 PC/H5”时，不得推断两端一致；
8. PRD 未定义终态时，不得写流程结束、终审、已完成。

输出格式：
一、需求摘要；
二、评审问题表；
三、评审问题收敛；
四、评审会上优先提问的 5 个问题。

请输出：
1. SKILL.md 初稿；
2. 触发测试样例；
3. 不触发测试样例；
4. Eval 检查清单；
5. 后续 Improve 建议。

这个 Prompt 的重点不是让 Skill Creator“写得完整”，而是让它同时输出：

• Skill 初稿；
• 触发样例；
• 不触发样例；
• Eval 清单；
• Improve 建议。

这样生成出来的 Skill 更容易进入迭代。

---

十五、Skill Creator 最容易犯的 5 个误区

误区 1：把 Skill 当成超长 Prompt

Skill 不是越长越好。

太长会挤占上下文，也会让模型抓不住重点。

更好的方式是：

Skill 写流程和红线；
references 放详细规则；
examples 放样例；
scripts 放确定性工具。

---

误区 2：一个 Skill 想包所有流程

比如一个 Skill 同时做：

需求评审
→ 测试点
→ 用例
→ 自动入库
→ 报告
→ 发消息

这很容易失控。

更好的方式是拆分：

需求评审 Skill
测试设计 Skill
用例生成 Skill
报告生成 Skill

---

误区 3：只写触发场景，不写不触发场景

不触发场景很重要。

否则 Skill 可能在不该工作的时候乱启动。

例如：

没有具体 PRD 时，不触发。
用户只是询问方法论时，不触发。
用户只是润色文字时，不触发。

---

误区 4：没有失败样例

没有失败样例，就不知道 Skill 会在哪里出错。

建议每个 Skill 至少准备：

• 2 个正向样例；
• 2 个边界样例；
• 2 个反向样例；
• 1 个容易误触发样例。

---

误区 5：没有自检

测试类 Skill 尤其需要自检。

因为它输出的内容可能进入测试平台或评审文档。

没有自检，AI 的合理推断很容易变成正式用例。

---

十六、小结

Skill Creator 不只是一个帮你生成 SKILL.md 的工具。

它真正适合做的是：

把一次性的工作经验，变成可复用、可评估、可改进的 Agent 能力。

对测试工程师来说，它的价值尤其明显。

因为测试工作里有大量可以沉淀的经验：

• 需求评审方法；
• 测试点设计规则；
• 边界值规则；
• 状态机规则；
• 权限测试规则；
• 多端收敛策略；
• 导出测试规则；
• 用例自检规则。

这些经验如果只存在测试工程师脑子里，AI 每次都要重新猜。

如果沉淀成 Skill，AI 才能稳定复用。

所以，使用 Skill Creator 时，不要只停留在：

帮我生成一个 Skill。

更好的目标是：

帮我设计一个能被测试、能被改进、能稳定复用的 Skill。

一句话总结：

Prompt 让 AI 完成一次任务，Skill 让 AI 复用一套能力。
Skill Creator 的价值，不是生成文件，而是帮助我们把经验产品化。