如果你已经把 OpenClaw 跑起来了,但总觉得它只会聊天、不会干活,那十有八九是 Skills 这一层还没有真正用起来。
这篇我不讲空概念,直接把我自己最常用的一套流程写出来:先看 Skills 放哪儿,再看依赖够不够,最后用一条实际提示词把调用链跑通。
先把目录、依赖、触发条件和调试命令串起来,后面会顺很多。
一、先把 Skills 放置位置理清楚
官方文档里已经把 Skills 的加载位置说得比较清楚了,常用的就 3 个:内置 Skills、~/.openclaw/skills、以及当前工作区里的 skills 目录。
想全局复用,就放到
~/.openclaw/skills。只想当前项目用,就放到项目根目录下的
skills。先别急着写复杂逻辑,能被 OpenClaw 识别出来比什么都重要。
mkdir -p ~/.openclaw/skills/deploy-helper
mkdir -p ./skills/deploy-helper
openclaw skills list
openclaw skills list --eligible我自己调试时会先跑一遍 openclaw skills list,确认技能被扫描到了;再跑 openclaw skills list --eligible,确认它不只是存在,而且真的符合当前机器的运行条件。
二、给你一个我常用的最小 Skill 模板
---
name: deploy-helper
description: 帮我检查 Kubernetes 发布状态并给出排查建议
metadata:
{ "openclaw": { "emoji": "🛠️", "requires": { "bins": ["kubectl"], "env": ["KUBECONFIG"] } } }
---
当用户要求排查 Kubernetes 发布失败、Pod Pending、探针异常、镜像拉取失败时:
1. 先看 deployment、pod、events。
2. 输出时先给结论,再给关键命令。
3. 不做 delete、scale、restart 之类的破坏性操作,除非用户明确授权。这个模板的好处是很直接。requires.bins 和 requires.env 这两个门槛一加,很多“装上了但死活不触发”的问题,现场就能少一半。
我的顺序基本固定:能否扫描到、是否 eligible、依赖是否齐全、提示词是否足够具体。
三、真正开始调试时,我只盯这 4 个命令
openclaw skills list
openclaw skills list --eligible
openclaw skills info deploy-helper
openclaw skills checklist看有没有被加载。list --eligible看当前机器是否满足运行条件。info看它到底要求了哪些二进制、环境变量和配置。check适合在升级 OpenClaw 或改完环境后做一次总体验证。
四、提示词别写得太虚
我自己一开始最容易犯的错,就是明明 Skills 装好了,但提示词写成“帮我看看项目”这种非常虚的句子。结果 OpenClaw 当然也不太知道要不要动用技能。
帮我用 deploy-helper 检查 test 命名空间里 payment 服务为什么一直 Pending,
先看 deployment、pod 和 events,再给我一个最短的排查结论。如果 list 能看到、eligible 也没问题,但实际就是不调,大多数时候不是安装错了,而是提示词没有把场景说具体。
五、发到这里之前,我会顺手做的检查
先看
openclaw skills info deploy-helper输出的依赖列表,跟本机环境逐项对一下。第一次测试尽量指定 Skill 名称,等跑通以后再逐步放松提示词。
第三方 Skill 我会先当成不受信任代码看,别一上来就给高权限环境。











还没有评论,来说两句吧...