「驗證者是瓶頸」這句話，只對了一半
名字只是給問題貼上標籤。打造驗證者，仍然是你的功課。
前言
幾年前，這件事只有一個名字：提示詞工程。就是反覆修改一句話，直到模型按你期望的方式運作。去年，同樣的工作被冠上了「上下文工程」的新名字，而今年在討論串裡，人們開始叫它「迴圈工程」。而無論哪個名字，底下總跟著同一句話：「現在瓶頸不再是模型，而是驗證者了。」
每次換名字，開發者的反應都如出一轍：「是真的有改變，還是為了賣一堂課重新刷了層漆？」這個懷疑大體上是对的。AI 工具的術語，換得比它所指向的問題還快得多。
所以我們來逐一拆解。先說結論：每次換名字，你實際在「工程化」的單位確實變了。不是刷漆，而是工作對象本身。 但最新這個名字所指向的問題是真的，名字只是給問題貼了張標籤，並沒有幫你解開它。
單位曾是「提示詞」
我們把時間框定在 2022 年到 2024 年。那時候工作的單位就是一條提示詞。打磨一個請求的句子。放進少樣本1 範例、賦予角色、加上「請逐步思考」、調整先問什麼的順序。你所能掌控的全部表面，就是一則訊息的文字，而把它寫好就是技術的全部。
回頭看，那個時期的訣竅幾乎都收斂到「一句話該怎麼寫」上。放幾個範例、以什麼順序提問、角色怎麼給。這個直覺到今天依然有效，因為好的提示詞仍然是好結果的起點。改變的是，它不再是「全部」了。工作本身已經裝不進一則訊息裡了。
🧩 單位變成了「表面」
2025 年中，Andrej Karpathy 給人們已經在做的東西起了個名字：上下文工程。單位從一則訊息擴展到了視窗（window）內的所有東西。系統提示詞、檢索回來的文件、工具定義，以及每一輪對話都隨附的 CLAUDE.md 或 AGENTS.md2 這類指令檔案。你不再只是打磨一句話，而是在策展一整個表面。
這個表面上有一個開發者付了慘痛代價才意識到的特性：表面上放的大部分内容，其實沒有真正連接到實際行為。「The State of AI Instruction Quality」用確定性分析器掃描了 28,721 個儲存庫，發現指令檔案的中位數包含 50 個內容項目，但真正的指令文只有 12 條。 剩下的都是標題、背景說明，以及模型完全可以忽略的結構。
更尖銳的失敗模式另有專文討論。「Do NOT Think of a Pink Elephant」指出以否定形式撰寫的約束（「不要用 mock」）反而可能提高被禁止行為的發生機率。 原因就和這篇文章的標題剛在你腦中喚起了一頭粉紅大象一樣。
兩者都是上下文工程的問題，而且已被測量、已被公開。
🔁 單位現在是「迴圈」
2026 年 6 月，術語變成了迴圈工程。Addy Osmani 將 Boris Cherny 和 Peter Steinberger 的討論整理後廣為流傳，幾週內就蔓延到整條時間軸上。現在單位是運轉的迴圈：生成、檢查、調整方向、重試、停止。 提示詞成了迴圈中的一個節點。上下文表面則成了迴圈在每次迭代之間傳遞的狀態（state）。
（圖：提示詞 → 模型生成 → 驗證者（這樣夠了嗎？）→ 停止。驗證者處有回到「調整方向並重試」的迴路，上下文表面會一併進入模型生成。）
所有說明文反覆強調的主張就是這個：現在決定上限的不再是模型，而是那個判定「夠了，停」的檢查。讓我們寬容地接受這個名字。前兩個名字悄悄略過的东西，這個名字正面指了出來——那個判定一次迭代是否合格、是否該再跑一次的機制。這個機制一直存在。任何會重試的智能體都有。迴圈工程貢獻的，是把這個機制從「繼承預設值」提升為你主動設計的對象。
🔑 那驗證者到底在檢查什麼？
「驗證者是瓶頸」是個好口號。但只對了一半。它指出了瓶頸在哪，卻沒說那個驗證者到底該檢查什麼。那個空白，正是口號跳過的工程問題。
檢查有兩種，彼此不能互換。確定性檢查3是執行程式碼、檢查終止狀態、掃描是否有被禁止的 import、對相同輸入永遠給出相同判定。中間不夾帶任何判斷。基於模型的檢查4則是問另一個模型「這行不行？」。第一種方式無法表達的標準——「這段說明夠清楚嗎」、「這段讀起來是否失禮」——第二種可以觸及。但代價是，它原封不動地繼承了迴圈本來要鎖住的那份不穩定性。讓概率性地生成的一方何時該停，交給一個概率性地判斷的裁判來決定。
我們來看實際迴圈中兩者分岔的點。你讓智能體重構一個模組，完成後就停。確定性驗證者可以證明測試仍然通過、沒有偷偷混入被禁止的 import。這是每次迭代都能驗證的事實，沒有爭論空間。但它無法判斷那次重構是否值得做。所以如果你加上基於模型的檢查來回答這個問題，現在停止條件就建立在「一個模型為另一個模型的品味打分」之上。迴圈在裁判滿意時結束，而那個裁判恰恰是迴圈要監督的那類組件。
兩者都沒有錯。它們回答的是不同的問題。當你搞不清自己正在問哪種問題時，迴圈就會在錯誤的迭代上自信地停下。
實務上，我這樣區分：「這個標準能不能不問模型，而是透過執行或掃描得出真／假？」如果能，幾乎永遠該用確定性檢查。成本低、不搖擺、失敗時有日誌可查。反過來，如果那個標準只存在於人的腦中（例如：「這段文案符合品牌語氣嗎？」），就無法迴避模型判定。這時候至少把判定標準拆細，讓模型逐項回答檢查清單，而不是自由地給總評，這樣能減少搖擺。不是取消判定，而是收窄判定搖擺的空間。
這個權衡——也就是「檢查實際在檢查什麼」——不是新問題。「Green Tests Don’t Mean Better Software」用 CI 的語境討論了這件事。亮綠燈的測試只能證明程式碼符合規格，卻對「這個變更是否讓系統變好」沉默不語。 檢查回答了一個你根本沒問的問題。把同樣的區分從測試套件轉移到智能體迴圈上，迴圈工程的問題就能用所有開發者已經熟悉的案例來表述。
Oswald 的視角
老實說，我對這個名字既歡迎又謹慎。
長期規劃 GTM 策略，我見過無數次這個模式：「技術會改變一切」的預測大體上是对的，但時間和路徑幾乎全錯。每當新術語出現，我都會先對這個模式保持懷疑。但這三次改名有點不同。每次換名字，不是行銷在動，而是工作對象真的在動。 從句子到表面，從表面到迴圈。所以我認為這些改名是誠實的。
但這裡有一個需要冷靜的點。名字給你一個「對象」。打造驗證者的工作仍然是你的，而且那是工作的大頭。 定義某項工作中「對」是什麼，然後把它轉化成可執行的檢查。
這工作的有一半是選擇檢查的類型。用處理數據的習慣來看，這是度量設計問題。「這段說明夠清楚嗎」需要模型來判斷。「沒有被禁止的 import」用確定性掃描就夠了。選錯了，兩邊都要付代價。該用確定性檢查的卻交給模型裁判，等於白買了一份不穩定性；該用判斷的地方卻立了確定性檢查，得到的只是看起來比實際意義更淺的綠燈。名字只是讓這個選擇變得可見，但不會替你選。
結語
總結如下。第一，從提示詞到上下文、再到迴圈的改名，不是刷漆，而是工程化的單位確實變大了。 第二，「驗證者是瓶頸」是对的，但只對了一半。另一半是：那個驗證者檢查什麼、以什麼方式檢查。第三，名字只是給問題貼上標籤，打造驗證者仍然是你的功課。
這個迴圈有很多組件。接下來幾篇我會把迴圈一塊一塊拆開，在每塊下面鋪上一個度量。怎麼區分在錯誤地方響起的檢查和根本沒有的訊號、調整方向的規則和拒絕的規則有何不同、上下文表面上放的一條指令每輪對話要付多少成本。今天這篇文章提出的問題，就是下一篇的起點。
如果你實際跑過智能體迴圈，停止條件是用確定性檢查還是交給模型裁判？在哪裡被燙得最慘？歡迎在留言區分享。我會考慮納入下一期的素材。
💬 歡迎在留言區分享你如何設計停止條件 · 📨 如果有正在打造智能體的同事，請把這篇文章轉發給他
參考資料 & 延伸閱讀
核心來源
- reporails, “The State of AI Instruction Quality”。：指令檔案中位數包含 50 個內容項目、真正指令文 12 條這組數據的出處。
- cleverhoods, “Do NOT Think of a Pink Elephant”。：否定形式約束會提高被禁止行為發生機率這一論點的出處。
- reporails, “Green Tests Don’t Mean Better Software”。：「檢查回答了一個你沒問的問題」這一論旨的出處。
- cleverhoods, “Prompt Engineering, Context Engineering, Loop Engineering: What Actually Changed”。：本期電子報所依據的原始來源。
背景知識
- Andrej Karpathy，「上下文工程」命名（2025 年中）。：追溯這個術語由來的起點。
- Addy Osmani，「迴圈工程」整理（2026 年 6 月，綜合 Boris Cherny 與 Peter Steinberger 的討論）。：本文第三個名字流傳的路徑。
適合搭配閱讀的往期
- （如果有主題確實相連的往期，請在此處加入連結。例如：討論過上下文視窗或指令檔案的期數，連結起來會很好。）
📝 術語說明
