Claude Code循环实战：从零搭建自动化工作流
- 从手动到自动
- Loop Readiness Check：什么时候值得搭循环？
- 最小可行Claude Loop
- Verification by Separation：校验分离
- 定时调度：/loop 命令
- Permission Boundaries：安全边界
- 实战要点
- 总结
从手动到自动
大多数人用Claude Code的方式还是手动的：写一个提示→等它回答→检查结果→决定下一轮问什么。单次任务没问题，但一旦工作变成重复的、有状态的、需要多轮校验的，更好的抽象不是更好的提示词，而是一个循环（Loop）。
A Claude loop is a repeatable workflow around the model. It defines:
- 什么触发执行
- Claude应该读什么上下文
- 它被允许做什么
- 输出如何验证
- 状态存在哪里
- 何时停止、重试、或升级到人工处理
模型仍然负责推理和工具调用，但循环提供了操作框架。
Loop Readiness Check：什么时候值得搭循环？
不是所有事情都值得搭Loop。在开始之前，先问自己几个问题：
任务是否涉及多步决策？ 如果只需要三步以内就能搞定，手动更快。
是否涉及外部工具调用？ 读文件、写文件、执行命令——这些是Loop的典型场景。
输出需要验证吗？ 如果输出错了不会立刻发现，说明需要内置验证。
有一个明确的完成标准吗？ 没有完成标准的Loop会无限运行。
三步以上且有明确完成标准，才值得搭Loop。
最小可行Claude Loop
一个最小的Loop由四个文件构成，放在项目的 .claude/loops/你的循环名/ 目录下。
文件结构
.claude/loops/your-loop/
├── TASK.md # 做什么
├── LOOP_INSTRUCTIONS.md # 怎么做（含验证规则和停止条件）
├── PROGRESS.md # 持久化状态
└── outputs/ # 每次执行的产出物
TASK.md — 任务定义
描述要完成的目标和验收标准：
# 任务：定期检查依赖更新
## 目标
每周一检查项目依赖是否有安全更新，自动更新并跑测试。
## 验收标准
- 发现过期的依赖并列出
- 更新到最新兼容版本
- 跑完整测试套件确认无回归
LOOP_INSTRUCTIONS.md — 操作指令
核心文件。定义worker和checker的职责分工：
# Loop 指令
## Worker 职责
1. 读取 TASK.md，了解本次目标
2. 读取 PROGRESS.md，了解当前进度
3. 执行一轮任务操作
4. 更新 PROGRESS.md，记录做了什么
5. 把所有产出物写入 outputs/ 目录
## Checker 职责
1. 读取 TASK.md 的验收标准
2. 检查 worker 的输出是否达标
3. 如果达标：在 PROGRESS.md 标记完成，停止循环
4. 如果不达标：在 PROGRESS.md 记录问题，触发下一轮
## 停止条件
- 任务完成（checker 确认达标）
- 重试超过 5 次
- 遇到无法自动修复的错误 → 输出人工介入指令
PROGRESS.md — 持久状态
这是Loop区别于普通prompt的关键。状态文件让每次执行都能看到前一次干了什么：
# 进度追踪
## 当前轮次：0
## 完成项
（空）
## 发现
（空）
## 待办
- [ ] 初始运行
## 决策记录
（空）
每次循环执行后，模型更新这个文件，写入当前轮次、完成了什么、发现了什么、待办项和决策记录。即使模型上下文窗口有限，也能通过读写文件延续跨轮次的工作。
Verification by Separation：校验分离
这是最核心的模式：把「执行者」和「检查者」分开。
- Worker 负责执行任务、写结果。它可以犯错，允许试错。
- Checker 负责审阅Worker的输出、判断是否达标、决定是否需要重做。
这种角色分离的好处是：执行者不需要同时判断自己的输出是否正确——这是人类开发者也遵循的模式（写代码的人和Code Review的人分开）。
在单个文件里就能实现这种分离：LOOP_INSTRUCTIONS.md 中分别定义worker和checker的指令块。
定时调度：/loop 命令
Claude Code 的 /loop 命令可以设置定时执行频率：
/loop every 24h # 每天跑一次
/loop every 7d # 每周跑一次
/loop at 9:00 # 每天早上9点
这对于以下场景特别有用：
- 每天凌晨检查依赖更新
- 每小时拉一次数据并刷新看板
- 每周自动生成周报
Permission Boundaries：安全边界
Loop自动化不等于让机器无限制操作。需要在 LOOP_INSTRUCTIONS.md 中定义明确的权限边界：
## 权限
- ✅ 读取：src/、tests/、package.json、requirements.txt
- ✅ 写入：outputs/ 目录、PROGRESS.md
- ❌ 写入：.env、config/production.json、.git/
- ❌ 执行：git push、npm publish、rm -rf
这些边界确保Loop在失控时不会造成破坏。
实战要点
从最小版本开始
不要一开始就想做全自动。从「一个文件 + 一个校验」的极简版开始：
- 建目录和 TASK.md
- 写 LOOP_INSTRUCTIONS.md（含worker和checker）
- 跑一次看看
- 再加 PROGRESS.md 做状态持久化
- 再加定时调度
Checker的能力上限
Checker的能力上限就是Claude本身的能力上限。如果worker搞不定的复杂任务，换同一个模型做checker也很难发现问题。真正需要强校验的场景，应该引入：
- 不同模型做checker（比如worker用Sonnet，checker用Opus）
- 人工审核作为回退
PROGRESS.md 的读写竞争
如果Loop同时有多个实例在跑（定时任务和手动触发重叠），PROGRESS.md的状态可能被覆盖。生产级用法应该加时间戳分隔或单向状态机。
总结
Claude Loop的核心价值不在于让模型全自动运行，而在于为重复性工作搭建一个可控的自动化框架。按照”手动测试→搭最小Loop→加校验→加状态→加调度”的顺序逐步建设，不要一步到位。
你每天用Claude Code处理重复性任务超过30分钟吗？如果是，花两小时搭第一套Loop，成本一两天就能回收。