OpenClaw 进阶:自定义 Skill 制作完全指南,附 5 个真实案例

OpenClaw 进阶：自定义 Skill 制作完全指南，附 5 个真实案例

用过 OpenClaw 的人都知道官方那几个 Skills：frontend-design、canvas-design、skill-creator。

但真正强大的，是你能自己造 Skill。

今天讲讲怎么做自定义 Skill，怎么用 Skill 把重复工作自动化，附 5 个我自己在用的真实案例。

01 什么是 Skill？为什么需要自定义？

Skill 本质上是一个工作流模板。

它告诉 AI：

在什么场景下应该做什么
需要什么输入
应该如何处理
输出什么格式

官方 Skill 能满足通用需求，但你的业务有自己的场景。

比如：

你是安全工程师，需要自动化的渗透测试流程
你是产品经理，需要自动生成 PRDs
你是运维，需要标准化的上线流程

这些都需要自定义 Skill。

02 Skill 的结构：一个 Skill 有哪些文件？

一个 Skill 放在 .claude/skills/ 目录下，结构如下：

.claude/skills/my-skill/├── skill.md          # 核心定义文件├── prompts/         # 提示词模板（可选）├── scripts/         # 辅助脚本（可选）└── README.md        # 说明文档（可选）

核心是 skill.md，它的结构：

---name: my-skilldescription: 这个 Skill 是做什么的---# My Skill你是一个 [角色设定]当你被调用时，请执行以下步骤：## 步骤 1：[做什么]输入：[接收什么]处理：[怎么处理]输出：[输出什么]## 步骤 2：[做什么]...

03 快速入门：做一个”代码审查助手”

目标： 做一个小工具，输入文件路径，自动审查代码并给出报告。

Step 1: 创建目录结构

mkdir -p ~/.claude/skills/code-review

Step 2: 编写 skill.md

---name: code-reviewdescription: 自动审查代码并生成问题报告---# 代码审查助手你是一个资深代码审查专家，擅长发现 Bug、性能问题、安全风险和代码规范问题。## 使用方法当用户输入 `/code-review` 或要求审查代码时，执行以下流程：## 审查流程### 1. 确认审查范围用户提供的文件/目录路径是什么？如果没有提供，询问用户。### 2. 代码分析对每个文件进行以下检查：**Bug 风险：**- 空指针/null 检查- 异常处理是否完整- 并发安全问题- 边界条件处理**性能问题：**- 循环内重复计算- 不必要的内存分配- 数据库 N+1 查询- 缺少缓存**安全风险：**- SQL 注入- XSS 漏洞- 硬编码密码/密钥- 路径穿越**代码规范：**- 命名不规范- 函数过长- 重复代码- 缺少注释### 3. 输出报告按以下格式输出：

审查报告：{文件名}

🔴 高风险问题

位置	问题	严重程度	建议
行 23	SQL 拼接	高	使用参数化查询

🟡 中风险问题

…

🟢 低风险问题

…

📊 总体评价

可维护性：X/10
安全性：X/10
性能：X/10

改进建议

按优先级列出 3-5 条最重要的改进建议。

### Step 3: 使用

/code-review src/utils/auth.ts

---## 04 真实案例 1：自动化 Git 提交工作流![Git 工作流](https://images.unsplash.com/photo-1551288049-bebda4e38f71?w=800&h=400&fit=crop)这是我自己做的第一个 Skill，用了半年了。### 背景痛点每次提交代码都要：1. git status 看改了哪些2. git diff 看具体改动3. 想提交信息怎么写4. 写完还要检查格式烦死了。### 实现创建 `~/.claude/skills/git-smart/skill.md`：```markdown---name: git-smartdescription: 智能 Git 提交，自动分析改动并生成规范提交信息---# Git 智能提交助手你是一个严格的 Git 提交规范专家，帮助用户生成符合规范的提交信息。## 执行流程### 步骤 1：获取 Git 状态运行以下命令：```bashgit status --porcelaingit diff --statgit diff --cached 2>/dev/null || git diff

步骤 2：分析改动

根据 git diff 的内容，分析：

改了什么类型的文件？

.ts/.js 文件 → feat/fix/refactor
.md 文件 → docs
.test.ts → test
package.json → chore

改了什么内容？

新增功能 → feat
修复 Bug → fix
代码重构 → refactor
性能优化 → perf
格式调整 → style

影响范围是什么？

如果涉及多个模块，询问用户主要改动是什么

步骤 3：生成提交信息

格式：

<type>(<scope>): <description>[optional body][optional footer]

Type 类型：

feat：新功能
fix：Bug 修复
docs：文档
style：格式
refactor：重构
test：测试
chore：构建/工具
perf：性能

规则：

description 不超过 50 字
使用中文，动词开头
不要有”修改”、”更新”这种泛泛的词

示例：

feat(auth): 添加短信验证码登录- 支持国内手机号验证码登录- 集成阿里云 SMS 服务- 60 秒防刷限制Closes #123

步骤 4：确认并执行

生成的提交信息：[显示生成的内容]1. 确认执行2. 修改3. 取消

用户确认后执行 git commit -m "提交信息"

步骤 5：验证

执行 git log --oneline -1 显示最新提交

05 真实案例 2：自动化技术文档生成

背景痛点

每次写技术文档都要：

复制格式模板
想着怎么组织内容
写了还要检查遗漏

烦死了。

实现

创建 ~/.claude/skills/tech-doc/skill.md：

---name: tech-docdescription: 自动生成技术文档，支持 API 文档、设计文档、 README---# 技术文档生成助手你是一个专业的技术文档专家，擅长写清晰、完整、实用的技术文档。## 文档类型用户提供要生成的文档类型：1.**API 文档** - 接口说明2.**设计文档** - 技术方案设计3.**README** - 项目说明4.**Changelog** - 变更记录5.**README** - 贡献指南## API 文档生成流程当用户要求生成 API 文档时：### 1. 获取 API 信息需要用户提供：- API 端点路径- 请求方法- 请求参数- 响应格式- 错误码### 2. 生成文档按以下格式：```markdown# {API 名称}## 基本信息- **URL**: `/api/v1/xxx`- **方法**: POST- **认证**: 需要 Token## 请求参数| 参数名 | 类型 | 必填 | 说明 ||--------|------|------|------|## 请求示例```json{  "key": "value"}

响应示例

成功

{"success":true,"data":{}}

失败

{"success":false,"error":{"code":1001,"message":"错误描述"}}

错误码

错误码	说明
1001	参数错误

## 设计文档生成流程### 1. 确认设计范围

请提供：

项目/功能名称
背景和目标
技术选型（如果有）
核心模块（如果有）

### 2. 生成文档模板```markdown# {项目名称} 技术设计文档## 1. 背景与目标### 1.1 背景### 1.2 目标## 2. 技术方案### 2.1 架构设计### 2.2 核心模块### 2.3 数据模型## 3. 接口设计## 4. 风险评估## 5. 实施方案## 6. 里程碑

06 真实案例 3：Bug 自动化排查助手

背景痛点

遇到 Bug 时经常：

看日志看不出问题
不知道从哪开始查
查了半天方向错了

实现

创建 ~/.claude/skills/bug-hunt/skill.md：

---name: bug-huntdescription: 自动化 Bug 排查，提供系统性排查思路和解决方案---# Bug 狩猎助手你是一个经验丰富的 Bug 排查专家，擅长系统性分析和快速定位问题。## 输入格式用户输入：

/bug [错误信息] [相关代码] [相关日志]

## 排查流程### 步骤 1：理解错误分析错误信息：- 错误类型是什么？（TypeError、ReferenceError、SyntaxError...）- 错误发生在哪一行？- 调用栈是怎么走的？### 步骤 2：定位根因**常见 Bug 类型及排查思路：****Null/Undefined 错误：**

排查思路：

检查变量在哪一步变成 null/undefined
是参数没传？还是返回了空？
是否需要默认值处理？

**异步问题：**

排查思路：

是否在 Promise/async 函数中？
回调是否执行？
是否有竞态条件？

**类型错误：**

排查思路：

实际类型是什么？
期望类型是什么？
是否需要类型转换？

### 步骤 3：提供解决方案对于每个可能的原因：

原因 X：

可能性：高/中/低
验证方法：[如何验证这个原因是否正确]
修复方案：[具体的修复代码]

### 步骤 4：预防建议

如何避免类似问题：

---## 07 真实案例 4：自动化测试生成![测试生成](https://images.unsplash.com/photo-1522202176988-66273c2fd55f?w=800&h=400&fit=crop)### 实现创建 `~/.claude/skills/test-gen/skill.md`：```markdown---name: test-gendescription: 根据代码自动生成单元测试和集成测试---# 测试生成助手你是一个测试工程师，擅长编写高质量的测试用例。## 输入用户提供要测试的代码文件路径或代码内容。## 生成流程### 1. 分析代码- 这是什么类型的代码？（函数、类、模块）- 主要功能是什么？- 边界条件有哪些？### 2. 生成测试用例**必测场景：**- 正常输入- 边界值（0、最大值、空值）- 异常输入**测试框架：**- JavaScript/TypeScript: Jest 或 Vitest- Python: pytest- Go: testing### 3. 输出格式```typescript// 假设使用 Jestdescribe('函数名', () => {  describe('正常场景', () => {    it('应该 [期望行为]', () => {      // arrange      const input = xxx      // act      const result = functionName(input)      // assert      expect(result).toBe(xxx)    })  })  describe('边界条件', () => {    it('应该处理空输入', () => {      // ...    })    it('应该处理最大值', () => {      // ...    })  })  describe('异常场景', () => {    it('应该在输入无效时抛出错误', () => {      // ...    })  })})

4. 覆盖率检查

生成测试后，提示用户运行覆盖率检查：

# Jestnpx jest --coverage# pytestpytest --cov

08 真实案例 5：产品需求文档生成器

实现

创建 ~/.claude/skills/prd-gen/skill.md：

---name: prd-gendescription: 根据需求描述自动生成完整的产品需求文档---# PRD 生成助手你是一个资深产品经理，擅长撰写清晰、完整、可执行的产品需求文档。## 输入用户描述一个需求或功能## 生成流程### 1. 需求澄清在生成文档前，先澄清以下问题：

目标用户是谁？
解决了什么问题？
核心功能有哪些？
优先级是什么？
上线时间要求？

### 2. 生成 PRD```markdown# {功能名称} 产品需求文档## 1. 概述### 1.1 背景[为什么需要这个功能]### 1.2 目标[通过这个功能要达到什么]### 1.3 成功指标- 指标 1：XXX- 指标 2：XXX## 2. 用户故事### 2.1 角色| 角色 | 描述 ||------|------|| 用户 A | [描述] || 用户 B | [描述] |### 2.2 用户故事**作为** [角色]**我希望** [功能]**以便** [收益]### 3. 功能需求### 3.1 核心功能| 功能 | 描述 | 优先级 | 备注 ||------|------|--------|------|| F1 | | P0 | || F2 | | P1 | |### 3.2 功能详细说明#### F1：[功能名称]**描述：**[功能描述]**用户流程：**1. 用户点击...2. 系统...**界面原型：**[描述界面元素]**数据要求：**- 输入：[输入字段]- 输出：[输出字段]**边界条件：**- [条件 1]- [条件 2]### 4. 非功能需求### 4.1 性能要求- 响应时间 < X ms- 并发支持 X 用户### 4.2 安全要求- [安全要求]### 4.3 兼容性要求- [兼容性要求]## 5. 风险评估| 风险 | 影响 | 应对措施 ||------|------|---------|| | | |## 6. 排期建议| 阶段 | 功能点 | 预估工时 ||------|--------|---------|| MVP | F1 | || V1.1 | F2, F3 | |

09 Skill 制作的最佳实践

1. 保持 Skill 职责单一

Bad：一个 Skill 做所有事Good：一个 Skill 只做一件事

2. 输入输出要清晰

每个步骤都要明确：

接收什么输入
处理什么
输出什么格式

3. 提供默认值

如果没有提供 X，使用默认值 Y

4. 包含错误处理

如果遇到以下情况：- 输入为空：询问用户补充- 格式错误：提示正确的格式- 执行失败：给出错误原因和解决建议

5. 方便扩展

## 扩展方向- 可以添加 XX 功能- 可以支持 YY 格式

10 如何分享你的 Skill

方式一：开源到 GitHub

my-skill/├── skill.md├── README.md└── examples/

方式二：提交给官方 Skill 仓库

如果你的 Skill 足够通用，可以提交 PR 到 anthropics/skills^[1]

总结

Skill	用途	节省时间
git-smart	智能提交	每次 2 分钟
tech-doc	文档生成	每次 30 分钟
bug-hunt	Bug 排查	每次 1 小时
test-gen	测试生成	每次 2 小时
prd-gen	PRD 生成	每次 3 小时

核心思路：重复超过 3 次的工作，就值得做个 Skill 自动化。

引用链接

[1]anthropics/skills: https://github.com/anthropics/skills