無限大 Engineering — 邊掃地邊開發。Loop Engineering ＋ Development Loop ＝ ∞ Engineering，一份從「打掃家裡」長出來的 agentic engineering 筆記。
來推銷一個最近在用的概念，叫「無限大 Engineering」。名字聽起來很唬人，其實只是我想打掃家裡邊開發🤣
事情是這樣的。最近小孩放暑假，我要當奶爸，白天除了顧小孩，還得整理堆滿地的玩具、快爆出來的書櫃。但我又是那種閒不下來的人 — 手一停就渾身不對勁。所以腦子裡冒出的念頭：能不能一邊掃地、一邊把滿地的玩具塞回書櫃，一邊順便進行開發（還可以去逛逛早市，參考我血清素分泌早市那篇🤣）
於是我修改了我的開發模式：搞了一套塞進手機的開發閉環。我一手收玩具、一手滑手機，開發機上的 agent 自己在跑；收一收，看一下手機 build 好了沒；收一收，在 LINE 打一句話叫它改；再收一收，改好的版本已經發到我手機上等我測 🫠
玩具收回書櫃，功能也差不多長出來了。
然後我盯著這個東西看，覺得它好像可以裝 b 一下 — 所以就有了今天這個公式：
Loop Engineering ＋ Development Loop ＝ 無限大 Engineering
∞ ∞ ∞
說正經的，這個 framing 底下有一個我想認真講的技術觀點。這幾週 loop engineering 的主流論述，濃縮成一句話就是：把人從 loop 裡拿掉。Steinberger、Cherny、Osmani 講的都是同一個方向 — 不要再當那個手動 prompt agent 的人，你要去設計那套替你 prompt 的系統（也可以參考之前發過的 Higher-Order Prompting）。
我這套剛好相反 — 它不是把我拿掉，是讓我可以邊掃地邊留在 loop 裡。一條 loop 負責把我從「執行」裡移出去（這條就是主流講的 Loop Engineering），另一條 loop 負責讓我人不在電腦前也能繼續開發跟驗收（這條是我的 Development Loop）。兩條方向相反的 loop 接起來，就是無限大 ∞（呃啊啊啊，中二到不行，無限大工程學）
這篇就是把這個公式拆開講。我會先講主流 Loop Engineering 到底在最佳化什麼，再講我這兩條 loop 各自長怎樣，最後講那個接點 — 因為整個 ∞ 真正的重點，從來不是兩個圈，是中間那個交叉點，而站在那個交叉點上、手裡還拿著拖把的人，是我。
主流 Loop Engineering：它其實想把人推出執行迴圈
事情大概是 2026 年 6 月初開始的。Peter Steinberger 在 X 上丟了兩句話：「You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.」很快在工程圈被大量轉傳。同一天，WorkOS 整理 Boris Cherny 在 Acquired Unplugged（6 月 2 日）的訪談時，也抓出同一個方向 — 他不再直接 prompt Claude，而是寫 loop，讓 loop 去 prompt Claude、決定下一步要做什麼。隔天 Addy Osmani 發了一篇就叫《Loop Engineering》（2026 年 6 月 7 日）的文章，把這個 pattern 命名、拆成五個元件 — automations、worktrees、skills、connectors、sub-agents — 再加一個放在對話之外的 memory。
這條脈絡其實往回接得很深。agent loop 的學術根，是 Yao 等人 2022 年那篇《ReAct: Synergizing Reasoning and Acting in Language Models》（arXiv:2210.03629）— reasoning 跟 action 交錯的重複循環，think → act → observe → think again。現代很多 coding agent 的互動形狀，都可以看成這類 pattern 的產品化版本。再往前一點，還有 Geoffrey Huntley 2026 年初命名的 Ralph Wiggum Loop — 在一個單純的 while loop 裡餵同一個 prompt，讓 agent 挑一件事做，開新 instance 再餵一次，重複到完成，成功與否交給外部驗證而不是 agent 自己判斷。
把這些疊起來會發現，主流 loop engineering 的向量非常一致 — 它在最佳化 autonomy，把人往 loop 外面推。Cherny 自己描述的三階段就是這個方向的縮影：一年前手寫 code 配 autocomplete、後來並行跑好幾個 session 手動 prompt 每一個、現在完全不 prompt 只寫 loop。
我完全同意這個方向在很多場景是對的。它的一個假設是 — 把「人在 loop 裡」預設成一種要被消除的 latency，一個 bottleneck。這個假設在「autonomous 執行」這一段成立，可是它悄悄把另一件事一起吞掉了：人在 loop 裡不是只有「執行」這一種待法。
左圈 ＝ Loop Engineering：Flywheel，把我從 turn-by-turn 執行移出去
我的第一條 loop 完全服從主流論述，它就是要把我移出去。
我用的是我自己做的 Flywheel（github.com/romanticamaj/flywheel），一個 Claude Code plugin，一句話定位是「zero-cost session handoffs for long-running AI coding agents」。它要解的痛點很明確 — AI agent 在大專案上會把 context window 燒光，結果就是一堆半成品 feature、跳過的測試、session 之間掉了的上下文。
Flywheel 的三條核心規則 — 一個 session 只做一個 feature、要嘛 merge-ready 要嘛 revert（不留 WIP commit）、以及一份 machine-readable 的 handoff。整個狀態的唯一 source of truth 是一個 feature-checklist.json（故意用 JSON 不用 markdown，agent 沒辦法在結構上偷吃步），跨 session 的記憶靠一份 claude-progress.jsonl 的 handoff log 撐著。
這裡我要標一個引用，因為這個 handoff 的設計不是我憑空想的 — Anthropic 的《Effective harnesses for long-running agents》講得很好：long-running agent 必須在離散 session 裡工作，每個新 session 都沒有前一班的記憶，像輪班的工程師每班都失憶，所以他們用 claude-progress.txt 加 git history 來搭橋。Flywheel 的 handoff log 就是同一個 idea 的實作。
我實際在跑的是一個更長跑的版本，在 Flywheel 上面疊了一層平行編排。骨架大概是這樣：
- 我丟一份
spec.md進去，主 agent 拆解成一堆 orthogonal 的 feature，每個 feature 帶 Given/When/Then 的test_scenarios，寫進 checklist - 主 agent 對每個 feature 開獨立的 git worktree、開 branch，並行 dispatch subagent
- 每個 subagent 在自己的 worktree 裡跑
/flywheel:relay，TDD 寫測試、實作、過四層 review - 外圈掛一個 stateless 的 reconciler（用 ralph-wiggum 的 ralph-loop）— 它每一輪都重讀 checklist，從不依賴上一輪記憶，是唯一能寫 checklist 的角色
- 全部 ready 的 feature 跑完之後，人類批次驗收，通過的才標
verified，再依 dependency 拓樸序 merge 回 main
裡面有幾條鐵則是這條 loop 能長跑不炸的關鍵。任兩個 feature 不可共享 file / schema / test file（orthogonality，開跑前用 jq 檢查 files_owned 沒交集）。外圈永遠 stateless，checklist 是唯一 SoT 且唯一寫者是 reconciler，subagent 只能把結果寫進自己獨佔的 status 回報檔，多 agent 同寫一個 JSON 的 corruption 整類消失。以及最重要的一條 — subagent 永遠不准自己標 verified，它能回報的終態只有 implemented / needs-fix / blocked。
這條 maker 跟 checker 的分離，其實就是 Anthropic《Building Effective Agents》裡 evaluator-optimizer loop 的老東西 — 寫 code 的模型太會給自己打高分，所以驗的人必須是另一個。Claude Code /goal 這類 run-until-done 的使用上，也很接近這種 maker/checker 分離的精神 — 每一輪後由另一個角色判定是否完成，寫 code 的 agent 不是打分的那個。
所以我實際的操作是 — 前期把 spec 跟截圖餵進去，讓 AI 幫我建好 Flywheel checklist，然後我下 Claude Code 的 /goal，走人。這條 loop 就自己跑到結束（我甚至 goal 都是 AI 幫我生成的，我就無腦餵進去，然後 "go!"）
到這裡，主流論述完全兌現了 — 人真的被移出去了。但「移出」的精確位置 — 我被移出的是「turn-by-turn 的執行」，我沒有被移出「定義 spec」跟「批次驗收 verified」這兩端。這個細節等一下是整個 ∞ 的關鍵。
右圈 ＝ Development Loop：讓我不在電腦前也能驗收
我的第二條 loop 方向完全相反 — 它不移除我，它把我留在 loop 裡，但把 loop 的空間座標解開，讓整條迴圈跟著我的手機到處跑。
串法我之前寫過，這邊帶一下整圈。起點是 LINE，它走 Messaging API 加 Webhook，是 event-driven 的 — 使用者一傳訊息，LINE 就主動把事件 POST 到你事先註冊好的網址，不是後端一直去 poll。所以你要先準備一個外面連得到的 Webhook 網址（ngrok、Cloudflare Tunnel、或自架網域都行），填回 LINE 後台，再往內接到跑在開發機或雲端的 agent。
我這端很單純 — 裝 OpenClaw，再裝 LINE plugin，一個 Webhook → 一個 LINE Bot → 一隻龍蝦，一對一對一。這不是 LINE 的限制，是我自己為了乾淨才這樣切的。
接下來整圈是這樣接的：我在 LINE 對話框裡描述問題、或叫它去看某幾個 repo → 透過我的 issue tracker（我用 Paperclip）做 trigger，把工單派出去、調度更多 agent（往外接龍蝦、或接 Claude Code 都行）→ 讓它們在不同 runtime 底下自動去修 → 修完把 build 自動發到 TestFlight，回到我手機上實測（或開網頁版搭 Tailscale 在網頁上驗）。從「在 LINE 講一句話」到「修好的版本回到我手機上被我測」，中間我不用坐在電腦前面。
這條 loop 有一個地方我想特別講，因為它是「把人留在裡面」這件事能安全成立的前提 — 物理隔離。
prompt 層的防禦本來就永遠是機率性的，再怎麼調都有機會被打爆。而龍蝦又是有名的權限全開 🦞 有 shell、能讀檔、能跑指令。與其去約束一個全能的東西，不如直接把它關進一個隔離環境 — 而這件事放在 developer loop 的脈絡下特別合身。我可以把每一條 loop 會碰到的範圍事先隔離好，於是我很清楚：這條 loop 在我下完指令之後，到底能收到什麼程度的資訊、能動到哪些東西。隔離好的那個範圍，就等於這條 loop 的視野邊界。與其花力氣去驗證它會不會亂來，不如直接讓它碰不到不該碰的東西。
現在講這條 loop 真正特別的地方。它的人沒被移除 — 我還在裡面下判斷、實測、決定下一句話。但它把開發的 feedback loop 從「綁在開發機前」這件事解開了。這裡我想接一個更大的脈絡 — Clark 跟 Chalmers 1998 年那篇《The Extended Mind》講的 extended cognition，工具跟外部環境會變成認知系統的一部分。當手機變成這條開發 loop 的實測終端、LINE 變成 loop 的入口，我的開發迴圈就從書桌延伸到了「躺在床上滑手機」。認知還在，只是它的物理邊界被推出去了。
交叉點：build 出來的那一刻，人才重新進場
現在把兩條 loop 放在一起看。
左圈（Loop Engineering，我的 Flywheel）的向量是 autonomy — 人往外退，退到只剩兩端。右圈（Development Loop，我的 mobile 開發閉環）的向量是 mobility — 人留在裡面，但解除空間綁定。兩個方向相反的圈，要能接成一個 ∞，唯一的條件是它們共享一個交叉點。這也就是那條公式 — Loop Engineering ＋ Development Loop ＝ 無限大 Engineering — 真正在講的東西。
那個交叉點，就是 /goal 完成、build 被吐出來的那一刻。
具體跑起來是這樣的循環 — 左圈跑完，Flywheel 產出一批 verified 的 build，走到交點；交點把棒子交給右圈，把 build 發到我手機；我在手機上實測、驗收，然後在 LINE 講下一句話、或開一份新的 spec；這句話走回交點，交點又把棒子交回左圈，左圈再接手跑下一輪。棒子在交點上反覆換手，整個圖形就是一個 ∞，中間那個交叉點永遠是同一個人在站崗 — 那個人是我。
這就是我要反主流那個隱藏假設的地方。主流 loop engineering 把人移出「執行」；我做的是把人移到兩個 loop 的交點上。人沒有離開系統，人換了位置，而且是物理位置，太爽了🥴
為什麼交點才是重點：intent 跟 accountability 不能外包
會不會這整個 ∞ 只是我硬湊出來的一個好看符號？應該是啦🤣 而且其實 Martin Fowler 在 Human in/on/out of the loop 也有類似概念，但有一個東西讓我覺得交點是真的有結構意義，而不只是修辭。
Osmani 在《Loop Engineering》裡自己就承認，loop 只自動化了中間的步驟，有兩端它幫不了你 — 一端是 intent（精確說出你要什麼，而且清楚到結果可以被驗證），一端是 accountability（為跑出來的東西負責）。loop 自動化中間，兩端留給人。
我的 ∞ 交點，剛好就是這兩端反覆交棒的地方。我前期把 spec 加截圖餵進去，那是 intent 的高精度外顯化 — spec 寫得越 orthogonal，feature 切得越乾淨，模糊的 spec 會拆出共享 file 的 feature，後面整條 pipeline 就會到處爆炸。而 verified 這個狀態的定義權我從不外包 — Flywheel 裡 subagent 永遠不能自己標 verified，只有交點上的人可以。這不是我不信任 agent，是因為驗收的信任必須建立在 artifact 上，不是 agent 自述，所以我還逼 subagent 每個 on-device 測試都要留截圖、還要用 manifest 把截圖綁死在對應的 commit SHA 上，主 agent 再主動把關鍵截圖傳回我手機 🫣
換句話說，交點做的兩件事 — 高精度地把 intent 送進左圈、拿 artifact 驗收後決定 verified — 剛好就是 loop 唯一自動化不掉的那兩端。這也是我對抗 Osmani 講的那兩個風險（comprehension debt 跟 cognitive surrender）的位置。loop 跑得越順，越容易停止有意見、照單全收，那個 gap 會長很快。站在交點上讀 artifact、下判斷，是我唯一沒讓自己滑進去的辦法。
所以，無限大 Engineering 到底是什麼
整件事收束成一句 — 主流 Loop Engineering 把人從 loop 裡拿掉，我做的是把它跟我的 Development Loop 接在一起，湊成一個無限大 Engineering，然後把自己搬到兩條 loop 的交點上。
右圈讓我在執行這一段消失，左圈讓我在驗收這一段可以人不在電腦前，交點確保我在 intent 跟 accountability 這兩端從沒真的離開過。這半年雖然幾乎沒在親手寫 code，但花在交點上的腦力其實比以前更多 — 拆 spec、驗 artifact、決定 verified，這些都比 turn-by-turn 打字累。
而且老實講，小孩也顧了、書櫃也收乾淨了，功能還 merge 回 main，我人從頭到尾沒坐到電腦前 — 這大概是無限大 Engineering 目前唯一被驗證過的 killer use case 🤣
至於這個 ∞ 框架，我還是相信啦⋯一週工作四天，對，但是必須無所不在開發 🤣