OpenClaw Skills:AI编程助手的本地化技能调度框架 📅 2026/6/24 21:29:15 1. OpenClaw Skills 是什么别被名字骗了它根本不是“爪子”而是一套开发者增强型技能调度中枢很多人第一次看到OpenClaw Skills这个名字下意识会联想到某种带机械臂或仿生结构的硬件项目——毕竟“Claw”爪这个单词太具象了。我刚接触时也查过 GitHub 上带“claw”字样的机器人库、USB HID 控制工具甚至翻过几篇工业抓取论文结果全跑偏了。直到我把openclaw和skills拆开在 GitHub 搜索框里分别输入这两个词再结合热词中反复出现的claude code skills、cursor skills、superpower skills才真正理清它的定位OpenClaw Skills 不是一个独立软件而是一套面向 AI 编程助手如 Claude Code、Cursor、CodeWhisperer 等的本地化技能扩展框架。它的核心价值是把原本只能在云端调用、依赖厂商 API、功能固定且响应延迟明显的“Skills”比如自动写单元测试、生成 SQL、重构函数签名变成你本机可安装、可配置、可调试、可组合、低延迟执行的命令行工具链。举个最直白的例子你在 VS Code 里选中一段 Python 代码右键点“Generate Unit Test”传统方式是把代码发到 Claude 服务器等几秒后返回 pytest 用例而用了 OpenClaw Skills 后这个动作会触发你本地一个叫skill-pytest-gen的脚本它直接调用你本机已安装的pytest --collect-onlyast.parse()分析 AST 结构300ms 内就生成带patch模拟的完整测试骨架——整个过程不走网络不传代码不依赖 API 配额也不受“Claude 正在忙”的提示干扰。这解释了为什么热词里高频出现openclaw 为什么会延迟绝大多数人安装失败或卡顿根本原因不是 OpenClaw 本身慢而是他们误以为它是“替代 Claude 的本地大模型”于是硬塞进 4GB 显存的笔记本去跑 Llama-3-70B结果连openclaw --version都要等 8 秒。实际上OpenClaw Skills 的主体是 Shell 脚本 Python 小工具 YAML 配置文件它对硬件的要求和你装一个git或curl差不多。它真正的“重头戏”是你自己写的那些skills——比如一个用pandas清洗 CSV 的 skill一个调用ffmpeg截取视频关键帧的 skill一个读取kubectl get pods -o json并高亮异常状态的 skill。这些才是消耗资源的地方而 OpenClaw 只是那个精准调度它们的“交通指挥员”。提示如果你在搜索openclaw 安装时看到大量教程让你先docker pull openclaw/openclaw或pip install openclaw-core请立刻暂停。截至 2024 年 7 月官方并未发布任何名为openclaw-core的 PyPI 包也没有维护openclaw/openclaw的 Docker Hub 官方镜像。所有这类教程要么是早期 fork 分支的遗留文档要么是混淆了OpenClaw一个开源的 USB 设备控制库与OpenClaw Skills本文主题两个完全无关的项目。这是新手踩坑率最高的第一道坎。关键词里的codex安装、cc switch windows 安装、deveco鸿蒙应用开发实战等看似无关的词其实揭示了 OpenClaw Skills 的真实生态位它不是一个孤立工具而是嵌入在现代开发者工作流中的“胶水层”。当你在鸿蒙 DevEco Studio 里需要一键生成AbilitySlice模板或在 Kubernetes 集群管理界面里想用自然语言查pod日志又或者在 Cursor 里让 AI 帮你“把这段 JS 改成 TypeScript 并加 JSDoc”这些需求背后都需要一个能快速加载、安全执行、结果可验证的本地技能容器——OpenClaw Skills 就是为此而生。它不造轮子只管接轮子不写业务逻辑只定义调度协议。2. 安装前必须搞懂的三件事环境、权限与路径90% 的失败都卡在这一步很多教程一上来就甩命令curl -sL https://raw.githubusercontent.com/openclaw/skills/main/install.sh | bash然后告诉你“搞定”。我试过 7 种不同系统环境发现这行命令在 macOS Sonoma、Windows WSL2 Ubuntu 22.04、以及群晖 DSM 7.2 的 Docker 容器里有 5 种不同的失败姿势。根本原因在于OpenClaw Skills 的安装逻辑极度依赖三个底层事实Shell 解释器版本、用户主目录权限、以及$PATH中二进制文件的查找顺序。跳过这三件事直接安装等于没系安全带就踩油门。2.1 Shell 解释器别让 zsh 和 bash 在后台打架OpenClaw Skills 的核心调度器oclOpenClaw CLI是一个 Bash 脚本它内部大量使用[[ ]]条件判断、declare -A关联数组、以及source (curl ...)这类 Bash 4.0 特性。这意味着在 macOS 上默认终端是 zsh但ocl脚本第一行是#!/bin/bash它会强制调用系统/bin/bash通常是 3.2 版本而该版本不支持declare -A直接报错declare: -A: invalid option在 Windows WSL2 中如果你用的是 Ubuntu 20.04默认bash是 5.0没问题但如果你升级过系统或手动装了bash-completion某些补丁版本会破坏source (...)的管道行为导致ocl list命令卡死最隐蔽的是群晖 DSM它的 BusyBox 环境里sh是阉割版bash需要额外安装且默认不在$PATH里。实操验证法打开终端逐行执行# 查看当前 shell 类型和版本 echo $SHELL; $SHELL --version # 检查 declare -A 是否可用关键 $SHELL -c declare -A test; echo OK # 检查 source (...) 是否能执行 $SHELL -c source (echo echo hello)如果第二行或第三行报错说明你的基础环境不满足。此时不要硬装先修复macOS 用户brew install bash然后sudo bash -c echo /opt/homebrew/bin/bash /etc/shells最后chsh -s /opt/homebrew/bin/bash切换默认 shellWSL2 用户sudo apt update sudo apt install -y bash确保which bash返回/usr/bin/bash群晖用户通过 Synology Package Center 安装Entware再opkg install bash并确认export PATH/opt/bin:$PATH已加入.profile。注意不要试图用alias bash/opt/bin/bash这种软链接方式绕过。ocl脚本是硬编码调用/bin/bashalias 对 shebang 无效。必须让/bin/bash本身指向新版或修改ocl脚本首行后续章节会讲怎么安全改。2.2 用户主目录权限~/.openclaw不是随便谁都能写的OpenClaw Skills 的所有配置、缓存、下载的 skills 都存在~/.openclaw/目录下。这个目录的权限设置直接决定ocl install命令能否成功写入文件。常见陷阱有公司 Mac 电脑被 MDM如 Jamf策略锁定~/Library和~/.config下所有子目录默认为dr-xr-xr-x只读ocl尝试mkdir -p ~/.openclaw/skills时会静默失败但后续ocl list却显示“无技能”让人误以为安装没生效Windows WSL2 用户用sudo执行安装脚本导致~/.openclaw所属用户变成root而你日常用普通用户登录ocl无法读取~/.openclaw/config.yaml报错Permission denied却不提示具体文件群晖 Docker 容器以root用户运行但挂载的宿主机目录如/volume1/docker/openclaw权限是755容器内ocl进程以 UID 1000 运行对宿主机目录只有读权限ocl update时无法写入新版本。诊断命令执行后看输出是否全是drwxr-xr-xls -ld ~/.openclaw ~/.openclaw/skills ~/.openclaw/config.yaml 2/dev/null || echo 目录不存在修复方案macOS MDM 锁定联系 IT 部门申请临时解锁~/Library写权限或改用ocl的--home参数指定其他可写路径如ocl --home ~/Documents/openclaw installWSL2 权限错乱sudo chown -R $USER:$USER ~/.openclaw然后chmod 700 ~/.openclaw群晖 Docker启动容器时加参数-u $(id -u):$(id -g)并确保宿主机挂载目录权限为775组为users。2.3$PATH查找顺序为什么ocl命令总说“找不到”安装脚本最后一步通常是export PATH$HOME/.openclaw/bin:$PATH但这行只对当前终端会话有效。很多用户关掉终端再开which ocl就返回空。更麻烦的是某些 IDE如 VS Code 的 Integrated Terminal会继承父进程的$PATH而父进程GUI 应用的$PATH可能压根没包含~/.openclaw/bin。验证方法# 在终端里执行 echo $PATH | tr : \n | grep openclaw # 在 VS Code 终端里执行同样的命令对比结果如果两者不一致说明 IDE 没加载你的 shell 配置。此时不能靠code --new-window重启解决因为 GUI 启动的 VS Code 不读~/.bashrc。终极解决方案亲测在 macOS、WSL2、群晖 Docker 全平台生效把export PATH$HOME/.openclaw/bin:$PATH这行同时写入三个文件~/.bash_profilemacOS GUI 终端加载~/.bashrcWSL2 和大多数 Linux 终端加载~/.profile群晖 DSM 和部分最小化系统加载在 VS Code 设置里搜索terminal.integrated.env添加terminal.integrated.env.linux: { PATH: /home/youruser/.openclaw/bin:/usr/local/bin:/usr/bin:/bin }, terminal.integrated.env.osx: { PATH: /Users/youruser/.openclaw/bin:/opt/homebrew/bin:/usr/bin:/bin }重启 VS Code不是 reload window再打开终端which ocl必须返回/home/youruser/.openclaw/bin/ocl。这三件事做完你的环境才算真正准备好。接下来的安装成功率从 30% 直接拉到 98%。记住OpenClaw Skills 不是“装上就能用”而是“配好环境才能装”。很多所谓“安装失败”的帖子其实连第一步echo $SHELL都没做。3. 从零开始安装分四步走每步都附带失败回滚方案现在进入实操环节。我不会给你一个“复制粘贴就完事”的单行命令而是拆解成四个原子步骤每个步骤都明确告诉你要做什么、为什么这么做、如果失败了怎么原路退回、以及最关键的——这一步成功后你该看到什么输出。这才是真正能复现、能排错的安装指南。3.1 第一步下载并校验安装脚本耗时约 15 秒不要直接curl | bash。先下载脚本到本地用sha256sum校验完整性再执行。这是防止中间人攻击和 CDN 缓存污染的底线操作。# 创建临时目录避免污染主目录 mkdir -p ~/tmp/openclaw-install cd ~/tmp/openclaw-install # 下载安装脚本注意这是 2024 年 7 月最新稳定版 URL curl -fsSL -o install.sh https://raw.githubusercontent.com/openclaw/skills/v0.8.3/install.sh # 校验 SHA256官方发布页会公示此值当前为 echo a1b2c3d4e5f67890... install.sh | sha256sum -c # ✅ 正确输出应为install.sh: OK # ❌ 如果报错 install.sh: FAILED立刻删除并重下rm install.sh为什么必须校验我在测试时遇到过一次GitHub Raw CDN 节点缓存了旧版脚本v0.7.1它尝试安装一个已废弃的ocl-cli包而该包在 PyPI 上已被删导致pip install卡死 10 分钟后报404 Not Found。校验能 100% 规避这种“版本漂移”问题。3.2 第二步执行安装并捕获详细日志耗时约 40 秒用bash -x执行开启调试模式所有命令都会打印出来。同时重定向日志到文件方便出问题时逐行分析。# 执行安装同时记录完整日志 bash -x ./install.sh 21 | tee install.log # 安装完成后检查关键文件是否存在 ls -l ~/.openclaw/bin/ocl ~/.openclaw/config.yaml ~/.openclaw/skills/成功标志必须全部满足install.log文件末尾有✅ OpenClaw Skills installed successfully!~/.openclaw/bin/ocl是一个可执行文件ls -l显示-rwxr-xr-x~/.openclaw/config.yaml存在且内容非空至少包含version: 0.8.3~/.openclaw/skills/目录存在但可以为空初始安装不自带 skills。常见失败及回滚失败现象install.log中出现curl: (7) Failed to connect或pip: command not found原因网络不通或未安装 Python/pip回滚rm -rf ~/.openclaw然后先装python3和pip3再重试失败现象install.log卡在Downloading skill-template...超过 60 秒原因GitHub 下载限速或 DNS 污染回滚rm -rf ~/.openclaw然后手动下载https://github.com/openclaw/skill-template/archive/refs/tags/v0.2.0.tar.gz到~/.openclaw/skills/解压重命名mv skill-template-0.2.0 template再运行ocl init3.3 第三步初始化配置并测试基础命令耗时约 5 秒安装只是放好了二进制文件ocl还不知道你的偏好。必须运行ocl init生成个性化配置。# 初始化会交互式提问按回车用默认值即可 ocl init # 测试基础命令 ocl --version # 应输出 v0.8.3 ocl list # 应输出 No skills installed正常 ocl help # 应显示完整帮助文本关键检查点ocl init会创建~/.openclaw/config.yaml其中editor字段应自动识别你默认编辑器如 VS Code 会填codeVim 填vim如果ocl --version报command not found说明$PATH没生效回到 2.3 节修复如果ocl list报Error: failed to read config: open /home/user/.openclaw/config.yaml: permission denied说明权限问题执行chmod 600 ~/.openclaw/config.yaml。3.4 第四步安装第一个实战技能skill-git-status并验证耗时约 10 秒别急着装一堆花里胡哨的技能。先装一个最简单、最实用、且 100% 本地执行的skill-git-status它能在任意 Git 仓库目录下用自然语言描述当前分支状态如“当前在 main 分支有 2 个未提交修改1 个未推送提交”。# 安装技能从官方仓库 ocl install git-status # 进入一个真实的 Git 仓库比如你的项目目录 cd ~/my-project # 执行技能无需任何参数 ocl run git-status # ✅ 成功输出示例 # Git Status Summary # Branch: main # Uncommitted: 2 files modified # Unpushed: 1 commit ahead of origin/main # Ahead by: 1 commit为什么选这个技能作为首个验证它不依赖外部 API纯本地git status --porcelain解析输出结果直观一眼能看出对错如果失败错误信息明确如fatal: not a git repository便于定位是技能问题还是环境问题它是 OpenClaw Skills 的“Hello World”所有后续技能都遵循同一套接口规范。失败排查清单现象可能原因解决方案ocl run git-status: command not foundocl install未成功或~/.openclaw/skills/git-status/bin/run没有执行权限chmod x ~/.openclaw/skills/git-status/bin/run输出Branch: unknown当前目录不是 Git 仓库git init git add . git commit -m init后重试输出为空git-status技能的parse.sh脚本解析逻辑有 bug手动执行~/.openclaw/skills/git-status/bin/run看原始git status输出比对parse.sh中的正则表达式完成这四步你已经拥有了一个可工作的 OpenClaw Skills 环境。接下来才是真正体现它价值的实战环节。4. 实战应用从“自动写 README”到“K8s 故障快查”五个真实场景手把手拆解安装只是起点OpenClaw Skills 的威力在于它能把重复、琐碎、易出错的运维和开发任务封装成一句ocl run xxx就能解决的“超能力”。下面我用五个来自真实工作场景的案例手把手带你从零写出、调试、并落地一个可用的 Skill。每个案例都包含需求背景、Skill 设计思路、完整代码、调试技巧、以及生产环境注意事项。拒绝“Hello World”只讲能立刻用上的干货。4.1 场景一自动生成符合团队规范的 README.md解决 80% 新项目启动时的格式焦虑需求背景我们团队要求每个新项目 README 必须包含 7 个固定区块# 项目名、## 简介、## 快速开始含git clone和npm install、## 目录结构自动生成、## 环境变量从.env.example提取、## 贡献指南、## 许可证。手动写太慢用模板又容易漏项。Skill 设计思路名称skill-readme-gen输入当前目录隐式ocl run自动传入输出生成README.md覆盖同名文件核心逻辑用find . -maxdepth 2 -type d | head -20生成目录树用grep ^# .env.example 2/dev/null | sed s/^# //g提取注释行作为环境变量说明所有内容用 Here Document 拼接避免多行 echo 的转义灾难。完整代码保存为~/.openclaw/skills/readme-gen/bin/run#!/bin/bash # skill-readme-gen/bin/run set -euo pipefail PROJECT_DIR$(pwd) PROJECT_NAME$(basename $PROJECT_DIR) ENV_EXAMPLE$PROJECT_DIR/.env.example # 生成目录结构排除 node_modules, .git 等 DIR_TREE$(find $PROJECT_DIR -maxdepth 2 -type d ! -path $PROJECT_DIR/node_modules* ! -path $PROJECT_DIR/.git* | \ sed s|^$PROJECT_DIR/|| | sort | head -15 | awk {printf %*s%s\n, length($0)-length($NF), , $NF} | \ sed s/^/ / | sed 1s/^ //) # 提取 .env.example 中的注释环境变量说明 ENV_DESC if [[ -f $ENV_EXAMPLE ]]; then ENV_DESC$(grep ^# $ENV_EXAMPLE 2/dev/null | sed s/^# //g | sed s/^/ - /g) fi # 生成 README 内容 cat $PROJECT_DIR/README.md EOF # $PROJECT_NAME ## 简介 一句话描述项目用途。 ## 快速开始 \\\bash git clone https://github.com/your-org/$PROJECT_NAME.git cd $PROJECT_NAME npm install npm start \\\ ## 目录结构 \\\ $(echo $DIR_TREE) \\\ ## 环境变量 $(echo $ENV_DESC) ## 贡献指南 1. Fork 本仓库 2. 创建特性分支 (\git checkout -b feature/AmazingFeature\) 3. 提交更改 (\git commit -m Add some AmazingFeature\) 4. 推送到分支 (\git push origin feature/AmazingFeature\) 5. 打开 Pull Request ## 许可证 Distributed under the MIT License. See \LICENSE\ for more information. EOF echo ✅ README.md generated in $PROJECT_DIR调试技巧先手动执行bash -x ~/.openclaw/skills/readme-gen/bin/run看每一步变量值是否符合预期用diff -u (cat README.md) (bash -c source ~/.openclaw/skills/readme-gen/bin/run; cat README.md)对比生成前后差异在cat README.md EOF前加echo DEBUG: DIR_TREE$DIR_TREE把调试信息输出到终端。生产注意事项此 Skill 会覆盖现有README.md上线前务必加--force参数开关或在脚本开头加if [[ -f $PROJECT_DIR/README.md ! $1 --force ]]; then echo README.md exists, use --force to overwrite; exit 1; fifind命令在 macOS 和 Linux 行为略有不同-maxdepth在 BSD find 中不可用所以脚本开头加set -euo pipefail强制失败退出避免静默错误。4.2 场景二一键诊断 Kubernetes Pod 异常解决 SRE 团队 30% 的夜间告警响应时间需求背景当 Prometheus 告警KubePodCrashLooping触发时SRE 需要在 5 分钟内判断是应用崩溃、OOMKilled、还是 InitContainer 失败。手动敲kubectl describe pod、kubectl logs --previous、kubectl top pod至少 6 条命令极易遗漏关键信息。Skill 设计思路名称skill-k8s-diagnose输入Pod 名称ocl run k8s-diagnose my-app-7d8f9b4c5-xyzab输出结构化 Markdown 报告高亮关键字段如Reason: OOMKilled,Exit Code: 137核心逻辑用kubectl get pod -o json解析 JSON提取status.phase、status.reason、status.containerStatuses[].state.waiting.reason用kubectl logs --previous捕获崩溃前日志所有命令加超时timeout 10s防卡死。完整代码~/.openclaw/skills/k8s-diagnose/bin/run#!/bin/bash # skill-k8s-diagnose/bin/run set -euo pipefail POD_NAME${1:-} if [[ -z $POD_NAME ]]; then echo ❌ Usage: ocl run k8s-diagnose pod-name exit 1 fi # 获取 Pod 基础信息超时 5 秒 POD_INFO$(timeout 5s kubectl get pod $POD_NAME -o json 2/dev/null) || { echo ❌ Failed to get pod info: kubectl get pod $POD_NAME exit 1 } # 解析 JSON用 jq若无则提示安装 if ! command -v jq /dev/null; then echo ⚠️ jq not found. Install with: brew install jq (macOS) or apt install jq (Ubuntu) exit 1 fi PHASE$(echo $POD_INFO | jq -r .status.phase // Unknown) REASON$(echo $POD_INFO | jq -r .status.reason // None) EXIT_CODE$(echo $POD_INFO | jq -r .status.containerStatuses[0].state.terminated.exitCode // N/A) WAITING_REASON$(echo $POD_INFO | jq -r .status.containerStatuses[0].state.waiting.reason // N/A) # 获取上次日志超时 8 秒 PREV_LOGS$(timeout 8s kubectl logs $POD_NAME --previous 2/dev/null | head -20) # 生成报告 cat EOF # K8s Pod Diagnostics: $POD_NAME | Field | Value | |-------|--------| | **Phase** | \$PHASE\ | | **Reason** | \$REASON\ | | **Exit Code** | \$EXIT_CODE\ | | **Waiting Reason** | \$WAITING_REASON\ | ## Last Logs (truncated) \\\ $(echo $PREV_LOGS | sed s/^/ /) \\\ EOF调试技巧在测试集群中故意kubectl delete pod my-app-7d8f9b4c5-xyzab让它进入Pending状态再运行ocl run k8s-diagnose my-app-7d8f9b4c5-xyzab验证WAITING_REASON是否正确抓取ImagePullBackOff用kubectl run debug-pod --imagebusybox -- sleep 3600创建一个长期运行的 Pod然后kubectl delete pod debug-pod再立即运行诊断看PREV_LOGS是否为空应为空因为 busybox 没日志。生产注意事项此 Skill 依赖kubectl和jq必须在~/.openclaw/skills/k8s-diagnose/README.md中明确列出Prerequisites: kubectl, jqtimeout命令在 macOS 上是gtimeout需brew install coreutils所以脚本开头加兼容判断TIMEOUT_CMDtimeout; if [[ $(uname) Darwin ]]; then TIMEOUT_CMDgtimeout; fi敏感信息过滤实际生产中PREV_LOGS可能含密码需加| sed s/password[^ ]*/password***/g等脱敏逻辑。因篇幅限制以下三个实战场景简述核心要点完整代码和调试细节同上4.3 场景三鸿蒙 DevEco Studio 项目一键打包签名对接devecoCLI痛点鸿蒙.hap包签名需sign-hap工具、.p12证书、.cer证书、profile文件四者严格匹配手动执行 12 步命令错一步就得重来。Skill 设计skill-harmony-sign输入ocl run harmony-sign MyFeature自动查找entry/src/main/ets目录调用deveco build再用sign-hap签名输出build/default/outputs/default/app-release-signed.hap。关键技巧用find . -name *.p12 -o -name *.cer | head -1自动发现证书避免硬编码路径用deveco build --help 21 | grep -q harmony验证devecoCLI 版本兼容性。4.4 场景四MySQL 慢查询自动分析并生成优化建议对接pt-query-digest痛点DBA 每天收 50 份slow.log人工看Rows_examined和Query_time太耗时。Skill 设计skill-mysql-slow输入ocl run mysql-slow /var/log/mysql/slow.log调用pt-query-digest生成 HTML 报告并用awk提取前 3 个Query_time最高的 SQL给出EXPLAIN和索引建议。关键技巧用mktemp -d创建临时目录存放 HTML 报告避免污染用mysql --defaults-file~/.my.cnf -e SHOW INDEX FROM table自动检测缺失索引。4.5 场景五VS Code 插件市场热门插件一键安装对接code --install-extension痛点新配开发机要装 30 个插件Prettier、ESLint、GitLens一个个搜太慢。Skill 设计skill-vscode-essentials预置~/.openclaw/skills/vscode-essentials/extensions.txt每行一个插件 ID运行ocl run vscode-essentials时循环执行code --install-extension $id。关键技巧用code --list-extensions | grep -q $id跳过已安装插件用code --install-extension $id 21 | grep -q already installed捕获重复安装提示。这五个场景覆盖了前端、后端、SRE、鸿蒙开发、DBA 等主流角色。你会发现所有 Skill 的核心范式都是接收输入 → 调用本地 CLI 工具 → 解析输出 → 生成结构化结果。OpenClaw Skills 从不替代专业工具它只是让这些工具的调用变得像呼吸一样自然。5. 高级技巧与避坑指南那些官方文档绝不会告诉你的真相写到这里你已经能独立安装、调试、并开发实用的 OpenClaw Skills。但真实世界远比教程复杂。下面分享我在 12 个生产环境部署中踩过的、查过的、最终总结出的 7 条高级技巧。它们不写在任何 README 里却是决定你能否把 OpenClaw Skills 用深、用稳的关键。5.1 技巧一ocl run的隐藏参数--debug和--dry-run是你的救命稻草几乎所有 OpenClaw Skills 都支持这两个全局参数但官方文档只字未提。它们的存在是为了让你在不改变任何生产环境的前提下彻底看清 Skill 的执行逻辑。--debug打印 Skill 执行时的所有环境变量、命令执行路径、以及run脚本中set -x开启的调试输出。实操ocl run k8s-diagnose my-pod --debug你会看到类似 kubectl get pod my-pod -o json的每一行命令以及 POD_INFO{kind:Pod,...的变量赋值。这是定位“为什么jq解析失败”的唯一途径。--dry-run跳过所有写操作如cp、mv、kubectl apply只打印“如果执行将会运行什么命令”。实操ocl run readme-gen --dry-run输出Would generate README.md in /home/user/my-project而不会真的覆盖你的文件。这对批量处理 100 个仓库的 README 生成是绝对的安全网。提示这两个参数是 OpenClaw Skills 的“开发者模式”它们由ocl主程序解析传递给每个 Skill 的run脚本。你可以在自己的 Skill 中用if [[ $1 --debug ]]; then set -x; fi主动启用调试。5.2 技巧二用 ocl exec