别再把 Claude 当一次性计算器了：用 Loop 搭建可复用的自动化工作流

大多数人和 Claude 的协作方式还是”一问一答”的单次模式。你写一段提示词，Claude 给出回复，会话结束。到了第二天，你把差不多的上下文再重建一遍。

处理一次性任务，这套流程没问题。但面对日常代码审查、CI 故障分类、项目进度监控这类重复性工作，每天手动拼凑相同的背景信息，本质上不是工作流，而是披着 AI 外衣的手工劳动。

真正能产生杠杆效应的抽象方式是 Loop（循环）。把它存下来，你会反复用到。

什么是 Claude Loop？和你想的”再问一遍”不一样

Claude Loop 不是简单地”再问 Claude 一次”。它是围绕模型构建的一套可重复执行的工作流结构，定义了触发条件、读取的上下文、允许执行的动作、输出验证方式、状态存储位置以及何时停止或交由人工处理。

模型本身依然负责推理，Loop 提供的是运行框架。

这个区分很关键，因为 Claude 的会话是临时的。没有 Loop，每次运行都从零开始；有了 Loop，Claude 会读取上一次发生的事情并从那里继续。

一个完整的 Loop 包含六个部分，缺一不可：

• 触发器：什么启动这次运行。手动命令、定时器、文件变动、CI 失败或 Git 事件。
• 上下文：Claude 行动前读什么。任务定义、历史进度、项目文件、操作指令。
• 动作：Claude 做什么。写报告、起草修复方案、分类故障、更新文档。
• 验证：如何检查结果。检查清单、测试套件、必填章节、安全边界检查。
• 状态更新：为下次运行记住什么。更新 PROGRESS.md、记录阻塞项、指导下一次运行。
• 决策：停止、重复，还是升级给人工。

跳过验证，Loop 会盲目自信；跳过状态更新，每次运行回到原点；跳过决策，Loop 永远不知道何时该停。

搭建 Loop 不需要复杂的基础设施，四个文件就够了

你不需要搞什么重型架构，只需要四个文件和一个文件夹。

my-loop/
├── TASK.md
├── LOOP_INSTRUCTIONS.md
├── PROGRESS.md
└── outputs/
    └── daily-review.md

• TASK.md：目标。这个 Loop 要达成什么。
• LOOP_INSTRUCTIONS.md：操作规程。Claude 该怎么跑、能做什么、怎么验证。
• PROGRESS.md：记忆。上次发生了什么、卡在哪里、下次该关注什么。
• outputs/：Claude 写结果的地方。路径可预测、内容可审查、操作安全。

Claude 在每次运行开始时读取这些文件，结束时更新它们。下一次运行就从上一次停下的地方继续。这就是 Loop 和重复发提示词的根本区别：状态存在聊天之外。

TASK.md 怎么写才能防止 Claude 越界？

TASK.md 告诉 Claude 这个 Loop 的目的是什么。保持高层次描述，具体的操作细节放在 LOOP_INSTRUCTIONS.md 里。

直接套用这个模板：

# 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

注意最后的 “Claude should NOT” 部分。任何 Loop 的第一个版本都必须包含明确的”禁止”规则。这不是因为不信任 Claude，而是你在做一个严谨的工程师该做的事——划定边界。

PROGRESS.md 为什么是整个系统里最重要的文件？

没有 PROGRESS.md，每次运行都从零开始。有了它，Claude 知道之前发生了什么，并能接着往下干。

实测好用的结构如下：

# 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

-

这里面有两个关键段落。”Do Not Repeat” 防止 Claude 重试已经失败过的事情，避免死循环。”Needs Human Review” 让 Loop 在不该继续的时候停下来，而不是闷头往下跑。

维护 PROGRESS.md 有两条铁律：如果 Claude 需要靠它来决定下一步动作，就留在 PROGRESS.md 里；如果你只是想要个历史记录，挪到 outputs/history/ 去。无限膨胀的状态文件最终会变成废料。把它当控制面板用，别当档案柜。

LOOP_INSTRUCTIONS.md：给 Claude 画好操作框和兜底策略

这个文件是套在 Claude 外面的控制层。它精确规定读什么、写什么、碰什么、怎么在停止前验证结果。

# 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

重点看底部的 Failure Policy（失败策略）。大部分 Loop 没有这个，一出错 Claude 就开始即兴发挥，这正是 Loop 惹祸的根源。必须把失败路径白纸黑字写清楚。

先别急着定时，手动跑通前五次再说

别上来就设定时任务。先手动跑。

在 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 里塞一个阻塞项，改改工作区里的东西。每次运行都应该能接住这些变化，而不是从头来过。这种连续性才是 Loop 的核心价值。

验证环节：大多数人跳过的步骤，恰恰是 Loop 不翻车的关键

有一种失败模式没人提：Claude 跑完 Loop，说自己干完了，更新了状态，停了。表面一切正常。但报告缺了必填章节，或者 PROGRESS.md 其实没改，又或者 Claude 悄悄改了不该碰的文件。等你发现的时候，东西已经坏了。

这就是验证存在的理由。Loop 不该因为 Claude 说”我做完了”就停。它该停在一个具体的检查条件被满足的时候。

好的验证长这样：

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.

先跑执行者，再跑验证者，分开跑。早期测试阶段绝对不要合并。验证者需要一个明确的通过/不通过标准。”看看这个行不行”不是验证，”检查这 7 个条件，全过才接收”才是。

/loop 和 /goal 有什么区别？什么时候用哪个？

手动跑稳了，就可以调度了。在 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 的质量来自提示词外围的结构——文件、指令、验证、状态。/loop 只提供触发器。

还有一个 /goal 命令。/loop 是”时间到了再跑一次”，/goal 是”跑到条件满足为止”。

/goal outputs/daily-review.md exists, PROGRESS.md is updated,
verification checklist passes, no forbidden files modified.

基于时间的任务（每日审查、监控）用 /loop，基于完成度的任务（跑到测试通过、写到所有章节填满）用 /goal。

权限梯子：别一上来就让 Loop 直接发消息和推代码

Loop 出问题，多半栽在这一步。很多人刚搭好一个能跑的 Loop，立刻给它塞一堆权限。直接往 Slack 发消息、不经审查就推代码、自动关工单。然后出事了，一地鸡毛。

用权限梯子代替冲动：

• Level 1 — 仅读：Claude 读文件、工单、日志、Issue。
• Level 2 — 草稿输出：Claude 只往 outputs/ 写东西。报告、计划、建议，不碰外部。
• Level 3 — 沙盒编辑：Claude 在隔离的分支或 worktree 里改文件。
• Level 4 — 外部动作草稿：Claude 准备 PR、Slack 消息、工单更新，但不发送不合并。
• Level 5 — 人工批准后执行：Claude 在你明确点头后才动。
• Level 6 — 自动化低风险动作：Claude 在有日志、限制和回滚机制的前提下，自动完成范围极窄的任务。

你的第一个 Loop 应该待在 Level 1 或 Level 2。这不是保守，是工程纪律。这两个级别的 Loop 已经能产生巨大价值：Claude 可以扫你的 GitHub Issue、读 CI 报错、审 PRD、全汇总起来，完全不碰任何要紧的东西。先在 Level 2 证明它能跑对，再考虑它配不配上 Level 3。

Loop 翻车的五个原因（以及怎么避开）

看一个反面教材：

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

没有停止条件，没有验证，没有状态，”感觉更强”根本不是检查项。这个 Loop 要么什么有用的事都不做，要么乱改一气。

正面教材：

每周五审查产品策略文档。标出本周改动的章节。列出未解决的假设。写一份结构化审查笔记到 outputs/strategy-review.md。不要直接编辑策略文档。

有明确的时间表，有限的范围，可预测的输出路径，安全的权限边界。差别不在于智能程度，在于设计。

搞砸 Loop 的原因就五个：没手动测就定时；没有状态文件导致每次重启；没有验证导致盲目自信；没有失败策略导致出错时乱来；过早接入太多工具导致爆炸半径失控。在敲第一个 /loop 命令之前，把这五个全解决掉。

接入外部工具前，先在指令里写死权限边界

本地 Loop 稳了之后，你可以接 GitHub、Slack、Linear、Jira、CI 日志。但每多一个工具，爆炸半径就大一圈。

坚持同一个原则：先读，再起草，跑通多次之后才考虑写入。工具级别的规则写进 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

如果某个工具没在列表里，Claude 应该停下并请求人工审查。这能防住 Loop 做出你没想到的操作。

从零开始的完整搭建流程

把前面的内容串起来，完整的实操路径是这样的：

第一步，建目录和文件：

mkdir my-loop && cd my-loop
mkdir outputs
touch TASK.md LOOP_INSTRUCTIONS.md PROGRESS.md

第二步，把上面的模板填进对应文件。

第三步，手动跑执行提示词。

第四步，手动跑验证提示词。

第五步，带着小改动手动跑 3 到 5 次。

第六步，加 /loop 24h 定时。

第七步，审查第一周的定时输出，没问题才真正放手。

瓶颈从”生成工作”转移到了”审查工作”。这才是真正的杠杆。你不是在问 Claude 更好的问题，而是在设计一个不需要你盯着也能运转的系统。

本周就能搭出来的 10 个实用 Loop

所有这些起手式都是同一套四文件系统，变的只是 TASK.md 和 LOOP_INSTRUCTIONS.md 的内容：

• 每日项目审查：读工作区，写摘要。
• 会议跟进提取器：把会议笔记转成待办事项。
• 文件夹清理规划器：做整理方案，但不真动文件。
• CI 故障分类：读日志，给失败原因打标签，起草排查方向。
• GitHub Issue 汇总：读开放 Issue，按主题分组。
• PR 审查助手：读 Diff，标出潜在问题。
• Newsletter 调研 Loop：收集素材，起草摘要。
• 文档缺口扫描：读现有文档，标出缺漏的章节。
• 每日站会草稿：读 PROGRESS.md，写站会发言稿。
• 周回顾 Loop：回顾一周记录，找规律。

---

实用摘要 / 操作清单

• [ ] 创建 my-loop/ 目录，内含 TASK.md、LOOP_INSTRUCTIONS.md、PROGRESS.md 和 outputs/ 文件夹。
• [ ] 在 TASK.md 中写清目标、预期输出和明确的”禁止事项”。
• [ ] 在 PROGRESS.md 中预留”Needs Human Review”和”Do Not Repeat”段落。
• [ ] 在 LOOP_INSTRUCTIONS.md 底部写死 Failure Policy。
• [ ] 用执行提示词手动跑通第一次。
• [ ] 用独立的验证提示词跑一次检查。
• [ ] 制造小改动，手动再跑 3 到 5 次，确认连续性。
• [ ] 确认权限停留在 Level 1 或 Level 2。
• [ ] 使用 /loop 24h 或 /goal 调度。
• [ ] 审查第一周的输出。

一页速览

Claude Loop 是围绕模型构建的六步可重复工作流（触发、上下文、动作、验证、状态更新、决策），通过四个本地文件（TASK.md、LOOP_INSTRUCTIONS.md、PROGRESS.md、outputs/）将会话记忆从聊天窗口剥离到文件系统。核心原则是：手动跑通再定时，状态文件当控制面板用，验证必须基于硬性检查项而非感觉，权限从只读和写草稿起步，失败路径必须显式定义。

FAQ

Claude Loop 和我每天手动发同样的提示词有什么区别？
手动发提示词每次都从零开始，Loop 会读 PROGRESS.md 接续上次的进度和上下文。

PROGRESS.md 写太多东西会不会撑爆上下文？
会。只留决定下一步动作所需的信息，纯历史记录移到 outputs/history/，把它当控制面板而不是档案库。

为什么不第一步就接入 Slack 和 GitHub？
每接入一个外部工具，Loop 搞砸时的爆炸半径就大一圈。先在本地只读和写草稿的级别证明它不会乱来。

/loop 和 /goal 该选哪个？
看任务性质。每天早上跑一次用 /loop，跑到测试全过才停用 /goal。

验证环节能不能和执行合并成一步？
早期测试绝对不行。分开跑才能确保验证标准是硬性的，而不是 Claude 自己觉得”看起来挺好”。

Loop 悄悄改了不该改的文件怎么办？
在 LOOP_INSTRUCTIONS.md 里写死 Failure Policy，一旦触犯禁止路径立刻停止并标记需要人工审查。

第一个 Loop 做什么最不容易翻车？
每日项目审查或会议笔记提取。只读工作区文件，往 outputs/ 写摘要，完全不碰源文件和外部工具。