Claude 面试官：“提示词已死，Loop 称王！” 我冷笑：“不就是炒概念骗 token？” 她激动：“入职！我给你讲一遍”

大家好，我是程序员鱼皮。

之前我写过一篇，从概念到多工具实战，比较全面地讲了循环工程的玩法。

这两天 Claude Code 官方团队下场，发了一篇博客叫「Getting started with loops」，系统地整理了他们团队内部对「循环」的定义和分类。

这篇博客的含金量十足，作者是 Claude Code 团队的大神，分享的都是团队内部的一线经验。

下面我结合自己的使用体验，给大家做一篇中文深度解读。

原文指路：https://claude.com/blog/getting-started-with-loops

现在 AI 编程圈到处都在聊「设计循环」，但每个人对循环的理解都不太一样。

Claude Code 团队的定义是：循环就是让 AI 重复执行工作，直到满足某个停止条件。

仔细想想，日常用 AI 编程的大部分场景都可以套进去。

让 AI 修一个 Bug 直到测试通过，这是循环。

让 AI 每小时检查一次 PR 有没有新评论要处理，这也是循环。

官方根据触发方式、停止条件、适用场景的不同，把循环分成了 4 种类型。从手动循环到主动循环，你需要操心的事情越来越少，交给 AI 的越来越多。

下面我逐个来讲。

循环的 4 种类型 1、手动循环（Turn-based）

每次你给 Claude Code 发一条提示词，其实就已经启动了一个循环。

Claude 收到指令后，会自动完成一系列动作：读取上下文、执行操作、检查结果、判断是否完成、返回结果。

官方把这个过程叫做 Agentic Loop。

举个栗子，你让 Claude 加一个点赞按钮。它会先读你的代码，找到合适的位置，写入代码，跑一下测试，然后把它认为能用的结果交给你。

到这一步，“球” 又回到了你手里。

你人工检查一下效果，觉得哪里不对就再发一条提示词，下一轮循环开始。

这种模式的特点是：你控制每一轮的启动和方向。

适合比较短的、非固定流程的任务，比如你还在调研方案、还在尝试不同思路、或者只是临时需要改个东西的阶段。

那怎么让手动循环的质量更高呢？

官方的建议是：把你手动检查的步骤写成 SKILL.md，让 Claude 自己也能做验证。

比如你每次改完前端代码，都要手动开浏览器看看有没有问题、控制台有没有报错。这些步骤完全可以写成一个 Skill：

--- 
name: verify-frontend-change 
description: 在报告完成之前，端到端验证所有 UI 改动。 
--- 

 # 验证前端改动
不要仅凭代码编辑成功就报告 UI 改动已完成。
要像人类审查者一样去验证：

 1. 启动开发服务器，在浏览器中打开被修改的页面。

 2. 直接与改动进行交互。如果是新控件（按钮、输入框、开关），
   点击它，确认预期的状态变化，并截图记录前后对比。

 3. 检查浏览器控制台：确保没有新的报错或警告。

 4. 使用 Chrome DevTools MCP，运行性能追踪并审计 Core Web Vitals。

 如果任何步骤失败，修复问题后从步骤 1 重新开始，
不要交回未经完整验证的工作。

这样一来，只要你配好了对应的工具和连接器（比如浏览器 MCP），Claude 每次改完代码不会直接告诉你「改好了」，而是会打开页面验证一遍，确认没问题才交给你。

官方特别强调，检查越量化、越具体，Claude 自己判断「做没做好」的准确率就越高。

2、目标循环（/goal）

手动循环有个问题：很多任务你明明知道什么时候该停，但 Claude 不知道。它可能改了一半觉得差不多了，就停了，或者在一个小问题上纠结太久。

/goal 就是解决这个问题的。

你给一个明确的完成条件，Claude 会一直工作到条件满足为止。

这里有个关键细节，判断目标是否达成的和执行任务的不是同一个模型。每次 Claude 想停下来的时候，会有一个独立的评估模型去检查你设定的条件，如果没达标，就把它踹回去继续干。

正因为 AI 会一直干活直到达成目标，所以「目标」一定要具体、可衡量。

举个例子：

/goal 把首页的 Lighthouse 得分提升到 90 以上，5 轮还没搞定就停下来。

这段提示词中，「Lighthouse 得分 90 以上」是一个可以量化验证的指标，评估模型能很准确地判断有没有达标。

而如果你写「优化一下首页性能」，就太模糊了，模型不太好判断什么叫优化好了。

之前我修复团队产品的 Bug 时，就用 /goal 来跑。设定好「所有测试通过且零报错」的条件，Claude 一轮一轮地排查问题、尝试不同的修复方案，每轮自动跑测试，没过就继续，全过了自动停。

想中途看看进度的话，直接输入 /goal（不带参数）就能看到当前跑了多少轮、花了多少 token：

3、定时循环（/loop 和 /schedule）

前面两种循环都是你手动触发的，但有些工作本身就是周期性的。

比如每天早上总结一下邮件消息、每隔几分钟检查一下 PR 有没有新的 Review 评论需要处理。

/loop 命令就是干这个的，让 Claude 按固定时间间隔重复执行某个任务：

/loop 5m 检查我的 PR，处理 Review 评论，修复失败的 CI

上面这条命令，就是每 5 分钟自动检查一次 PR、处理 Review 评论、修复 CI 报错。你只管写自己的代码，PR 那边的琐事交给 Claude 盯着就好。

定时循环什么时候停呢？

分为两种情况：

1. 你主动取消它

2. 工作本身完成了，比如 PR 合并了、队列清空了。

不过 /loop 有个限制，它跑在你本地电脑上，电脑关了它就停了。

如果你希望循环在云端持续运行，不依赖本地环境，可以用 /schedule 创建一个云端的 Routine 定时任务，不过目前是 Research Preview 研究预览阶段。

我之前用 /loop 命令来监控一个部署任务，设置了每 5 分钟检查一次部署状态，确实很方便，不用自己来回切换窗口看进度。

但因为 /loop 跑在本地，合上笔记本就断了。后来我改用 /schedule 把同样的检查任务放到云端执行，这个痛点就解决了。

4、主动循环（Proactive loops）

到这一步，循环变得真正自动化了。

主动循环不需要你实时在场，它由事件或定时任务触发，完全在后台运行。

官方的思路是把前面提到的这些命令和能力组合起来，搭建一套完整的自动化流水线。

比如处理用户反馈这个场景：

1. 用 /schedule 设置定时任务，每小时检查有没有新的 Bug 反馈

2. 用 /goal 定义完成标准，比如每条反馈都要分类、修复、回复

3. 用 Skills 规范验证流程

4. 用 Dynamic Workflows 动态工作流来编排多个 Agent 并行工作，一个负责分类、一个负责修复、一个负责审查修复结果

5. 开启 Auto Mode 自动模式，让整个流程不需要人工确认就能自动运行

组合起来的提示词长这样：

/schedule 每小时检查一次 -feedback 频道的 Bug 反馈。
/goal 这一轮发现的每条反馈都要分类、处理、回复，全部搞定才能停。
修复 Bug 时，用 workflow 在并行工作树中探索三种方案，
再让一个评审 Agent 对每个方案做对抗性审查。

你品品这条提示词，把所有能力串在一起之后，新反馈来了自动分类、自动修复 Bug、修完还有另一个 Agent 做代码审查，审过了还会自动回复用户。

另外官方还提了一个省钱的思路，日常执行的 Routine 可以路由到更小更快的模型上跑，把最强的模型留给需要判断力的关键环节。这样成本和效果都能兼顾。

目前 /schedule 和 Dynamic Workflows 动态工作流还在 Research Preview 阶段，Auto Mode 则是其中的一个组合能力。从这个方向能看出来，Claude Code 团队在做的事情就是让 AI 能承担越来越完整的工程流程。

保持代码质量

循环跑得再溜，如果每轮产出的代码质量拉胯，那也是白费 tokens。

官方总结了几个实操要点，值得参考。

1）保持代码库本身干净整洁。Claude 会模仿你代码库里已有的模式和规范，你的代码库本身就乱七八糟的话，它写出来的也好不到哪去。

2）用 Skills 给 Claude 配一个验证自己工作的方法。检查标准越量化越好，最好让它能运行脚本、查看截图、测试性能，而不是靠它自己感觉代码没问题，AI 的感觉可不靠谱。

3）把框架和库的文档放在 Claude 能找到的地方。最新的最佳实践它不一定知道，但如果你提供了文档，它就能参考着写。这也是为什么联网搜索能力和 Context7 这类能自动拉取最新文档的 MCP 插件越来越重要了。

4）用第二个 Agent 做代码审查。使用不同的 Agent 来写代码和审查代码，审查者有了全新的上下文，不会受写代码 Agent 的思路影响。实操层面，Claude Code 内置了 /code-review 技能可以直接用，如果你的代码托管在 GitHub 上，还可以配合 GitHub 自带的 Code Review 功能做双重把关。

我觉得最有价值的是第 4 条。自己检查自己的代码，跟学生自己批改考卷一样，容易放水。让另一个 Agent 来审查，相当于请了一个没有偏见的同事帮你把关。

官方还提了一个很重要的原则。当某次循环的结果不达标时，不要只修这次的问题就完事了，要把这次踩的坑编码到系统里，比如更新 Skill 或规则文件，让以后每一轮循环都不再犯同样的错。

这个思路跟我之前分享的 CLAUDE.md 维护经验是一样的，每次纠正 Claude 的错误，顺手把教训沉淀下来，长期下来质量会越来越稳。

管理 Token 用量

很多人对 Loop Engineering 最大的顾虑就是烧 token。

支持这个概念的大佬们，一个是 Claude Code 之父，一个是 OpenClaw 小龙虾之父，人家用自家模型做实验，token 成本几乎为零。但咱们普通开发者，一个月几十刀的订阅套餐哪经得起这么折腾？

好在官方也意识到了这个问题，给了一些很实用的省钱方法。

1）选对工具和模型。简单任务不需要多 Agent 或复杂循环，有些任务用更便宜更快的模型就够了，比如最近新出的 Claude Sonnet 5，相比 Claude Opus 和 Claude Fable，速度快、价格低，适合跑日常循环任务。

2）把停止条件写具体。条件越清晰，Claude 越能快速收敛到正确结果，少走弯路就是省钱。

3）先小范围试跑再全量铺开。虽然 Dynamic Workflows 动态工作流这类能力可以同时启动几百个 Agent，听起来很爽，但如果直接全量跑，这 tokens 消耗想都不敢想。建议先拿一小部分任务试试水，看看效果和消耗，确认划算了再全量执行。

4）能用脚本搞定的事情就别用 AI 推理。比如批量重命名文件、格式化 JSON、跑数据迁移这些确定性的操作，写个脚本让 Claude 直接执行就行，不用它每次都从头推理一遍，省下来的 token 可不少。

5）循环频率别设太高。你监控的东西多久变化一次，循环就设多长间隔。没必要每分钟检查一个一天才更新一次的东西。

6）用 /usage 命令看看钱花哪了。这个命令能按 Skills、Subagents、MCPs 拆解最近的用量。

除了 /usage，Claude Code 还有几个命令也能帮你盯着消耗，比如 /goal 不带参数可以看到当前任务跑了多少轮、花了多少 token，/workflows 能查看每个 Agent 的 token 用量，发现哪个 Agent 烧钱太猛还能随时停掉它。

一张表看懂 4 种循环

最后用一张表来总结这 4 种循环的递进关系，一目了然：

循环类型

你交出了什么

适合什么场景

用什么工具

手动循环

验证环节

较短的、非固定流程的任务

自定义 Skills

目标循环

停止条件

有明确完成标准的任务

/goal

定时循环

触发时机

周期性的、依赖外部系统的任务

/loop、/schedule

主动循环

整个提示词

持续性的、流程化的工作

以上全部 + Dynamic Workflows

从上到下，你管的事情越来越少，交给 AI 的越来越多。

但这不意味着你要一步跳到最底下。前面提到了，不是所有任务都需要复杂循环，先从最简单的方案开始，按需选择合适的层级。

讲了这么多概念，怎么快速上手 Loop Engineering 呢？

建议从你日常工作中找一个重复性高、你又经常需要人工盯着的任务，然后问自己：能不能把验证步骤写成 Skill？目标够不够明确？这件事是不是按固定频率发生的？

想清楚这几个问题，你就知道该用哪种循环了。先跑起来，观察 AI 在哪里卡住、在哪里过度发挥，然后持续迭代优化。

最后哔哔

这篇官方博客给了一个非常清晰的循环分类框架，算是官方对「什么是 Loop」给出的标准参考答案。之前大家聊 Loop Engineering，各有各的理解，现在 Claude Code 团队把它拆成了 4 种类型，从手动到自动、从简单到复杂，层层递进，一下子就理清楚了。

关于 Loop Engineering 更完整的概念介绍和多工具实战（包括 Claude Code、Codex、Cursor 的用法），可以看我之前写的那篇保姆级教程，已经收录到了我免费开源的 里面，两篇互补着看效果更好。

我是鱼皮，持续分享 AI 编程干货。觉得有用的话记得点赞收藏和关注~

也欢迎在评论区聊聊：你有没有尝试过让 AI 自己循环干活？你觉得 Loop Engineering 是真的有用还是炒概念？