Agent Skill 深入浅出：让 AI 按你的规矩办事
Agent Skill 深入浅出：让 AI 按你的规矩办事
你每天都在用 AI 写代码，但它总是不按你的套路来——每次都要重复说"别写注释"、"走 TDD 流程"、"用 Maven 时加那个参数"。Skill 就是来解决这个问题的。
一、三个让你抓狂的时刻
先看看这几个场景，你是否似曾相识：
场景一：每开一个会话都是"初见"
你花了一个小时调教 AI，终于让它理解了你的项目规范——Maven 本地仓库在 D:\repository，Git 路径是 D:\Git\cmd，提交信息用中文，别写废话注释。第二天打开新会话，一切归零。你又得从头说一遍。
你在 CLAUDE.md 里写了这些规则，但 AI 偶尔还是会忽略。为什么？因为 CLAUDE.md 告诉 AI 的只是偏好声明——"我喜欢这样"，而不是执行指令——"遇到这种情况就这么做"。
场景二：你想走 TDD，AI 上来就写实现
你说"写一个用户登录功能"，AI 噼里啪啦写出 200 行代码，Controller、Service、DAO 全给你整好了。你说"先写测试"，它说"好的"，然后在已有代码外面套了一层测试——测试直接通过，什么都没证明。
你想要的流程是：先写失败的测试 → 写最小实现 → 重构。但 AI 默认不会这么做，因为它没有"肌肉记忆"。
场景三：团队里每个人都在用自己的方式做事
你习惯了"写完代码 → code review → 合并到 UAT"的流程。同事 A 习惯直接 push，同事 B 习惯 rebase 后再 push。AI 在中间帮倒忙——它不知道该遵循谁的规矩，于是按自己的默认行为来。
这些问题的根因是一样的：AI 知道"要做什么"，但不知道"怎么做"。
二、Skill 的本质：给 AI 装上"肌肉记忆"
2.1 一句话定义
Skill 是一个可编程的工作流文件，它定义了触发条件、执行步骤和检查清单。 AI 在合适的时机自动加载它，然后严格按照它定义的流程执行。
用个比喻：
| 概念 | 类比 | 作用 |
|---|---|---|
| CLAUDE.md | 公司员工手册 | 声明偏好和规范（"我们使用 Spaces 缩进"） |
| System Prompt | 岗位职责描述 | 定义 AI 的基本行为边界 |
| Skill | SOP 标准作业程序 | 告诉 AI 遇到某件事时，第一步做什么、第二步做什么、做到什么程度算完成 |
CLAUDE.md 是"是什么"，Skill 是"怎么做"。
2.2 技术本质：一个 Markdown 文件
打开一个真实的 Skill 文件，你会发现它就是一个 Markdown 文件，加上一段 YAML 头：
---
name: brainstorming
description: "You MUST use this before any creative work..."
---
# Brainstorming Ideas Into Designs
Help turn ideas into fully formed designs...
## Checklist
1. **Explore project context** — check files, docs, recent commits
2. **Ask clarifying questions** — one at a time
3. **Propose 2-3 approaches** — with trade-offs
4. **Present design** — get user approval after each section
5. **Write design doc** — save and commit
就这么简单。没有复杂的 DSL，没有 YAML 配置地狱，就是一个 Markdown 文件里写了流程描述和检查清单。
2.3 Skill 是怎么被激活的？
整个流程是这样的：
用户发消息 → AI 扫描消息内容 → 匹配 Skill 的 description 字段
→ 匹配到了？调用 Skill 工具加载完整内容
→ AI 读取 Skill 里的指令 → 严格按 Skill 定义的流程执行
关键在于 description 字段。它就像搜索引擎的关键词——AI 通过它判断"这个 Skill 适不适合当前场景"。
比如 brainstorming 的 description 是：
"You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior."
当你说的内容涉及"创建功能、构建组件、添加功能"时，AI 就会自动触发这个 Skill。你不需要手动指定用哪个 Skill，AI 自己判断。
2.4 Skill 和 Slash Command 的区别
很多新手会混淆这两个概念：
| Skill | Slash Command | |
|---|---|---|
| 触发方式 | AI 自动判断，自动调用 | 用户手动输入 /command |
| 使用场景 | 工作流约束（"每次写代码前先设计"） | 快捷操作（"帮我提交代码"） |
| 典型例子 | brainstorming、TDD、debugging | /commit、/merge-to-uat、/code-review |
| 用户感知 | 无感——AI 自动执行了流程 | 有感——你主动发起了操作 |
实际上，Slash Command 底层也经常绑定一个 Skill。比如 /commit 命令会触发 commit Skill，后者定义了"先 git status → 再 git diff → 生成 commit message → 执行 commit"的完整流程。
三、你已经在用了，只是不知道
如果你用过 Claude Code 一段时间，下面这些场景你可能都遇到过，但不一定意识到背后是 Skill 在驱动：
3.1 脑暴时 AI 变得"很有章法"
你说"帮我设计一个新功能"，AI 没有直接写代码，而是一步一步问你：
- "先让我了解一下项目上下文"
- "这个功能面向什么用户？"
- "有两种方案，A 更灵活但复杂，B 更简单但扩展性差，你倾向哪种？"
- "这是我的设计方案，你看第一部分对吗？"
这不是 AI 突然变聪明了——这是 brainstorming Skill 在背后约束它的行为。Skill 里写了："每次只问一个问题，先理解再设计，设计方案要分节确认"。
3.2 TDD 流程被强制执行
你说"修复这个 bug"，AI 说"先写一个能复现 bug 的失败测试"。你本来想让它直接改代码，但它坚持先写测试。
这就是 test-driven-development Skill 的铁律：
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Skill 里甚至列了一张"借口对照表"：
| 借口 | 真相 |
|---|---|
| "这个太简单了不需要测试" | 简单代码也会出错，写测试只要 30 秒 |
| "我先写完再补测试" | 写完再补的测试直接通过，什么都证明不了 |
| "我已经手动测过了" | 手动测试没有记录，不能重复运行 |
这就是 Skill 的力量——它不只是建议，而是规则。 它把"最好这么做"变成了"必须这么做"。
3.3 代码审查变成标准流程
你写完代码，AI 不是直接 commit，而是：
- 检查是否所有新功能都有测试
- 确认你看到了每个测试失败
- 验证所有测试通过
- 检查是否有未处理的边界情况
完成所有检查后，AI 才会说"可以提交了"。这套流程来自 verification-before-completion Skill。
3.4 指令优先级：谁说了算？
当多个规则冲突时，优先级是这样的：
用户指令 > Skill 规则 > 系统默认行为
比如 Skill 要求你必须走 TDD，但你说"这次跳过测试直接写代码"，AI 听你的。Skill 是约束 AI 的，不是约束你的。 你永远是最高优先级。
四、手把手创建一个 Skill
理论讲完了，我们来实操。创建一个"发布文章到博客园"的 Skill——虽然我们已经有 MCP 工具，但把它包装成 Skill 后，AI 会在合适的时候自动使用。
4.1 Skill 的目录结构
一个完整的 Skill 插件目录长这样：
my-plugin/
├── README.md # 插件说明（可选）
├── commands/ # Slash Command 定义
│ └── publish-article.md
└── skills/ # Skill 定义
└── publish-article/
└── SKILL.md # Skill 核心文件
4.2 写 SKILL.md
核心就是 SKILL.md 文件。我们一步步来：
第一步：写 frontmatter
---
name: publish-article
description: "当用户要求发布、推送、上传文章到博客园时使用此 Skill。触发词包括：发布文章、发博客、推送到博客园、publish post。"
---
name 是唯一标识，description 是触发条件。description 写得越具体，AI 越能准确判断何时触发。
第二步：定义执行流程
# 发布文章到博客园
## 执行步骤
1. **确认文章内容** — 检查文章文件是否存在，读取内容
2. **确认发布参数** — 标题、标签、分类是否齐全
3. **调用 MCP 工具** — 使用 cnblogs-mcp 的 create_post 工具发布
4. **验证发布结果** — 确认返回文章地址
5. **告知用户** — 返回文章链接
第三步：加入检查清单和边界条件
## 检查清单
- [ ] 文章文件存在且非空
- [ ] 标题不为空
- [ ] 标签数量不超过 5 个
- [ ] 发布成功并获得文章 URL
- [ ] 文章 URL 已返回给用户
## 错误处理
- 如果 CNBLOGS_TOKEN 未配置：提示用户配置环境变量
- 如果网络错误：重试一次，仍失败则告知用户
- 如果文章已存在（同标题）：询问用户是否覆盖
就这么简单。写完这个 Markdown 文件，放到 skills/publish-article/SKILL.md，AI 下次看到"发布文章"就会自动加载这个流程。
4.3 创建 Slash Command（可选）
如果你想手动触发，可以加一个 Command 文件 commands/publish-article.md：
---
allowed-tools: Bash(git status:*), Read, Write
description: 发布文章到博客园
---
## 任务
用户要求发布一篇文章到博客园。加载 publish-article Skill 并按其流程执行。
## 步骤
1. 找到要发布的文章文件
2. 读取文章内容
3. 通过 MCP 工具 create_post 发布
4. 确认发布成功并返回链接
这样用户既可以手动输入 /publish-article，AI 也可以在检测到"发布文章"意图时自动触发。
4.4 调试技巧
Skill 调试不像代码调试那样有断点，但有几个实用方法：
- 看 AI 有没有调用 Skill：如果 AI 的行为不符合预期，先确认 Skill 是否被触发——在对话开头看有没有"Using xxx skill"的提示
- 检查 description 是否准确：如果 Skill 没被触发，大概率是 description 写得太模糊。把触发关键词写清楚
- 测试边界条件：故意触发一些边缘场景，看 Skill 的检查清单是否覆盖
- 逐步完善：先写一个最小版本的 Skill（只有核心流程），跑通了再逐步加检查清单和错误处理
五、Skill 生态与未来
5.1 当前生态
Skill 的社区生态正在快速发展。在 Claude Code 中，你已经可以安装来自官方市场和各种第三方插件的 Skill：
- Superpowers 系列：brainstorming、TDD、debugging、writing-plans 等基础工作流 Skill
- Commit Commands：一键 commit、push、创建 PR
- Code Review：自动化代码审查流程
- 文档处理：xlsx、pptx、pdf 的读写 Skill
- 前端设计：UI 组件设计 Skill
这些 Skill 都可以通过插件市场一键安装，就像 npm install 一样简单。
5.2 Skill 改变了什么
在 Skill 出现之前，AI Agent 的行为主要靠 System Prompt 控制。问题是：
- System Prompt 是一次性的、静态的
- 修改 System Prompt 需要改配置、重启服务
- 不同任务需要不同的行为模式，但 System Prompt 是全局的
Skill 解决了这些问题：
| 之前 | 之后 |
|---|---|
| 一个巨大的 System Prompt 管所有场景 | 按需加载的 Skill，不同场景不同行为 |
| 修改行为 = 改配置重启 | 修改行为 = 改一个 Markdown 文件 |
| 团队规范靠口头约定 | 团队规范靠共享 Skill 文件强制执行 |
| AI 行为不可预测 | AI 行为被 Skill 约束在预定轨道上 |
5.3 未来展望
我判断 Skill 会往三个方向发展：
1. 成为 AI 时代的 "npm package"
就像 npm 让 JavaScript 生态爆发一样，Skill 市场会让 AI Agent 的能力生态爆发。你不需要从头教 AI 怎么做代码审查——安装一个 code-review Skill 就行了。不需要教 AI 怎么部署——安装一个 deploy Skill。
2. 企业级 Skill 会成为核心竞争力
每个公司的开发规范、部署流程、代码审查标准都不一样。把这些规范写成 Skill，就能确保团队里每个人用的 AI 都遵循同一套流程。这比写文档、做培训有效得多——文档可能没人看，但 Skill 会强制执行。
3. Skill 组合会催生"超级 Agent"
单个 Skill 解决单个问题，但多个 Skill 可以串联成完整的工作流：brainstorming（设计）→ writing-plans（计划）→ TDD（实现）→ code-review（审查）→ commit（提交）→ deploy（部署）。
这本质上就是一个 AI 驱动的软件工程流水线。
六、总结
Skill 不是什么高深的概念。它就是一个 Markdown 文件，里面写了什么情况下做什么、按什么步骤做、做到什么程度算完成。
但它解决的问题是根本性的：AI 很聪明，但聪明不等于可靠。 Skill 给 AI 的聪明加上了约束，让它从"可能按你的方式做事"变成"一定按你的方式做事"。
如果你只记住一句话，记住这句：
CLAUDE.md 告诉 AI 你是什么样的人，Skill 告诉 AI 你希望事情怎么做。
下一步做什么？打开你的 ~/.claude/plugins 目录，看看你已经安装了哪些 Skill，读一读它们的 SKILL.md 文件。然后想想你的日常工作里，有哪些重复性的流程可以被写成 Skill——那可能就是你的第一个 Skill。
本文基于 Claude Code 的 Skill 机制撰写，但 Skill 的概念正在被越来越多的 AI Agent 平台采用，核心思想是通用的。
浙公网安备 33010602011771号