Claude 為什麼愈用愈笨？Anthropic 內部實戰全指南：提示詞不是越長越好

大型語言模型能力持續升級，但許多開發者仍會遇到一個矛盾現象：明明換上更強的 Claude 模型，實際寫程式或執行任務時，卻感覺它愈來愈笨，不只忽略指令、算錯數字，甚至會在原本能完成的工作上退步。

在 Anthropic 於倫敦舉辦的「Code with Claude」活動中公開多場實戰工作坊，說明如何正確向 Claude 下指令、哪些操作會破壞它在程式碼上的表現、Anthropic 員工每天如何使用 Claude，以及如何透過重新設計上下文與 Agent 架構，讓模型的表現明顯改善。

整場活動反覆傳達的核心觀念是：Claude 表現不佳時，問題往往不是模型智力不足，而是人類給它的上下文太混亂、工具不正確，或要求一個模型同時完成太多不同性質的工作。

正確提示 Claude：先建立評測，不要憑感覺一直加規則

在第一場提示詞實戰中，Anthropic 將企業常見情境分成兩類。

第一類是已經在正式環境中運作的 AI 應用，在更換新模型後，原本正常的功能突然失效；第二類則是從零開始建立一個新的 Agent，需要同時設計提示詞、模型與執行架構。

Anthropic 指出，許多團隊在模型犯錯後，習慣直接在系統提示詞裡增加一條禁令。下一次再出錯，就再補一條。經過數月或數年後，提示詞逐漸變成由不同工程師留下的大型補丁集合，其中混雜角色設定、政策、資料、輸出格式與舊模型的行為修正。

當模型升級後，這些舊補丁可能產生反效果。較早期模型不一定完全遵守限制，但新模型的指令遵循能力更強，反而可能過度執行舊規則。

因此，提示詞優化的起點不是繼續增加文字，而是建立一套評測，也就是 Evals。

評測應包含模型必須穩定通過的基礎案例、過去曾經出錯的回歸案例，以及模型應拒絕、轉交人工或保護資訊的邊界案例。每次修改提示詞或更換模型後，都重新執行測試，確認究竟改善了什麼，又讓哪些能力退步。

Anthropic 以電信客服機器人為例。原始系統提示詞將角色、方案政策、客戶資料、語氣與計算規則全部寫在同一個大段落中。團隊只是刪除冗餘內容，並用 XML 標籤分開不同資訊，模型的部分測試成績便立即改善。

講者提出一項簡單判斷原則：如果人類讀完提示詞後，無法分辨哪些是政策、哪些是資料、哪些只是語氣要求，模型通常也無法正確分辨。

不要只叫 Claude「算準一點」，而要給它真正的工具

提示詞能定義模型的行為，卻不能憑空賦予模型穩定的執行能力。

在客服案例中，使用者詢問月中更換方案後的帳單金額。原始提示詞多次強調「必須正確計算按比例費用」，但模型仍只給出模糊的心算過程，無法穩定提供正確結果。

Anthropic 對此表示，告訴模型「做好一點」沒有太大意義，尤其當任務涉及帳單、庫存、價格或其他需要確定性答案的計算時。

團隊最後加入一個專門處理按比例計費的工具，明確定義輸入、計算公式與輸出。模型遇到相關問題時，不再自行心算，而是呼叫工具，測試案例才穩定通過。

提示詞只是提供目標，還要工具來提供能力。

這項原則也適用於搜尋資料庫、執行程式、讀取大型檔案、建立訂單及呼叫企業內部系統。要求 Claude 在文字上下文中記住並處理所有資訊，通常不如直接給它檔案系統、程式執行環境或專門工具。

什麼會讓 Claude 在程式碼上變笨？答案是上下文污染

到了 Claude Code 的實戰環節，Anthropic 工程師進一步說明，Claude 在長時間工作後表現下降，最常見原因之一是上下文逐漸被塞滿。

Claude Code 會持續讀取檔案、呼叫工具、執行指令並累積對話內容。即使模型擁有大型上下文視窗，也可能被不再相關的舊訊息、執行輸出與程式碼片段占滿。

當真正重要的任務資訊被淹沒，Claude 就可能開始忽略先前要求、重複已完成的工作，或根據過時資訊修改程式。

Anthropic 因此建議，在長時間工作階段中使用 /clear 或 /compact。

/clear 會清除當前工作階段，讓 Claude 重新開始；/compact 則會把目前完成的工作、關鍵決策與待辦事項濃縮成摘要，再用摘要延續下一階段。

後者就像把專案交接給另一名工程師：不保留所有對話細節，只留下繼續完成工作的必要資訊。

另外，開發者也不應把所有規則塞進 CLAUDE.md。這個文件適合記錄專案結構、測試方式、常用命令與長期規範，但如果內容過長或充滿舊模型補丁，同樣會在每次啟動時污染上下文。

Anthropic 員工表示，新模型通常更能遵循指令，因此每次模型升級後，都值得重新檢查 CLAUDE.md，刪除不再必要的規則。

先叫 Claude 找原因和列計畫，不要立即動手改

Anthropic 建議，面對較複雜的程式錯誤，不要一開始就對 Claude 說「幫我修掉這個 Bug」。

更有效的提示方式是要求 Claude 先搜尋程式碼庫、找出可能根因，並提出修復計畫，但暫時不要修改。

人類先檢查 Claude 的理解和計畫，確定方向正確後，再讓它執行。

這種流程可以避免模型在尚未理解系統前便大幅修改程式，也能讓開發者較早發現 Claude 是否走錯方向。

Claude Code 也會在大型任務中建立待辦清單。開發者應觀察待辦內容，一旦出現不合理步驟，就立即按 Escape 中止和修正，而不是等它完成大量錯誤修改後才回頭。

Anthropic 將這種使用方式稱為更聰明的 Vibe Coding：可以讓 AI 自主工作，但仍需透過測試、小幅修改、程式碼檢查與頻繁提交，建立可回復的安全邊界。

Anthropic 每天怎麼用 Claude：讓 Agent 擁有人類也有的基本工具

在 Agent 架構工作坊中，Anthropic 公開內部設計 Agent 時的一項核心原則：優先給 Agent 使用人類工作時也會使用的基本能力。

例如，員工工作時會使用檔案系統、終端機、瀏覽器、搜尋、API 與程式執行環境，Agent 也應先取得這些通用工具，而不是為每個任務建立一個狹窄且固定的專屬工具。

Anthropic 展示一個庫存管理 Agent，原始架構擁有約 400 行系統提示詞、12 項工具，以及三個被包裝成工具的子代理。

隨著功能增加，系統開始出現回歸。模型明明讀取到正確的促銷倍率 3.1 倍，計算時卻改用 1.35 倍。Anthropic 判斷，這並不是模型能力不足，而是系統提示詞太長、不同政策互相衝突，導致上下文出現問題。

團隊首先將約 400 行的系統提示詞縮短至約 50 行。

只有模型無論執行什麼任務都必須知道的內容，才留在系統提示詞中；只有在特定情境才需要的庫存、預測或報告規則，則拆成 Skills，在模型真正需要時才載入上下文。

這種「漸進式揭露」可以減少上下文浪費，也降低不同規則互相干擾的機率。

別把整份 CSV 塞給 Claude，讓它自己寫程式分析

Anthropic 也展示，給 Agent 程式執行能力，可能比新增大量專屬工具更有效。

在原始流程中，Agent 必須把完整 CSV 資料讀進上下文，再由模型直接閱讀和分析，單一任務一度消耗超過 20 萬 Token。

改為讓 Claude 使用檔案系統和 Python 後，模型可以先撰寫程式篩選、統計或整理資料，再只讀取程式輸出的關鍵結果。

調整後，Token 使用量大幅下降，成本與執行時間也同步減少。原因在於 Claude 不再需要把整份資料「放在腦中」，而是把大量機械式工作交給程式處理。

Anthropic 因此建議，不必為每個操作都建立 MCP 工具。

若只有單一 Agent 需要某項能力，可以先建立本地工具；如果能透過 CLI 或程式碼呼叫 API，也可直接使用程式執行。只有當多個 Agent 或多個客戶端需要存取同一套標準化、受治理的工具時，才較適合封裝成 MCP Server。

過多 MCP 工具本身也會占用上下文，反而讓模型更難判斷該使用哪一個。

子代理不是愈多愈好，只適合平行化與獨立審查

Anthropic 表示，子代理最適合兩種情境。

第一種是需要平行處理，例如讓多個 Agent 分別搜尋不同資料來源、探索程式碼庫的不同區域，或同時研究多個方向。

第二種是需要一個「新的腦袋」進行獨立審查。例如，一個 Claude 負責撰寫程式，另一個擁有獨立上下文的 Claude 負責 Code Review。

但如果一項工作只是單純流程，硬拆成多個子代理，會增加上下文傳遞與協調成本。子代理雖然可能正確完成工作，結果在傳回主代理時仍可能失真。

因此，Anthropic 不建議為了看起來更像多 Agent 系統，就將所有工作拆成子代理。

讓 Claude 變聰明的修正：不要靠更長 Prompt，而是重建架構

在活動後段，Anthropic 將各種改善方式歸納成同一項原則：讓 Claude 變聰明的關鍵，不是加入更多提示詞，而是把正確資訊，在正確時間，以正確方式提供給模型。

對複雜任務而言，Anthropic 展示了「生成、評估、修復」架構。

第一個 Agent 生成初版結果；第二個 Agent 逐條檢查規則並列出錯誤；第三個 Agent 根據錯誤報告進行定向修復。

在員工排班案例中，單一模型搭配長提示詞無法穩定遵守所有限制；改用推理能力較強的模型雖然可以完成，Token 與延遲卻大幅上升。

拆成生成、評估、修復三個步驟後，系統通過全部測試，同時降低 Token 與延遲。

這種架構有效的原因，是每個模型只負責一項清楚且容易驗證的任務，而不是要求同一個 Claude 同時理解規則、生成答案、檢查錯誤並自行修改。

從被動工具變成主動同事：Anthropic 用 Routines 自動維護文件

Anthropic 也公開一項更接近日常工作的內部案例。

Claude Code 團隊自年初以來，每週 Pull Request 數量增加約 200%，新功能推出速度提高，但也讓負責維護 Claude Code 與 Agent SDK 文件的工程師承受更大壓力。

團隊因此使用 Claude Code 的 Routines 功能，自動追蹤程式碼變更並建立或更新文件。

Routines 可以在 Anthropic 管理的基礎設施上啟動遠端 Claude Code 工作階段，不需要使用者的電腦保持開機。開發者只要設定提示詞、程式碼庫、可用連接器，以及時間或事件觸發條件，系統便能定期或在 GitHub 事件發生時自動執行。

與傳統 Cron Job 不同，這些工作階段仍然可以被開啟、觀察、中途指導與繼續執行。Anthropic 希望藉此把 Claude Code 從等待使用者按下 Enter 的工具，轉變為能發現問題並主動處理的程式設計同事。

Claude 看起來變笨，很多時候其實是開發者給錯了環境

Anthropic 的分享顯示，模型表現不應只以模型名稱或參數規模解釋。

當系統提示詞過長、規則互相矛盾、上下文被無關資料塞滿、工具設計過度狹窄，或多個子代理溝通失敗時，即使使用更強的模型，最終效果仍可能退步。

反過來說，縮短系統提示詞、按需載入 Skills、提供檔案與程式執行能力、建立持續評測，並把複雜工作拆成可以獨立驗證的步驟，往往能在不更換模型的情況下大幅改善效果。

所謂讓 Claude「變聰明」，本質上並不是找到一句神奇 Prompt，而是讓模型不必在混亂的上下文裡猜測人類真正要它做什麼。