Loop Engineering 实操篇手把手教你写第一个 Loop适合人群用过 Claude Code 的开发者、想让 AI 自动修 Bug 的效率控、上篇看完想动手的技术人01 先别急你真需要 Loop 吗上一篇我们聊了 Loop Engineering 是什么。评论区问得最多的一句道理我懂了可到底怎么动手别急着上手。Loop 不是白来的——它烧 Token、要花时间搭、出了问题你还得去 debug 一个你没盯着它跑过的系统。前置条件动手前先确认- 你用过 Claude Code熟悉基本操作- 你的项目有自动化测试至少能跑npm test或pytest- 你有 GitHub CLIgh命令已登录- 你的 Claude Code 是最新版本先拿四个问题把自己问一遍第一这活你是不是每周都要干好几遍一锤子买卖的话写个好 Prompt 更快更省搭 Loop 纯属杀鸡用牛刀。第二有没有东西能自动判定这活干砸了测试、类型检查、linter、构建脚本随便哪个能当裁判都成。没有裁判Loop 吐出来的东西你还得一行行读 diff 去验——那它省了啥第三Token 预算扛得住浪费吗Loop 会反复读上下文、重试、试探不出活也照样烧。第四你打算 review 它产出的代码吗不打算那别建了真的。一句话总结如果你发现自己在重复做给 AI 下指令 → 检查结果 → 再下指令超过三次就该考虑写个 Loop。02 Claude Code 里的五种自动触发很多人以为 Loop 就是/loop一个命令。其实在 Claude Code 里自动化触发有好几种形态它们共同构成了 Loop 的设计空间触发方式命令适合场景定时循环/loop每隔 N 分钟检查一次CI 状态、部署进度目标驱动/goal一直干到条件满足测试全过、构建成功云端定时Routines关了电脑也能跑每天早上 9 点审查 PR事件触发Hooks特定事件自动执行编辑文件后自动 lint子 Agent 并行spawn大任务拆成多个子 Agent 同时干实际工作流里这些形态会组合使用。比如一个定时 Loop 每天早上触发主 Agent 分析今天有哪些任务然后 spawn 多个子 Agent 并行执行每个子 Agent 用 Goal 循环验证自己的结果。03 最简单的一个 Loop5分钟上手不需要三层架构不需要写配置文件。打开 Claude Code照着做就行。第一步准备一个有测试的项目cd your-project # 进入你的项目目录 npm test # 确认测试能跑有通过有失败最好第二步输入 Loop 命令在 Claude Code 里直接输入/loop 2m 运行 npm test如果有失败就分析报错原因并修复直到全部通过Claude Code 会每 2 分钟自动执行一次跑测试 → 有失败就分析 → 改代码 → 再跑 → 全通过就停。第三步观察它干活你会看到 Claude Code 自动1. 运行npm test2. 读报错信息3. 找到对应的源码文件4. 修改代码5. 再跑一次测试6. 如果还有失败重复步骤 2-57. 全部通过输出所有测试通过第四步看结果回到你的项目跑一下npm test确认真的全过了。再看看 git diff看它改了什么。这就是一个 Loop。和你手动跑测试→看报错→告诉 AI 改的区别在于中间那几轮没有你。如果你的项目没有测试怎么办用 linter 代替/loop 2m 运行 eslint .如果有报错就修复直到零报错04 进阶Builder Checker 双 Agent 模式单 Agent 跑 Loop 有一个致命问题写代码的 Agent 往往高估自己的答案。写完再问自己行不行答案大概率是行。解决方案把执行和验证拆开用两个专职 AgentBuilder— 只负责写代码和修代码不自己检查。Checker— 只负责跑测试、跑 linter、检查结果不碰代码。两个 Agent 放在 Claude Code 的.claude/agents/目录下builder.mdname: builder description: 负责编写和修复代码 tools: Read, Write, Edit, Glob, Grep, Bash model: sonnet --- 你只负责构建和修复不做其他任何事情。 接到任务时 1. 先读项目的 README、package.json理解架构和编码约定 2. 确认任务涉及的文件范围 3. 开始实现 接到修复请求时 1. 逐条阅读 Checker 报告的失败项每条都要读到 file:line 2. 定位根因区分症状和病因测试失败是症状代码逻辑错误是病因 3. 一次只修一个根因 4. 不要顺手重构不相关的代码checker.mdname: checker description: 负责验证代码质量 tools: Read, Bash, Glob, Grep model: sonnet --- 你只负责检查不修改任何代码。 检查清单 1. 运行测试套件记录所有失败 2. 运行 linter记录所有警告 3. 运行类型检查如有 4. 检查是否有明显的逻辑错误 输出格式 每条失败必须包含文件路径、行号、错误信息、严重程度然后在编排器里写循环逻辑Builder 改完 → Checker 检查 → 有失败就反馈给 Builder → 再检查 → 直到全绿。05 四个最实用的 Loop 场景不是所有任务都适合 Loop。以下四个场景是目前最成熟的场景一CI 失败自动修复/loop 5m 检查 GitHub Actions 的 CI 状态如果有失败的测试就分析原因并修复适合场景团队协作频繁合并代码CI 经常因为小问题挂掉。Loop 会自动检测失败、分析报错、修复代码、提交 PR。场景二批量重构/goal 把项目中所有的 var 声明改成 const 或 let全部测试通过适合场景20 个文件都有同一个需要改的逻辑。手动改一个测试一个太慢让 Loop 自动改完验证。场景三Issue 转 PR用 Routines 配置定时任务每天早上 9 点检查 GitHub 上 label 为 good first issue 的未分配 Issue选一个最简单的分析需求实现代码跑通测试提交 PR 草稿。适合场景开源项目维护者Issue 太多处理不过来。Loop 自动筛选、实现、验证你只需要 review PR。场景四每日代码审查用 Routines 配置定时任务每天下午 5 点检查今天所有新提交的 PR对每个 PR 给出代码审查意见包括潜在 bug、风格问题、性能隐患。适合场景你是 Tech Lead每天要审一堆 PR。Loop 先过一遍你只需要看它标记的问题。06 Loop 的边界控制Loop 最大的风险不是做不好而是做错了还停不下来。没有边界控制的 Loop 就像一辆没有刹车的车。2023 年 AutoGPT 就试过让 AI 自己跑循环没有验证、没有边界结果烧了一堆 Token产出的东西基本不能用。必须设的四个边界条件1. 最大迭代次数max_iterations: 50 # 超过 50 次还没搞定大概率是方向错了2. Token 预算上限max_tokens: 500000 # 防止一个 Loop 把你的月度配额烧光3. 连续失败阈值max_consecutive_failures: 5 # 连续 5 次没有进展说明卡住了需要人介入4. 进展度量progress_metric: 测试通过率 # 每轮对比上一轮如果没有改善提前退出一个判断标准如果 Loop 跑了 10 轮你完全不知道它在干嘛、有没有接近目标说明你的 Loop 设计有问题。07 五个最常见的 Loop 反模式反模式一乒乓循环Agent 在两个状态之间来回切换永远停不下来。迭代1我需要检查配置文件 迭代2配置文件看起来没问题 迭代3等等还是再检查一下配置文件吧 迭代4配置文件确实没问题 迭代5让我再确认一遍配置...解法设连续无进展阈值超过 3 次直接退出。反模式二过度修复Agent 修了一个 Bug引入了两个新 Bug。修新 Bug 又引入更多 Bug。越修越多。解法每轮修复后必须跑完整测试套件。如果新失败数 上一轮回滚这次修改。反模式三上下文膨胀Agent 跑到第 20 轮时上下文窗口里塞满了前面 19 轮的历史真正有用的信息被淹没了。解法每轮只保留关键信息当前任务、最近一次成功、最近一次失败原因丢弃中间过程。反模式四盲目执行Agent 拿到任务就开始干不先理解项目结构和编码约定结果写出的代码风格完全不对。解法在 Agent 定义里强制要求先读 README 和编码约定再动手。反模式五无人 reviewLoop 跑完了代码自动合并了没人看过。三天后线上出了问题。解法Loop 只负责提交 PR 草稿必须有人 review 后才能合并。永远不要让 Loop 直接推代码到 main 分支。08 Loop 的五个构件想搭一个靠谱的 Loop你需要这五个构件。每个都能单独用、单独试1. Automation触发器Loop 的心跳。按节奏触发——定时、或某个事件。Claude Code 用/loop和 Routines 配。关键是停止条件要写死别让它无限跑。2. Worktree工作隔离多个 Agent 同时干活最怕它们改同一个文件。Git worktree 给每个 Agent 一份独立工作区互不干扰最后再合。3. Skill项目记忆项目用什么框架、有什么约定、踩过什么坑写成一个文档存着。Agent 每轮直接读省得你每次从零解释。Claude Code 里就是CLAUDE.md文件。4. Connector工具接入只能看文件系统的 Loop 干不了几件事。通过 MCP 接上 GitHub开 PR、Slack发通知、CI查状态Loop 才算真正接入你的工作流。5. Sub-agent职责分离写的和验的分开。这可能是最有用的一个改造。Builder 只写Checker 只查编排器负责调度。09 一个完整的 Loop 实战案例用一个真实场景演示自动修复 CI 失败。背景你的项目用 GitHub Actions 跑 CI经常有人合并代码后测试挂了。第一步写 CLAUDE.md# 项目约定 - 语言TypeScript - 测试框架Jest - 包管理pnpm - CIGitHub Actions - 分支策略main 分支保护必须通过 CI 才能合并 # 常见 CI 失败原因 - import 路径错误新文件忘加到 tsconfig - 测试文件没有 mock 外部依赖 - 类型错误any 类型泛滥第二步写 Checker Agentname: ci-checker description: 检查 CI 状态并分析失败原因 tools: Read, Bash --- 步骤 1. 运行 gh run list --limit 1 获取最新 CI 状态 2. 如果状态是 success输出CI 正常并退出 3. 如果状态是 failure运行 gh run view id --log-failed 获取失败日志 4. 分析失败原因输出 - 失败的测试文件和行号 - 错误信息 - 可能的原因第三步写 Builder Agentname: ci-fixer description: 根据 Checker 的分析修复代码 tools: Read, Write, Edit, Bash --- 规则 1. 只修复 Checker 报告的问题不改其他代码 2. 修复后立即运行对应的单个测试验证 3. 单个测试通过后运行完整测试套件确认没有引入新问题 4. 如果修复需要改动超过 5 个文件停止并请求人工介入第四步配置 Loop在 Claude Code 中输入概念示例具体语法以 Claude Code 官方文档为准/loop 5m 1. 用 ci-checker 检查 CI 状态 2. 如果 CI 正常什么都不做 3. 如果 CI 失败用 ci-fixer 修复 4. 修复后推送代码等待下一轮 CI 5. 最多试 3 轮3 轮后还有失败就通知我第五步撒手Loop 每 5 分钟自动检查一次。CI 挂了它自己修修好了它自己推推完它自己等结果。3 轮修不好才叫你。10 关于我国内某互联网上市公司高级研发工程师、研发组长致力于 AI 方面的研究和学习分享。关注我一起学习成长。《MC AI技术开发》