Anthropic 的工程师每月薪资高达 8 万美元。如今，他们每天合并的代码量是去年的 8 倍。这并不是因为模型变得更聪明了，而是因为他们不再通过提示词（prompting）来驱动 Claude，转而开始构建能够代其进行提示的系统。
Anthropic 旗下 Claude Code 的负责人 Brian Cherny 表示：“我不再向 Claude 发送提示词了。我运行着一些循环（loops），由它们来提示 Claude 并决定要做什么。我的工作就是编写这些循环。”
大多数开发者读到这里时，并不理解这在实践中意味着什么。读完这篇文章，你不仅会明白其中的含义，还将掌握本周末构建第一个循环所需的一切。
什么是循环（Loop）
提示词是一条单一的指令。而循环是一个 AI 会持续努力实现的目标，直到达成目的为止。
两者的区别在于谁在掌控方向。使用提示词时，你需要手动推动 Claude 完成每一个步骤；而使用循环时，你只需定义一次目标，系统就会自动运行整个周期——寻找任务、执行任务、检查结果并决定下一步做什么。这一切都无需你亲自操作。
1提示词 | 你输入，Claude 回答，你再次输入2循环 | 系统寻找任务，Claude 执行，3 | 系统检查结果，重复直到完成
每一个真正的循环都包含五个阶段：
1发现（Discover） | 找出需要做的事情2规划（Plan） | 决定如何去做3执行（Execute） | 完成工作4验证（Verify） | 对照目标进行检查5迭代（Iterate） | 未完成？将结果反馈回去并再次循环
其中三个阶段承担了所有实际工作。
验证（Verify）是核心。 如果没有对结果进行真正的检查，你就没有循环，而只是一个 Agent 在不断地自我认同。这种检查必须是客观的：一个通过或失败的测试、一个能编译或不能编译的构建、一个返回零或非零状态的 linter。不要让第二个 Agent 去“审查”第一个，两个乐观主义者达成一致并不等于验证。
状态（State）是循环能够学习的原因。 在每一轮循环中，AI 必须记住它已经尝试过什么，否则它会永远重复同样的错误。一个真正的循环会在对话之外保留记录——什么已完成、什么失败了、下一步是什么。Agent 在会话之间会遗忘，但文件不会。
停止条件（Stop condition）是保持系统理智的关键。 没有出口的循环会一直运行，直到成功、崩溃或耗尽你的预算。每一个严肃的循环都有两种停止方式：成功，以及硬性限制。没有这些，你构建的机器就会在静默中消耗你的资金。
构建前的 4 条件测试
只有当以下四个条件全部满足时，循环才值得投入成本。如果缺少其中任何一个，请将其保留为手动提示词。
1条件 1 | 任务至少每周重复一次2 | 频率低于每周一次——设置成本永远无法收回34条件 2 | 有自动拒绝错误输出的机制5 | 例如测试、构建、linter、类型检查6 | 如果没有自动门控——你又得回到审查每一个差异的旧路78条件 3 | Agent 可以端到端地完成工作9 | 不会在任务中途把一半工作丢回给你1011条件 4 | “完成”是客观的，而非主观判断12 | 如果质量取决于品味，那么人类依然胜出
适合作为首个循环的任务：
1CI 失败分类 | 每晚运行，对失败进行分类，起草修复方案2依赖项升级 | 每周运行，扫描更新，提交 PR3Lint 和修复流程 | 在每个 PR 上运行，自动应用样式修复4Issue 转 PR 草稿 | 在测试覆盖率高的代码库上运行
不适合作为首个循环的任务——请保持人工介入：
1架构重构 | 需要主观判断，循环会发生偏离2身份验证或支付代码 | 不可逆的错误代价太高3生产环境部署 | 需要人工审批门控4模糊的产品工作 | “完成”的标准不客观
五个构建模块
每一个有效的循环都是由五个部分组装而成的。Claude Code 提供了全部五个模块。
1 - 自动化（心跳）
这使得循环成为真正的循环，而不是你执行的一次性任务。触发器按计划或事件启动，将任务交给 Claude，并在无需你反复检查的情况下带回结果。
1/loop | 按节奏重复执行提示词2/goal | 持续运行直到你编写的条件达成3hooks | 在 Agent 生命周期的特定点触发命令4cron | 通过 GitHub Actions 在你合上笔记本后运行
最重要的是 /goal。一个独立的小型模型会检查条件是否满足——这样编写代码的 Agent 就不会是评分的那一个。
1/loop 30m /goal "test/auth 中的所有测试通过且 lint 检查通过。"2扫描 src/auth 中的失败项，起草修复方案，并在目标达成时提交 PR。
2 - 技能（一次性编写项目知识）
技能（skill）是你不再需要在每次会话中重复解释项目背景的方式。一个 SKILL.md 文件包含了循环在每次运行时读取的指令、规范和规则。
如果没有技能，循环在每个周期都会从零开始重新推导你的整个项目。有了技能，意图就会产生复利——规范、构建步骤、之前出错的地方——写一次，读万次。
1skills/2 ci-triage.md - 分类规则、修复模式、升级标准3 frontend.md - Tailwind、Next.js、SEO、无障碍规则4 security.md - 身份验证模式、输入验证、禁止触碰列表5 deps.md - 更新规则、兼容性检查、回滚模式
自动化程序通过名称调用技能。这种循环作业保持了可维护性，而不是在无人更新的计划表中腐烂。
3 - 子 Agent（将制造者与检查者分开）
这是任何循环中最有用的结构性设计。将编写代码的 Agent 与检查代码的 Agent 分开。
编写代码的模型在评估自己的工作时往往过于宽容。第二个带有不同指令（有时是更强大的模型）的 Agent 可以捕捉到第一个 Agent 自我说服忽略的问题。
1制造者 Agent | 快速、廉价的模型——负责探索、实现、起草2检查者 Agent | 强大的模型、高投入——负责审查、验证、拒绝
1.claude/agents/2 explorer.md | 只读、快速模型，找出需要做的事情3 implementer.md | 编写修复代码，运行测试4 reviewer.md | 安全审计、代码质量、客观门控
一个模型，三个专家。当你不盯着看时，循环依然在运行，而验证者是你能够真正放手的唯一理由。
4 - 连接器（使其能够行动，而非仅仅建议）
这区分了“告诉你修复方案”的循环和“提交 PR、关联工单并在 CI 通过后通知 Slack”的循环。
1GitHub | 读取仓库、创建分支、提交 PR、响应 Webhook2Linear | 更新工单、关联 PR、在验证通过后关闭任务3Slack | 发布分类结果、在需要升级处理时通知人类4Sentry | 调查实时警报、为高频问题起草修复方案
没有连接器，循环只能描述它会做什么；有了连接器，它就能直接完成工作。
5 - 状态文件（Agent 会遗忘，但文件不会）
这一部分听起来简单到不值一提，却是每一个有效循环的脊梁。这是一个位于对话之外的 Markdown 文件，记录了已完成的任务、失败的任务以及下一步计划。
1# 循环状态 - ci-triage23## 上次运行42026-06-09 03:30 UTC - 7 个失败项已分类，3 个修复方案已起草，4 个已升级56## 进行中7- claude/fix-auth-token-refresh - 本地测试通过，等待 CI89## 今日已完成10- claude/bump-axios-1.7.4 - 已合并，CI 通过1112## 已升级给人工处理13- src/billing/refund.ts - 测试在 3 个方面失败，根本原因不明1415## 经验教训16- 2026-06-08: PowerShell 在 Windows runner 上遇到 TLS 问题。改用 bash。17- 2026-06-07: tests/e2e/checkout 需要 Stripe webhook 密钥。如果缺失则跳过。
明天的运行会读取此文件并继续。没有它，每次运行都将从零开始。
真正的循环是什么样的
CI 失败分类是最好的首个循环之一，因为验证是自动化的，且输出错误的风险很低。
1触发器 | 每晚 3 点或在 CI 失败事件时2技能 | ci-triage.md3状态读取 | STATE.md - 昨天失败了什么，修复了什么
循环运行过程：
1步骤 1 | 通过连接器从 GitHub 读取 CI 失败信息2步骤 2 | 对每一项进行分类：环境 / 偶发 / Bug / 依赖项 / 基础设施3步骤 3 | 对于每一项可修复的失败 - 打开工作树，发送实现者 Agent4步骤 4 | 审查者 Agent 根据测试和安全规则检查修复方案5步骤 5 | 门控通过 - 提交 PR 并关联 Linear 工单6步骤 6 | 门控失败 - 升级到人工分类收件箱7步骤 7 | 更新 STATE.md8步骤 8 | 向 Slack 发布过夜总结
早上醒来，你会看到一条 Slack 消息，一个只有棘手问题的分类收件箱，以及一组已经通过自动审查的 PR。你甚至不需要手动提示任何一个步骤。
跨业务产生复利的循环
最强大的版本不是单个循环，而是多个循环向共享的工件系统写入数据，从而相互学习。
在 SuperDesign，他们的循环涵盖了支持、SEO、产品增长和广告。每个循环都有自己的触发器和工作流，但它们都写入同一个共享信号库。
支持循环注意到有 5 个用户询问如何导出数据，于是创建了一个信号：
1kind: signal2title: 导出功能太难找了3frequency: 54category: friction5tags: [反馈, 定价, 转化]
SEO 循环注意到一个页面流量很大但转化率很低，也创建了一个信号。产品增长循环同时读取这两个信号并结合分析数据，发现导出功能的摩擦力比原始数据暗示的要大得多——因为现在有两个独立的来源证实了同一个问题。广告循环发现了关键词缺口，并将其直接反馈给 SEO 循环。
1支持循环 | 发现摩擦点，写入信号2SEO 循环 | 发现内容缺口，写入信号3产品循环 | 读取两个信号，确定优先级4广告循环 | 发现关键词缺口，反馈给 SEO 循环
这些循环都不是孤立的自动化，它们基于业务学习到的共享知识库运行。每个循环都让其他循环变得更聪明。这就是复利。
没人警告过你的失败陷阱
Ralph Wiggum 循环。 一个本应在完成时发出信号的 Agent，却在任务未完成时就提前发出信号。循环在工作完成一半时退出，却在持续运行并计费，同时产出为零。修复方案：一个能够客观判定工作失败的硬门控，而不是软性的“看起来不错”。
长会话中的目标偏离。 随着上下文在第 47 轮自动总结，约束条件消失了。修复方案：一个常驻的 AGENTS.md，Agent 在每次运行开始时都会重新阅读它。
理解债务。 循环交付你未编写的代码速度越快，现有代码与你理解的代码之间的差距就越大。真正昂贵的不是 Token 账单，而是某天你需要调试一个团队中无人阅读过的系统。修复方案：阅读循环打开的每一个差异（diff）。
认知投降。 停止形成观点并接受循环返回的任何内容的冲动。当你带着判断力去做时，设计循环是治愈方法；而当你为了逃避思考而做时，它就是催化剂。同样的动作，结果截然相反。
复利的 Token 成本。 每次循环迭代都会重新读取完整的上下文，且堆栈在每一轮都会增长。追踪每次已接受变更的成本。如果接受率低于 50%，那么循环的成本就超过了它的节省。
真正有效的构建顺序
每一个在生产环境中存活下来的循环构建者都遵循同样的方法：
1步骤 1 | 首先确保一次手动运行是可靠的2步骤 2 | 将其转化为技能 - 将指令保存在 SKILL.md 中3步骤 3 | 将技能包装在循环中 - 添加门控和停止条件4步骤 4 | 然后将其放入计划任务中
在没有手动验证可靠性的情况下就进行定时调度，正是循环在你睡觉时失控的原因。先证明一次，加固它，然后再自动化。
真正重要的指标不是消耗的 Token 或尝试的任务数量，而是每次已接受变更的成本。如果循环给你十个结果，你拒绝了六个，那么你实际上是在做它本应为你节省的审查工作。
已经发生的转变
在 2024 年，杠杆点在于提示词。更好的提示词，更好的输出，更好的开发者。而在 2026 年，杠杆点高了一层——在于那个决定 Claude 做什么、何时做、使用什么门控以及在运行之间保留什么状态的系统。
Anthropic 的工程师每天合并的代码量是原来的 8 倍，并不是因为他们找到了向 Claude 提问的更好方式，而是因为他们停止了提问，转而构建了代其向 Claude 提问的系统——持续地、彻夜地、在他们睡觉时。
循环并没有让工作变得更容易，它改变了工作发生的地方。从输入提示词转变为设计输入提示词的系统。从握住工具转变为建造工厂。
大多数开发者会继续手动输入提示词，并纳闷为什么差距在不断扩大。而少数人会花一个周末构建他们的第一个循环——一个自动化、一个技能、一个状态文件、一个门控——然后就再也回不去了。
