虽然网络上针对 skill 的定义很多，但这里我想用大白话来讲解 skill 是什么以及我们要如何创建自己的 skill。

什么是 skill

skill 是把成熟的方案沉淀下来以便后续进行重复利用的方案。 大模型每次的效果都是不稳定的，这涉及到底层的 sampling 原理，这个我之前讲解过，这里不过多赘述。我们经常需要多次对话才能找到那个最正确的方案，而下一次我们再想重复一次一模一样的诉求，大模型往往仍然不会执行那个我们预期的最正确的执行路线。也许有稍微懂一些的同学可能会说，大模型有上下文，openclaw 还有长期记忆，它会根据历史对话总结最佳的执行路径。但我之前一直说过，不要过于依赖过长的上下文，因为你会遇到上下文污染，遇到 token 爆炸。这也是为什么很多人会觉得智能体越用越笨，越用越费钱的原因。

正确的使用方法是把 “知识” 和 “工作路径” 沉淀下来，每次都尽量用一个干净的上下文来完成任务。skill 的意义是：历史的对话中我们完成了一个任务，我们确定了这个任务的执行路径和相关工具。 于是我们让 AI 帮我们把知识沉淀到一个文档中，如果涉及到一些脚本和代码，那也把这些代码沉淀下来。 这样以后当用户说出我想做 XXX 的时候，智能体能精准命中用户的意图，并调用这个 skill 完成相关的工作流。

skill 也充分体现了复用性的设计，当其他人把自己的 skill 发布到网络上后，我们就可以拿来即用。

所以总结一下：

Skill 本质上是 “任务经验包”：把一个任务里已经验证过的知识、步骤和工具，固化下来，方便下一次重复执行。

你可以把它类比成团队里的 “标准作业手册”，但这个手册不是给人看的，而是给智能体直接执行的。

为什么它重要？

因为只靠临场对话，结果会不稳定。主要有三个现实问题：

1. 同题不同解，路径不固定
   
   今天它走 A 路线，明天可能走 B 路线。都不一定错，但你要的是 “稳定可预期”。

2. 上下文会污染
   
   会话越长，历史内容越多，模型越容易被前文里一些无关信息带偏。

3. 上下文越长，成本越高，质量不一定越好
   
   很多人误以为 “多喂点历史就更聪明”，实际经常是 token 变多了，效果反而变差了。

所以，正确做法不是无限拉长对话，而是：

• 把常见任务沉淀成 Skill
• 尽量在干净上下文下触发 Skill
• 用固定流程拿稳定结果

Skill 的真实形态：不是一句提示词，而是一套可执行流程

很多人把 Skill 理解成 “保存一段提示词”。这只说对了一半。

一个能长期使用的 Skill，至少有两层：

流程层（Prompt / 规则层）

这层负责 “怎么做”，通常会明确：

• 这个 Skill 解决什么问题（任务边界）
• 接收什么输入（参数定义）
• 产出什么结果（输出格式）
• 执行顺序是什么（先后步骤）
• 遇到异常怎么处理（回退策略）

动作层（Tool / 脚本层）

这层负责 “真正动手做”，例如：

• 读取日志、检索文件
• 调接口拉取数据
• 聚合统计
• 生成报告
• 回写系统状态

如果只有流程层，没有动作层，结果经常是 “说得很完整，但没执行”；
如果只有动作层，没有流程层，就会变成 “工具堆在那里，不知道先调哪个”。

所以一个成熟的 Skill，一定是：

流程约束 + 工具执行 + 结果校验

---

怎么判断一个任务值得做成 Skill？

不是所有任务都要 Skill。一般满足下面任意两条，就值得做：

1. 重复出现：同类任务每周都会来几次
2. 步骤固定：执行顺序较稳定，不靠纯灵感
3. 结果要求一致：输出格式、质量标准明确
4. 可自动化程度高：至少 60% 步骤能工具化

反过来，如果是一次性探索任务、目标模糊、输入差异极大，先别急着做 Skill，先把场景跑熟。

---

OpenClaw 实战演示：从 0 创建一个可用 Skill

下面用一个实战例子：

Skill 名称：日志异常定位（log-incident-analyzer）

输入一份日志，并检索历史错误经验知识库，输出：异常摘要、历史命中依据、根因候选、建议动作、风险提示。

这个例子的优点是：

• 足够真实（几乎每个团队都会遇到）
• 结果可验证（可以对照日志证据）
• 易于迭代（新错误模式可以持续补充）

---

实操步骤（OpenClaw）

PS：日志分析的 skill 涉及到每次分析都去查询历史错误经验知识库，这里的实现一般是把历史错误信息保存在一个库里，可以是数据库，也可以是本地文件，也可以是一个向量库。最佳方案是搭建专业的，可用于知识检索的知识库，例如搭建一个向量库，然后让大模型编写一个脚本去做语义检索。但这个成本比较高，我们可以只在本地文件中进行保存历史知识。然后让大模型编写一个根据关键字检索的脚本。 这些都可以实现，这里我们只简单介绍一下。下面的提示词里也不详细讲解了，只是简单说明需要提供历史错误信息经验库的内容，毕竟每个方案实现的细节不同。

第一步：先写 “任务说明”，别急着写提示词

在 OpenClaw 里新建前，先用 5 分钟把下面四件事写清楚：

1. 触发语（用户会怎么说）

   • “帮我分析这份日志”
   • “看下这个报错怎么回事”

2. 输入参数

   • log_path（必填）
   • error_keyword（可选）
   • time_range（可选）
   • history_kb（必填，历史错误经验知识库，可以提供默认路径）

3. 输出结构

   • 异常摘要
   • 历史案例命中情况（命中条目 / 相似度 / 命中依据）
   • 根因候选（按置信度）
   • 建议动作（立即 / 后续）
   • 风险提示（证据不足项）

4. 成功标准

   • 每个结论必须引用证据
   • 建议必须可执行
   • 证据不足要明确标注

这一步决定了 Skill 以后是否好维护。写得越清楚，后面越省事。

第二步：在 OpenClaw 用 skill-creator 生成初稿

很多环境里都内置了 skill-creator。可以直接给它一段 “结构化需求”，例如：

请创建一个 skill，名称是 log-incident-analyzer。

目标：
对日志进行异常定位，并优先复用历史错误经验知识库中的已验证方案，输出结构化排查报告。

输入：
- log_path（必填）
- error_keyword（可选）
- time_range（可选）
- history_kb（必填，历史错误经验知识库，可以提供默认路径）

输出（Markdown）：
1) 异常摘要
2) 历史案例命中情况（命中条目、相似度、命中依据）
3) 根因候选（按置信度排序，附证据）
4) 建议动作（立即动作 / 后续动作）
5) 风险提示（证据不足项）

执行流程：
1. 读取日志并确认可访问
2. 提取异常模式（ERROR/Exception/Traceback 等）和关键日志片段
3. 用异常特征检索 history_kb
4. 若命中高相似历史案例，优先给出已验证方案，并补充本次差异分析
5. 若未命中，再执行常规根因分析
6. 本次形成稳定结论后，按模板回写或更新 history_kb

约束：
- 禁止编造日志内容
- 所有结论必须附证据片段
- 命中历史案例时必须说明命中依据
- 证据不足时必须明确写“证据不足”
- 输出使用中文

你会得到一个可运行的初稿，但先别直接上线。

第三步：把初稿改成 “可维护版本”

初稿通常够跑通，但不一定够稳。建议重点补三块：

1. 边界定义

   • 输入为空怎么处理
   • 文件不存在怎么处理
   • 日志格式异常怎么处理

2. 异常回退

   • 工具调用失败时返回什么
   • 是否允许降级输出

3. 输出一致性

   • 每次都按固定章节输出
   • 证据引用格式保持统一

---

六、一份可直接使用的 Skill 模板

# Skill: log-incident-analyzer

## 任务目标
针对输入日志进行异常定位，并优先复用历史错误经验知识库中的已验证方案，输出可执行、可追溯的排查结论。

## 适用场景
- 用户反馈“系统报错/接口失败/服务异常”
- 需要快速给出第一轮排查建议
- 期望在重复故障中直接命中历史方案

## 输入参数
- log_path: string, 必填，日志文件路径
- error_keyword: string, 可选，指定检索关键词
- time_range: string, 可选，时间范围（如最近30分钟）
- history_kb: string/object, 必填，历史错误经验知识库或其连接信息

## 输出格式（Markdown）
1. 异常摘要
2. 历史案例命中情况（命中条目 / 相似度 / 命中依据）
3. 根因候选（按置信度排序）
4. 建议动作（立即动作 / 后续动作）
5. 风险提示（证据不足项）

## 执行流程（严格顺序）
1. 校验输入参数合法性
2. 读取日志并检查是否可访问
3. 提取异常模式与关键日志片段
4. 使用异常特征检索 `history_kb`
5. 若命中高相似案例，优先输出历史已验证方案，并给出本次差异说明
6. 若未命中，执行常规根因分析流程
7. 形成根因候选并逐条附证据
8. 输出建议动作并标记优先级
9. 本次结论稳定后，新增或更新一条历史经验到 `history_kb`

## 约束规则
- 不得编造日志内容
- 所有结论必须引用证据
- 命中历史案例时必须明确命中依据
- 严禁在证据不足时硬套历史方案
- 输出语言必须为中文

## 失败回退策略
- 文件不存在：返回“输入文件不可访问”，并提示检查路径
- 无异常匹配：返回“未检测到明确异常模式”，并给出下一步采样建议
- 历史库不可用：明确标注“本次未能检索历史经验库”，并降级走常规分析
- 工具执行失败：返回失败原因、已完成步骤、建议重试方式

---

OpenClaw 里怎么做验收（这一步决定能不能长期用）

推荐做三轮测试，每轮都要记录结果：

命中测试

给几种真实说法，看是否能触发正确 Skill：

• “帮我看下这份日志为什么报错”
• “这个异常是哪里来的”
• “定位一下线上报错原因”

目标：触发率稳定，不误命中别的 Skill。

流程测试

看它是否严格按既定顺序执行：

• 是否先校验输入
• 是否读取并检索日志
• 是否输出证据链

目标：不跳步，不凭空下结论。

结果测试

检查输出质量是否达标：

• 至少给出 2 条根因候选
• 每条都有证据片段
• 建议动作具备可执行性
• 不确定项明确标 “证据不足”

目标：结果能直接给工程同学使用，而不是 “看起来像报告”。

---

八、上线后怎么迭代，才不会越改越乱

给你一个简单好用的迭代策略：

只沉淀两类东西

1. 新知识：新增错误模式、典型故障链路
2. 新路径：哪一步容易失败，就补规则或补工具

8.2 每次迭代都要有 “回归样例”

至少保留 3 组固定测试输入：

• 正常可定位样例
• 证据不足样例
• 输入异常样例

每次改动都跑这 3 组，避免 “修了 A，坏了 B”。

8.3 控制复杂度

别把一个 Skill 写成万能总控。遇到场景分叉明显时，拆成两个 Skill 更稳。

---

一个更接地气的理解方式

如果把智能体当 “新人同事”，那 Skill 就是你写给 TA 的 “岗位 SOP + 可调用工具清单”。

• 没有 Skill：每次都要重新讲一遍
• 有 Skill：直接按成熟流程干

你真正节省的，不只是 token，而是团队协作里的时间和返工成本。

---

写在最后

Skill 的核心价值在 “可复用、可验证、可交付”。

在 OpenClaw 里做 Skill，建议始终抓住三件事：

1. 边界清楚：它做什么，不做什么
2. 流程清楚：先后顺序和回退策略
3. 证据清楚：所有结论都能追溯来源

把这三件事做扎实，Skill 就能从 “演示可用” 变成 “生产可用”。

最后再宣传一下自己的星球：