一、引言
最近在使用 Cursor、Claude Code、Codex 等 AI 编程工具时，经常会看到一个概念：
Skill
例如：
- frontend-design
- humanizer
- git-workflow
- code-review
我们可能会产生一个疑问：
Skill 不就是一段 Prompt 吗？
如果只是 Prompt，那么为什么还要单独设计 Skill 这种机制？
实际上，两者存在明显区别。
一个普通 Prompt 通常解决的是：
"这一次，我希望 AI 怎么做。"
而 Skill 更关注：
"当 AI 遇到某一类问题时，它应该具备什么能力，以及应该按照什么规则完成任务。"
可以简单理解为：
| 类型 | 说明 |
|---|---|
| Prompt | 告诉 AI 一次具体任务怎么做 |
| Skill | 给 AI 增加一种可复用能力 |
按照团队约定的方式，把这个功能正确的实现出来：
开发者
│
▼
提出需求
│
▼
AI Agent
│
├── 项目规范
├── 业务知识
├── 开发经验
├── 工作流程
└── 工具能力
│
▼
分析任务
│
▼
执行开发
│
▼
验证结果Skill 的出现，本质上是在解决一个问题：
如何把"人类开发者的经验"，转化成 AI Agent 可以理解、调用和复用的能力？
二、需求背景
2.1 大模型本身并不知道你的项目规范
假设我们正在开发一个 Vue 3 项目。
项目规定：
- 使用 Vue 3 + TypeScript
- UI 使用 Element Plus
- 表格统一使用 vxe-table
- API 请求统一封装
- 所有页面必须支持国际化
- 禁止直接修改公共组件
- 页面组件采用 PascalCase
- API 文件统一放在 api 目录
如果我们每次让 AI 写代码，都告诉它：
- 请使用 Vue3 + TypeScript
- 不要使用 Element UI
- 使用 Element Plus
- 表格使用 vxe-table
- 接口必须经过 request 封装
- 支持国际化
- ...
很快就会发现一个问题：
Prompt 越来越长。
而且开发者很容易忘记某些规则。
于是出现第一个问题：
如何让 AI 长期稳定地遵循一套开发规范？
2.2 单纯 System Prompt 也不是最佳方案
理论上可以把所有规则直接放进 System Prompt：
你是一个 Vue 高级开发工程师......
项目规范：
......
......
......
但是这种方案存在一个明显问题：
上下文污染。
例如我们正在开发一个普通 CRUD 页面：
User Prompt → 创建用户管理页面
实际上 AI 可能并不需要知道：
- PDF 如何处理
- Git 如何提交
- 如何进行 UI 设计
- 如何生成 PPT
- 如何分析数据库
- 如何做安全审计
如果全部塞进上下文：
System Prompt + 所有 Skill + 项目规则 + User Prompt
上下文会越来越大。
最终导致：
- Token 消耗 ↑
- 上下文噪声 ↑
- 推理成本 ↑
- 规则冲突 ↑
因此，Agent 需要一种更加合理的机制：
需要的时候加载，不需要的时候不要加载。
这就是 Skill 非常重要的一个设计思想。
三、Skill 到底是什么？
我们先给 Skill 一个比较工程化的定义：
Skill 是一个面向 Agent 的可复用能力模块，它通过结构化指令、知识、工作流程以及可选工具，为 Agent 提供特定领域的执行能力。
可以把它类比成 JavaScript 中的模块：
javascript
import frontendDesign from './skills/frontend-design.js';
agent.use(frontendDesign);Agent 就获得了一种新的能力。
因此可以建立这样的对应关系：
| 软件工程 | AI Agent |
|---|---|
| Module | Skill |
| Function | Skill 能力 |
| npm package | Skill Package |
| README | Skill Instructions |
| API | Tool |
| Configuration | Skill Config |
| Runtime | Agent Runtime |
这也是我理解 Skill 最重要的一点：
Skill 并不是简单的 Prompt，而是 Agent 能力的模块化封装。
四、Skill 的基本结构
一个典型 Skill 可以设计成：
skills/
└── frontend-design/
├── SKILL.md
├── examples/
│ ├── dashboard.md
│ └── landing-page.md
├── templates/
│ └── component.vue
└── resources/
└── design-system.md其中最核心的是：
它可以包含：
yaml
---
name: frontend-design
description: 用于创建高质量前端 UI
---
# Frontend Design
## 适用场景
当用户要求：
- 创建页面
- 设计 UI
- 优化页面视觉效果
- 创建 Dashboard
时使用此 Skill。
## 设计原则
1. 不使用模板化布局
2. 合理使用字体
3. 保持视觉层次
4. 注意响应式设计
## 工作流程
1. 分析需求
2. 确定视觉方向
3. 设计布局
4. 编写代码
5. 检查视觉一致性这里实际上包含了三类信息：
Skill
│
├── Metadata
│
├── Instructions
│
└── Resources五、Skill 的工作原理
这是理解 Skill 最重要的部分。
很多人会误以为：
用户输入 → 直接执行 Skill
实际上，一个比较合理的 Agent Skill 架构应该是：
User Prompt
│
▼
┌──────────────┐
│ Agent Runtime │
└───────┬──────┘
│
▼
┌──────────────┐
│ Skill Router │
└───────┬──────┘
│
判断是否需要 Skill
│
┌────────┴────────┐
▼ ▼
不需要 需要
│ │
│ ▼
│ Load Skill
│ │
│ ▼
│ Skill Context
│ │
└────────┬────────┘
▼
LLM Reasoning
│
▼
Tools
│
▼
Result核心过程可以拆成几个步骤。
5.1 第一步：用户提出任务
例如：
帮我设计一个医疗 LIS 系统的检验工作站页面。
Agent 首先分析：
- 这是普通代码任务？
- 还是 UI Design？
- 还是数据分析？
- 还是 PDF？
- 还是 Git？
5.2 第二步：Skill Discovery
Agent 会根据 Skill 的：
- name
- description
- trigger
进行匹配。
例如：
javascript
const skills = [
{
name: 'frontend-design',
description: '用于设计和实现高质量前端 UI'
},
{
name: 'pdf',
description: '用于 PDF 创建、编辑和分析'
},
{
name: 'code-review',
description: '用于代码审查和质量分析'
}
];用户请求：
设计一个 LIS 检验工作站页面
Agent 可以判断：
frontend-design ↑ 高相关
于是加载对应 Skill。
六、写一个简化版 Skill
下面我们不依赖任何第三方 Agent 框架，直接使用 JavaScript 实现一个极简版本。
目的不是做生产级 Agent，而是帮助我们理解 Skill 的核心机制。
首先定义 Skill：
javascript
const skills = [
{
name: 'frontend-design',
description: '用于网页 UI 设计、Dashboard、页面视觉优化',
instructions: `
你是一名高级前端 UI 工程师。
设计页面时需要遵循：
1. 保持合理的视觉层次
2. 避免模板化设计
3. 保持组件结构清晰
4. 考虑响应式布局
5. 优先保证用户体验
`
},
{
name: 'code-review',
description: '用于 JavaScript、TypeScript、Vue、React 代码审查',
instructions: `
你是一名高级前端代码审查工程师。
审查代码时重点关注：
1. Bug
2. 性能问题
3. 可维护性
4. 安全问题
5. 类型问题
6. 架构问题
`
}
];七、Skill 解决了哪些痛点？
7.1 痛点一：重复 Prompt
没有 Skill：
请遵循项目规范：......每次重复。
有 Skill：
启用 project-standard 即可。
7.2 痛点二：上下文过长
没有 Skill：
所有知识 → 全部注入 → LLM
有 Skill：
User Prompt → Skill Discovery → 只加载相关 Skill
可以减少大量无关上下文。
7.3 痛点三：AI 输出不稳定
没有 Skill：
- 第一次：使用 Element Plus
- 第二次：使用 Ant Design
- 第三次：自己写组件
有 Skill：
Project Skill → 统一规范 → 稳定输出
7.4 痛点四：团队经验无法沉淀
这是我认为 Skill 最有价值的地方之一。
一个高级开发工程师可能知道：
- 这个项目怎么写
- 这个组件不能改
- 这个接口怎么调用
- 这个 Bug 怎么避免
但是新人不知道。
如果把经验整理成 Skill：
Senior Engineer → Skill → 整个团队
就可以把个人经验转化成：
机器可执行的工程知识。
八、Skill 与传统 Prompt 的区别
| 对比项 | Prompt | Skill |
|---|---|---|
| 使用方式 | 一次性 | 可复用 |
| 作用范围 | 单次任务 | 某类任务 |
| 结构 | 通常是一段文本 | 模块化上下文 |
| 主动提供 | 按需加载 | --- |
| 工具协作 | 较弱 | 可以结合项目规范 |
| 不稳定 | 更稳定 | --- |
| 团队复用 | 较差 | 较好 |
| 能力扩展 | 有限 | 较强 |
一句话：
Prompt 是任务指令，Skill 是能力封装。
九、Skill 与 MCP 有什么区别？
这个问题非常容易混淆。
MCP 主要解决：
AI 如何连接外部工具和数据。
Skill 主要解决：
AI 如何获得某种专业能力和执行方法。
可以理解成：
Agent
│
┌──────────┴──────────┐
│ │
Skill MCP
│ │
▼ ▼
"怎么做" "能操作什么"
│ │
▼ ▼
专业知识/流程 工具/数据/服务例如：
- Skill：如何进行 Figma → Vue 页面开发
- MCP：提供 Figma 文件读取能力
组合起来：
Figma MCP + Frontend Design Skill + Coding Agent → 自动生成前端页面
所以两者并不是竞争关系。
而是：
Skill + MCP 可以组合成更强的 Agent 能力。
十、Skill 与 Agent 的关系
可以进一步抽象：
LLM
↓
Agent
├── Planning
├── Memory
├── Tool Calling
├── Skill
└── ReflectionSkill 是 Agent 的一个能力组件。
因此：
Skill ≠ Agent
一个 Agent 可以拥有很多 Skill：
Agent
│
├── frontend-design
├── code-review
├── testing
├── security
├── database
└── deployment这和传统软件架构中的：
Application
├── Module A
├── Module B
└── Module C非常类似。
十一、竞品分析
目前 AI Coding / Agent 领域已经出现了很多类似的能力扩展机制。
这里重点从工程思想上比较。
| 方案 | 核心定位 | Skill | Tool | MCP | 特点 |
|---|---|---|---|---|---|
| Claude Code | Agent Coding | ✅ | ✅ | ✅ | Agent 能力强 |
| Codex | AI Coding Agent | ✅ | ✅ | 部分场景 | 代码任务能力强 |
| Cursor | AI IDE | 类似 | ✅ | ✅ | IDE 集成优秀 |
| GitHub Copilot | AI Coding | 类似 | ✅ | ✅ | GitHub 生态强 |
| OpenAI Agents | Agent Framework | 可组合 | ✅ | 可接入 | 更偏 Agent 平台 |
| Dify | AI 应用平台 | 类似 | ✅ | 可扩展 | 企业应用友好 |
这里需要特别注意：
不同厂商对 Skill 的命名和实现方式并不完全一致。
有些产品直接使用：
Skill
有些产品可能使用：
Rules 、Instructions 、Commands 、Plugins 、Agents 、Extensions 、Workflows
但从架构思想来看，它们解决的问题高度相似：
让 AI 的能力变得可组合、可复用、可扩展。
十二、Skill 设计中的几个关键原则
如果自己开始写 Skill，我建议注意以下几个问题。
Skill 不要写成百科全书
错误：
Vue 所有知识
JavaScript 所有知识
CSS 所有知识
这种 Skill 会非常臃肿。
正确：
只描述 Agent 完成特定任务需要知道的内容。
Skill 应该关注"行为"
不要只写：
Vue3 是一个前端框架......
而应该写：
创建 Vue3 页面时：
- 优先使用 Composition API
- 复杂逻辑抽离 composable
- API 请求统一放入 api 目录
- 不允许在页面中直接调用 axios
也就是：
Knowledge → Behavior
后者更加有价值。
十三、Skill 最大的价值是什么？
如果让我总结 Skill 的价值，我认为不是：
"让 AI 更聪明。"
而是：
让 AI 的能力变得工程化。
传统大模型：
能力很强，但不可控
Skill：
能力 + 规范 + 流程 + 知识 + 工具
最终变成：
可复用 、可组合 、可维护 、可版本化 、可团队共享
这其实和软件工程的发展非常类似。
我们过去经历了：
Machine Code → Assembly → Function → Module → Package → Framework
AI 能力也可能经历：
Prompt → Prompt Template → Skill → Skill Composition → Agent → Agent System
十四、总结
Skill 表面上看只是一个：
但从 Agent 架构角度来看，它实际上代表了一种非常重要的思想：
将 AI 能力进行模块化、结构化和工程化。
它解决的核心问题可以概括为：
- Prompt 解决："这一次怎么做？"
- Skill 解决："以后遇到这类问题应该怎么做？"
- Tool 解决："AI 实际能够操作什么？"
- Agent 解决："AI 如何自主规划和完成任务？"
因此可以建立一个非常清晰的关系：
AI Agent
│
┌───────────┼───────────┐
│ │ │
Skill Tool Memory
│ │ │
怎么做 能做什么 记住什么
│ │ │
└───────────┼───────────┘
▼
LLM对于前端开发者来说，Skill 最值得关注的地方其实是：
未来我们可能不只是"让 AI 帮我们写代码"，而是把整个团队的开发规范、架构经验、设计规范、测试方法和业务知识，逐渐沉淀成一套 AI Skill。
比如一个 LIS 项目，可以逐步形成：
LIS Agent
│
├── lis-business
├── vue-development
├── frontend-design
├── coding-standard
├── code-review
├── testing
└── security最终实现：
需求 → AI Agent → 自动选择 Skill → 读取项目规范 → 调用工具 → 编写代码 → 自动测试 → 代码审查 → 交付
这时候，AI Coding 就从：
AI 帮我写代码
逐渐变成：
AI 按照团队工程体系帮我完成开发。
我认为这可能才是 Skill 真正值得关注的地方。
作者: 王新焱
博客: https://blog.csdn.net/qq_34402069
时间: 2026年8月29日