Anthropic 工程師利用 AI 迴圈將每日程式碼產出提升 8 倍

Anthropic 的工程師每月薪資高達 8 萬美元。這些工程師現在每天合併的程式碼數量是去年的 8 倍。這並非因為模型變得更聰明，而是因為他們不再手動向 Claude 發送提示詞（prompt），而是開始構建能代為發送提示詞的系統。

Anthropic 旗下 Claude Code 的負責人 Brian Cherny 表示：「我不再親自向 Claude 發送提示詞了。我運行著一些迴圈（loops），由它們來提示 Claude 並決定要做什麼。我的工作是編寫這些迴圈。」

大多數開發者讀到這裡時，並不清楚這在實務上意味著什麼。讀完這篇文章後，你就會明白——而且你將擁有在本週末構建第一個迴圈所需的一切。

什麼是真正的迴圈

提示詞（prompt）是一項單一指令。而迴圈（loop）則是一個 AI 會持續努力直到達成目標的過程。

兩者的區別在於誰在駕駛。使用提示詞時，你必須手動推動 Claude 完成每一個步驟。使用迴圈時，你只需定義一次目標，系統就會自行執行完整週期——尋找任務、執行任務、檢查結果並決定下一步。這一切都不需要你親自坐鎮。

1提示詞      |  你輸入，Claude 回答，你再次輸入
2迴圈        |  系統尋找任務，Claude 執行，
3            |  系統檢查結果，重複直到完成

每個真正的迴圈都有五個階段：

1探索 (Discover)    |  找出需要做的事
2規劃 (Plan)        |  決定如何執行
3執行 (Execute)     |  完成工作
4驗證 (Verify)      |  對照目標進行檢查
5迭代 (Iterate)     |  未完成？將結果反饋回去並重新開始

其中三個階段負責所有實際工作。

「驗證」是核心。 如果沒有對結果進行真正的檢查，你就沒有迴圈——你只是擁有一個不斷自我認可的 Agent。檢查必須是客觀的：一個通過或失敗的測試、一個能編譯或不能編譯的建置、一個回傳零或非零值的 linter。而不是要求另一個 Agent 去「審查」。兩個樂觀主義者互相認同並不是驗證。

「狀態」是迴圈學習的關鍵。 在每一輪執行中，AI 必須記住它已經嘗試過什麼，否則它會永遠重複同樣的錯誤。一個真正的迴圈會在對話之外保留記錄——什麼已完成、什麼失敗了、下一步是什麼。Agent 在對話階段之間會遺忘，但檔案不會。

「停止條件」是維持系統正常的關鍵。 沒有出口的迴圈會一直運行，直到成功、崩潰或耗盡你的預算。每個嚴謹的迴圈都有兩種停止方式：成功，以及強制上限。沒有這個機制，你等於構建了一台會在無聲中扣光你預算的機器。

構建前的 4 條件測試

只有當以下四個條件皆成立時，迴圈才值得投入成本。若缺少任何一項，請繼續使用手動提示詞。

1條件 1  |  任務至少每週重複一次
2        |  頻率低於每週 - 設置成本永遠無法回本
3
4條件 2  |  有東西可以自動拒絕錯誤輸出
5        |  例如測試、建置、linter、型別檢查
6        |  沒有自動化門檻 - 你又得回頭審查每一個差異檔
7
8條件 3  |  Agent 可以從頭到尾完成工作
9        |  不會在任務中途把一半工作丟回給你
10
11條件 4  |  「完成」是客觀的，而非主觀判斷
12        |  如果品質取決於個人品味，人類依然勝出

適合的首批迴圈：

1CI 失敗分類      |  每晚進行，分類失敗原因，草擬修復方案
2依賴套件更新     |  每週進行，掃描更新，開啟 PR
3Lint 與修復流程  |  在每個 PR 上，自動套用風格修正
4Issue 轉 PR 草稿 |  在測試覆蓋率高的程式碼庫上執行

不適合的首批迴圈——請保持人類參與：

1架構重寫        |  需要主觀判斷，迴圈會產生偏差
2身份驗證或支付程式碼 |  不可逆的錯誤代價太高
3生產環境部署     |  需要人類審核關卡
4模糊的產品需求   |  「完成」定義不明確

五大構建模組

每個運作中的迴圈都由五個部分組成。Claude Code 具備這五項功能。

1 - 自動化（心跳）

這就是讓迴圈成為真正的迴圈，而不僅僅是你執行過一次的任務。觸發器會根據排程或事件啟動，將任務交給 Claude，並在無需你親自檢查的情況下帶回結果。

1/loop     |  按節奏重複執行提示詞
2/goal     |  持續運行直到你寫下的條件為真
3hooks     |  在 Agent 生命週期的特定點觸發指令
4cron      |  透過 GitHub Actions 在你闔上筆電後運行

最重要的是 /goal。一個獨立的小型模型會檢查條件是否滿足——這樣寫程式碼的 Agent 就不是評分的那一個。

1/loop 30m /goal "test/auth 中的所有測試通過且 lint 檢查乾淨。"
2掃描 src/auth 的失敗項目，草擬修復方案，在目標達成時開啟 PR。

2 - 技能（將專案知識寫入一次）

「技能」是你不再需要在每次對話中重複解釋相同專案背景的方式。一個 SKILL.md 檔案包含了迴圈在每次執行時都會讀取的指令、慣例和規則。

沒有技能，迴圈在每個週期都會從零開始重新推導你的整個專案。有了技能，意圖就會累積——慣例、建置步驟、過去發生的錯誤——寫入一次，永久讀取。

1skills/
2  ci-triage.md   - 分類規則、修復模式、升級標準
3  frontend.md    - Tailwind、Next.js、SEO、無障礙規則
4  security.md    - 驗證模式、輸入驗證、禁止觸碰清單
5  deps.md        - 更新規則、相容性檢查、回滾模式

自動化流程會按名稱呼叫技能。重複性的工作保持可維護性，而不是在沒人更新的排程中腐爛。

3 - 子 Agent（將開發者與審查者分開）

這是任何迴圈中最有用的結構。將負責編寫的 Agent 與負責檢查的 Agent 分開。

編寫程式碼的模型在評估自己的工作時太過寬容。另一個帶有不同指令——有時是更強大模型——的 Agent 可以捕捉到前者自我說服忽略的問題。

1開發 Agent (Maker)     |  快速、便宜的模型 - 探索、實作、草擬
2審查 Agent (Checker)   |  強大模型、高成本 - 審查、驗證、拒絕

1.claude/agents/
2  explorer.md      |  唯讀、快速模型，找出需要做的事
3  implementer.md   |  編寫修復程式碼，執行測試
4  reviewer.md      |  安全性審計、程式碼品質、客觀門檻

一個模型，三個專家。當你不在監控時，迴圈會持續運行，而驗證者是你真正可以放心離開的原因。

4 - 連接器（讓它採取行動，而非僅僅建議）

這區分了「說出修復方案」的迴圈，與「開啟 PR、連結工單並在 CI 通過後通知 Slack」的迴圈。

1GitHub    |  讀取儲存庫、建立分支、開啟 PR、回應 Webhook
2Linear    |  更新工單、連結 PR、在驗證通過時關閉項目
3Slack     |  發布分類結果、在需要升級時通知人類
4Sentry    |  調查即時警報、為高頻率錯誤草擬修復方案

沒有連接器，迴圈只能描述它「會做什麼」。有了連接器，它就能直接執行。

5 - 狀態檔案（Agent 會遺忘，但檔案不會）

這部分聽起來簡單到不重要，卻是每個運作中迴圈的脊椎。這是一個在對話之外的 Markdown 檔案，記錄了已完成、失敗以及下一步的內容。

1# 迴圈狀態 - ci-triage
2
3## 上次執行
42026-06-09 03:30 UTC - 7 個失敗項目已分類，3 個修復方案已草擬，4 個已升級
5
6## 進行中
7- claude/fix-auth-token-refresh - 本地測試通過，等待 CI
8
9## 今日已完成
10- claude/bump-axios-1.7.4 - 已合併，CI 通過
11
12## 已升級至人類處理
13- src/billing/refund.ts - 測試在 3 個方面失敗，根本原因不明
14
15## 經驗教訓
16- 2026-06-08: PowerShell 在 Windows runner 上遇到 TLS 問題。改用 bash。
17- 2026-06-07: tests/e2e/checkout 需要 Stripe webhook 密鑰。若缺失則跳過。

明天的執行會讀取此檔案並繼續。沒有它，每次執行都會從零開始。

真正的迴圈長什麼樣

CI 失敗分類是最好的首批迴圈之一，因為驗證是自動化的，且輸出錯誤的風險很低。

1觸發器     |  每晚 3 點或 CI 失敗事件觸發
2技能       |  ci-triage.md
3狀態讀取   |  STATE.md - 昨天失敗了什麼，修復了什麼

迴圈運行過程：

1步驟 1  |  透過連接器從 GitHub 讀取 CI 失敗項目
2步驟 2  |  分類每個項目：環境 / 偶發錯誤 / Bug / 依賴 / 基礎設施
3步驟 3  |  針對每個可修復的失敗 - 開啟工作區，派遣開發 Agent
4步驟 4  |  審查 Agent 對照測試與安全規則檢查修復方案
5步驟 5  |  門檻通過 - 開啟 PR 並連結 Linear 工單
6步驟 6  |  門檻失敗 - 升級至人類分類收件匣
7步驟 7  |  更新 STATE.md
8步驟 8  |  發布過夜總結至 Slack

早上醒來，你會看到 Slack 訊息、一個只有棘手問題的分類收件匣，以及一組已經通過自動化審查的 PR。你不需要手動提示任何一個步驟。

跨業務整合的迴圈

最強大的版本不是單一迴圈，而是多個迴圈寫入共享的信號系統，讓它們相互學習。

在 SuperDesign，他們的迴圈涵蓋了支援、SEO、產品增長和廣告。每個迴圈都有自己的觸發器和工作流程，但它們都寫入同一個共享的信號儲存庫。

支援迴圈注意到有 5 位用戶詢問如何匯出資料。它建立了一個信號：

1類型: 信號
2標題: 匯出功能太難找
3頻率: 5
4類別: 摩擦點
5標籤: [回饋, 定價, 轉換]

SEO 迴圈注意到一個頁面流量很大但轉換率很差，於是建立了另一個信號。產品增長迴圈讀取這兩個信號並結合分析數據，發現匯出功能的摩擦點比原始數據顯示的更嚴重——因為現在有兩個獨立來源確認了同一個問題。廣告迴圈發現了關鍵字缺口，並直接將其餵給 SEO 迴圈。

1支援迴圈   |  發現摩擦點，寫入信號
2SEO 迴圈   |  發現內容缺口，寫入信號
3產品迴圈   |  讀取兩個信號，識別優先級
4廣告迴圈   |  發現關鍵字缺口，餵給 SEO 迴圈

這些迴圈都不是孤立的自動化。它們基於業務學習到的共享知識庫運作。每個迴圈都讓其他迴圈變得更聰明。這就是複利效應。

沒人警告你的失敗之處

Ralph Wiggum 迴圈。 一個本應在完成時才發出信號的 Agent，卻在半途就發出信號。迴圈在工作完成一半時退出，卻持續運行並計費，卻什麼也沒產出。解決方案：一個能客觀判定工作失敗的硬性門檻，而不是「看起來不錯」的軟性判斷。

長對話中的目標漂移。 隨著對話輪數增加，限制條件會在第 47 輪時因為上下文總結而消失。解決方案：一個常駐的 AGENTS.md，讓 Agent 在每次執行開始時重新讀取。

理解債務。 迴圈產出你未編寫的程式碼速度越快，現有程式碼與你理解之間的差距就越大。最痛的帳單不是 Token 費用，而是當你需要除錯一個團隊中沒人讀過的系統時。解決方案：閱讀迴圈開啟的每一個差異檔。

認知投降。 停止形成觀點並接受迴圈返回的任何結果的衝動。當你帶著判斷力去做時，設計迴圈是解藥；當你為了逃避思考而做時，它就是催化劑。同樣的動作，結果截然不同。

複合的 Token 成本。 每次迴圈迭代都會重新讀取完整上下文，且堆疊會隨著每一輪增加。追蹤每次已接受變更的成本。若接受率低於 50%，迴圈的成本將高於其節省的價值。

真正有效的建置順序

每個能在生產環境中存活的迴圈，構建方式都一樣：

1步驟 1  |  先確保「一次」手動執行是可靠的
2步驟 2  |  將其轉化為技能 - 將指令儲存在 SKILL.md 中
3步驟 3  |  用迴圈包裝技能 - 加入門檻和停止條件
4步驟 4  |  最後再設定排程

在你還沒手動使其可靠之前就設定排程，正是迴圈在你睡覺時崩潰的原因。先證明一次，強化它，然後再自動化。

重要的指標不是消耗的 Token 或嘗試的任務數，而是「每次已接受變更的成本」。如果迴圈給你十個結果，而你拒絕了六個，那你就是在做它本應為你節省的審查工作。

已經發生的轉變

在 2024 年，槓桿在於提示詞。更好的提示詞、更好的輸出、更好的開發者。在 2026 年，槓桿高了一層——在於決定 Claude 做什麼、何時做、使用什麼門檻以及在執行之間保留什麼狀態的系統。

Anthropic 的工程師每天合併的程式碼數量是以前的 8 倍，不是因為他們找到了更好的方式向 Claude 提問。而是因為他們停止提問，開始構建能代為向 Claude 提問的系統——持續不斷、通宵達旦，在他們睡覺時運行。

迴圈並沒有讓工作變簡單，它改變了工作發生的地點。從輸入提示詞轉變為設計輸入提示詞的系統。從握住工具轉變為建造工廠。

大多數開發者會繼續手動輸入提示詞，並納悶為什麼差距越來越大。少數人會花一個週末構建他們的第一個迴圈——一個自動化、一個技能、一個狀態檔案、一個門檻——然後就再也回不去了。