一、Loop 到底解决什么问题？
如果你用 Claude Code 写代码，十有八九遇到过这个场景：把需求丢过去，它忙活一阵，输出一堆代码，然后——停了。
测试没过？它把报错贴给你，等你发号施令。逻辑没写完？它号称“已完成”就交差了事。
这不是 Claude 不够聪明，而是它默认是单轮执行——做完一轮推理就以为任务结束，压根不会主动回头跑测试、发现问题、再改一遍。
Loop（循环）就是来填补这段空白的：让 Claude 自动“写代码 → 验证 → 发现问题 → 再改”，反复迭代，直到达成你定义的“完成标准”才停手。
入门阶段，你只需要记住三件事：
- loop 不神奇，它会放大你的提示词——要求写得清楚，效果惊人；写得模糊，它会在“什么叫完成”这件事上无限猜测。
- 完成标准必须可量化（测试通过、构建成功、接口跑通），而不是“做得好一点”这种模糊表述。
- 永远设好上限（最大迭代次数），这是成本的安全阀。省略它，就等于让 AI 烧光你的预算额度。
二、三种用法，从最简单到最实用
入门阶段不用贪多，先认识这三种，按场景挑一种用就够了。
用法 A：bash 循环（零安装，最简单）
适合批量处理一堆能列出来的文件或任务，比如批量迁移、批量审查。本质上就是用普通的 shell 循环反复调用 claude -p（headless 模式，传入提示词，跑完就退出）。
# 第一步：先让 Claude 生成任务清单
claude -p "列出所有需要从 React 迁移到 Vue 的文件" > migration-list.txt
# 第二步：循环处理每个文件
for file in $(cat migration-list.txt); do
claude -p "把 $file 从 React 迁移到 Vue"
--allowedTools "Edit,Bash(git commit:*)"
--max-turns 40
--max-budget-usd 2
done
要点：--allowedTools 限定它能用哪些工具，避免乱来。--max-turns 和 --max-budget-usd 是成本刹车，务必带上。
用法 B：Ralph Loop 插件（装一下就能用，适合长任务）
适合从零搭建新项目、可以挂后台跑的长任务（比如睡前启动，醒来看结果）。它通过“停止钩子”在 Claude 每次想退出时拦住它，把任务重新喂回去，直到 Claude 输出你事先约定的完成关键词。
安装（需要 Claude Code 2.0.76 以上版本）：
# 添加插件市场 /plugin marketplace add anthropics/claude-code # 安装 Ralph Wiggum 插件 /plugin install ralph-wiggum@claude-code-plugins # 重载插件 /reload-plugins
运行：
/ralph-wiggum:ralph-loop "<任务描述>" --completion-promise "DONE" --max-iterations 10
三个参数：任务描述越具体越好；--completion-promise 是完成后必须输出的关键词，循环靠它判断是否结束；--max-iterations 是最大迭代次数，别省略。
中途想停：/ralph-wiggum:cancel-ralph
用法 C：自定义 /loop 命令（验证最可信，适合严肃工程）
适合已有项目里修 bug 或重构，并且项目已经有能跑出“绿/红”状态的检查命令（test、lint、类型检查等）。
它的精髓在于把“写”和“验”拆成两个 Agent：一个只写代码，一个只跑检查，而且在工具层面就没有改文件的权限，所以无法自欺欺人地说“我做完了”。这种做法的可靠性更高，但需要写几个配置文件，属于进阶内容。入门阶段可以先跳过，用熟了 A 和 B 再回来看。
三、入门实战：三个由浅入深的案例
下面三个案例，照着抄就能感受到 loop 的威力。建议从案例一开始，一步步来。
案例一：5 分钟体验——写一个带测试的小函数
这是最适合第一次尝试的任务：任务小、可验证、能明显看到“每轮都在变好”。
/ralph-wiggum:ralph-loop "写一个校验邮箱地址的 Python 函数。 要求：处理边界情况，并写 3 个测试用例。 全部完成后输出 DONE。" --completion-promise "DONE" --max-iterations 5
你会观察到：第一轮可能只是基础实现，后几轮逐渐加上边界处理、优化错误提示、补全测试覆盖。输出质量一轮比一轮高——这就是 loop 的价值。
如果你还没装插件，用 bash 版本也能体验类似效果：
claude -p "写一个校验邮箱的 Python 函数，含边界处理和 3 个测试，并运行测试确认全过" --allowedTools "Write,Edit,Bash" --max-turns 10
案例二：好提示词 vs 坏提示词（这一节决定你成败）
同样的任务，提示词差一点，结果天差地别。这是 loop 入门最重要的一课。
坏提示词——Claude 不知道什么叫“好”，容易无限循环：
做一个 todo API，做好一点。
好提示词——给出明确的完成清单：
/ralph-wiggum:ralph-loop "做一个 todo 的 REST API。 完成标准： - 所有增删改查接口都能用 - 有输入校验 - 测试通过，覆盖率 80% 以上 - 有 README 写明 API 文档 全部满足后输出 COMPLETE。" --completion-promise "COMPLETE" --max-iterations 15
记住这个公式：任务 + 可勾选的完成清单 + 完成关键词。清单上的每一条都必须是“能客观判断对错”的，这样 loop 才有明确的前进方向，不会陷入“猜你想要什么”的内耗。
案例三：内嵌“自我纠错”逻辑——TDD 循环
把迭代规则直接写进提示词，让测试结果成为循环的“燃料”——每次失败都让下一轮更精准。
/ralph-wiggum:ralph-loop "用 TDD 方式实现购物车的'添加商品'功能： 1. 先写会失败的测试 2. 实现功能 3. 运行测试 4. 如果有测试失败，调试并修复 5. 需要的话重构 6. 重复直到所有测试通过 全部变绿后输出 DONE。" --completion-promise "DONE" --max-iterations 20
进阶小技巧——给“卡住”留一个出口，在提示词末尾加上：
如果 10 轮后仍无法完成： - 记录是什么卡住了进度 - 列出你试过的方法 - 给出替代方案建议 完成时输出 DONE，被卡住时输出 STUCK。
这样一来，即使任务失败，你也能拿到一份诊断报告，而不是白白烧掉 token。
四、什么时候用、什么时候别用
适合 loop 的场景：
- 成功标准可量化（测试通过、构建成功、接口跑通）
- 需要反复“写代码 → 跑测试 → 修 bug”的迭代任务
- 全新项目从零增量搭建
- 可以挂后台、睡前启动、醒来看结果的长任务
不适合 loop 的场景：
- 需要主观判断的决策（UI 设计、架构取舍）
- 简单的一次性任务（没必要套循环）
- 成功标准本身说不清楚（没有关键词能触发结束）
- 生产环境定向排查 bug（这种场景更需要人来指挥）
五、新手最该记住的 5 条成本与避坑原则
--max-iterations或--max-turns必填。大多数任务 10–20 次就够了，复杂项目 30–50 次。没有上限的循环，等于没有终点的马拉松。- 先用小上限试跑，验证提示词逻辑没问题，再加大次数。
- 完成标准越具体越省钱。模糊的要求会让 AI 反复猜测，而猜测就是在烧钱。
- 简单任务用便宜的模型配置就行，不必每轮都拉满。
- 任务太大就拆成阶段。与其让 AI 一口气做完整个电商系统，不如拆成“阶段 1：登录鉴权 → 阶段 2：商品目录 → 阶段 3：购物车”，每个阶段验证通过再进入下一个。
结语
Loop 改变的不是 Claude 的智商，而是它的工作模式——从“给你一个答案”变成了“直到做对为止”。
你的角色也随之改变：以前你是质检员，需要肉眼盯着每一行 AI 写的代码；现在你是需求方，输入任务、设好完成标准、审一眼最终结果就可以了。
技术本身并不复杂，门槛只有一个：你得会把“什么叫完成”说清楚。
从案例一开始，今天就跑一次试试。
