OpenClaw Skills 从入门到精通:一篇就够了

核心观点：Skill 的本质不是提示词增强，而是 Workflow 的迁移。它把原本静态存在的方法，变成一种可以被 Agent 调用、被模型理解、被工具执行的能力单元。

📑 目录

一、为什么 Skills 会出现？三大工程化痛点
二、Skills vs Prompt：一次性杯子 vs 保温杯
三、Claude Skills 设计解析
四、OpenClaw Skills 的六大升级
五、实战：如何写好一个 Skill
六、避坑指南：两个常见错误
七、总结与展望

一、为什么 Skills 会出现？三大工程化痛点 🎯

近一年，Agent 的进化速度极其迅速。从能力本身来说，大家关心的无非是上下文窗口有多长、记忆有多强大。但做得深入一点的同学，会更关注Tools 调用的稳定性。

大模型在实际应用中面临着三大工程化痛点：

1️⃣ 提示词臃肿、维护困难

一个复杂的任务，特别是多步工作流的任务，需要写几百甚至上千字的 Prompt。里面装满了各种要求、规则、格式说明、示例，Prompt 会变得又长又难读。Prompt 越多，模型注意力就越容易分散，越容易出现幻觉，程序执行的流程就越不稳定。

2️⃣ 上下文窗口限制

就算你写了一个非常完美的 Prompt，它也要占用宝贵的上下文窗口。但当你需要处理多个复杂任务时，很快就会不够用。

3️⃣ 能力复用困难

当你调教好了一个"代码重构专家"，明天同事也想用，怎么办？只能通过聊天发给他？这既不优雅，也很难保证执行效果一致。

💡 Skills 就是为解决这些问题而生的。它的核心价值可以收敛成三点：•知识的沉淀与复用：反复使用的流程被固化为技能，避免重复造轮子•模块化架构：每个技能都是独立的，易于测试、维护和扩展•无限的可能性：通过组合不同技能，可以构建复杂的工作流

二、Skills vs Prompt：一次性杯子 vs 保温杯 ☕

Skills 是执行单元不是高级 Prompt，他们的差别有点像：一次性杯子和随身保温杯。

举个具体的例子。如果你想让 AI 帮你审查代码：

# 用 Prompt 的方式：请你检查这段代码，看看有没有安全问题，特别是 SQL 注入、XSS 这些常见的漏洞、敏感信息泄露、权限控制问题对了，输出的时候要按严重程度排序，高危的放前面。# 用 Skills 的方式：在一个 pr-code-review 的文件夹里，放一个 SKILL.md 文件，里面写着触发条件、检查范围、输出格式...

这个看起来确实差不多，都在做安全检查，提示词的结构也几乎一样，但关键的差别，不在"写什么"，而在"怎么用"。

与 Prompt 不同的是，Skills 更为工程化了，Skill 一旦写好，就被工具"托管"了。工具会在合适的时候会自动调用它：当你提交 Pull Request，或者主动发起安全检查时，对应 skill 就会被自动加载、执行。

🌟 当每个人都可以把自己的最佳实践写成 skill，分享出来，一个良性循环就形成了：用的人越多，积累的经验越多，Skills 的质量和覆盖面就越广。Skills 不再是个人本地的"小本本"，而是一个可共享、可迭代、可组合的能力生态。

三、Claude Skills 设计解析 🔍

作为工程概念提出者，只要看懂了 Claude Skills 的设计，也就能看懂所有 Skills 底层的运行机制。

三个核心要素

要素	说明	示例
元数据	技能的名称、描述、标签等信息	name, description
指令	技能具体的执行逻辑	SKILL.md 中的工作流程
资源	技能附带的相关资源	脚本、模板、配置文件

渐进式披露设计

渐进式披露的设计，可以缓解 Tools 调用的稳定性问题：模型开始的时候，只会加载 skill 的基础元数据，当模型判断需要使用这个 skill 的时候，才会加载完整的指令（skill.md）。

# 第一层：元数据（始终加载）name: douyin-summary description: 抖音视频总结助手。当用户提供抖音视频链接并请求总结时，使用此技能。# 第二层：核心指令（触发时加载）# 抖音视频总结助手 ## 工作流程 1. 识别抖音链接 2. 调用脚本获取内容 3. 总结内容 4. 友好输出# 第三层：代码与资源（按需加载）scripts/ └── fetch_douyin.py

💡 三层设计的精妙之处

• 元数据层让 Claude 快速了解自己有哪些能力• 指令层只在需要时才加载，节省上下文• 资源层按需调用，避免不必要的开销

四、OpenClaw Skills 的六大升级 🚀

很多人第一次接触 OpenClaw Skills 就会发现：这和 Claude Skills 的写法几乎一模一样啊？那是当然一样啊，skill 的写法是一样的，大多 skills 是可以互通的。

但 OpenClaw 在使用场景上做了大量工程化升级：

1️⃣ 六级优先级覆盖机制

OpenClaw Skills 有个设计：优先级覆盖机制。6 个来源按优先级从低到高写入 Map，后写入覆盖先写入，工作区同名 Skill 最终胜出。

// 优先级从低到高：① 额外目录 ② 内置 bundled ③ 用户 managed ④ 个人 Agent ⑤ 项目 Agent ⑥ 工作区 ← 最终胜出

📌 实际场景示例

假设你日常开发用 "summarize-changes" 这个技能来生成 commit 信息，放在 ~/.openclaw/skills/ 里。有一天接手一个开源项目，这个项目对 commit 格式要求非常严格。你可以在该项目根目录下创建 .openclaw/workspace/skills/summarize-changes/，放一个专门针对这个项目的版本。当你使用这个 Agent 工作时，工作区的技能会覆盖你用户目录里的同名技能。使用其他 Agent，在其他地方又会自动切回你个人的习惯版本。

2️⃣ 四种触发方式

触发方式	说明	示例
语义触发	自然语言对话，AI 自动匹配技能	"帮我审查这段代码"
指令触发	/skill [name] 显式调用	/skill code-review
定时任务	Cron 表达式支持	0 8 * * *（每天早上 8 点）
事件驱动	Webhooks 支持	GitHub PR 提交、Slack 消息

3️⃣ 三级预算降级策略

核心问题是：如果一个工作区有上百个 Skill，全部塞进 System Prompt，模型上下文就爆了。OpenClaw 的解法是三级预算降级策略：

# 第一级：完整格式（name + description + instructions）if fitsFull(skillsForPrompt): return {compact: false, truncated: false}# 第二级：紧凑格式（name + location only）if fitsCompact(skillsForPrompt): return {compact: true, truncated: false}# 第三级：二分搜索找最大可行前缀，截断# 截断到前 lo 个技能

💡 省 token 小细节：compactSkillPaths 函数会把 /Users/alice/.bun/.../skills/github/SKILL.md 替换为 ~/.bun/.../skills/github/SKILL.md。每个路径省 5-6 个 token，300 个 Skill 就是 400-600 tokens 的节省。

4️⃣ 庞大的技能生态：ClawHub

OpenClaw 有一个强大的官方技能市场：ClawHub（https://clawhub.ai/）。截至文章发布时，ClawHub 上已经有38000+ 个技能，覆盖了几乎所有你能想到的场景：

办公自动化：邮件处理、文档转换、会议纪要
开发工具：GitHub 操作、代码审查、部署管理
生活服务：天气查询、新闻聚合、健康提醒
智能交互：网页自动化、数据抓取、API 调用

5️⃣ 安全扫描与热更新

OpenClaw 为 Skills 配备了三个关键的工程能力：

🔒 安全扫描

Skill 安装时，安全扫描器会检查 SKILL.md 和 scripts 目录中的危险代码模式，防止恶意 skill 注入。

🔄 文件监听热更新

OpenClaw 用 Chokidar 监听所有 skill 目录中的 */SKILL.md 文件。当你修改了某个 SKILL.md（新增、修改或删除），监听器会在 250ms 去抖后触发版本号递增，自动重建 system prompt 中的技能目录。整个过程无需重启，对正在进行的对话也是生效的。

🔑 环境变量安全注入

很多 Skill 需要配置 API Key 或环境变量才能工作。OpenClaw 通过配置系统注入，支持引用计数、自动回收、安全过滤。

6️⃣ 模型中立

Claude Skills 绑定 Claude 模型，而 OpenClaw Skills 是模型中立的，可配置对接多种 LLM。

五、实战：如何写好一个 Skill ✍️

⚠️ 核心理念：skill = 被工程化管理的 Prompt 单元，说人话就是带元数据和资源的可执行 Prompt 单元。核心未变，范式已变。

决定 skill 质量的两个要素

要素一：元数据

其实就两个东西：name 和 description。这是模型认识这个 skill 的唯一窗口。能不能在合适的时机被调用，全靠这两句话。

# ❌ 糟糕的写法：用于审查代码质量的 Skill# ✅ 更好的写法：在用户提交 Pull Request 后自动触发对新增代码进行安全审查输出审查报告并标注高风险问题

要素二：约束强度

很多人写 skill 容易走两个极端：

管得太死：先做 A，再做 B，然后 C... 限制得过于死的话，模型稍微超出预期的情况就不知道怎么办了
放得太松：只说了"帮我审查代码"，模型自己发挥，每次结果都不一样

💡 技巧：需要明确的告诉模型要做什么，给它留足推理空间；但也要明确告诉它不要做什么，把边界说清楚。然后再给一些例子，什么时候做什么事情。

五步法写 Skill

第一步：小技巧 - 裸模型

在动手写 skill 之前，先用裸模型跑一遍你要做的事，看看它到底会出什么问题。这些出错的地方，就是你写 skill 要填的坑。

第二步：定标准

写 skill 之前，需要先定标准：什么算好，什么算不好？有了这个及格线，你写 skill 的时候心里就有谱了。

第三步：先有再优

写 skill 最容易一上来就写一堆逻辑，想把所有场景都照顾到，结果 skill 越写越长，逻辑越绕越乱，一跑就崩。

💡 经验：评测里暴露什么问题，就先解决什么问题，别的先别管。先写个能过当前评测的最小版本，哪怕只能处理一种类型的会议，也比大而全更容易成功。

第四步：补边界

最小版本能用了，下一步才是慢慢往里加东西。这时候做三件事：

把边界情况写清楚：能处理什么、不能处理什么，都说明白
定好输入输出格式：什么格式进来，什么格式出去，越明确越好
给例子：模型最快理解你的方式，就是看例子

第五步：持续观察

skill 不是一次性产品，上线之后得经常看看：

它有没有在不该触发的时候跑出来？
执行过程中有没有漏掉关键信息？
有没有产生什么奇怪的依赖？

六、避坑指南：两个常见错误 ⚠️

坑一：写成说明书了

不少人写 Skill 的时候，忍不住加一堆背景介绍、设计理念：

本 Skill 基于敏捷开发方法论旨在通过结构化思维提升会议纪要的质量...

🚫 模型不吃这套！它要的是：什么情况用我、怎么执行、做成什么样。要记住：skill 不是给人看的文档，是给模型下的指令。

坑二：越写越复杂

有人觉得 skill 功能越多越好，恨不得一个 skill 搞定十几种场景，规则套规则。

🎯 Agent 不是传统软件，复杂只会带来不稳定。skill 越简单，触发越精准，执行越稳定。一个 skill 就干一件事，单一职责，到哪都好使。

七、总结与展望 🎉

OpenClaw 对 Skills 的设计，其实不是加了一个技能目录这么简单。它延续了 Claude Code 对 Skills 的设计思路，并且将其升级成了Agent Runtime里的正式构件。

这套设计，可以概括成五件事：

先把 Skill 当成"资源"统一发现：从多个来源扫描技能，把磁盘上的文件夹统一收束成运行时里的 Skill 集合
再把 Skill 当成"配置"做优先级覆盖：后写覆盖前写，优先级高的覆盖优先级低的
然后把 Skill 当受控单元：策略控制，确保 Skill 在当前上下文里可被授权使用
最终注入 Prompt：Skill 最终表现为 Prompt，但它并不是从 Prompt 开始设计的
持续运维：热更新、文件监听、版本刷新、环境变量注入、安全扫描

🌟 终极总结：Skills 的本质，不是提示词增强，而是 Workflow 的迁移。未来普通人使用 Agent，未必是天天重写 Prompt，而更可能是围绕一组已经沉淀好的 Skills，去持续调用、组合。