Claude Code 动态循环（Dynamic Looping）实战：告别傻轮询，用事件把 Claude 叫醒

你有没有被“定时轮询”折磨过？

比如你让 Claude 帮你盯 CI：每隔 30 秒问一次“好了没”，一晚上 token 烧到心疼，屏幕还刷得像弹幕。

动态循环就是来治这个的。

你输入 /loop [任务]（不带间隔）
Claude 会自己判断任务处在哪个阶段
该等就等，该勤快就勤快
更关键：能用 Monitor 在后台跑脚本，有事件才叫醒它 🛎️

这玩意儿用对了，Claude 从“笨定时器”直接进化成“会睡觉的值班同事”。

1）动态循环到底变了啥？

以前的 loop 很像“机械闹钟”：

你设 10 秒，它就每 10 秒来一次
不管有没有新情况，都要来报个到

现在的动态循环更像“会看情况的巡逻”：

任务刚开始、变化多：检查会更密
进入等待（比如跑 CI、等部署）：检查会拉长
发现异常苗头：会主动加密检查

你得到的体验很直观：少刷屏、少耗 token、出事更快喊你。

2）一句话上手：直接用 /loop（不写间隔）

把你以前那种“每隔 N 秒检查一次”的习惯改掉。

直接这样写：

/loop 帮我盯住这次 CI 的结果：通过就总结变更点；失败就定位最可能的失败步骤，并给出修复建议。

再来个更贴近现场的：

/loop 我正在部署到生产环境。只要出现错误日志、健康检查失败、或响应时间明显升高，就立刻提醒我并给出排查路径。

你会发现它不会一直“打卡”，更多时候是安静的。

3）真正的王牌：Monitor 工具（事件发生才唤醒）

动态调度已经能省很多。

但 Monitor 更狠：没事件就完全不吭声。你可以把它理解成：

后台跑一个轻量监控命令（例如 tail -f、watch、grep）
一旦匹配到你关心的信号（error、失败、评论更新）
才把信息推给 Claude

适合的场景：

CI/CD：失败就叫醒
日志巡检：出现 error/exception 就叫醒
部署观察：健康检查挂了就叫醒
PR 协作：有人评论、有人 push 新提交就叫醒

3.1 监控日志：只抓 error/exception

你不需要把整条日志喂给 Claude。

你需要的是“触发条件”。比如只要出现 error 就提醒：

# 示例：实时跟踪日志，只把包含 error/exception 的行吐出来
tail -f /var/log/app.log | grep -E "error|exception|panic" --line-buffered

你的 loop 任务可以这么写（核心是明确 Claude 被唤醒后要干嘛）：

/loop 用 Monitor 盯 app.log。只要捕获到 error/exception/panic，就：
1) 解释这条错误的含义
2) 给出最可能的 3 个原因（按概率排序）
3) 给出我能立刻执行的排查命令

3.2 盯 CI：失败才出现

如果你们 CI 能用命令查状态（GitHub Actions、GitLab CI、Jenkins 都行），就让 Monitor 去跑“状态查询”，发现失败再叫。

一个常见思路：

watch 每隔几秒查一次状态（这是脚本在跑，不是 Claude 在刷 token）
只有检测到失败/完成，才输出一行“触发信息”

示例（伪代码风格，按你们环境替换查询命令）：

# 每 10 秒检查一次 CI 状态；只有失败/完成时输出
watch -n 10 "./ci_status.sh | grep -E 'FAILED|SUCCESS'"

Claude 被唤醒后要做的事写清楚：

/loop 用 Monitor 监控 CI 状态。
- 如果 SUCCESS：总结这次合并/提交的风险点和回归建议
- 如果 FAILED：根据失败阶段给出最小修复方案，并写一段可复制的排查清单

3.3 盯部署健康检查：接口挂了立刻报警

很多线上事故不是“完全挂”，而是“慢慢变慢”。

你可以让 Monitor 盯一个健康检查接口：

# 每隔 5 秒请求一次，非 200 或耗时过高就输出
while true; do
  start=$(date +%s%3N)
  code=$(curl -s -o /dev/null -w "%{http_code}" https://example.com/health)
  end=$(date +%s%3N)
  cost=$((end-start))

  if [ "$code" != "200" ] || [ $cost -gt 800 ]; then
    echo "health_check_alert code=$code latency_ms=$cost"
  fi

  sleep 5
done

配合的任务：

/loop 用 Monitor 盯健康检查。
一旦出现告警，告诉我：
- 最可能的问题方向（依赖、数据库、网络、限流、CPU/内存）
- 我该优先看哪些指标/日志
- 给我一份 10 分钟内能执行完的止血动作

4）写 /loop 的“好用模板”（照抄就能跑）

你写 loop 别写成“帮我盯一下”。要写成“叫醒后做什么”。

把下面模板填空就行：

/loop 用 Monitor 盯【信号来源：日志/CI/接口/PR】。
触发条件：【出现什么文本/状态变化/阈值】
叫醒后你要做：
- 解释发生了什么（用人话）
- 判断影响范围（会不会扩散、是否需要回滚）
- 给 3 个优先级最高的操作（每个操作给命令/路径）
- 如果需要升级处理，告诉我该叫谁、贴什么信息

5）避坑清单（不看真的会踩）

日志太吵：别 tail -f 全量喂。用 grep -E 把触发条件收紧，不然 Claude 会被“假警报”烦死。
缺少上下文：只输出一行 error 有时不够。可以把触发行的前后 N 行一起输出（比如用 awk/sed/日志工具的“上下文”参数）。
触发条件写太宽：比如只匹配 error，有些应用把“error”当普通字段。你得匹配更具体的关键词（模块名、错误码、exception 类型）。
权限问题：日志路径、CI 查询命令、PR 查询命令，Claude 运行环境没权限就白搭。先在你本机/runner 上把命令跑通。
频率太高：Monitor 虽然省 token，但脚本会占机器资源。间隔别上来就 1 秒，除非真在救火。
把“分析”写进监控脚本：脚本负责“发现信号”，Claude 负责“判断与行动”。别在 bash 里写一坨业务逻辑，维护地狱。

6）你该从哪个场景开始用？

给你几个“今天就能用上”的：

你在等 CI 结果，别盯网页了：失败再叫醒你
你在跟线上异常：出现关键 error 立刻推送
你在发版：健康检查非 200 或延迟飙升就报警
你在带团队协作：PR 有新评论就提醒并生成回复草稿

把 loop 用对，你会明显感觉：屏幕不吵了，人也不焦虑了，真正出事的时候反而更快收到信号。