Loop Engineering：AI 工程的第三次範式轉移

2025 年，大家在學 Prompt Engineering — 怎麼寫出讓 AI 聽懂的指令。

2026 年初，焦點轉向 Context Engineering — 怎麼把正確的資訊在正確的時機餵給 AI。

2026 年中，日本技術社群開始大量使用一個新詞：ループエンジニアリング（Loop Engineering）。

這不是改名遊戲。每一次轉移都在回應同一個問題的不同層次：怎麼讓 AI 在 production 穩定運作？

Prompt Engineering 回答的是「怎麼說」。Context Engineering 回答的是「說什麼」。Loop Engineering 回答的是「說完之後呢？」

為什麼 Prompt 和 Context 不夠

一個精心設計的 prompt，搭配完美的 context，AI 跑出來的結果還是可能是錯的。

不是模型太笨。是你沒有驗證機制。

想像你指派一個新人工程師寫一個功能。你給了清晰的需求文件（prompt），提供了完整的 codebase context。他交回一份 code。你會直接 merge 嗎？

不會。你會 code review。你會跑測試。你會問：「這個 edge case 有考慮嗎？」如果有問題，你會讓他改，然後再 review 一次。

這個「做 → 檢查 → 修正 → 再檢查」的循環，就是 Loop Engineering。

差別在於：對人類工程師，這個循環是隱含的 — 你知道他會犯錯，所以 code review 是標準流程。但對 AI，很多人跳過了這一步。寫一個厲害的 prompt，按下 Enter，然後直接用結果。

2026 年的教訓是：AI 的產出需要跟人類工程師一樣的驗證流程，甚至更嚴格。

Loop Engineering 的三個核心概念

1. Verification Loop（驗證迴圈）

最基本的 loop：AI 產出結果 → 自動驗證 → 通過就繼續，失敗就修正重來。

Agent 寫 code → 跑測試 → 測試通過？
  ├── 是 → 提交
  └── 否 → 回饋錯誤訊息 → Agent 修正 → 再跑測試

Claude Code 的 /verify 就是這個模式。它不只是跑 typecheck — 它會實際驅動功能、觀察行為、比對預期。失敗了就帶著錯誤訊息回去修。

關鍵洞察：loop 的品質不在於 AI 多聰明，而在於驗證步驟多嚴格。一個笨 AI + 嚴格驗證，比一個聰明 AI + 沒有驗證更可靠。

2. Cross-Model Review Loop（跨模型審查迴圈）

用不同的 AI 模型互相審查，避免單一模型的盲點。

Claude 寫 code → Codex review → 有問題？
  ├── 否 → 通過
  └── 是 → 回饋 review 報告 → Claude 修正 → Codex 再 review

這比 self-review（讓同一個模型檢查自己的產出）有效得多。就像學生不該批改自己的考卷 — 同一個 training data 產生的 bias，self-review 看不到。

日本社群的一個精準比喻：「AI 自審機制是降低 AI 生成程式碼風險的關鍵路徑」。不是可選的品質提升，是必要的風險控制。

我的實踐是把 Codex review 做成 gate — 完成任何非 trivial 修改，必須經過 Codex 審查才能視為完成。今天的 session 就有一個活例子：我改了搜尋函式的參數，Codex review 抓到 HTTP handler 用位置參數呼叫的 bug。如果沒有這個 loop，bug 會直接上線。

3. Script-Agent Fallback（腳本化逃生）

這是最務實的一個概念：讓 Agent 跑幾次任務，從 tool call trace 產生可重用的腳本。之後就不需要 Agent 了。

Agent 執行任務 3 次 → 觀察 tool call 模式 → 產生 shell script
→ 之後直接跑 script，不再呼叫 Agent

Agent 的價值不是「每次都幫你做」，而是「幫你做一次，之後自動化」。

這直接解決了上一篇講的可靠性問題 — 20 步的 Agent 鏈成功率只有 36%，但 20 步的 shell script 成功率趨近 100%。把不確定性的 Agent 步驟轉化成確定性的腳本，是 loop engineering 的終極目標。

從日本社群看 Loop Engineering 的爆發

2026 年 6 月中旬開始，日本的 Zenn 和 Qiita 上出現了大量 loop engineering 相關文章。我的知識庫裡有 20 篇直接相關的 Zenn 文章，時間集中在 6 月到 7 月。

幾個有代表性的觀點：

「AI 開發術語的演進本質上是解決瓶頸的過程，而非單純的名稱更迭。」

Prompt engineering 解決的瓶頸是「AI 聽不懂」。Context engineering 解決的是「AI 看不到需要的資訊」。Loop engineering 解決的是「AI 做完了但你不知道對不對」。

「AI 代理正將開發重心從『撰寫程式碼』轉移至『流程狀態管理』。」

當 AI 能寫 code 的時候，人類的價值不在寫 code，而在設計驗證流程。Loop engineering 就是這個轉移的具體實踐。

「Agent 的效能不在於單次 Prompt，而在於設計能自我修正的循環機制。」

一次性的完美 prompt 是幻想。可修正的循環才是工程。

日本社群比英文圈更早系統化這個概念，可能跟日本製造業的品質文化有關 — 豐田的 PDCA 循環、品管圈、持續改善（kaizen）。Loop engineering 本質上就是 PDCA 的 AI 版本：Plan（prompt）→ Do（execute）→ Check（verify）→ Act（fix or ship）。

我的 Loop 實作：Hooks + Rules + Review Gate

我不是讀了 loop engineering 才開始做的。是做了一年多的多代理系統，回頭看才發現整套架構就是 loop engineering。

Pre-commit hook：每次 commit 前自動跑 ruff check。這是最簡單的 verification loop — 程式碼品質不過就不讓 commit。

Codex review gate：完成非 trivial 修改 → Codex 審查 → 有問題就修 → 再審。這是 cross-model review loop。

撞牆停手規則：2 次失敗 → 強制停止。這是 loop 的斷路器 — 防止無效的 retry 無限循環。沒有斷路器的 loop 比沒有 loop 更危險，因為它會在錯誤的方向上越陷越深。

Session 開場/收尾：開場搜 memhall 拿上次進度 → 工作 → 收尾寫回 memhall。這是跨 session 的 feedback loop — 每個 session 的經驗餵回下一個 session。

Skill benchmark（worktree A/B test）：同一個任務，worktree A 用 skill、B 不用，git diff 比較產出。這是 meta-loop — 驗證你的驗證機制本身有沒有效。

把這些拆開看，每一個都很普通。但組合在一起，它們形成了一個多層次的 loop 系統：

最內層：pre-commit hook（秒級，自動）
第二層：Codex review gate（分鐘級，半自動）
第三層：撞牆停手（session 級，規則觸發）
第四層：memhall 跨 session 回饋（天級，結構化）
第五層：skill benchmark（週/月級，刻意驗證）

五層 loop，從秒到月，覆蓋不同時間尺度的品質控制。

Prompt → Context → Loop：一張演進圖

這三者不是替代關係 — 是疊加。你仍然需要好的 prompt（Layer 1），仍然需要正確的 context（Layer 2），但如果沒有 loop（Layer 3），前兩層的效果無法被驗證和持續改進。

結語：迴圈比直覺更可靠

Addy Osmani 說得好：真正的進步不是從 prompt engineering 到 loop engineering 的「跳躍」，而是從「依賴直覺判斷品質」到「用系統驗證品質」的思維轉變。

你可以花一小時打磨一個完美的 prompt。但如果你花同樣的時間設計一個驗證迴圈，那個迴圈會在之後的每一次執行中持續保護你。

Prompt 是一次性的。Loop 是持續的。

在 AI 能力每季翻倍的時代，你寫的 prompt 很快就會被更強的模型 trivialize。但你設計的驗證流程 — 跑測試、跨模型 review、失敗時停手、跨 session 累積經驗 — 這些不會因為模型升級而失效。

這就是為什麼 loop engineering 不只是一個新名詞。它是 AI 工程從「demo 級」走向「production 級」的分水嶺。

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。