基于 Claude Code 打造你的第一个 Loop 工程：五步实战指南
2026/6/18大约 9 分钟
基于 Claude Code 打造你的第一个 Loop 工程。
从零到一，五步实战，
让 AI 真正「自己转起来」。
前置条件
Claude Code v2.1.72 或更高版本。
# 检查版本
claude --version
# 如果版本过低，更新
npm update -g @anthropic-ai/claude-code/loop 命令在 Claude Code v2.1.72 之后可用。
作用就一个：按时间间隔，把同一件事重跑一遍。
第一步：认识 /loop 的三种形态
/loop 有三种形态，你按需要挑。
┌─────────────────────────────────────────────────────────┐
│ /loop 的三种形态 │
├─────────────────────────────────────────────────────────┤
│ │
│ 形态 1：单次循环（One-shot） │
│ ┌─────────────────────────────────────────────────┐ │"
│ │ /loop "run tests" --every 1h │ │
│ │ │ │
│ │ 用途：定时任务 │ │
│ │ · 每小时跑一次测试 │ │
│ │ · 每天检查一次依赖更新 │ │
│ │ · 每周生成一次报告 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 形态 2：条件循环（Conditional） │
│ ┌─────────────────────────────────────────────────┐ │
│ │ /loop "fix failing tests" --when tests-fail │ │
│ │ │ │
│ │ 用途：事件驱动 │ │
│ │ · 当测试失败时触发修复 │ │
│ │ · 当 CI 失败时触发分析 │ │
│ │ · 当有新 Issue 时触发处理 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 形态 3：持续循环（Continuous） │
│ ┌─────────────────────────────────────────────────┐ │
│ │ /loop "monitor and triage" --continuous │ │
│ │ │ │
│ │ 用途：长期运行 │ │
│ │ · 持续监控 CI 状态 │ │
│ │ · 持续处理 Issues │ │
│ │ · 持续优化代码 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘形态选择原则：
- 单次循环：周期性、固定间隔的任务
- 条件循环：事件驱动、有明确触发条件的任务
- 持续循环：长期运行、需要持续监控的任务
第二步：让它读 CI 和 Issue，先做 Triage
目标： 让 Claude 能够感知外部世界，识别需要处理的任务。
2.1 读取 CI 状态
# 创建你的第一个循环
/loop "检查 CI 状态并分析失败原因" --every 30mPrompt 模板：
请执行以下任务：
1. 读取 CI 状态
- 检查 GitHub Actions 的最新运行结果
- 找出所有失败的构建
2. 分析失败原因
- 读取失败构建的日志
- 判断是「逻辑错误」还是「环境噪音」
- 只标记「逻辑错误」的失败
3. 输出结果
- 列出所有需要处理的逻辑失败
- 简要说明每个失败的根因关键点：
- 使用
--every 30m每 30 分钟检查一次 - 在 Prompt 中明确区分「逻辑错误」和「环境噪音」
- 只输出需要人工介入的任务
2.2 读取 Issues
# 扩展循环，让它也处理 Issues
/loop "Triage CI 和 Issues" --every 30mPrompt 模板：
请执行以下任务：
1. 检查 CI 状态（同上）
2. 检查 Issues
- 列出所有未分配的 Issues
- 按优先级排序（P0 > P1 > P2）
- 标注出「可以自动化处理」的 Issues
3. 生成 Triage 报告
- 合并 CI 失败和 Issues
- 按优先级排序
- 输出为结构化的任务列表输出示例：
┌─────────────────────────────────────────────────┐
│ Triage 报告（示例） │
├─────────────────────────────────────────────────┤
│ │
│ P0 - 紧急 │
│ ┌───────────────────────────────────────────┐ │
│ │ [CI-失败] 生产环境部署失败 │ │
│ │ └─ 原因：数据库迁移脚本错误 │ │
│ │ │ │
│ │ [Issue] 用户无法登录 │ │
│ │ └─ 原因：认证服务超时 │ │
│ └───────────────────────────────────────────┘ │
│ │
│ P1 - 高优先级 │
│ ┌───────────────────────────────────────────┐ │
│ │ [CI-失败] 单元测试失败（3 个用例） │ │
│ │ └─ 原因：边界条件处理错误 │ │
│ │ │ │
│ │ [Issue] 需要添加导出功能 │ │
│ │ └─ 标记：可自动化 │ │
│ └───────────────────────────────────────────┘ │
│ │
│ P2 - 中优先级 │
│ ┌───────────────────────────────────────────┐ │
│ │ [CI-失败] 集成测试失败（1 个用例） │ │
│ │ └─ 原因：测试数据过期 │ │
│ └───────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────┘第三步：加一个状态文件，让它有记忆
问题： 默认情况下，每次循环都是「全新」的，Claude 不记得上次做了什么。
解决： 用一个状态文件来存储循环的历史和进度。
3.1 创建状态文件
# 创建状态文件目录
mkdir -p .loop
# 创建初始状态文件
cat > .loop/state.json << 'EOF'
{
"lastCheck": null,
"processedItems": [],
"pendingItems": [],
"metrics": {
"totalChecks": 0,
"itemsProcessed": 0,
"itemsSkipped": 0
}
}
EOF3.2 更新循环 Prompt
请执行以下任务：
1. 读取状态文件
- 加载 .loop/state.json
- 读取上次检查的时间和已处理的任务
2. 检查 CI 状态和 Issues（同上）
3. 对比状态
- 过滤掉已处理的任务
- 只保留新增或状态变更的任务
4. 更新状态文件
- 记录本次检查的时间
- 更新已处理的任务列表
- 更新指标
5. 输出 Triage 报告（只包含新增任务）状态文件的作用：
- 避免重复处理：同一任务不会在每次循环中重复出现
- 历史追溯：可以查看循环的历史记录
- 指标统计：可以追踪循环的效率
第四步：加一个 Evaluator，让它能说不
问题： Claude 可能会「自欺欺人」，认为自己的方案没问题。
解决： 引入第二个 Agent（Evaluator）进行对抗性审查。
4.1 创建 Evaluator 配置
# 创建 Evaluator 配置文件
cat > .loop/evaluator.md << 'EOF'
# Evaluator 角色定义
你是一个严格的代码审查者，负责评估 Claude 的工作质量。
## 你的任务
1. **审查 Triage 结果**
- 检查是否有遗漏的失败或 Issue
- 验证优先级排序是否合理
- 确认根因分析是否准确
2. **审查修复方案**（如果有）
- 检查方案是否真的解决了问题
- 评估是否引入了新的风险
- 判断是否有更简单的方案
3. **必须找问题**
- 至少找出 1 个潜在问题
- 如果真的没问题，解释为什么
## 输出格式评估结果：PASS / FAIL
评估理由： ...
## 重要规则
- 你只读需求和结果，不读实现代码
- 你必须「故意说不」，除非真的完美
- 如果置信度 < 80%，标记为 FAIL
EOF4.2 更新循环，加入 Evaluator
请执行以下任务：
1. 读取状态文件
2. 检查 CI 状态和 Issues
3. 生成 Triage 报告
4. **调用 Evaluator 审查**
- 将 Triage 报告发送给 Evaluator
- Evaluator 是一个独立的 Agent
- 使用 .loop/evaluator.md 作为系统提示
5. 处理 Evaluator 的反馈
- 如果 Evaluator 说 PASS → 输出报告
- 如果 Evaluator 说 FAIL → 修改并重新审查
6. 更新状态文件
7. 输出最终报告Evaluator 的作用：
- 对抗性审查：打破 Claude 的「自欺欺人」
- 质量保证：确保输出真正可靠
- 持续改进：通过反馈提升质量
第五步：加 Worktree，让它并行
问题： 默认情况下，Claude 的所有操作都在同一个工作目录中，多个任务会互相干扰。
解决： 使用 --worktree（或 -w）为每个后台 Agent 开一个独立的 worktree。
5.1 Worktree 的优势
┌─────────────────────────────────────────────────────────┐
│ Worktree 的优势 │
├─────────────────────────────────────────────────────────┤
│ │
│ 不使用 Worktree： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Agent 1 在修复 bug A │ │
│ │ └─ 修改了文件 X │ │
│ │ │ │
│ │ Agent 2 在修复 bug B │ │
│ │ └─ 修改了文件 X（冲突！） │ │
│ │ │ │
│ │ 结果：相互踩脚，需要手动解决冲突 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 使用 Worktree： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Agent 1 在 worktree-1 中修复 bug A │ │
│ │ └─ 修改了文件 X │ │
│ │ │ │
│ │ Agent 2 在 worktree-2 中修复 bug B │ │
│ │ └─ 修改了文件 X（独立副本！） │ │
│ │ │ │
│ │ 结果：互不干扰，可以并行执行 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘5.2 在循环中使用 Worktree
请执行以下任务：
1. 读取状态文件
2. 检查 CI 状态和 Issues
3. 生成 Triage 报告
4. 调用 Evaluator 审查
5. **为每个任务创建独立的 Worktree**
- 使用 --worktree 或 -w 参数
- 每个任务在一个独立的 worktree 中执行
- 避免任务之间的相互干扰
6. 在各自的 Worktree 中执行修复
- Agent 1 修复 bug A（在 worktree-1 中）
- Agent 2 修复 bug B（在 worktree-2 中）
- Agent 3 修复 bug C（在 worktree-3 中）
7. 更新状态文件
8. 输出最终报告（包含所有 worktree 的状态）Worktree 的技术细节：
# Git Worktree 的工作原理
# 共享 .git 目录，但有不同的工作目录
git worktree add ../worktree-1 -b fix-bug-A
git worktree add ../worktree-2 -b fix-bug-B
git worktree add ../worktree-3 -b fix-bug-C
# 每个 worktree 可以独立操作
cd ../worktree-1
# Agent 1 在这里修复 bug A
cd ../worktree-2
# Agent 2 在这里修复 bug B
# 最后，将所有 worktree 的变更合并回主分支完整的 Loop 配置
将以上五步整合起来，你的完整 Loop 配置如下：
请执行以下任务：
1. **读取状态文件**
- 加载 .loop/state.json
- 读取上次检查的时间和已处理的任务
2. **检查 CI 状态和 Issues**
- 读取 GitHub Actions 的最新运行结果
- 找出所有失败的构建（逻辑错误）
- 列出所有未分配的 Issues
- 按优先级排序（P0 > P1 > P2）
3. **对比状态**
- 过滤掉已处理的任务
- 只保留新增或状态变更的任务
4. **生成 Triage 报告**
- 合并 CI 失败和 Issues
- 按优先级排序
- 简要说明每个任务的根因
5. **调用 Evaluator 审查**
- 将 Triage 报告发送给 Evaluator
- 使用 .loop/evaluator.md 作为系统提示
- Evaluator 必须找出至少 1 个潜在问题
6. **处理 Evaluator 的反馈**
- 如果 Evaluator 说 PASS → 继续
- 如果 Evaluator 说 FAIL → 修改并重新审查
7. **为每个任务创建独立的 Worktree**
- 使用 --worktree 或 -w 参数
- 每个任务在一个独立的 worktree 中执行
8. **在各自的 Worktree 中执行修复**
- 分析问题
- 设计修复方案
- 编写代码
- 运行测试
9. **更新状态文件**
- 记录本次检查的时间
- 更新已处理的任务列表
- 更新指标
10. **输出最终报告**
- 列出所有处理的任务
- 包含每个 worktree 的状态
- 提供修复方案的摘要启动循环：
/loop "执行完整的 Triage 和修复流程" --every 30m --worktree五步总结
┌─────────────────────────────────────────────────────────┐
│ 五步打造你的第一个 Loop 工程 │
├─────────────────────────────────────────────────────────┤
│ │
│ 第一步：认识 /loop │
│ ┌─────────────────────────────────────────────────┐ │
│ │ · 单次循环：定时任务 │ │
│ │ · 条件循环：事件驱动 │ │
│ │ · 持续循环：长期运行 │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ 第二步：让它读 CI 和 Issue │
│ ┌─────────────────────────────────────────────────┐ │
│ │ · 检查 CI 状态，分析失败原因 │ │
│ │ · 列出 Issues，按优先级排序 │ │
│ │ · 生成 Triage 报告 │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ 第三步：加一个状态文件 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ · 创建 .loop/state.json │ │
│ │ · 记录历史和进度 │ │
│ │ · 避免重复处理 │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ 第四步：加一个 Evaluator │
│ ┌─────────────────────────────────────────────────┐ │
│ │ · 创建 .loop/evaluator.md │ │
│ │ · 引入对抗性审查 │ │
│ │ · 质量保证 │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ 第五步：加 Worktree │
│ ┌─────────────────────────────────────────────────┐ │
│ │ · 使用 --worktree 或 -w │ │
│ │ · 每个 Agent 独立 worktree │ │
│ │ · 互不踩脚，并行执行 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘从这里到哪里？
你已经完成了第一个 Loop 工程。接下来：
监控循环的运行
- 定期查看 .loop/state.json
- 关注循环的指标（处理率、准确率）
- 调整时间间隔（
--every参数）
优化 Evaluator
- 根据反馈调整审查标准
- 添加更多检查维度
- 提高审查的准确度
扩展循环的能力
- 添加更多的数据源（不仅限于 CI 和 Issues）
- 支持更复杂的任务（不仅是 bug 修复）
- 集成更多的工具（不仅限于 Git）
保持工程师身份
- 定期抽查循环的输出
- 理解循环的工作原理
- 主动思考改进空间
关键洞察
五步的本质：
- 第一步：理解工具的能力和形态
- 第二步：让工具感知外部世界
- 第三步：让工具记住历史
- 第四步：让工具有批判性思维
- 第五步：让工具能并行工作
从零到一，五步实战，让 AI 真正「自己转起来」。
收尾金句
- 第一步：认识 /loop 的三种形态
- 第二步：让它读 CI 和 Issue，先做 triage
- 第三步：加一个状态文件，让它有记忆
- 第四步：加一个 evaluator，让它能说不
- 第五步：加 worktree，让它并行
- Claude Code 用 --worktree（或 -w）给每个后台 agent 开一个独立 worktree
- 互不踩脚
- 五步打造你的第一个 Loop 工程
- 从零到一，让 AI 真正「自己转起来」
基于 Claude Code 打造你的第一个 Loop 工程
五步实战指南