把这 3 个测试 Skill 装进 OpenClaw：本地目录、安装、验证与排错（TaoToken 统一 Key 通道版）

1. 为什么要把测试 Skill 放进 OpenClaw 本地目录

OpenClaw 的 Skill 机制本质上是一套“按需加载的提示词模块”。你可以把它理解成给 AI 助手准备的工具箱：平时工具箱合着，只有当你的输入命中某个 Skill 的触发条件时，OpenClaw 才会把对应的 SKILL.md 读进来，作为当前对话的上下文约束。这个设计的好处是显而易见的——不用把所有规则一次性塞进系统提示词，既省 token，又避免不同任务之间的规则互相干扰。

但很多人第一次接触 OpenClaw Skill 时会卡在同一个地方：Skill 到底放哪、怎么让 OpenClaw 知道它的存在、写完怎么验证它真的生效了。尤其是当你想先做本地实验、不想一上来就污染全局 Skill 目录时，这套链路就更容易出问题。我这次要装的 3 个测试 Skill 分别是 sqa-prd-review（需求评审问题生成与收敛）、sqa-test-design（测试点设计与可入库筛选）、sqa-test-case-gen（正式用例生成与自检）。它们串起来是一条完整的测试设计流水线：先评审、再设计测试点、最后生成用例。

这篇的目标不是教你写一个完美的 Skill，而是带你走完“本地目录 → 安装 → 验证 → 排错”这条最小可用链路。同时我会把 OpenClaw 的 endpoint 和鉴权统一改到 TaoToken 通道，这样你后续不管换哪个模型，Key 和 Base URL 都不用反复改。如果你之前被多个平台的 Key 管理搞得很烦，这一步会省不少事。

适合谁看：正在用 OpenClaw 做测试工作流、想先把 Skill 跑通再考虑全局安装的测试工程师；以及任何想把本地 Skill 目录加载机制搞清楚的人。下面所有命令都可以直接复制执行，目录结构、SKILL.md 内容、验证话术我都会给全。

2. TaoToken 统一 Key 通道的前置准备

在装 Skill 之前，先把 OpenClaw 的模型通道理顺。OpenClaw 默认可能指向某个单一模型服务，但测试场景里你经常需要在不同模型之间切换——评审用推理强的，用例生成用输出稳定的。如果每个模型都单独配 Key，配置文件会变得很难维护。TaoToken 的作用就是提供一个统一的 API 入口，你只需要一个 Key，就能在它支持的模型列表里切换。

先拿到你的 Key。访问 API Keys 管理页：https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite ，登录后创建一个新 Key，复制保存。注意这个 Key 只在创建时完整显示一次，丢了就得重建。

然后确认你的 OpenClaw 版本支持自定义 endpoint。大多数近期版本在配置文件里都有base_url或endpoint字段。TaoToken 的 API 地址是 https://taotoken.net/api ，注意这里不加任何 UTM 参数，直接写这个地址就行。如果你用的是 OpenAI 兼容格式的客户端，Base URL 填https://taotoken.net/api/v1即可。

这里有个容易踩的坑：有些人会把官网地址 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 直接填进 base_url，这是错的。官网是给人看的页面，API 地址才是给程序调用的。两者不要混。

配置前建议先备份原配置：

cp ~/.openclaw/config.json ~/.openclaw/config.json.bak

如果你不确定配置文件在哪，可以先跑：

openclaw config path

它会打印当前生效的配置文件路径。拿到路径后再改，避免改错文件。Key 的管理建议单独放一个环境变量，不要硬编码进配置文件，后面我会给具体写法。

3. 可复制的目录结构与安装配置

这一步是核心。我建议先建一个独立的实验目录，不要直接往 OpenClaw 全局 Skill 目录里塞。原因很简单：Skill 还没验证稳定，触发条件可能过宽，输出可能过长，直接进全局会影响你日常使用。等本地验证通过再考虑正式安装。

先建实验工作区：

mkdir -p ~/openclaw-sqa-lab/{rules,examples,outputs,skills} 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 . -maxdepth 2 -type d | sort

预期输出：

. ./examples ./outputs ./rules ./skills ./skills/sqa-prd-review ./skills/sqa-test-case-gen ./skills/sqa-test-design

接下来写第一个 Skill 文件skills/sqa-prd-review/SKILL.md。这个 Skill 只负责需求评审，不生成测试点和用例：

cat > skills/sqa-prd-review/SKILL.md <<'EOF' # SQA PRD Review Skill ## 名称 sqa-prd-review ## 作用 当用户提供 PRD、需求说明或产品规则，并要求需求评审、评审问题生成、待确认项整理时，使用本 Skill。 ## 不适用场景 - 未提供具体 PRD 文本，不触发。 - 仅询问测试方法论，不触发。 - 仅要求润色、翻译普通文本，不触发。 ## 工作原则 1. 不替产品回答问题。 2. 不编造 PRD 中没有的规则。 3. 不明确内容必须标记为“待确认”。 4. 只提出影响测试范围、用例设计、上线风险的问题。 5. 不直接生成测试点或测试用例。 6. 核心必须确认问题控制在 5～7 个。 7. 输出必须表格化。 ## 参考规则 - rules/testcase-quality-rules.md - rules/state-machine-rules.md - rules/export-test-rules.md - rules/multi-platform-rules.md ## 执行流程 ### 1. 需求摘要 提取需求名称、核心变更、涉及端/系统、关键规则、明确待确认项。 ### 2. 生成评审问题 按业务规则、边界值、权限角色、状态流转、异常流程、数据一致性、多端兼容、导出影响、历史数据、通知影响等维度生成问题。每个问题必须说明为什么需要确认、不确认的风险。 ### 3. 问题收敛 分为核心必须确认、建议确认、扩展风险三类。 ## 输出格式 ### 一、需求摘要 ### 二、按维度分类的问题表 ### 三、评审问题收敛 ### 四、评审会上优先提问的 5 个问题 ## 输出长度控制 评审问题超过 15 条时分批输出，每批结束提示“本批输出完毕，回复继续输出下一批。” EOF

第二个 Skillskills/sqa-test-design/SKILL.md，负责测试点设计和可入库筛选：

cat > skills/sqa-test-design/SKILL.md <<'EOF' # SQA Test Design Skill ## 名称 sqa-test-design ## 作用 当用户已提供 PRD、评审问题或确认后的需求规则，并要求生成测试点、测试点收敛或可入库筛选时，使用本 Skill。 ## 不适用场景 - 无具体 PRD 或确认规则，不执行。 - 要求直接生成正式用例时，提示先完成测试点设计。 ## 工作原则 1. 只生成测试点，不直接生成正式用例。 2. 不明确内容标记“依赖确认=是”。 3. 不把“业务重要”等同于“可生成正式用例”。 4. PRD 已明确规则进入“核心已确认”。 5. PRD 未明确但业务重要进入“核心待确认”。 6. 范围外或非功能类进入“扩展风险”。 7. 测试点超过 20 条时分批输出。 ## 参考规则 - 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. 测试点设计 输出字段：编号、测试维度、测试点、来源、优先级、是否依赖确认、说明。 ### 2. 测试点收敛 分为核心已确认、核心待确认、扩展风险。核心已确认建议 10～15 条。 ### 3. 可入库用例筛选 逐条判断核心已确认测试点是否可生成正式用例，判断项包括规则是否明确、预期是否可验证、是否含待确认内容、是否存在 AI 推断。 ## 核心红线 1. PRD 使用 ≤、<、> 明确边界时，识别边界归属。 2. PRD 未说明金额精度时，不默认小数。 3. PRD 只写“需财务复审”时，只生成“包含财务复审节点”测试点。 4. PRD 未说明终态时，不生成审批通过终态测试点。 5. PRD 只写“导出受影响”时，只生成导出基础回归。 6. PRD 只写“影响 PC/H5”时，不推断两端完全一致。 7. PRD 标注“待确认”时，不进入核心已确认。 ## 输出长度控制 测试点超过 20 条时分批输出。 EOF

第三个 Skillskills/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。 ## 不适用场景 无“核心已确认”或可入库测试点时，不直接生成正式用例。 ## 工作原则 1. 只基于“核心已确认”测试点生成正式用例。 2. 不为“核心待确认”和“扩展风险”生成正式用例。 3. 待确认内容单独输出为清单。 4. 用例步骤必须可执行，预期结果必须可验证。 5. 不补充 PRD 中没有的规则。 6. 不写“流程结束”“终审”“已完成”等未确认结论。 7. 多端用例要收敛，不机械复制。 8. 正式用例生成后必须执行自检并输出修正版。 ## 参考规则 - 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. 正式测试用例生成 输出字段：用例编号、用例标题、前置条件、操作步骤、预期结果、优先级、来源测试点。 ### 2. 用例自检 检查是否把待确认问题写成确定性用例、是否存在 PRD 外预期、是否出现未确认结论、PC/H5 是否机械重复、预期是否可验证、是否遗漏待确认清单、是否存在需求外编造、是否存在可合并重复用例。 ### 3. 修正输出 输出修正版用例、数量统计、P0/P1/P2 数量、仍需确认问题清单、是否可进入人工评审。 ## 核心红线 | 场景 | 禁止写法 | 正确写法 | |---|---|---| | 审批终态未确认 | 流程结束、终审通过 | 标记为待确认 | | 财务复审链未确认 | 部门负责人+财务复审两层 | 仅验证包含财务复审节点 | | 导出字段未确认 | 包含审批状态、审批人字段 | 导出可用、记录数量一致 | | PC/H5 一致性未确认 | 状态与 PC 端一致 | 本端状态正确展示 | | 待确认功能 | 生成正式用例 | 输出到待确认清单 | ## 输出长度控制 正式用例超过 10 条时分批输出。 EOF

现在把 OpenClaw 的 endpoint 和鉴权改到 TaoToken。配置文件通常是 JSON 格式，找到model或provider相关字段，改成：

{ "provider": { "base_url": "https://taotoken.net/api/v1", "api_key": "${TAOTOKEN_API_KEY}", "model": "claude-sonnet-4-20250514" } }

注意api_key用环境变量引用，不要明文写死。然后在 shell 里导出：

export TAOTOKEN_API_KEY="你的Key"

如果你用的是 TOML 格式配置，对应写法：

[provider] base_url = "https://taotoken.net/api/v1" api_key = "${TAOTOKEN_API_KEY}" model = "claude-sonnet-4-20250514"

Model ID 按你实际要用的填，TaoToken 支持的模型列表可以在模型对话页确认：https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite 。三件套（Base URL + Key + Model ID）缺一不可，少任何一个都会在验证阶段报错。

最后在AGENTS.md里追加 Skill 索引，让 OpenClaw 知道这 3 个 Skill 的存在：

cat >> AGENTS.md <<'EOF' ## 本地测试 Skill 草案 1. skills/sqa-prd-review/SKILL.md - 需求评审问题生成和收敛，不生成测试点和用例。 2. skills/sqa-test-design/SKILL.md - 测试点设计、收敛和可入库筛选，不直接生成正式用例。 3. skills/sqa-test-case-gen/SKILL.md - 基于核心已确认测试点生成正式用例，必须自检并输出修正版。 使用原则：先评审，再测试点，再用例；不跨步生成。 EOF

4. 验证请求与成功结果对照

配置改完后，先做一次最小连通性验证，确认 TaoToken 通道是通的。用 curl 直接打一次 API：

curl -s https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer $TAOTOKEN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "claude-sonnet-4-20250514", "messages": [{"role": "user", "content": "回复 OK 两个字母即可"}], "max_tokens": 10 }'

成功的话你会看到类似这样的返回：

{ "id": "chatcmpl-xxx", "object": "chat.completion", "choices": [ { "index": 0, "message": {"role": "assistant", "content": "OK"}, "finish_reason": "stop" } ] }

如果这一步就报 401，说明 Key 有问题，先别往下走。如果报local proxy failed，说明 base_url 写错了或者网络层有问题。这两个错误后面排错章节会细讲。

通道通了之后，准备一个验证用 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 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 内容】

观察输出，对照这张检查表：

第一段通过后，继续第二段验证：

请参考当前工作区的 skills/sqa-test-design/SKILL.md，基于上一步评审结果执行测试点设计、测试点收敛和可入库用例筛选。 要求： 1. 不要生成正式测试用例； 2. 每个测试点必须标记是否依赖确认； 3. 将测试点分为核心已确认、核心待确认、扩展风险； 4. 对可入库测试点逐条说明是否可生成正式用例； 5. 不要把“需财务复审”推断成完整审批链； 6. 不要把“导出受影响”推断成字段明细； 7. 不要把“影响 PC/H5”推断成两端完全一致。

重点看它有没有正确识别金额边界：5000 属于第一档，20000 属于第二档，>20000 只能验证“包含财务复审节点”。如果它写出“部门负责人审批后进入财务复审”，就是过度推断了。

第三段验证：

请参考当前工作区的 skills/sqa-test-case-gen/SKILL.md，基于上一步“核心已确认”测试点生成正式测试用例，并执行用例自检和修正版输出。 要求： 1. 只基于核心已确认测试点生成正式用例； 2. 不为核心待确认和扩展风险生成用例； 3. 不写审批通过后的“流程结束”“终审”“已完成”； 4. 不生成导出字段明细校验； 5. 不生成批量导入正式用例； 6. 金额 >20000 只验证包含财务复审节点； 7. 生成后必须自检。

三段都跑通，说明 Skill 加载链路和 TaoToken 通道都是正常的。把每段输出保存到outputs/目录，方便后续对比版本变化：

# 手动把 Dashboard 输出粘贴保存 # outputs/01-prd-review-output.md # outputs/02-test-design-output.md # outputs/03-case-gen-output.md

5. 常见报错排查：401、local proxy failed、reading choices

这一节把验证过程中最容易撞上的几个报错拆开讲。每个报错我都给触发条件和修复步骤，你对照自己的终端输出定位。

报错一：401 Unauthorized

典型返回：

{"error": {"message": "Invalid API key", "type": "authentication_error"}}

触发条件通常是三种：Key 没导出到当前 shell、Key 复制时带了空格、Key 已失效。先确认环境变量：

echo $TAOTOKEN_API_KEY | head -c 8

如果输出为空，说明没导出。重新执行export TAOTOKEN_API_KEY="你的Key"。如果输出有值但还是 401，去 API Keys 页面重新生成一个：https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite 。注意 Key 只在创建时完整显示一次。

报错二：local proxy failed

典型输出：

Error: local proxy failed: dial tcp 127.0.0.1:7890: connect: connection refused

这个报错说明你的客户端在尝试走本地代理端口，但那个端口没有服务在监听。检查你的配置文件里有没有残留的proxy字段，或者环境变量里有没有HTTP_PROXY/HTTPS_PROXY：

env | grep -i proxy

如果有，先 unset：

unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

然后确认 base_url 写的是https://taotoken.net/api/v1，不是官网地址。官网地址填进 base_url 也会导致连接异常。

报错三：reading choices 相关错误

典型输出：

Error: failed to parse response: reading 'choices': unexpected end of JSON input

这个报错说明客户端收到了响应，但响应体不是预期的 JSON 结构。常见原因是 base_url 少了/v1后缀，请求打到了错误的路径，返回了 HTML 页面而不是 JSON。检查你的 base_url：

grep -r "base_url" ~/.openclaw/config.json

正确值应该是https://taotoken.net/api/v1。如果写成了https://taotoken.net/api，补上/v1。另外确认 model ID 拼写正确，错误的 model ID 有时也会返回非标准响应。

报错四：OAuth 相关错误

如果你用的是 Claude Code 或 Codex 这类带 OAuth 流程的客户端，可能会看到：

Error: OAuth token expired, please re-authenticate

这类客户端如果同时配了 OAuth 和 API Key，会优先走 OAuth。解决办法是在配置里显式指定用 API Key 模式，或者把 OAuth 相关字段清掉。以 Codex 的auth.json为例，确认里面是：

{ "api_key": "${TAOTOKEN_API_KEY}", "base_url": "https://taotoken.net/api/v1" }

而不是残留的 OAuth token 字段。如果你用 CC Switch 或 Cline MCP 管理多个通道，记得在切换后确认三件套（Base URL + Key + Model ID）都指向 TaoToken，不要只改了其中一项。

报错五：Skill 不触发

如果 OpenClaw 完全没有读取你的 SKILL.md，先别纠结自动加载机制。本地验证阶段直接手工加载：

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

把输出复制到 Dashboard 里，再输入 PRD。等 Skill 稳定后再考虑正式安装。如果自动加载时好时坏，检查AGENTS.md里的索引路径是否和实际目录一致，路径写错会导致 OpenClaw 找不到文件。

报错六：输出被截断

测试点超过 40 条时经常出现。在对话里追加：

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

如果已经截断在 TP-032 附近，追加：

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

这也是为什么我在每个 SKILL.md 里都写了“输出长度控制”段落——提前约束比事后补救有效。

6. 把 Skill 接入 TaoToken 后的持续使用建议

三段验证跑通之后，你手里就有了一套可用的本地测试 Skill 流水线。接下来要考虑的是怎么让它稳定复用，而不是跑通一次就放着。

第一件事是建立版本对比习惯。每次修改 SKILL.md 或 rules 目录后，重新跑一遍三段验证，把输出存到outputs/下带版本号的文件里。比如01-prd-review-output-v2.md。这样你能直观看到规则调整后输出有没有变好。我试过不存过程直接改 Skill，结果改了三版之后完全不记得哪版更好，只能重跑，很浪费时间。

第二件事是把纠偏内容沉淀回 rules 目录。验证过程中如果发现 AI 又过度推断了，比如把“需财务复审”写成完整审批链，不要只在对话里纠正，要把这条规则写进rules/state-machine-rules.md。下次加载 Skill 时规则会自动生效。Skill 负责流程，rules 负责判断标准，这个分工能让维护成本低很多。

第三件事是控制触发条件。测试类 Skill 最容易出现的问题是“一看到 PRD 就自动跑完整流程”。如果你希望更可控，可以在 SKILL.md 里加一段确认式触发：

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

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

第四件事是长期编码和 Agent 场景的通道选择。如果你不只是做测试 Skill 验证，还要跑长期的编码任务或 Agent 工作流，可以了解一下 Coding Plan：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite 。它适合需要持续调用、对额度有预期的场景。日常验证和调试用按量通道就够了。

接入文档在这里：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite ，里面有各客户端的详细配置示例。如果你用 Claude Code，对应的接入说明在：https://taotoken.net/claude-code-anthropic?utm_source=taotoken_aicg_blog_end&utm_content=claude_code&utm_campaign=rewrite 。

最后说一个实际经验：Skill 的价值不在“跑通一次”，而在“稳定复用”。我建议至少用 3 个不同的 PRD 样例验证过，确认触发稳定、输出结构固定、不再明显过度推断之后，再考虑正式安装到全局 Skill 目录。在那之前，本地实验目录就是你的安全沙盒，改坏了直接删掉重建，成本很低。