迴圈工程：在驗證成本低廉之處，迴圈才能取勝

打造 Claude Code 的工程師 Boris Cherny，白天會同時開著五到十個會話、跑著數百個代理，每晚則有數千個代理運行。²上週，當一段他說「我已經不再對 Claude 下提示了……我的工作是寫迴圈」的影片在 X 上瘋傳時，多數評論都把這句話當成對自主軟體開發的預言；幾天之內，Addy Osmani 便以此為名提出了一門學問：迴圈工程（loop engineering）。⁷我把影片背後那三場演講的完整逐字稿全部拉了出來。逐字稿說的是一個更平靜的故事，而這個平靜的版本，才是值得在其上建構的：Cherny 真正點名的每一個迴圈，都有一個機器可以免費檢查的成功條件。決定什麼能自動化的，是驗證成本，而非迴圈本身的構造。我從二月起就在正式環境中跑迴圈，我的日誌與逐字稿不謀而合——其中包括兩次讓我以慘痛方式學會這個道理的事故。

摘要 / 重點整理

• 這句瘋傳的話出自 Cherny 在 Acquired Unplugged 的訪談，他在其中把迴圈定位為一條連續軸線上的下一步：從打孔卡到組合語言，再到高階語言，再到下提示。¹他給這個轉變定了很短的賞味期：「接下來幾個月，或許延續到今年剩下的時間。」¹
• 這套機制刻意設計得平淡無奇。在 Sequoia 的演講中，Cherny 把 /loop 描述為 Claude 用 cron 排定一個重複執行的作業。²他點名的迴圈負責看顧 pull request、維持 CI 健康，並每隔 30 分鐘把 Twitter 上的回饋分群。²
• 這些迴圈每一個都是維護性質的。每一個都有機器可檢查的終止狀態：CI 綠燈、PR 已重定基底、回饋已分群。他點名的範例中，沒有一個是在無人看管下打造新功能。
• 寫迴圈這份工作本身正在溶解進模型裡。Cherny 表示，較新的模型會主動發起迴圈，而他把使用者端構造迴圈一事稱為「一個產品設計問題」，意味著「我做得不夠好」。⁵
• 迷因底下那項持久的技能：判斷什麼東西在無人看管下自動化是安全的。這項判斷是對「可驗證性」的衡量，並且在迴圈語法消失之後，仍會留在你身上。

他到底說了什麼

人人轉發的那段影片，出自一場 Acquired 的現場訪談。Cherny 用家族史鋪陳這句話：他的祖父在蘇聯用打孔卡寫程式，他的父親寫組合語言，並且「會因為我寫 Python 而取笑我」。接著就是那段廣為流傳的內容：

「這某種程度上就是程式設計的本質：抽象層級總是往上走……我一年前寫程式的方式，是在 IDE 裡靠某種自動補完寫程式碼。到了 11 月，我把 IDE 解除安裝了，因為我根本沒在用它……那時候，我大概同時跑著五到十個 Claude，而我的『寫程式』就是對 Claude 下提示去寫程式碼。現在又升級了……我已經不再對 Claude 下提示了。我有一些正在運行的迴圈。是它們在對 Claude 下提示，並且自己摸索該做什麼。我的工作是寫迴圈。」¹

完整的 Acquired Unplugged 訪談；迴圈那一段從 11:14 開始。

完整逐字稿裡有兩個細節，從未進入那些剪輯片段。其一，Cherny 親自為這個轉變定下時間：迴圈是「接下來幾個月，或許延續到今年剩下的時間」我們會看到的東西。¹他描述的是一個階段，而非終點。其二，給任何想追溯這場討論源頭的人一個提醒：好幾則瘋傳的貼文把迴圈這段內容歸到他那集長達一小時的 Y Combinator podcast。我查過那一集的完整逐字稿，裡頭完全沒有提到迴圈；那集談的是這項產品的緣起與子代理。⁶真正的內容存在於 Acquired 訪談，以及一場 24 分鐘的 Sequoia 演講中。

一個迴圈就是一個 cron 作業

Sequoia 的演講提供了機制，而這些機制刻意做得很平淡：

「它的全部，就是讓 Claude 用 cron 為未來某個時間點排定一個作業，而且是重複作業。它可以每分鐘、每五分鐘、每天執行一次。」²

Sequoia 演講補上了瘋傳片段略過的每一個機制細節；迴圈段落從 7:56 開始。

Cherny 跑著數十個這樣的迴圈。他點名的有：一個看顧他 PR 的迴圈（修 CI、自動重定基底）、一個維持 CI 健康的迴圈（它會修復不穩定的測試），以及一個每 30 分鐘從 Twitter 抓回饋並分群的迴圈。²五月在 Anthropic 的 Code with Claude 活動上發表的 Routines，把同一套模式搬到了伺服器端，讓迴圈即使在筆電闔上後仍能存活。²替主題演講做即時部落格直播的 Simon Willison，記下了 Anthropic 自己採用的說法：Routines 是「高階提示」。¹²Cherny 數個月來一直對外表示，/loop 和 /schedule 是這項產品中最強大的兩個功能；他的經典入門範例，是一個每五分鐘看顧 PR 的迴圈。¹¹

這套模式有個更粗糙的祖先。Geoffrey Huntley 的 Ralph Wiggum 技巧，用他自己的話說，「Ralph 就是一個 Bash 迴圈」：一個 while true，永無止盡地把同一份提示檔案餵給代理，而進度則透過檔案與 git 歷史在每次迭代之間持續保存。⁹Anthropic 如今已把 Ralph 作為官方外掛推出，它會攔截代理試圖結束的動作，並反覆重新餵入提示，直到出現某個完成字串，或撞到迭代次數上限為止。⁹The Register 證實 Cherny 本人也使用 Ralph，並引述了 Huntley 對這套經濟學走向何方的警告：新創公司會用這項技巧複製既有的 SaaS 事業並削價競爭，因為代理式編程的成本大約是每小時 10 美元。¹⁰這條血脈之所以重要，是因為它顯示了這個概念真正的年紀：迴圈是計算領域中最古老的控制結構，這個構造本身毫無新意可言。¹⁵

他點名的每一個迴圈都是維護性質

這裡就是那場討論略過的觀察。再把 Cherny 的迴圈列一次，看看它們的終止狀態：

每一個迴圈，要嘛有機器可檢查的成功條件，要嘛產出的內容即使出錯也毫無代價。他點名的範例中，沒有一個是「趁我睡覺時把功能做出來」。這位每晚跑著數千個代理的人，把他自己的個人自動化描述為：修 CI、重定基底，以及回饋分流。

那個看似反例的例子，反而證明了這條規則。Anthropic 自家的工程團隊，讓 16 個代理在無限迴圈中跑了兩週，產出了一個 10 萬行、以 Rust 寫成的 C 編譯器，運算成本約 2 萬美元。⁸編譯器是軟體中最可驗證的單一產物：一個由各種程式組成的龐大測試套件，要嘛能正確編譯並執行，要嘛不能。團隊挑了一個驗證幾乎免費的目標，而即使如此，主持這項實驗的 Nicholas Carlini 仍寫道，程式設計師部署自己從未親自驗證過的軟體，是「一項真切的隱憂」。⁸

Addy Osmani 那篇為這門學問命名「迴圈工程」的文章，從設計這一側落到了同樣的限制上：「一個無人看管運行的迴圈，也是一個無人看管犯錯的迴圈。」⁷他提出的架構（獨立的驗證者代理，讓製作者永遠不替自己的工作打分數），正是試圖在驗證不會自然發生之處，人工製造出低廉的驗證。⁷

我自己的迴圈教會我的事

我在二月寫過我那套通宵運行的代理系統，當時這項技巧比較體面的稱呼還是個《辛普森家庭》的梗。¹⁶自那之後，在我的環境裡存活下來的迴圈，全都收斂到同一種形狀，而失敗的那些，教會我的比成功的那些還多。

存活下來的，都是「檢查」形狀的。一個夜間迴圈會讀取當天的提交、把動到的檔案對應到上線的 URL、載入每一個受影響的頁面，並連同載入時間回報通過或失敗。一個資安迴圈會通宵監看各個端點，並寫出一份早晨簡報。一個爬蟲迴圈會讀取 Googlebot 與 Bingbot 在我各個網站上的活動，回報索引漂移。這些迴圈沒有一個會「創造」任何東西。每一個都是觀察、與預期狀態比對，然後回報。當其中一個出錯，代價只是一份過時的報告，而非一個壞掉的產品。早晨的閱讀只需幾分鐘，因為每一項的產出都是二元的：通過、失敗、看這裡。

失敗的那些，是會「動手」的迴圈。一個會自動為平行代理建立 git worktree 的隔離功能，兩度刪掉了它自行判定為可棄置的暫存目錄；這套自動化的波及範圍，涵蓋了它既未建立、也不理解的檔案。一個排程的快取清除，曾經在相對於部署的錯誤順序下執行，導致搜尋引擎爬蟲花了 11 個小時，對實際存在的頁面收到 404，因為清除動作在來源伺服器送出替換內容之前，就先把正確的快取回應驅逐掉了。¹⁶這兩次失敗都不是出自壞掉的模型。兩次都出自我把寫入權限授予了一個我尚未把前置條件釘死的迴圈。如今每一個都加上了防護：worktree 自動化已被全面封鎖，而清除動作只有在部署驗證通過之後才會執行。我從中萃取出的通則是：一個只讀的迴圈需要的是排程；一個會寫入的迴圈，則需要先有一份排序證明，以及一道波及範圍的限制，才配得上排程。

這條規則也解釋了 Cherny 那套做法中，人們最難以置信的部分。「現在其實我大部分的工作都是用手機做的，」他說，他透過 Claude app 裡的程式碼分頁來運行會話。²手機是個審查程式碼的糟糕地方，卻是個閱讀通過／失敗報告的好地方。這個用手機的說法，骨子裡其實是一個關於驗證的說法：他的迴圈所發出的產出，清楚到足以讓人一眼接受或拒絕——而這唯有在迴圈開始運行之前就先設計好成功條件時，才有可能做到。

驗證成本的階梯

如果這個論點成立，那麼選擇要自動化什麼，就化約為一個問題：誰來驗證結果，而那次驗證的成本是多少？以下是我在任何任務取得排程之前所用的階梯。

決定一切的是第二欄，而任務難度從未出現在其中。一個有免費驗證者的困難任務（那個不穩定的測試），會比一個有昂貴驗證者的簡單任務（一行需要人核可的文案改動）更早自動化。Cherny 的迴圈、Anthropic 的編譯器，以及我那些存活下來的迴圈，全都坐落在這道階梯的上半部；而瘋傳的評論假設的是下半部。

無論規模大小，能通過這道階梯而存活下來的形狀，看起來都像同一種「監督者」模式：

一個配得上排程的迴圈的解剖圖。驗證者畫得比較粗，因為它是那個承重的方塊：把它拿掉，迴圈照樣會跑，但沒人知道它做了什麼。

最小的、值得一跑的迴圈，是唯讀的、能自我驗證的、可一眼看完的——這讓它今天就能安心寫下，明天看著它運行則無聊到不行：

# Nightly site check: observes and reports, never edits.
# Run it under a permission mode that blocks writes outside reports/.
while true; do
  claude -p "Read today's commits. For each changed file that maps to a live
    page, fetch the staging URL and confirm it returns 200 and renders its
    headline. Append PASS or FAIL per page, with the reason, to
    reports/site-check-$(date +%F).md. Write nothing outside reports/."
  sleep 86400
done

在 Claude Code 內部，同一個迴圈只需一行：/loop 24h 後面接上指令。晉升是之後的事。等報告已經無聊地跑了一個月，這個迴圈才取得了被考慮晉升到階梯下一階的資格——不會更早。

剩下來的那份工作

Sequoia 演講中最奇特的一段，反而拆穿了它所催生的那個迷因。Cherny 說，較新的模型開始在無人要求下自行發起迴圈：他要求做一次資料查詢，模型注意到資料會隨時間變化，於是提議每 30 分鐘產出一份定期報告，並自行把報告接進 Slack。⁵他的結論是：「該怎麼把工具拿得更好，不是使用者的責任……這其實是個產品設計問題，而我做得不夠好。」⁵懷疑者在 X 上提出的那個無窮回退論證（如果人類今天寫迴圈，模型明天就會寫迴圈），結果竟是 Anthropic 的路線圖，而且由這個迷因本人親口承認。

他講得更深：「隨著模型變得更好，代理框架某種程度上變得沒那麼重要了，」他預測，隨著對齊改善，權限模式、提示注入防禦，以及人類介入的檢查點都會淡出。³這筆交易我只認一半。安全的鷹架或許會縮小。但依他自己的說法，編排的鷹架正在變成這份工作的全部：Anthropic 工程師的代理，會趁主人工作時透過 Slack 彼此協調，而且「公司裡再也沒有任何手寫的程式碼。所有的 SQL 都是模型寫的。」⁴總得有人決定那些代理可以碰什麼、什麼算是完成，以及當兩個代理意見相左時該怎麼辦。那個做決定的層，才是真正的代理介面，而 cron 只是其中容易的部分。

所以，那項持久的技能不是迴圈語法——模型已經在吸收它了；也不是下提示——迴圈早就把它吸收掉了。那項持久的技能，是坐落在這兩者底下的那個判斷：判定什麼東西在無人看管下自動化是安全的。這個判斷，永遠是一個關於驗證成本的問題。CI 修復之所以最先自動化，是因為測試套件早就是那個驗證者了。回饋分群之所以能自動化，是因為出錯免費。功能開發之所以抗拒自動化，是因為驗證仍要付出一個人閱讀差異的代價——而 Hacker News 上一位資深工程師，把由此產生的陷阱講得再清楚不過：這項工具需要熟練的判斷力來駕馭，而使用這項工具，恰恰侵蝕的就是那份判斷力。¹⁴

Casey Newton 在 Platformer 與 Cherny 的訪談，標題是「Claude Code 創造者談軟體工程師的終結」。Cherny 在訪談中預測，到今年年底，「軟體工程師」這個頭銜會溶解成某種類似「建造者」的東西，而透過代理寫程式的人數則會成長百倍。¹³在那個預測裡，建造者就是那些選擇迴圈的人。選得好，意味著在任何東西開始運行之前，就先知道你將如何得知它成功了。

重點整理

給運行編程代理的工程師： - 以驗證成本來稽核你的候選自動化，而非以興奮程度。CI 修復、重定基底、監看與報告產生，今天都有免費的驗證者；先自動化這些。 - 套用讀／寫的拆分：一個唯讀迴圈需要的是排程，而一個有寫入權限的迴圈，在無人看管運行之前，需要一道明確的排序限制與一道波及範圍限制。 - 在迴圈之前先設計報告。如果你無法在 10 秒內用手機拒絕掉迴圈的產出，這個迴圈就還沒準備好在夜裡運行。

給團隊主管： - 你的審查頻寬，而非你的代理數量，才是有用平行度的天花板。在那道天花板之上再加代理，產出的是沒人審查的合併，而非吞吐量。 - 把製作者和檢查者分開。一個驗證自己工作的代理，宣稱的是正確性；而一個帶著不同視角的獨立驗證者，至少有機會抓到那個宣稱的破綻。

給工具打造者： - Cherny 把使用者端構造迴圈稱為一次產品設計的失敗，而模型本身已經在主動發起迴圈了。⁵打造「編寫迴圈」的 UX，等於是為一個模型供應商打算吸收掉的層做開發。壽命更長的那塊介面是驗證：證據、追蹤，以及接受／拒絕的操作體驗。

常見問題

參考資料