提示词已死Loop称王？入职揭秘炒概念骗token

近期，Claude Code 官方团队发布了一篇名为《Getting started with loops》的博客，系统性地阐述了团队内部对「循环」概念的界定与分类。

这篇博客干货十足，作者是 Claude Code 核心团队成员，分享的均为一线实战经验。本文将结合自身使用体验，进行中文深度解读。

什么是循环？

当前 AI 编程领域，「设计循环」几乎成为绕不开的话题，但每个人对它的理解并不完全一致。

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

仔细想想，日常使用 AI 编程的大部分场景，其实都能套进这个定义里。

让 AI 修复一个 Bug，直到所有测试通过，这是循环。
让 AI 每隔一小时检查 PR 是否有新评论需要处理，这也是循环。

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

下面逐一展开。

循环的四种类型

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 盯着就好。

定时循环什么时候停呢？分为两种情况：一是你主动取消它，二是工作本身完成了，比如 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 每小时检查一次 #project-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 烧钱太猛还能随时停掉它。

一张表看懂四种循环

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

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

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

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

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

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

最后来个总结

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

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：提示词已死Loop称王？入职揭秘炒概念骗token要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题