别再只写 Prompt 了，开始设计 Loop

最近圈子里很流行讨论“设计 loop”而不是单纯写 prompt 来指挥 coding agent。但如果你去 X 上搜一下“loop 到底是什么”，会发现说法五花八门。Claude Code 团队给出的定义其实很干脆：

。

文章从几个维度对 loop 做了分类：触发方式、终止条件、用到了 Claude Code 的哪个原语，以及什么类型的任务最适合用哪种 loop。核心建议是——不是所有任务都需要复杂的 loop，先从最简单的方案开始，按需选用这些模式。

01 按轮次触发

• 触发方式：
  用户输入一次 prompt

• 终止条件：
  Claude 自己判断任务完成，或者需要更多信息

• 适用场景：
  比较短、不属于常规流程或排期任务的工作

• 管理方式：
  写具体的 prompt，用 skills 改进验证环节，从而减少来回轮次

每次你发一条 prompt，就手动启动了一轮 loop：Claude 收集上下文、执行动作、检查自己的工作（如果需要就重复）、再给出结果。这个过程就叫做 agentic loop。

举例来说：让 Claude 做一个类似按钮的功能，它会读代码、改代码、跑测试，然后把它“认为”完成的结果交给你，你手动核实、再决定下一步 prompt。

你可以把验证这一步写进 SKILL.md，让 Claude 能更端到端地核查自己的工作，而不需要你介入。可以在 skill 里包含工具或指令，让 Claude 能自己看、自己交互、自己核实结果。检查项越量化，Claude 自我验证的能力就越强。

比如在 SKILL.md 里可以这样写（核心思路）：

---  
name: verify-frontend-change  
description: Verify any UI change end-to-end before declaring it done.  
---  
# Verifying frontend changes  
Never 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.

02 目标导向

• 触发方式：
  一次性手动 prompt

• 终止条件：
  达成目标，或者达到最大轮次上限

• 适用场景：
  有明确、可验证成功标准的任务

• 管理方式：
  设置具体的完成标准和明确的轮次上限，比如“跑到 5 次后停止”

对更复杂的任务，单轮对话往往不够，需要 Claude 能自己迭代。做法是明确定义“什么叫成功”，让 Claude 自己反复尝试，直到满足条件，或提前触及轮次上限。由你来定义判断标准，Claude 不需要自己判断“是否足够好”，也不会提前结束。每一轮它会检查是否达到你定义的条件，没达到就继续，直到满足为止。

正因如此，

（比如测试全部通过，或者达到某个分数）效果最好。

举例：

/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

03 按时间触发

• 触发方式：
  设定的时间间隔

• 终止条件：
  你手动取消，或工作本身完成（比如 PR 合并、队列清空）

• 适用场景：
  周期性工作，或需要对接外部环境/系统的工作

• 管理方式：
  设置合适的时间间隔，或者基于事件触发而不是纯粹按时间

有些 agentic 工作本质上是周期性的：任务内容不变，但输入每次都在变化。比如每天早上总结 Slack 消息。也有些工作依赖外部状态变化，只需要在状态变化时检查一下，比如一个可能会因为 CI 通过而收到新 review 意见的 PR。

对这类场景，可以用 /loop 命令，让 Claude 在同一个 prompt 上反复运行：

/loop 5m check my PR, address review comments, and fix failing CI

/loop 是在你本机运行的，所以关掉终端它就停了。如果想把这个 loop 挪到云端持续运行，可以用 /schedule 创建一个例行任务。

04 主动型

• 触发方式：
  事件或排期触发，全程无需人工实时介入

• 终止条件：
  每个具体任务在达成目标后自动退出，整个例行程序会一直运行，直到你手动关闭

• 适用场景：
  定义明确、反复出现的一类工作，比如 bug 报告、issue 分诊、依赖升级、迁移工作等

• 管理方式：
  把例行任务路由给更小更快的模型，只在需要判断力的地方用最强模型

05 组合起来

上面提到的几种 loop 类型，再加上 Claude Code 的其他能力，比如

和 ，可以组合成能长期运行的复杂 loop。

比如要处理用户反馈，你可以这样组合：

1. /schedule（研究预览版）：定期检查是否有新的反馈
2. /goal：定义“完成”的标准，用 skills 记录如何验证

3. Dynamic workflows
   ：编排多个 agent 分诊每条反馈、修复问题、审查修复结果

4. Auto mode
   ：让整个流程自动运行，不需要人工授权确认

组合起来，一条 prompt 大概是这样：

/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. When fixing a bug, use a workflow to explore three solutions in parallel worktrees and ha ve a judge adversarially review them.

06 代码质量

loop 输出质量的好坏，取决于你围绕它搭建的整个系统。文章给出了几条建议：

• 保持代码库本身干净：
  Claude 会遵循代码库里已有的模式和约定

• 给 Claude 一种验证自己工作的方式：
  用 skills 把“什么叫好”这件事写清楚

• 让文档容易被查阅到：
  框架和库的文档要保持最新的最佳实践

• 用第二个 agent 做代码审查：
  一个带着“新鲜”上下文、不受主 agent 推理过程影响的 reviewer 更客观。可以用内置的 /code-review skill，或者 GitHub 上的 Code Review 功能

当某一次结果没达到标准时，不要只是修补这一次的问题，尽量把它沉淀进系统里，让未来所有迭代都能受益。

07 token 消耗

loop 应该有清晰的边界，具体建议：

• 选对原语和模型：
  简单任务不需要多个 agent 或复杂 loop，也不需要用最贵的模型

• 明确定义成功和终止标准：
  讲清楚“完成”是什么样子，让 Claude 能尽早收敛（但也别太早）

• 大规模跑之前先小范围试点：
  dynamic workflows 可能一次派生上百个 agent，先在一小部分工作上评估用量

• 确定性工作用脚本解决：
  比如一个填表脚本，比每次都让模型重新推导代码更省钱

• 不要跑得比实际需要更频繁：
  检查间隔应该匹配你关注对象变化的频率

• 定期查看用量：
  /usage 命令可以查看近期各 skill、subagent、MCP 的使用和 token 消耗；/goal 不带参数可查看当前轮次和 token 用量；/workflows 可查看每个 agent 的 token 用量，随时可以终止某个 agent

08 入门总结

▲ 图：不同 loop 类型的适用场景

想要开始用 loop，可以先看看你手头已有的工作，找一个你自己是瓶颈的任务，问自己：能不能把验证这一步交出去？目标是不是足够清晰？这个工作是不是可以排期？一旦有了想法，先跑起来，观察它在哪里卡住或者过度发挥，然后大胆迭代。

更多信息可以查看 Claude Code 文档中关于“并行运行 agent”以及 loop、schedule、goal、dynamic workflows 相关的页面。