用 Claude Code /loop 加速 openclaw Skill 开发（实测）

摘要：Claude Code v2.1.71 引入的 /loop 命令允许在会话内设置定时重复任务。本文以 openclaw douyin下载 Skill 的开发过程为例，展示如何利用 /loop 在脚本迭代阶段自动验证依赖可用性和端到端下载流程，将"手动跑命令→等待结果→目视检查"的循环简化为一条 loop 指令。

---

一、/loop 简介

/loop 是 Claude Code 从 v2.1.71 版本开始内置的定时任务调度命令，用于在终端会话存活期间，按指定频率自动重复执行一段指令。

基本语法

/loop [间隔] [指令]

• 间隔：s（秒）、m（分）、h（时）、d（天）
• 指令：自然语言描述，越具体执行越精确
• 省略间隔时 Claude 动态选择最优延迟（60s - 1h）

# 每 5 分钟检查一次
/loop 5m 检查所有 PR 的 CI 状态，有新失败立刻告诉我

# 不设间隔，动态调度
/loop 盯着日志，出现 ERROR 立刻通知

# 查看活跃任务
/loop list

# 手动取消
按 Esc

关键约束

特性	说明
作用域	仅当前会话，终端关闭即失效
过期	3 天后自动删除
间隔下限	秒级向上取整到分钟

两种使用模式

# 模式 A：持续监控（手动停止）
/loop 5m 检查 XXX，异常立刻通知

# 模式 B：自动停止（验证完成即收工）
/loop 30s 检查 XXX，连续 3 次通过后自动停止

本文用到的主要是模式 B——开发期间的临时验证，通过后自动停止，不长期占用会话。

---

二、douyin下载 Skill 的结构与开发挑战

douyin-kukutools-weixin 的功能是：用户在微信发送douyin分享链接，Skill 通过 Playwright 无头浏览器打开douyin页面、捕获视频/音频媒体流 URL、用 ffmpeg 合并为 MP4 文件、回传到微信。

代码结构

skills/douyin-kukutools-weixin/
├── SKILL.md                            # AI 执行指令
└── scripts/
    ├── download-douyin-kukutool.ps1    # PowerShell 入口
    ├── download-douyin-kukutool.mjs    # Node.js 核心逻辑
    ├── config-manager.ps1              # 环境路径管理
    ├── check-dependencies.ps1          # 依赖检查
    ├── stage-douyin-download.ps1       # 文件落盘
    └── install-checker.ps1             # 安装后自检

核心流程（mjs 中的 main 函数）

解析分享文本 → 提取douyin URL
    → Playwright 无头浏览器打开页面
    → 监听 request/response 事件，捕获视频和音频 URL
    → 有音视频分离 → ffmpeg 合并
    → 无音频流 → 直接下载视频流
    → 主路径失败 → 降级到直接 API 下载（iesdouyin.com/aweme/v1/play/）

开发中的两个痛点

痛点一：外部依赖多，容易悄然断裂。 脚本依赖 Node.js、Chrome、ffmpeg、Playwright 四个外部组件，每个都有特定路径。一旦某次修改导致路径解析错误（比如 config-manager.ps1 返回的 JSON 字段变化），脚本会静默失败。

痛点二：端到端测试有延迟。 douyin页面的 DOM 结构和媒体 URL 格式会变化。每次修改代码后需要找一条真实的douyin链接跑完整的下载流程——解析 → 打开页面 → 等待捕获 → 合并 → 落盘——才能确认功能完好。手动做每次至少 2-3 分钟。

---

三、/loop 实战一：依赖可用性持续检查

问题

check-dependencies.ps1 已经能输出四个依赖的状态 JSON：

{
  "NodeJS":    { "Installed": true, "Path": "...", "Version": "v24.2.0" },
  "Chrome":    { "Installed": true, "Path": "C:\\Program Files\\Google\\..." },
  "FFmpeg":    { "Installed": true, "Path": "..." },
  "Playwright": { "Installed": true, "Path": "..." }
}

但它只在开发初期手动跑过一次。后续修改 config-manager.ps1 或 download-douyin-kukutool.ps1 中的路径解析逻辑时，没有机制自动验证依赖是否仍然可用。

方案

开发期间用 loop 每 5 分钟自动跑一次依赖检查，并验证每个字段：

/loop 5m 执行 powershell -NoProfile -ExecutionPolicy Bypass -File
"C:\Users\your-username\.openclaw\skills\douyin-kukutools-weixin\scripts\check-dependencies.ps1"。
分析输出的 JSON：
- NodeJS.Installed 是否为 true，Version 是否包含 "v24"
- Chrome.Installed 是否为 true，Path 指向的文件是否确实存在
- FFmpeg.Installed 是否为 true
- Playwright.Installed 是否为 true
任意一个 Installed 为 false 或路径对应的文件不存在 → 立刻通知具体是哪个依赖挂了。
全部正常 → 静默，不输出。

这条指令逐项分析：

要素	内容
间隔	5 分钟，匹配代码修改节奏
任务	执行 check-dependencies.ps1 获取依赖状态
检查条件	4 个依赖的 Installed 字段 + 路径文件存在性
告警策略	异常时通知具体哪个依赖、什么原因
静默策略	全部正常不输出（减少干扰）

关键设计：检查比脚本本身更严格

check-dependencies.ps1 只检查路径是否注册，但不会验证路径指向的文件是否真实存在。所以在 loop 指令中额外加了 Path 指向的文件是否确实存在 —— 用 AI 的能力弥补脚本检查的不足。

开发期间如果改 config-manager.ps1 把 Chrome 路径写坏了，5 分钟内就能发现，不用等到跑完整的下载测试才发现"咦 Playwright 怎么启动不了"。

---

四、/loop 实战二：端到端下载流程验证

问题

download-douyin-kukutool.mjs 的逻辑比较长：URL 提取 → 打开页面 → 等待视频/音频 URL 捕获（45 秒超时）→ ffmpeg 合并 → 落盘。如果主路径失败，还有降级逻辑：直接调 iesdouyin.com/aweme/v1/play/ API 下载。

每次改完代码需要验证：

1. 输入一段douyin分享文本 → 脚本能否正确提取 URL
2. Playwright 能否打开页面并捕获媒体 URL
3. ffmpeg 合并后的 mp4 文件是否生成
4. JSON 输出是否包含 ok: true 和 path 字段

手动验证每次至少 2-3 分钟（加上等待超时的情况）。

方案

用一条固定的douyin链接作为测试输入，loop 定时跑全流程：

/loop 5m 执行以下端到端测试：

powershell -NoProfile -ExecutionPolicy Bypass -File
"C:\Users\your-username\.openclaw\skills\douyin-kukutools-weixin\scripts\download-douyin-kukutool.ps1"
-ShareText "https://v.douyin.com/xxxx/ douyin测试链接"

检查输出：
1. 退出码是否为 0
2. JSON 中 ok 是否为 true
3. path 字段是否非空，且指向的 mp4 文件是否存在且大小 > 1KB
4. 如果 fallbackMode 为 "direct-play"，标记为 "触发降级路径"
   → 通知我，但不视为失败

任意条件不满足 → 输出完整的 stderr 和 JSON 片段。
连续 3 次全部通过且未触发降级 → 回复 "端到端测试通过" 并自动停止。
触发降级的通过也算通过，但额外报告降级次数。

---

五、开发期 loop 的使用原则

以上两个案例体现了几个通用原则：

原则一：必须有停止条件

开发期的 loop 是"用完即弃"的，不是长期守护进程：

# ✅ 明确停止
/loop 5m 执行测试，连续 3 次通过后停止，满 20 次仍未通过也停止并输出所有失败记录

# ❌ 没有停止——开发完了还在空转
/loop 5m 执行测试

上限兜底（满 20 次也停止）同样重要——防止因环境问题（比如 Chrome 进程卡死）导致 loop 无限重试。

原则二：检查条件必须机器可判定

loop 指令中的"检查条件"必须是脚本输出可以明确判断的——退出码、字段存在、文件大小。不能依赖人工主观判断：

# ❌ 模糊
/loop 5m 执行下载脚本，看看能不能用

# ✅ 可判定
/loop 5m 执行下载脚本，检查：退出码 0、ok=true、path 指向文件 >1KB

原则三：区分硬失败和降级通过

如第四节所示，主路径挂掉但降级路径通过的，算"通过"但标记通知。这样既不会因为一个非致命问题中断验证，也不会漏掉需要关注的降级趋势。

---

六、效果

以 douyin-kukutools-weixin 开发为例：

操作	之前	之后
依赖可用性检查	出问题才想到跑 check-dependencies.ps1	loop 每 5 分钟自动验证，依赖挂了 5 分钟内发现
端到端下载测试	每次改完代码手动找链接跑一次，等 2-3 分钟看结果	loop 自动跑，改坏即知
主路径还是降级路径	不确定，只有手动跑的时候才看到	loop 统计降级频率，连续降级主动通知

节省的不是写代码的时间，是改完代码后手动执行命令、目视检查输出、等待超时这些碎片操作的等待时间。

---

七、局限性

以下操作 /loop 无法替代人工：

• 新链接适配：douyin分享链接格式可能变化（短链→长链→口令），需要人工确认新的 URL 格式能否被 extractDouyinUrl 正确解析
• 页面交互调试：Playwright 的 DOM 等待策略、选择器选择需要开发者肉眼确认页面结构
• 微信回传验证：文件下载后是否正确发送到微信，用户端的播放体验，loop 无法模拟

---

八、风险与注意事项

1. Token 消耗

loop 的每一次触发都是一轮完整的 Agent 对话，包含系统 prompt、工具定义和上下文，token 是计费的。以 5 分钟间隔为例：

每次 ~800 token（执行检查 + 解析输出 + 报告状态）
一天 288 次 × 800 = ~230,000 token
月 token 消耗 ≈ 690 万

对比之下，15 分钟间隔：

一天 96 次 × 800 = ~76,800 token
月 token 消耗 ≈ 230 万

建议：开发期 loop 设置短间隔时务必加上停止条件（连续 N 次通过即停），避免遗忘导致空转。若仅为回归检查，5-10 分钟足够；只有紧急 Debug 时才用 30s-1min 间隔。

2. 忘记停止

开发完成后如果忘记按 Esc 取消 loop，任务会一直跑到 3 天自动过期。如果停止条件设置得当（连续 3 次通过即停），这个问题可以被自动化解——但若是"模式 A"（只告警不停止），空转的成本很容易被忽视。每次开始新 loop 前用 /loop list 确认没有残留任务是一个好习惯。

3. 测试数据覆盖有限

loop 使用固定的测试输入（如一条固定的 douyin 链接），只能验证代码对已知输入的行为是否退化，无法覆盖新输入格式的兼容性。douyin 链接格式变化（短链→长链→口令解析）时，loop 的测试结果仍然显示"通过"，但新链接实际可能已经无法解析。loop 是回归测试工具，不能替代新用例的探索性测试。

4. 环境差异

loop 运行在终端会话中，与 Gateway 实际运行环境可能略有差异——环境变量、工作目录、进程权限等。loop 中脚本测试通过不代表 Gateway 中 Skill 调用一定正常。最终仍需在微信端做一次真实触发验证。

---

（本文案例仅学习交流使用）
《在 openclaw WebChat 中使用douyin无水印视频下载 Skill》
https://blog.csdn.net/weixin_29129287/article/details/161591696?spm=1011.2415.3001.10575&sharefrom=mp_manage_link

---

如果您觉得有用，欢迎 点赞、转发、评论、关注。