Loop engineering 是什麼？

最近冒出一個新詞：loop engineering。它不是要取代什麼，而是幫我把「為什麼我這套開發方式跟 AI coding 這麼合」講清楚了。

這個詞怎麼來的

它是一條演進線，注意力從「怎麼問一次」一路移到「怎麼設計一個會自己收斂的循環」：

• Prompt engineering：把一句話問對。
• Context engineering：餵給模型的整包脈絡怎麼組。
• Harness engineering：把模型接上工具與環境，讓它能動手、拿回饋。
• Loop engineering：設計 agent 一圈一圈跑的迴圈，何時繼續、何時停、每圈拿什麼回饋修正。

源頭大致是 Boris Cherny（Claude Code）跟 Peter Steinberger（OpenClaw，NanoClaw 的前身）這條線。

跟 TDD／SDD 差在哪

很多人以為它要取代 TDD／SDD，其實它們不在同一層。

TDD 跟 SDD 都在回答「什麼才算對」，是真相來源；loop engineering 回答「怎麼一圈圈跑、何時停」，是迭代的接線。所以兩者不是對手：TDD／SDD 正是每一圈結尾那個「這圈過了沒、能不能停」的驗證。沒有明確的真相來源，loop 就停不下來，只能空轉。

一條實用結論：真相來源愈明確、回饋愈便宜快，loop 愈容易收斂，就能安全地放更多自動化；反之就要人站在圈裡把關。想要更多自動化，別追「更聰明的 agent」，要投資「更好的驗證訊號」。

flowchart TD
    Spec["真相來源<br/>SDD 規格 / TDD 測試"]
    Act["Agent 行動"]
    Feedback["拿回饋<br/>測試 / 型別 / lint"]
    Check{"對了嗎？<br/>（驗證＝停止條件）"}
    Human["人在圈裡<br/>依風險把關"]
    Done["收斂：停"]

    Spec --> Act --> Feedback --> Check
    Check -->|否| Act
    Check -->|是，高風險| Human
    Human -->|放行| Done
    Human -->|退回| Act
    Check -->|是，低風險| Done

對到我的 Spectra 加 Rails

我平常的做法整個對上了。Spectra 的 discuss → propose → apply → archive，本質就是「SDD 加上人審」；Rails 則讓迴圈容易收斂：慣例把行動空間縮小、測試讓回饋幾秒就到、monolith 讓脈絡完整、Kamal 讓上線也是一條收斂的 loop。loop engineering 需要的三件事（小行動空間、便宜回饋、完整脈絡），Rails 剛好都內建。

還有個常被忽略的維度：起動門檻。NanoClaw 跑在樹莓派、我用 Discord 指揮，搭捷運用手機就能起一輪 loop，寫文章、驗證想法、或把太長的東西收斂成人願意讀的長度（這篇就是這樣被砍短的）。門檻愈低、一天能跑的圈數愈多。

這是不是只是 hype？

老實說我第一個直覺是：這詞聞起來像在鼓勵你多燒 token。這懷疑對一半。agentic AI 圈確實有「讓 agent 多跑幾圈」的順風，背後有商業誘因，賣 token 的人樂見「放手讓它 loop」變成最佳實踐。但另一半相反：認真做這門功夫是讓 loop 更快收斂、更早停，那是在省 token，真正燒 token 的是沒被工程過、空轉不收斂的 loop。所以它兩面刃：

• 行銷版：給 agent 更多自主、讓它自己跑，燒 token。
• 工程版：縮小行動空間、把驗證做便宜、把停止條件定清楚，省 token。

分辨方法很簡單：問一個做法是讓你的 loop「用更少圈、更清楚地停」，還是「給更多自主、讓它多跑」。而且旋鈕要放多開，該由風險決定：醫療碰病人安全，人就得留在關鍵決策的圈裡。

一句收尾

loop engineering 沒推翻我的做法，只是把「Spectra 定對錯、Rails 讓迴圈收斂、人依風險把關」講成一個講得清楚的框架。別被熱度牽著走：值錢的不是「讓 agent 多跑」，是「讓每一圈都便宜、都收斂、該停就停」。