夜雨聆风其实不是。
OpenClaw 里的“技能开发”，本质上更像是在做一件事：把你原本靠人手完成的一套工作流程，整理成 Agent 可以理解、调用和执行的能力模块。
说得更直白一点：技能，不只是“写个功能”，而是把一套业务动作封装起来。
比如这些场景，其实都可以做成技能：
自动生成公众号文章
自动整理某类信息
自动推送审核消息
自动执行固定脚本
自动完成某个业务 SOP
所以，真正值得学的不是“怎么堆代码”，而是：怎么把一个流程拆清楚，写清楚，组织清楚，最后让 OpenClaw 稳定调用。
今天这篇文章，就用尽量通俗、适合实操的方式，带你把 OpenClaw 技能开发的流程完整走一遍。
一、先理解一件事：OpenClaw 里的“技能”到底是什么？
很多新手最容易混淆两个概念：Workspace（工作区） 和 Skill（技能）。
你可以把它们理解成两层。
第一层，是 Agent 的“基础设定”。这部分决定的是：
它是谁
它怎么说话
它遵循什么规则
它优先怎么做事
第二层，才是技能。技能决定的是：
它额外会什么
它遇到什么任务时该怎么执行
它能不能把某类流程走完整
所以可以这样记：工作区定义“人格与规则”，技能定义“能力与动作”。
这也是为什么很多人只盯着技能文件，却忽略了工作区本身。实际上，一个真正好用的 OpenClaw Agent，往往不是“单靠一个技能跑起来”，而是：工作区负责行为底层，技能负责任务执行层。
二、技能开发真正的起点，不是写代码，而是先定目标
很多人一上来就开始建目录、写脚本、配环境变量。结果做到一半才发现：
这个技能到底解决什么问题，其实没想清楚
触发条件不明确
输入输出不明确
哪一步需要人工介入，也没设计清楚
最后技能不是不能跑，而是：能跑一次，但不好用；能做演示，但不敢真上生产。
所以，正确顺序应该反过来。在动手之前，先回答四个问题：
这个技能要解决什么问题？
它应该在什么场景下被调用？
它需要哪些输入？
它最终要输出什么结果？
举个例子。如果你要做的是“公众号文章自动化技能”，那它的目标就不该只是“会写文章”，而应该是：
根据用户给的主题生成文章
输出适合公众号排版的结构
生成配图提示词
推送到企业微信审核
审核通过后进入发布流程
当你把目标定义成“完成一个闭环”，后面的开发才会越来越顺。
三、OpenClaw技能开发，建议按这6步来做
这部分是核心。如果你是第一次做技能，按这个顺序最稳。
第一步：先定义技能边界
一个技能最怕的，不是功能少，而是边界太模糊。
比如下面两种说法，看起来都像需求，但质量完全不一样。
第一种：做一个处理内容工作的技能。
第二种：做一个根据选题生成公众号文章，并推送企业微信审核的技能。
很明显，第二种才是可以落地的。因为它至少已经说清楚了：处理什么任务，适用于什么场景，输出什么结果，流程大概怎么走。
所以技能开发的第一步，就是把边界画出来。什么时候该调用，什么时候不该调用，一开始就要明确。
第二步：把任务拆成节点
一个成熟的技能，不能只有一句“帮我完成这个任务”。你要把整个流程拆成几个稳定动作。
以“公众号文章自动化”为例，可以拆成下面几个节点：
节点一：读取选题方向（主题、目标读者、风格、字数要求）
节点二：生成标题和提纲（先定结构，避免正文跑偏）
节点三：生成正文初稿（输出适合公众号阅读的内容）
节点四：生成配图提示词（方便后续用 AI 生成插图）
节点五：推送企业微信审核（人工把关）
节点六：记录审核结果（通过、驳回、待修改，都要有状态）
节点七：审核通过后执行发布（进入真正的发布流程）
技能拆分到这个程度，后面你无论是调试、扩展还是排查问题，都会轻松很多。
第三步：先写 SKILL.md，再写脚本
这是很多人最容易做反的一步。在 OpenClaw 里，SKILL.md 不是一个可有可无的说明文件，它更像是这个技能写给 Agent 看的“规则说明书”。
你可以把它理解成：这个技能的职责、边界、输入输出、执行方式，都要先在这里说清楚。
一个合格的 SKILL.md，至少应该讲明白这些内容：
这个技能是干什么的
什么时候该用
什么时候不要用
输入是什么
输出是什么
执行步骤是什么
依赖什么环境
失败时怎么处理
为什么建议先写它？因为如果这个文件你都写不顺，基本就说明这个技能本身还没想清楚。这时候去写脚本，大概率是边做边返工。
第四步：把技能结构整理清楚
很多技能后面越改越乱，不是因为能力不够，而是因为目录从一开始就没规划。
比如提示词和脚本混在一起，模板和配置混在一起，示例文件和正式文件混在一起，这样时间一长，自己都看不懂。
所以更好的方式，是按职责拆开。
四、一个更适合公众号展示的文件结构理解方式
这里不再用一大块复杂目录树，我直接按“层”来展示。
1. 工作区根目录
这是 Agent 的基础区域，主要放全局规则和身份设定。你通常会看到这些核心文件：
AGENTS.md：定义总体工作规则、行为优先级、处理原则。
SOUL.md：定义表达风格、人格语气、整体调性。
USER.md：定义用户偏好、常见需求、长期约束。
TOOLS.md：说明当前有哪些工具、这些工具适合怎么用。
IDENTITY.md：定义这个 Agent 是谁，以什么身份对外工作。
MEMORY.md：记录长期有效的重要记忆内容。
2. memory 目录
这里通常放每日记忆或阶段性记录。比如某天新增的用户偏好、某个项目的重要上下文、某段时间积累的操作经验。它更像是 Agent 的长期上下文补充区。
3. skills 目录
这里才是技能真正存放的地方。也就是说，你开发的每一个技能，通常都应该放在这里。比如你要做一个“公众号自动写作审核技能”，目录名可以是 skills/wechat-article-pipeline。而这个技能目录里面，再继续按功能分层。
五、一个实际技能目录，推荐这样拆
下面这个结构，是更适合实际维护的写法。
技能主文件
SKILL.md：技能核心说明文件，必须有。它负责告诉 Agent：这个技能是做什么的、什么时候该调用、怎么调用。
README.md：这是给人看的补充说明，写给开发者或维护者，解释技能用途、安装方法、修改方式。
prompts 文件夹
这个目录专门放提示词模板。比如：
title_prompt.md：用来生成标题。
outline_prompt.md：用来生成提纲。
article_prompt.md：用来生成正文。
这样拆开有个很大的好处：以后你想调整内容风格，不一定非要改脚本，只改提示词就够了。
scripts 文件夹
这个目录放真正执行动作的脚本。比如：
draft_article.js：生成文章草稿。
send_to_wecom.js：把内容推送到企业微信审核。
check_review_status.js：检查审核状态。
publish_to_cms.js：审核通过后执行发布。
这一层负责“做动作”。
config 文件夹
这个目录放配置样例。例如：
channels.example.json：审核通道示例配置。
publish.example.json：发布接口示例配置。
这里通常不建议直接塞真实密钥，而是放示例结构，方便迁移和维护。
templates 文件夹
这个目录放输出模板。比如：
wechat_article_template.md：公众号文章的模板格式。
review_card_template.json：企业微信审核卡片模板。
这一层负责“输出长什么样”。
六、如果把它整理成一个更直观的结构，大概就是这样
你可以把整个技能理解成下面这几层：
第一层：规则层 — SKILL.md
第二层：提示层 — prompts/
第三层：执行层 — scripts/
第四层：配置层 — config/
第五层：输出层 — templates/
这样看是不是就清楚很多了？相比一长串复杂目录树，这种方式更适合公众号读者理解，也更适合你后续写教程时讲解。
七、下面给你一个更适合发布的结构示意
这个你可以直接放文章里。
OpenClaw 工作区│├─ 全局规则文件│ ├─ AGENTS.md│ ├─ SOUL.md│ ├─ USER.md│ ├─ TOOLS.md│ ├─ IDENTITY.md│ └─ MEMORY.md│├─ 记忆目录│ └─ memory/│└─ 技能目录└─ skills/└─ wechat-article-pipeline/├─ SKILL.md├─ README.md├─ prompts/├─ scripts/├─ config/└─ templates/
这个结构已经比那种“超细目录树”更适合公众号排版了。读者一眼就能看出：上层是工作区，下层是技能目录，技能内部再分模块。八、实战举例：做一个“公众号自动写作 + 企业微信审核”的技能
讲概念不如讲案例。下面就用一个非常实用的场景举例：
技能名称：wechat-article-pipeline
它的目标不是简单“写篇文章”，而是完成下面这个流程：
接收一个选题方向
生成标题和提纲
生成正文内容
生成配图提示词
推送给企业微信审核
审核通过后进入发布流程
这个技能的输入，可以包括：
文章主题
目标受众
风格要求
字数要求
是否生成配图提示词
这个技能的输出，可以包括：
标题
摘要
提纲
正文
配图提示词
审核状态
发布状态
这样定义之后，整个技能就非常清楚了。
九、一个适合实战的 SKILL.md，应该怎么写？
这里给你一个公众号里也能直接展示的简化版结构。
# wechat-article-pipeline## Purpose根据用户提供的选题方向，生成适合公众号发布的文章草稿，并推送到企业微信进行人工审核；审核通过后可进入发布流程。## Use this skill when- 用户明确要求写公众号文章- 用户给出了主题或热点方向- 用户需要标题、提纲、正文和配图提示词- 用户希望内容经过审核后再发布## Do not use this skill when- 用户只是简单咨询问题- 用户只需要一句文案或一个标题- 用户没有明确主题方向- 当前任务与文章生成无关## Inputs- topic- target_audience- tone- word_count- include_image_prompts## Outputs- title- summary- outline- article_markdown- image_prompts- review_status- publish_status## Workflow1. 分析选题和目标读者2. 生成标题备选3. 生成文章提纲4. 生成正文初稿5. 生成配图提示词6. 推送企业微信审核7. 审核通过后执行发布## Failure handling- 审核推送失败时，返回草稿并提示人工发送- 发布失败时，保留内容并返回错误信息
你会发现，真正让技能稳定运行的，不是“代码有多复杂”，而是：这个规则文件有没有把边界写明白。
十、技能开发里最重要的几个节点，一定要盯住
这一部分非常重要。因为很多技能做不稳，不是写不出来，而是卡在这些关键点上。
第一，技能有没有被正确识别文件放进去，不代表 OpenClaw 一定识别到了。你要先确认：
技能目录位置是否正确
技能名是否规范
加载路径是否正确
是否已经启用
这是第一道门槛。
第二，SKILL.md 是否写得足够清楚很多时候技能“不好用”，不是脚本问题，而是规则写得太含糊。例如：
使用场景写得太宽
禁用场景没写
输入输出没有固定下来
流程顺序写得不明确
这样一来，Agent 就会出现“有时调用、有时不调用、甚至乱调用”的情况。
第三，环境变量和接口配置是否真的生效这一点特别容易出问题。比如企业微信 webhook、发布接口地址、API key、鉴权参数。很多人以为自己已经配好了，结果运行时才发现根本没生效。所以技能开发一定要有“环境检查”意识，不能只看配置文件有没有写，还要看实际执行时有没有拿到。
第四，审核节点有没有设计如果这个技能涉及的是发公众号、发社媒、发邮件、发通知、发企业消息，那最好都不要直接“一步到位自动发出”。更稳的流程一定是：自动生成 → 人工审核 → 审核通过 → 再发布。这一步看起来麻烦，但实际上是在保护整条流程。
第五，错误处理有没有做降级一个成熟技能，不是从不出错，而是出了错也不会整条链路崩掉。比如审核推送失败，能不能先把草稿返回出来；发布失败，能不能保留待发布内容；某个节点中断，能不能让人工继续接手。这些细节，决定的是技能能不能真正长期用。
十一、给新手一个最稳的开发顺序
如果你准备开始做第一个 OpenClaw 技能，我很建议你按这个路线走：
先只做文章生成
再加配图提示词
然后再加企业微信审核
最后才接正式发布
为什么这样最好？因为这是一条风险最低、最容易调试的路线。先保证内容能稳定产出，再保证审核链路打通，最后才考虑自动发布。这样做出来的技能，才更像一个能长期使用的生产工具，而不是一次性 demo。
十二、最后总结：OpenClaw 技能开发，核心其实是“流程封装”
如果要把这篇文章压缩成一句话，那就是：OpenClaw 技能开发，不是单纯开发一个功能，而是把你的业务流程整理成 Agent 可调用的标准模块。
真正决定一个技能好不好用的，不只是代码，而是下面四件事：
边界清不清楚：什么时候该用，什么时候不该用。
结构清不清楚：规则、提示词、脚本、配置、模板有没有分层。
流程清不清楚：输入输出稳不稳定，节点顺不顺。
风控清不清楚：审核、失败处理、发布控制有没有做好。
当这四件事都清楚了，你做出来的技能才不只是“能跑”，而是“真能干活”。
结尾
很多人一开始会觉得 OpenClaw 技能开发很复杂。但真正做过之后你会发现，它更像是一种能力：把你脑子里的业务流程，变成 Agent 可以执行的结构。
一旦你掌握了这个思路，后面很多事情都能慢慢技能化：内容生成、审核流转、通知推送、数据整理、自动发布、多平台联动……当这些流程一个个被封装起来，OpenClaw 才会真正从“一个工具”，变成“一个可以持续帮你干活的系统”。
如果你喜欢这篇文章，欢迎点赞、在看、分享，也欢迎在评论区聊聊你在 OpenClaw 技能开发中遇到的问题或心得。我们下期见！
