# How to Create Loops with Claude Code
**作者**: Rahul
**日期**: 2026-07-06T09:31:09.000Z
**来源**: [https://x.com/sairahul1/status/2074063593759227938](https://x.com/sairahul1/status/2074063593759227938)
---
Most Claude workflows are still one-shot.
You write a prompt. Claude responds. Session ends. Tomorrow you start from zero.
That's fine for one-off tasks.
But for repetitive work — daily reviews, CI triage, project monitoring, meeting follow-ups — you're rebuilding the same context every single day.
That's not a workflow. That's manual labor with AI sprinkles.
The better abstraction is a loop.
Save this. You'll use it.
## What a Claude loop actually is
A loop is not "just ask Claude again."
A loop is a repeatable workflow structure around the model.
It defines:
→ What triggers the run
→ What context Claude reads before acting
→ What Claude is allowed to do → How the output is verified
→ Where the state is stored
→ When to stop, repeat, or ask for human review
The model still does the reasoning.
The loop provides the operating structure.
The shift matters because Claude sessions are temporary.
Without a loop, every run starts from zero. With a loop, Claude reads what happened before and continues from there.
## 6 parts every Claude loop needs
A loop without structure is just a prompt that runs twice.
Here are the 6 parts that make a loop actually work:
→ 1. Trigger
What starts the run.
Manual command. Scheduled timer. File change. CI failure. Git event.
→ 2. Context
What Claude reads before acting.
Task definition. Previous progress. Project files. Instructions.
→ 3. Action
What Claude does.
Write a report. Draft a fix. Classify failures. Update a document.
→ 4. Verification
How you check the result.
Checklist. Test suite. Required sections. Safety boundary check.
→ 5. State update
What gets remembered for next time.
PROGRESS.md updated. Blockers recorded. Next run guided.
→ 6. Decision
Stop. Repeat. Or escalate to human.
That's the full loop.
And every step matters.
Skip verification → the loop trusts itself blindly.
Skip state → every run starts from zero.
Skip the decision → the loop never knows when to stop.
## The 4-file system that makes loops work
You don't need infrastructure.
You need 4 files and a folder.
```
my-loop/
├── TASK.md
├── LOOP_INSTRUCTIONS.md
├── PROGRESS.md
└── outputs/
└── daily-review.md
```
TASK.md — The goal. What this loop is trying to accomplish.
LOOP_INSTRUCTIONS.md — The operating procedure. How Claude should run, what it's allowed to do, how to verify.
PROGRESS.md — The memory. What happened last time, what's blocked, what the next run should focus on.
outputs/ — Where Claude writes results. Predictable. Inspectable. Safe.
That's it.
Claude reads these files at the start of every run. Updates them at the end. Next run continues from where the last one stopped.
This is what makes loops different from repeated prompts.
State lives outside the chat.
## TASK.md — Define the goal clearly
This file tells Claude what the loop is for.
Keep it high-level. Don't put operating details here. Those go in LOOP_INSTRUCTIONS.md.
Copy this template:
```
# Daily Project Review Loop
## Goal
Review this project folder, summarize what changed,
identify blockers, and produce a short daily review report.
## Expected Output
Each run should produce or update:
- `outputs/daily-review.md`
- `PROGRESS.md`
## Scope
Claude may inspect files in this workspace and write
reports to the `outputs/` folder.
Claude should NOT:
- Modify source files
- Delete or rename files
- Send messages or open tickets
```
Notice the last section.
The first version of any loop should have explicit "do not" rules.
This is not Claude being untrusted.
This is you being a good engineer.
## PROGRESS.md — The loop's memory
This is the most important file in the system.
Without it, every run starts from scratch. With it, Claude knows what happened and continues from there.
The structure that actually works:
```
# Loop Progress
## Current State
- Status: Active
- Main objective: Daily project review
- Current focus: [what matters right now]
- Last updated: [date]
## Last Run
- Date:
- Summary:
- Files reviewed:
- Output produced:
## Open Items
-
## Blockers
-
## Needs Human Review
-
## Next Run Should
-
## Decisions Made
-
## Do Not Repeat
-
```
The "Do Not Repeat" section is critical.
It prevents Claude from retrying things that already failed.
The "Needs Human Review" section is critical.
It stops the loop from silently continuing when it shouldn't.
Two rules for keeping PROGRESS.md useful:
→ If Claude needs it to decide the next action → keep it in PROGRESS.md → If you just want a record → move it to outputs/history/
State files that grow forever become useless.
Keep PROGRESS.md as a control panel, not an archive.
## LOOP_INSTRUCTIONS.md — The operating procedure
This file is the control layer around Claude.
It tells Claude exactly what to read, what to write, what not to touch, and how to verify the result before stopping.
The template that works:
```
# Loop Instructions
You are running a daily project review loop.
## Before You Start
1. Read `TASK.md`
2. Read `PROGRESS.md`
3. Inspect the project folder
4. Identify what changed, what's incomplete, what needs human review
## What You Should Do
Write a short daily review to `outputs/daily-review.md` including:
- Summary of current state
- Files reviewed
- Meaningful changes
- Blockers or unresolved questions
- Recommended next actions
After writing, update `PROGRESS.md` with:
- Date of this run
- Summary of what happened
- Files checked
- What the next run should do
- Whether human review is needed
## Safety Rules
- Do not delete files
- Do not rename or move files
- Do not modify source files
- Only write to `outputs/daily-review.md` and `PROGRESS.md`
- If unsure whether an action is allowed → stop and ask
## Verification Checklist
Before ending the run, confirm:
- `outputs/daily-review.md` exists with all required sections
- `PROGRESS.md` was updated
- No files outside allowed paths were modified
## Failure Policy
If verification fails:
1. Missing section in report → fix once
2. PROGRESS.md not updated → update once
3. Forbidden file modified → stop immediately
4. Same check fails twice → mark as needing human review
```
Notice the failure policy at the bottom.
Most loops have no failure policy.
So when something goes wrong, Claude improvises.
That's where loops create problems.
Define the failure path explicitly. Always.
## Running your first loop manually
Don't schedule yet.
Run manually first.
Open the folder in Claude Code or Claude Desktop/Cowork. Use this prompt:
```
Run the daily project review loop for this workspace.
Follow `LOOP_INSTRUCTIONS.md` exactly.
Before acting, read:
- `TASK.md`
- `PROGRESS.md`
- `LOOP_INSTRUCTIONS.md`
Then inspect the workspace, write the daily review to
`outputs/daily-review.md`, update `PROGRESS.md`,
run the verification checklist, and report what changed.
Do not modify any files except
`outputs/daily-review.md` and `PROGRESS.md`.
```
After the run, check two things:
→ outputs/daily-review.md — structured report with all sections
→ PROGRESS.md — updated state, next run guidance, human review flags
If both look right → the loop is working.
Now run it 3-5 more times with small changes.
Add a notes file. Add a blocker to PROGRESS.md. Change something in the workspace.
Each run should pick up the changes without starting from zero.
That continuity is the whole point.
## Verification: the part most people skip
Here's the failure mode nobody talks about.
Claude runs the loop. Says it's done. Updates the state. Stops.
Everything looks fine.
But the report is missing required sections. Or PROGRESS.md wasn't actually updated. Or Claude quietly edited a file it shouldn't have.
You only find out when something breaks.
That's why verification exists.
The loop should not stop because Claude says it's finished.
It stops because a concrete condition was checked.
Good verification looks like this:
Run a verification pass for the latest loop execution.
Check the output against the Verification Checklist
in `LOOP_INSTRUCTIONS.md`.
Report:
1. Which checks passed
2. Which checks failed
3. Which files were modified
4. Whether the run is safe to accept
5. Whether human review is required
Do not modify any files during this verification pass.
Run the worker. Then run the verifier. Separately.
Over time you can merge them. But during early testing, keep them apart.
The verifier needs a pass/fail standard.
"Review this and tell me if it looks good" is NOT a verifier.
"Check these 7 conditions and mark the run accepted only if all 7 pass" IS a verifier.
## Scheduling with /loop
The loop is running reliably manually.
Now schedule it.
In Claude Code, use /loop:
```
/loop 24h Run the daily project review loop for this workspace.
Follow `LOOP_INSTRUCTIONS.md` exactly.
Read `TASK.md` and `PROGRESS.md` first.
Write the report to `outputs/daily-review.md`.
Update `PROGRESS.md` before stopping.
Run the verification checklist.
If no meaningful changes → keep the report short.
If human review needed → mark clearly in `PROGRESS.md`.
Do not modify any files except `outputs/daily-review.md`
and `PROGRESS.md`.
```
The interval options:
→ /loop 15m — Testing cadence (use while watching)
→ /loop 1h — Hourly monitoring
→ /loop 24h — Daily review
→ /loop 7d — Weekly cleanup or summary
Important: /loop is not magic.
It just repeats the prompt.
The quality of the loop comes from the structure around the prompt — the files, the instructions, the verification, the state.
/loop only provides the trigger.
Also know about /goal:
/loop = run again because time passed.
/goal = keep running until a condition is met.
```
/goal outputs/daily-review.md exists, PROGRESS.md is updated,
verification checklist passes, no forbidden files modified.
```
Use /loop for time-based work (daily reviews, monitoring).
Use /goal for completion-based work (fix until tests pass, write until all sections done).
## The permission ladder
This is where most loops go wrong.
People build a loop that works. Then immediately give it too much power.
The loop posts to Slack directly. Pushes code without review. Closes tickets automatically.
Then something goes wrong and it's a mess.
Use the permission ladder instead:
```
Level 1 — Read only
Claude reads files, tickets, logs, issues.
Level 2 — Draft outputs
Claude writes to outputs/ only.
Reports, plans, recommendations.
Nothing external.
Level 3 — Sandbox edits
Claude modifies files inside a controlled sandbox.
Isolated branch or worktree.
Level 4 — Draft external actions
Claude prepares PR, Slack message, ticket update.
Does NOT send or merge.
Level 5 — Human-approved actions
Claude applies changes only after explicit approval.
Level 6 — Automated low-risk actions
Claude completes narrowly scoped tasks automatically.
With logs, limits, and rollback.
```
Your first loop should live at Level 1 or Level 2.
That's not weakness. That's engineering.
Level 1 and 2 loops can still be enormously valuable.
Claude can inspect your GitHub issues, read CI failures, review PRDs, and summarize everything — all without touching anything important.
Prove the loop works at Level 2 first.
Then decide whether it deserves Level 3.
## When loops go wrong (and how to prevent it)
Bad first loop:
Every day, improve the product strategy until it feels stronger.
→ No stop condition → No verification → No state → "Feels stronger" is not a checklist item
This loop will either do nothing useful or change things it shouldn't.
Good first loop:
Every Friday, review the product strategy document.
Identify sections that changed this week.
List unresolved assumptions.
Write a structured review note to outputs/strategy-review.md.
Do not edit the strategy document directly.
→ Clear schedule → Limited scope → Predictable output file → Safe permission boundary
The difference isn't intelligence. It's design.
The 5 things that sink loops:
→ Scheduling before manual testing
→ No state file — every run restarts from zero
→ No verification — the loop trusts itself
→ No failure policy — bad outcomes improvise
→ Too many tools too early — blast radius expands
Fix all five before the first /loop command.
## Adding tools and connectors
Once the local loop is stable, you can extend it.
GitHub. Slack. Linear. Jira. CI logs.
But every new tool expands the blast radius.
Follow the same principle: read first, draft second, write only after repeated successful runs.
Tool-specific rules go in LOOP_INSTRUCTIONS.md:
```
## Tool Permissions Policy
### GitHub
Allowed:
- Read open issues
- Read pull request status
- Read CI status
- Draft summary in `outputs/github-review.md`
NOT allowed:
- Push commits
- Merge pull requests
- Close issues
- Comment publicly without approval
### Slack
Allowed:
- Draft message in `outputs/slack-update.md`
NOT allowed:
- Send messages
- Mention users
- Post to channels
### Linear/Jira
Allowed:
- Read assigned tickets
- Draft suggested updates
NOT allowed:
- Change status
- Close tickets
- Create tickets without approval
```
If the tool isn't listed → stop and ask for human review.
This protects you from the loop doing things you didn't think about.
## What your first complete loop looks like
Here's the full setup from scratch.
```
## Tool Permissions Policy
### GitHub
Allowed:
- Read open issues
- Read pull request status
- Read CI status
- Draft summary in `outputs/github-review.md`
NOT allowed:
- Push commits
- Merge pull requests
- Close issues
- Comment publicly without approval
### Slack
Allowed:
- Draft message in `outputs/slack-update.md`
NOT allowed:
- Send messages
- Mention users
- Post to channels
### Linear/Jira
Allowed:
- Read assigned tickets
- Draft suggested updates
NOT allowed:
- Change status
- Close tickets
- Create tickets without approval
```
Then fill each file (use the templates from above).
Then run manually:
```
Run the daily project review loop for this workspace.
Follow `LOOP_INSTRUCTIONS.md` exactly.
Before acting, read TASK.md, PROGRESS.md,
and LOOP_INSTRUCTIONS.md.
Write the daily review to `outputs/daily-review.md`.
Update `PROGRESS.md` before stopping.
Run the verification checklist.
Do not modify any files except
`outputs/daily-review.md` and `PROGRESS.md`.
```
Then verify:
```
Run a verification pass.
Check against the Verification Checklist in
`LOOP_INSTRUCTIONS.md`.
Report which checks passed, which failed,
which files were modified, whether human review is required.
Do not modify any files.
```
Run 3-5 times manually with small workspace changes.
Then schedule:
```
/loop 24h Run the daily project review loop...
[same prompt as manual, prefixed with /loop 24h]
```
Review the first week of scheduled outputs before trusting it.
That's the full system.
## The shift that changes everything
Before loops:
→ You wrote a prompt
→ Claude answered
→ Tomorrow you wrote the same prompt again
→ Claude had no memory of yesterday
→ You manually tracked what changed
→ Everything reset with each session
After loops:
→ TASK.md defines the goal once
→ PROGRESS.md carries memory across runs
→ LOOP_INSTRUCTIONS.md controls behavior
→ Claude reads, acts, verifies, updates, stops
→ Tomorrow it continues from where it left off
→ You review outputs, not prompts
The bottleneck shifts from generating work to reviewing work.
That's the real leverage.
You're not asking Claude better questions.
You're designing a system that keeps working without you.
## 10 loops you can build this week
→ Daily project review — reads workspace, writes summary
→ Meeting follow-up extractor — turns notes into action items
→ Folder cleanup planner — organizes, proposes, doesn't touch
→ CI failure triage — reads logs, classifies failures, drafts investigation
→ GitHub issue summarizer — reads open issues, groups by theme
→ PR review assistant — reads diff, flags potential issues
→ Newsletter research loop — gathers sources, drafts summaries
→ Documentation gap finder — reads docs, flags missing sections
→ Daily standup drafter — reads PROGRESS.md, writes standup
→ Weekly retrospective loop — reviews the week, identifies patterns
Every one of these starts with the same 4-file system.
The only thing that changes is TASK.md and LOOP_INSTRUCTIONS.md.
## If this was useful:
→ Repost to share it with every developer using Claude
→ Follow @sairahul1 for more systems that work without you
→ Bookmark this — the templates are copy-paste ready
Subscribe to theaibuilders.co for more such interesting articles
I write about AI, building products, and automation systems.
## 相关链接
- [Rahul](https://x.com/sairahul1)
- [@sairahul1](https://x.com/sairahul1)
- [147K](https://x.com/sairahul1/status/2074063593759227938/analytics)
- [@sairahul1](https://x.com/@sairahul1)
- [theaibuilders.co](https://theaibuilders.co/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [5:31 PM · Jul 6, 2026](https://x.com/sairahul1/status/2074063593759227938)
- [147.2K Views](https://x.com/sairahul1/status/2074063593759227938/analytics)
- [View quotes](https://x.com/sairahul1/status/2074063593759227938/quotes)
---
*导出时间: 2026/7/7 10:57:53*
---
## 中文翻译
# 如何使用 Claude Code 创建循环
**作者**: Rahul
**日期**: 2026-07-06T09:31:09.000Z
**来源**: [https://x.com/sairahul1/status/2074063593759227938](https://x.com/sairahul1/status/2074063593759227938)
---
大多数 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 个文件和一个文件夹。
```
my-loop/
├── TASK.md
├── LOOP_INSTRUCTIONS.md
├── PROGRESS.md
└── outputs/
└── daily-review.md
```
TASK.md — 目标。这个循环试图达成什么。
LOOP_INSTRUCTIONS.md — 操作流程。Claude 应该如何运行，它被允许做什么，如何验证。
PROGRESS.md — 记忆。上次发生了什么，什么被阻塞了，下一次运行应该关注什么。
outputs/ — Claude 写入结果的地方。可预测、可检查、安全。
就这样。
Claude 在每次运行开始时读取这些文件。在结束时更新它们。下一次运行从上一次停止的地方继续。
这就是循环与重复提示词的区别。
状态存在于聊天之外。
## TASK.md — 清晰地定义目标
这个文件告诉 Claude 循环的目的是什么。
保持高层次。不要把操作细节放在这里。那些属于 LOOP_INSTRUCTIONS.md。
复制这个模板：
```
# 每日项目复盘循环
## 目标
审查此项目文件夹，总结变更内容，
识别阻碍因素，并生成一份简短的每日复盘报告。
## 预期输出
每次运行应生成或更新：
- `outputs/daily-review.md`
- `PROGRESS.md`
## 范围
Claude 可以检查此工作区中的文件并将
报告写入 `outputs/` 文件夹。
Claude 不应该：
- 修改源文件
- 删除或重命名文件
- 发送消息或创建工单
```
注意最后一部分。
任何循环的初版都应该有明确的“禁止”规则。
这不是因为 Claude 不可信。
而是因为你是一位优秀的工程师。
## PROGRESS.md — 循环的记忆
这是系统中最重要的文件。
没有它，每次运行都从零开始。有了它，Claude 知道发生了什么并在此基础上继续。
真正有效的结构：
```
# 循环进度
## 当前状态
- 状态：活跃
- 主要目标：每日项目复盘
- 当前关注点：[当前重要的事项]
- 最后更新：[日期]
## 上次运行
- 日期：
- 摘要：
- 审查的文件：
- 产生的输出：
## 待办事项
-
## 阻碍因素
-
## 需要人工审查
-
## 下次运行应该
-
## 已做出的决策
-
## 不要重复
-
```
“不要重复”这一节至关重要。
它防止 Claude 重试已经失败的事情。
“需要人工审查”这一节至关重要。
它阻止循环在不该继续时悄无声息地继续运行。
保持 PROGRESS.md 有用的两条规则：
→ 如果 Claude 需要它来决定下一个动作 → 保留在 PROGRESS.md
→ 如果你只是想留个记录 → 移至 outputs/history/
无限增长的文件会变得毫无用处。
把 PROGRESS.md 当作控制面板，而不是档案库。
## LOOP_INSTRUCTIONS.md — 操作流程
这个文件是围绕 Claude 的控制层。
它明确告诉 Claude 读什么、写什么、不要碰什么，以及在停止前如何验证结果。
有效的模板：
```
# 循环指令
你正在运行每日项目复盘循环。
## 开始之前
1. 阅读 `TASK.md`
2. 阅读 `PROGRESS.md`
3. 检查项目文件夹
4. 识别变更、未完成事项以及需要人工审查的部分
## 你应该做什么
将简短的每日复盘写入 `outputs/daily-review.md`，包括：
- 当前状态摘要
- 审查的文件
- 有意义的变更
- 阻碍因素或未解决的问题
- 推荐的下一步行动
写入后，更新 `PROGRESS.md`，包括：
- 本次运行的日期
- 发生的事情摘要
- 检查的文件
- 下次运行应该做什么
- 是否需要人工审查
## 安全规则
- 不要删除文件
- 不要重命名或移动文件
- 不要修改源文件
- 只能写入 `outputs/daily-review.md` 和 `PROGRESS.md`
- 如果不确定某操作是否被允许 → 停下来询问
## 验证清单
在结束运行前，确认：
- `outputs/daily-review.md` 存在且包含所有必需章节
- `PROGRESS.md` 已更新
- 没有修改允许路径之外的文件
## 失败策略
如果验证失败：
1. 报告缺少章节 → 修复一次
2. PROGRESS.md 未更新 → 更新一次
3. 禁止的文件被修改 → 立即停止
4. 同一检查失败两次 → 标记为需要人工审查
```
注意底部的失败策略。
大多数循环没有失败策略。
所以当出错时，Claude 会即兴发挥。
这就是循环制造问题的地方。
明确地定义失败路径。始终如此。
## 手动运行你的第一个循环
先别安排定时。
先手动运行。
在 Claude Code 或 Claude Desktop/Cowork 中打开文件夹。使用这个提示词：
```
Run the daily project review loop for this workspace.
Follow `LOOP_INSTRUCTIONS.md` exactly.
Before acting, read:
- `TASK.md`
- `PROGRESS.md`
- `LOOP_INSTRUCTIONS.md`
Then inspect the workspace, write the daily review to
`outputs/daily-review.md`, update `PROGRESS.md`,
run the verification checklist, and report what changed.
Do not modify any files except
`outputs/daily-review.md` and `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 个条件，只有全部通过才将运行标记为接受”**是**验证者。
## 使用 /loop 进行调度
循环手动运行可靠了。
现在安排定时。
在 Claude Code 中，使用 /loop：
```
/loop 24h Run the daily project review loop for this workspace.
Follow `LOOP_INSTRUCTIONS.md` exactly.
Read `TASK.md` and `PROGRESS.md` first.
Write the report to `outputs/daily-review.md`.
Update `PROGRESS.md` before stopping.
Run the verification checklist.
If no meaningful changes → keep the report short.
If human review needed → mark clearly in `PROGRESS.md`.
Do not modify any files except `outputs/daily-review.md`
and `PROGRESS.md`.
```
时间间隔选项：
→ /loop 15m — 测试频率（在有人监控时使用）
→ /loop 1h — 每小时监控
→ /loop 24h — 每日复盘
→ /loop 7d — 每周清理或汇总
重要提示：/loop 并不是魔法。
它只是重复提示词。
循环的质量来自于提示词周围的结构——文件、指令、验证、状态。
/loop 只提供触发器。
还要了解 /goal：
/loop = 时间到了就再运行一次。
/goal = 持续运行直到满足条件。
```
/goal outputs/daily-review.md exists, PROGRESS.md is updated,
verification checklist passes, no forbidden files modified.
```
将 /loop 用于基于时间的任务（每日复盘、监控）。
将 /goal 用于基于完成的任务（修复直到测试通过、编写直到所有章节完成）。
## 权限阶梯
这是大多数循环出错的地方。
人们建立了一个能用的循环。然后立即给它太大的权力。
循环直接发帖到 Slack。未经审查推送代码。自动关闭工单。
然后出问题了，变得一团糟。
改用权限阶梯：
```
Level 1 — 只读
Claude 读取文件、工单、日志、议题。
Level 2 — 草稿输出
Claude 只写入 outputs/。
报告、计划、建议。
不涉及任何外部操作。
Level 3 — 沙盒编辑
Claude 在受控的沙盒内修改文件。
隔离的分支或工作树。
Level 4 — 草拟外部操作
Claude 准备 PR、Slack 消息、工单更新。
不发送或合并。
Level 5 — 人工批准的操作
Claude 仅在获得明确批准后应用更改。
Level 6 — 自动化低风险操作
Claude 自动完成范围狭窄的任务。
带有日志、限制和回滚机制。
```
你的第一个循环应该停留在 Level 1 或 Level 2。
这不是弱点，这是工程。
Level 1 和 2 的循环仍然可以非常有价值。
Claude 可以检查你的 GitHub 议题，阅读 CI 失败，审查 PRD，并总结所有内容——所有这些都不需要触碰任何重要的东西。
首先证明循环在 Level 2 有效。
然后决定它是否值得进入 Level 3。
## 循环出错时（以及如何预防）
糟糕的初版循环：
每天改进产品策略，直到感觉更强有力。
→ 无停止条件 → 无验证 → 无状态 → “感觉更强有力”不是清单项
这个循环要么什么都不做，要么修改不该修改的东西。
好的初版循环：
每周五，审查产品策略文档。
识别本周变更的章节。
列出未解决的假设。
将结构化的审查笔记写入 outputs/strategy-review.md。
不要直接编辑策略文档。
→ 清晰的时间表 → 有限的范围 → 可预测的输出文件 → 安全的权限边界
区别不在于智能，而在于设计。
导致循环失败的 5 个原因：
→ 在手动测试前就安排定时
→ 没有状态文件 —— 每次运行都从零重启
→ 没有验证 —— 循环自我信任
→ 没有失败策略 —— 糟糕的结果即兴发挥
→ 太早使用太多工具 —— 爆炸半径扩大
在执行第一个 /loop 命令之前，修复这全部五点。
## 添加工具和连接器
一旦本地循环稳定，你就可以扩展它。
GitHub。Slack。Linear。Jira。CI 日志。
但每个新工具都会扩大爆炸半径。
遵循相同的原则：先读，后草稿，只有在反复成功运行后才写入。
针对特定工具的规则写在 LOOP_INSTRUCTIONS.md 中：
```
## 工具权限策略
### GitHub
允许：
- 读取开放议题
- 读取拉取请求状态
- 读取 CI 状态
- 在 `outputs/github-review.md` 中起草摘要
不允许：
- 推送提交
- 合并拉取请求
- 关闭议题
- 未经批准公开发表评论
### Slack
允许：
- 在 `outputs/slack-update.md` 中起草消息
不允许：
- 发送消息
- 提及用户
- 发布到频道
### Linear/Jira
允许：
- 读取分配的工单
- 起草建议的更新
不允许：
- 更改状态
- 关闭工单
- 未经批准创建工单
```
如果工具未列出 → 停止并请求人工审查。
这保护你免受循环执行你意想不到的操作。
## 你的第一个完整循环是什么样的
这是从头开始的完整设置。
```
## 工具权限策略
### GitHub
允许：
- 读取开放议题
- 读取拉取请求状态
- 读取 CI 状态
- 在 `outputs/github-review.md` 中起草摘要
不允许：
- 推送提交
- 合并拉取请求
- 关闭议题
- 未经批准公开发表评论
### Slack
允许：
- 在 `outputs/slack-update.md` 中起草消息
不允许：
- 发送消息
- 提及用户
- 发布到频道
### Linear/Jira
允许：
- 读取分配的工单
- 起草建议的更新
不允许：
- 更改状态
- 关闭工单
- 未经批准创建工单
```
然后填充每个文件（使用上面的模板）。
然后手动运行：
```
Run the daily project review loop for this workspace.
Follow `LOOP_INSTRUCTIONS.md` exactly.
Before acting, read TASK.md, PROGRESS.md,
and LOOP_INSTRUCTIONS.md.
Write the daily review to `outputs/daily-review.md`.
Update `PROGRESS.md` before stopping.
Run the verification checklist.
Do not modify any files except
`outputs/daily-review.md` and `PROGRESS.md`.
```
然后验证：
```
Run a verification pass.
Check against the Verification Checklist in
`LOOP_INSTRUCTIONS.md`.
Report which checks passed, which failed,
which files were modified, whether human review is required.
Do not modify any files.
```
用微小的工作区更改手动运行 3-5 次。
然后安排定时：
```
/loop 24h Run the daily project review loop...
[same prompt as manual, prefixed with /loop 24h]
```
在信任之前审查第一周的定时输出。
这就是完整的系统。
## 改变一切的转变
在循环之前：
→ 你写一个提示词
→ Claude 回答
→ 明天你又写了同样的提示词……