“我不再往 Claude 里敲提示词了。跑的是那个循环，是由循环决定下一步该做什么，它自己去提示 Claude。我的工作变成了写这些循环。”
这话是 Boris Cherny 公开说的，他是 Claude Code 的负责人（相关内容出现在 The New Stack 和 Addy Osmani 的文章里）。
当大多数人还在打磨提示词来提高准确率的时候，这个造工具的人，自己已经不再当那个“下指令的人”了。
仔细想想，只要“人的回合”——坐在屏幕前，等 AI 回复，检查，再下达指令——还在流程里，速度的上限就被你双手的速度锁死了。
循环工程 就是把人的那个回合从结构里拿掉的想法。Boris 是彻底这么干的；他说自己在 2024 年 11 月就把 IDE 删了，之后再也没打开过。他声称过去一个月里他对 Claude Code 的几乎所有贡献，都是 Claude Code 自己写的（据说超过了 200 个 PR）。
这个工具的创造者自己不写代码，而是退到了“观察循环是否正常运转”的位子上。今天，我会从技术规格层面来拆解这件事，不只是谈感觉。我自己也在往循环那边靠，而且我越靠过去，越觉得自己的双手变自由了。
相关文章：Vibe Coding 入门：不会编程的人也能用 Claude 制作应用的 6 个步骤。周末自造的时代来了
https://note.com/nobel/n/n8192ec07d689
循环工程意味着角色的转变
换句话说，你的位置变了。以前，人坐在一个来回交互的中间：人下达指令，AI 回答，人检查并纠正。在循环设计里，人负责设计这个循环运转的机制，而结果的试错和验证则交给了 AI 这边。你只需要等它完成时收到一条通知。
Google 的 Addy Osmani 在题为 Loop Engineering 的文章里也写了同样的观点，将其描述为“用自动打出提示词的机制，来替代那个手动打提示词的人”。关键的着力点已经从“能写出好提示词的能力”，转向了“如何设计一个让 AI 为你写提示词的系统”。这就是核心。
不过，Addy 本人也警告说：“这还在早期阶段，我多少有点怀疑。你真的要小心 token 成本。”我们会在后半部分回到这个陷阱。
/loop 的技术规格
Claude Code 内置了一个叫 /loop 的技能（从 v2.1.72 版本开始）。这是进入循环工程最简单的入口。因为网上的解释经常有错，我会根据官方的定时执行文档来聚焦关键点。
它的行为取决于你传给它的内容：
- 同时指定间隔和提示词：
/loop 5m check if the deployment is finished and let me know会按固定间隔运行。 - 只指定提示词：
/loop check if the CI passed and respond to review comments。Claude 会在 1 分钟到 1 小时之间自己决定间隔（自定节奏）。 - 什么都不传：
/loop。会执行内置的维护提示词（继续未完成的工作、处理 PR、简单清理）或者你自己放的loop.md文件。
间隔可以放在开头，比如 30m，也可以放在结尾，比如 every 2 hours。单位是 s / m / h / d。你也可以传其他命令，比如 /loop 20m /review-pr 1234，这样每次都会运行保存好的技能。要停止的话，在等待时按 Esc 键（通过自然语言请求创建的任务不能用 Esc 停止，必须要求删除）。在自定节奏模式下，如果 Claude 判断任务确实完成了，它就会结束，不会安排下一次运行。
自定节奏模式有一个微妙的好处：它会自动调整，在构建快完成时等短一点，没什么动静时就等长一点。有时会用一种叫“Monitor”的机制来流式传输后台输出，而不是轮询，这通常比按固定间隔发一次提示词更便宜。
我来纠正一下在原始文章中发现的一个常见误解。有时会写成任务在“创建 3 天后自动删除”，但准确的说法是，重复任务在创建 7 天后过期（它会再跑最后一次然后消失）。另外，/loop 是会话级别的，开始一个新对话就会消失。如果把它关掉，只要还没过期，可以用 --resume 恢复。
有三种调度方法，按用例选择：
- Cloud (Routines)：在 Anthropic 那端运行。即使你的电脑合上了也能继续跑。最小间隔是 1 小时。
- Desktop Scheduled Tasks：在你的电脑上运行，可以触及本地文件。
- /loop：仅在会话打开期间有效。最小 1 分钟，适合在会话中进行轮询。
分工是这样的：需要无人值守长期运行的就用 Routines 或 GitHub Actions，会话期间的监控就用 /loop。
循环适合处理的标准任务
你日常工作中那些“检查一下、修一点”的重复任务，基本上都适合用循环。这里有三种常见模式：
- Bug 巡逻：定期检测问题或测试失败，读取原因，修复它，运行测试，然后创建一个 PR。
- 持续审查：监控代码变更，持续指出需要关注的区域。人只决定是否采纳建议。
- 文档同步：检测源码变更，让 README 或规格说明保持最新。
这三者的共同点是，目标可以清晰判断，比如“测试通过”或“PR 已创建”。反过来说，标准模糊的任务就不适合用循环。如果停下来的点不明确，它就会一直跑下去，不停消耗 token。对于你的第一个任务，选择那种成功或失败一目了然的会更安全。
用“状态文件”防止失控和忘事
对循环有两种担心：重复犯同样的错误，以及无休止地消耗 token。
这时候，在项目里设计一个单一的状态文件就很有效。无论是 STATE.md 还是 todo.md，AI 在每次循环中都会读写当前目标 / 已完成项 / 下一步 / 卡点。即使会话中断了，AI 也不会搞不清“自己在哪里、目标是什么”。
这不只是一个随意实践；Anthropic 自己在长效 Agent 的有效框架（2024 年 11 月）里也得出了几乎相同的结论。他们的配置使用了两个角色：一个初始化 Agent 来设置环境，一个编码 Agent 来在每次会话中推进一个功能。进度通过 git 提交和一个 claude-progress.txt 文件在会话之间传递。对于长时间的任务，单纯的摘要压缩是不够的。策略是，一次性写出到结构化文件，然后重建上下文。
在我自己的操作中，我使用 tasks/state.md 作为共享状态的中心，不管是头脑风暴的一方还是实现的一方，在行动之前都会先读它。这和那篇论文说的是一样的：“别信上下文，信文件。”虽然简单，但没它的话，循环在第二圈就会迷路。
Ralph 方法以及区分创建者与检查者
有一个循环的极端版本叫“Ralph”方法。由 Geoffrey Huntley 推广开来，原始来源只是一个简单的 bash 循环：
通过无休止地喂同一个提示词，并利用一个包含计划的 Markdown 文件作为磁盘上的共享状态，AI 每次都会读它，然后自己决定“下一步做什么”。这看起来有点鲁莽，但因为有了状态文件，每跑一圈它都会往前推进。Claude Code 也有一个官方的 ralph-loop 插件，它会持续重新提交同一个提示词，直到满足完成条件（完成承诺）。有一个约束是，声明完成只能在实际达成时才能发出。
然而，如果所有事情都交给一个 AI，它对自己写的代码会说“没问题”。这时候，把负责创建的 AI（Maker）和负责检查的 AI（Checker）分开就很有效。在我自己的操作中，我把实现和验证分给不同的 Agent，并且不给验证的那一边实现意图——我只展示需求，让它独立评估。我是在吃过亏之后才学到的：在同一个会话里做自我审查，必然会放水。
把一个具有“不同视角的仅审查 Agent”整合进循环——设计这种多层级的检查，是人类应该保留的工作之一。
分三个阶段设计自主权
一次性全盘托付容易出事故。把参与程度分成不同层次会更安全：
- L1（手动）：人类输入提示词并逐一检查。传统方式。
- L2（半自主循环）：遵循状态文件，用
/loop监视一组特定任务直到完成。 - L3（常驻）：通过 Routines 或 GitHub Actions 持续运行，无需人工干预。
从 L2 开始比较现实。用 /loop 运行一个任务直到完成，观察它的行为。看到可靠性的范围之后，再升到 L3。头几次，我是在副屏上看日志，观察“它在什么地方做出了错误判断”。
陷阱（先了解这些）
因为我只说了好的一面，这里提三个可能会卡住你的地方：
- Token 成本：循环跑得越久消耗越多。这就是 Addy 强调的点；间隔设得太短的话，一晚上可能花掉不少钱。自定节奏比固定间隔好，因为它会在该等的时候等着，减少浪费。
- 不可逆操作：内置的维护提示词只会在“对话里已经允许的范围内”采取推送或删除等不可逆操作。自己写提示词时，最好为破坏性操作定义好边界。
- 7 天后消失：重复的
/loop任务在创建 7 天后过期。如果想让它跑更久，就转到 Routines 或 Desktop 任务。
给中级用户的提示
/loop和/goal不同。/loop是按间隔运行。如果你想在满足条件之前每个回合都继续，用/goal。如果你想在事件发生时立即响应，通过 Channels 使用 push。- 放置一个
loop.md（.claude/loop.md或~/.claude/loop.md）可以让你用自己的内容替换裸/loop的默认提示词。对于编写日常任务很有用，比如“如果 release 分支的 CI 是红色，就修复它”。 - 每个会话最多 50 个定时任务。可以用
CronList查看列表，用CronDelete按 ID 删除。
总结
以前，我坐在屏幕前的时间就是进步的上限。现在，一个在我睡觉时读取状态文件的循环，逐个功能地推进进度，而我的早晨从检查那个进度开始。
在改进内容（提示词准确度）之前，先设计它的运作方式（循环分离、状态管理、验证）。着力点已经转移到了那里——这就是 Boris、Addy 和 Anthropic 框架故事的共同点。我觉得这不是什么深奥的理论，而是简单设计的稳步积累，比如在启动循环之前先决定好什么时候停下来。
在 X 上无法分享的有用信息正在 LINE OpenChat 中分享。如果你对使用 Claude Code/Codex 或利用 AI 进行 X 运营感兴趣，欢迎加入。
