最近 AI 圈子里流行一个新说法——设计 Loop循环而不是写 Prompt。但如果你去 X推特上扒一扒会发现每个人对什么是 Loop的理解都不太一样众说纷纭。好在 Claude Code 官方团队最近发了一篇博客Getting started with loops给出了一套清晰的定义和分类。什么是循环LoopClaude Code 团队的定义很简洁循环就是 Agent 不断重复工作—检查的过程直到满足某个停止条件为止。他们从四个维度给循环分类循环是怎么被触发的循环怎么停止用到了 Claude Code 的哪个功能组件最适合哪种类型的任务按照复杂度从低到高,一共有四种循环类型回合制循环、目标循环、时间循环、主动循环。下面逐个拆解。回合制循环(Turn-based loop):最基础的日常用法触发方式:你发一条 Prompt停止条件:Claude 自己判断任务完成了,或者需要你补充信息适用场景:不属于固定流程、体量较小的任务优化方式:写更精准的 Prompt,用 Skill 强化自检能力这其实就是我们每天在用的模式:你发一个指令,Claude 读代码、做修改、跑测试,然后把它认为没问题的结果交给你。你再手动检查,决定要不要继续追问。name: verify-frontend-changedescription: Verify any UI change end-to-end before declaring it done.# Verifying frontend changesNever report a UI change as complete based on a successful edit alone. Verify it the way a human reviewer would:1. Start the dev server and open the edited page in the browser.2. Interact with the change directly. For a new control (button, input, toggle): click it, confirm the expected state change, and screenshot before/after.3. Check the browser console: zero new errors or warnings.4. Use the Chrome Devtools MCP, run a performance trace and audit Core Web Vitals.If any step fails, fix the issue and rerun from step 1 — do not hand back partially verified work.官方给了一个很实用的技巧:把你人工验收的步骤,写成一份 SKILL.md,让 Claude 学会像人类审查员一样自己验证工作,而不是改完就交差。比如给前端改动写一份验证清单,要求它必须启动开发服务器、真实点击交互、检查控制台报错、跑性能审计,任何一步失败就打回重做。验证标准越量化,Claude 自我核查的效果就越好。目标循环(Goal-based loop,/goal):把完成标准交给 Claude触发方式:实时手动输入停止条件:达成目标,或者达到你设定的最大尝试次数适用场景:有明确、可验证退出标准的任务优化方式:设定具体的完成标准和明确的次数上限,比如最多试 5 次单轮对话有时候不够用,复杂任务需要 Claude 反复迭代。这时可以用 /goal 明确告诉它什么叫做完成了,这样 Claude 就不用自己纠结差不多得了还是再改改,而是由一个独立的评估模型来判断,没达标就继续干,直到目标达成或次数用完。官方特别强调:尽量用可量化的标准,比如测试通过率、某项分数达标,这样效果最好。示例:/goal 把首页的 Lighthouse 得分提到 90 分以上,最多尝试 5 次。时间循环(Time-based loop,/loop和/schedule):定时自动跑触发方式:按固定时间间隔停止条件:你手动取消,或者工作本身完成了(比如 PR 被合并、队列清空)适用场景:周期性重复的工作,或者需要跟外部系统交互的任务优化方式:间隔时间拉长一些,或者改成事件触发而不是定时触发有些工作是重复性的,比如每天早上总结一下 Slack 消息;还有些工作依赖外部系统的状态变化,比如一个 PR 可能随时收到评论或者 CI 报错。用 /loop 可以让 Claude 按固定间隔重复执行同一个 Prompt,例如:/loop 5m 检查我的 PR,处理评审意见,修复失败的 CI需要注意,/loop 是跑在你本地电脑上的,关机就停。想让它 7x24 跑在云端,可以用 /schedule 把它变成一个常驻的例行任务(routine)。主动循环(Proactive loop):完全无人值守的自动化流水线触发方式:事件或计划表触发,全程没有人在场停止条件:每个子任务完成自己的目标就退出,整个例行任务(routine)则一直跑到你手动关闭适用场景:大量重复、定义清晰的工作流,比如 bug 报告处理、issue 分诊、代码迁移、依赖升级优化方式:琐碎工作交给更小更快的模型,关键判断才用最强模型这是最高阶的形态,把前面几种能力,加上auto 模式和**动态工作流(dynamic workflows)**组合起来,处理长期运行的复杂任务。以处理用户反馈为例,可以这样搭:用 /schedule 定时检查是否有新的问题反馈用 /goal 定义完成的标准,配合 Skill 说明怎么验证用动态工作流编排多个子 Agent,分别负责分诊、修复、评审开启 auto 模式,让整个流程不用人工放行就能跑下去组合起来大概长这样:/schedule 每小时:检查 #project-feedback 频道里的 bug 报告。 /goal:本轮发现的所有报告都要被分诊、处理并回复,不许提前停。 修复 bug 时,用工作流在三个并行的 worktree 里探索三种方案,并让一个裁判 Agent 交叉评审。用循环,不代表放弃质量把关官方特意提醒:循环产出的质量,取决于你围绕它搭建的系统本身。几个关键点:保持代码库整洁:Claude 会顺着已有的代码风格和约定走,脏代码只会带来更多脏代码给 Claude 自检的手段:把什么叫做得好写成 Skill让文档触手可及:框架和库的最新文档要方便 Claude 查到用第二个 Agent做代码评审:一个带着全新上下文的评审者更客观,不会被主 Agent 的思路带偏。可以用内置的 /code-review,或者 GitHub 上的 Code Review 功能而且不要只满足于修好这一个问题,发现问题后最好想办法把经验固化下来,让系统本身变得更好,惠及以后所有的循环。怎么控制 Token 消耗循环最大的风险是越跑越贵。官方给了几条实操建议:小任务不需要多 Agent 或复杂循环,选对模型和组件很重要,便宜快速的模型能省则省明确完成的标准,让 Claude 尽早收敛(但也别太早收敛导致质量不够)大规模跑之前先小范围试跑——动态工作流一次能拉起几百个 Agent,先摸清用量再放开跑确定性的工作用脚本解决,比脚本让模型重新推理一遍要便宜得多例行任务的检查频率别设得太频繁,跟它监控对象实际变化的频率匹配就好定期用 /usage、/goal(不带参数)、/workflows 等命令查看用量,该停就停一张表看懂四种循环官方给的入门建议其实很朴素:回头看看你自己日常做的工作,找一个你是瓶颈的任务,问自己能不能把某一部分交出去——是验证标准可以写清楚吗?目标够明确吗?工作是不是按周期出现的?想清楚之后,先跑起来,观察它在哪里卡壳、在哪里用力过猛,再慢慢迭代。不是所有任务都需要上主动循环,从最简单的方案开始,按需选用才是这套体系的核心心法。更多transformerVITswin tranformer 参考头条号人工智能研究所 v号人工智能研究Suo, 启示AI科技动画详解transformer 在线视频教程
