剛剛，F(xiàn)able 5 極限續(xù)命五天，Claude 榨干指南請收好

本來以為一覺醒來，會看到 Fable 5 正式退出訂閱套餐，GPT-5.6 接檔發(fā)布，趁勢搶走 Claude 的流量。劇本都寫好了，但偏偏現(xiàn)實沒照著演。

就在剛剛，F(xiàn)able 5 官宣延期 5 天，推遲到當(dāng)?shù)貢r間 12 號。Anthropic 還順帶上線了 Claude Cowork 移動端，關(guān)掉筆記本也能持續(xù)工作。

盡管 Anthropic 難得干了回人事，真實打?qū)嵮悠诹耍瑓s未必人人領(lǐng)情。有人緊趕慢趕才將額度清了零，如今不講武德地變卦，反倒徹底沒招了，當(dāng)然，也有人沒來得及用，手里還攥著不少。

既然額度反正要用，怎么用才不虧，就成了眼下最實際的問題。剛好，ClaudeDevs 最近發(fā)布了一篇武林秘籍，主題正是當(dāng)下大火的 AI 詞匯：循環(huán)工程（Loop Engineering）。

上個月 Claude Code 的創(chuàng)造者 Boris Cherny 更是直接攤牌：「我早就不寫提示詞了。」他現(xiàn)在只寫「循環(huán)（Loop）」，扔個目標(biāo)給 Claude，自己轉(zhuǎn)身去喝咖啡，讓 AI 自己跟自己死磕。

知名開源項目 OpenClaw 的作者 Peter Steinberger 也在呼吁：別再給 AI 寫提示詞了，趕緊去設(shè)計能自動生成提示詞的系統(tǒng)。Google Cloud 工程總監(jiān) Addy Osmani 干脆把它稱為 AI 時代的新一代軟件架構(gòu)。

而看完這份秘籍你會發(fā)現(xiàn)，只要定好規(guī)矩，我們甚至就能舒舒服服當(dāng)個「甩手掌柜」了。

https://x.com/ClaudeDevs/status/2074208949205881033

讓 AI 自己卷自己，官方認(rèn)證的四種循環(huán)姿勢

以前我們怎么用 AI 寫代碼？喊一句「加個按鈕」，它寫一段代碼，我們跑一下，報錯了再把報錯交給它……這叫提示詞工程，本質(zhì)上我們還是個人肉搬運工。

循環(huán)工程要干的事，就是把人類從這個循環(huán)里跳脫出去，至于怎么做？ClaudeDevs 官方給出了四種核心循環(huán)方式，自動化程度一檔比一檔高。

回合制循環(huán)（Turn-based），一步一驗收

這是最基礎(chǔ)的循環(huán)形式，還是你下一條指令、AI 干一件事，比如「添加一個點贊按鈕」。 區(qū)別在于， 你可以提前寫一份 SKILL.md 文件，把驗收標(biāo)準(zhǔn)白紙黑字定下來。

有點像給實習(xí)生發(fā)一份入職手冊：活干完不許直接來找我，先自己啟動本地測試服務(wù)器，去瀏覽器里真點一下那個按鈕，確認(rèn)它有反應(yīng)，截圖為證；再檢查控制臺一個報錯都不能有，最后跑一遍 Lighthouse 性能測試（可以理解為給網(wǎng)頁做個體檢）。

所有檢查項全綠，才準(zhǔn)來交作業(yè)。

放到寫作或辦公場景里，也可以用同樣的思路：讓 AI 每次改完稿后，順帶檢查標(biāo)題是否吸引人、事實是否有出處、段落是否連貫、PPT 是否一頁只講一個重點。

目標(biāo)制循環(huán)（Goal-based）：只認(rèn)結(jié)果，不管過程

復(fù)雜任務(wù)往往不是一輪對話能搞定的。這時候可以用 /goal 命令，給 AI 設(shè)一個機器可驗證的硬指標(biāo)——比如「Lighthouse 評分達到 90 分以上」——再加一個最大重試次數(shù)。

然后 AI 就會在后臺自己試、自己測、自己改，要么達標(biāo)，要么撞到次數(shù)上限為止。

這一招的妙處在于，AI 不用再去猜「怎樣才算好」這種玄學(xué)問題了。90 分就是 90 分，89 分就接著改。模糊的審美判斷，變成了確定性的數(shù)字。

定時制循環(huán)（Time-based）：把雜活變成定時鬧鐘

寫代碼之外，程序員每天還有一堆重復(fù)性雜活：代碼審查、回復(fù)評論、修復(fù)跑崩的 CI（持續(xù)集成，可以理解為代碼的自動質(zhì)檢流水線）。

例如輸入 /loop 5m 檢查我的 PR，回復(fù)別人的審查意見，并修復(fù)跑崩的 CI，系統(tǒng)便會每隔 5 分鐘自動執(zhí)行一次巡檢，將其轉(zhuǎn)變?yōu)橐粋€持續(xù)運行的后臺守護進程。

編程團隊里，這類循環(huán)可以用來盯 PR、查測試、處理報錯。放到內(nèi)容和辦公場景里，也可以用來每天定時匯總行業(yè)新聞、整理會議紀(jì)要、掃描選題線索，或者每周生成一份學(xué)習(xí)復(fù)盤。

它的價值在于，那些過于繁瑣的事情，可以先交給 AI 處理一遍。

主動循環(huán)（Proactive）：事件驅(qū)動的自主工作流

這是自動化程度最高的形態(tài)，結(jié)合了動態(tài)工作流和自動模式（Auto mode）。 官方給的典型場景是：設(shè)定系統(tǒng)每小時自動檢查 Bug 反饋區(qū)，在分發(fā)、處理、回復(fù)完所有新 Bug 之前，不許停。

更夸張的是修 Bug 環(huán)節(jié)。系統(tǒng)可以同時開 3 個相互隔離的工作區(qū)（worktrees），讓 3 個 AI 各寫一套解決方案，再拉來一個專門的「裁判 AI」做對抗性審查，最后擇優(yōu)合并。

一個 Bug，三個方案，賽馬機制。以前這是大廠才玩得起的奢侈，現(xiàn)在是幾行配置的事。

當(dāng)然，機器轉(zhuǎn)得越快，翻車也越快。不加約束的自動化循環(huán)，很容易把代碼質(zhì)量寫崩、把 API 賬單燒穿。ClaudeDevs 給了幾條保命建議：

·引入獨立的驗證者。

大模型在評估自己生成的代碼時往往會表現(xiàn)出盲目的自信（即「幻覺成功」）。為了保證質(zhì)量，系統(tǒng)設(shè)計中應(yīng)使用 /code-review 技能，引入一個具有全新上下文環(huán)境的獨立 AI 專門負責(zé)代碼審查，確保檢查的客觀性。

·確定性任務(wù)使用腳本代替模型推理。

為了有效管理 Token 消耗，不應(yīng)讓 AI 每次都從頭推導(dǎo)固定的邏輯。例如填寫 PDF 表單等流程明確的任務(wù)，最好讓 AI 編寫并運行一個固定的執(zhí)行腳本，這比每次都調(diào)用大模型推理要經(jīng)濟高效得多。

·大規(guī)模運行前先進行小范圍測試。

動態(tài)工作流一旦啟動，可能會衍生出大量的子 Agent。官方建議在全面推開前，先選取一小塊任務(wù)進行試運行，并定期使用 /usage 命令檢查 Token 余額和子 Agent 的花費情況，設(shè)定明確的預(yù)算上限。

循環(huán)工程背后，還有一套基礎(chǔ)設(shè)施

真正能進入生產(chǎn)環(huán)境的循環(huán)系統(tǒng)，遠比一個 while(true) 復(fù)雜。

Addy Osmani 在解釋循環(huán)工程時提到，一套可用的循環(huán)至少離不開幾類基礎(chǔ)組件：自動化機制、Worktrees、Skills、插件和連接器，以及子 Agent。

一個個說。

自動化負責(zé)讓任務(wù)反復(fù)發(fā)生。可以是定時任務(wù)，也可以是 hooks 或事件觸發(fā)，比如每 30 分鐘掃描一次依賴漏洞，或者監(jiān)聽 GitHub 合并事件后自動開啟檢查。

Worktrees 負責(zé)給多個 Agent 提供彼此隔離的工作區(qū)。當(dāng)十幾個 Agent 同時處理同一個代碼庫時，隔離環(huán)境能避免它們相互污染進度，也能降低合并沖突帶來的混亂。

Skills 負責(zé)把項目經(jīng)驗寫進規(guī)則里。

SKILL.md 這類文件，本質(zhì)上是一本持續(xù)更新的「踩坑手冊」：這個倉庫不能用 npm，那個測試必須等服務(wù)完全啟動，某類改動必須截圖驗證。人類老員工的經(jīng)驗，就這樣變成了 AI 新員工的肌肉記憶。

插件和連接器則讓 AI 接觸真實系統(tǒng)。

通過 MCP 這類連接方式，Agent 可以讀取工單、查詢數(shù)據(jù)庫、調(diào)用 CI、向 Slack 發(fā)布狀態(tài)。只在本地文件夾里打轉(zhuǎn)，AI 更像一個代碼助手；接入真實工具后，它才開始像一個執(zhí)行角色。

子 Agent 解決的是制衡問題。寫代碼的模型給自己打分，通常會太客氣。更可靠的方式，是讓一個智能體負責(zé)實現(xiàn)，另一個智能體負責(zé)審查。多花一些 Token，換來一次獨立判斷。

從更大的視角看，循環(huán)也有層級。Andrew Ng 曾把現(xiàn)代軟件開發(fā)拆成左環(huán)、中環(huán)和右環(huán)：左環(huán)交給 Agent 快速寫代碼、運行測試；中環(huán)由工程師審架構(gòu)、調(diào)方向；右環(huán)來自真實用戶、線上數(shù)據(jù)和商業(yè)反饋。

上下滑動查看更多內(nèi)容， https://x.com/AndrewYNg/status/2071988145667928442

越靠近左環(huán)，越適合自動化；越靠近右環(huán)，越需要人的判斷。

LangChain 等工具鏈也在往這個方向演進。底層是 Agent 執(zhí)行任務(wù)，再往上是驗證循環(huán)、事件驅(qū)動循環(huán)，甚至還有分析歷史執(zhí)行記錄、自動改寫提示詞和評分規(guī)則的改進循環(huán)。

所以，循環(huán)工程聽起來像是讓 AI 自己干活，放到系統(tǒng)設(shè)計里，其實更像是在搭一條 AI 生產(chǎn)線。機器負責(zé)高頻執(zhí)行，人類負責(zé)規(guī)定節(jié)奏、邊界和驗收標(biāo)準(zhǔn)。

Loop 不只是程序員的事

這條 AI 生產(chǎn)線到底有多香？ Anthropic 自己先吃了螃蟹。

他們已經(jīng)把 Claude Code 接入到 Pull Request 處理流程中。系統(tǒng)會在夜間安排大量 Agent 執(zhí)行長時間任務(wù)，包括跟進審查意見、清理廢棄代碼、處理重復(fù)性維護工作等。

相關(guān)數(shù)據(jù)顯示，引入這類流程后，Anthropic 內(nèi)部人均代碼交付量提升了約 70%。

效率提升固然明顯，但自動化程度越深，隱藏成本也越難忽視。循環(huán)工程真正危險的地方，不只在于 AI 寫錯一段代碼，更在于它能在無人看管的情況下，持續(xù)不斷地寫出大量看似正確的代碼。

代價也是顯而易見的。

最先浮出水面的，是技術(shù)「理解負債」。AI 能快速產(chǎn)出通過測試的代碼，但團隊未必真正理解其邏輯，一旦出問題就難以排查。同時，高速循環(huán)下的自動修補也會讓架構(gòu)逐漸變形，代碼表面更「健壯」，底層卻更混亂。

成本失控也是一大難題。多個 Agent 同時運行，每個子 Agent 又要調(diào)用模型和工具，很容易把個人 Token 額度燒穿，也很容易讓企業(yè)賬單突然變得難看。

Steinberger 曾自嘲自己是有「無限 Token」的人。但對于普通開發(fā)者和普通公司來說，循環(huán)頻率不能只按野心設(shè)置，也要看預(yù)算。尤其是長周期循環(huán)和大量子 Agent 會讓 Token 成本迅速膨脹。

更棘手的是，同一模型既寫代碼又自檢，容易出現(xiàn)幻覺式成功；若測試本身有漏洞，問題還會被循環(huán)放大。同時，接入真實系統(tǒng)帶來的高權(quán)限，也會放大注入、數(shù)據(jù)泄露和誤操作的風(fēng)險。

說了這么多，眼下關(guān)于循環(huán)工程的討論，主要集中在 agentic coding，但這并不意味著循環(huán)（Loop）只屬于軟件工程師。

提示詞時代，人類還在親自分派每一步動作；循環(huán)時代，人類開始設(shè)計崗位、流程和驗收標(biāo)準(zhǔn)。AI 不再只是回答問題，它被安排進了一套持續(xù)運轉(zhuǎn)的組織結(jié)構(gòu)里。

ChatPRD 創(chuàng)始人 Claire Vo 給過一個更好的理解角度，把自己想象成一個管理者。

你設(shè)計的不是一句提示詞，而是一個崗位。這個崗位可以是軟件工程師，也可以是客服、產(chǎn)品助理、運營助理，甚至是一個每天自動整理信息、跟進事項、處理反饋的執(zhí)行角色。這也是循環(huán)工程突然變得重要的原因。

從表面上看，大家從重復(fù)勞動中解脫了，但這反而對我們提出了更高的要求：只會下達簡單指令的人可能會被慢慢取代，而那些懂得如何設(shè)計目標(biāo)、管理權(quán)限、理解大局的人，會變得越來越不可或缺。

說到底，AI 搶走的不是你的工作，是你「執(zhí)行」的那部分工作。剩下所謂判斷的部分，才是接下來最值錢的東西。

我們正在招募伙伴

簡歷投遞郵箱 hr@ifanr.com

?? 郵件標(biāo)題 「姓名+崗位名稱」（請隨簡歷附上項目/作品或相關(guān)鏈接）