Claude Code · Loops · 2026-06-30

从“写 Prompt”到“设计循环”

Anthropic 这篇文章的核心不是教你把提示词写长，而是教你把 Claude Code 当成可迭代执行的工程系统：明确触发条件、停止条件、验证方式和成本边界。

4 类 Loop 模式 3 个核心变量：触发 / 停止 / 验证 面向 Claude Code 自动化
Trigger Work Verify Stop? Agentic Loop
循环 = Agent 重复执行“理解 → 操作 → 检查 → 再操作”，直到满足停止条件。

一眼看懂文章主旨

Claude Code 团队把 Loop 定义为：Agent 重复工作周期，直到满足某个停止条件。不同 Loop 的差异，主要在于谁触发、何时停止、用什么 Claude Code 原语、适合什么任务。

🎯

不要一上来就复杂化

文章明确提醒：不是所有任务都需要复杂 Loop。先用最简单方案，只有在任务可验证、可重复、可边界化时才升级。

✅

Loop 的关键是“停止条件”

真正让 Agent 可靠的不是“继续干”，而是“什么时候算干完”：测试通过、分数达标、队列清空、PR 合并等。

💸

Token 成本必须被设计

循环越长，成本越容易失控。要用明确边界、小模型分流、脚本处理确定性工作，以及先小范围试运行。

4 类 Loop：从人工控制到自动化例行任务

可以把它理解成 Claude Code 自动化能力的四个台阶：先让它单轮做事，再让它围绕目标迭代，再让它定时检查，最后让它长期主动处理事件流。

01 · Turn-based

回合式循环

你发一个 prompt，Claude 读代码、修改、检查并返回。下一步仍由你手动判断和继续提示。

用户提示→Claude 执行→人工检查

适合：短任务、探索性修改、不固定流程。

02 · /goal

目标式循环

你定义“完成标准”，Claude 不再每轮等你催，而是反复尝试，直到目标满足或达到次数上限。

定义目标→多轮迭代→评估器判断

适合：有明确验收标准的任务，比如测试全部通过、Lighthouse ≥ 90。

03 · /loop & /schedule

时间式循环

按固定或动态时间间隔重复执行同一类 prompt，用来轮询外部状态或做周期性处理。

每 5 分钟→查 PR / CI→修复问题

适合：CI、PR review、部署状态、Slack 摘要等外部状态变化。

04 · Proactive

主动式循环

无需人工实时介入，由 schedule、goal、workflow、auto mode 组合成长期例行任务。

事件/计划→分流处理→自动反馈

适合：bug 报告、issue triage、依赖升级、迁移、批量维护。

文章里的核心对照表

这张表适合直接作为你以后设计 Codex / Claude Code 自动化任务的判断框架。

Loop 类型 你交出去的是什么 何时使用 对应能力 / 原语 主要风险
Turn-based回合式 检查过程的一部分 探索、决策、短任务 普通 prompt + 自定义 Skill 过度依赖人工检查，容易多轮来回
Goal-based目标式 停止条件 你很清楚“完成”长什么样 /goal 目标写得模糊，评估器无法稳定判断
Time-based时间式 触发时机 任务依赖外部状态或周期执行 /loop、/schedule 轮询太频繁，浪费 token；本地关闭就停
Proactive主动式 完整 prompt 与流程 重复、清晰、长期的工作流 schedule + goal + workflows + auto mode 权限、成本、误操作、上下文污染

这篇文章对工程团队最有价值的一句话

“把你手动检查的动作，沉淀成 Claude 可以自检的系统。”

对前端开发尤其关键：不要只让 Agent 改代码，还要让它启动页面、点击交互、看控制台、截图对比、跑性能或测试。这样 Loop 才不是“盲目重复”，而是“带验收的迭代”。

落地到前端 / AI 编程工作流

结合你的场景，可以把文章方法转成下面几类可执行模板。

1）把人工验收写成 SKILL.md

文章举的前端验证思路很实用：不能只因为代码改完就说完成，必须像人工 reviewer 一样验证 UI。

# verify-frontend-change

1. 启动 dev server，打开被修改页面
2. 直接点击按钮 / 输入框 / 切换控件
3. 截图 before / after
4. 检查浏览器 console，无新增错误或 warning
5. 必要时运行性能 trace 或核心指标检查
6. 任一步失败：修复后从第 1 步重新验证

2）把“完成标准”写成 /goal

目标式 Loop 的关键是可度量，不要写“优化一下页面”，而要写“达到某个可验证标准”。

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

更工程化的写法：
/goal all tests in test/auth pass, npm run lint exits 0,
and no unrelated files are modified, or stop after 10 turns.

3）用 /loop 处理等待型任务

例如 PR 等 review、CI 等结果、部署等完成。这类任务的输入会变，但动作重复，适合时间式循环。

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

或：
/loop check whether CI passed and address any review comments

4）用 Proactive Loop 处理固定工作流

例如每天整理 issue、定期升级依赖、监听 bug 报告、处理迁移任务。越自动化，越需要更强的权限边界和验收规则。

/schedule every hour:
check #project-feedback for bug reports.

/goal:
don't stop until every report found this run is triaged,
actioned, and responded to.

Loop 设计方法：5 步判断法

你后续给 Codex、Claude Code 或其它 Agent 写任务时，可以先过一遍这个清单。

先问：这个任务真的需要循环吗？

一次性解释、简单改代码、临时探索，用普通 prompt 就够了。不要为了“自动化”而自动化。

明确触发条件

是你手动触发、目标未达成触发、时间间隔触发，还是 GitHub / Slack / CI 事件触发？

明确停止条件

最好是确定性结果：测试通过、构建成功、分数达标、无待处理项、PR 合并、错误率恢复。

设计验证手段

能用脚本就用脚本，能量化就量化；需要模型判断时，最好让另一个评审 agent 或 evaluator 判断。

控制成本与权限

设置最大轮次、较长间隔、小范围 pilot、小模型分流、只开放必要仓库 / connector / 环境变量。

对文章的评价

这篇文章的价值不在概念新，而在把 Agentic Coding 的“自动化边界”讲清楚了。

01

它把 Agent 从聊天工具变成工程执行器

只写 prompt 时，Agent 仍是被动执行；设计 Loop 后，Agent 才开始接近“可持续执行的工程流程”。

02

它强调“验证”比“执行”更重要

没有验收条件的 Loop 只会扩大错误；可验证的 Loop 才能提高交付质量。

03

它提醒自动化不是免费的

动态 workflows 可能产生大量 agent 和 token 消耗，所以要先试小切片，再放大到全量任务。

一句话总结

Claude Code Loops 的本质，是把“人不断提醒 AI 做下一步”改造成“AI 根据明确条件自动进入下一轮”。

提示词解决“做什么”，Loop 解决“何时继续、何时停止、如何证明完成”。

真正适合放进 Loop 的任务，通常满足三个条件：重复性强、目标清晰、结果可验证。否则，普通 prompt 或人工协作更安全。