AI 指令的空洞化：為什麼再長的 Prompt 也無法取代驗證迴圈
真正讓 AI 工作流變穩的，從來不是把 prompt 寫得更長，而是讓規則進入可驗證、可回饋、可版本化的閉環。當系統缺少 harness、評測與失敗回流，再漂亮的 instruction 也只是文字。
在導入 AI 的過程中，許多團隊會不自覺地陷入一個誤區：不斷擴充、堆疊 prompt 指令，試圖用鉅細靡遺的規則來「馴化」模型。然而，當這些指令未能進入一個嚴謹的驗證閉環，再長的 prompt 也只是堆積著缺乏執行力的規範。單純的規則本身無法自動演變成可靠的系統，真正有效的，是建立外部測試框架（harness）、自動化評測、失敗回流與版本治理。這不僅是 Prompt Engineering 的技術挑戰，更是 AI workflow 能否制度化、系統能否長期可靠的根本問題。
為什麼我們的 AI 指令集會逐漸失效？
最近，日本開發者豬排（@cutlet_of_pork）分享了他優化 Claude Code 設定的實戰經驗，點出了一個普遍的痛點。許多開發者或團隊在使用 AI 工具時，都曾遇到類似的困境：
- 在網路上看到好的 prompt 技巧，心想著「等等來加到設定檔」，然後就忘了。
- 團隊成員不斷加入新的規則，導致設定檔（例如
CLAUDE.md）無限膨脹，最終因為過於複雜，反而讓模型開始忽略某些指令。 - 許多早期加入的設定或 hook，從來沒有人去驗證它們是否依然有效，或者是否與新規則產生衝突。
- 針對 prompt 的優化工作，常常因為 session 中斷而遺失，下次又得從頭來過。
這些問題的本質，是我們把 prompt 當成了一份靜態的「許願清單」，而非一份需要被嚴格管理的「程式碼」。當指令集不斷膨脹，模型的「注意力」就成為稀缺資源。
多項研究早已顯示，大型語言模型在處理長文本時，容易出現「迷失在中間（Lost in the Middle）」的現象，位於輸入文本中間的資訊更容易被忽略。即使是像 Claude 3.5 Sonnet 這樣擁有 200K context window 的先進模型，也不代表它會同等地關注每一條指令。當我們把 prompt 塞滿「你應該...」、「你不能...」等規範，卻沒有機制去驗證其有效性時，這就像頒布了一部無人執法的法典，最終只會被模型「策略性地」忽略。
當指令沒有進入驗證閉環，再長的 prompt 都只是在堆積沒有執行力的規範。
從「手寫規則」到「測試驅動」的系統化思維
前述的日本開發者為了解決這個問題，設計了一套稱為「Harness 自我改善迴圈」的機制。這裡的「Harness」（或稱測試挽具），是一個源自軟體工程的概念，指的是模型外部所有用於控制、驅動與驗證其行為的元件與流程。這套機制的核心，是將 prompt 的管理，從「手工藝」提升到「工程」的層次。
他不再是憑感覺修改 prompt，而是建立了一個自動化的測試流程。每當他想新增或修改一條規則，他會先定義一個能夠驗證該規則是否生效的測試案例，然後執行測試。如果測試失敗，就調整 prompt，再重新測試，直到通過為止。這個過程，本質上就是軟體開發中的「測試驅動開發（Test-Driven Development, TDD）」。
透過這樣一個閉環，他反覆迭代了 34 次，才將他的 Claude Code 設定優化到一個相對穩定的狀態。這個數字本身就說明了問題：可靠的 AI 行為不是一次性「寫」出來的，而是持續「驗證」出來的。這代表一種關鍵的思維轉變：我們的工作不是寫出完美的 prompt，而是建立一個能夠證明 prompt 有效、並在它失效時能即時發現的系統。
如何建立有效的 AI 指令驗證迴圈？
要將這種思維落實到日常工作流程中，並不需要非常複雜的工具，但需要紀律與結構。一個基礎的 AI 指令驗證迴圈，至少應該包含以下幾個部分：
- 指令版本化 (Version Control)：將所有的 prompt、設定檔（如
rules/）、以及 persona 描述都納入 Git 進行版本控制。這使得每一次的修改都有跡可循，並且可以輕易地進行比較和回滾。 - 測試案例庫 (Test Case Repository)：建立一組標準化的輸入範例與預期輸出標準。這些案例應該涵蓋你希望模型遵守的各種核心規則，例如「生成程式碼時必須包含註解」、「回覆時絕對不能使用簡體中文」等。
- 自動化測試框架 (Automated Harness)：撰寫腳本來自動化執行測試流程。這個腳本會讀取特定版本的 prompt，跑遍測試案例庫，並將模型的輸出結果記錄下來。
- 評估與斷言 (Evaluation & Assertion)：定義清晰的成功標準。評估方式可以從簡單的關鍵字匹配、正規表示式檢查，到更複雜的，例如使用另一個 LLM 來判斷輸出是否符合語意要求（即 LLM-as-a-Judge 的概念）。當輸出不符預期時，測試應標記為「失敗」。
- 失敗回流機制 (Failure Feedback Loop)：將失敗的測試結果回饋給開發者，作為下一輪 prompt 優化的起點。這確保了系統的持續改進，而不是讓問題被掩蓋或遺忘。
當我們開始用測試來驅動 prompt 的演進，整個 AI workflow 的樣貌就改變了。團隊的討論不再是「我覺得這樣寫比較好」，而是「這個修改通過了 95% 的既有測試，並解決了我們新發現的 failure case」。這不僅提升了 AI 輸出的可靠性，也為團隊協作提供了客觀的依據，是邁向負責任與可治理 AI 的重要一步。
最終，一個 AI 應用的成熟度，不應由其 prompt 的長度或複雜度來衡量，而應由其驗證流程的嚴謹度來定義。與其繼續在無盡的規則清單中掙扎，不如現在就開始建立你的第一個測試案例。從手寫規則的工藝時代，邁向可測試、可驗證、可治理的工程時代，這才是打造可信賴 AI 系統的務實路徑。
延伸閱讀
- Claude Codeの設定が無限に増える問題にハーネス自己改善ループで立ち向かう：本文主要啟發來源的 Zenn.dev 技術文章。
- Lost in the Middle: How Language Models Use Long Contexts：關於大型語言模型在長文本中資訊提取能力的學術研究。
- Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena：探討使用 LLM 作為自動化評估工具的研究論文。
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。