别再每次都从零写用例了，把经验封装成Skill，让AI替你干活
大家好，我是某互联网公司的测试架构师。
上个月，团队来了个新项目——一个用户登录模块的改版。需求文档不长，也就五六页。按以往的经验，测试新人拿到这份文档，至少得花两天才能写出像样的用例——啃文档、画流程图、一条条敲表格、反复修改。
但这次不一样。团队里一个刚转正的测试同学，打开Cursor，调了一个Skill，10分钟后交出了一份覆盖正向、逆向、异常、并发的完整用例集，直接就能拿去评审。
测试组长看完之后，在群里发了一句话：
“这是谁写的？格式比我们模板还规范，场景比我列的还全。”
他说的是“那个东西”——Cursor + Skill。
一、先搞清楚：Skill到底是什么？
很多人第一次接触“Skill”这个概念的时候，以为就是“高级一点的Prompt”。
完全不是一回事。
Skill是2026年AI编程工具里最核心的能力之一。Cursor、Claude Code、OpenClaw都在用。它的本质是一组结构化的指令和资源，用于教会AI完成特定任务，让AI按照标准规则干活，是一套可复用的规则。
用大白话说：Skill就是把“资深测试工程师怎么做用例设计”的完整经验，封装成一个文件夹。AI在需要的时候自动加载，按你的要求执行任务。
一个Skill的核心结构很简单：
SKILL.md（必需）：技能说明书，告诉AI这个技能是做什么的、什么时候触发、怎么使用scripts/（可选）：可执行的脚本文件，AI可以直接运行references/（可选）：参考资料，给AI提供专业知识和分析框架
对比一下：
传统方式：每次打开Cursor，重新输入一遍“帮我生成测试用例，覆盖正向、逆向、异常、边界……” Skill方式：输入 /testcase-generator，AI自动加载全部规则，10分钟出活
区别不是“快一点”，是“不用每次都重新教”。
二、10分钟完整步骤
下面我用一个用户登录功能的真实案例，带你把整个流程走一遍。
第一步：创建Skill（2分钟）
打开Cursor，按 Cmd/Ctrl + Shift + P 打开命令面板，选择 “Cursor: Open Settings” 。
在设置菜单中，找到 Rules、Skills、Subagents 标签页，点击 “New Skill” 。
在弹出的对话框中，输入以下内容：
根据需求文档生成测试用例，需要覆盖正向、逆向、异常、并发场景。
就这么一句话。Cursor会基于这句话，自动帮你生成一个Skill草稿，写入 SKILL.md 文件。
整个过程不需要你写一行代码。
第二步：完善Skill配置（3分钟）
Cursor生成草稿后，会问你两个问题：
输出格式：你希望输出主要是Markdown用例描述，还是也要JSON？ 需求编号格式：你们的“需求编号/字段”是否有固定格式（如REQ-1、模块-条款号）？
我的建议是——全都要。直接告诉AI：
我希望用例输出格式同时生成Markdown、JSON、Excel（.xlsx）
这样一份Skill，可以同时输出三种格式，满足不同场景的需求——Markdown用于评审讨论，Excel用于导入测试管理工具，JSON用于自动化流转。
Cursor会根据你的回答，自动完善 SKILL.md 的内容。
最终你得到的是一个名为 testcase-generator 的Skill。
Skill文件放在哪？
Skill放在项目的 .cursor/skills/ 目录下。结构是这样的：
.cursor/
└── skills/
└── testcase-generator/
└── SKILL.md
如果想让Skill在所有项目中都能用，也可以放在用户级目录 ~/.cursor/skills/。
第三步：准备需求文档（2分钟）
Skill建好了，接下来需要一份需求文档作为输入。
你不会还傻傻地自己手敲需求文档吧？让AI帮你生成一份就行了。
打开DeepSeek或任何大模型工具，输入：
帮我生成一份用户登录功能的PRD需求文档，包含功能描述、输入参数、业务规则、异常说明。
AI会帮你生成一份结构完整的PRD。保存为Word或Markdown格式，放在项目目录下。
真实案例中，我们的需求文档是这样的：
功能：用户登录
输入：手机号（11位）、密码（6-20位）
业务规则：
- 手机号格式校验：11位数字，以1开头
- 密码校验：6-20位，字母+数字组合
- 连续输错5次密码，账号锁定30分钟
- 登录成功后跳转首页
异常场景：
- 手机号为空 → 提示“请输入手机号”
- 密码错误 → 提示“密码错误，还剩X次机会”
- 账号被锁定 → 提示“账号已锁定，请30分钟后重试”
第四步：运行Skill生成用例（3分钟）
回到Cursor，按 Ctrl/Cmd + I 打开Chat。
输入斜杠 / 查看可用技能列表，选择 /testcase-generator 。
然后把需求文档拖到Chat输入框中，或者在指令里引用文档：
/testcase-generator @登录功能PRD.docx
AI会自动加载Skill的规则，分析需求文档，然后生成结构化的测试用例。
10分钟后，你得到的是一份这样的输出：
同时还会生成JSON和Excel格式的文件，可以直接导入测试管理工具。
伙伴们，对AI测试、大模型评测、质量保障感兴趣吗？我们建了一个 「人工智能测试开发交流群」，专门用来探讨相关技术、分享资料、互通有无。无论你是正在实践还是好奇探索，都欢迎扫码加入，一起抱团成长！期待与你交流！👇
三、为什么Skill生成的用例质量更高？
很多人问：“我自己在Chat里写Prompt也能生成用例，为什么要搞Skill？”
三个原因：
第一，一致性。 每次生成的用例格式、颗粒度、覆盖标准完全一致。不会因为今天心情好就多写几条、明天赶时间就少写几条。
第二，经验固化。 把团队资深测试工程师的“隐性经验”变成“显性指令”，写入Skill。新人拿到Skill，等于拿到了老员工的“脑图”。
第三，渐进式披露。 Skill采用分级加载机制——平时只加载名字和描述，等到真正使用时才加载完整内容。不会像把所有规则塞进一个Prompt那样浪费上下文。
四、避坑指南
坑一：SKILL.md写得像百科全书
很多人把Skill当成“把所有内容塞进去”，结果一个SKILL.md写了800多行。每次调用都消耗大量Token。
解法： SKILL.md只放核心流程（建议控制在500行以内），详细内容移到references/目录。Claude只在需要时才读这些文件。
坑二：description写得太空
description是AI判断“什么时候触发这个Skill”的唯一依据。写“帮助生成测试用例”这种描述，AI永远不知道什么时候该用它。
解法： description要写清楚“触发条件”。比如：“当用户提到‘生成测试用例’‘编写测试’‘测试场景’等意图时触发。”
坑三：只建Skill，不迭代
Skill不是一次性产物。业务在变、需求在变，Skill也需要更新。
解法： 每次使用后记录“AI漏了什么场景”“哪里判断错了”，定期更新SKILL.md。
最后
传统测试的底层资产是“测试用例库”——用例是一次性的，用完就扔。
AI时代的底层资产正在变成“Skill库”——Skill是可组合、可复用的能力单元。
你今天花10分钟建了一个“测试用例生成”的Skill，以后每一个项目都能复用。你今天花5分钟优化了Skill的规则，以后每一次生成都会更精准。
Skill不是让你“少干活”，是让你“把经验留下来”。
下次你拿到一份需求文档的时候，别从零开始写用例了。花10分钟建一个Skill，让AI替你干活。
10分钟后，你会看到一份可以直接拿去评审的用例集。
而你写的那个Skill，会在未来的每一个项目里，继续替你干活。
