用 AI Skill 封装你的工作流：从代码规范到全流程提效实战
你有没有发现，每次让 AI 写代码都要重复说一遍"用 TypeScript"、"用函数式组件"、"不要 any"？每次做需求评审都要重新解释一遍你们团队的流程？本文教你用 Skill 文件把这些重复工作封装成"AI 工具包"------一次封装，永久生效。
前言：你在做 AI 的"人肉提示词工程"
用 AI 开发工具（OpenClaw / Cursor / Windsurf 等）一段时间后，你大概率会陷入这个循环：
- 每次开新项目都要说一遍"我用 React + TypeScript + Tailwind"
- 每次写代码都要补一句"遵循 ESLint 规范，不要用 var"
- 每次做 Code Review 都要提醒"检查空值处理、错误边界、类型安全"
- 每次写文档都要说"用中文、用 Markdown、标题不超过三级"
你在用自然语言手动维护一套"规范系统"，每次对话都要重新加载一遍。
这个问题的本质是什么？
arduino
┌───────────────────────────────────────────────────────────┐
│ 你在做什么 │
│ │
│ 你的工作流程 / 规范 / 偏好 │
│ ↓ │
│ 每次对话都用自然语言重复一遍 │
│ ↓ │
│ AI 执行（这次记住了） │
│ ↓ │
│ 新会话 → 全忘了 → 再说一遍 │
│ │
│ 问题： │
│ ├── 效率低：每次都在做"人肉提示词注入" │
│ ├── 不一致：这次说的和上次说的可能不一样 │
│ ├── 有遗漏：总会忘记说某些规则 │
│ └── 不可复用：换个项目又要从头来 │
│ │
│ 解决方案：把工作流封装成 Skill 文件 │
│ ├── 一次编写，永久生效 │
│ ├── 跨项目复用 │
│ ├── 版本化管理（Git 追踪变更） │
│ └── 按需加载，不浪费 token │
└───────────────────────────────────────────────────────────┘一、什么是 Skill？30 秒搞懂
Skill 是一个 Markdown 文件（通常叫 SKILL.md），放在特定目录下，AI 工具会在合适的时机自动加载它。
你可以把它理解为：给 AI 写的 SOP（标准作业流程）。
objectivec
人类世界 AI 世界
───────── ─────────
员工手册 ← 对应 → SOUL.md（身份认知）
岗位SOP ← 对应 → SKILL.md（技能包）
项目规范文档 ← 对应 → AGENTS.md（项目规则）
经验教训库 ← 对应 → MEMORY.md（历史记忆）Skill 文件的基本结构
markdown
# Java Spring Boot 开发规范 Skill
## 触发条件
当开发 Java Spring Boot 项目时自动加载。
## 技术栈
- Java 17+
- Spring Boot 3.x
- MyBatis-Plus
- Maven
## 代码规范
### 命名规范
- 类名：大驼峰（UserService）
- 方法名：小驼峰（getUserById）
- 常量：全大写下划线（MAX_RETRY_COUNT）
- 包名：全小写（com.example.user）
### 分层结构
controller/ → 只做参数校验和返回值封装
service/ → 业务逻辑
mapper/ → 数据访问
dto/ → 数据传输对象
vo/ → 视图对象
### 必须遵守
- 所有 API 返回统一 Result<T> 包装
- 异常使用全局异常处理器
- 禁止在 Controller 中写业务逻辑
- 所有查询必须分页当 AI 加载了这个 Skill，它就像一个"入职培训过的新员工"------知道你的规范，不需要你每次都说。
二、Skill 的放置位置与加载机制
2.1 目录结构
css
你的项目/
├── .cursor/
│ └── skills/ ← Cursor 的 Skill 目录
│ ├── java-spring/
│ │ └── SKILL.md
│ ├── react-ts/
│ │ └── SKILL.md
│ └── code-review/
│ └── SKILL.md
│
├── .openclaw/
│ └── skills/ ← OpenClaw 的 Skill 目录
│ └── ...
│
├── AGENTS.md ← 项目级规则
└── src/
└── ...2.2 加载逻辑
javascript
Skill 的加载是"按需"的，不是全部加载：
全局 Skill（~/.cursor/skills/ 或 ~/.openclaw/skills/）：
├── 所有项目都会检查
├── 适合放通用规范（代码风格、Git 提交规范）
└── 注意控制大小，因为每次都加载
项目级 Skill（项目/.cursor/skills/）：
├── 只在当前项目生效
├── 适合放项目特定规范（API 设计、数据库规范）
└── 更精准，不污染其他项目
触发匹配：
├── AI 会根据当前任务内容匹配相关 Skill
├── 比如你在写 Java 代码 → 自动加载 java-spring Skill
├── 比如你在做 Code Review → 自动加载 code-review Skill
└── 不相关的 Skill 不会加载 → 节省 token三、实战：6 个开箱即用的 Skill 模板
3.1 Java Spring Boot 规范
markdown
# Java Spring Boot 开发规范
## 适用场景
Java 后端项目，使用 Spring Boot 框架。
## 核心规则
### 分层架构
- Controller：参数校验 + 调用 Service + 返回 VO
- Service：业务逻辑，注入 Mapper，事务在这层
- Mapper：继承 BaseMapper<T>，复杂 SQL 用 XML
- DTO：接收前端参数，用 @Valid 校验
- VO：返回给前端的数据结构
### 统一返回格式
所有 API 返回 Result<T>：
{
"code": 200,
"message": "success",
"data": {}
}
### 异常处理
- 业务异常用自定义 BusinessException
- 全局 @RestControllerAdvice 捕获
- 不要在代码中吞异常（catch 空块）
### 数据库规范
- 表名小写下划线：user_order
- 必须有 id, create_time, update_time
- 逻辑删除字段：is_deleted
- 禁止 SELECT *
### 禁止事项
- 禁止在 Controller 写业务逻辑
- 禁止硬编码魔法数字
- 禁止直接拼 SQL（防注入）
- 禁止 System.out.println（用 log）3.2 React + TypeScript 前端规范
markdown
# React + TypeScript 前端开发规范
## 适用场景
React 18+ 项目，使用 TypeScript + Tailwind CSS。
## 核心规则
### 组件规范
- 使用函数式组件 + Hooks，禁止 Class 组件
- 组件文件名：PascalCase（UserProfile.tsx）
- 每个组件一个文件，不超过 200 行
- Props 必须定义 interface，不用 any
- 导出方式：named export（不用 default export）
### 状态管理
- 简单状态：useState
- 复杂状态：useReducer
- 全局状态：Zustand（不用 Redux）
- 服务端状态：TanStack Query
### 样式规范
- 使用 Tailwind CSS，不写自定义 CSS
- 响应式：mobile-first（sm → md → lg）
- 暗色模式：使用 dark: 前缀
### TypeScript 规范
- 严格模式（strict: true）
- 禁止 any，用 unknown 替代
- 接口用 interface，类型别名用 type
- 枚举用 const enum 或 as const
### 禁止事项
- 禁止 var（用 const/let）
- 禁止 index 作为 key（除非是静态列表）
- 禁止在 useEffect 中直接调 async 函数
- 禁止 !important3.3 Code Review 检查清单
markdown
# Code Review Skill
## 适用场景
当用户要求做代码审查时加载。
## 审查维度（按优先级）
### P0 --- 安全性
- [ ] SQL 注入风险
- [ ] XSS 风险
- [ ] 敏感信息硬编码（密码、密钥、Token）
- [ ] 权限校验是否完整
- [ ] 输入参数是否校验
### P1 --- 正确性
- [ ] 空值处理（null/undefined/空数组/空字符串）
- [ ] 边界条件（空集合、负数、超大数）
- [ ] 并发安全（竞态条件、死锁风险）
- [ ] 错误处理（异常是否被正确捕获和处理）
- [ ] 资源释放（连接、流、锁）
### P2 --- 性能
- [ ] N+1 查询问题
- [ ] 不必要的重复计算
- [ ] 大集合操作（是否应该分页/流式处理）
- [ ] React 不必要的重渲染
- [ ] 接口响应体是否过大
### P3 --- 可维护性
- [ ] 命名是否清晰（读代码能懂意图）
- [ ] 函数是否过长（>50 行考虑拆分）
- [ ] 重复代码（DRY 原则）
- [ ] 注释：只注释"为什么"，不注释"做了什么"
- [ ] 类型定义是否完整
## 输出格式
按 P0→P3 优先级排列问题，每个问题给出：
1. 问题描述
2. 代码位置
3. 修复建议
4. 严重程度（Critical/Major/Minor）3.4 Git 提交规范
markdown
# Git Commit Message 规范
## 适用场景
当执行 git commit 时加载。
## 格式
<type>(<scope>): <subject>
## Type 类型
- feat: 新功能
- fix: 修复 bug
- docs: 文档变更
- style: 代码格式（不影响逻辑）
- refactor: 重构
- perf: 性能优化
- test: 测试相关
- chore: 构建/工具变更
## 规则
- subject 用中文或英文均可，但项目内统一
- 不超过 72 个字符
- 不以句号结尾
- 使用现在时态（"add feature" 而非 "added feature"）
## 示例
feat(user): 新增用户注册接口
fix(order): 修复订单金额计算精度丢失
refactor(auth): 重构登录逻辑，抽取 TokenService3.5 API 设计规范
markdown
# RESTful API 设计规范
## 适用场景
设计或审查 API 接口时加载。
## URL 规范
- 使用名词复数：/api/v1/users（不是 /getUser）
- 层级关系：/api/v1/users/{id}/orders
- 版本号在 URL 中：/api/v1/
## HTTP 方法
- GET：查询（幂等）
- POST：创建
- PUT：全量更新
- PATCH：部分更新
- DELETE：删除
## 状态码
- 200：成功
- 201：创建成功
- 400：请求参数错误
- 401：未认证
- 403：无权限
- 404：资源不存在
- 500：服务器错误
## 分页
{
"data": [],
"pagination": {
"page": 1,
"pageSize": 20,
"total": 100,
"totalPages": 5
}
}
## 错误返回
{
"code": 40001,
"message": "用户名不能为空",
"details": [
{ "field": "username", "message": "required" }
]
}3.6 需求分析 Skill（非开发场景）
markdown
# 需求分析 Skill
## 适用场景
当用户给出一个需求/想法，需要分析可行性时加载。
适用于产品经理、项目经理、创业者。
## 分析框架
### 第一步：需求澄清
- 用户是谁？
- 核心痛点是什么？
- 现有解决方案是什么？为什么不够好？
- 最小可行产品（MVP）包含哪些功能？
### 第二步：可行性评估
- 技术可行性：现有技术能否实现？
- 市场可行性：有多少潜在用户？
- 商业可行性：如何赚钱？客单价？
- 时间可行性：MVP 需要多久？
### 第三步：优先级排序
使用 MoSCoW 方法：
- Must have：没有就不能上线
- Should have：重要但可延后
- Could have：锦上添花
- Won't have：明确不做
### 输出格式
用表格展示功能清单 + 优先级 + 预估工时 + 风险点。四、进阶：超越代码规范的 Skill 封装
Skill 不只是给开发者用的。任何有重复流程的工作都可以封装：
css
┌───────────────────────────────────────────────────────────────┐
│ Skill 的适用范围 │
│ │
│ 开发类： │
│ ├── 代码规范（Java/TS/Python/Go...） │
│ ├── Code Review 检查清单 │
│ ├── API 设计规范 │
│ ├── 数据库设计规范 │
│ ├── Git 工作流 │
│ └── 测试用例编写规范 │
│ │
│ 非开发类： │
│ ├── 周报/日报撰写模板 │
│ ├── 需求评审流程 │
│ ├── 竞品分析框架 │
│ ├── 商业计划书结构 │
│ ├── 技术方案评审清单 │
│ ├── 面试评估模板 │
│ ├── 邮件回复规范 │
│ └── 文章写作风格指南 │
│ │
│ 个人效率类： │
│ ├── 每日计划制定流程 │
│ ├── 读书笔记整理模板 │
│ ├── 知识卡片生成规范 │
│ └── 学习路径规划框架 │
│ │
│ 核心判断标准： │
│ 你是否在 AI 对话中重复说过 3 次以上的相同指令？ │
│ 如果是 → 封装成 Skill │
│ │
└───────────────────────────────────────────────────────────────┘五、Skill 编写的 5 个黄金法则
法则 1：一个 Skill 只做一件事
objectivec
✗ 错误：一个 SKILL.md 塞了 Java 规范 + 前端规范 + Git 规范 + API 设计
→ 太长，token 浪费严重，而且任何场景都会全部加载
✓ 正确：每个规范一个 Skill 文件
→ skills/java-spring/SKILL.md
→ skills/react-ts/SKILL.md
→ skills/git-commit/SKILL.md
→ skills/api-design/SKILL.md法则 2：写"规则"而不是"教程"
arduino
✗ 错误（教程式）：
"React 的 useEffect 是一个 Hook，它可以让你在函数组件中
执行副作用操作。它接受两个参数......"
→ AI 已经知道 useEffect 是什么，你不需要教它
✓ 正确（规则式）：
"useEffect 依赖数组不能为空（除非明确需要只执行一次）。
禁止在 useEffect 回调中直接使用 async。
清理函数必须处理组件卸载后的异步回调。"
→ 直接告诉它"怎么做"，不用解释"是什么"法则 3：用示例代替描述
markdown
✗ 模糊描述：
"函数命名应该清晰表达意图"
✓ 具体示例：
命名规范：
- getUserById ✓
- getData ✗（太模糊）
- processInfo ✗（process 什么？）
- handleUserLoginAndSendWelcomeEmail ✗（太长，应该拆成两个函数）法则 4：明确"禁止事项"
AI 特别擅长遵守"禁止"规则。与其说"最好不要"，不如说"禁止"：
sql
模糊：尽量不要使用 any 类型
明确：禁止使用 any。如果类型不确定，使用 unknown + 类型守卫。法则 5：控制篇幅
理想长度：200-500 行
├── 太短（<100 行）：规则不够具体，AI 还是会乱来
├── 刚好（200-500 行）：覆盖核心规则，不浪费 token
└── 太长（>1000 行）：占用大量上下文，影响 AI 性能
每个 Skill 消耗的 token 大约：
├── 200 行 ≈ 600-800 tokens
├── 500 行 ≈ 1,500-2,000 tokens
└── 1,000 行 ≈ 3,000-4,000 tokens六、实战案例：我如何用 Skill 体系管理 3 个项目
objectivec
我的 Skill 目录结构：
~/.cursor/skills/ ← 全局 Skill（所有项目共用）
├── code-style/
│ └── SKILL.md ← 通用代码风格（命名、注释）
├── git-commit/
│ └── SKILL.md ← Git 提交规范
└── code-review/
└── SKILL.md ← Code Review 检查清单
项目 A（Java 后端）/.cursor/skills/
├── java-spring/
│ └── SKILL.md ← Spring Boot 开发规范
└── api-design/
└── SKILL.md ← RESTful API 设计规范
项目 B（React 前端）/.cursor/skills/
├── react-ts/
│ └── SKILL.md ← React + TS 规范
└── component-design/
└── SKILL.md ← 组件设计规范
项目 C（iOS App）/.cursor/skills/
├── swiftui/
│ └── SKILL.md ← SwiftUI 开发规范
└── admob/
└── SKILL.md ← AdMob 集成规范效果对比：
| 指标 | 没有 Skill | 有 Skill |
|---|---|---|
| 新会话启动时间 | 前 5 分钟在描述规范 | 即刻开始写代码 |
| 代码一致性 | 每次风格不同 | 严格统一 |
| Review 通过率 | 约 60%（常忘规范） | 约 90%+ |
| 重复提示次数 | 每会话 3-5 次 | 0 次 |
| 跨项目切换 | 要重新"教" AI | 自动加载对应规范 |
七、从 0 到 1 搭建你的 Skill 体系
Step 1：回顾你最近 10 次 AI 对话
找出你重复说过的指令：
- "用 TypeScript，不要用 JavaScript"
- "返回格式用 Result 包装"
- "不要给我写注释"
- "用 Tailwind，不要写 CSS 文件"
Step 2：按场景分类
把这些指令归类到不同的 Skill：
- 语言/框架规范类
- 流程规范类（Code Review、Git、API）
- 输出格式类（文档、报告）
Step 3：写第一个 Skill
从你最常用的场景开始，参考上面的模板，写一个 200-300 行的 Skill 文件。
Step 4：测试和迭代
- 开新会话，看 AI 是否遵守了 Skill 中的规则
- 发现没覆盖到的场景 → 补充规则
- 发现冗余的规则 → 删除
- 每 2 周 review 一次 Skill 文件
八、总结
arduino
┌───────────────────────────────────────────────────────────────┐
│ │
│ Skill 封装的本质： │
│ 把"你脑子里的工作流程"变成"AI 能自动执行的 SOP" │
│ │
│ ┌────────────┐ ┌────────────────────┐ │
│ │ 你的大脑 │ │ Skill 文件 │ │
│ │（会忘记） │ →→→ │（不会忘记） │ │
│ │ │ │ │ │
│ │ - 编码规范 │ │ - java-spring.md │ │
│ │ - 审查习惯 │ │ - code-review.md │ │
│ │ - 设计偏好 │ │ - api-design.md │ │
│ │ - 工作流程 │ │ - requirement.md │ │
│ └────────────┘ └────────────────────┘ │
│ │
│ 三条核心原则： │
│ 1. 一个 Skill 只做一件事 → 按需加载，不浪费 token │
│ 2. 写规则不写教程 → AI 不需要你教它 React 是什么 │
│ 3. 用示例代替描述 → "getUserById ✓ / getData ✗" 胜过千言万语 │
│ │
└───────────────────────────────────────────────────────────────┘把 Skill 体系搭建好，你的 AI 开发工具就从"每次都要调教的实习生"变成了"熟悉你所有规范的老同事"。
相关资源
如果这篇文章对你有帮助，点个赞让更多人看到。有问题欢迎评论区交流，我们下一篇继续聊 AI 工具的高级玩法。