這八個原則我不是開發者，哪些最值得我立刻開始做？
如果你只用 Claude.ai 的一般對話，最值得立刻套用的是這三個：
原則三（上下文污染）：長對話裡 Claude 開始答非所問，或者忘記你說過的事，不要繼續在同一個對話裡追問，直接開新對話，把重點整理成一段背景說明再開始。這個改變幾乎立刻有效果。
原則二（給工具）：如果你需要 Claude 查即時資料或做精確計算，打開 Claude.ai 的網路搜尋功能。不要叫它靠記憶回答「現在的匯率是多少」或「某個數字的精確計算」，給它工具才能給你準確答案。
原則四（先診斷再執行）：遇到你想叫 Claude 幫你修改或改善某個東西的時候，先問「你覺得問題在哪裡，你打算怎麼做」，看完它的計畫再說「好，去做吧」。這個小改變能讓你更早發現它有沒有理解錯誤。
原則一（建立評測）和原則八（架構設計）對日常對話用戶來說比較難直接套用，但它們背後的邏輯——「不要靠感覺，要靠可驗證的結果來判斷改善」——是一個值得記住的通用思維。
「上下文污染」到底有多嚴重？我的對話大概要多長才會出現這個問題？
沒有一個精確的「幾個訊息之後」的門檻，因為上下文污染不只和訊息數量有關，更和每條訊息的內容有關。
幾個讓上下文快速污染的因素：
從體感上說，如果一個對話超過 20-30 輪（你一條、Claude 一條算一輪），而且內容很密集，通常已經值得考慮開新對話了。如果你感覺 Claude 開始忽略你前面說的重要事情，或者開始重複已經做過的工作，這是明確的信號。
一個簡單的預防做法：在每個新的對話開頭，花 30 秒寫一個「本次對話的目的和背景」段落，而不是直接進入任務。這個習慣能讓每次對話即使不長，Claude 也有足夠的上下文理解你的需求。
「生成→評估→修復」架構聽起來很像讓 Claude 自我修改，這和直接叫它修改有什麼根本的差別？
這個問題觸碰到一個很核心的點。表面上看，兩者都是「Claude 生成，然後改」，但背後的機制完全不同。
直接叫 Claude 修改的問題：同一個 Claude，在同一個上下文裡，先生成答案，然後自己檢查，然後自己修改。問題是它在生成答案的時候，已經在某種程度上「承諾」了這個方向。自我檢查時，它很難真正從頭質疑自己，因為它的上下文裡已經有了「自己的解法」。這就像叫你自己校對你自己剛剛寫的文章——很難發現自己的盲點。
生成→評估→修復的不同：評估的那個 Agent 擁有獨立的上下文，它沒有「生成這個答案」的包袱。它只負責一件事：根據明確的規則清單，找出問題在哪裡。它不需要同時理解生成的邏輯，只需要驗證輸出是否符合規則。
這就是 Anthropic 說的「新的腦袋」——不是 Claude 更聰明了，而是角色分離讓每個模型只需要做一件容易驗證的事，而不是同時做所有事。
這些原則對我「每天用 Claude 幫我寫文字」的場景有什麼具體啟示？
非常有，而且可以直接套用。以下針對日常文字工作的具體翻譯：
提示詞不是越長越好（原則一、八）：如果你有一段很長的「寫作指引」，試試把它縮短到只有最核心的要求。多餘的規則不只沒用，還可能讓 Claude 在「遵守規則 A」和「遵守規則 B」之間搖擺。最好的測試是：你能把這段指引說給一個聰明的人聽，讓他立刻理解你要什麼嗎？如果說起來很長很複雜，提示詞可能也需要簡化。
分階段比一次到位更好（原則四、八）：叫 Claude 「幫我寫一篇完整的分析報告」，不如分成「先給我一個大綱」→「你覺得這個架構有沒有問題」→「好，現在依照這個大綱寫第一個部分」。每個步驟都讓你能確認方向，也讓 Claude 每次只做一件事。
長對話開新對話（原則三）：如果你今天和 Claude 討論了一篇文章的架構，明天繼續討論這篇文章的時候，不要繼續昨天的對話——開新對話，把已確定的架構作為背景貼進去。這能讓 Claude 在清晰的上下文裡工作，而不是在昨天一堆「嗯我覺得可以試試這樣」的探索性討論裡翻找重點。
你有沒有遇過這種情況：換了更新的 Claude 模型，結果感覺它反而更難用了？明明之前能跑的流程，換模型之後開始出錯；越來越長的提示詞，感覺越來越沒用；叫它修 bug，結果引入了更多 bug。
Anthropic 在倫敦舉辦的「Code with Claude」活動裡，工程師們用了一整天時間回答這個問題。核心結論只有一句話：Claude 表現不佳，大多數時候不是模型的問題，而是我們給它的環境出了問題。
以下是從這場活動整理出來的八個原則。這些不是技術文件，而是任何用 Claude 工作的人都能直接套用的思維框架。
Anthropic 描述了一個很多人都經歷過的模式：模型每次出錯，你就在提示詞裡加一條規則。時間一長，提示詞變成一個什麼都有的大雜燴——角色設定、政策規定、資料、輸出格式、舊版模型的行為修正，全都擠在同一個地方。
問題是，當你換上一個更強的新模型，它的指令遵循能力反而更強，會更認真執行那些你加進去但已經不合時宜的舊規則。結果就是：模型越強，表現越奇怪。
這不是模型變笨了，是你給它的上下文讓它沒辦法發揮。
Anthropic 觀察到，大多數團隊調整提示詞的方式是「憑感覺」：改一下，試一試，感覺好一點就繼續；感覺沒差就再改。這個方法的問題是，你不知道改了什麼有用、改了什麼反而讓其他地方退步。
更好的做法是先建立一套評測（Evals）：
每次修改提示詞或換模型之後，重新跑一遍這些評測。你才能知道哪裡真的改善了，哪裡悄悄退步了。
Anthropic 用電信客服機器人示範：光是把混在一起的提示詞，用 XML 標籤分成「角色設定」「政策規定」「資料」幾個區塊，不更換模型、不加新規則，部分測試成績就立刻改善了。
提示詞能告訴 Claude 要做什麼，但不能賦予它做不到的能力。
Anthropic 舉的例子很直接：客服機器人需要計算月中換方案後的按比例帳單。提示詞裡寫了很多次「必須正確計算」，但模型每次都給出模糊的心算過程，沒辦法穩定給出正確數字。
解決方法不是繼續叫它「算更準一點」，而是給它一個計算工具——明確定義輸入、公式和輸出格式。有了工具，模型不再自己猜，直接呼叫工具就能得到正確答案。
這個原則適用於所有需要確定性答案的任務：查資料庫、執行程式、讀取大型檔案、建立訂單。在文字上下文裡靠模型記住並處理所有事情，通常不如給它正確的工具。
Claude Code 在長時間工作後表現下降，最常見的原因是上下文被塞滿了。
Claude 在工作過程中會持續讀取檔案、執行指令、累積對話內容。就算上下文視窗很大，也可能被不再相關的舊訊息、執行輸出、程式碼片段占滿。當真正重要的資訊被淹沒在雜訊裡，Claude 就開始忽略先前的要求、重複已完成的工作，或根據過時的資訊修改程式。
兩個對應的做法：
同樣的道理也適用於 CLAUDE.md 這個設定檔：它適合記錄專案結構、測試方式、長期規範，但如果內容太長或充滿了給舊模型的補丁規則，每次啟動都會污染上下文。模型升級後，值得重新檢查並刪掉不再需要的規則。
面對複雜的錯誤，不要一開始就叫 Claude「幫我修掉這個 bug」。
更有效的流程是：先叫它搜尋程式碼庫、找出可能的根本原因、列出修復計畫——但先不要動手改。你看過計畫、確認方向正確之後，再讓它執行。
這樣做的好處是：在模型還沒真正理解系統的時候，就大幅修改程式碼，往往會引入新問題；讓你更早發現 Claude 有沒有走錯方向，在花了大量時間之前就能修正。
Anthropic 把這種用法稱為「更聰明的 Vibe Coding」：可以讓 AI 自主工作，但透過頻繁的小步驟確認、程式碼審查和提交，建立可以回復的安全邊界。關鍵是「能中斷」，而不是等它跑完再收拾爛攤子。
Anthropic 設計 Agent 的一個核心原則是：優先給 Agent 人類工作時也會用到的基本能力。
員工工作時用的是：檔案系統、終端機、瀏覽器、搜尋、程式執行環境、API。Agent 也應該先取得這些通用工具，而不是為每個任務建一個狹窄的專屬工具。
Anthropic 展示了一個庫存管理 Agent 的案例：原本有約 400 行系統提示詞、12 個工具。隨著功能增加，開始出現奇怪的問題——模型明明讀到了正確的促銷倍率 3.1 倍，計算時卻用 1.35 倍。
診斷結果不是模型能力不足，而是系統提示詞太長、規則互相衝突，導致模型在混亂的上下文裡猜錯了。解法：把 400 行提示詞縮短到 50 行，只留任何任務都需要的核心資訊；其他的庫存規則、預測規則、報告規則拆成 Skills，真正需要時才載入。
這個原則顛覆了很多人的直覺。
很多人的做法是：把整份 CSV 或大量資料貼進上下文，叫 Claude 直接讀取分析。Anthropic 展示，這種做法單一任務可能消耗超過 20 萬 Token，而且效果不好——模型要把整份資料「放在腦中」，這不是它最擅長的事。
更好的做法是：給 Claude 檔案系統和程式執行能力，讓它自己寫 Python 來篩選、統計、整理資料，再只讀取程式輸出的關鍵結果。Token 用量大幅下降，執行時間也縮短，因為大量機械式工作交給程式處理，不是交給模型的注意力。
延伸原則：不必為每個操作都建立 MCP 工具。如果只有一個 Agent 需要某個能力，先建本地工具；如果能透過程式直接呼叫 API，就直接用程式。只有多個 Agent 或多個客戶端需要存取同一套標準化工具時，才適合封裝成 MCP Server。工具太多本身也會占用上下文，讓模型更難判斷該用哪個。
子代理（Subagent）適合兩種情境，除此之外不要硬拆：
如果一項工作只是單純的流程，硬拆成多個子代理會增加上下文傳遞和協調的成本。子代理就算正確完成了工作，把結果傳回主代理的過程中也可能失真。
Anthropic 的建議：不要為了「看起來像多 Agent 系統」就把所有工作拆開。
Anthropic 把各種改善方式歸納成一個核心原則：讓 Claude 更好用的關鍵，不是寫出更長的提示詞，而是把正確的資訊，在正確的時間，以正確的方式提供給模型。
對複雜任務，Anthropic 展示了「生成→評估→修復」架構：
員工排班的案例裡，用單一模型加長提示詞，無法穩定通過所有限制；換成推理能力更強的模型雖然能過，但 Token 和延遲大幅上升。拆成三個步驟之後，通過所有測試，同時降低了 Token 和延遲。
原因很直接：每個模型只負責一件清楚且容易驗證的事，而不是要求同一個 Claude 同時理解規則、生成答案、檢查錯誤、再自行修改。
這八個原則的大多數，不需要你是開發者也能套用。把它們翻譯成日常用 Claude 的語言：
Anthropic 在活動最後說的話值得記住：讓 Claude「變聰明」，本質上不是找到一句神奇的提示詞，而是讓模型不必在混亂的上下文裡猜測你真正想要什麼。