輝達執行長黃仁勳最近一句話，讓「迴圈工程」（Loop Engineering）這個詞瞬間變成AI圈最熾熱的話題。根據X網友引述，他說「現在沒人在寫提示詞了，都在編寫、管理迴圈」，並把這個轉變形容為定義2026下半年AI發展的關鍵詞。
如果你還停留在「把提示詞寫好」的階段，這篇文章會帶你搞懂迴圈工程到底是什麼，以及它跟提示工程有什麼本質上的不同。最後還會用一個可以直接在Google Colab執行的範例，讓你親手做出一個會自我修正的AI迴圈。
🔔 不錯過任何精彩內容
立即訂閱我們的 LINE 或將本站設為 Google 偏好來源，掌握最新資訊！
Loop Engineering（迴圈工程）是什麼？
迴圈工程是一種讓AI系統自己重複「行動、驗證、修正」這個循環，直到達成目標為止的設計方法，人類不需要在每一步手動下指令。過去你跟AI互動的方式，大概是你問一句、AI答一句，如果答案不對，你再寫一句新的指令去修正，整個過程你必須全程盯著。迴圈工程要做的，是把這整套「問、答、檢查、修正」的流程包裝成一個會自動運轉的系統，你只需要設定一次目標，剩下的交給系統自己跑。
這個概念背後其實有學術根源，源自普林斯頓大學與Google共同提出的ReAct模式（Reason + Act，推理加行動）。簡單說，一個標準的迴圈會不斷重複四個動作：感知環境現況、推理該怎麼做、實際採取行動、觀察結果，然後再重新感知一次，直到任務完成或達到停止條件為止。
黃仁勳為什麼會談到這個概念？
這波討論其實是由幾位重量級工程師接連發言所引爆，黃仁勳的發言則讓它正式進入主流視野。最早把這件事說得很直接的是開源工具OpenClaw的創辦人Peter Steinberger（目前任職於OpenAI），他在X上發文表示：「你不應該再去提示你的程式碼代理了，你應該設計會去提示代理的迴圈。」這則貼文獲得超過三百萬次觀看。
幾乎同時，Anthropic旗下Claude Code的負責人Boris Cherny也說了類似的話：他已經不再直接對Claude下提示詞，而是讓自己設計的迴圈去提示Claude、自行判斷下一步該做什麼，他形容「我現在的工作就是寫迴圈」。
黃仁勳則是在受訪時把這個趨勢拉到更高的層次，他提到未來的AI將超越單次提示詞，成為能夠自主搜尋資料、評估結果、推理、使用工具，並透過重複循環自我改進的系統，而這正是迴圈工程想要實現的目標。
迴圈工程跟提示工程有什麼不同？
提示工程拚的是把一句指令寫得更精準，迴圈工程拚的是設計一套能自動驗證、自動修正的系統架構。可以用一個簡單的對照來理解：提示是給AI一道指令，迴圈是給AI一份完整的工作。提示工程師每跑一次都要自己檢查結果對不對，他本人就是那個回饋迴圈；迴圈工程師則是把「檢查、修正」這個動作也寫進系統裡，讓系統自己驗證、自己改、自己決定要不要再跑一次。
換句話說，一個聰明的提示詞最多只能改善一次回覆的品質，但一個設計良好的迴圈可以讓整個工作流程持續進化，把原本需要人工反覆來回的工作，變成一套可以自己收斂到正確答案的系統。
如何設計一個會自我修正的AI迴圈？
一個最簡單的自我修正迴圈，只需要四個步驟：執行測試、檢查結果、請AI修復、重新驗證。下面這個範例用Python示範了完整的流程：故意寫一個有bug的函式，讓系統自動偵測錯誤、呼叫AI分析並修復，再重新測試一次，直到全部通過為止。
這份程式碼是設計給Google Colab執行的互動式筆記本，程式碼最上方的@title、@markdown、@param是Colab專屬的表單語法，會自動生成可勾選、可填寫的互動介面。如果直接複製到本機的.py檔案執行，這幾行會被當成一般註解，互動表單的功能就會消失，但程式邏輯本身不受影響。
USE_MOCK_AI = True # @param {type:"boolean"}
OPENAI_API_KEY = "your-key-here" # @param {type:"string"}
!pip install openai -q
def run_tests(code_string):
"""執行測試並回傳結果"""
try:
local_vars = {}
exec(code_string, {}, local_vars)
func = local_vars.get('calculate_discount')
if not func:
return False, "錯誤：找不到 calculate_discount 函數"
tests = [
(100, True, 80),
(100, False, 100),
(-50, True, 0),
(0, False, 0),
]
for i, (price, is_vip, expected) in enumerate(tests):
result = func(price, is_vip)
if result != expected:
return False, f"測試{i+1}失敗: price={price}, is_vip={is_vip}, 預期={expected}, 實際={result}"
return True, "所有測試通過！"
except Exception as e:
return False, f"執行錯誤: {str(e)}"
if not USE_MOCK_AI:
from openai import OpenAI
client = OpenAI(api_key=OPENAI_API_KEY)
def get_ai_response(current_code, error_message, iteration):
"""獲取 AI 的修復建議"""
if USE_MOCK_AI:
return '''def calculate_discount(price, is_vip):
if price < 0:
return 0
if is_vip:
return price * 0.8
return price'''
else:
response = client.chat.completions.create(
model="gpt-4o-mini",
messages=[
{"role": "system", "content": "你是 Python 專家。只輸出純程式碼，不要 markdown。"},
{"role": "user", "content": f"修復這段程式碼：\n{current_code}\n\n錯誤：{error_message}"}
]
)
return response.choices[0].message.content.replace("```python", "").replace("```", "").strip()
def run_loop_engineering():
"""主迴圈執行函數"""
buggy_code = """def calculate_discount(price, is_vip):
if is_vip:
return price * 0.8
return price"""
current_code = buggy_code
max_iterations = 5
print(f"初始程式碼（有 Bug）:\n{current_code}\n")
for i in range(max_iterations):
print(f"--- 第 {i+1} 次迭代 ---")
passed, message = run_tests(current_code)
if passed:
print(f"成功！在第 {i+1} 次迭代完成修復")
print(f"最終程式碼:\n{current_code}")
return current_code
print(f"測試失敗: {message}")
print("AI 正在分析並修復...")
current_code = get_ai_response(current_code, message, i)
print(f"AI 修復後的程式碼:\n{current_code}\n")
print("達到最大迭代次數，未能完全修復")
return current_code
if __name__ == "__main__":
final_code = run_loop_engineering()
執行之後你會看到：第一次迭代測試失敗，原因是函式沒處理負數價格的情況；接著系統把這個錯誤訊息交給AI，AI回傳修正後的程式碼；第二次迭代重新測試，全部通過，迴圈結束。這個過程完整對應了感知、推理、行動、觀察這四個步驟不斷重複的核心邏輯。
這裡有一個重要提醒：範例裡用exec()直接執行AI回傳的程式碼，這在教學示範中很常見，但如果接上真實的API金鑰（把USE_MOCK_AI設為False），AI回傳的任何程式碼都會被直接執行，沒有經過任何沙箱隔離。正式環境如果要採用類似架構，務必搭配容器或沙箱機制，不要直接對不受信任的AI輸出執行exec()。
使用迴圈工程要注意哪些風險？
迴圈工程最大的風險不是技術做不到，而是目標設得太模糊，導致系統陷入無意義的空轉。業界已經出現一個專門形容濫用情況的詞，叫做「loopmaxxing」，意思是迴圈成癮，心態是「反正讓AI一直跑、跑夠久，總會跑出正確答案」。問題是，AI迴圈一定要有一個可以被驗證的成功標準，例如測試通過、程式編譯成功；如果目標模糊到像「把這個功能重構得更好」，AI根本不知道什麼叫做完了,於是就會陷入無止盡的空轉，甚至開始追逐自己幻想出來的指標。
另一個現實問題是成本。自主運行的迴圈如果沒有謹慎設定停止條件和預算上限，token消耗可能在你沒注意到的時候急速攀升，尤其是讓系統在無人監督的情況下整夜運轉時更要小心。
常見問題
Q1：黃仁勳真的這麼說嗎？
黃仁勳在受訪時確實多次提到，AI系統正在從單次提示詞走向能自主搜尋、評估、透過重複循環自我改進的架構，方向跟「迴圈工程」這個概念是一致的。
Q2：迴圈工程跟提示工程，我只能選一個學嗎？
不需要。提示工程是基礎技能,迴圈工程是建立在它之上的系統設計能力。即使你設計了一套自動運行的迴圈，迴圈裡每一次跟 AI 互動的指令，本質上還是要靠提示工程去寫好。
Q3：一般人也能自己動手做迴圈工程的範例嗎？
可以。文章中的範例設計成可以直接在 Google Colab 執行，不需要寫程式環境設定，而且內建模擬模式，完全不用 API 金鑰就能看到完整的迴圈運作過程。
Q4：迴圈工程會不會讓AI的使用成本大幅增加？
如果沒有設定清楚的停止條件，確實有可能。讓AI在迴圈裡反覆嘗試、驗證、重試,消耗的 token 會比單次提示詞高出許多，所以設計迴圈時，明確的目標和終止條件非常重要。
Q5：Claude Code 跟 OpenAI Codex 都支援迴圈工程嗎？
兩者都已經內建相關能力，例如自動化排程、子代理協作、工作區隔離等機制，讓開發者不需要從零開始寫迴圈的基礎架構，但實際操作時建議查閱各自的官方文件確認最新功能與權限設定。
迴圈工程把開發者的角色，從那個轉動曲柄的人，變成設計那台機器的人，你不再忙著一句一句下指令，而是花時間想清楚目標是什麼、怎麼驗證、什麼時候該停下來。