)
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_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 登录后创建一个新 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_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_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. 核心必须确认问题控制在 57 个。 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. 测试点收敛 分为核心已确认、核心待确认、扩展风险。核心已确认建议 1015 条。 ### 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-20250514Model ID 按你实际要用的填TaoToken 支持的模型列表可以在模型对话页确认https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。三件套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 - 基于核心已确认测试点生成正式用例必须自检并输出修正版。 使用原则先评审再测试点再用例不跨步生成。 EOF4. 验证请求与成功结果对照配置改完后先做一次最小连通性验证确认 TaoToken 通道是通的。用 curl 直接打一次 APIcurl -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.mdcat 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 内容】观察输出对照这张检查表检查项合格标准实际结果是否只输出评审问题是是否没有生成用例是是否识别批量导入待确认是是否识别审批终态缺失是是否识别导出字段待确认是是否输出优先 5 问是第一段通过后继续第二段验证请参考当前工作区的 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.md5. 常见报错排查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_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。注意 Key 只在创建时完整显示一次。报错二local proxy failed典型输出Error: local proxy failed: dial tcp 127.0.0.1:7890: connect: connection refused这个报错说明你的客户端在尝试走本地代理端口但那个端口没有服务在监听。检查你的配置文件里有没有残留的proxy字段或者环境变量里有没有HTTP_PROXY/HTTPS_PROXYenv | grep -i proxy如果有先 unsetunset 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_urlgrep -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 Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。它适合需要持续调用、对额度有预期的场景。日常验证和调试用按量通道就够了。接入文档在这里https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有各客户端的详细配置示例。如果你用 Claude Code对应的接入说明在https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaude_codeutm_campaignrewrite 。最后说一个实际经验Skill 的价值不在“跑通一次”而在“稳定复用”。我建议至少用 3 个不同的 PRD 样例验证过确认触发稳定、输出结构固定、不再明显过度推断之后再考虑正式安装到全局 Skill 目录。在那之前本地实验目录就是你的安全沙盒改坏了直接删掉重建成本很低。