# Loop engineering：從 Prompter 到 Loop Designer 的 14 步指南 > 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt) > 原作者：Codez (@0xCodez) · 策展與摘要：EasyVibeCoding · 平台：X (Twitter) · 熱度：🔥 · 日期：2026-06-10 > 原始來源：https://x.com/0xCodez/status/2064374643729773029 ## 中文摘要 # Loop engineering：從 Prompter 到 Loop Designer 的 14 步指南 大多數開發者仍然手動對他們的 Coding Agent 下達 Prompt。他們輸入、等待、閱讀 Diff，然後再次輸入。十個開發者中有九個從未寫過一個能自動為他們執行 Prompt 的 Loop。 沒有自動化、沒有狀態檔案、沒有驗證器、沒有排程。槓桿點已經轉移了——從「輸入 Prompt」轉向「設計會自動執行 Prompt 的系統」。這是從 Prompter 轉型為 Loop Designer 的 14 步指南。 > 追蹤我的 Linkedin 以獲取最新的 AI 資訊：linkedin.com/in/lev-deviatkin 這份 14 步指南旨在協助你完成轉型，內容彙整自 Anthropic 的工程文件、Addy Osmani 關於 Loop engineering 的長篇論述，以及近期的效能評估研究。 分為三個階段：確認你是否真的需要 Loop、學習五個建構模組，然後在不造成損害的前提下，建構出最小可行性的 Loop。 ![此圖表展示了自動化代理（Agent）運作循環的五個關鍵步驟，並強調了「狀態檔案（State file）」在跨執行週期中維持記憶的重要性。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/ba89ae4c7cd794b2.png)
展開畫面重點
圖表標題：What a loop actually does（一個循環實際上做了什麼） 上方選單項目： - AUTOMATIONS - WORKTREES - SKILLS - CONNECTORS - SUB-AGENTS - STATE FILE（目前選取狀態） 循環流程圖： 1. Find work（尋找工作）：A loop finds the work（循環負責尋找工作） 2. Hand it to the agent（交給代理）：Bounded job, right context（有限的工作，正確的上下文） 3. Check result（檢查結果）：Test, type error, failing build（測試、型別錯誤、建置失敗） 4. Record what happens（記錄發生什麼）：State survives between runs（狀態在執行間存續） 5. Decide next move（決定下一步）：Stop, retry, or hand off（停止、重試或轉交） 底部說明： - State file：The agent forgets each run. The file does not.（代理會忘記每次執行，但檔案不會。） 畫面重點：此圖解說明了自動化系統如何透過「狀態檔案」來克服代理程式（Agent）本身無記憶的限制，確保任務在多次執行循環中能持續追蹤進度並做出決策。
14 個步驟，3 個階段。停止手動輸入 Prompt，開始進行系統設計。 --- 第一部分 · 為什麼要這麼做與測試方法 ## 01. Loop engineering 就是讓你從 Prompter 的角色中解放出來。 過去兩年，你從 Coding Agent 獲取成果的方式是：寫一個 Prompt、分享 context、閱讀回傳的內容、寫下一個 Prompt。Agent 是一個工具，而你全程都在操作它。那個時代即將結束。 Loop engineering 是建立一個小型系統，讓它能自動尋找工作、交付給 Agent、檢查結果、記錄過程，並自行決定下一步。你只需要設計一次這個系統，之後系統就會自動為你對 Agent 下達 Prompt。 Addy Osmani 將其拆解為六個部分： ![本圖表比較了「Codex app」與「Claude Code」在自動化、工作樹、技能、外掛、子代理與狀態管理等六大核心原語（Primitive）上的實作差異。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/5436fca6ddc03dc0.png)
展開畫面重點
該表格詳細列出了六種軟體開發原語（Primitive）及其在「Codex app」與「Claude Code」中的具體應用方式： 1. **Automations（自動化）**： - Job in the loop：排程進行發現與分類（discovery + triage on a schedule）。 - Codex app：透過 Automations 分頁設定專案、提示詞、節奏與環境，結果存於 Triage 收件匣；使用 `/goal` 執行直到完成。 - Claude Code：支援排程任務、cron、`/loop`、`/goal`、hooks 以及 GitHub Actions。 2. **Worktrees（工作樹）**： - Job in the loop：隔離平行功能開發（isolate parallel features）。 - Codex app：每個執行緒內建工作樹（Built-in worktree per thread）。 - Claude Code：使用 `git worktree`、`--worktree`，並透過子代理（subagent）實現工作樹隔離。 3. **Skills（技能）**： - Job in the loop：編碼專案知識（codify project knowledge）。 - Codex app：透過 `SKILL.md` 定義 Agent Skills，以 `$name` 或隱式調用。 - Claude Code：同樣使用 `SKILL.md` 定義 Agent Skills。 4. **Plugins / connectors（外掛/連接器）**： - Job in the loop：連接工具（connect your tools）。 - Codex app：使用 Connectors (MCP) 以及用於發布的外掛。 - Claude Code：使用 MCP 伺服器與外掛。 5. **Sub-agents（子代理）**： - Job in the loop：構思與驗證（ideate and verify）。 - Codex app：在 `.codex/agents/` 目錄下以 TOML 格式定義。 - Claude Code：在 `.claude/agents/` 目錄下定義任務子代理，並支援代理團隊（agent teams）。 6. **State（狀態）**： - Job in the loop：追蹤進度（track what’s done）。 - Codex app：透過連接器使用 Markdown 或 Linear。 - Claude Code：使用 Markdown（`AGENTS.md`、進度檔案）或透過 MCP 連接 Linear。
Anthropic 的工程師現在每天合併的程式碼數量是 2024 年的八倍——儘管 Anthropic 自己也承認這「幾乎可以肯定誇大了實際的生產力提升」。 數字或許有爭議，但機制沒有：槓桿點已經從「輸入 Prompt」轉移到「設計執行 Prompt 的 Loop」上。 --- ## 02. 在動手建構前，先執行 4 條件測試。 Loop 必須在四個條件下才具備經濟效益。只要錯過其中一個，Loop 的成本就會高於其產出。這是 AlphaSignal 分析中誠實的觀點，也是大多數 X (Twitter) 討論串會略過的部分： ![這張流程圖說明了在決定是否要為自動化任務「建立循環（Build the loop）」前，必須先評估的四個關鍵條件。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/a8718602618ac368.png)
展開畫面重點
這張圖表標題為「So do you actually need one?」（你真的需要一個嗎？），旨在引導使用者判斷是否應將某項任務自動化。圖表分為四個主要評估步驟（01-04）： - 01: The task repeats（任務會重複執行），說明：Happens at least weekly（每週至少發生一次）。 - 02: Verification is automated（驗證已自動化），說明：Test, type check, build, linter（測試、型別檢查、建置、代碼檢查）。 - 03: Token budget absorbs the waste（Token 預算能吸收浪費），說明：Retries cost even when no ship（即使沒有產出成果，重試仍有成本）。 - 04: Agent has senior engineer tools（代理程式具備資深工程師工具），說明：Logs, repro env, run the code（日誌、重現環境、執行程式碼）。 若以上四項皆通過（Answer yes to all four），則進入「Build the loop」（建立循環）。 若未能滿足其中任何一項（Miss one box），則應維持「Manual prompt」（手動提示）。 圖表下方註記： - SOLID = all conditions pass（實線 = 所有條件通過） - DASHED = keep manual（虛線 = 維持手動） - Run the test before you build.（在建置前先執行測試。）
這四個條件簡單來說： - **任務必須重複發生**：Loop 的建置成本需透過多次執行來攤提。對於一次性工作，良好的 Prompt 更快且更便宜。如果工作不是每週都會發生，那你就不是在做 Loop，而是在執行一個只跑一次的腳本。 - **驗證必須自動化**：Loop 需要一個能在你不在場時判斷工作失敗的機制。例如測試套件、型別檢查器、Linter 或建置流程。如果沒有自動化檢查，你就得回到電腦前閱讀每一個 Diff——這正是 Loop 本應幫你省下的工作。 - **token 預算能承擔浪費**：Loop 會重複讀取 context、重試、探索。無論執行結果是否成功，這都會消耗 token。這項技術隨著預算規模擴大而展現優勢，這就是為什麼對於那些擁有幾乎免費 token 的人來說這顯而易見，但對使用計費方案的人來說卻顯得魯莽。 - **Agent 擁有資深工程師的工具**：例如 Logs、重現環境，以及執行它所寫程式碼並觀察錯誤的能力。沒有這些，Loop 就只是在盲目迭代。 --- ## 03. 誰是贏家，誰是輸家？Loop 偏好那些「花得起」的人。 經濟效益並非普世適用。那些稱 Loop engineering 為「顯而易見」的人，通常擁有無上限的 token 額度。 而對於那些每月只有 20 美元消費級方案，卻試圖在不觸發限制或收到驚人帳單的情況下執行繁重驗證 Loop 的人來說，這通常是魯莽的。 實際上，誰能真正受益： - 擁有重複性、機器可檢測的工作，且有預算執行它的團隊——例如持續的測試分類、依賴套件更新、Lint 與修復流程、在測試覆蓋率高的程式庫中自動建立 Issue-to-PR 草稿。 - 擁有強大測試套件的程式庫。如果初階工程師可以根據檢查清單完成任務，且測試套件能捕捉他們的錯誤，那麼 Loop 就很適合。 - 已經採用多 Agent 模式的非同步優先團隊。對於這些團隊來說，Routine 就是缺失的排程層。 誰現在應該跳過它： - 使用消費級方案的個人開發者——token 帳單會比生產力提升先到來。 - 在沒有自動化驗證的程式碼上工作的人。沒有實際檢查的 Loop，只是 Agent 在不斷地自我認同。 - 真正的瓶頸在於「審查能力」而非「輸入速度」的團隊。Loop 會產生更多程式碼；如果審查已經是瓶頸，這只會讓佇列更長。 對於一次性任務、探索性工作，或是任何「完成」與否取決於主觀判斷的工作，一個精準的 Prompt 仍然勝出。這篇文章最誠實的說法是：Loop engineering 是真實存在的，但大多數開發者目前還不需要它。 --- ## 04. 30 秒 Loop 檢查清單。 第 2 步的 4 條件測試是戰略決策，而這是戰術檢查——在你將特定任務轉化為 Loop 之前執行的檢查清單。 只要漏掉其中一項，就請維持手動 Prompt。 - 1. 任務每週至少發生一次。少於每週一次 → 建置成本永遠無法攤提。 - 2. 有測試、型別檢查、建置或 Linter 可以拒絕錯誤的輸出。沒有自動化閘門 → Agent 會給自己的作業打分數。 - 3. Agent 可以執行它所修改的程式碼。沒有重現環境 → 迭代就是盲目的。 - 4. Loop 有強制停止機制。例如 token 預算、迭代次數或時間限制。沒有這些，Loop 就會一直跑，直到有人發現帳單為止。 - 5. 在合併、部署或變更依賴套件前，有人類進行審查。任何不可逆的操作在執行前都需要人類批准閘門。 ![此圖表展示了 AI 代理（Agentic）運作的循環流程，包含收集背景資訊、執行動作、驗證結果，以及使用者介入的機制。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/f0da1c81eb4cb0dc.png)
展開畫面重點
該圖表描繪了一個「代理循環」（agentic loop），流程如下： 1. 起始點：使用者輸入提示（Your prompt）。 2. 循環核心（agentic loop）： - 收集背景資訊（Gather context） - 執行動作（Take action） - 驗證結果（Verify results） - 循環機制：若結果未達標，流程會從「驗證結果」回饋至「收集背景資訊」。 3. 終點：完成（Done）。 4. 使用者介入：使用者可以隨時中斷、引導或補充背景資訊（You: interrupt, steer, or add context），此介入動作會影響整個代理循環。
適合的初次 Loop 嘗試： - CI 失敗分類：每晚掃描失敗項目、分類原因、為簡單問題草擬修復 PR。 - 依賴套件更新 PR：每週掃描更新、測試相容性、開啟 PR。 - Lint 與修復流程：在每個 PR 開啟事件時，自動套用樣式修復。 - 難以重現的測試（Flaky test）重現：不斷循環直到理論通過測試。 - 在測試強大的程式碼上進行 Issue-to-PR 草稿，錯誤輸出會被測試套件拒絕。 不適合的初次 Loop 嘗試——這些需要人類親自處理： - 架構重構 - 驗證（Auth）或支付程式碼 - 生產環境部署 - 模糊的產品需求 - 任何「完成」與否取決於主觀判斷的工作 --- 第二部分 · 5 個建構模組 ## 05. 自動化（Automations）：心跳。 自動化是讓 Loop 成為真正的 Loop，而不是你只跑一次的任務。它們在排程、事件或觸發條件下啟動。它們是心跳——Loop 中的其他一切都依賴於它們。 在兩個關鍵工具中的呈現方式： - **Codex**：自動化分頁——選擇專案、設定 Prompt、設定頻率、選擇本地 checkout 或背景 worktree。找到問題的執行結果會進入 Triage 收件匣；沒找到問題的執行結果則會自動封存。 - **Claude Code**：組合成相同形狀的三個原語： `/loop` 用於工作階段範圍的頻率，Desktop 排程任務用於重啟後的存續，Routines 用於筆電關機後的雲端執行。搭配 Hook 處理生命週期事件。 自動化中區分「有效 Loop」與「昂貴 Loop」的兩個原語： - `/loop` 按頻率重新執行。當你想要無論狀態如何都進行定期檢查時使用。 - `/goal` 持續執行直到你寫下的條件真正達成。由一個獨立的小型模型檢查完成度，確保寫程式碼的 Agent 不是那個給自己打分數的 Agent。 ![這張圖表對比了使用與不使用 `/goal` 指令時，使用者與 Claude AI 互動流程的差異。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/a77138f83ea2c1d4.jpg)
展開畫面重點
這張圖表分為上下兩個區塊，展示了工作流程的優化： 1. **Without /goal — You Are the Loop (沒有 /goal — 你就是迴圈)** - 流程：You prompt (你提示) -> Claude works (Claude 工作) -> Claude stops (Claude 停止) -> You review (你審閱) -> You prompt again (你再次提示) -> Claude works (Claude 工作) -> Claude stops (Claude 停止) -> You review again (你再次審閱)。 - 說明：You are the bottleneck. Every turn requires your input to continue. (你是瓶頸。每一輪都需要你的輸入才能繼續。) 2. **With /goal — Claude Closes the Loop (使用 /goal — Claude 閉合迴圈)** - 流程：You set the goal (你設定目標) -> Claude works (Claude 工作) -> Evaluator checks (評估器檢查) -> (若 Done ✓) -> Goal cleared (目標達成)；(若 Not done) -> Claude starts next turn (Claude 開始下一輪) -> 回到 Claude works。 - 說明：You are removed from the loop. Claude works until the condition is met. (你被移出了迴圈。Claude 會一直工作直到條件滿足為止。) 畫面重點：此圖展示了透過設定明確目標（/goal），可以將使用者從重複的審閱與提示流程中解放出來，讓 AI 實現自動化的迭代工作。
這就是將「開發者 vs 檢查者」的分工應用於停止條件本身。 ```python > /loop 30m /goal All tests in test/auth pass and lint is clean. Scan src/auth for new failures, propose fixes in claude/auth-fixes, open draft PR when goal condition holds. ▲ Claude CronCreate(*/30 * * * * : auth quality loop) Stop condition: tests pass + lint clean (verified by checker) ✓ Scheduled. Will continue past intermediate completions until /goal condition is met by independent checker. ``` --- ## 06. Worktrees：不混亂的平行處理。 一旦你同時執行多個 Agent，檔案就會開始衝突。兩個 Agent 修改同一個檔案，就像兩個工程師在沒溝通的情況下提交相同的程式碼行一樣，會造成頭痛的問題。 Git worktree 解決了這個問題——在同一個儲存庫歷史記錄下，建立一個位於不同分支的獨立工作目錄，因此一個 Agent 的編輯內容絕對不會觸碰到另一個 Agent 的 checkout。 在兩個工具中的應用： - Codex 內建 worktree 支援——多個執行緒同時存取同一個儲存庫而不會互相干擾。 - Claude Code 直接公開 git worktree，透過 `--worktree` 旗標在獨立的 checkout 中開啟工作階段，並在子 Agent 上設定 `isolation: worktree`，讓每個輔助 Agent 都能獲得一個執行完畢後會自動清理的全新 checkout。 Worktrees 移除了機械性的衝突，但你仍然是上限。你的審查頻寬決定了你能同時執行多少個 Agent，而不是工具本身。 --- ## 07. Skills：專案知識寫一次，每次執行都讀取。 Skill 是讓你不再像金魚一樣，在每個工作階段都重複解釋相同專案 context 的方式。這兩個工具都使用相同的格式：一個包含 `SKILL.md` 的資料夾，裡面存放指令、metadata，以及選用的腳本、參考資料和 asset。 這對 Loop 特別重要：沒有 Skill 的 Loop 會在每個週期從零開始重新推導你的整個專案 context。有了 Skill，意圖是可以累積的。 慣例、建置步驟、「因為那次事件所以我們不這樣做」——這些寫在外面，每次執行都會被讀取。 ```python name: ci-triage description: Classify CI failures by root cause (env, flake, real bug, dependency, infra), draft fixes for the easy ones, escalate the rest. Trigger whenever a workflow run fails or on the morning triage loop. --- # CI triage skill ## Classification rules - env: missing secret, wrong env var, infra not provisioned. # human - flake: passes on retry without code change. # retry once, then file - bug: deterministic failure tied to recent commit. # draft fix - dependency: failure tied to a version bump. # draft rollback - infra: timeout, OOM, runner issue. # escalate ## Fix patterns - Auth tests → check src/auth/middleware first - Database tests → verify migration applied in CI env - E2E tests → check selectors against the latest UI snapshot ## Never do - Disable failing tests — always file as escalation instead - Modify CI config without human approval - Touch src/payments/ or src/billing/ (in claude/permissions.md) ## State Update STATE.md after each run: file paths checked, classifications, PRs opened, items escalated. ``` --- ## 08. Connectors：透過 MCP 讓 Loop 觸及你的真實工具。 一個只能看到檔案系統的 Loop 是非常侷限的。基於 Model Context Protocol (MCP) 建構的 Connector，讓 Agent 可以讀取你的 Issue 追蹤系統、查詢資料庫、呼叫 Staging API 或在 Slack 發送訊息。 ![Claude 介面中的「Connectors」設定視窗，展示了可與外部工具（如 Asana、Google Drive、Notion 等）整合的清單。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/ebde1f5973b899b5.jpg)
展開畫面重點
這是 Claude 的「Connectors」（連接器）設定視窗，旨在透過連結外部工具來增強 Claude 的功能。視窗標題為「Connectors」，副標題為「Unlock more with Claude when you connect your favorite tools. Manage connectors」。 介面分為「Web」與「Desktop extensions」兩個分頁，目前顯示的是「Web」分頁，並設有搜尋框。下方條列了多項可連接的工具，每個項目包含名稱、功能簡述以及操作按鈕（「+」代表尚未連接，「✓」代表已連接）： - Asana: Connect to Asana to coordinate tasks, projects, and goals (已連接) - Atlassian: Access Jira & Confluence from Claude (+) - Canva: Search, create, autofill, and export Canva designs from a prompt (+) - Cloudflare: Build applications with compute, storage, and AI (+) - Gmail: Draft replies, summarize threads, & search your inbox (+) - Google Calendar: Understand your schedule and optimize your time (已連接) - Google Drive: Find and analyze files instantly (已連接) - Intercom: AI access to Intercom data for better customer insights (+) - Linear: Manage issues, projects & team workflows in Linear (+) - Notion: Connect your Notion workspace to summarize, search, and move faster (+) - PayPal: Access PayPal payments platform using PayPal's MCP server (+) - Plaid: Monitor, debug, and optimize your Plaid integration (+) 畫面左側為 Claude 的側邊欄導覽列，包含新增對話、歷史紀錄、檔案庫與設定等圖示。
Codex 和 Claude Code 都支援 MCP，因此你為其中一個編寫的 Connector 通常可以直接在另一個使用。 這就是「說出修復方案的 Agent」與「能開啟 PR、連結 Linear Ticket，並在 CI 通過後通知頻道」的 Loop 之間的區別。 Connector 是 Loop 能在你的真實環境中採取行動，而不僅僅是告訴你「如果可以的話它會做什麼」的原因。 對 Loop 工作效益最高的 Connector 順序如下： - **GitHub**：讀取儲存庫、建立分支、開啟 PR、評論 Issue、對 Webhook 事件做出反應。這是任何程式碼 Loop 第一天就能獲得的最大勝利。 - **Linear 或 Jira**：隨著 Loop 進度更新 Ticket、將 PR 連結回 Issue、在驗證通過時自動關閉項目。 - **Slack**：發布分類結果、在需要升級處理時通知人類、總結隔夜的執行結果。 - **Sentry / 錯誤追蹤系統**：讓 Loop 調查即時警報，並為高頻錯誤草擬修復方案。 --- ## 09. Sub-agents：將開發者與檢查者分開。 Loop 中最有用的結構，莫過於將「負責撰寫的 Agent」與「負責檢查的 Agent」分開。 Osmani 的觀點非常精確：撰寫程式碼的模型「在給自己的作業打分數時太過寬容」。另一個擁有不同指令，有時甚至使用不同模型的 Agent，能捕捉到第一個 Agent 自圓其說的錯誤。 ![此圖展示了一個基於大型語言模型（LLM）的迭代式生成與評估工作流程。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/5021908935efd5ec.png)
展開畫面重點
該流程圖描述了一個自動化的反饋迴圈系統，包含以下組件與流程： 1. 輸入（In）：系統的起始點。 2. LLM Call Generator：負責生成解決方案（Solution）的模組。 3. LLM Call Evaluator：負責評估生成內容的模組。 4. 輸出（Out）：當解決方案被評估為「Accepted」（接受）後，流程結束並輸出結果。 5. 反饋迴圈：若解決方案未通過評估，系統會將「Rejected + Feedback」（拒絕與反饋）傳回給 Generator，進行修正與重新生成。
這就是 Anthropic 2024 年 12 月工程文章中提到的「評估者-優化者（evaluator-optimizer）」模式，只是換了個名字。一個模型生成，另一個批判，重複進行。這個在 2026 年爆紅的詞彙，其實在十八個月前就已經被記錄下來了。 Sub-agents 在兩個工具中的實現： - Codex 僅在你要求時才會產生 Sub-agents，它們同時執行，然後將結果匯總成一個答案。你在 `.codex/agents/` 中定義自己的 Agent 為 TOML 檔案——包含名稱、描述、指令、選用的模型和推理強度。 你可以讓你的安全性審查員使用高強度模型，而讓探索者使用快速的唯讀模型。 - Claude Code 在 `.claude/agents/` 中使用相同的 Sub-agents，並透過 Agent 團隊在彼此之間傳遞工作。 常見的分工：一個 Agent 負責探索，一個負責實作，一個負責根據規格進行驗證。 這在 Loop 中特別重要：Loop 在你沒看著的時候執行，因此一個你真正信任的驗證器是你敢於放手的唯一原因。 Sub-agents 會消耗更多 token，因為每個 Agent 都有自己的模型和工具呼叫——請將資源花在值得尋求第二意見的地方。 --- 第三部分 · 正確地建構，否則就不要建構 ## 10. 狀態檔案（State file）。Agent 會忘記，但檔案不會。 這聽起來簡單到不重要，但它實際上是每個有效 Loop 的脊椎。一個 Markdown 檔案、一個 Linear 看板、一個 JSON 狀態——任何存在於單一對話之外，記錄著「已完成」與「下一步」的東西。 為什麼這很重要：Agent 預設的記憶力很短。除非你寫下來，否則它們在這個工作階段學到的東西明天就會消失。 Osmani 的規則：Agent 會忘記，但儲存庫不會。沒有持久狀態的 Loop 每次執行都會重啟；有狀態的 Loop 則會從上次中斷處繼續。 ```json # Loop state · ci-triage ## Last run 2026-06-09 03:30 UTC · 7 failures classified, 3 fixes drafted, 4 escalated ## In progress - claude/fix-auth-token-refresh — tests passing locally, awaiting CI - claude/fix-flaky-payment-webhook — retry pattern applied, monitoring ## Completed today - claude/bump-axios-1.7.4 → merged (CI green, deps loop verified) - claude/lint-fix-pass-june-9 → merged ## Escalated to humans - src/billing/refund.ts — tests failing in 3 ways, root cause unclear - ci/staging-runner — infra timeouts, not a code issue ## Lessons learned (write here, not in chat) - 2026-06-08: PowerShell hits TLS 1.2 issue on this Windows runner. Use bash. - 2026-06-07: tests/e2e/checkout requires Stripe webhook secret in env. Skip if missing. ## Stop conditions met since last review - /goal “all tests pass + lint clean” achieved on commit 3a7b8c1 at 02:14 UTC ``` 狀態檔案存放位置的兩種模式： - **儲存庫中的 Markdown**：根目錄或 `.claude/` 下的 `STATE.md`。版本控制、簡單、Diff 可讀。最適合個人或小型團隊。 - **外部系統（Linear, GitHub Issues, 資料庫）**：跨儲存庫存續、可查詢、支援團隊層級的能見度。最適合需要多人共同檢視 Loop 運作情況的生產環境 Loop。 對於容易偏離目標的長時間執行 Loop，請將狀態檔案與高層級的「願景規格書」（例如 `VISION.md` 或 `AGENTS.md`）配對，讓 Agent 每次執行時重新讀取。狀態檔案告訴 Agent 它在哪裡，規格書則告訴它要去哪裡。 --- ## 11. 最小可行性 Loop（Minimum Viable Loop）。 如果你通過了第 2 步的 4 條件測試，請在進行任何複雜設計前，先建構出最小可行性的 Loop。四個部分，不要 swarm。 ![此圖展示了「最小可行循環」的四個關鍵步驟（自動化、技能、狀態文件、閘門），並列出其實際運行的衡量指標，其中每次接受變更的成本為 12.37 美元，拒絕率為 17%。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/4731ff7b4d813e19.png)
展開數據表（1）最小可行循環步驟
描述工具
01 One automationScheduled run, cadence, stop condition/loop · /goal
02 One skillProject context the agent would otherwise re-deriveSKILL.md
03 One state fileWhat is done and what is nextMarkdown / Linear
04 One gateTest, type check, or build fails bad workCAN SAY NO
展開數據表（2）每次接受變更的成本衡量
COST / ACCEPTEDACCEPTEDREJECT RATEMTTA (MIN)LEAD (HR)
指標值$12.3712817%14.26.8
這四個部分簡單來說： - **一個自動化**：按頻率觸發並在明確條件下停止的排程執行。使用 Claude Code 的 `/loop` 或 Codex 的自動化。當你希望它執行到特定條件達成時，搭配 `/goal` 使用。 - **一個 Skill**：單一 `SKILL.md`，儲存 Agent 否則會在每次執行時從零重新推導的專案 context。 - **一個狀態檔案**：記錄已完成與下一步的 Markdown 檔案或 Linear 看板。讓明天的執行能繼續而非重啟。 - **一個閘門**：自動拒絕錯誤工作的測試、型別檢查或建置。這是決定 Loop 是在幫你還是純粹在燒錢的部分。 順序很重要：先讓一次手動執行變得可靠。將其轉化為 Skill。將其包裝在 Loop 中。然後再進行排程。跳過步驟是 Loop 在生產環境失敗的原因。 真正重要的指標是「每次被接受變更的成本」——而不是消耗的 token、嘗試的任務數或排程的 Loop 數。如果你的變更接受率低於 50%，代表你正在做 Loop 本應幫你省下的審查工作，那麼這個 Loop 就是在虧錢。 --- ## 12. Ralph Wiggum Loop：安靜失敗的 Loop。 工程師 Geoffrey Huntley 記錄了這種失敗模式並為其命名。一個本應在完成時才發出完成 token 的 Agent，卻在工作完成一半時就發出，導致 Loop 在工作未完成時就退出。沒有硬性閘門，Loop 會安靜地失敗並持續消耗資源。 ![這是一張展示 AI 代理（Agent）自動化開發工作流程的循環圖。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/06d87c22c0e1507e.jpg)
展開畫面重點
該圖表描述了一個四階段的自動化開發循環： 1. **Start**：流程起始點。 2. **Agent reads prompt + repo state**：AI 代理讀取提示詞與儲存庫（Repository）當前狀態。 3. **Agent writes code/makes changes**：AI 代理編寫程式碼或進行變更。 4. **External check**：進行外部檢查。 在檢查階段後，系統會進行判斷（Pass?）： - 若結果為「Yes」，則執行 **Exit Loop**（退出循環）。 - 若結果為「No」，則回到 **Start**（重新開始循環）。 圖表中央有一個藍色的星狀圖示，象徵 AI 核心處理單元。
Ralph Wiggum Loop 發生在以下情況： - **沒有真正的驗證器**：只是要求第二個 Agent「審查」，沒有客觀訊號。兩個樂觀主義者互相認同。 - **軟性完成條件**：由 Agent 的主觀判斷定義「完成」，而非測試、建置或型別檢查。 - **沒有強制停止**：Loop 持續執行直到外部因素終止它（速率限制、你發現了），而不是直到成功被驗證。 解決方案是第 11 步的閘門——一個能客觀判定工作失敗的機制。測試通過或失敗、建置成功或失敗、Linter 回傳 0 或非 0。而不是一個有「意見」的驗證器。 其他值得注意的失敗模式： - **長工作階段中的目標偏移**：每次總結步驟都會有資訊損失；「不要做 X」的限制在第 47 輪時就會消失。緩解方式：每次執行時重新讀取 `VISION.md` 或 `AGENTS.md`。 - **自我偏好偏差**：撰寫程式碼的 Agent 在給自己打分數時太過寬容。緩解方式：使用一個與開發者推理過程完全隔離的獨立驗證 Sub-agent。 - **Agent 的懶惰**：Loop 在部分完成時就宣稱「足夠了」。緩解方式：使用 `/goal` 並搭配由全新模型檢查的客觀停止條件。 --- ## 13. 理解債（Comprehension debt）與認知投降。 這種失敗模式會隨著 Loop 變得越強大而越尖銳。Osmani 的文章中提到了兩個風險： - **理解債**：Loop 交付你未親手撰寫的程式碼速度越快，儲存庫內容與你理解之間的差距就越大。真正讓你痛苦的帳單不是 token 帳單，而是某天你需要除錯一個團隊中沒人讀過的系統時。 - **認知投降**：停止形成自己的觀點，直接接受 Loop 回傳結果的衝動。當你帶著判斷力設計 Loop 時，它是解藥；當你為了逃避思考而設計它時，它就是催化劑。相同的動作，相反的結果。 緩解方式並非技術性的： - **閱讀 Diff**：如果你不閱讀 Loop 交付的內容，你就是在以複利租借理解債。 - **抽查閘門**：挑選幾個 Loop 開啟的 PR，驗證批准它們的測試是否真的捕捉到了你在意的失敗模式。閘門會腐爛。 - **禁止 Loop 進行架構工作**：將其限制在小型、機器可檢測的變更上。一旦你讓它觸及需要判斷的工作，理解債就會加速累積。 - **與隊友共同設計 Loop**：在設計 Loop 時多一雙眼睛，可以捕捉到那些 Loop 永遠會利用的盲點。 --- ## 14. 安全稅：無人看管的 Loop 就是無人看管的攻擊面。 一個無人看管的 Loop，同時也是一個無人看管的攻擊面。 你的 Loop 必須防禦的威脅模型： - **生成的程式碼未經審查就發布**：Loop 開啟 PR 的速度比人類閱讀的速度快。如果沒有包含安全檢查（SAST、依賴套件審計、機密掃描）的閘門，不安全的程式碼會自動合併。 - **Skill 作為注入向量**：一個自動安裝 Skill 的 Loop，會繼承隱藏在 Skill 描述中的所有 Prompt 注入風險。安裝前請審計 Skill 來源。 - **Log 中的憑證**：長時間執行 Loop 時的除錯 Log 會將機密散佈到你未監控的 Log 中。在生產環境的 Loop 中停用詳細 Log；並對 Log 內容進行去識別化處理。 - **權限範圍蔓延**：一個以唯讀權限測試的 Loop，為了方便被「順手」加上一個寫入權限，之後卻從未重新審計。請每 30 天重新審計權限。 --- ## § 將 Loop 變成錢坑的錯誤 - **未執行 4 條件測試就建構 Loop**：第 2 步存在是有原因的。大多數開發者至少會錯過一個條件。 - **沒有客觀閘門**：要求第二個 Agent「審查」而沒有測試、型別檢查或建置，只是多了一個樂觀主義者。 - **同一個 Agent 既寫又驗**：自我偏好偏差。開發者給自己的作業打分數，永遠是「A+」。 - **沒有狀態檔案**：明天的執行從零開始，而不是從上次中斷處繼續。 - **模糊的停止條件**：「看起來不錯就完成」永遠無法成立。請使用測試、型別檢查或建置通過作為標準。 - **沒有 token 預算上限**：Loop 會重複讀取 context 並重試。沒有上限，野心勃勃的 Loop 會消耗你預期 5-10 倍的 token。 - **在消費級方案上執行繁重的驗證 Loop**：token 帳單或速率限制，總有一個會找上你。 - **自動安裝社群 Skill**：在 17,022 個審計過的 Skill 中，有 520 個會洩漏憑證。安裝前請閱讀原始碼。 - **將 Loop 用於需要判斷的工作**：架構、驗證、支付、模糊的產品決策。讓 Loop 專注於 Lint 與修復，而不是策略。 - **不閱讀 Diff**：以複利累積理解債。某天你需要除錯一個沒人讀過的系統時，付出的代價遠高於 token 費用。 --- ## 結論： ## 槓桿點轉移了，你的工作也是。 過去兩年，與 Coding Agent 合作的槓桿點在於 Prompt。更好的 Prompt、更好的 context、更好的單次輸出。 那個階段即將結束。Agent 已經足夠強大，下一個槓桿點在更高一層：決定它們做什麼、何時做、用什麼閘門，以及在執行之間保留什麼狀態的系統。 但這個故事最誠實的版本並不是「每個人都應該趕快去建構 Loop」。大多數開發者還不需要——除非任務是重複的、驗證是自動化的、預算能承擔浪費，且 Agent 擁有資深工程師的工具。 只要錯過一個條件，Loop 的成本就會高於其產出。 如果你通過了測試，請從小規模開始。一個自動化、一個 Skill、一個狀態檔案、一個閘門。先讓一次手動執行變得可靠，將其轉化為 Skill，包裝在 Loop 中，然後再進行排程。順序很重要。跳過步驟，你就是在為一個沒人理解的系統付費。 Cherny 的觀點並不是工作變簡單了，而是槓桿點轉移了。建構 Loop，並保持工程師的專業。 ## 標籤 Loop Engineering, Agent, 教學資源, 自動化