OpenClaw Skills实战：用10个核心技能打造自动化智能助理

最近身边好几个朋友都在折腾 OpenClaw，但多数人把它当成一个能聊天的 AI 面板，装好就扔在后台吃灰。直到有人提到“养小龙虾”这个说法，我才意识到这类系统最大的乐趣不在聊天，而是通过 Skills 一点一点把它养成一个懂你工作习惯的智能助理。“小龙虾”这个叫法其实很形象——OpenClaw 的 Claw 就是爪子，小龙虾也有钳子，社区里凑在一起讨论时，就管配置好的实例叫“智能小龙虾”。你要喂它“食儿”，它才有力气干活，喂的东西就是技能包。

项目的默认能力其实很基础，顶多帮你做个简单的文本整理。真正让它从“玩具”变成“能干活的工具”，是一套一套装进去的 Skills。我把自己在项目里从零开始验证过的、社区最近更新比较频繁的 10 个 Skills 做了整理，写成一篇偏实战的教程。这篇文章写给已经装好 OpenClaw、想让流程自动化的开发者，也写给那些正准备入坑、但面对一堆技能列表不知道该装什么的朋友。下面所有的安装命令、配置片段和排查思路，都是我在真实调试环境里跑过的，直接照着做能省不少试错时间。

1. 为什么非装这 10 个 Skills 不可：我的挑选逻辑

如果你搜索过 OpenClaw 的技能商店，会发现列表长到能翻好几页，从翻译、写文案到算数学题什么都有。但“必装”这件事，不该按官方推荐热度来，而应按你自己的日常任务流来挑。我的工作流大体是“获取信息 → 拆解任务 → 执行处理 → 输出成果 → 沉淀记忆”这五段，所以最终留下的 10 个技能，恰好覆盖这五段的闭环。

下面先给一个全景对照表，后面每个章节再展开讲用法和配置：

我把挑选标准定成三条，你也可以拿这三条去筛别的技能：

• 覆盖闭环而非堆数量。如果一个技能只解决临时需求，而无法串进完整自动化流程，就不值得常驻。比如“翻译”这种单点功能，我会在需要时临时调用，而不是长期挂着。
• 避免功能重叠。十几个技能里，真正容易撞车的是“内容提取”“格式转换”这一类。我只保留实现更稳定、接口更简洁的那一个，减少模型误调用。
• 依赖少、更新活跃。技能包如果经常因为底层依赖崩掉，维护成本会吃掉它省下来的时间。选择时优先看它的最近更新记录和 requirements 数量。

还有一个容易被忽略的点：技能之间是有协作关系的。web-fetch 抓回来的网页如果很长，直接丢给模型去读会浪费大量上下文，这时候应该先让 data-cook 做文本切分，再让 mem-kit 存进知识库。也就是说，你在选技能的时候就要考虑“它们要怎么配合”，而不是孤立地看单个能力。

2. 安装前的三个准备步骤：环境、目录和密钥

很多人装上技能之后跑不通，问题不在技能本身，而在安装前置条件没做好。我建议在下载任何技能包之前，先花十分钟做下面三件事。

2.1 运行时检查

OpenClaw 的技能大多依赖本地的 Python 或 Node 环境，部分图表和文档处理技能还需要额外的命令行工具。我的经验是先执行一次环境自检命令，它会一次告诉你缺了什么：

bash复制openclaw doctor

这个命令会检查 Python 版本（建议 3.10 以上）、Node 版本（建议 18 以上）、ffmpeg、ImageMagick、中文字体等运行时。输出里每一项不是 OK 就是 WARN，见到 WARN 就顺手补上：

bash复制# 以 Ubuntu 系为例，缺少系统级工具时
sudo apt install ffmpeg imagemagick fonts-noto-cjk

别跳过这一步。我遇到过一台环境里 Python 是 3.9，表面上看一切正常，但某个 data-cook 依赖的 pandas 版本需要 3.10 的特性，装完技能之后一调用就静默崩溃，日志里只有一句很模糊的“internal error”。

2.2 理解 Skills 的目录与配置文件结构

OpenClaw 的技能采用“一个技能一个目录”的结构，默认放在主目录下的 skills 文件夹：

text复制openclaw/
  skills/
    web-fetch/
      SKILL.md
      manifest.yaml
      requirements.txt
  config/
    settings.yaml
  logs/
    openclaw.log

每个技能目录里最重要的两个文件是 manifest.yaml 和 SKILL.md。manifest.yaml 是声明文件，里面记录技能名称、版本、权限声明、入口函数名称；SKILL.md 则是给大模型看的说明书，写清楚“这个技能什么时候用、怎么调用、参数长什么样”。模型本身不会去读代码，它只靠 SKILL.md 理解工具。

所以装完技能后，我强烈建议你打开 SKILL.md 看一眼，确认它的触发描述和你的使用习惯一致。如果描述写得太过宽泛，比如“可以处理各种网络请求”，模型就可能在不需要抓网页的时候也频繁调用它，拖慢整个任务。

2.3 密钥与权限的最小化

信息获取类、日历类和代码检查类技能，往往需要 API 密钥或本地权限。我的做法是：密钥一律放在环境变量或 .env 文件里，写进 .gitignore，不进配置文件。manifest.yaml 里的权限声明则遵循最小权限原则——需要读网页的就只开网络权限，需要执行脚本的就限定在白名单目录内。

这里多说一句为什么最小权限重要。OpenClaw 的本质是让大模型根据 SKILL.md 的描述主动调用工具，如果工具权限过大，模型在执行自然语言指令时可能做出超出预期的操作。比如 exec-shell 如果允许全盘写入，你让系统“把这个文档整理一下”，它可能把整理结果写到任意路径。把权限约束在 config 层，比事后靠提示词约束可靠得多。

这三步做完，再开始装技能，后面会顺很多。接下来进入正题，先说第一批技能的实际配置。

3. 前四个 Skills 实战：信息获取与任务拆解

这一批解决的是“从外部世界拿数据、并把数据变成可执行任务”的问题。四个技能分别是 web-fetch、search-kit、plan-forge、exec-shell。

3.1 web-fetch：把网页变成干净文本

安装方式很简单：

bash复制openclaw skills install web-fetch

装完先别急着用，去改一下配置，让它更贴合你的抓取场景：

yaml复制# config/skills/web-fetch.yaml
max_content_length: 20000
timeout_seconds: 30
extract_mode: readability
max_redirect: 3

extract_mode: readability 是我的首选模式。它会把网页里的导航、广告、侧边栏过滤掉，只保留正文内容。为什么要这样做？因为大模型的上下文窗口是有限的，你丢给它一个包含了各种杂质的 5 万字符页面，一半 token 都浪费在无关内容上，回答质量自然会下降。填 max_content_length: 20000 是为了防止某个异常页面撑爆上下文；max_redirect: 3 则是限制重定向次数，避免抓取任务卡在循环跳转里。

调用示例。你可以在对话里直接说：

text复制用 web-fetch 抓取这个页面：https://example.com/post/123
提取主要内容，并用 200 字以内总结它的核心观点

实测下来，这个技能搭配“总结”类指令效果最好。如果你的目标是“抓取后归档”，我建议不要直接让模型总结，而是让它先原文输出到文件，再做二次清洗，因为总结会丢失大量细节，不利于后续检索。

3.2 search-kit：从搜索到结构化结果

search-kit 的价值在于聚合多源搜索结果。配置我建议这样调：

yaml复制# config/skills/search-kit.yaml
sources:
  - source_a
  - source_b
  - source_c
max_results: 10
result_deduplication: true
timeout_seconds: 15

为什么我坚持多源聚合而不是单选一个源？单一搜索源的结果受首页排序影响非常大，同一个关键词在两个源里返回的页面可能完全不同。多源交叉之后，召回率明显提升，尤其适合找技术方案和排查报错信息。

这里有一个实操小技巧：搜索关键词最好自己加上时间限定词。比如“最新 OpenClaw skills 配置教程”，搜索引擎默认可能返回半年前甚至更早的结果，你改成“OpenClaw skills 配置教程 最近一周”，召回质量会明显提升。search-kit 只会按你给的字符串去检索，它不会自动帮你理解“最新”这个语义，所以关键词里带时间，效果立竿见影。

3.3 plan-forge：把大任务拆成可执行步骤

plan-forge 是这批技能里最“聪明”的一个。它做的事可以简单理解为“任务拓扑拆解”：给定一个大目标，输出一组有前后依赖关系的小步骤。它生成的不是普通列表，而是带依赖关系的结构化 JSON：

json复制{
  "steps": [
    {"id": 1, "desc": "用 search-kit 查找相关背景资料", "depends_on": []},
    {"id": 2, "desc": "用 web-fetch 抓取最相关的 3 个页面", "depends_on": [1]},
    {"id": 3, "desc": "用 data-cook 清洗并汇总抓取结果", "depends_on": [2]},
    {"id": 4, "desc": "用 doc-writer 生成最终报告", "depends_on": [3]}
  ]
}

为什么要专门做这个拆解？因为大模型在处理复杂目标时，直接一口气输出数千字的长文，质量通常会崩塌——不是遗漏步骤，就是前后逻辑矛盾。而拆成步骤后，每步都能独立校验结果，某个环节失败了，只需要重跑那一个环节，不用整条链重启。

我在实际项目中会让 plan-forge 的输出固定为 JSON，然后在外部把它交给一个任务执行器，逐步骤调用对应技能。这种方式比让模型自己“边想边做”稳定得多，因为外部流程可控，每一步都能留日志、设超时。

3.4 exec-shell：本地脚本执行的安全边界

这个技能解决的是“让 AI 动本地文件、跑本地脚本”的需求。它最强大，也最危险，配置时必须把边界划清楚。

yaml复制# config/skills/exec-shell.yaml
allowed_paths:
  - ./scripts
  - ./tmp
blocked_commands:
  - "rm -rf"
  - "mkfs"
  - ":()"
timeout_seconds: 120
log_output: true

一个典型的安全配置如上。allowed_paths 限定脚本只允许在指定目录下运行；blocked_commands 则直接在配置层拦截高危命令，而不是依赖模型的自我判断。说句实话，模型对“这条命令是否危险”的判断能力并不可靠，把危险命令挡在配置层是最稳妥的。

使用方法示例：

bash复制openclaw skill exec-shell run --script ./scripts/backup.sh --timeout 120

也会在自然语言中直接触发：

text复制运行 scripts 目录下的 backup.sh，把输出日志存到 logs/ 下

我强烈建议所有通过 exec-shell 执行的脚本，都在开头加一句 set -euo pipefail，让脚本“出错即停”，这样一旦某条命令失败，不会继续执行后面的危险操作。这个习惯帮我避免过好几次数值计算结果错误，因为中间步骤静默失败后，脚本还在继续跑。

4. 中间三个 Skills 实战：把材料变成成品

信息抓回来、任务拆好了，接下来就是“出活”的阶段。这一批技能把零散材料变成可交付的文档、表格和图表。

4.1 doc-writer：从草稿到可交付文档

doc-writer 的核心不是“让模型写文章”，而是“让模型按模板写文章”。它的配置逻辑非常务实：

yaml复制# config/skills/doc-writer.yaml
template_path: ./templates/weekly_report.md
output_dir: ./outputs/documents
default_heading_level: 2

先准备一个模板，定义好标题层级、段落结构、需要的字段，然后让模型在模板框架内填充内容。为什么模板先行？因为直接说“帮我写一份周报”，模型会自由发挥，每次格式都不一样；而给它一份模板之后，输出的结构稳定得多，后续做自动化处理也更方便。你可以这么用：

text复制使用 doc-writer，按 templates/weekly_report.md 模板，
把今天的搜索结果整理成一份周报，输出到 outputs/documents/

doc-writer 会自动识别模板中的占位符，把模型生成的内容填进对应位置。我在用的时候发现一个细节：模板里放上“结论先行”的提示词结构，生成的质量比“背景—过程—结论”的流水账式结构好很多，读者第一眼就能看到重点。

4.2 data-cook：数据清洗与统计汇总

data-cook 是我日常使用频率最高的技能之一，因为现实世界的数据远没有你想象的干净。我遇到过的典型问题包括：日期格式不统一、存在空值、字符串前后带空格、数字列混入文本等。data-cook 做的事情就是把这些脏数据变成可分析的结构化数据。

一个典型调用场景：

text复制用 data-cook 处理 data/source.csv：
第一步，删除所有列都为空的行
第二步，将 date 字段统一为 YYYY-MM-DD 格式
第三步，对 score 列做 Z-score 异常值检测，标记偏离超过 3 倍标准差的数据
最后，输出处理后文件和处理报告

这里的“Z-score 异常值检测”是我比较推荐的方法，它比直接设阈值更通用。原理很简单：对某一列数值计算均值和标准差，如果某个样本偏离均值超过 3 个标准差，就认为是异常值。这个方法在处理“波动较大的数据”时表现稳定，不会因为个别极端值把整个分布带偏。

实际踩过的一个坑：有一次我统计某论坛一周发帖分布，data-cook 算出来的结果怎么都对不上。排查半天发现是日期字段里混了三种格式——有的是 2025-02-01，有的是 2025/02/01，还有几条是带时区的 ISO 格式。排序时这三种格式被当成字符串处理，分组自然就错了。后来我在 data-cook 的配置中加了一条标准化的规则，把所有日期先转成时间戳再分组，问题才彻底解决。

4.3 chart-maker：把数据变成图表

看数字总不如看图表直观，chart-maker 负责把 data-cook 处理好的数据渲染成可视化图片。它的接口设计得很克制，参数就那么几个：

bash复制openclaw skill chart-maker create \
  --data ./outputs/cleaned_data.csv \
  --type bar \
  --x column_a \
  --y column_b \
  --output ./outputs/charts/result.png \
  --style default

支持的类型包括柱状图、折线图、散点图、饼图和词云。这里我想专门说一个设计上的体会：把绘图封装成独立 Skill，而不是让模型直接生成 matplotlib 代码，是明显更优的做法。绘图库的参数极其繁多，模型很容易写错字体、配色和坐标轴标签，生成一张失败的图再反复调试，浪费的时间和上下文都很多。而独立技能把绘图逻辑固定成标准接口后，失败率大幅下降，对于不熟悉可视化的用户尤其友好。

实操里我还会给 chart-maker 加上中文字体配置。默认字体渲染中文时会变成方块，解决办法是在配置里指定系统 CJK 字体路径：

yaml复制# config/skills/chart-maker.yaml
font_path: /usr/share/fonts/noto-cjk/NotoSansCJK-Regular.ttc

这个坑不填，图表做出来虽然能用，但交付时观感很差，推荐一发出来就立刻原形毕露。

5. 最后三个 Skills 实战：记忆、日程与代码检查

前两批技能解决的是“单次任务”的执行，这最后一批解决的是“长期使用”的问题。它们的共同点是都需要外部存储或接口配合，配置上有各自的门道。

5.1 mem-kit：长期记忆与知识库检索

mem-kit 的本质是为 OpenClaw 增加长期记忆能力。它会把文档切块、向量化、存进本地索引，下次提问时先检索相关片段再交给模型参考。这就是典型的检索增强生成（RAG）思路。

配置参考：

yaml复制# config/skills/mem-kit.yaml
index_path: ./data/memory_index
chunk_size: 512
chunk_overlap: 64
top_k: 5
embedding_model: local_embedding
watch_dirs:
  - ./knowledge_base

chunk_size: 512 表示每个文本块大约 512 个字符，chunk_overlap: 64 让相邻块有少量重叠，避免语义断在切分处。top_k: 5 表示每次检索最多召回 5 个片段。

我是怎么用它的？我会把团队规范、之前写过的技术方案、常见问题的处理记录都扔进 knowledge_base 目录，之后遇到类似问题，模型就会优先从记忆库中找历史结论，而不是凭空生成。这个体验改善非常明显，相当于你的智能助理越用越懂你的偏好。

有一点需要注意：mem-kit 要求 watch_dirs 里的文件命名尽量带日期和主题，比如 2025-02-01_数据库选型记录.md。因为检索是召回式而不是全量阅读，文件名里带主题词能在向量相似度计算之外提供额外权重，提升召回命中率。

5.2 cal-sync：日程读取与提醒

cal-sync 解决“让 AI 管时间”的问题。它需要你授权日历接口的读取和写入权限，然后你就可以用自然语言操作日程了：

text复制下周三上午 10 点有一个项目评审会，时长 1 小时，提前 15 分钟提醒我

cal-sync 会自动创建日程，设置提醒时间，并在规定时间通过配置的通知通道推消息。配置提醒通道时我推荐用系统通知+日志双通道，万一主通知没送达，日志里还能看到触发痕迹。

这里有一个很实用的设置：新增事件时开启冲突检测。默认配置下，如果一个时间段已有日程，cal-sync 会返回冲突提示而不是直接覆盖。你可以让它列出冲突日程，再决定是否强制插入。这个功能在日常使用中能帮你避免不少“时间重叠”的麻烦。

5.3 code-reviewer：代码检查与修改建议

code-reviewer 面向开发者，它会扫描指定仓库路径下的代码，做静态检查、计算圈复杂度，并给出修改建议。安装后配置好仓库路径和检查规则即可：

yaml复制# config/skills/code-reviewer.yaml
repo_path: ./projects/example_app
enabled_linters:
  - pylint
  - eslint
max_files: 50
ignore_paths:
  - "vendor/"
  - "node_modules/"

实际使用场景：

text复制用 code-reviewer 检查 projects/example_app 下最近修改的文件，
重点关注圈复杂度超过 10 的函数，给出重构建议

我为什么要装这个技能？因为人工审查时最花时间的不是“看懂代码逻辑”，而是“扫描全仓库找可疑点”。code-reviewer 把可疑点先捞出来，人工再审的时候效率能提升好几倍。但我也要说句大实话：它的建议不能盲信。模型对“代码风格”的判断比“架构合理性”要可靠得多，遇到涉及跨模块依赖的问题，它经常给出表面正确但实际不合适的建议。你该把它当筛选器，而不是终审法官。

6. 踩坑实录：从装不上到跑不通的完整排查链路

再好的教程也躲不过真实环境里的各种意外。这一章我按“现象 → 排查思路 → 修复方案”的方式，记录几个我在调试过程中真正遇到、且有代表性的问题。

6.1 现象：Skill 装了但找不到

第一个印象深刻的坑是：技能明明安装成功了，但对话里怎么调用都提示不存在。我当时怀疑是安装命令没跑完，重新装了一遍还是一样。

排查思路：先跑一下技能列表，看看系统到底认识哪些技能。

bash复制openclaw skills list --all

结果列表里根本没有 web-fetch。继续查，发现安装并行时，技能索引没有自动刷新。这就像你把一本书放进了书架，但目录卡片还没更新，管理员自然找不到。

修复方案：执行索引重建命令：

bash复制openclaw skills rebuild-index

之后再 list --all 就能看到了。这个坑的教训是：装完技能后先跑一次 list 确认加载状态，再进测试对话。省得你以为装好了，白等十几分钟才发现没用上。

6.2 现象：任务执行超时

第二个常见问题就是超时。我遇到一个典型场景：web-fetch 抓取一个内容很重的网页，模型在等待过程中直接放弃，返回“timeout”。排查发现目标站点响应速度本身就不稳定，而我又把 timeout_seconds 设成了 15 秒，明显不够。

修复方案：调大超时，并加入重试机制：

yaml复制timeout_seconds: 30
retry_count: 2
retry_interval_seconds: 3

更重要的是我后来意识到，超时参数不是越大越好。设成 120 秒意味着任何一次抓取卡住，整个任务会挂在那里 2 分钟。合理的做法是给单次请求 30 秒、重试 2 次，三次都失败就放弃，让流程继续往前推进。别让某个局部慢节点拖垮整条自动化链路。

6.3 现象：Python 脚本没有输出

exec-shell 执行脚本时，我最开始遇到的是“脚本跑完了，但日志里什么都没有”。单独在终端运行脚本却正常输出。

排查思路：这其实是 Python 标准输出缓冲和字符编码两个问题叠加的结果。第一，Python 进程的输出在内核层被缓冲，子进程结束后日志捕获模块没能读到全部内容；第二，某些环境下 PYTHONUTF8 没有显式打开，遇到中文就直接抛编码异常。

修复方案：在配置里指定执行参数：

yaml复制# config/skills/exec-shell.yaml
python_exec_args: ["-u"]
env:
  PYTHONUTF8: "1"

-u 参数强制 Python 在 print 后立即冲刷缓冲区，PYTHONUTF8=1 避免中文编码报错。改完之后，日志输出完整且中文正常。这个坑让我养成了一个习惯：所有给 exec-shell 用的脚本，开头我都会手动加上编码声明，避免依赖全局环境。

6.4 推荐的排查顺序

踩过这些坑之后，我总结出了一套相对固定的排查流程：

我的习惯是：先看日志，再查配置，最后才考虑改代码。日志目录 logs/openclaw.log 会记录每一次技能调用的入参、出参和报错堆栈，绝大多数问题都能在这里找到线索。对照日志去排查，比黑盒瞎猜高效得多。

7. 把“小龙虾”养成型的调教心得

技能装齐、流程跑通之后，剩下的工作就是持续调教。这个阶段更依赖使用经验，而不是单纯的配置。

7.1 给技能设置触发词，减少误调用

技能多了，模型在自然语言中区分意图的难度也会变大。我的方案是在配置里为每个技能设置 alias（别名），让触发更确定：

yaml复制# config/settings.yaml
skills:
  aliases:
    "查一下": "search-kit"
    "抓这个页面": "web-fetch"
    "整理成文档": "doc-writer"
    "跑一下脚本": "exec-shell"

这样当你说出“查一下”时，系统会更倾向于调用 search-kit，而不是凭语义在多个技能里猜测。实测下来，设置别名后意图识别的准确率提升非常明显，尤其是“搜索”和“抓取”这两个高频操作，误调用率下降了一大截。

7.2 常用配置参考

一句话总结我在项目里跑着最稳的一组配置：

skills.auto_load: false 是我特别建议的。全部技能同时加载时会占掉大量上下文，给模型理解任务的空间就变少了。改成按需加载后，整体响应速度和质量都会提升，代价只是首次调用某个技能时稍慢半秒，完全值得。

7.3 个人经验：先短任务后长任务，版本锁定

最后分享几条调教过程中的个人经验。

第一，先让小龙虾做单技能短任务，稳定后再串成链。别一上来就把 10 个技能编排成超长流程，任何一个环节出问题，你都不知道是该调模型还是调技能。先用单个技能跑通 5 个短任务，再逐步加长。

第二，每加一个新技能就回归一遍旧任务。我吃过一次亏：加装 chart-maker 后，原先的 doc-writer 输出短时间出现了格式偏差。排查后确认是技能之间的配置默认值冲突。从那以后，每次装完新技能，我都会跑一遍已有的核心流程做回归测试，确保没有不良反应。

第三，版本锁定并定期备份。技能的更新不是越多越好，有些新版本改了接口，你的旧流程就断了。我在配置里会把核心技能版本固定下来，只有确认新版兼容后才统一升级。skills 目录我每周备份一次，出了问题可以随时回滚。

把上面这些做下来，OpenClaw 就不再是一个需要你反复折腾的工具，而会慢慢成长为真正理解你工作习惯的助手。我对它的体会是：真正重要的不是装了多少技能，而是你愿不愿意花时间去摸清它的脾气。养好之后再回头看，你会觉得它真的挺像一只懂你的虾——平时安安静静地待在后台，喊一声才伸出钳子来帮你干活。