Claude Code循环实战：实测三种循环的token消耗对比
内容提要
Claude Code循环工程虽能自动化AI编程，但token消耗惊人，可能烧钱失控。文章介绍四种循环模式：turn-based、goal-based、time-based和proactive，各有优劣。核心风险是循环易失控、验证不可靠，导致巨额费用。建议选对类型、明确完成条件、设上限、谨慎用auto mode、小范围试跑并监控用量，避免AI“自证正确”的陷阱。
延伸解读
循环失控的真实代价
文章列举了多个循环失控的案例：有人一晚上烧掉六千美元，有人单次会话消耗八十万token，还有人因死循环产生五百多美元账单。这些案例提醒我们，循环工程虽然能自动化任务，但若缺乏有效控制，token消耗可能远超预期。理解这些风险是使用循环工程的前提。
如何选择循环类型
文章介绍了四种循环模式：turn-based适合短任务，goal-based适合有明确完成标准的任务，time-based适合定时任务，proactive适合完全自动化。选错类型可能导致浪费或失控。例如，任务已完成但time-based循环仍会继续运行，而goal-based循环若条件定义不清晰则可能永远停不下来。
验证环节的陷阱
循环工程中，验证任务也交给AI，但AI可能只根据对话记录中的内容判断，甚至可能“自证正确”。例如，Claude可能声称测试通过但实际未运行。因此，验证条件必须可量化且可被AI输出证明，同时要警惕AI在验证环节的不可靠性。
控制成本的六条法则
文章提出六条保命法则：选对循环类型、定义明确的完成条件、设置轮次和预算上限、谨慎使用auto mode、小范围试跑、监控用量。这些措施能有效防止循环失控和token浪费，是使用循环工程时的重要参考。
Q&A
Claude Code的循环工程有哪几种模式？
Claude Code的循环工程主要有四种模式：turn-based loops（基于回合）、goal-based loops（基于目标）、time-based loops（基于时间）和proactive loops（主动循环）。
turn-based loops和goal-based loops有什么区别？
turn-based loops需要用户手动触发每一轮，Claude执行任务后由用户验收；而goal-based loops通过/goal命令设定明确的完成条件，Claude会一直执行直到条件满足，期间不需要用户干预。
使用/goal命令时，如何定义完成条件？
完成条件必须可测量且能由Claude的输出证明，例如“所有测试通过且lint零告警”或“首页Lighthouse分数达到90以上”。条件应基于Claude执行命令后的输出，因为评估模型只读取对话记录中的内容。
time-based loops（/loop和/schedule）有什么特点？
/loop按固定时间间隔自动执行任务，每次迭代上下文独立，最小间隔1分钟，最多50个定时任务，最长存活7天；/schedule将循环部署到云端，即使关闭电脑也能运行。
什么是proactive loops？
Proactive loops是结合了/schedule、/goal和动态工作流的主动循环，通过事件或定时任务触发，全程无需人工干预。动态工作流（dynamic workflows）是核心，Claude会生成JavaScript调度脚本，并行运行多个子代理处理任务。
循环工程的主要风险是什么？
主要风险是token消耗失控，导致巨额费用。例如，有用户因循环失控单次会话消耗80万token，被扣27.6美元；还有用户因无限循环产生500多美元费用。此外，验证环节可能不可靠，AI可能“自证正确”而实际未完成任务。
如何避免循环工程烧钱？
避免烧钱的方法包括：选对循环类型、明确可测量的完成条件、设置轮次和预算上限、谨慎使用auto mode、先小范围试跑、监控usage用量。
为什么AI循环可能会“自证正确”？
因为验证环节也由AI执行，评估模型和审查agent只依赖对话记录中的内容。如果Claude在对话中声称“测试通过”但实际未运行，评估模型可能信以为真，导致循环停止但结果无效。
