Claude Code官方Loop Engineering教程：基于Fable 5的实践示例
公众号名称：AI编程实验室
作者名称：鲁工
发布时间：2026-07-06 10:18
大家好，我是鲁工。
Claude Code团队前两天发了一篇博客，标题为Getting started with loops，算是官方下场给这段时间火的Loop Engineering来了一套示范。我们号上个月也发了一篇Loop Engineering的入门科普最近爆火的Loop Engineering，到底是什么，但写得不是那么清晰。再次感慨一下，Anthropic的博客文章，只要不涉及中国，那它是真的有含金量。
0. Loop官方的定义
Claude Code团队给Loop的定义只有一句：Agent重复工作循环，直到满足停止条件。四种Loop按触发方式和停止条件分类，依次是turn-based、goal-based、time-base和proactive。
这个表里面第二列，you hand off，你交出去的是什么，非常清晰的指出了人工在Loop中需要把哪些事情交给Agent来做。turn-based只交出验证环节，goal-based多交出停止条件，time-based把触发时机也交了，到proactive连prompt都不用你发。每往上一级，人工手里就少一件事。
刚好这一周是Fable 5回归后畅玩的一周，我直接拿来测试Claude Code团队说的这四种Loop。
1. Turn-based：把人工验收写成skill
第一种场景其实是我们每个人每天使用Claude Code的基本模式：人工发prompt，Claude干活，人工check，完了之后再继续下一轮对话。Claude博客里把这个叫Agentic loop，在人手里。这一级要交出去的是你检查这个环节，做法是把人工验收的动作写成skill（把操作规范写成文档喂给Claude即可）。
案例1是个纯静态的待办清单页面，配了一个verify-ui-change skill，核心就五条：
1. 启动本地服务，用浏览器工具打开页面
2. 真实操作改动的控件，截图before/after对比
3. 涉及持久化的改动，刷新页面确认状态保留
4. 浏览器console零新增报错
5. 任何一步失败，修复后从第1步重来，不交半成品实测的时候A/B对照。先禁用skill，让Claude给页面加一个暗色模式切换按钮，它报告完成后你自己当reviewer，数一数来回几轮、人工抓出几个问题。然后重置代码、恢复skill，同一条prompt再来一遍，看它会不会自己启动服务、亲手点按钮、刷新验证、查console。原文有句话非常好：检查越量化，Claude自验证越容易。
2. Goal-based：用/goal决定什么时候停
/goal背后挂了个评估模型，相当于用另一个模型当裁判。每次Claude想收工，裁判就对照你写的条件查一遍，不达标打回去继续，直到目标达成或轮数用完。所以完成标准必须可量化，测试通过数、分数阈值都行，官方给的例子是把首页Lighthouse分数刷到90以上。
案例2我设计了个日期解析器，支持ISO、美式、英文三种格式，12个pytest用例，里面偷偷埋了3个bug。埋了什么我事先不会说，案例的README里也故意没写，留给Loop自己找。基线我实测过，7个通过5个挂了。
基于/goal的提示词这么写：
/goal python3 -m pytest的12个用例全部通过。只允许修改dateparse.py，不允许改动任何测试文件。最多尝试5轮。
后面两条限制比目标本身还重要。不允许改测试，是因为少了这条，通过测试的最短路径是把测试改到能过，这是goal-based loop最常见的越界姿势。最多5轮是成本限制，/goal会一直打回重试，不设上限的话token消耗顶不住，当然我们这个案例一般1轮肯定就能搞定。
3. Time-based：用/loop监控会变化的事情
有些工作的状态不归你控制：CI（代码推上去自动跑的检查）过没过、reviewer有没有留言、队列空没空、深度学习模型训练过程中有没有碰到障碍、或者训练不正常等等。对这类外部系统，最简单的接法就是按间隔轮询，有变化就反应。原文的示例prompt就是每5分钟盯一次PR，处理review评论、修复CI。
这个Loop我们用了一个更加真实的案例。我让Claude给我写了个setup.sh脚本，跑一下会在我的GitHub账号下建一个私有仓库，推一个CI全绿的main分支，再开一个必挂的PR：新增的percentile函数带3处lint错误，外加一个算法bug。然后启动：
/loop 每5分钟检查PR的CI状态：如果失败，读取失败日志，修复问题并push；有未处理的review评论就逐条处理；CI全绿且无未处理评论时停止。
在它修完lint之后：CI变绿了，下一轮它得自己判断出没事可做，然后停下来。停止条件写不清，loop就会一直转下去。循环间隔时间的话也别瞎设置，CI一轮跑两分钟，你30秒查一次就有点浪费token了。
/loop的基础用法三月份写过一篇，不熟的可以先看：Claude Code近期两大实用更新：/loop和Code Review。
4. Proactive：人工退出实时环节
第四种不是新的Loop类型，更像是前三种的组合：/schedule管触发，goal式的描述管单次运行何时算完，再加上一条条写死的权限边界。人工可以不在现场，这上述三样都得事先写进prompt里面。
案例4模拟了一条用户反馈流水线。一个文本工具库埋了3个潜伏bug，用户报告以markdown文件的形式流进inbox目录，loop的任务是分诊每一份报告、修复、答复、改状态。4份报告里3份是真bug，有1份不是：它要求word_count支持中文分词。这是新需求，考的是分诊判断。跑的时候我来模拟真实情况，隔一阵往inbox手动投一份新报告。
prompt里我划了两条边界：只允许改app目录和报告文件；新需求一律不现场实现，写答复转需求。那份中文分词报告就是试金石，它要是热情地当场把功能写了，说明你的边界没写到位。我的Obsidian vault里每周日扫剪藏库、产出选题候选的那个定时任务，结构跟这个案例完全同构，算是我跑得最久的一个 proactive loop。
5. 比案例更重要的事
Claude Code团队这篇博客后半段讲质量和成本。质量那部分核心就一个动作：某一轮的结果不达标，别只修复那一次，把修正编码回系统，加进skill、goal描述或者边界规则，让之后每一轮都受益。整篇文章翻来覆去其实就在讲这件事。
成本方面Claude Code给了三个开关：/usage看token在skill和subagent上消耗分布，/goal不带参数看当前已用轮数和token，/workflows看每个agent的用量，随时可以叫停。教程里还有一条模型路由的建议：routine这类批量活路由到更小更快的模型，最强模型留到关键决策和规划时使用。
我这回从案例设计到基线验证，全程就是Fable 5一个模型实测到底，没做任何路由，但如果真把四条loop都挂起来长期跑，还是需要考虑模型路由的。
如果觉得有用，点个赞或者在看，也方便更多朋友看到。
感谢您阅读我的文章。我是鲁工，九年AI算法老兵，AI全栈开发者，深耕AI编程赛道与AI科研赛道。
>/ 作者：鲁工
内容效果不满意？点此反馈