Loop Engineering：Claude Code 的新工作法

Loop Engineering 把 AI 開發工作改成觀察、回饋、修正的循環流程。

2026 年 6 月初，Anthropic 的 Boris Cherny 丟出一句話。意思很直接：他不再自己寫提示詞給 Claude Code。他先讓模型做，再看結果修正。

這句話會紅，不意外。說白了，它把很多人卡住的地方講穿了。重點不是把 prompt 寫到像聖經，而是把回饋回路跑起來。這才像工程，不像許願。

你如果有寫過程式，就會懂。第一版通常不會漂亮。可是一輪一輪修，常常比一次寫滿更快。這就是 Loop Engineering 的核心。

Loop Engineering 到底在講什麼

它不是正式標準。比較像一種工作法。先讓模型產出，再檢查，再修正，再跑下一輪。整個流程的重點，不是第一句話多厲害，而是每一輪有沒有把錯誤縮小。

這和傳統 prompt engineering 差很多。傳統方法在拚一次輸入的完整度。Loop Engineering 則在意整段互動的品質。對複雜任務來說，後者通常比較實際。

因為真實工作本來就不完整。需求會變，資料會漏，測試會炸。你很難在第一輪就把所有限制講清楚。循環式流程剛好接受這件事，然後用下一輪補洞。

• 先產出草案，再看結果
• 用測試、規則、人工檢查做回饋
• 只修失敗點，不整包重寫
• 把可重複步驟固定成流程

為什麼這個說法會突然流行

因為它很貼近 Claude Code 的使用方式。這類工具不是叫你打一長串命令，然後等神諭。它更像是可以反覆對話的工程搭檔。你給目標，它先做；你給回饋，它再改。

這也是 Addy Osmani 會關注它的原因。他長期在看前端、開發體驗、AI 輔助編程。對他來說，重點不是 AI 會不會寫 code，而是人怎麼把 AI 放進工作流。

“I no longer write prompts for Claude myself.” — Boris Cherny

這句話很有意思。它把主角從 prompt 作者，換成流程設計者。模型負責出第一版。人負責判斷、驗收、糾偏。這才是現在很多團隊真正需要的能力。

很多人還在追長 prompt。老實說，這常常是徒勞。任務越複雜，越不可能一次寫全。循環的價值，就在於它允許你一輪一輪補上原本漏掉的條件。

它和傳統提示詞方法差在哪

傳統 prompt engineering 像寫說明書。你希望一次把背景、目標、格式、限制都交代完。Loop Engineering 比較像做產品迭代。先出最小版本，再依回饋修正。

兩者不是誰取代誰。比較像適用場景不同。簡單任務、格式固定的輸出，一次性提示就夠了。複雜任務、結果不確定、要反覆驗證的工作，循環法更穩。

你可以直接想成這樣：寫文案時，先出 3 個版本；做 code review 時，先找風險，再排優先級；整理研究資料時，先抽事實，再補來源。這些都比一句「請給我最終稿」更好控。

• 一次性提示：適合短任務、固定格式
• 循環式工作流：適合 code、研究、長文、決策
• 人工主導：人先把要求寫滿
• 流程主導：人設計檢查點與停止條件

還有一個很現實的點。循環法能減少全盤重來。第一版如果塞太多要求，模型常常會在細節上失控。先跑一輪，再針對錯誤修補，通常更省時間。

但別把它想得太美。沒有測試，沒有評估標準，沒有停止條件，循環就會變成無限回圈。那不是工程，那是浪費 Token。

對開發者來說，真正有用的是什麼

Loop Engineering 最有價值的地方，不是多了一個新名詞。它是把大模型使用方式，拉回工程現場。編譯、測試、修復。建置、發布、回滾。抓 log、定位、再驗證。開發者本來就活在循環裡。

把 AI 放進這種結構，比把它當萬能聊天框更合理。模型可以寫 code、改文件、產測試、整理 issue。前提是你得把每一步的輸入和輸出講清楚。這就是流程設計，不是嘴砲。

如果要落地，我會先看這幾件事：

• 把大任務拆成可驗證的小步
• 每一步都定義驗收標準
• 先產出，再用測試或規則過濾
• 把高頻循環寫成腳本或模板

對個人開發者也一樣有用。你最缺的往往不是靈感，是穩定節奏。先生成，再校驗，再修正，再固化。這套節奏一旦跑順，AI 才真的像工具，不是玩具。

如果你想看更接近實務的延伸，可以看 Claude Code 工作流 和 AI agent 開發模式。這兩個主題和 Loop Engineering 講的是同一件事：怎麼讓模型穩定產出。

這股風潮放在產業裡怎麼看

Loop Engineering 之所以有意思，是因為它很像軟體工程本來就有的思路，只是換成 AI 版本。人類不會期待一個 compiler 第一次就把 bug 全修掉。那為什麼會期待模型一次就給完美答案？

這也是為什麼很多團隊開始把 AI 接進既有工具鏈。不是只在聊天視窗玩。是接到測試、CI、文件系統、issue tracker。這樣模型才有回饋來源，流程才跑得動。

我覺得這件事還會繼續往前走。不是因為名詞會火多久，而是因為它解決了真問題。真問題不是「模型會不會寫」。真問題是「怎麼讓它在你的流程裡穩定工作」。

• 對產品團隊：適合做文案、規格、FAQ 的反覆修正
• 對後端團隊：適合做測試生成、錯誤修補、重構
• 對研究團隊：適合做摘要、抽取、來源比對
• 對個人開發者：適合做小步快跑的 side project

背景脈絡也很重要

這幾年，AI 編程工具的重點一直在變。早期大家比的是誰回答快。後來比的是誰能接長上下文。現在更像在比工作流。也就是說，誰能把模型放進真的工程流程。

Anthropic 的路線很清楚。它一直在推安全、可控、可驗證的使用方式。Claude Code 也很符合這個方向。它不是只賣聊天感，而是賣協作感。

所以 Loop Engineering 會紅，不只是因為一段話好轉傳。它剛好踩中一個轉向：大家開始從「怎麼問 AI」轉成「怎麼管 AI 的輸出」。這個差別很大。

如果你是台灣開發者，我會建議你把它當成一種工作習慣，而不是新口號。先從一個小流程開始。像是測試生成、PR 摘要、文件修補。把回饋回路縮短，你會很快感受到差異。

結尾：先把回饋回路做短

Loop Engineering 不是神奇招式。它比較像一個很務實的提醒：別再把 AI 當一次性答題機。把它放進觀察、回饋、修正的迴圈裡，效果通常更穩。

如果你今天就要試，我的建議很簡單。挑一個小任務。定一個驗收標準。讓模型先做，再看錯在哪。你會發現，真正值錢的不是 prompt 長度，而是回饋速度。