在AI Agent与智能体技术快速普及的当下，Skill（技能）已成为连接业务需求与AI能力的核心单元。与传统API或微服务不同，一个Skill不仅封装了执行逻辑，还融合了语义理解、工具调用、上下文推理与结果生成等智能行为。
先说几个核心判断：Skill并非简单的工具或接口，而是智能体在执行复杂任务时的“操作手册”或“标准作业程序”。如果你正为如何让AI高效、稳定地完成专业任务而烦恼，那么这篇文章正是为你量身定制。
一、什么是Skill？为何不可或缺？
核心定义
简单来说，Skill是智能、行动与上下文的有机融合。
- 智能：能够理解自然语言指令。例如，用户说“请帮我Review一下这个React组件的代码”，系统就能准确领会其意图。
- 行动：能够调用外部工具完成任务，例如调用linter、代码分析工具、测试框架等。
- 上下文：能结合项目规范、团队编码标准、历史Review意见做出合理判断，而非机械套用。
典型案例
“Review前端代码”这件事，远不止跑一遍语法检查那么简单。一个合格的Review Skill需要识别代码类型、应用团队规范、检查安全性（如XSS、CSRF）、验证可访问性、评估性能影响，最终给出可执行的改进建议。这才是名副其实的Skill。
技术本质
从技术架构来看，Skill采用了渐进式披露（Progressive Disclosure）设计理念。简而言之，就是“用多少，加载多少”，避免一次性将所有信息都塞入模型上下文。
| 层级 | 位置 | 作用 | 加载时机 |
|---|---|---|---|
| 第一层 | YAML Frontmatter | 元数据（名称、触发条件） | 总是加载 |
| 第二层 | SKILL.md正文 | 具体步骤、检查清单、示例 | 需要时动态加载 |
| 第三层 | 关联文件 | references/、assets/等 | 仅在需要时查看 |
这种设计带来的直接好处是：大幅节省Token消耗，同时提升执行效率与稳定性。市场反馈也印证了这一点——采用分层设计的Skill，平均Token消耗可降低40%以上。
二、编写高质量Skill的六大原则
原则1：单一职责，避免“大而全”
❌ 错误做法：创建一个名为code-helper的庞大Skill，试图涵盖前后端Review、文档生成、Bug修复等所有功能。结果往往不尽如人意。
✅ 最佳实践：采用Micro-skills（微技能），将大任务拆解为小而专的Skills：
frontend-code-reviewer：前端代码审查器（React/Vue/HTML/CSS）accessibility-auditor：可访问性审计performance-optimizer：性能优化建议
原因在于：Claude的上下文窗口虽大但并非无限。加载无关Skills的上下文会通过“噪声”降低模型智商。行业共识是：专才比全才更可靠，尤其在Agent这类高精度执行场景中。
原则2：命名即路由
Claude根据Skills的name和description决定是否调用。因此，拒绝模糊命名。
❌ 错误示例：
name: code-review
description: Helps with code.✅ 正确示例：
name: frontend-code-reviewer
description: |
审查React/Vue组件代码，检查代码质量、安全性、性能和可访问性。
当用户要求review前端代码、审查组件、检查React/Vue代码时使用。关键在于：描述中必须包含What（做什么）和When（何时使用，即触发短语）。
原则3：步骤明确可执行
Skill的核心是“步骤”，每一步都必须是可执行的指令。避免使用“可能”“大概”这类模糊词汇。
一个小技巧：采用结构化指令，利用大模型的注意力机制。例如：
## Review Categories
### 1. Code Quality (代码质量)
- **必须**检查组件职责单一性
- **必须**验证Props类型定义完整
### 2. Security (安全性)
- **必须**检查XSS风险（用户输入未转义）
- **必须**检查敏感信息泄漏（API Key硬编码）
## Workflow
1. Analysis Phase: 静默分析代码
2. Security Check: 执行安全检查清单
3. Output: 生成结构化报告原则4：自我纠错能力
在Skills的指令中，明确要求Claude验证自身输出。这个环节容易被忽略，但实际效果显著。
实战技巧：要求Claude在输出最终结果前，先反向验证——自己提出的修改建议是否真的能解决问题？有无更优方案？
原则5：失败策略完备
人都会犯错，模型也不例外。关键在于错误发生后如何处理。明确告诉模型遇到问题时的应对方式：
## Error Handling
当遇到以下情况时：
- 代码片段不完整：请求用户提供更多上下文
- 无法识别框架：询问是React还是Vue
- 缺少项目规范：使用通用最佳实践作为标准原则6：可复用与可组合
一个Skill创建后，可在不同对话中反复调用。多个Skill还能组合构建更复杂的工作流。例如：
frontend-code-reviewer+accessibility-auditor→ 完整的前端质量检查frontend-code-reviewer+performance-optimizer→ 代码Review + 性能优化
这就是Skill的“乐高”特性——积木式组合，灵活且强大。
三、从0到1创建Skill的完整流程
Step 1：明确Skill目标与边界
以“前端代码自动审查”为例：
- 名称：
frontend-code-reviewer - 触发条件：用户表达“review前端代码”“审查组件”“检查React/Vue代码”等意图
- 输入：代码片段、技术栈标识（React/Vue）、项目规范（可选）
- 输出：结构化Review报告，包含问题清单、严重程度、修复建议
- 依赖工具：ESLint配置、Prettier配置、浏览器兼容性数据库
这一步至关重要，目标定义越清晰，后续执行效果越可控。
Step 2：设计元数据
---
name: frontend-code-reviewer
description: |
审查React/Vue组件代码，检查代码质量、安全性（XSS/CSRF）、性能和可访问性。
当用户要求review前端代码、审查组件、检查React/Vue代码时使用。
version: 1.0.0
author: FrontendTeam
---Step 3：实现Skill逻辑
在SKILL.md中编写详细指令。这部分是Skill的灵魂，需将Review的流程、检查点、输出规范都写清楚。
# Frontend Code Reviewer Skill
## Input Format
- code: 待审查的代码片段
- framework: 框架类型（react/vue，默认react）
- specs: 项目规范文件（可选，默认使用通用最佳实践）
## Review Categories
### 1. Code Quality (代码质量)
- **必须**检查组件职责单一性，避免巨型组件
- **必须**验证Props类型定义完整（TypeScript接口或PropTypes）
- **必须**检查变量命名语义化
- **必须**验证逻辑复用（useHooks提取公共逻辑）
- **建议**检查代码可读性和注释完整性
### 2. Security (安全性)
- **必须**检查XSS风险：
- 用户输入直接插入DOM（dangerouslySetInnerHTML、innerHTML）
- 未转义的用户内容渲染
- **必须**检查CSRF风险：
- 表单提交是否携带token
- API调用是否有认证机制
- **必须**检查敏感信息泄漏：
- API Key、Secret硬编码
- 调试console.log未清理
### 3. Performance (性能)
- **必须**检查不必要的重新渲染：
- 缺少React.memo、useMemo、useCallback
- 组件挂载时重复执行昂贵操作
- **必须**检查资源加载：
- 大图片未压缩
- 未使用懒加载（lazy loading）
- **建议**检查Bundle大小影响（避免引入巨型库）
### 4. Accessibility (可访问性)
- **必须**检查语义化HTML使用
- **必须**检查键盘导航支持
- **必须**检查ARIA标签完整性
- **建议**检查颜色对比度
### 5. Best Practices (最佳实践)
- **必须**检查错误边界（Error Boundary）
- **必须**检查状态管理规范（避免props drilling）
- **建议**检查CSS-in-JS或CSS Modules使用
- **建议**检查响应式设计
## Workflow
请严格按照以下步骤执行：
1. **Framework Detection** - 自动识别代码框架（React/Vue）
- 如果无法识别，询问用户
2. **Static Analysis** - 静默阅读代码，在思维链中标记所有不符合Review Categories的问题
- 记录每个问题的行号和上下文
3. **Self-Correction** - 再次检查是否遗漏安全问题（特别是XSS和敏感信息泄漏）
- 确认每个建议都是可执行的
4. **Output Generation** - 按照Output Format生成结构化报告
- 确保每个问题都有明确的修复建议
## Output Format
使用以下Markdown表格格式输出：
| 类别 | 严重程度 | 行号 | 问题描述 | 修复建议 |
|------|----------|------|----------|----------|
| Security | 
