1. 为什么要在 Cursor 里做测试用例生成 Skill需求评审前最尴尬的场景是开发说这个逻辑很简单测试说那用例呢然后大家对着空白文档沉默。测试用例这件事难的不是写而是每次都要重新组织格式、重新想边界、重新对齐评审口径。一个登录需求正向、逆向、异常、并发四类场景手写两小时评审时还被指出漏了密码错误次数锁定后的解锁路径。Cursor 的 Agent Skills 正好能治这个病。Skill 的本质是一份SKILL.md它把什么时候触发、按什么规则干活、输出成什么结构固化下来AI 每次调用都按同一套标准执行不用你反复贴提示词。我试过把资深测试的用例模板塞进 Skill之后在 Chat 里输入/testcase-generator加需求文档三种格式的用例直接落盘。这篇面向的是需要快速产出可评审用例的研发和测试同学。所谓可评审不是用例数量多而是每条用例都有编号、前置条件、步骤、预期结果、优先级评审会上能逐条过。下面从零开始交付可直接复制的SKILL.md骨架、Cursor 配置片段以及用示例需求触发 Skill 并校验输出的完整动作。2. TaoToken 前置给 Skill 接一个稳定的模型出口Skill 本身只是规则文件真正干活的是背后的模型。Cursor 内置模型在长文档解析时偶尔会截断尤其是需求文档超过 5000 字、要求同时输出 Markdown/JSON/XLSX 三种结构时输出容易半途而废。我的做法是把模型出口切到 TaoToken它在 OpenAI 兼容协议上做得比较干净Cursor 里改个 Base URL 就能用。先到控制台建一个 API Key地址是https://taotoken.net/api-keys注意这个链接带了 utm 参数方便你从这篇直接跳过去。建 Key 的时候选默认项目即可权限给 Chat Completions 就够Skill 生成用例不需要额外能力。拿到 Key 之后Cursor 的配置入口在Settings - Models - OpenAI API Key。如果你用的是 Cursor 的 OpenAI 兼容模式填两个字段配置项值Base URLhttps://taotoken.net/apiAPI Key你刚建的那串sk-开头的 Key注意 Base URL 不要带 utm 参数https://taotoken.net/api就是纯接口地址。填完点 Verify能返回模型列表就说明通了。这一步做完后面 Skill 触发的所有请求都走这个出口长文档解析稳定性会好很多。如果你还想在浏览器里先验证模型对需求文档的理解能力可以打开模型对话页https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite把需求文档粘进去问一句这份需求有哪些边界条件没写清楚先摸清模型的解析水平再决定 Skill 里要不要加约束。3. 可复制的 SKILL.md 骨架与 Cursor 配置Cursor 里新建 Skill 的路径是Settings - Rules, Skills, Subagents - New Skill。点完之后它会开一个 New Chat让你用自然语言描述技能。但更可控的方式是直接手写SKILL.md放到项目的.cursor/skills/testcase-generator/目录下。目录结构长这样.cursor/ └── skills/ └── testcase-generator/ ├── SKILL.md ├── examples/ │ └── case-template.md └── references/ └── boundary-checklist.mdSKILL.md是必需项examples和references是可选的。下面这份骨架可以直接复制我把它拆成 frontmatter 和正文两部分。frontmatter 里的description是触发关键写得越具体AI 越容易在合适的时候调用它。--- name: testcase-generator description: 根据需求文档生成可评审的测试用例覆盖正向、逆向、异常、并发四类场景输出 Markdown、JSON、XLSX 三种格式。当用户提供需求文档、PRD、用户故事或提到生成测试用例用例评审时触发。 --- # 测试用例生成器 ## 触发条件 - 用户提供需求文档.docx/.md/.pdf/.txt或粘贴需求正文 - 用户输入 /testcase-generator 斜杠命令 - 用户提到用例评审覆盖场景 ## 输出要求 必须同时输出三种格式缺一不可 1. Markdown 表格用于评审会逐条过 2. JSON用于导入测试管理平台 3. XLSX用于归档和二次编辑 ## 用例字段规范 每条用例必须包含以下字段不允许省略 - case_id格式 TC-模块-序号如 TC-LOGIN-001 - title一句话描述验证点 - priorityP0/P1/P2 - precondition前置条件 - steps操作步骤编号列表 - expected预期结果 - test_data测试数据 - scene_type正向/逆向/异常/并发 ## 场景覆盖规则 - 正向主流程至少 3 条覆盖正常输入组合 - 逆向非法输入、越权、参数缺失至少 4 条 - 异常网络中断、超时、服务降级至少 3 条 - 并发同一资源竞争、幂等、乐观锁版本冲突至少 2 条 ## 输出格式模板 见 examples/case-template.md严格按模板结构输出。 ## 约束 - 单次输出用例不超过 40 条超出则按模块拆分 - 并发用例必须标注一致性语义幂等/乐观锁/最终一致窗口 - 不确定的需求点在用例末尾用 [待确认] 标注不要编造examples/case-template.md里放你的标准表格结构AI 会照着填。references/boundary-checklist.md放边界检查清单比如空值、超长、特殊字符、并发阈值、时区、编码这些容易漏的点。主文件控制在 500 行以内超出的内容往references里挪避免解析效率下降。配置片段方面如果你想让 Skill 在特定项目里自动生效可以在项目根目录的.cursor/rules里加一条引用{ skills: [ .cursor/skills/testcase-generator/SKILL.md ], autoTrigger: true }autoTrigger设为 true 后只要你在 Chat 里提到需求文档Cursor 会优先尝试调用这个 Skill不用每次手打斜杠命令。4. 用示例需求触发 Skill 并校验输出Skill 建好之后先验证它能不能被正确触发。在 Cursor Chat 里输入/如果下拉列表里出现testcase-generator说明 Skill 已注册成功。这一步没出现的话检查SKILL.md的 frontmatter 有没有语法错误name字段不能有空格。准备一份需求文档。不用自己手敲随便找个模型对话页生成一份登录需求就行。提示词可以这样写生成一份用户登录需求文档包含账号密码登录、短信验证码登录、连续错误锁定、多端并发登录四个模块用 Markdown 输出。拿到文档后存成login-prd.md。触发 Skill 的方式有两种。第一种是斜杠命令加文件引用/testcase-generator login-prd.md第二种更省事直接把文件拖进 Chat 输入框然后打一句生成测试用例。两种方式都会触发 Skill区别是第一种更明确适合演示第二种更顺手适合日常。执行完成后Cursor 会在工作区生成三个文件testcases.md、testcases.json、testcases.xlsx。打开 Markdown 那份检查几个关键点。第一case_id是不是按TC-LOGIN-001的格式递增第二scene_type四类场景是不是都覆盖到了第三并发用例有没有标注一致性语义。我实测下来登录需求大概能生成 28 条用例其中并发场景 3 条分别覆盖了同一账号两端登录验证码重复使用锁定状态下的并发解锁。JSON 那份可以直接导入测试管理平台字段名和 Skill 里定义的完全一致。XLSX 那份打开后列头是case_id / title / priority / precondition / steps / expected / test_data / scene_type评审会上投屏逐条过谁有异议直接在那行批注。校验输出格式是否合规可以用一段小脚本快速检查 JSON 的字段完整性import json with open(testcases.json, r, encodingutf-8) as f: cases json.load(f) required [case_id, title, priority, precondition, steps, expected, test_data, scene_type] for i, case in enumerate(cases): missing [k for k in required if k not in case] if missing: print(f第 {i1} 条用例缺字段: {missing}) if case.get(scene_type) 并发 and 幂等 not in case.get(expected, ): print(f第 {i1} 条并发用例未标注一致性语义) print(f共 {len(cases)} 条用例字段校验完成)跑一遍如果输出字段校验完成且没有缺字段提示说明 Skill 的输出结构是稳定的可以进入评审流程。5. 本篇常见错排查Skill 不触发斜杠命令里找不到。九成是 frontmatter 格式问题。name和description必须用---包起来且description里要包含触发关键词。如果你只写了生成测试用例没写需求文档那用户拖文档进来时可能不触发。把触发词写全包括同义词。输出只有 Markdown没有 JSON 和 XLSX。检查SKILL.md的输出要求段落是不是明确写了必须同时输出三种格式缺一不可。模型对必须这类强约束词更敏感。另外如果需求文档太长导致输出被截断把单次用例上限从 40 条降到 25 条分模块生成。用例字段缺失或格式不统一。这是examples/case-template.md没被正确引用。在SKILL.md里用相对路径引用模板文件路径要相对于SKILL.md所在目录。如果模板文件放在examples/下引用写examples/case-template.md不要写绝对路径。并发用例没有标注一致性语义。在约束段落里加一条硬性规则并发用例的 expected 字段必须包含幂等、乐观锁版本冲突、最终一致窗口三者之一否则重新生成。模型对明确的否定约束执行得更好。XLSX 文件打不开或乱码。这是编码问题。在SKILL.md里指定XLSX 使用 UTF-8 编码列头固定为以下顺序并给出列头列表。如果还是乱码检查 Cursor 的工作区编码设置确保是 UTF-8 而不是 GBK。Skill 调用后模型报超时。长文档加三格式输出对模型压力不小。把 Base URL 切到 TaoToken 的https://taotoken.net/api它的长上下文稳定性比默认出口好。如果还超时把需求文档拆成两个文件分两次生成最后合并 JSON。6. 把 Skill 接进日常评审流程Skill 生成用例只是第一步真正省时间的是把它接进评审流程。我的做法是在项目里建一个testcases/目录每次需求评审前跑一遍 Skill生成的 Markdown 直接贴进评审文档JSON 导入测试平台XLSX 作为附件归档。评审会上只讨论[待确认]标注的条目其他默认通过会议时间从一小时压到二十分钟。如果你需要长期在编码和 Agent 场景里用这套流程可以看看 Coding Plan地址是https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite它针对长会话和代码生成做了优化Skill 反复调用时额度更耐用。接入文档在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite里面有 Cursor、Claude Code 等工具的完整配置示例照着改 Base URL 就行。最后留一个实用技巧把SKILL.md里的场景覆盖规则做成可配置的。比如在文件顶部加一个coverage_level变量评审前设成strict生成 40 条日常冒烟设成lite生成 15 条。这样一份 Skill 能适配两种节奏不用维护两个文件。 Cursor Skill 实战：用 SKILL.md 打造 10 分钟可评审测试用例生成器
1. 为什么要在 Cursor 里做测试用例生成 Skill需求评审前最尴尬的场景是开发说这个逻辑很简单测试说那用例呢然后大家对着空白文档沉默。测试用例这件事难的不是写而是每次都要重新组织格式、重新想边界、重新对齐评审口径。一个登录需求正向、逆向、异常、并发四类场景手写两小时评审时还被指出漏了密码错误次数锁定后的解锁路径。Cursor 的 Agent Skills 正好能治这个病。Skill 的本质是一份SKILL.md它把什么时候触发、按什么规则干活、输出成什么结构固化下来AI 每次调用都按同一套标准执行不用你反复贴提示词。我试过把资深测试的用例模板塞进 Skill之后在 Chat 里输入/testcase-generator加需求文档三种格式的用例直接落盘。这篇面向的是需要快速产出可评审用例的研发和测试同学。所谓可评审不是用例数量多而是每条用例都有编号、前置条件、步骤、预期结果、优先级评审会上能逐条过。下面从零开始交付可直接复制的SKILL.md骨架、Cursor 配置片段以及用示例需求触发 Skill 并校验输出的完整动作。2. TaoToken 前置给 Skill 接一个稳定的模型出口Skill 本身只是规则文件真正干活的是背后的模型。Cursor 内置模型在长文档解析时偶尔会截断尤其是需求文档超过 5000 字、要求同时输出 Markdown/JSON/XLSX 三种结构时输出容易半途而废。我的做法是把模型出口切到 TaoToken它在 OpenAI 兼容协议上做得比较干净Cursor 里改个 Base URL 就能用。先到控制台建一个 API Key地址是https://taotoken.net/api-keys注意这个链接带了 utm 参数方便你从这篇直接跳过去。建 Key 的时候选默认项目即可权限给 Chat Completions 就够Skill 生成用例不需要额外能力。拿到 Key 之后Cursor 的配置入口在Settings - Models - OpenAI API Key。如果你用的是 Cursor 的 OpenAI 兼容模式填两个字段配置项值Base URLhttps://taotoken.net/apiAPI Key你刚建的那串sk-开头的 Key注意 Base URL 不要带 utm 参数https://taotoken.net/api就是纯接口地址。填完点 Verify能返回模型列表就说明通了。这一步做完后面 Skill 触发的所有请求都走这个出口长文档解析稳定性会好很多。如果你还想在浏览器里先验证模型对需求文档的理解能力可以打开模型对话页https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite把需求文档粘进去问一句这份需求有哪些边界条件没写清楚先摸清模型的解析水平再决定 Skill 里要不要加约束。3. 可复制的 SKILL.md 骨架与 Cursor 配置Cursor 里新建 Skill 的路径是Settings - Rules, Skills, Subagents - New Skill。点完之后它会开一个 New Chat让你用自然语言描述技能。但更可控的方式是直接手写SKILL.md放到项目的.cursor/skills/testcase-generator/目录下。目录结构长这样.cursor/ └── skills/ └── testcase-generator/ ├── SKILL.md ├── examples/ │ └── case-template.md └── references/ └── boundary-checklist.mdSKILL.md是必需项examples和references是可选的。下面这份骨架可以直接复制我把它拆成 frontmatter 和正文两部分。frontmatter 里的description是触发关键写得越具体AI 越容易在合适的时候调用它。--- name: testcase-generator description: 根据需求文档生成可评审的测试用例覆盖正向、逆向、异常、并发四类场景输出 Markdown、JSON、XLSX 三种格式。当用户提供需求文档、PRD、用户故事或提到生成测试用例用例评审时触发。 --- # 测试用例生成器 ## 触发条件 - 用户提供需求文档.docx/.md/.pdf/.txt或粘贴需求正文 - 用户输入 /testcase-generator 斜杠命令 - 用户提到用例评审覆盖场景 ## 输出要求 必须同时输出三种格式缺一不可 1. Markdown 表格用于评审会逐条过 2. JSON用于导入测试管理平台 3. XLSX用于归档和二次编辑 ## 用例字段规范 每条用例必须包含以下字段不允许省略 - case_id格式 TC-模块-序号如 TC-LOGIN-001 - title一句话描述验证点 - priorityP0/P1/P2 - precondition前置条件 - steps操作步骤编号列表 - expected预期结果 - test_data测试数据 - scene_type正向/逆向/异常/并发 ## 场景覆盖规则 - 正向主流程至少 3 条覆盖正常输入组合 - 逆向非法输入、越权、参数缺失至少 4 条 - 异常网络中断、超时、服务降级至少 3 条 - 并发同一资源竞争、幂等、乐观锁版本冲突至少 2 条 ## 输出格式模板 见 examples/case-template.md严格按模板结构输出。 ## 约束 - 单次输出用例不超过 40 条超出则按模块拆分 - 并发用例必须标注一致性语义幂等/乐观锁/最终一致窗口 - 不确定的需求点在用例末尾用 [待确认] 标注不要编造examples/case-template.md里放你的标准表格结构AI 会照着填。references/boundary-checklist.md放边界检查清单比如空值、超长、特殊字符、并发阈值、时区、编码这些容易漏的点。主文件控制在 500 行以内超出的内容往references里挪避免解析效率下降。配置片段方面如果你想让 Skill 在特定项目里自动生效可以在项目根目录的.cursor/rules里加一条引用{ skills: [ .cursor/skills/testcase-generator/SKILL.md ], autoTrigger: true }autoTrigger设为 true 后只要你在 Chat 里提到需求文档Cursor 会优先尝试调用这个 Skill不用每次手打斜杠命令。4. 用示例需求触发 Skill 并校验输出Skill 建好之后先验证它能不能被正确触发。在 Cursor Chat 里输入/如果下拉列表里出现testcase-generator说明 Skill 已注册成功。这一步没出现的话检查SKILL.md的 frontmatter 有没有语法错误name字段不能有空格。准备一份需求文档。不用自己手敲随便找个模型对话页生成一份登录需求就行。提示词可以这样写生成一份用户登录需求文档包含账号密码登录、短信验证码登录、连续错误锁定、多端并发登录四个模块用 Markdown 输出。拿到文档后存成login-prd.md。触发 Skill 的方式有两种。第一种是斜杠命令加文件引用/testcase-generator login-prd.md第二种更省事直接把文件拖进 Chat 输入框然后打一句生成测试用例。两种方式都会触发 Skill区别是第一种更明确适合演示第二种更顺手适合日常。执行完成后Cursor 会在工作区生成三个文件testcases.md、testcases.json、testcases.xlsx。打开 Markdown 那份检查几个关键点。第一case_id是不是按TC-LOGIN-001的格式递增第二scene_type四类场景是不是都覆盖到了第三并发用例有没有标注一致性语义。我实测下来登录需求大概能生成 28 条用例其中并发场景 3 条分别覆盖了同一账号两端登录验证码重复使用锁定状态下的并发解锁。JSON 那份可以直接导入测试管理平台字段名和 Skill 里定义的完全一致。XLSX 那份打开后列头是case_id / title / priority / precondition / steps / expected / test_data / scene_type评审会上投屏逐条过谁有异议直接在那行批注。校验输出格式是否合规可以用一段小脚本快速检查 JSON 的字段完整性import json with open(testcases.json, r, encodingutf-8) as f: cases json.load(f) required [case_id, title, priority, precondition, steps, expected, test_data, scene_type] for i, case in enumerate(cases): missing [k for k in required if k not in case] if missing: print(f第 {i1} 条用例缺字段: {missing}) if case.get(scene_type) 并发 and 幂等 not in case.get(expected, ): print(f第 {i1} 条并发用例未标注一致性语义) print(f共 {len(cases)} 条用例字段校验完成)跑一遍如果输出字段校验完成且没有缺字段提示说明 Skill 的输出结构是稳定的可以进入评审流程。5. 本篇常见错排查Skill 不触发斜杠命令里找不到。九成是 frontmatter 格式问题。name和description必须用---包起来且description里要包含触发关键词。如果你只写了生成测试用例没写需求文档那用户拖文档进来时可能不触发。把触发词写全包括同义词。输出只有 Markdown没有 JSON 和 XLSX。检查SKILL.md的输出要求段落是不是明确写了必须同时输出三种格式缺一不可。模型对必须这类强约束词更敏感。另外如果需求文档太长导致输出被截断把单次用例上限从 40 条降到 25 条分模块生成。用例字段缺失或格式不统一。这是examples/case-template.md没被正确引用。在SKILL.md里用相对路径引用模板文件路径要相对于SKILL.md所在目录。如果模板文件放在examples/下引用写examples/case-template.md不要写绝对路径。并发用例没有标注一致性语义。在约束段落里加一条硬性规则并发用例的 expected 字段必须包含幂等、乐观锁版本冲突、最终一致窗口三者之一否则重新生成。模型对明确的否定约束执行得更好。XLSX 文件打不开或乱码。这是编码问题。在SKILL.md里指定XLSX 使用 UTF-8 编码列头固定为以下顺序并给出列头列表。如果还是乱码检查 Cursor 的工作区编码设置确保是 UTF-8 而不是 GBK。Skill 调用后模型报超时。长文档加三格式输出对模型压力不小。把 Base URL 切到 TaoToken 的https://taotoken.net/api它的长上下文稳定性比默认出口好。如果还超时把需求文档拆成两个文件分两次生成最后合并 JSON。6. 把 Skill 接进日常评审流程Skill 生成用例只是第一步真正省时间的是把它接进评审流程。我的做法是在项目里建一个testcases/目录每次需求评审前跑一遍 Skill生成的 Markdown 直接贴进评审文档JSON 导入测试平台XLSX 作为附件归档。评审会上只讨论[待确认]标注的条目其他默认通过会议时间从一小时压到二十分钟。如果你需要长期在编码和 Agent 场景里用这套流程可以看看 Coding Plan地址是https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite它针对长会话和代码生成做了优化Skill 反复调用时额度更耐用。接入文档在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite里面有 Cursor、Claude Code 等工具的完整配置示例照着改 Base URL 就行。最后留一个实用技巧把SKILL.md里的场景覆盖规则做成可配置的。比如在文件顶部加一个coverage_level变量评审前设成strict生成 40 条日常冒烟设成lite生成 15 条。这样一份 Skill 能适配两种节奏不用维护两个文件。