如何使用 Claude Code 创建循环

大多数 Claude 工作流仍然是一次性的。

你写一个提示词。Claude 回复。会话结束。第二天你从零开始。

这对一次性任务来说没问题。

但对于重复性工作——每日回顾、CI 分类、项目监控、会议跟进——你每天都在重建相同的上下文。

这不是工作流。这是加了 AI 点缀的体力活。

更好的抽象是一个循环。

保存好这个。你会用到它的。

Claude 循环到底是什么

循环不是"再问一次 Claude"。

循环是一个围绕模型的可重复工作流结构。

它定义了：

→ 什么触发运行

→ Claude 在行动前读取什么上下文

→ Claude 被允许做什么 → 如何验证输出

→ 状态存储在哪里

→ 何时停止、重复或请求人工审核

模型仍然负责推理。

循环提供的是运行结构。

这种转变很重要，因为 Claude 会话是临时的。

没有循环，每次运行都从零开始。有了循环，Claude 会读取之前发生的事情，然后从那里继续。

每个 Claude 循环需要的 6 个部分

没有结构的循环只是一个运行两次的提示词。

以下是让循环真正起作用的 6 个部分：

→ 1. 触发器

什么启动运行。

手动命令。定时器。文件更改。CI 失败。Git 事件。

→ 2. 上下文

Claude 在行动前读取什么。

任务定义。先前进度。项目文件。指令。

→ 3. 行动

Claude 做什么。

撰写报告。起草修复方案。分类失败。更新文档。

→ 4. 验证

你如何检查结果。

检查清单。测试套件。必需部分。安全边界检查。

→ 5. 状态更新

什么被记住以供下次使用。

PROGRESS.md 已更新。阻塞项已记录。下次运行有指导。

→ 6. 决策

停止。重复。或升级给人类。

这就是完整的循环。

每一步都很重要。

跳过验证 → 循环盲目信任自己。

跳过状态 → 每次运行都从零开始。

跳过决策 → 循环永远不知道何时停止。

让循环工作的 4 文件系统

你不需要基础设施。

你需要 4 个文件和一个文件夹。

1my-loop/
2├── TASK.md
3├── LOOP_INSTRUCTIONS.md
4├── PROGRESS.md
5└── outputs/
6    └── daily-review.md

TASK.md — 目标。这个循环试图完成什么。

LOOP_INSTRUCTIONS.md — 操作流程。Claude 应该如何运行，它被允许做什么，如何验证。

PROGRESS.md — 记忆。上次发生了什么，什么被阻塞了，下次运行应该关注什么。

outputs/ — Claude 写入结果的地方。可预测。可检查。安全。

就是这样。

Claude 在每次运行开始时读取这些文件。在结束时更新它们。下次运行从上次停止的地方继续。

这就是循环与重复提示词的不同之处。

状态存在于聊天之外。

TASK.md — 清晰定义目标

这个文件告诉 Claude 循环的用途。

保持高层次。不要把操作细节放在这里。那些放在 LOOP_INSTRUCTIONS.md 中。

复制这个模板：

1# 每日项目回顾循环
2
3## 目标
4审查此项目文件夹，总结变更内容，
5识别阻塞项，并生成一份简短的每日回顾报告。
6
7## 预期输出
8每次运行应生成或更新：
9- `outputs/daily-review.md`
10- `PROGRESS.md`
11
12## 范围
13Claude 可以检查此工作区中的文件，并将
14报告写入 `outputs/` 文件夹。
15
16Claude 不应：
17- 修改源文件
18- 删除或重命名文件
19- 发送消息或创建工单

注意最后一部分。

任何循环的第一个版本都应该有明确的"禁止"规则。

这不是因为 Claude 不可信。

这是你在做一个好工程师。

PROGRESS.md — 循环的记忆

这是系统中最重要的文件。

没有它，每次运行都从头开始。有了它，Claude 知道发生了什么并从中继续。

实际有效的结构：

1# 循环进度
2
3## 当前状态
4- 状态：活跃
5- 主要目标：每日项目回顾
6- 当前焦点：[现在重要的事]
7- 最后更新：[日期]
8
9## 上次运行
10- 日期：
11- 摘要：
12- 审查的文件：
13- 生成的输出：
14
15## 待办项
16-
17
18## 阻塞项
19-
20
21## 需要人工审核
22-
23
24## 下次运行应
25-
26
27## 已做决策
28-
29
30## 不要重复
31-

"不要重复"部分至关重要。

它可以防止 Claude 重试已经失败的事情。

"需要人工审核"部分至关重要。

它可以防止循环在不该继续时悄悄继续。

保持 PROGRESS.md 有用的两个规则：

→ 如果 Claude 需要它来决定下一步行动 → 保留在 PROGRESS.md 中 → 如果你只是想要记录 → 将其移到 outputs/history/

无限增长的状态文件会变得无用。

保持 PROGRESS.md 作为一个控制面板，而不是一个存档。

LOOP_INSTRUCTIONS.md — 操作流程

这个文件是围绕 Claude 的控制层。

它告诉 Claude 确切地读什么、写什么、不要碰什么，以及在停止前如何验证结果。

有效的模板：

1# 循环指令
2
3你正在运行一个每日项目回顾循环。
4
5## 开始之前
61. 阅读 `TASK.md`
72. 阅读 `PROGRESS.md`
83. 检查项目文件夹
94. 识别哪些发生了变化、哪些未完成、哪些需要人工审核
10
11## 你应该做什么
12将一份简短的每日回顾写入 `outputs/daily-review.md`，包括：
13- 当前状态摘要
14- 审查的文件
15- 有意义的变更
16- 阻塞项或未解决的问题
17- 推荐的下一步行动
18
19写入后，更新 `PROGRESS.md`，包括：
20- 本次运行的日期
21- 发生情况的摘要
22- 检查的文件
23- 下次运行应该做什么
24- 是否需要人工审核
25
26## 安全规则
27- 不要删除文件
28- 不要重命名或移动文件
29- 不要修改源文件
30- 只写入 `outputs/daily-review.md` 和 `PROGRESS.md`
31- 如果不确定某个操作是否允许 → 停止并询问
32
33## 验证检查清单
34在结束运行前，确认：
35- `outputs/daily-review.md` 存在并包含所有必需部分
36- `PROGRESS.md` 已更新
37- 没有修改允许路径之外的文件
38
39## 失败策略
40如果验证失败：
411. 报告中缺少部分 → 修复一次
422. PROGRESS.md 未更新 → 更新一次
433. 修改了禁止的文件 → 立即停止
444. 同一检查失败两次 → 标记为需要人工审核

注意底部的失败策略。

大多数循环没有失败策略。

所以当出现问题时，Claude 会即兴发挥。

这就是循环产生问题的地方。

始终明确地定义失败路径。

手动运行你的第一个循环

先不要安排定时。

先手动运行。

在 Claude Code 或 Claude Desktop/Cowork 中打开文件夹。使用这个提示词：

1为此工作区运行每日项目回顾循环。
2
3严格遵循 `LOOP_INSTRUCTIONS.md`。
4
5在行动之前，阅读：
6- `TASK.md`
7- `PROGRESS.md`
8- `LOOP_INSTRUCTIONS.md`
9
10然后检查工作区，将每日回顾写入
11`outputs/daily-review.md`，更新 `PROGRESS.md`，
12运行验证检查清单，并报告哪些发生了变化。
13
14不要修改任何文件，除了
15`outputs/daily-review.md` 和 `PROGRESS.md`。

运行后，检查两件事：

→ outputs/daily-review.md — 包含所有部分的结构化报告

→ PROGRESS.md — 更新的状态、下次运行指导、人工审核标记

如果两者看起来都正确 → 循环正在工作。

现在再运行 3-5 次，做一些小的更改。

添加一个笔记文件。在 PROGRESS.md 中添加一个阻塞项。在工作区中更改一些内容。

每次运行都应该能够捕捉到更改，而无需从零开始。

这种连续性就是全部意义所在。

验证：大多数人跳过的部分

这是没人谈论的失败模式。

Claude 运行循环。说完成了。更新状态。停止。

一切看起来都很好。

但报告缺少必需的部分。或者 PROGRESS.md 实际上没有更新。或者 Claude 悄悄编辑了它不应该编辑的文件。

只有当某些东西出问题时你才会发现。

这就是为什么验证存在。

循环不应该因为 Claude 说它完成了就停止。

它停止是因为一个具体的条件被检查过了。

好的验证看起来像这样：

为最新的循环执行运行一次验证。

对照 LOOP_INSTRUCTIONS.md 中的验证检查清单

检查输出。

报告：

1. 哪些检查通过了
2. 哪些检查失败了
3. 哪些文件被修改了
4. 运行是否可以安全接受
5. 是否需要人工审核

在此验证过程中不要修改任何文件。

先运行工作器。然后运行验证器。分开进行。

随着时间的推移，你可以合并它们。但在早期测试中，保持它们分开。

验证器需要一个通过/失败的标准。

"审查一下，告诉我看起来好不好" 不是验证器。

"检查这 7 个条件，只有全部 7 个通过才标记运行为已接受" 才是验证器。

使用 /loop 进行调度

循环手动运行可靠了。

现在安排它。

在 Claude Code 中，使用 /loop：

1/loop 24h 为此工作区运行每日项目回顾循环。
2
3严格遵循 `LOOP_INSTRUCTIONS.md`。
4先阅读 `TASK.md` 和 `PROGRESS.md`。
5将报告写入 `outputs/daily-review.md`。
6在停止前更新 `PROGRESS.md`。
7运行验证检查清单。
8如果没有有意义的变更 → 保持报告简短。
9如果需要人工审核 → 在 `PROGRESS.md` 中清晰标记。
10不要修改任何文件，除了 `outputs/daily-review.md`
11和 `PROGRESS.md`。

间隔选项：

→ /loop 15m — 测试节奏（在观察时使用）

→ /loop 1h — 每小时监控

→ /loop 24h — 每日回顾

→ /loop 7d — 每周清理或总结

重要：/loop 不是魔法。

它只是重复提示词。

循环的质量来自于提示词周围的结构——文件、指令、验证、状态。

/loop 只提供触发器。

也要了解 /goal：

/loop = 因为时间过去了而再次运行。

/goal = 持续运行直到满足条件。

1/goal outputs/daily-review.md 存在，PROGRESS.md 已更新，
2验证检查清单通过，没有修改禁止的文件。

对于基于时间的工作（每日回顾、监控）使用 /loop。

对于基于完成的工作（修复直到测试通过，写直到所有部分完成）使用 /goal。

权限阶梯

这是大多数循环出错的地方。

人们构建了一个有效的循环。然后立即赋予它太多权力。

循环直接发布到 Slack。未经审查推送代码。自动关闭工单。

然后出了问题，变成一团糟。

改用权限阶梯：

1级别 1 — 只读
2Claude 读取文件、工单、日志、问题。
3
4级别 2 — 草拟输出
5Claude 只写入 outputs/。
6报告、计划、建议。
7不涉及外部。
8
9级别 3 — 沙盒编辑
10Claude 在受控沙盒内修改文件。
11隔离的分支或工作树。
12
13级别 4 — 草拟外部操作
14Claude 准备 PR、Slack 消息、工单更新。
15不发送或合并。
16
17级别 5 — 人工批准的操作
18Claude 仅在明确批准后应用更改。
19
20级别 6 — 自动化的低风险操作
21Claude 自动完成范围狭窄的任务。
22带有日志、限制和回滚。

你的第一个循环应该处于级别 1 或级别 2。

这不是软弱。这是工程学。

级别 1 和级别 2 的循环仍然可以非常有价值。

Claude 可以检查你的 GitHub 问题、阅读 CI 失败、审查 PRD，并总结所有内容——所有这些都不触及任何重要的东西。

先在级别 2 证明循环有效。

然后再决定它是否值得升级到级别 3。

当循环出错时（以及如何预防）

糟糕的第一个循环：

每天改进产品策略，直到感觉更强。

→ 没有停止条件 → 没有验证 → 没有状态 → "感觉更强" 不是检查清单项

这个循环要么什么有用的事都不做，要么改变它不应该改变的东西。

好的第一个循环：

每周五审查产品策略文档。

识别本周发生变化的章节。

列出未解决的假设。

将结构化的审查笔记写入 outputs/strategy-review.md。

不要直接编辑策略文档。

→ 清晰的日程 → 有限的范围 → 可预测的输出文件 → 安全的权限边界

区别不在于智能。在于设计。

导致循环失败的 5 件事：

→ 在手动测试之前就安排调度

→ 没有状态文件——每次运行都从零重启

→ 没有验证——循环信任自己

→ 没有失败策略——糟糕的结果即兴发挥

→ 过早引入太多工具——爆炸半径扩大

在第一个 /loop 命令之前修复所有这五点。

添加工具和连接器

一旦本地循环稳定，你可以扩展它。

GitHub。Slack。Linear。Jira。CI 日志。

但每个新工具都会扩大爆炸半径。

遵循同样的原则：先读，再草拟，只有在多次成功运行后才写入。

工具特定的规则放在 LOOP_INSTRUCTIONS.md 中：

1## 工具权限策略
2
3### GitHub
4允许：
5- 读取开放的问题
6- 读取拉取请求状态
7- 读取 CI 状态
8- 在 `outputs/github-review.md` 中草拟摘要
9不允许：
10- 推送提交
11- 合并拉取请求
12- 关闭问题
13- 未经批准公开发布评论
14
15### Slack
16允许：
17- 在 `outputs/slack-update.md` 中草拟消息
18不允许：
19- 发送消息
20- 提及用户
21- 发布到频道
22
23### Linear/Jira
24允许：
25- 读取分配的工单
26- 草拟建议的更新
27不允许：
28- 更改状态
29- 关闭工单
30- 未经批准创建工单

如果工具未列出 → 停止并请求人工审核。

这可以保护你免受循环做你没想到的事情。

你的第一个完整循环看起来像什么

这是从头开始的完整设置。

1## 工具权限策略
2
3### GitHub
4允许：
5- 读取开放的问题
6- 读取拉取请求状态
7- 读取 CI 状态
8- 在 `outputs/github-review.md` 中草拟摘要
9不允许：
10- 推送提交
11- 合并拉取请求
12- 关闭问题
13- 未经批准公开发布评论
14
15### Slack
16允许：
17- 在 `outputs/slack-update.md` 中草拟消息
18不允许：
19- 发送消息
20- 提及用户
21- 发布到频道
22
23### Linear/Jira
24允许：
25- 读取分配的工单
26- 草拟建议的更新
27不允许：
28- 更改状态
29- 关闭工单
30- 未经批准创建工单

然后填充每个文件（使用上面的模板）。

然后手动运行：

1为此工作区运行每日项目回顾循环。
2
3严格遵循 `LOOP_INSTRUCTIONS.md`。
4在行动之前，阅读 TASK.md、PROGRESS.md
5和 LOOP_INSTRUCTIONS.md。
6将每日回顾写入 `outputs/daily-review.md`。
7在停止前更新 `PROGRESS.md`。
8运行验证检查清单。
9不要修改任何文件，除了
10`outputs/daily-review.md` 和 `PROGRESS.md`。

然后验证：

1运行一次验证。
2对照 `LOOP_INSTRUCTIONS.md` 中的验证检查清单
3进行检查。
4报告哪些检查通过了，哪些失败了，
5哪些文件被修改了，是否需要人工审核。
6不要修改任何文件。

手动运行 3-5 次，对工作区进行小的更改。

然后安排调度：

1/loop 24h 运行每日项目回顾循环...
2[与手动相同的提示词，前面加上 /loop 24h]

在信任它之前，先审查第一周的计划输出。

这就是完整的系统。

改变一切的转变

在循环之前：

→ 你写了一个提示词

→ Claude 回答了

→ 第二天你写了同样的提示词

→ Claude 没有昨天的记忆

→ 你手动跟踪变化

→ 每次会话都重置一切

在循环之后：

→ TASK.md 一次定义目标

→ PROGRESS.md 跨运行携带记忆

→ LOOP_INSTRUCTIONS.md 控制行为

→ Claude 读取、行动、验证、更新、停止

→ 第二天它从上次停下的地方继续

→ 你审查输出，而不是提示词

瓶颈从生成工作转变为审查工作。

这才是真正的杠杆作用。

你不是在问 Claude 更好的问题。

你是在设计一个没有你也能持续工作的系统。

本周可以构建的 10 个循环

→ 每日项目回顾 — 读取工作区，写入摘要

→ 会议跟进提取器 — 将笔记转化为行动项

→ 文件夹清理规划器 — 组织、提议、不触碰

→ CI 失败分类 — 读取日志，分类失败，草拟调查

→ GitHub 问题总结器 — 读取开放问题，按主题分组

→ PR 审查助手 — 读取差异，标记潜在问题

→ 新闻通讯研究循环 — 收集来源，草拟摘要

→ 文档缺口查找器 — 读取文档，标记缺失部分

→ 每日站会草稿器 — 读取 PROGRESS.md，写入站会内容

→ 每周回顾循环 — 回顾一周，识别模式

每一个都从相同的 4 文件系统开始。

唯一改变的是 TASK.md 和 LOOP_INSTRUCTIONS.md。

如果这对你有帮助：

→ 转发分享给每个使用 Claude 的开发者

→ 关注 @sairahul1 获取更多无需你操心的系统

→ 收藏这个——模板是复制即用的

订阅 theaibuilders.co 获取更多此类有趣文章

我写关于 AI、产品构建和自动化系统的内容。