企业官网建设流程全解析

把OpenClaw从“聊天窗口”变成“干活的手”，就差一个Skills

我见过太多人把OpenClaw跑起来之后，兴冲冲地丢给它一句“帮我把 downloads 文件夹里超过500MB的文件列出来”，结果它回了一段完美的Python代码，然后客气地补了一句“你可以手动运行这段脚本”。那一刻你会觉得，这家伙就是个会打字的百科全书，有脑没手。我自己刚接入的时候也踩过这个坑，折腾了大半个晚上，才搞明白问题不在模型本身，而在于我没有告诉OpenClaw“你的手在哪”。这个“手”，就是Skills。

简单说，Skills是OpenClaw用来执行真实操作的能力模块：它能调用系统命令、读写文件、请求接口、处理数据，并把执行结果交还给模型去整理和汇报。没有Skills，模型只能生成“文本”；有了Skills，模型才能产生“动作”。这篇文章适合两类人：一类是刚把OpenClaw跑起来、觉得它只会聊天不会干活的；另一类是已经写了几个Skills但发现触发率极低、形同虚设的。我会从原理讲到实操，再把最容易翻车的几个坑按排查顺序展开，最后聊一聊怎么把零散的Skills组织成一套能让模型“主动起来”的体系。

1. 为什么OpenClaw天生只会“答”不会“做”：模型与系统之间的断桥

如果你不先理解这个断桥，后面写Skills也只会靠蒙。

大语言模型的本质是一个“文本续写器”。它输入一段文字，输出下一段最合理的文字。你说“帮我删掉临时文件”，它能理解这句话，也能生成一段删除文件的bash命令——但它生成的是“描述动作的文本”，不是“动作本身”。就像一位资深顾问可以写出一份详细的施工方案，但不会亲自搬砖。要让模型真的去执行，必须在模型和操作系统之间架一座桥：模型先在对话里声明“我要怎么办”，桥接层拿到声明后调用真实工具，工具执行完把结果写回对话，模型再把结果整理成人话。OpenClaw里的这座桥，就是Skills。

这个机制在业界有各种叫法：Function Calling、Tool Use、插件、动作包。OpenClaw的Skills只是其中一种工程实现，但它有几个独特的设计倾向：Skill以独立目录存在，声明文件、脚本文件、参数定义放在一起；模型通过读取Skill的描述来决定“什么时候用、用什么参数”；执行环境通过配置决定“哪些Skill允许自动跑、哪些需要人工确认”。理解这三层，你才能理解为什么“只写了脚本”不等于“有了Skill”。

没有配置Skills的时候，OpenClaw面对你的操作请求只有三个选择：给出步骤让你自己执行；生成代码让你复制去跑；或者明确说“我无法直接操作系统”。并不是它不想做，而是它没有“可调用动作”的清单。你可以把模型想象成一个新来的实习生，他满肚子理论知识，但你既没给他门禁卡，也没告诉他操作手册在哪，他当然只能把建议写在纸上递给你。Skills要解决的，就是发门禁卡、定操作手册、规定什么活必须请示、什么活自己看着办这一整套流程。

2. 第一个Skills的完整解剖：从目录结构到最小执行闭环

我习惯用一个非常小、但能完整走通闭环的任务来做第一个Skill，比如“日志异常巡检”：读取指定的日志文件，筛出带有ERROR/WARN的行，统计数量并展示前十条。这个任务足够具体、不涉及破坏性操作、结果能直观验证，特别适合跑通整条链路。

一个Skill在OpenClaw下通常就是这个样子：

skills/ └── log-inspector/ # 技能目录，名字一般用短横线连接 ├── SKILL.md # 给模型看的“说明书” ├── skill.yaml # 给执行器看的“配置单” └── inspect.sh # 真正干活的脚本

SKILL.md是给模型看的。OpenClaw会把文件内容塞进模型决策时能看到的上下文里。模型就是通过这份说明来判断“这个技能是干什么的、什么时候该调它、参数怎么填”。所以这份文件的写法，直接决定了模型“想不想得到”这个技能。

# Log Inspector 分析指定日志文件中的 Error / Warning 级别记录。 当用户提到日志文件、报错信息、异常记录、排查现场时，优先考虑使用本技能。 参数说明： - path: 必填，日志文件绝对路径 - keyword: 选填，追加过滤关键字，例如 "timeout"

这里有个容易忽略的点：描述里除了写“能干什么”，还要写清楚“什么时候用”。模型在对话里看不到你的日志内容，它只能靠描述里的关键词去做匹配。如果你只写“分析日志文件”，触发率会低得可怜；一旦补上“当用户提到日志、报错、异常、排查现场”，触发率会明显上升。

skill.yaml是给执行环境看的，它定义了入口脚本和参数传递方式。一个最小可用的配置大概长这样：

name: log-inspector description: 日志异常巡检 entry: inspect.sh parameters: - name: path required: true type: string description: 日志文件路径 - name: keyword required: false type: string description: 附加过滤词

执行脚本inspect.sh的核心逻辑不需要多复杂，关键是三点：从参数里拿到path；对文件做过滤统计；把结果按固定格式输出到标准输出，因为OpenClaw会捕获脚本的stdout作为执行结果回传给模型。脚本可能是这样的：

#!/bin/bash path="$1" keyword="$2" if [ ! -f "$path" ]; then echo "ERROR: file not found: $path" exit 1 fi if [ -n "$keyword" ]; then pattern="ERROR|WARN" echo "=== Lines matching ($pattern) and containing '$keyword' ===" grep -E "$pattern" "$path" | grep "$keyword" else echo "=== Error/Warning count ===" grep -Ec "(ERROR|WARN)" "$path" || true echo "=== First 10 lines ===" grep -E "(ERROR|WARN)" "$path" | head -10 fi

把这三个文件放进skills目录，并在配置文件里声明“skills目录在这”，一个最小闭环就成了：用户说“看下/etc/app/logs/error.log有没啥异常”，模型读到了SKILL.md里“日志、报错、异常”这些关键词，决定调用log-inspector，参数path被填成/etc/app/logs/error.log，脚本跑完把统计结果打印出来，模型拿到输出后整理成一句“查到47条错误记录，前十条如下……”。到这一步，OpenClaw才算真正“做”了一件事，而不只是“说”了怎么做。

3. 从“能跑”到“主动干活”：关键配置与权限边界的设置

第一个Skill跑通之后，你很快会发现一个尴尬的局面：你得明确命令它“用log-inspector去看日志”，它才动手。如果不提Skills的名字，它又退回纯聊天的老路。这不怪模型，是因为OpenClaw默认的决策策略是“按需调用”：用户明确要求了，模型才会考虑是否调用工具。要让Skill被“主动想起”，你必须调整两层东西：一是提示词层面的工具可见性，二是执行层面的自动运行权限。

先说工具可见性。OpenClaw在组装上下文时，会从配置的skills目录里读取每个Skill的声明，但具体塞多少技能描述进去、哪些优先，取决于上下文长度和配置。如果你的配置文件里把skills目录设成了全局目录，而里面塞了三十个不相关的技能，模型真正拿到的有效描述可能只剩前十项；你的log-inspector如果排第二十位，模型压根没看见它，自然想不起来用。解决办法是避免在一个目录里堆大量低相关度的技能，把强相关技能放到同一个目录，或者把高优技能写在模型系统提示词里，让它们永远出现在模型视野的前排。

再说自动运行权限。这是“主动干活”最核心的一道开关。默认情况下，OpenClaw把Skill当成“半自动”工具：模型可以生成执行请求，但执行环境需要等用户确认。这意味着你每次都要点一下确认，体验上跟手动跑脚本没太大区别。要实现真正的自动执行，需要打开autonomy相关的配置，并设置允许自动执行的技能白名单。以我用的配置为例，它会解析类似下面这样的配置段：

skills: directory: ./skills auto_approve: enabled: true allowlist: - log-inspector - file-stats - http-ping ask_for_confirmation: - file-delete - service-restart

这里的思路是分级授权：低风险、只读类技能放进自动执行白名单，模型判断需要时可以直接跑；删除文件、重启服务这类有副作用的技能，无论模型多想自动，都强制要求人工确认。这种设计比较像给实习生发了两把钥匙：一扇门随时能进，另一扇门必须主管刷卡。OpenClaw的“主动干活”，本质上就是在这个授权边界之内，允许模型自己判断“现在的场景该不该调用工具”。一旦配置好，它会主动调用log-inspector去巡检、主动调用http-ping去探测连通性，用户只需要看最终汇报。

配置完之后必须验证一件事：用一句模糊的、不点名工具的话去测试。比如不说“用log-inspector”，只说“我感觉服务最近不太稳，你帮我看看日志里有没有异常”。如果模型能自动定位到Skill并执行，说明自动决策链路通了；如果它只是回你“可以查看日志”，那就要检查描述关键词和技能可见性。

4. 实测中翻车率最高的三个环节：排查思路与解决办法

跑通自动执行只是开始，真实使用里你会遇到各种“明明配置了，却像没配置”的怪现象。我总结出三个翻车率最高的点，按排查顺序写在这里，大家以后遇到可以先照着检查。

第一类问题：模型完全不知道有Skill存在。现象是日志里根本没有工具调用记录，模型全程在纯文本回答。排查链路是先确认配置里的skills目录路径是否正确，再看启动日志里有没有成功加载该Skill的记录，然后检查模型上下文里到底有没有出现SKILL.md的内容。很多时候问题出在技能描述太长，被上下文管理器截断了；或者目录权限不对，文件根本没被读取。选型排查的要点是“先看日志，再猜模型”，不要凭感觉改提示词。

第二类问题：Skill被调用了，但参数解析失败。现象是日志里能看到模型尝试调用工具，但脚本秒退或报“parameter error”。这类问题九成出在模型生成的JSON参数和skill.yaml定义不一致。比如模型以为字段叫file_path，而你的配置里写的是path；或者模型把路径参数填成了数组而不是字符串。我的处理经验是在脚本入口加一层防御性解析，不要信任模型生成的JSON结构：

# 防御性参数解析示例 import sys, json raw = sys.argv[1] if len(sys.argv) > 1 else "{}" try: params = json.loads(raw) except Exception: params = {} path = params.get("path") or params.get("file_path") or params.get("target")

这样哪怕模型生成了别名参数，脚本也能兜住。

第三类问题：执行成功了，但结果没回到对话里。这是最隐蔽的坑。脚本可能把结果写进了result.txt，或者只打印到了日志文件，但OpenClaw只会捕获脚本的stdout内容作为执行结果。你看模型回复“我已经完成了”，可它压根没看到执行结果，只是基于“调用成功”的假象在推测。解决方法是养成一个习惯：任何Skill脚本，关键结论必须打印到标准输出；文件路径、退出码、统计结果、异常摘要，全都得让模型看得见。你宁可多打印，也别让模型“盲猜”。

排查这三类问题时，我有两个顺手的小工具：一是在配置里打开详细执行日志，能看到模型决策时到底看到了哪些技能描述；二是写一个极简的“echo技能”，什么也不干，只把传入参数原样打印出来。用它来测试参数链路是否通顺特别快，成本几乎为零。

5. 让Skills“主动起来”的体系设计：从单技能到分工协作

单个Skill能自动执行，离“主动干活”还有一段距离。我见过很多人配了十个技能，最后只有一两个会被频繁触发，其余全吃灰。问题在于技能之间没有形成“协作感”，模型面对的任务往往需要多个动作组合，而你只给了它零散的动作孤岛。要让OpenClaw从“你说一步它动一步”变成“交个目标它自己拆解”，需要做三层设计。

第一层是触发设计。每个Skill的描述里都要明确“什么时候必须用”“什么时候不要用”，这不仅提升命中率，还能降低误触发。比如给log-inspector加一句“当用户只是在闲聊网络问题时，不要使用本技能”；给restart-service加一句“只处理生产环境服务，本地开发服务直接拒绝”。负面清单比正面描述更能帮模型做排除决策，实测效果非常明显。

第二层是分层设计。把技能分成基础技能、判断技能、编排技能。基础技能是真实动作，如读日志、发请求、执行备份；判断技能不直接干变化性的活，只检查环境状态，比如“磁盘剩余量是否低于20%”“端口是否在监听”；编排技能不自己动手，而是负责设计流程：先跑判断技能，拿到结果后才决定是否调用基础技能，组合成一条可执行链路。举个我常用的例子：夜间巡检流程，OpenClaw会先调用disk-check判断磁盘使用率，如果超过阈值，再调用log-inspector看是哪个服务在写大量日志，然后定位到具体目录执行清理；只有当所有条件都满足时，才会调用需要人工确认的清理脚本。这就是一个典型的“判断技能驱动基础技能”的编排结构。

第三层是失败回退设计。技能执行不可能永远成功：日志文件不存在、接口超时、权限不足。一开始我写的Skill失败后只会return 1，模型就回一句“执行失败”，然后结束。正确的做法是让每个Skill在失败时输出可读的错误原因和可能的替代方案，比如“文件不存在，请检查路径，或尝试用find技能定位日志位置”。模型拿到这些信息后会自己另想办法。这套机制的投入产出比极高，一个小时的改进能消灭大量“卡死在半路”的情况。

最后是复盘。用了一个月之后，我去翻了执行日志，发现三个技能从未被触发。逐一检查后发现：一个是描述里的关键词离真实对话太远，一个是功能被另一个成体系的高优Skill覆盖，还有一个纯粹是因为上下文太长被挤出了名单。修完它们的共同思路不是改代码，而是改SKILL.md里的“何时使用”描述，并给高优先级流程做一次上下文拼接优化。这个过程让我确信，Skills体系不是一次性搭建，而是持续调参才能越来越聪明的。

6. 关于“主动干活”这件事，我的几点真实体会

跑了一段时间之后，我对“OpenClaw + Skills 主动干活”这件事最大的感受是：它不会像科幻电影里那样突然开窍，而是一个渐进增强的过程。最开始它是“你推一步它走一步”，配置好白名单后它变成“能看到局部目标并自行行动”，等技能分层和回退设计做完，它才开始像“能承接一个模糊目标并拆分执行”的初级数字员工。这中间的变量不是模型本身，而是你给它的“手”够不够清晰、够不够可靠。

如果你正准备上手，我的建议是不要一口气写十个Skills。挑一个你每天都在重复的、低风险的、结果容易验证的小任务，比如日志巡检、磁盘统计、定时网页抓取，先把一个Skill的自动触发链路跑顺。确认它能主动干活了，再考虑第二个。另外一个小技巧可能对其他人都适用：在SKILL.md里先写“什么时候不要用”，再写“什么时候用”，这会让模型的决策准确率高出一截；因为我实测过，只写正向触发条件的Skill误触发率大概在15%到20%，加上负面清单后能降到5%以下。先让模型知道“不要干涉什么”，它才知道“该主动去做什么”。