本文永久链接 – https://tonybai.com/2026/07/07/how-to-create-loops-with-claude-code
大家好，我是Tony Bai。
在上两篇中，我们先后探讨了 Andrej Karpathy 关于长程运行的 Agent 的核心理念《LOOPS.md》，以及 20 个极具启发性的“LOOP 设计模式”。
这些前沿理论无一不在昭示着一个事实：AI 开发的下半场，是属于“循环（Loops）”的。
然而，理论再性感，无法落地也只是空中楼阁。基于 Anthropic 推出命令行工具 Claude Code，以及各大厂商纷纷跟进 Agentic 开发者工具，我们有了可以直接上手构建“Loop”的利器。
今天翻译的这篇实战指南，同样来自技术专家 Rahul (@sairahul1)。他将手把手教你如何利用极简的“4文件系统”和权限控制阶梯，在 Claude Code（或任何主流 LLM 开发环境）中无缝搭建一套“睡后运行”的自动化循环系统。
无论你是想做每日代码库自动审计、CI/CD 错误自动排查，还是想让 AI 自动跟踪你的项目进度，这套保姆级的实战模板都能让你直接复制粘贴、即刻上线。
以下为译文全文：
目前，绝大多数人使用 Claude 的工作流，依然是“一锤子买卖（One-shot）”。
你写一段 Prompt -> Claude 给出回复 -> 会话结束。
明天，一切又得从零开始。
对于一次性的简单任务，这种方式完全没问题。
但对于高频重复的工作——比如每日项目审查、CI/CD 故障排查、项目进度监控——这就称不上是一个“工作流”了。这充其量只是在传统的体力劳动上，撒了一点 AI 调味料。
更好的抽象设计，应该是构建一个“循环（Loop）”。
建议收藏本文，你绝对用得上。
循环绝对不等于“重复地去问 Claude 相同的问题”。
循环，是围绕大模型构建的一套可复用的工作流结构。
它明确定义了：
模型依然负责底层的推理（Reasoning），但循环为它提供了运转的框架结构（Operating Structure）。
这种转变至关重要。因为 Claude 的 Session（会话）是临时性的。没有循环，每一次运行都是从零开始；而有了循环，Claude 能够读取上一次发生的事，并在上一次停下的地方完美接棒。
一个缺乏结构的循环，不过是一个被运行了两次的普通 Prompt 而已。
要让一个循环真正跑起来，必须具备以下 6 个核心拼图：
PROGRESS.md、记录当前的 Blockers（阻碍项）、为下一次运行留下指南。在整个闭环中，每一步都生死攸关：
你根本不需要配置复杂的数据库和后台系统，只需要在你的项目目录下新建 4 个 Markdown 文件：
my-loop/
├── TASK.md
├── LOOP_INSTRUCTIONS.md
├── PROGRESS.md
└── outputs/
└── daily-review.md
就是这么简单。
Claude 在每次运行开始前，会读取这些文件；在结束运行前，会更新这些文件。下一次运行启动时，它便能完美实现断点续传。状态存在于聊天窗口之外，这就是循环与普通 Prompt 调优的本质区别。
这个文件告诉 Claude 这个循环是干嘛的。
保持高层次（High-level）的宏观描述，不要把具体的操作细节写在这里，那是 LOOP_INSTRUCTIONS.md 的工作。
你可以直接复制这个模板：
# 每日项目审查循环
## 目标（Goal）
审查当前项目文件夹，总结变更内容，识别当前的阻碍项（Blockers），并输出一份简短的每日审查报告。
## 预期输出（Expected Output）
每次运行应当产出或更新：
- `outputs/daily-review.md`
- `PROGRESS.md`
## 权限与范围（Scope）
Claude 允许检查当前工作区的文件并写入：
- 禁止删除或重命名文件
- 禁止直接发送消息或开 Ticket
请特别注意最后一节。任何循环的第一版，都必须有明确的“禁止行为（Do Not）”规则。这不是因为不信任 Claude，而是合格工程师的职业素养。
这是整个系统中最灵魂的文件。
没有它，每一次运行都是盲目的。有了它，Claude 才能拥有跨越会话的记忆。
# Loop 运行进度表
## 当前状态（Current State）
- 状态：运行中（Active）
- 核心任务：每日项目审查
- 当前聚焦：[写下目前最重要的工作]
- 上次更新时间：[日期]
## 上次运行记录（Last Run）
- 日期：
- 摘要：
- 审查过的文件：
- 产出的结果：
## 未解决事项（Open Items）
-
## 阻碍项（Blockers）
-
## 需人工介入（Needs Human Review）
-
## 下次运行聚焦（Next Run Should）
-
## 已做出的决策（Decisions Made）
-
两条保持 PROGRESS.md 高效运转的铁律：
PROGRESS.md 中。outputs/history/ 文件夹中。永远膨胀的状态文件等同于无用。请把 PROGRESS.md 当作控制面板（Control Panel）来维护，而不是当作无休止的历史档案馆。
这个文件精细控制着 Claude 的行为：该读什么、该写什么、什么东西绝对不能碰，以及在停止前如何进行质量自我验证。
实测表现最稳定的一套模板：
你当前正在执行【每日项目审查循环】。
## 启动准备（Before You Start）
1. 读取 `TASK.md`
2. 读取 `PROGRESS.md`
3. 检查项目当前的主文件夹
4. 识别出发生了哪些变更、哪些部分还没写完、哪些地方需要人工介入
## 标准操作流程（What You Should Do）
撰写一份简短的每日审查报告，并写入 `outputs/daily-review.md`，内容包含：
- 当前整体状态总结
- 审查过的文件列表
- 产生的实质性变更
- 当前遇到的阻碍项或未解决的疑问
- 建议的下一步动作
写完报告后，立即更新 `PROGRESS.md` 中的以下项：
- 本次运行日期
- 本次工作摘要
- 检查过的文件
- 下次运行的建议焦点
- 是否需要人工介入审查
## 安全与红线规则（Safety Rules）
- 严禁删除任何文件
- 严禁重命名或移动任何文件
- 严禁擅自修改任何源代码文件
在结束本次运行前，必须确认以下事项：
- `outputs/daily-review.md` 已生成，且包含所有必备章节
- `PROGRESS.md` 已被成功更新
- 没有任何安全红线以外的文件被擅自修改过
## 异常失败策略（Failure Policy）
如果自我验证（Verification）失败：
1. 报告中缺失部分章节 -> 尝试修复一次。
2. PROGRESS.md 未更新 -> 尝试更新一次。
3. 发现有红线外的源码文件被修改 -> 立即无条件终止运行（Stop Immediately）。
4. 相同的校验连续失败两次 -> 停止运行，将状态标记为“需要人工审查”。
注意底部的异常失败策略（Failure Policy）。大多数人设计的 Agent 没有任何失败退路，一旦出错，AI 只能当场胡乱发挥。优秀的循环，必须明确定义好失败后的退出机制。
在把循环放进定时任务之前，先手动跑通。
在工作区目录打开 Claude Code（或 Claude 桌面客户端），输入以下手动提示词：
请运行当前工作区的每日项目审查循环。
严格遵循 `LOOP_INSTRUCTIONS.md` 的要求。
在采取任何行动前，请先完整阅读：
- `TASK.md`
- `PROGRESS.md`
- `LOOP_INSTRUCTIONS.md`
接着检查当前工作区，将每日审查结果写入 `outputs/daily-review.md`，并在停止运行前更新 `PROGRESS.md`。最后执行自我校验清单，并向我汇报发生了哪些变更。
除了 `outputs/daily-review.md` 和 `PROGRESS.md`，严禁修改任何其他文件。
检查产出的两个文件是否完美。如果格式和内容都正确，说明循环逻辑走通了。
接下来，手动模拟 3-5 次项目变更：
在目录里增加一个临时笔记、在 PROGRESS.md 里手动写一个阻碍项、改动一点代码。然后重新运行上面的指令，观察 Claude 能否完美读取上一次留下的状态，做到“断点续传”。
这是整套 Agent 运行机制中，几乎所有人都在悄悄隐瞒的失败模式：
Claude 跑完了循环，自信满满地向你汇报它已经全部搞定了，接着更新了状态文件，然后利落地停止了运行。
你打开目录，一切看起来似乎都毫无破绽。
然而事实却是：最终生成的报告里，其实漏掉了几个必不可少的硬性章节；或者 PROGRESS.md 只是被敷衍地涂改了两笔，根本没有写入实质性进度；甚至更糟糕的是，Claude 在你看不见的地方，悄悄修改了一个根本不该碰的源码文件。
而这些致命的失误，你往往只有在系统彻底跑崩、或者项目上线报错的那一刻才会痛苦地发现。
这就是为什么验证（Verification）必须作为独立的一环存在。
一个优秀的循环之所以会停下来，绝对不是因为模型“觉得写完了”，而是因为某一个具体的、硬性的约束条件通过了校验。
独立运行一个专门的“验证步骤”：来审查最近一次(latest)循环的执行结果。
对照标准进行体检：严格根据 LOOP_INSTRUCTIONS.md 中写明的“验证清单（Verification Checklist）”来核对输出结果。
生成一份详尽的体检报告，内容必须包含以下 5 个硬性指标：
在执行此验证步骤期间，验证器严禁修改工作区内的任何文件。
干活的与监工的，必须彻底分离。
先让“工人”（Worker）干活。干完之后，再让“监工”（Verifier）入场。两者必须分属不同的会话或不同的提示词逻辑。
因为监工需要一套绝对黑白分明的“通过/不通过”的标准。
“帮我看看这个结果，告诉我它看起来怎么样，行不行？”
“严格对照这 7 条硬性指标进行体检，只有在 7 条指标全部亮绿灯（PASS）的情况下，才允许将这次运行标记为‘接受（Accepted）’。”
当你在手动模式下反复验证，系统表现极度稳定之后，就可以将它托付给自动化了。
在 Claude Code 中，直接使用自带的 /loop 命令行工具：
/loop 24h 请为当前工作区运行每日项目审查循环。
严格遵循 `LOOP_INSTRUCTIONS.md`。
先阅读 `TASK.md` 与 `PROGRESS.md`。
将审查报告写入 `outputs/daily-review.md`，并在退出前更新 `PROGRESS.md`。
执行验证 checklist。
若无 meaningful 变更，保持报告简短。
若需要人工介入，在 `PROGRESS.md` 中进行显式标记。
除了`outputs/daily-review.md` 和 `PROGRESS.md`，严禁修改任何其他文件。
其中可选的时间间隔包括：
/loop 15m：测试节奏（在观看过程中使用）/loop 1h：每小时监控/loop 24h：每日定时运行/loop 7d：每周例行整理敲黑板：
/loop自身不是魔法。它仅仅是一个帮你自动按时发送 Prompt 的定时器。一个循环系统的真正生命力，完全来自于你在 Prompt 之外所设计的 4 文件结构、SOP 指南、强验证机制和状态持久化。
此外，你还需要了解另一个强大的内置命令 /goal：
/loop：代表基于时间触发（因为时间到期了，所以再跑一次，适合做日常监控、日报生成）。/goal：代表基于状态/目标触发（不达目标不停下，比如：直到通过所有测试用例前，不断尝试修复 Bug）。/goal outputs/daily-review.md exists, PROGRESS.md is updated,
verification checklist passes, no forbidden files modified.
很多人在构建 Loop 时，一上来就给 AI 开放最高权限：让它自由地往 Slack 发消息、直接合并代码到 Master 分支、自动关闭工单。
一旦发生幻觉，后果就是一场毁灭性的车祸。
你应该使用“权限控制阶梯”，逐步放权：
第 1 级 - 只读（Read Only）：AI 只能读取文件、工单、日志，无法做任何修改。
第 2 级 - 输出草稿（Draft Outputs）：AI 只能在指定的 `outputs/` 目录下生成草稿报告，严禁与外界发生任何交互。
第 3 级 - 沙盒修改（Sandbox Edits）：AI 被允许在完全隔离的 Docker 容器或 Git 临时分支或Worktree上尝试修改源码。
第 4 级 - 外部动作草稿（Draft external Actions）：AI 准备好 PR 描述、草拟好 Slack 消息，但绝不发送，等待人类最后点击确认。
第 5 级 - 人类授权动作（Human-approved actions）：只有在人类显式授权后，才能实施修改。
第 6 级 - 授权低风险自动化（Automated Low-risk）：在有严格日志、范围限制和回滚（Rollback）方案的前提下，允许 AI 自动执行窄领域的低风险任务。
你的第一个循环系统，必须老老实实呆在第 1 级或第 2 级。
这绝不意味着系统无能，恰恰相反，这是极度成熟的工程化体现。即使是前两级的循环，仍然具有巨大的价值。
Claude 可以检查你的 GitHub 问题，查看持续集成中的失败情况，审核 Pull 请求，并汇总所有相关信息——而无需直接接触那些重要的文件或数据。
首先，请证明该循环在 2 级时能够正常工作。
然后判断它是否值得获得三级评级。
这是大多数人最容易踩坑的地方。
一个反面教材（糟糕的初始循环设计）：
“每天持续优化产品战略文档，直到觉得它变得更强大。”
这个设计之所以糟糕，是因为：
这样一个失控的循环，要么什么有用武之地的事情都做不成，要么会在后台把你根本不想改动的文件改得面目全非。
一个优秀的循环：
outputs/strategy-review.md。这个设计之所以优秀，是因为它具备了：
这其间的差距，根本不在于模型的“智商（Intelligence）”，而在于你的“系统设计（Design）”。
请在执行你的第一条 /loop 命令前，务必排查并解决这五个问题：
一旦本地的单机循环运行稳定后，你才可以考虑逐步为它扩展外部连接：GitHub、Slack、Linear、Jira、CI 日志等。
但是，每增加一个新工具，都会相应地扩大系统的破坏半径。
请遵循完全相同的工程原则：先只读，再草拟，只有在经历过反复、多次成功的运行后，才放开写入权限。
你需要在 LOOP_INSTRUCTIONS.md 中，为特定的工具配置极其详尽的规则：
## 工具权限管理策略（Tool Permissions Policy）
### GitHub
允许的行为（Allowed）：
- 读取公开/未解决的 Issues
- 读取 Pull Request 的状态
- 读取 CI 的构建状态
- 在 `outputs/github-review.md` 中草拟摘要总结
禁止的行为（NOT allowed）：
- 在未经人类审核前，直接在公开讨论区发表评论
### Slack
允许的行为（Allowed）：
- 在 `outputs/slack-update.md` 中草拟消息内容
禁止的行为（NOT allowed）：
- 直接发送 Slack 消息
- 擅自 @ 提及用户
- 擅自往公共频道发帖
### Linear / Jira
允许的行为（Allowed）：
- 读取分配给当前用户的任务工单（Tickets）
- 在指定目录下草拟建议的更新内容
禁止的行为（NOT allowed）：
- 擅自修改工单状态
- 擅自关闭工单
- 在未经人类审核确认前，创建新工单
如果遇到任何未在上述策略中列出的工具，立即停止运行，并向人类寻求审核。
这项安全机制，能提供一道坚实的防火墙，保护你的系统不会在后台做出你意料之外的事情。
以下是你可以从零开始直接复制的完整配置：
首先，建立 LOOP_INSTRUCTIONS.md 并在其中声明基础工具策略：
## 工具权限管理策略（Tool Permissions Policy）
### GitHub
允许（Allowed）：
- 读取 open 状态的 issues
- 读取 pull request 状态
- 读取 CI 状态
- 关闭 issues
- 在未经批准前，允许在公开区域进行非评论类操作
... (其余工具策略同上文)
随后，根据前文提供的模板，填满 TASK.md、PROGRESS.md 和 LOOP_INSTRUCTIONS.md。
运行以下提示词来手动触发任务：
在采取行动前，请先完整阅读 TASK.md、PROGRESS.md 以及 LOOP_INSTRUCTIONS.md。
将每日审查报告写入 `outputs/daily-review.md`。
在停止运行前，务必更新 `PROGRESS.md`。
执行自我验证核对清单。
除了 `outputs/daily-review.md` 和 `PROGRESS.md`，严禁修改任何其他文件。
运行以下提示词来进行独立验证：
请执行一次验证过磅（Verification Pass）。
严格对照 `LOOP_INSTRUCTIONS.md` 中的“验证清单”进行逐项检查。
向我汇报：哪些检查通过了、哪些失败了、有哪些文件被改动过，以及是否需要人类介入审查。
在此期间，严禁修改任何文件。
在手动模拟微小的项目变更、并反复运行上述流程 3 到 5 次之后。
如果你确认它的表现已经无懈可击，即可配置定时任务：
[使用与上述手动运行完全相同的提示词，但在其最前面加上 /loop 24h 前缀]
在自动运行的第一周，请务必对每一次输出结果进行人工复审，确认无误后再完全信任它。
这就是一套完整的、生产级循环系统的生命周期。
TASK.md 一次性向系统声明了终极目标。PROGRESS.md 跨越不同的会话，完美传递运行状态和记忆。LOOP_INSTRUCTIONS.md 如同法律般死死控死 AI 的行为。至此，系统的瓶颈已经彻底从“如何生成代码/文案”，转移到了“如何更好地去审查和验证代码/文案”。
你真正地设计出了一套无需你肉身盯防、自己就能持续运转的自动化系统。
PROGRESS.md，自动为你润色好今天的站会发言稿。请记住，上面列出的每一个自动化工作流，全都是从那套极其简单的 “4文件系统” 开始起步的。
唯一需要修改的就是TASK.md 和 LOOP_INSTRUCTIONS.md。
如果说调整 Prompt 是在教 AI “怎么说一句话”，那么构建 Loop 就是在教 AI “怎么打一份工”。
这套以 TASK.md 定目标、INSTRUCTIONS.md 定规矩、PROGRESS.md 存记忆、outputs 装成果的极简“4 文件系统”，完美击中了当下大模型落地的最痛点——状态丢失与行为失控。它不依赖任何昂贵的企业级架构，任何一个掌握了命令行的开发者，今晚就能在自己的本地文件夹里跑通。
请记住文章中的那句忠告：“永远膨胀的状态文件等同于无用。把 PROGRESS.md 当作控制面板，而不是历史档案馆。” 收起你的权限，从只读（Level 1）开始，让你的循环在严苛的强验证（Strong Verification）下经历 5 次手动测试，再放心地交给自动调度。掌握了这一套微型系统工程学，你便跨越了普通使用者的门槛，真正成为了 AI 时代的系统架构师。
所有这些，都只需要你复制、粘贴本文的模板，填写你的具体要求，即可开始在 Claude Code 中狂奔。
去构建你的第一个循环，把重复的体力劳动，交还给守纪律的 AI吧。
原文链接：https://x.com/sairahul1/status/2074063593759227938
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。