# 策展 · X (Twitter) 🔥🔥 > 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt) > 作者：𝗿𝗮𝗺𝗮𝗸𝗿𝘂𝘀𝗵𝗻𝗮— 𝗲/𝗮𝗰𝗰 (@techwith_ram) · 平台：X (Twitter) · 日期：2026-06-12 > 原始來源：https://x.com/techwith_ram/status/2064925285003542820 ## 中文摘要 # Loop Engineering 並非你想像的那樣 那些正在打造最先進程式開發 Agent 的人表示，他們幾乎不再需要撰寫 Prompt 了。相反地，他們建立的是一套能自行產生、審查並改進自身工作的系統。這個願景相當誘人：減少瑣碎的監管，實現更多的自動化。 但這其中有個陷阱。 大多數關於「Loop（迴圈）」的討論都聚焦於它們能做什麼，而非它們的代價。每一次額外的轉折都會消耗 token、做出預設假設，並讓你離直接掌控的距離越來越遠。 ## 如果你想學習 AI Agent，請參考這個 GitHub 儲存庫： ## https://github.com/Ramakm/ai-agents.git Claude Code 背後的工程師 Boris Cherny 曾說過一句話，讓許多開發者停下來深思。 當被問及他現在如何工作時，他說他幾乎不再直接對模型下 Prompt。相反地，他建立了能為他向模型下 Prompt 的 Loop。他的工作變成了「建立這些 Loop」。 這是一個微妙但重要的轉變。 他不再專注於與 AI 對話，而是專注於建立那個「與 AI 對話的系統」。OpenClaw 的創作者 Peter Steinberger 也提出了類似的觀點：停止對程式開發 Agent 下 Prompt，開始設計能對它們下 Prompt 的 Loop。 理所當然地，AI 圈隨即跟進。Agentic Loop 成了最新的熱門詞彙。 但一如既往，現實比標題所描述的更為複雜。大多數談論 Loop 的人，無法清楚解釋它們是什麼、在什麼時候真正有幫助，或者你為了換取自動化而犧牲了什麼。 在這篇文章中，讓我為你釐清這些問題！ # 首先，什麼是「Loop」？ 其實你一直都在執行 Loop，只是裡面有一個人類參與者：你自己。 你打開 Cursor、Claude Code 或 Codex，輸入：「幫我建立一個登陸頁面（landing page）。」你查看產出的結果。Hero section 看起來不太對勁，所以你要求修改。它產生了另一個版本。你審查它、引導它，然後重複這個過程。 產生。審查。引導。重複。 這個循環有個名稱：Human-in-the-loop（人在迴圈中）。 Agent 負責建構，但你仍然是那個負責指揮、判斷並引導工作方向的人。 ![這張手繪圖表展示了人類與 AI 代理（AI agent）在開發流程中的互動循環。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/e25a73fc3a124d8e.jpg)
展開畫面重點
圖片呈現了一個循環式的開發流程，包含以下文字內容： - 左側標示為「you」（代表使用者）。 - 中間方框標示為「AI agent」，下方括號內註明「Cursor / Claude Code」。 - 右側方框標示為「result」。 - 箭頭說明： - 從「you」指向「AI agent」的箭頭標示為「prompt」。 - 從「AI agent」指向「result」的箭頭標示為「generates」。 - 從「result」指向「you」的循環箭頭標示為「you review, test & redirect - every cycle」。 - 右下角署名為「X techwith_ram」。
這種方式讓人感到安心，因為你能及早發現偏差。登陸頁面看起來不對勁？在寫下任何一行驗證程式碼之前，你就能指出來。你是品質把關者、品味判斷者，也是修正方向的人，這一切都濃縮在一個緩慢但專注的人類身上。 # 新的理念：將人類移出迴圈 每個人都感到興奮的趨勢，徹底翻轉了這個圖表。你不再需要在每次循環時都介入，而是只在開頭介入一次。你將一份規格書（例如 `spec.md` 或 `PRD.md`）交給 Agent，描述要建構什麼，然後退後一步觀察。 看看這個儲存庫：https://github.com/snarktank/ai-dev-tasks/blob/main/create-prd.md Agent 產生內容、讀取自己的輸出、決定還有什麼需要做，然後再次對自己下 Prompt。它會不斷地、自主地重複這個過程，直到它認為工作完成為止。 ![這張手繪風格圖表展示了 AI 代理（agent）自動化工作流程的運作機制。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/24b973b11b8752bd.jpg)
展開畫面重點
圖表呈現了一個自動化流程，包含以下元素與文字： - 左側有一個虛線繪製的人形圖示，標註為「fires once」（觸發一次）與「human steps away」（人類離開）。 - 一個標示為「spec.md」的文件圖示，箭頭指向右側的「agent」。 - 「agent」方框內標註「plans & writes」（規劃與撰寫）。 - 從「agent」指向「result」方框的箭頭，標註「1. writes」。 - 從「result」指向「agent」的橘色循環箭頭，標註「2. feeds result back」（將結果回饋）。 - 右下角有標記「X techwith_ram」。
這並非邊緣概念。開源開發者 Geoffrey Huntley 將其最簡單的版本封裝為「Ralph Wiggum」Loop。其核心是一個 Bash Loop，它會不斷地在同一個任務上重新執行 Agent，直到達到明確的完成條件。 像 Cursor 的 `/goal` 以及網路上流傳的各種 `/loop` 和 `/sloop` 指令，本質上都是同一種招數：「這是目標；沒完成前別停下來。」在 Anthropic，這種工作風格是 Claude 現在能撰寫絕大多數已合併生產環境程式碼的部分原因。 這確實讓我們瞥見了未來的發展方向。但簡報到此為止，現實才剛開始。 # 為什麼它感覺像魔法，卻往往不是 想像一下，你聘請了一位傑出的開發者，交給他一份規格書，然後兩週內音訊全無。 最後他帶著成品回來了。有些決策非常精準，但有些卻完全偏離了你的想法。 這不是因為他們能力差，而是因為沒有任何規格書能涵蓋所有細節。 這就是自主 Loop 的問題所在。 當 Agent 開始代表你做出數百個決策時，它被迫要填補那些空白。而空白總是存在的。 回傳的結果有時就像吃角子老虎機。拉下把手，等待，祈禱產出符合你的願景。有時會中獎，但更多時候不會。 最困難的部分在於，你無法在過程中進行引導。一旦你輸入 `/goal`，火車就已經離站了。 # 沒人會放在簡報上的部分：帳單 這是令人不安的現實：Loop 並非免費的。 單次請求是一輪 token 消耗。一個 Loop 可能會執行十次、二十次甚至五十次，並在每一步攜帶上下文、輸出和歷史記錄。成本會迅速累積。 這就是整個 Agentic Loop 運動背後那個安靜的星號。 許多提倡全自動化工作流程的人，其預算規模大到 token 成本幾乎可以忽略不計。但大多數開發者並沒有這種奢侈。 如果你每個月的預算只有 20 美元、100 美元甚至 200 美元，一個開放式的 Loop 可能會讓你驚訝地迅速燒光預算。 這就是為什麼企業開始限制 Agent 的使用。技術固然強大，但經濟效益同樣重要。 這並不代表 Loop 是個壞主意。這只代表它不是魔法。它是一個工具，像任何強大的工具一樣，你在讓它運作之前，必須先了解它的代價。 # 那麼，Loop 在什麼時候真正有效？ 這裡有一個簡單的規則：當成功標準是「客觀」的時候，Loop 效果最好。 測試通過了嗎？分數達到門檻了嗎？產出符合模板嗎？ 當答案是明確的「是」或「否」時，Loop 就有了具體的優化目標。麻煩在於當成功變得「主觀」時。 「這感覺對嗎？」、「這是我想像中的產品嗎？」、「客戶會喜歡嗎？」 這些都不是 Agent 可以可靠測量的問題。在這種情況下，Loop 只是在瞎猜。這就是為什麼 Loop 在產生大量固定格式的 SEO 頁面、執行評估或處理大規模程式碼遷移時表現出色。目標明確，且回饋保持一致。 ![這張圖表分析了 AI 迴圈（loops）在不同任務類型下的表現差異，指出其在固定回饋任務中表現較佳。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/b1f091f8ecc18a49.jpg)
展開畫面重點
圖片為一個二維座標圖，橫軸從左至右為「CREATIVE（創意）」到「FIXED FEEDBACK（固定回饋）」，縱軸為「BINARY（二元）」。圖中包含兩個方框： 1. 左上方的方框標示為「loops misfire ✗」，下方文字為「"build my startup, make no mistakes"」。 2. 右下方的方框標示為「loops shine ✓」，下方文字為「code review · passing tests · SEO page gen · migrations」。 右下角署名為「X techwith_ram」。
但是「幫我建立一個賺錢的創業公司」是完全不同的問題。沒有所謂的「產品市場契合度（Product-Market Fit）」測試套件，沒有品味的基準測試，也沒有願景的客觀分數。 目標越主觀，人類判斷的價值就越高。 # 你現在就能執行的 Loop 如果要我推薦一個 Loop 給幾乎所有開發者，那就是「自動化程式碼審查 Loop」。 為什麼？因為它擁有大多數 Agent 工作流程所缺乏的東西：明確且客觀的訊號。 你將程式碼推送到 GitHub。像 Greptile、CodeRabbit 或 Macroscope 這樣的審查 Agent 會審查變更，並給出五分制的分數。 然後你設定一個簡單的規則：低於 4/5 分的程式碼禁止發布。 ![這張流程圖展示了一個基於 AI 代理進行自動化程式碼審查與部署的工作流程。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/d132d5c4b4eb8b21.jpg)
展開畫面重點
該圖表描述了一個自動化開發流程，包含以下步驟與文字： 1. 「push code to GitHub」：將程式碼推送到 GitHub。 2. 「review agent Greptile · CodeRabbit」：由指定的 AI 代理進行程式碼審查。 3. 「score / 5 ?」：判斷審查分數是否達到標準。 4. 若分數「>= 4/5」，則執行「ship to prod ✓ live」（部署至正式環境）。 5. 若分數「< 4/5」，則執行「read review, fix, re-push (up to 5 tries)」（閱讀審查意見、修正並重新推送，最多嘗試 5 次）。 圖表右下角標註了「X techwith_ram」。
如果分數回傳是 2/5 或 3/5，你不需要手動介入。你觸發一個小型工作流程，讀取審查意見、套用建議的修復、推送變更，然後等待下一次審查。 這個過程會重複，直到分數超過 4/5 或 Loop 達到最大嘗試次數。這就是一個好的 Loop 該有的樣子：一個擁有可測量目標和明確退出條件的封閉系統。 秘密不在於 Loop 本身，而在於擁有一個 Loop 可以可靠追蹤的分數。如果你想要最基礎的雛形，Ralph 風格的 Loop 其實就是在你的 Agent 周圍加上幾行程式碼： ```python # 核心概念，省略細節 for i in $(seq 1 5); do agent run "read the latest review, apply fixes, push" score=$(get_review_score) # 固定且客觀的訊號 if [ "$score" -ge 4 ]; then echo "passed at $score/5 — shipping"; break fi done ``` 警告：即使是這種乾淨的 Loop，在邊緣情況下也會崩潰。一次推送超過約 1,000 行程式碼，審查 Agent 就很難維持完整的上下文；你幾乎不可能拿到 5/5 分。解決方法是優秀工程師早已習慣的紀律：保持變更規模小，將大型工作拆分成多個 PR。即使在一個整潔、定義明確的 Loop 中，範圍（Scope）仍然是導致它失敗的主因。 # 我的真心話 以上這些並非要否定那些推動自主 Loop 的人。他們可能只是走得比較早，而不是錯了。具備自我修復能力的 Agent、自動化 Bug 修復，以及能觀察並測試自身工作的系統，出現的速度比大多數人預期的還要快。 但「出現」與「萬事俱備」是兩回事。 現實是，大多數偉大的產品並非僅靠邏輯構建。它們需要品味、判斷力，以及無數個規格書無法完全涵蓋的微小決策。 這就是為什麼我喜歡這句話：AI 可以複製醬汁（sauce），但它無法創造醬汁。 當目標明確時，Loop 是不可思議的。審查、測試、Linting、遷移、基於模板的產生。給它們一個可測量的目標，它們可以整天運作。 但當問題變成「這感覺對嗎？」或「人們真的會想要這個嗎？」時，你仍然需要人類在迴圈中。 所以，不要建立一個巨大的 Loop 並要求它幫你創立公司。在工作中枯燥、二元的部分周圍建立小型 Loop，並在任何需要品味和願景的地方，親自掌握方向盤。 這不是對抗趨勢，而是理解趨勢。 追蹤 @techwith_ram 以獲取更多此類內容 ## 標籤 Agent, 自動化, 開源專案, 教學資源, Loop Engineering, AI Agent