用好 Loop 能讓你事半功倍，六個實戰場景教你駕馭循環工程

一句話概覽

過去兩年，99%的人用 AI 寫代碼、寫東西，大概都是這樣：寫個 prompt，等它回，讀一遍，再補一句，繼續等。人一直握着工具，一回合一回合往前推。

「你不該再去 prompt 你的編程 agent 了，你該去設計那些替你 prompt agent 的循環。」Anthropic Claude Code 負責人 Boris Cherny 也講到類似經驗：「我已經不 prompt Claude 了，我有一堆 loop 在跑，是它們在 prompt Claude、在決定下一步。我的工作是寫 loop。」隨後 Addy Osmani 把這件事命名爲 Loop Engineering（循環工程）。

✅說得直白一點：

Loop Engineering，就是從“自己一句句去 prompt”轉到“設計一套會繼續 prompt 的系統”。

人的價值沒有消失，只是位置變了。一頭是意圖：把“我到底要什麼”說到可以驗收。一頭是擔責：跑出來的東西，最後算在你頭上。中間那些反覆問、反覆查、反覆改的步驟，可以交給循環。

這事已經沒那麼折騰了。一年前你想要個 loop，常常要攢一摞只有自己看得懂的 bash。到 2026 年中，Claude Code、Codex、OpenCode 已經把不少零件做進產品裏。看懂 loop 的形狀，比糾結工具名更重要。

一、Loop 是什麼

要理解循環工程，先看它在譜系裏的位置。這幾年槓桿點一直在往離“裸模型調用”更遠的地方移：

它和 cron 定時任務的差別，在於裏面多了一個會判斷下一步的 agent。cron 跑寫死的腳本；循環會看當前狀態，挑動作，執行，檢查結果，再決定繼續、重試、回滾或停止。這個“觀察、決策、行動、驗證”（observe-decide-act-verify）就是循環的內核。主流 AI 廠商最後都靠近了這個結構，源頭可以追到 2022 年普林斯頓和 Google 的 ReAct 框架（推理與行動交替）。

一個循環由什麼組成：五個部件和一個狀態層

第六個最容易被新手跳過。模型每次跑完都會忘，狀態文件就是讓今天這次運行知道昨天干了什麼的辦法。少了它，很多系統看似在循環，其實只是在重複同一個第一步。

記住這個六件套的形狀，忘掉每一個具體命令鍵，你就學會了循環工程；反過來背熟命令鍵、錯過形狀，你只學會了這個月的 CLI。

二、怎麼判斷一個活該不該做成 loop

不要把所有活都做成循環。先過三道篩子：

重複：你做得夠頻繁，設計這套系統的成本能賺回來。
可驗：“做完了”能寫成一個 agent 或驗收子 agent 真能跑的檢查。說不清“通過長什麼樣”，循環就不知道何時該停。
值得：產出對得起燒的 token。循環有時間和金錢的底價，瑣碎小活不夠格。

三條都滿足，它想要一個循環；缺一條，老老實實手動 prompt 或寫個普通腳本更划算。

另一個判斷角度，是看這活屬於哪種工作結構：

流程型：步驟已知、順序已知、結果可預測（發票進來→匹配→付款）。畫成流程圖沒有任何決策分叉，用傳統自動化（腳本、RPA）就行，不需要循環。
工具輔助型：目標已知，但路徑多變。你問、它答、你定奪，人還在方向盤上。這是今天大多數 AI copilot 的位置。
目標驅動型：你定個目標、畫個邊界，讓系統自己摸出步驟，評估、決策、行動、檢查，重複到完成，或者把高風險事項交給人。這一類才適合循環。

更值得判斷的問題是：“哪些地方需要裝一個會判斷下一步的循環？”

三、手把手搭你的第一個循環

前面講的是形狀。這裏直接搭一個最常見的“晨間維護循環”。你可以照着在一個 throwaway 測試倉庫裏試，第一次別對着重要倉庫跑，循環會自己改文件。

成品大概長這樣：

每個工作日早上 9 點： # ① 心跳
讀 progress.md # ⑥ 狀態文件（記憶）
找昨夜的 CI 失敗 + 新 issue # 要乾的活
對每一條：
在獨立 checkout 裏起草修復 # ② Worktree
用項目的 triage 技能 # ③ Skill
讓一個單獨的 reviewer 打分 # ⑤ 子 agent（做/檢分離）
PASS：開 PR # ④ 連接器
有風險：寫進 progress.md 留給人
更新 progress.md # ⑥ 狀態文件

然後逐件拼。

第 0 步：選一個活，並把“完成”寫成能被驗證的條件

這是全場最難的一步。“把代碼改好”太虛，“test/auth 全過且 npm run lint 乾淨”纔夠用。把停止條件寫成驗收單，四個字段儘量都補上：

agent 還是那個執行者，你寫的是它必須通過的那張驗收單。

第 1 步：裝上心跳，讓它自己啓動

心跳有四種，從“停在這次會話裏”到“完全沒你也跑”。按需要選：

① 會話內循環（盯着看，關掉會話就停），適合盯一個長任務直到完成：

# Claude Code：每 5 分鐘跑一次，會話開着纔有效
/loop 5m 檢查部署有沒有跑完，跑完就告訴我結果

# OpenCode：自己用 shell 當心跳（opencode run 跑完一句就退出）
while true; do
opencode run "檢查部署是否完成，完成就回 DONE"
sleep 300
done

② 跑到達標爲止，讓循環自己判斷何時停止：

# Claude Code：給一個它自己輸出能證明的條件
/goal test/auth 下所有測試通過，且 npm run lint 乾淨。

# OpenCode：用 shell + 退出碼，讓命令來判停
for i in $(seq 1 8); do # 一定要封頂，別無限跑
opencode run "讓 test/auth 的測試通過，並修掉 lint 報錯。"
if npm test -- test/auth && npm run lint; then
echo "第 $i 次達標"; break
fi
done

/goal 好用的地方在這裏：每回合結束後，一個單獨的小模型讀一遍記錄，判斷“達標沒有”。寫代碼的那個 agent 不給自己判分。它沒有內置的“試 N 次就放棄”，要封頂就寫進條件裏，比如“跑滿 20 回合就停”。

③ 無人值守定時，你睡覺它也跑：

# 自己機器上用 cron：每個工作日 9 點
0 9 * * 1-5 cd /path/to/repo && claude -p "查 CI 看板，總結失敗項" >> ~/cron.log 2>&1

# 同樣一行，OpenCode 版
0 9 * * 1-5 cd /path/to/repo && opencode run "查 CI 看板，總結失敗項" >> ~/cron.log 2>&1

想要筆記本關着也跑，就用雲端 routine（在 claude.ai/code/routines 建，跑在服務器上）或 GitHub Actions 的 schedule 觸發。

④ 事件驅動，PR 打開、CI 掛了、消息到了就觸發。比如一個 PR review 的 GitHub Action：

on:
pull_request:
types: [opened, synchronize, reopened]
# 觸發後讓 agent review 這個 PR 的 diff

給循環兩個剎車：一個成功條件，一個上限。成功條件說明這事什麼時候算完成；上限說明最多跑幾次、幾分鐘、多少錢。少了上限，預算會被一個達不到的目標慢慢燒掉。

第 2 步：把步驟寫進一個 skill，讓循環 prompt 保持一行

凡是你每次都要重新解釋的東西，都該進 skill。這樣定時任務的 prompt 可以縮成一句“跑 daily-triage 技能”，細節留在版本控制裏，誰都能改。一個真實可用的 SKILL.md：

---
name: daily-triage
description: 晨間維護：讀進度文件，收集昨夜 CI 失敗、新 issue、審計告警，
起草安全修復（每個都由單獨的 reviewer 檢查），通過的開 PR，
有風險的寫進進度文件留給人。用於每日定時維護循環。
---
# 每日 triage（按順序做，別跳過進度文件，它是你唯一的跨次記憶）

## 1. 先讀記憶
- 打開 progress.md，讀“進行中”和“需要人”兩節。
- “已完成”裏有的，不要重做。

## 2. 找活（按序，最多取 5 條）
1. 上次記錄之後失敗的 CI。
2. 帶 bug、maintenance 標籤的 open issue。
3. npm audit（或本項目審計命令）的新告警。

## 3. 逐條處理
- 開一個獨立 checkout：git worktree，或新分支 claude/<短slug>。
- 起草解決“這一個”問題的最小改動，不要捆綁多個改動。
- 把 diff 交給 reviewer agent，拿到結論再繼續。

## 4. 按結論決定
- PASS 且低風險（不動公開 API、無數據遷移、不刪文件）：開 PR，標題 fix: <一行>，關聯 issue。
- FAIL 或動到任何風險項：不開 PR，往 progress.md“需要人”追加一條，寫清你試了什麼、爲什麼停。

## 5. 最後更新記憶
- 完成項移到“已完成”並寫上今天日期，保存 progress.md。

## 鐵律
- 一次最多開 5 個 PR；絕不直接動 main，只用 claude/* 分支；拿不準就升級給人。

第 3 步：做/檢分離，配一個 reviewer 子 agent

循環裏很重要的一條：寫活的 agent 不許給自己的活判分。模型給自己打分時經常太寬。配一個單獨的、只讀的、常用更便宜模型的 reviewer，它跑測試、對照規範，只回 PASS 或 FAIL：

---
name: reviewer
description: 對照 spec 和測試結果檢查 diff，回 PASS 或 FAIL 並給理由，不做任何改動。
tools: Read, Bash(npm test*), Bash(npm run lint*), Bash(git diff*)
model: claude-haiku-4-5
---

你是一個嚴格的只讀 reviewer，從不改文件。
1. 自己跑測試和 linter，親自讀輸出，別信“它說通過了”。
2. 對照 CLAUDE.md 裏的項目約定和相關 spec 檢查改動。
3. 找 bug、漏掉的邊界情況、安全風險、對公開行爲的改動。
然後只回其中一個：
- PASS：後跟一行你驗證了什麼。
- FAIL：後跟具體理由，一行一條。
“看起來沒問題”不算 PASS。測試必須真的過，且改動只做了被要求的事。

子 agent 更費 token，每個都跑自己的模型和工具。把它花在值得第二意見的地方，比如任何會在你不盯着時提交東西的循環；只讀的小雜活就別配了。

第 4 步：裝上狀態文件

模型每次跑完就忘，記憶必須放在模型之外、放在磁盤上。可以分兩層：一層是規則文件（CLAUDE.md、AGENTS.md，記錄穩定習慣，保持短，因爲每次讀都要花錢）；一層是進度文件，記“試了什麼、過了什麼、還開着什麼”：

## 已完成
- 2026-06-22：修了 test/auth 的 flaky 測試（token 刷新時重試）
## 進行中
- 依賴審計：7 個告警修了 3 個；lodash 升級遇到一個 API 變更
## 需要人
- 圖像庫 CVE-2026-xxxx：修復會改輸出格式，升級給維護者

習慣就一條：每次跑，開頭讀它，結尾更新它。當循環反覆犯同一個錯，別急着寫更玄的 prompt，把教訓寫進規則文件，讓後面的每一次運行都能讀到。

第 5 步：接上工具，讓它能動手

只能讀文件的循環只會“說”。連接器（基於 MCP）讓它開 PR、更新工單、發 Slack、查庫、調 staging API。一個系統只能說“這是修復方案”，另一個系統能在測試通過後開 PR、關聯工單、發頻道，差別就在這裏。把你手動用的那些連接器，加進定時或雲端 routine 的連接器清單即可。

把六件拼起來：一個真實早晨

你把上面這些設計一次。某個早晨醒來，記錄可能是這樣：

[09:00] daily-triage 觸發
→ 讀 progress.md：1 項還在進行（lodash），無新標記
→ 發現：昨夜 2 個 CI 失敗、1 個新 npm-audit 告警
→ CI 失敗 #1（flaky auth 測試）：
在 claude/fix-auth-retry 分支起草修復
reviewer → PASS（測試綠；token 刷新重試；無 API 改動）→ 開 PR #142
→ CI 失敗 #2（report.ts 類型錯）：
起草修復 → reviewer → PASS → 開 PR #143
→ 告警（圖像庫）：安全修復會改輸出格式
reviewer → FAIL（公開行爲變更）→ 寫進 progress.md“需要人”，不開 PR
→ 更新 progress.md，退出
[你，09:30] 兩個待 review 的 PR，一個要拍板的事項。你一個字沒敲。

這就是循環工程在乾的事：找活、起草、檢查，把安全的部分發出去，只把真正需要人的決定交到你手裏。Claude Code 和 OpenCode 的差別，主要在心跳和運行位置；中間的 skill、狀態文件、worktree、做/檢分離、連接器，設計思路差不多。

四、它能省下哪些重複勞動

骨架學會了，就可以把“晨間維護”這套東西搬到別的活上。別急着擴大範圍，先問一句：產出能不能被命令、清單或另一個 agent 驗收？

代碼與工程類

可以交出去的活：每天扒 CI 失敗、給 issue 分診、修一類反覆出現的 bug、跑依賴升級、做框架遷移、逐個 review PR。

做法基本沿用晨間維護循環。常見變體有幾種：

“跑到測試通過爲止”：/goal test/auth 全過且 lint 乾淨，讓小模型判停。
框架/API 遷移（清空隊列模式）：找下一個還在用舊 API 的文件，遷到新寫法，跑測試，停止條件是“沒有文件再匹配舊寫法”，封頂 200 次。
安全漏洞規模化：這類已有公開案例，比如某瀏覽器一個月提交 423 個安全修復。關鍵不只在模型能力，也在外層結構：先用一個簡單的 LLM 評委給每個文件打分（出內存安全問題的可能性 × 從網頁觸發的難易度）排優先級；agent 可以連續嘗試很多辦法去觸發一個 bug；驗證再分兩段，先觸發真實崩潰，再讓 verifier 確認報告合理。誤報會少很多。同一結構也能用於性能優化、技術債。

內容流水線類

可以交出去的活：批量清洗文案、把粗想法變 hook、把一篇長內容拆成多平臺版本、按缺口批量生成文章。

這裏要把“完成態”寫成數得出來的檢查。比如：

/goal 把 captions.txt 裏每條改寫到 150 字內、不帶話題標籤，全部改完爲止，
別動其他文件，最多 30 回合。 # 可驗收：0 條超 150 字或含 #

/goal 把 ideas.txt 裏 20 個粗想法各改成一個 10 詞內的 hook，全做完爲止。
# 可驗收：20 條全部改寫完

更大的形態是多 agent 流水線：一個 agent 按內容缺口生成配圖文章並排版，一個 agent 推送發佈。但這裏要清醒一點。模型越強，瓶頸越像指揮者的品味。循環會放大你寫進 rubric、skill、驗證步驟裏的判斷；判斷糊了，它只是更快地生產一堆你不該發的東西。

信息監控與研究類

可以交出去的活：盯日誌、盯服務健康、盯競品定價頁、盯 API changelog、盯一個領域的新聞、做一輪競品調研。

按觸發方式，可以分四種：

心跳：短間隔持續跑。每 5 分鐘查 staging 錯誤日誌，錯誤率超 1% 就開 issue。
定時：固定時間跑批。每工作日 10 點 review 所有超 3 天的 PR，逐個總結阻塞並 @ 作者。
鉤子：事件觸發跑一次。PR 推上來、CI 掛了、消息到了。
目標：迭代到達標才停，適合範圍未知的任務。找出我們品類所有公開競品，按這五個維度打分，起草定位簡報。

還有一種辦法，是把實時網頁當心跳：監控一組 URL，內容一變就觸發。定價頁改了，啓動競品響應；changelog 更新了，觸發文檔重寫；狀態頁出事，叫醒 on-call。個人場景裏最輕的版本，就是晨間簡報：每天早上讀未讀郵件，把最重要的 3 封各一行發我 Slack，別回任何東西。

文檔生成類

可以交出去的活：把一摞 PDF 逐個寫摘要、把零散數據整成結構化報告、按模板寫提案/方案初稿、維護一份會過時的文檔。

核心是“清空隊列 + 反思、多 agent 檢查”：

/goal 給 reports 文件夾每個 PDF 寫 5 行白話摘要到 summaries.md，
每個都有爲止，別改 PDF，最多 40 回合。 # 可驗收：每個 PDF 都有對應摘要

按風險選循環模式：

反思 + schema 校驗：起草結構化報告，對照 schema 補全缺字段，人最後過一遍。適合工地報告、表單類。
多 agent review + 人類閘門：A 起草，B 查規範、查合規、標出不該出現的敏感標識，人簽字。適合診療方案、合規文檔。
反思 + 清單校驗：起草，對照方法論框架、字數格式和數據一致性檢查，再標出需佐證的論斷。適合提案。
帶護欄的自治：逐條或逐批校驗，只把沒過自動檢查的（通常 <5%）升級給人。適合數據批處理。

文檔寫手循環還能再套四層：① agent 幹活（克隆倉庫、讀寫文件、開 PR）；② 驗證循環（一個 grader 跑檢查，鏈接是否都通、CI 是否全綠、diff 是否只動了被要求的範圍，不達標就帶反饋打回）；③ 事件循環（某頻道一來消息就觸發）；④ 改進循環（拿運行記錄喂分析 agent，自動改進 prompt 或工具配置）。

個人事務與辦公

可以交出去的活：清理爆滿收件箱、每月那份你一想到就頭疼的報告、客服工單清理。

做法也不用複雜。用“目標 + 定時器”拼第一個自治 agent，不用寫代碼。建一個 routine：“每天早上讀未讀郵件，最重要的 3 封各一行發我 Slack，別回任何東西”，連上 Gmail/Slack，設每天 9 點。進階時再加一個 skill，裏面寫你的處理方法；再加一個獨立 checker，比如它判斷某個被自動關閉的工單該留給人，就重新打開。

安全建議很簡單：先只讀。讓它先“總結、彙報”跑幾天，用大白話設死限制（“不許回覆”“不許刪除”），看着頭幾次跑，再讓它動手。

商業與運營

替你處理：那些本來週期性做、其實該連續做的決策。定價每季度看一次競品再調，HR 每年調研一次半年後纔行動，產品每 sprint 按上月數據排一次優先級，這些都可以重新看。

做法是從“能力地圖”升級成“循環地圖”。對每項能力問：它是流程型（傳統自動化）？工具輔助型（給人配更好工具）？還是目標驅動型（部署一個有邊界、有升級觸發、有人類監督的循環）？把“定價信號每天評估、實時建議”“持續追蹤早期流失、在人遞辭呈前標出干預點”這種位置識別出來。真正的價值，常常來自一個原本不存在的決策循環，或者把慢的季度循環改成更快的連續循環。

也要記得行業現實。Gartner 預測到 2027 年底，超過 40% 的 agentic AI 項目會被砍掉，原因是成本失控、價值不清、風控不足。很多問題都指向同一件事：把 agent 硬塞進碎片化流程，卻沒想清楚循環該裝在哪、需要什麼才能跑。

五、風險與邊界

循環改變了工作方式，但沒把你從工作裏刪掉。循環越強，下面三個問題越繞不開。

讓循環停下來很難。每個循環都得帶硬剎車，三道閘儘量都要有：
迭代次數硬上限：跑不動的循環不能一直轉；
無進展檢測：最近幾輪沒有任何變化，就停；
token、美元預算上限：賬單失控前先停。

三者缺一，賬單就容易失控。一個樸素的成本感：一拍（maker + checker）約讀 4 萬、寫 6 千 token，按 Sonnet 4.6 價約 0.2 美元一拍；一天 5 拍、一月 20 天約 20 美元，便宜。同一循環改成全天每 5 分鐘一拍，拍數上百倍，輕鬆破 1000 美元一月，卻未必多產出價值。真正花錢的是頻率。省錢三招：模型分級（強模型規劃與檢查、便宜模型幹活，這是最大頭的省）、prompt 和規則文件保持短、降低頻率（每小時一次比每 5 分鐘一次便宜約 12 倍）。

驗證還是你的活。無人值守地跑，也會無人值守地犯錯。把做和檢拆開，是爲了讓“做完了”有點分量；但“done”只是聲明，還得看證據。讀循環開的 diff，對它產出的代碼負責。最誠實的 checker 是測試 runner 和 linter，命令沒法說服自己“這活挺好”。
理解會慢慢變薄。循環把你沒寫的代碼更快送進倉庫，“倉庫裏有什麼”和“你真正理解什麼”之間的缺口會變大（comprehension debt，理解債）。循環跑起來以後，人也容易照單全收（cognitive surrender，認知投降）。同樣是設計循環，帶着判斷去做，它會幫你把熟悉的工作推進得更快；爲了逃避思考去做，它會把你推到更陌生的地方。循環分不出這兩種情況，人得自己分。