如何使用 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不要修改任何檔案。

手動運行 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、產品建構和自動化系統的文章。