AI 總是不聽話？問題可能不在模型，而在我們給的任務

我們常碰到一個令人困惑的場景：大型語言模型（LLM）在處理簡短、單一的任務時表現得服服貼貼，一旦任務變得冗長、複雜，它就開始「忘記」或忽略我們在初始指令中設定的關鍵約束。這並非模型隨機的「叛逆」或對齊（alignment）的徹底失敗。更精確的描述是，AI 遵循指令的能力是一個有上限的資源，會隨著任務複雜度增加而遞減。理解這一點，能幫助我們將問題從訓練模型的「人格問題」，轉向更務實、可控的系統設計、容量管理與工作流建構問題，這對於打造穩定可靠的 AI 應用至關重要。

AI 為什麼會「選擇性失憶」？

在開發基於 AI 的自動化工作流時，我們經常會設定一些全域規則。例如，在一個自動化程式碼生成的 Agent 中，我們可能會在系統提示（System Prompt）裡明確寫下：「所有程式碼提交（commit）前，必須先編寫並通過單元測試。」

在任務初期，AI Agent 可能會嚴格遵守這個指令。它會先產出功能程式碼，接著撰寫對應的測試案例，驗證通過後再模擬提交。但隨著對話持續、任務鏈變長、程式碼庫逐漸複雜，我們可能會驚訝地發現，在某個環節，Agent 突然就直接提交了程式碼，完全跳過了編寫測試的步驟。它並不是無法編寫測試，而是在繁重的認知負荷下，這個最初的指令被「擠出」了注意力範圍。

這種現象普遍存在於各種長任務中，從生成一份數萬字的深度報告，到管理一個多步驟的專案排程。模型並非存心違抗，而是其「遵循指令的能力」已經耗盡。

為什麼 AI 的「服從」不是開關，而是階梯？

開發者 cleverhoods 提出了一個非常有洞察力的框架，稱為「指令系統能力階梯」（Instruction systems capability ladder）。這個框架將模型遵循指令的能力劃分為從 L0 到 L7 的不同層級，它清晰地揭示了這項能力並非一個「有或無」的二元開關，而是一個連續的光譜。

• 低階梯（約 L1-L3）：模型能處理單一、具體的指令，例如「總結這段文字」或「把這句話翻譯成日文」。這是我們在多數聊天機器人互動中體驗到的層級。
• 中階梯（約 L4-L5）：模型能處理包含多個步驟、帶有條件約束的任務。例如，「閱讀這份文件，找出所有提到『專案 A』的部分，並將其整理成一個列表，但排除所有預算相關的數字。」這需要模型在執行過程中持續維護一個內在的任務狀態。
• 高階梯（約 L6-L7）：模型能夠理解並執行抽象的、長期的、甚至帶有自我修正意味的指令。前述「先寫測試再提交」就屬於這個範疇。它不僅是一個動作，更是一個在整個工作流中都必須維持的「行為準則」。根據 Google DeepMind 的研究，即使是頂尖模型，在處理這類需要長期記憶與複雜推理的指令時，成功率也遠非 100%。

當我們硬塞一個遠超出模型當前能力階梯的任務給它時，它就像一個試圖一次跳上三階樓梯的人，最終的結果往往是踉蹌或跌倒。尤其在長對話中，模型的上下文視窗（Context Window）雖然巨大（例如 Claude 3 的 200K tokens），但有效的「注意力空間」是有限的。複雜的任務會快速消耗這個空間，導致模型遺忘或忽略那些不是當下核心焦點的指令。

與其責備模型「不聽話」，不如反思我們的系統是否給了它一個「爬不上去的梯子」。

如何將「對齊失敗」重新框架為「容量管理」問題？

一旦我們接受了「能力階梯」這個心智模型，解決問題的方向就豁然開朗。我們不再執著於用更精巧的提示工程（Prompt Engineering）去「馴化」一個心猿意馬的模型，而是轉向設計一個更合理的系統，將大任務分解成模型能穩定處理的小單元。這是一個典型的系統設計思維轉變。

具體來說，我們可以從以下幾個方向著手：

1. 任務分解（Task Decomposition）：這是最核心的策略。不要給一個 L4 能力的模型一個 L6 的任務。將「開發一個新功能」這個宏大指令，分解成「設計 API 規格」、「編寫主要邏輯」、「編寫單元測試」、「撰寫文件」等一系列更小、更具體的子任務。每個子任務都落在模型能夠可靠執行的能力範圍內。
2. 狀態外部化（State Externalization）：不要期望模型在長達數十輪的對話中記住所有細節。系統應該負責管理狀態。例如，將「必須先寫測試」這個規則，從一個僅存在於提示中的「記憶」，變成工作流中的一個強制檢查點。在程式碼提交前，由外部工具或另一個 Agent 檢查是否存在對應的測試檔案，若無則駁回。這篇來自 a16z 的文章深入探討了LLM 應用的新興架構，其中就強調了外部化記憶與工具的重要性。
3. 專用 Agent 與工作流（Specialized Agents & Workflows）：與其讓一個「全能」Agent 處理所有事，不如設計一個由多個專用 Agent 組成的協作流程。例如，一個「開發 Agent」專注於寫程式，一個「品保 Agent」專注於執行與生成測試。當開發 Agent 完成程式碼後，將其交付給品保 Agent，後者根據明確的指令來執行測試。這種分工模式不僅降低了單一模型的認知負荷，也讓系統的行為更可預測、更穩定。史丹佛大學的 Generative Agents 研究便是一個例證，展示了多 Agent 系統如何模擬複雜的社會行為。

總結來說，當我們下次遇到 AI 不遵循指令時，第一反應不該是「這個模型不夠聰明」或「Alignment 沒做好」。更具建設性的問題是：「我設計的任務，是否超出了它所在的能力階梯？我能否透過更好的系統設計，將任務難度與模型能力對齊？」從這個角度出發，我們才能打造出真正穩健、可靠、可擴展的 AI 系統。

延伸閱讀

• The instruction systems capability ladder (cleverhoods 的原始文章)
• Instruction Following for Large Language Models: A Survey (一篇關於 LLM 指令遵循能力的學術綜述)
• AI Agents (Latent Space 對 AI Agent 架構的深度探討)

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。