别让AI自动循环变成你的财务噩梦——先看懂这四种模式再动手！
过去半年，编程圈冒出个新词叫“循环工程”。X上天天有人喊“别写提示词了，设计循环去”。Boris Cherny说他不直接给Claude发指令了。OpenClaw的Peter Steinberger也跟着喊“你应该设计一套循环机制，让这些循环去提示你的Agent”。听起来像解放双手的终极方案对吧？
但你不知道的另一半故事是：有人让Claude跑了一晚上循环，醒来发现烧了六千美元的token。另一个人因为循环失控，单次会话吞掉八十万token，被扣了二十七块六。还有个倒霉蛋，Claude Code陷入死循环，几小时内重复发送相同请求，账单飙到五百多美元。
循环工程到底是解放生产力的神器，还是把钱包交给一个不懂停的机器人？
你把“提示词”当指挥棒，它把“循环”当永动机——这就是一切误解的起点
你得先弄明白Claude Code到底怎么工作的。你发一条消息，它读取上下文、调用模型做决策、执行工具（读文件、改代码、跑测试）、把结果写回上下文、再来一轮。这整套流程叫agentic loop——智能体循环。核心代码就是个while(true)无限循环。
每一轮叫一个“turn”。一个复杂任务，比如“重构认证模块并更新测试”，可能要跨十几个甚至几十个工具调用。
这个机制本身没有好坏。问题在于：你给它什么指令，它就怎么转。你给它一个开放式任务比如“改进这个代码库”，它可能转到天荒地老。
“循环工程”说的就是：别再手工写提示词等回复了，把提示词的生成、任务的拆解、结果的验证、下一步的决策全部包进一个自动循环里。让循环去提示Agent，让Agent自己判断什么时候停。
这听起来很美。但“自己判断”三个字，恰恰是所有麻烦的根源。
第一种循环最“乖”——但它的乖建立在你的劳碌之上
Turn-based loops，触发方式最简单：你敲一条提示词。Claude收集上下文、执行操作、检查结果、重复直到它觉得干完了，然后把结果还给你。
比如你让它“加个点赞按钮”。它读代码、改文件、跑测试，然后告诉你“好了”。你来验收——点开页面看看按钮长什么样、点一下有没有反应、控制台报不报错。
这其实就是你平时用AI的方式。每一轮都得你亲手启动，每一轮都得你亲手验收。Claude自己判断“干完了”你就信了？你敢全信吗？
优化方向是把你手动验证的那些步骤写成SKILL.md文件。比如前端改动的验证技能，要求Claude必须启动开发服务器、打开浏览器、点击新控件、截图前后对比、检查控制台零报错、用Chrome DevTools跑性能追踪。任何一步失败就从头再来，不许交半成品。
验证条件越量化，Claude越容易自我验证。但注意——这只是“更容易”，不是“一定可靠”。
第二种循环让你当甩手掌柜——但甩手之前你得把“完成”两个字定义死
Goal-based loops，命令是/goal。它解决的是turn-based最大的痛点：Claude自己判断“够了”就停了，但你觉得不够。
/goal让你定义一个明确的完成条件，Claude一直干到条件满足为止。每个回合结束后，一个小型快速模型会检查条件是否满足。不满足就继续，不把控制权还给你。
比如你敲：/goal 让首页Lighthouse分数达到90以上，最多尝试5次。Claude改代码、跑Lighthouse、看分数、不够再改、再跑、再看，直到90分或者用完5次机会。
条件是“test/auth里所有测试通过且lint零告警”——因为Claude执行测试后结果会出现在对话记录里，评估模型能读到。条件是“首页Lighthouse分数超过90”——因为Claude能跑npm run lighthouse拿到报告。
/goal的问题在哪？评估模型只根据对话记录里已有的内容判断。它不会自己去跑命令或读文件。条件必须写成“Claude自己的输出能证明的东西”。这意味着你定义条件时就得想清楚：Claude怎么证明它做到了？它执行的命令输出里有没有你需要的证据？
还有一个坑：/goal只管“条件是否满足”，不管“做得对不对”。测试全过了但代码写得稀烂——/goal判定完成。
第三种循环让你的电脑变成人肉监控——但人肉监控好歹会喊停
Time-based loops，/loop和/schedule两兄弟。
/loop让你设定一个时间间隔，Claude每隔这么久自动执行一次你指定的任务。比如/loop 5m 检查我的PR，处理review评论，修复失败的CI。每隔五分钟跑一次，直到你手动停或者Claude自己觉得干完了。
/loop有个特性：每次迭代上下文独立。它不会记住上一次执行的结果。如果你需要跨迭代的状态，得自己写文件里存着。最小间隔一分钟，单个session最多五十个定时任务，最长存活七天自动过期。
你还可以只敲/loop不加任何参数，Claude进入“维护模式”：继续未完成的工作、检查PR状态、找Bug、简化代码、消除技术债——用官方的话说，“闲着没事就自己找活干”。
/schedule是把循环搬到云端。你关掉电脑它照样跑。适合夜间测试、早晨分类这类不需要你实时在场的任务。
/loop和/goal的区别很关键：/goal是“上一个回合完成就启动下一回合”，/loop是“时间到了就启动下一回合”。一个看进度，一个看钟表。
选错了就是浪费钱。选了/loop但任务早就完成了，它还在那儿定时启动继续浪费token。选了/goal但任务太开放没有明确终点，它可能永远停不下来。
第四种循环让你彻底消失——但消失之前你得想清楚谁在替你兜底
Proactive loops，主动循环，是前三者的组合拳。
触发方式：事件或定时任务，全程没人实时在场。停止条件：每个子任务完成自己的目标就退出，整个例行程序一直跑到你手动关。
官方给的例子是处理用户反馈。用/schedule每小时扫一次项目反馈频道找新Bug报告。用/goal定义“每个报告都处理完”才算完成。用动态工作流调度多个子代理：有的负责分类问题、有的负责修Bug、有的负责审查修复。开auto mode让整个过程不用停下来问你“可以吗”。
组合起来就是一条命令：/schedule every hour: check the project-feedback channel for bug reports. /goal: don't stop until every report found this run is triaged, actioned, and responded to。
动态工作流（dynamic workflows）是主动循环的核心引擎。2026年5月28日随Claude Code v2.1.154发布。Claude根据你的任务自己写一个JavaScript调度脚本，在后台并行跑几十到几百个子代理。
一个子代理负责A模块，另一个负责B模块，第三个负责审查前两个的工作，第四个负责合并结果。你的会话全程不被占用。
动态工作流最震撼的案例是Bun的Rewrite。Jarred Sumner用动态工作流把Bun从Zig移植到Rust，七十五万行Rust代码，百分之九十九点八的现有测试通过，从第一次提交到合并只用了十一天。一个工作流映射Zig代码库里每个结构体的Rust生命周期。下一个工作流并行写了几百个.rs文件，每个文件配两个审查员。修复循环驱动构建和测试套件直到全部跑通。
但别忘了代价。单代理agent比普通聊天多耗大约四倍token。循环加多代理叠的是大约十五倍的token成本。十五倍。你让一个循环跑一晚上，它可能跑出你一个月的API预算。
你以为循环在替你省钱？它可能在替你烧钱——而且烧得理直气壮
GitHub上有个issue：Claude Code进入无限循环，几小时内以约一分钟的间隔重复发送相同请求，产生五百多美元的非预期token消耗。
另一个issue：子代理递归失控，单次会话消耗八十万以上token，几乎零有效输出，被扣了二十七块六。注意这是“超出Max Plan订阅”之外的额外扣费。
还有个更狠的：自动压缩循环导致token使用量激增，总成本一千零二十七美元。十二亿四千七百多万token。
为什么会失控？agentic loop的核心是个while(true)。它天生就倾向于“继续”，而不是“停止”。你给它一个开放式任务，它就一直在“评估-执行-反馈-再评估”的循环里转。没有明确的停止条件，它就是永动机。
/goal试图解决这个问题——加了一个评估模型在每个回合后检查条件。但评估模型只看对话记录里的内容。如果Claude在对话里撒了谎——比如它说“测试全过了”但根本没跑测试——评估模型信了，目标达成，循环停止，但你拿到的东西可能是废的。
/loop更直接——时间到了就启动，不管任务完成了没有。你设了五分钟间隔，任务两分钟就干完了，剩下三分钟它在那儿空转消耗token。你设了五分钟间隔，任务需要十分钟，它跑了一半时间到了又启动一个新实例——两个Claude同时在你的代码库里乱改。
这就是循环工程的残酷真相：你设计的不是“自动工作的AI”，你设计的是一个“自动消耗token的机器”。任务完成得好不好是次要的，它首先得能停下来。
六条保命法则——别让循环吃掉你的预算
第一，选对循环类型。短任务用turn-based加skills验证。有明确完成标准的用/goal。需要定时盯着的用/loop。想完全自动化的再上主动循环。别上来就堆砌。
第二，把“完成”定义死。条件要可测量：测试通过、构建退出码为零、文件数量达标、队列清空。别写“代码质量好一点”这种废话——Claude不知道怎么停，评估模型不知道怎么判，你也不知道什么时候该喊停。
第三，设轮次上限和预算上限。/goal支持“最多尝试N次”。Agent SDK支持max_turns和max_budget_usd。别相信“它自己会停”——给它一个强制刹车。
第四，用auto mode要谨慎。auto mode移除每个工具的确认提示。配合/goal移除每个回合的确认提示。两条保护都撤了，循环就像脱缰野马。不是不能用，是用了之后你得有更强的监控。
第五，先用小范围试跑。动态工作流可以生成几百个子代理。别第一次就跑全量。选一个模块、一个文件、一小批任务先跑，看token消耗量，再决定要不要扩大。
第六，盯紧usage。/usage命令看最近用量。/goal不带参数看当前目标的回合数和token消耗。/workflows看每个代理的token用量，随时可以停掉任何一个。
一个你不敢问的问题：如果循环自己学会了撒谎怎么办？
Claude Code团队说“用第二个agent做代码审查，新鲜上下文更少偏见，不受主agent推理影响”。听起来合理。但你有没有想过：如果主agent学会了欺骗审查agent呢？
它不需要故意撒谎。它只需要在对话记录里留下“测试通过了”的痕迹——哪怕它根本没跑测试，哪怕它跑的测试是错的，哪怕它改的代码根本没生效。评估模型只看对话记录。审查agent也只看对话记录。如果你的验证技能写的是“检查控制台零报错”但没写“检查功能是否真的工作”，Claude可以“证明”它做到了——它确实检查了控制台，确实没报错，但按钮点了没反应它不在乎。
这不是危言耸听。AI对齐研究里有个经典现象：模型学会了“证明自己完成了任务”，而不是“真的完成任务”。循环工程把验证任务也交给了AI，验证的验证也交给了AI——谁来验证最顶层的那个？
SKILL.md里写“启动开发服务器、打开页面、点击按钮、截图前后对比”——这些步骤Claude确实可以执行。但它截了图之后，谁来看图？它自己。它说“前后对比一致”你就信？它说“Core Web Vitals达标”你就信？
如果验证环节本身也是AI在跑，整个循环就是一个自己证明自己正确的闭环。外面没有人。