夜雨聆风📑 目录
一、为什么 Skills 会出现？三大工程化痛点
二、Skills vs Prompt：一次性杯子 vs 保温杯
三、Claude Skills 设计解析
四、OpenClaw Skills 的六大升级
五、实战：如何写好一个 Skill
六、避坑指南：两个常见错误
七、总结与展望
一、为什么 Skills 会出现？三大工程化痛点 🎯
近一年，Agent 的进化速度极其迅速。从能力本身来说，大家关心的无非是上下文窗口有多长、记忆有多强大。但做得深入一点的同学，会更关注Tools 调用的稳定性。
大模型在实际应用中面临着三大工程化痛点：
1️⃣ 提示词臃肿、维护困难
一个复杂的任务，特别是多步工作流的任务，需要写几百甚至上千字的 Prompt。里面装满了各种要求、规则、格式说明、示例，Prompt 会变得又长又难读。Prompt 越多，模型注意力就越容易分散，越容易出现幻觉，程序执行的流程就越不稳定。
2️⃣ 上下文窗口限制
就算你写了一个非常完美的 Prompt，它也要占用宝贵的上下文窗口。但当你需要处理多个复杂任务时，很快就会不够用。
3️⃣ 能力复用困难
当你调教好了一个"代码重构专家"，明天同事也想用，怎么办？只能通过聊天发给他？这既不优雅，也很难保证执行效果一致。
二、Skills vs Prompt：一次性杯子 vs 保温杯 ☕
Skills 是执行单元不是高级 Prompt，他们的差别有点像：一次性杯子和随身保温杯。
举个具体的例子。如果你想让 AI 帮你审查代码：
这个看起来确实差不多，都在做安全检查，提示词的结构也几乎一样，但关键的差别，不在"写什么"，而在"怎么用"。
与 Prompt 不同的是，Skills 更为工程化了，Skill 一旦写好，就被工具"托管"了。工具会在合适的时候会自动调用它：当你提交 Pull Request，或者主动发起安全检查时，对应 skill 就会被自动加载、执行。
三、Claude Skills 设计解析 🔍
作为工程概念提出者，只要看懂了 Claude Skills 的设计，也就能看懂所有 Skills 底层的运行机制。
三个核心要素
| 要素 | 说明 | 示例 |
|---|---|---|
| 元数据 | ||
| 指令 | ||
| 资源 |
渐进式披露设计
渐进式披露的设计，可以缓解 Tools 调用的稳定性问题：模型开始的时候，只会加载 skill 的基础元数据，当模型判断需要使用这个 skill 的时候，才会加载完整的指令（skill.md）。
四、OpenClaw Skills 的六大升级 🚀
很多人第一次接触 OpenClaw Skills 就会发现：这和 Claude Skills 的写法几乎一模一样啊？那是当然一样啊，skill 的写法是一样的，大多 skills 是可以互通的。
但 OpenClaw 在使用场景上做了大量工程化升级：
1️⃣ 六级优先级覆盖机制
OpenClaw Skills 有个设计：优先级覆盖机制。6 个来源按优先级从低到高写入 Map，后写入覆盖先写入，工作区同名 Skill 最终胜出。
2️⃣ 四种触发方式
| 触发方式 | 说明 | 示例 |
|---|---|---|
| 语义触发 | ||
| 指令触发 | ||
| 定时任务 | ||
| 事件驱动 |
3️⃣ 三级预算降级策略
核心问题是：如果一个工作区有上百个 Skill，全部塞进 System Prompt，模型上下文就爆了。OpenClaw 的解法是三级预算降级策略：
4️⃣ 庞大的技能生态：ClawHub
OpenClaw 有一个强大的官方技能市场：ClawHub（https://clawhub.ai/）。截至文章发布时，ClawHub 上已经有38000+ 个技能，覆盖了几乎所有你能想到的场景：
办公自动化：邮件处理、文档转换、会议纪要
开发工具：GitHub 操作、代码审查、部署管理
生活服务：天气查询、新闻聚合、健康提醒
智能交互：网页自动化、数据抓取、API 调用
5️⃣ 安全扫描与热更新
OpenClaw 为 Skills 配备了三个关键的工程能力：
6️⃣ 模型中立
Claude Skills 绑定 Claude 模型，而 OpenClaw Skills 是模型中立的，可配置对接多种 LLM。
五、实战：如何写好一个 Skill ✍️
决定 skill 质量的两个要素
要素一：元数据
其实就两个东西：name 和 description。这是模型认识这个 skill 的唯一窗口。能不能在合适的时机被调用，全靠这两句话。
要素二：约束强度
很多人写 skill 容易走两个极端：
管得太死：先做 A，再做 B，然后 C... 限制得过于死的话，模型稍微超出预期的情况就不知道怎么办了
放得太松：只说了"帮我审查代码"，模型自己发挥，每次结果都不一样
五步法写 Skill
第一步：小技巧 - 裸模型
在动手写 skill 之前，先用裸模型跑一遍你要做的事，看看它到底会出什么问题。这些出错的地方，就是你写 skill 要填的坑。
第二步：定标准
写 skill 之前，需要先定标准：什么算好，什么算不好？有了这个及格线，你写 skill 的时候心里就有谱了。
第三步：先有再优
写 skill 最容易一上来就写一堆逻辑，想把所有场景都照顾到，结果 skill 越写越长，逻辑越绕越乱，一跑就崩。
第四步：补边界
最小版本能用了，下一步才是慢慢往里加东西。这时候做三件事：
把边界情况写清楚：能处理什么、不能处理什么，都说明白
定好输入输出格式：什么格式进来，什么格式出去，越明确越好
给例子：模型最快理解你的方式，就是看例子
第五步：持续观察
skill 不是一次性产品，上线之后得经常看看：
它有没有在不该触发的时候跑出来？
执行过程中有没有漏掉关键信息？
有没有产生什么奇怪的依赖？
六、避坑指南：两个常见错误 ⚠️
坑一：写成说明书了
不少人写 Skill 的时候，忍不住加一堆背景介绍、设计理念：
坑二：越写越复杂
有人觉得 skill 功能越多越好，恨不得一个 skill 搞定十几种场景，规则套规则。
七、总结与展望 🎉
OpenClaw 对 Skills 的设计，其实不是加了一个技能目录这么简单。它延续了 Claude Code 对 Skills 的设计思路，并且将其升级成了Agent Runtime里的正式构件。
这套设计，可以概括成五件事：
先把 Skill 当成"资源"统一发现：从多个来源扫描技能，把磁盘上的文件夹统一收束成运行时里的 Skill 集合
再把 Skill 当成"配置"做优先级覆盖：后写覆盖前写，优先级高的覆盖优先级低的
然后把 Skill 当受控单元：策略控制，确保 Skill 在当前上下文里可被授权使用
最终注入 Prompt：Skill 最终表现为 Prompt，但它并不是从 Prompt 开始设计的
持续运维：热更新、文件监听、版本刷新、环境变量注入、安全扫描
