先回顾Rules 文件解决了什么在上一篇教程里我们用 Rules 文件解决了一个问题让 AI 遵守我们的工程规范以及代码复用。Rules 文件的本质它是一段会被自动注入到每次对话里的提示词。比如我们写过纯文本- 禁止在测试文件中直接调用 HTTP 客户端 - 优先使用 Service 层的公共方法 - 测试用例命名必须遵循 test_{场景描述} 格式这些规则会在 AI 每次生成代码时生效确保它不跑偏。其实就是cursor或者其他AI辅助工具会自动把rules文件中的提示词注入到你的对话中。但 Rules 这种自动注入到对话中的形式注定了它是一种常驻的形式这样就不适合做一些特定的任务。它不擅长描述一套完整的、多步骤的操作流程。。举个例子如果你想让 AI 执行把一个旧版本接口迁移到新版本这种复杂任务假射这个流程需要 8 个步骤要跑脚本检查要按特定顺序操作把这一大段流程塞进 Rules 文件里就会带来一个问题Rules 是常驻的每次对话都加载这么长的内容会浪费大量 Token。同时会污染你的常规对话。就是你本来不想让他做这事但它自动把这些注入到你的对话里了。这套流程只在做迁移时才用得到平时挂着纯属干扰。这就是Skill登场的地方。Rules 与 Skill相同点与不同点Rules 可以看作是一个最特殊的 Skill 一个永远生效的底线型技能。而正式的 Skill是为特定场景封装的、按需唤起的专家型技能平时不会被唤起。相同点维度说明本质两者底层都是结构化的提示词Prompt Engineering都是写给 AI 看的说明书目的都是为了让 AI 的行为更可控、更符合预期减少跑偏形式都用 Markdown 编写人类可读、可维护价值都能把人脑里的经验沉淀成AI 可执行的指令不同点这是理解二者关系的关键请仔细看这张表维度Rules规则Skill技能定位底线、约束技能、能力生效方式始终生效常驻按需触发用到才加载内容长度宜短几十行可长几百行 脚本典型内容编码规范、安全红线、命名约定完整工作流、操作 SOP、模板能否带工具不能纯文本能可以包含脚本、配置模板等Token 成本每次对话都消耗不触发时零成本打个比方公司的《员工行为准则》某个岗位的《标准作业手册》 工具箱一张图看懂二者的关系纯文本都是写给 AI 看的说明书 │ ┌───────────────┴───────────────┐ │ │ ┌───▼────┐ ┌────▼─────┐ │ Rules │ │ Skill │ │ 规则 │ │ 技能 │ └────────┘ └──────────┘ ·始终生效 ·按需唤起 ·短、纯文本 ·可长、可带脚本工具 ·定义底线 ·封装完整能力 ·例不许硬编码 token ·例一键迁移接口版本 │ │ └──── Rules 是特殊的 ─────────┘ 那个常驻 Skill理解了这层关系我们就可以正式认识 Skill 了。什么是真正的 Skill一句话定义Skill 是为特定场景封装的技能包它是一组提示词和脚本工具的组合专门用来让 AI 高质量地完成某一类任务。拆开这句话的关键词特定场景Skill 不是万能的每个 Skill 只专注做好一件事比如生成单元测试审查 SQL 安全性提示词 脚本工具的组合这是 Skill 区别于 Rules 的核心skill可以附带脚本让 AI 真正执行检查、转换、验证等操作封装把做这件事需要的所有知识和工具打包在一起Skill 的三个要素一个完整的 Skill 通常包含三类内容要素英文作用举例指令Instructions告诉 AI 怎么干、按什么步骤第一步检查环境第二步生成代码第三步运行验证上下文Context提供背景知识、团队规范我们项目用 pytest断言风格是 XXX工具Tools辅助脚本、配置模板一个check_env.sh脚本、一个测试文件模板Skill 最大的价值一人编写所有人复用这是 Skill 在团队中的核心意义纯文本传统方式 老员工脑子里有一套怎么写好接口测试的经验 → 新人来了要口头教、文档可能过期 → 老员工离职经验也跟着走了 Skill 方式 老员工把经验写成一个 Skill一次性投入 → 提交到团队仓库 → 所有人包括新人的 AI 都能立刻用上这套经验 → 人走了Skill 还在知识留下来了Skill 可以主动被唤起和 Rules被动常驻不同Skill 可以根据用户的意图主动唤起执行。比如你对 AI 说纯文本帮我给 order_service.py 这个文件生成单元测试如果团队里有一个叫生成单元测试的 SkillAI 会自动识别到你的意图与这个 Skill 匹配于是自动加载并按照 Skill 里定义的流程执行。这种按意图自动唤起的能力是 Skill 体系最优雅的地方。当然也可以由用户主动唤起 我们在对话框中 使用 “/” 这个符号来唤起 Skill。它会显示出当前所有的skill用户可以主动选择使用哪一个 Skill。Skill 长什么样目录与文件结构纯文本my-first-skill/ ← 一个文件夹 └── SKILL.md ← 唯一必需的文件里面就是提示词没错最简单的 Skill 只需要一个SKILL.md文件。这个文件就是整个 Skill 的说明书其实就是你需要它干什么的提示词。复杂一点的 Skill带上脚本和资源当 Skill 需要附带工具时目录会丰富起来纯文本generate-unit-test/ ← Skill 文件夹 ├── SKILL.md ← 核心说明书必需 ├── scripts/ ← 脚本工具目录 │ ├── check_env.sh ← 环境检查脚本 │ └── run_coverage.sh ← 覆盖率检查脚本 ├── references/ ← 参考文档目录 │ └── test-patterns.md ← 详细的测试模式说明 └── assets/ ← 静态资源目录 └── test_template.py ← 测试文件模板目录用途是否必需SKILL.md核心说明书必需scripts/可执行脚本检查、转换、验证等有些任务可提前沉淀下来脚本保证每次都稳定正确的运行毕竟让大模型每次都自己发挥太不可控了可选references/详细参考文档避免把 SKILL.md 撑太长 很多任务需要一些知识才能完成你可以认为这是skill的知识库可选assets/模板、配置等静态资源也包括一些运行结果可选SKILL.md 的内部结构SKILL.md由两部分组成**YAML 头信息** **Markdown 正文**。Markdown--- name: generate-unit-test description: 为指定的源代码文件自动生成 pytest 单元测试。当用户要求写单元测试生成测试补测试覆盖时触发。 --- # 生成单元测试 ## 概述 本 Skill 帮助你为 Python 源文件自动生成符合项目规范的 pytest 单元测试。 ## 前置条件 - 项目已安装 pytest - 存在 conftest.py ## 处理步骤 1. 读取目标源文件理解其函数和类 2. 识别需要测试的公共方法 3. 为每个方法生成正常、边界、异常三类测试 4. 运行 pytest 验证生成的测试可以通过 ## 代码示例 这里放 代码 示例一般是references目录下的文件 ## 验证清单 - [ ] 所有测试可以被 pytest 收集 - [ ] 测试全部通过 - [ ] 覆盖率达到 80% 以上 - [ ] 调用scripts/check.sh 检查代码规范YAML 头---之间的部分定义 Skill 的元信息最关键的是name和descriptionMarkdown 正文详细的指令、上下文、示例、验证清单等划重点description字段极其重要——它决定了 AI 能否在合适的时机想起这个 Skill。后面第8章会专门讲怎么写好它。Skill 存放在哪里以 Cursor / Claude Code 类工具为例Skill 通常有两个存放位置位置路径示例作用范围用户级~/.claude/skills/或~/.cursor/skills/所有项目都能用项目级项目根目录/.claude/skills/或.cursor/skills/只在当前项目生效注意不同 AI 工具的具体路径和机制略有差异请以你使用的工具官方文档为准。本系列以通用机制讲解。当然最简单的创建方式 是直接在Agent对话中告诉大模型我想创建一个项目级的 Skill然后输入名称和描述即可。尝试写出第一个 Skill理论讲完了我们动手做一个真正能用的 Skill。目标做一个为接口测试工程自动生成测试用例的 Skill把我们前两篇的经验沉淀进去。第一步明确这个 Skill 要解决什么在动手前先想清楚三个问题问题我们的答案这个 Skill 做什么为接口生成符合三层架构规范的 pytest 测试用例什么时候触发用户说写接口测试生成测试用例给 XX 接口补测试时做完怎么算成功测试能被 pytest 收集 全部通过 符合代码规范第二步用对话让大模型创建 Skill 骨架PS就不用古法编程了直接用对话让大模型帮你生成 Skill。在 Cursor的Agent对话里直接这样说纯文本帮我在当前项目里创建一个项目级 Skill名字叫 api-test-generator。 它的作用是为接口生成符合三层架构api层 / service层 / tests层规范的 pytest 测试用例。当用户说写接口测试生成测试用例给某接口补测试覆盖时 应该触发它。技术栈是 pytest requests。 请先帮我把 Skill 的目录和 SKILL.md 骨架建好YAML 头信息里的 name 和 description 帮我写好description 要写清做什么 何时触发 技术关键词。大模型会自动帮你创建.cursor/skills/api-test-generator/目录生成SKILL.md文件写好 YAML 头信息你会得到类似这样的骨架这是大模型生成的不是你手敲的YAML--- name: api-test-generator description: 为接口生成符合三层架构api层/service层/tests层规范的 pytest 测试用例。当用户要求写接口测试生成测试用例给某接口补测试覆盖时触发。适用于使用 pytest requests 的接口自动化工程。 ---第三步用对话把流程经验喂给大模型让它补全正文骨架有了接下来是—处理步骤、示例、验证清单。同样不用手写你只要把脑子里的该怎么做用大白话讲给大模型让它整理成规范的 SKILL.md 正文。继续对话纯文本现在帮我把这个 SKILL.md 的正文补充完整按下面我说的流程来整理 【概述】 说明这个 Skill 会生成符合三层架构规范的 pytest 测试 自动遵循api 层定义接口、service 层封装流程、tests 层只写测试逻辑的约定。 【前置条件】 开始前要确认项目有 api/ services/ tests/ 三个目录、装了 pytest 和 requests、 有 conftest.py 且定义了 api_client fixture。不满足就提示用户。 【处理步骤】要分成这几步 1. 通过语义检索找到满足当前测试用例需要的方法和API。如果项目里没有定义好接口那需要收集接口信息路径、方法、必填/可选参数、成功响应字段、业务功能 2. 检查 api 层是否已有该接口没有就先在 {模块}_api.py 里补接口定义 3. 检查 service 层有没有可复用的流程比如先创建订单这种前置数据 4. 生成测试用例要覆盖正常、边界、异常三类场景 5. 运行 pytest 验证测试能收集且通过 【示例】给一个创建订单接口的例子展示生成的代码长什么样。 【验证清单】列出完成后要检查的点命名规范、不能在测试里直接拼接口路径、 三类场景齐全、pytest 能通过。大模型会把你这段口语化的描述整理成结构清晰的 SKILL.md 正文。你拿到后通读一遍发现哪里不对就继续让它调整第四步让大模型顺便补一个脚本工具如果你希望这个 Skill 带一个环境检查脚本也不用自己写 shell直接说纯文本再帮这个 Skill 加一个环境检查脚本放在 scripts/check_env.sh 功能是检查当前产品的测试环境是否健康是否可访问。毕竟如果环境有问题我们的测试用例也一定会失败。 这时候就不要去运行验证了。大模型会自动创建scripts/check_env.sh并在 SKILL.md 里加上引用。你只要看一眼脚本逻辑对不对即可。第五步测试你的 SkillSkill 建好后在 Cursor 中重新打开项目让它重新加载 Skill然后对 AI 说一句日常需求纯文本给查询订单列表接口写测试GET /api/v2/orders支持 page、page_size、status 参数如果 Skill 写得好AI 会自动识别意图、加载你刚建的 Skill、按照里面定义的步骤生成符合规范的测试用例——你甚至不用提用 api-test-generator它自己就唤起了。恭喜你的第一个 Skill 就这样聊出来了总结这里可能有些同学会说我这个项目就是用来做接口自动化的我直接使用rules文件不可以么 短期看是可以的 但其实在AI时代下一个接口自动化工程 可不是只为了接口自动化而存在而是为了整个项目自动化而存在。后面我要讲如何用AI来生成和执行性能测试场景高可用测试场景生成手工测试用例场景生成需求分析报告场景等等。 我们总不能把这些所有的东西都放在一个rules文件里吧毕竟我们有一种现象叫上下文腐坏过多的上下文会让大模型幻觉跳步自欺欺人等。这里也再重申一下 **Everything in git ** 的设计哲学。这些所有的代码和文档都是我们项目的知识这些知识为我们后续编写各种skill来完成特定任务都是有帮助的。最后在推荐一下我的知识星球 更多教程内容会在上面更新