从使用者到创造者

在前面章节我们介绍了 Skill 的原理、推荐安装的 Skills 清单，还演示了如何利用高德地图 Skill 做旅游规划。

到目前为止，你一直是 Skill 的使用者——安装别人写好的 Skill，体验它带来的效率提升。但如果你有一个具体的工作场景，翻遍了 Skills 市场也找不到合适的，怎么办？

答案是：自己开发一个

但”自己开发”不是说打开编辑器，一行一行手写SKILL.md和参考资源文件。别忘了——OpenClaw 本身就是你的生产力工具。你只需要把需求说清楚，让OpenClaw帮你完成创建工作。

这我们会用一个完整的案例——”Jenkins自动发布生成器”——走一遍从零开发 Skill 的全流程。整个过程就是一场有来有回的对话：

• 你负责：想清楚需求、审查产出、提出修改意见
• OpenClaw负责：生成文件、编写内容、执行调整

开发完成后，我们会用一段真实发布案例来测试 Skill 的实际效果，最后还会把它发布到 ClawHub，走一个完整的开发、使用、发布流程。

想清楚需求：对话之前的准备

很多人一上来就跟AI说”帮我写个Jenkins自动发布的Skill”，然后对生成的结果不满意——太泛、不实用、抓不住重点。

问题不在AI，在于你没想清楚自己要什么。需求越模糊，产出就越泛。

在打开 OpenClaw 之前，先花几分钟想清楚这几个问题。

解决什么痛点？

我们团队的 Jenkins发布，现在有这些问题：

• Jenkins任务Job项目较多
• 人工手动发布效率低下
• 发布完成之后没有监控告知结果

我们希望有一个 Skill，让 AI 基于统一的流程标准来进行Jenkins项目发布，并生成一份结构化的报告——有问题定位、有严重程度分级、有修复建议。

对话实战：让OpenClaw帮你造Skill

前面的章节中我们推荐过SkillCreator——辅助开发Skill的”教练”。现在要用到它了。

通常情况下，OpenClaw已经自带了SkillCreator，你无需额外安装。

第一步：可以先问OpenClaw确认一下：

你有skill-creator这个Skill吗？

如果OpenClaw回复已具备该能力，直接进入下一步即可。如果提示没有，可以参考之前课程的内容来安装 skill-creator：通过SkillHub或者ClawHub来安装。

SkillCreator就绪后，后续当你提出创建Skill的需求时，OpenClaw会自动结合它的能力来工作——它了解AgentSkills标准规范，能帮你检查结构是否合规、字段是否完整。

第二步：描述需求，生成Skill

现在把前面想好的需求告诉OpenClaw。

不需要一次说完所有细节，但核心信息要到位：

使用 Skill Creator 帮我创建一个 Jenkins自动发布的 Skill。

1.Jenkins发布的任务，其中586，Alph视图不需要确认通过任务名称就可以发布
2.其中发布的任务名称可以简写如（586-micro-auth-server只需要auth，586-micro-bill-server只需要说bill，586-micro-authcommon-server只需要authcommon），
3.ali_server视图的发布必须要确认通过之后才进行发布
4.输出格式：任务名称，视图名称，构建编号，发布任务状态，构建地址，控制台日志输出地址

发送之后，OpenClaw 会帮你生成整个 Skill 的目录结构和文件内容。

jenkins-deploy-task/
├── references                       # 参考资料
│   ├── env-config.md                # 环境变量
│   └── usage-examples.md            # Jenkins部署任务使用示例
├── scripts                          # 自动化脚本
│   ├── jenkins-confirm-deploy.sh    # 确认之后可发布
│   ├── jenkins-quick-deploy.sh      # 快速发布脚本
│   ├── jenkins-task-resolver.sh     # 任务名称解析 简写转换为完整的Job名称
│   └── test-build.sh                # 简单的Jenkins构建测试脚本
└── SKILL.md                         # 操作手册：任务流程和指令

其中，SKILL.md是 Skill 的核心——AI 执行审查时的完整指令。OpenClaw 生成的内容大致如下：

---
name: jenkins-deploy-task
description: Jenkins任务自动化部署技能，支持快速发布和无确认发布两种模式。当用户需要部署Jenkins任务时使用，特别是针对586视图和Alph视图的快速发布，以及ali_server视图的确认发布。支持任务名称简化（如586-micro-auth-server只需输入"auth"）。触发器："部署Jenkins任务"、"发布微服务"、"Jenkins构建"、"快速发布"、"确认发布"。
---

指令主体:（发布流程）

SKILL.md 的主体部分会定义清晰的发布流程，包括：

• When to Use：什么场景下触发这个 Skill——Jenkins构建、部署Jenkins任务、发布微服、快速发布
• 输入要求：使用全名称，简写，都能进行发布，不带视图标识默认 586 环境
• 发布流程：586，alph环境快速发布，ali_server（prod）环境需要确认之后才能进行发布 解析 → alph前缀 → alph:bill → Alph-micro-bill-server → 快速发布 → 返回结果
• 输出格式：任务名称，视图名称，构建编号，发布任务状态，构建地址，控制台日志输出地址

资源目录：

references/目录有env-config.md ，usage-examples.md文件，环境变量配置及使用方法介绍

usage-examples.md的内容大致如下：

# Jenkins部署任务使用示例

## 输入格式说明

### 简写格式
```
视图:服务名
```

### 支持的视图前缀
1. **586** - 586视图（快速发布）
2. **alph** - Alph视图（快速发布）
3. **ali** - ali_server视图（确认发布）

### 默认视图
- 无前缀时默认使用586视图
- 示例：`auth` → `586:auth` → `586-micro-auth-server`

## 完整使用示例

### 586视图任务发布（快速发布）

#### 示例1：无前缀简写
```
用户：发布auth
解析：auth → 586:auth → 586-micro-auth-server
结果：快速发布，无需确认
```

#### 示例2：带前缀简写
```
用户：发布586:ai
解析：586:ai → 586-micro-ai-server
结果：快速发布，无需确认
```

#### 示例3：完整名称
```
用户：发布586-micro-aifile-server
解析：直接识别为完整名称
结果：快速发布，无需确认
```

### Alph视图任务发布（快速发布）

#### 示例1：带前缀简写
```
用户：发布alph:auth
解析：alph:auth → Alph-micro-auth-server
结果：快速发布，无需确认
```

#### 示例2：带前缀简写（不同服务）
```
用户：发布alph:bill
解析：alph:bill → Alph-micro-bill-server
结果：快速发布，无需确认
```

#### 示例3：完整名称
```
用户：发布Alph-micro-ai-server
解析：直接识别为完整名称
结果：快速发布，无需确认
```

### ali_server视图任务发布（确认发布）

#### 示例1：带前缀简写
```
用户：发布ali:auth
解析：ali:auth → ali-micro-auth-server
结果：需要用户确认后才发布
```

#### 示例2：带前缀简写（不同服务）
```
用户：发布ali:ai
解析：ali:ai → ali-micro-ai-server
结果：需要用户确认后才发布
```

#### 示例3：完整名称
```
用户：发布ali-micro-bill-server
解析：直接识别为完整名称
结果：需要用户确认后才发布
```

## 交互流程示例

### 快速发布流程（586/Alph视图）
```
用户：发布auth
助理：检测到586视图任务，快速发布中...
助理：✅ 构建已触发
助理：任务：586-micro-auth-server
助理：构建链接：https://jenkins.laifuyun.com/jenkins/job/586-micro-auth-server/28/
```

### 确认发布流程（ali_server视图）
```
用户：发布ali:auth
助理：检测到ali_server视图任务，需要确认发布
助理：⚠️ 确认发布 ali-micro-auth-server 吗？
用户：确认
助理：✅ 构建已确认并触发
助理：任务：ali-micro-auth-server
助理：构建链接：https://jenkins.laifuyun.com/jenkins/job/ali-micro-auth-server/15/
```

### 批量发布示例
```
用户：批量发布auth,bill
解析：auth → 586-micro-auth-server
      bill → 586-micro-bill-server
结果：按顺序快速发布两个任务
```

## 错误处理示例

### 任务不存在
```
用户：发布unknown:service
助理：❌ 任务未找到：unknown:service
助理：使用 list 命令查看可用任务
```

### 视图识别错误
```
用户：发布some-micro-auth-server
助理：❌ 无法识别任务视图
助理：请使用标准格式：视图:服务名 或 完整任务名称
```

### 权限不足
```
用户：发布auth
助理：❌ Jenkins认证失败
助理：请检查环境变量配置
```

### 网络连接问题
```
用户：发布auth
助理：❌ 无法连接到Jenkins服务器
助理：请检查网络连接和Jenkins服务状态
```

## 测试命令

### 1. 测试任务解析
```bash
# 解析任务名称
./scripts/jenkins-task-resolver.sh resolve auth
./scripts/jenkins-task-resolver.sh resolve alph:auth
./scripts/jenkins-task-resolver.sh resolve ali:auth

# 获取任务信息
./scripts/jenkins-task-resolver.sh info auth
```

### 2. 测试连接
```bash
# 测试Jenkins连接
./scripts/jenkins-quick-deploy.sh test

# 查看可用任务
./scripts/jenkins-task-resolver.sh list
```

### 3. 查看简写映射
```bash
# 查看所有简写映射
./scripts/jenkins-task-resolver.sh map
```

## 最佳实践

### 1. 使用简写格式
- 优先使用 `视图:服务名` 格式
- 明确指定视图，避免歧义
- 示例：`586:auth` 比 `auth` 更明确

### 2. 批量操作
- 相同视图的任务可以批量发布
- 不同视图的任务建议分开发布
- 确认发布任务需要逐个确认

### 3. 环境配置
- 在`~/.openclaw/.env`中设置Jenkins凭证
- 定期检查环境变量有效性
- 使用测试命令验证连接

### 4. 监控与日志
- 关注构建控制台输出
- 定期检查构建历史
- 记录重要的发布操作

第三步：审查与迭代

OpenClaw 一次生成的内容不一定完美，这很正常。你的价值就在于审查和反馈——看看生成的东西，找出需要调整的地方，告诉 OpenClaw 去改。

打开生成的文件，逐个看一遍。你可能会发现一些问题。

第一轮反馈：完善SKILL.md

看完 SKILL.md 后，你可能觉得审查流程的描述还不够具体，报告模板也可以更清晰。直接告诉 OpenClaw：

完善一下，其中有三个视图，586，Alph，ali_server，其中视图下的job都相同的，发布586的任务需要跟上586标识，如（586-micro-ai-server，586-micro-auth-server，586：ai，auth），发布alph视图的时候（Alph-micro-bill-server，Alph-micro-auth-server，alph：bill，auth），发布ali_server视图下的任务必须要通过确认（ali-micro-ai-server，ali-micro-auth-server，ali：ai，auth）

三、实战测试：用你的 Skill 审查一段代码

AD：《熊孩子博客》熊孩子QQ:443060965