從混亂到高效：用這 8 個心法馴服 Claude，告別無效調試
整理版優先睇
有效使用 Claude 嘅關鍵在於先思考架構、優化 CLAUDE.md 同管理上下文，而唔係一味打字。
呢篇文章出自一位有多年軟件工程經驗嘅開發者，佢分享咗 8 個心法馴服 Claude Code，解決常見嘅無效調試問題。作者認為大部分人一開始就打字係最大錯誤，實際應該先思考，尤其係用計劃模式（雙擊 Shift+Tab）諗清楚系統架構先。佢強調輸出完全取決於輸入，輸入質素差，就算用 Opus 4.5 都冇用。整體結論係：要將 Claude 變成系統一部分，透過 Claude.md、外部記憶體、工具鏈、自動化嚟持續改善，而唔係靠單次對話。
作者指出 Claude.md 係最大槓桿點，必須保持簡短、具體、講明原因，並且隨住項目演進不斷更新。佢亦提醒上下文窗口實際喺 20-40% 使用率時質量就開始下降，所以要限定對話範圍、用外部檔案做持久記憶、必要時用複製貼上重置技巧清空上下文。另外，提示工程唔係神秘藝術，清晰具體嘅指示比含糊好，仲要講明「唔好做啲咩」同「點解要咁做」。
最後，作者建議善用工具：MCP 連接外部服務、Hooks 自動執行檢查、自訂斜線命令封裝常用提示。建立系統而非一蹴而就，用 -p 旗標做無頭模式，整合到自動化流程，再透過日誌改進 Claude.md，形成飛輪效應。
- 結論：輸出即輸入，先思考架構、寫好提示，先至係高效使用 Claude 嘅關鍵。
- 方法：用計劃模式（雙擊 Shift+Tab）諗清楚系統設計；優化 Claude.md 檔案，保持簡短、具體、講明原因，並持續更新。
- 差異：Claude 嘅上下文窗口喺 20-40% 使用率時質量就開始下降，所以要用外部記憶體（如 SCRATCHPAD.md）、限定對話範圍、必要時 /clear 重置。
- 啟發：提示工程係最基本溝通，要具體、限制、範例，唔好畀 Claude 太多創作自由；講「點解」可以提高執行質素。
- 可行動點：設定 Hooks 自動做 Prettier 同類型檢查；建立自訂斜線命令；用 MCP 連接 Slack/GitHub；用無頭模式 (-p) 整合到 CI/CD 流程。
CLAUDE.md 最佳實踐
保持簡短（唔超過 150 條指令）、具體相關、講明原因、隨項目更新。例子：用 TypeScript 嚴格模式，因為避免隱含 any 類型 bug。
MCP（模型上下文協議）
讓 Claude 連接外部服務（Slack、GitHub、數據庫），減少手動複製貼上。可自建 MCP 服務器。
先思考，先過打字
大部分人一開波就打字，但呢個係最大錯誤。作者話十次有十次，用計劃模式（雙擊 Shift+Tab）先諗清楚系統設計，輸出結果遠好過即興輸入。
先思考，再鍵入，比先鍵入然後希望Claude找出問題所在嘅結果要好得多
如果你冇軟件工程經驗，可以同 Claude 深入傾偈，問清楚系統設計方案，互相提問，而唔係單向指令。呢個適用於任何任務，包括總結電郵呢啲細微嘢。
架構決定輸出質素
架構就好似畀一個人輸出嘅範圍，太闊會搞到 Claude 亂嚟。例如「建立認證系統」太含糊，應該講清楚：「用現有用戶模型做 Email/密碼認證，喺 Redis 存 session，24 小時過期，加 middleware 保護 /api/protected」。
越具體嘅架構指示，Claude 越唔會擦邊球
作者反覆強調：架構係下一步，唔可以跳過。先諗清楚最終狀態，再叫 Claude 做嘢。
CLAUDE.md：你嘅最大槓桿
CLAUDE.md 係 Claude 每次對話前都會讀嘅入門材料。大部分人要唔係忽略佢，就係塞滿垃圾。關鍵係保持簡短，因為 Claude 一次只可靠執行約 150-200 條指令，系統提示已用 50 條。
你加嘅每一條指令都會爭奪注意力，所以 CLAUDE.md 要似「如果你聽日會失憶，留俾自己嘅筆記」
- 1 保持簡短：唔好解釋 component 係咩，Claude 知道。
- 2 具體相關：記低你 project 特有嘅流程、指令、bash 命令。
- 3 講明原因：唔止話「用 TypeScript 嚴格模式」，要加「因為避免隱含 any 類型 bug」。
- 4 持續更新：每當你要糾正 Claude 兩次同一件事，就即刻用 # 加落檔案。
上下文窗口嘅陷阱與對策
Claude 嘅上下文窗口（例如 Opus 4.5 有 200k tokens）實際喺 20-40% 使用率時輸出質量就開始下降。壓縮（/compact）唔會神奇回復質量。
一旦質量開始下降，越多上下文只會越差
記住：Claude 係無狀態嘅，每次對話由零開始，只有 CLAUDE.md 保留住 project 情境。
提示工程、工具同系統化
提示唔係神秘藝術，係最基本溝通。具體 > 含糊，限制 > 開放，範例 > 說明。仲要講明「唔好做啲咩」同「點解」。
「保持簡單，唔好加我冇要求嘅抽象概念」呢類限制令 Claude 唔會過度工程
善用工具：MCP 連接 Slack/GitHub 等外部服務；Hooks 自動執行 Prettier 或 TypeScript 檢查；自訂斜線命令（.claude/commands）封裝常用提示。
最後，當 Claude 陷入循環，唔好硬推，應該 /clear 重新開始、簡化任務、自己寫範例，或者重新構思問題角度。
先思考
大部分人都覺得，用Claude Code同其他AI工具，第一件事就係打字（或者開始講嘢）。但呢個可能係你一開始就會犯嘅最大錯誤之一。實際上，你需要做嘅第一件事係諗清楚。
十次有十次，我用計劃模式得到嘅輸出結果，都比我開聲講嘢同將所有嘢塞入Claude Code嗰時好得多。仲差好遠添。
對某啲人嚟講，呢件事講就容易做就難。你哋可能冇多年軟件工程經驗，冇辦法自己諗掂呢個問題。關於呢點，我有兩個建議：
開始學習。如果你從來唔學習，就算每次淨係學少少，你都係緊自毀前程。 同 ChatGPT/Gemini/Claude 進行深入交流，準確描述你想建立嘅系統，問 LLM 喺系統設計方面你可以採取嘅各種方案，最後確定一個解決方案。你同 LLM 應該互相提問，而唔係單向溝通。
呢個適用於所有工作。亦包括好細嘅任務，例如總結電郵。要求 Claude 建立功能之前，先諗下個架構。要求 Claude 重構某個功能之前，先諗下最終狀態係點樣。要求 Claude 除錯之前，先諗下你對問題嘅實際瞭解。
喺計劃模式之下，你掌握嘅資訊越多，你嘅輸出就會越好，因為輸入就會越好。呢種模式係一致嘅：先諗清楚，再打字，比起先打字然後希望Claude揾出問題所在，結果好得多。
架構
呢個就帶出我下一個觀點——架構。架構，尤其係軟件工程嘅架構，就有啲似俾一個人輸出，僅此而已。呢個就為點樣得到輸出留低好大嘅迴旋餘地，而呢個正正係人工智能生成代碼嘅問題所在。
如果你講嘅係「俾我建立一個認證系統」呢類超級闊嘅嘢，而唔係「用現有嘅用戶模型建立電郵/密碼認證，喺 Redis 入面儲存會話並 24 小時過期，加入中間件去保護 /api/protected 之下嘅所有路由」，你就睇到當中嘅分別。
計劃模式
撳兩下 Shift+Tab，你就進入咗計劃模式。相信我，呢個淨係需要你 5 分鐘時間，但就可以幫你慳返幾個鐘嘅除錯時間。
CLAUDE.md
CLAUDE.md 係一個標記符檔案。Markdown 係一種文字格式，人工智能模型可以好好處理呢種格式，尤其係Claude，佢比我測試過嘅大多數其他模型都處理得更好。
當你啟動Claude Code會話嗰時，Claude要做嘅第一件事就係讀取你嘅 CLAUDE.md 檔案。呢個檔案入面每一條指令都會影響Claude點樣處理你嘅項目。佢本質上係Claude每次對話前都會閲讀嘅入門材料。
大部分人一係完全忽略佢，一係喺裏面塞滿垃圾，令Claude嘅工作變得更差，而唔係更好。資訊過多或過少都會令模型輸出變差。
呢個先係真正重要嘅：
盡量簡短。Claude一次只可以可靠執行大約 150 到 200 條指令，而Claude Code嘅系統提示已經用咗當中大概 50 條。你加入嘅每一條指令都會爭奪注意力。如果你嘅 CLAUDE.md係一本小說，Claude就會開始隨意忽略一啲嘢，而你唔知係邊啲嘢。令佢同你嘅項目具體相關。唔好解釋組件文件夾係乜。Claude知道組件係乜。話俾佢知一啲奇怪嘅嘢，例如真正重要嘅 bash命令。所有屬於你流程嘅嘢都應該放埋入去。話俾佢知點解，而唔係淨係話俾佢知係乜。喺呢方面，Claude有啲似人類。當你話俾佢知指令背後嘅原因，Claude會比你淨係話佢做乜更好咁執行指令。「用 TypeScript嚴格模式」係可以嘅。而「用TypeScript嚴格模式，因為我哋喺生產環境遇到過隱含 any 類型嘅 bug」就更好。「點解」為Claude提供咗做判斷嘅語境，而呢樣嘢係你意料之外嘅。你會驚訝於咁做嘅效果。不斷更新。工作嘅時候撳 #掣，Claude會自動喺CLAUDE.md入面加入說明。每當你發現自己喺同一件事上糾正咗Claude兩次，呢個就預示住佢應該被加入檔案。隨住時間推移，你嘅CLAUDE.md檔案就會成為你嘅代碼庫點樣實際運作嘅活文檔。
糟糕的 CLAUDE.md 睇起嚟就好似為新員工編寫嘅文檔。好嘅 CLAUDE.md 睇起嚟就好似如果你知道自己聽日會失憶，就會俾自己留低嘅筆記。
上下文窗口嘅限制
例如，Opus 4.5 有一個 200,000 標記嘅上下文窗口。但大部分人冇意識到嘅係：當你用到 100%（取決於你係經API定桌面應用程式用）。
喺 20–40% 上下文使用率左右，輸出質量開始下降，就算下降幅度唔大。如果你曾經遇到Claude Code壓縮後輸出仍然好差嘅情況，就係呢個原因。喺壓縮之前，模型嘅質量已經下降咗，而壓縮並唔可以神奇咁恢復質量。（撳 /compact 進行壓縮）
你送出嘅每一條訊息、Claude讀取嘅每一個檔案、生成嘅每一段代碼、每一個工具結果，所有呢啲都會累積。一旦質量開始下降，更多上下文會令情況變得更差，而唔係更好。所以，以下幾件事實際上幫到避免出現差嘅語境：
確定對話範圍。每個功能或任務淨係進行一次對話。唔好用同一個對話嚟建立認證系統，然後再重構數據庫層。上下文會撈埋一齊，Claude會覺得混亂。我知道睇緊呢篇文章嘅人入面，至少有一個會犯呢種錯誤。 用外部記憶體。如果你正在處理複雜嘅工作，可以叫 Claude 將計劃同進度寫入實際檔案（我用 SCRATCHPAD.md或plan.md）。呢啲檔案會喺唔同會話之間持續存在。當你聽日返嚟，Claude可以讀取檔案並從你離開嘅地方繼續，而唔係由零開始。附註：如果你有一個檔案分級系統，咁就將呢啲檔案保留喺頂層。呢個就係令呢啲檔案喺你決定建立嘅每個任務/功能中都能發揮作用嘅方法。 複製貼上重置。呢個係我成日用嘅一招。當上下文變得臃腫，我會從終端複製所有重要資訊，執行 /compact獲取摘要，然後/clear完全清除上下文，然後淨係貼上重要資訊。新嘅上下文保留咗關鍵資訊。呢個比起俾Claude喺退化嘅上下文中掙紮好得多。知道幾時清除。如果對話已經偏離咗軌道，或者積累咗大量無關嘅上下文，淨係需要 /clear，然後重新開始。呢個點都好過喺混亂中掙扎。Claude仍然保留住CLAUDE.md，所以你唔會丟失項目上下文。十之八九，用/clear其實比唔用好，雖然聽起嚟違反直覺。
有效嘅心智模型
Claude係無狀態嘅。每一次對話都係由零開始，除咗你明確俾佢嘅嘢。按呢個嚟制定計劃。
提示就係一切
人們花幾星期時間學習框架同工具。但佢哋冇花時間學習點樣同實際生成代碼嘅嘢溝通。
提示唔係乜嘢神秘嘅藝術。佢可能係最基本嘅溝通方式。同任何交流一樣，清晰表達比含糊表達更能得到好效果。每。每一次。每一次。
真正嘅幫助
具體說明你想要乜。「建立一個身份驗證系統」俾咗Claude創造性嘅自由，但佢用得唔好。而「用現有嘅用戶模型構建電郵/密碼驗證，喺 Redis入面儲存會話，並加入中間件去保護/api/protected之下嘅路由」就俾咗Claude一個明確嘅目標。就算係咁，都唔完美。話俾佢知唔好做乜。Claude有傾向性。Claude 4.5 尤其鍾意過度工程化——額外檔案、不必要嘅抽象、你冇要求嘅靈活性。如果你想要最簡單嘅嘢，就話「保持簡單。唔好加我冇要求嘅抽象概念。如果可能，淨係一個檔案就得」。另外，一定要交叉引用Claude生成嘅檔案，因為你唔想最後產生技術債務，尤其係當你正喺度構建一個超級簡單嘅嘢，結果為一個任務整咗 12 個唔同嘅檔案，而呢個任務實際上只需要幾行代碼就解決到。 解釋原因。「我哋需要佢快，因為佢喺每個請求上運行」，呢句話改變咗Claude處理問題嘅方式。「呢個係一個我哋會掉咗嘅原型」會改變邊啲取捨有意義。Claude冇辦法讀取你冇提及嘅約束條件。 記住：輸出就係一切，但佢只係嚟自輸入。如果你嘅輸出好差，咁你嘅輸入都好差。呢樣嘢冇得避。
你一定要記住嘅係，人工智能嘅目的係加快我哋嘅速度，而唔係完全取代我哋，尤其係喺非常專業嘅軟件工程時代。Claude仍然會犯錯。我相信佢會繼續犯錯，就算佢會隨住時間變得更好。所以，能夠識別呢啲錯誤，實際上會解決你好多問題。
差嘅輸入 == 差嘅輸出
當得到差嘅結果，人們會怪個模型。「Claude唔夠聰明」或者「我需要一個更好嘅模型」。現實係：你太差啦。如果你用 Opus 4.5 呢類好模型得到差嘅結果，即係你嘅輸入同提示好差。完全正確。
模型好重要。實際上非常重要。但喺呢一點上，模型嘅質量係關鍵。瓶頸幾乎總係喺人嗰邊：你點樣組織你嘅提示，你點樣提供上下文，你點樣清楚傳達你真正想要嘅嘢。
如果你嘅成績一直唔好，解決方法唔係換模型。解決方法係喺以下方面做得更好：
點樣寫提示：具體 > 含糊；限制性 > 開放性；示例 > 說明。 點樣組織請求：將複雜嘅任務分成幾個步驟；喺實施前就架構達成一致；審查輸出結果並進行迭代。 點樣提供上下文：要做好呢項工作，Claude需要了解啲乜？你做咗邊啲Claude睇唔到嘅假設？
即係話，唔同模型之間確實有差異：
Sonnet更快、更平。佢非常適合路徑清晰嘅執行任務——編寫模板、根據特定計劃進行重構、實現已經做咗架構決策嘅功能。Opus運行速度更慢，成本更高。佢更適合複雜嘅推理、規劃同需要Claude深入思考取捨嘅任務。
可行嘅工作流程：用 Opus 做規劃同做架構決策，然後切換到 Sonnet（Claude Code入面嘅 Shift+Tab 掣）進行實施。呢個取決於你嘅任務，有時你都可以用 Opus 4.5 做實施。不過，如果你經 API 用選項卡嚟做呢件事，咁就諗下賣腎啦。
您的 CLAUDE.md 會確保兩個模型都喺相同嘅約束條件下運行，所以交接過程係乾淨利落嘅。
MCP、工具同配置
Claude擁有豐富嘅功能：MCP 伺服器、鈎子、自定義斜線命令、settings.json 配置、技能插件。
你並唔需要曬呢啲。但你應該真係試下，因為如果你唔試，好可能就會浪費時間或金錢。我向你保證，如果你留意Claude Code嘅創始人鮑里斯（Boris），Claude至少會有一項你唔知道嘅新功能。
MCP
MCP（模型上下文協議）令 Claude 可以連接外部服務：Slack、GitHub、數據庫、API。
如果你發現自己成日將資訊從一個地方複製到 Claude 入面，咁好可能有一個 MCP 伺服器可以自動完成呢項工作。有大量嘅 MCP 市場；如果冇 MCP，佢都只係一種獲取結構化數據嘅方式，所以你可以為任何你需要加入但目前仲未有嘅工具創建自己嘅 MCP 伺服器。
如果你揾到一個唔存在嘅 MCP 伺服器，我會覺得非常驚訝。
鈎子（Hooks）
鈎子可以令你喺 Claude 更改之前或之後自動運行代碼。想令 Prettier 喺Claude接觸嘅每個檔案上運行？鈎子。想要喺每次編輯後做類型檢查？鈎子。咁就可以立即發現問題，而唔係任由佢哋堆積。
呢個實際上都有助消除技術債務。如果你喺每一千行後設置一個特定鈎子，你就有一個潛在清理代碼嘅安全功能。當Claude審核你嘅 PR 嘅時候，呢個應該會好有幫助。
自定義斜線命令
自定義斜線命令只係你重複使用嘅提示，打包成命令。創建一個 .claude/commands 文件夾，加入包含提示資訊嘅標記檔案，而家就可以用 /commandname 運行佢哋啦。
如果你成日運行同類任務——除錯、審查、部署——咁就將佢變成命令啦。
如果你有 Pro Max 計劃（我每月畀 200 美元），點解唔試下 Claude 提供嘅所有服務呢？睇下邊啲有效，邊啲無效。反正你都畀咗錢。
仲有一點：唔好一試就放棄。呢啲模型基本上每星期都在改進。一個月前唔得嘅嘢，而家可能就得。作為早期採用者，意味住要保持好奇心同重新測試。
當Claude陷入困境嗰陣
有時，Claude只係喺度循環。佢嘗試同樣嘅嘢，失敗，再嘗試，再失敗，然後繼續。或者佢自信滿滿咁實現咗一啲完全錯嘅嘢，而你花咗二十分鐘試圖解釋原因。
當呢種情況發生，本能反應就係繼續推進：更多指導、更多糾正、更多上下文。但實際上，更好嘅做法係完全改變方法：
從簡單開始——理清對話。積累嘅上下文可能會令對話變得混亂。 /clear俾你一個全新嘅開始。簡化任務。如果Claude正為一個複雜嘅任務苦惱，咁就將佢分解成更細嘅部分。喺合併之前，先令每一部分都發揮作用。但實際上，如果Claude喺複雜任務中掙扎，即係你嘅計劃模式唔夠充分。 展示而唔係講述。如果Claude一直誤解你嘅意圖，咁就自己寫一個最簡單嘅例子。「輸出應該係咁樣。而家將呢個模式應用落其他方面」。Claude非常擅於理解成功嘅指標係點樣，並能真正按照呢啲指標去做，佢知道咩係好嘅範例。 要有創意。嘗試唔同角度。有時，你提出問題嘅方式同Claude嘅思維方式並不一致。重新構思——「將佢作為狀態機實現」同「處理呢啲轉換」——可以取得進展。 及早識別循環。呢度嘅「元技能」就係及早識別你是否陷入咗一個循環。如果同樣嘅事你已經解釋咗三遍，Claude仲係唔明，咁再解釋都冇用。改變一啲嘢。
建立系統
從Claude得到最大價值嘅人唔係將佢用於一次性任務。佢哋正在構建系統，而 Claude 就係其中一個組成部分。
但Claude Code遠不止於此。佢有一個 -p 標誌，用於無頭模式。佢可以運行你嘅提示，並喺唔入交互界面嘅情況下輸出結果。呢個意味住你可以編寫腳本：將輸出經管道輸送到其他工具；將佢同 bash 命令相連；將佢集成到自動化工作流程入面。
企業將佢用於自動公關審查、自動支持單回覆、自動記錄同文檔更新。所有呢啲都會被記錄、審計，並根據邊啲有效、邊啲無效而不斷改進。
飛輪：Claude犯咗一個錯誤，你查看日誌，改進 CLAUDE.md 或工具，Claude下次會做得更好。呢個化合物而家，我正喺度叫Claude改進自己嘅 Claude.md 檔案。經過幾個月嘅迭代，以呢種方式構建嘅系統比起動時有咗明顯改善——同樣嘅模型，只係配置更好咗。
如果你只係交互式咁用 Claude，咁你就失去咗價值。諗下，喺你嘅工作流程入面，Claude可以喺邊度運行，而唔需要你監視。
TLDR
打字前先諗清楚。制定計劃比亂咁講效果要好得多。 CLAUDE.md係你嘅槓桿點：保持簡短、具體，解釋原因，並不斷更新。呢個檔案會影響每一次互動。上下文會喺 30% 降級，而唔係 100%。用外部記憶體，確定對話範圍，唔好怕用複製貼上重置技巧清除並重新啟動。 架構比乜都重要。唔可以跳過規劃。如果唔先考慮結構，輸出結果就會好差。 輸出係嚟自輸入。如果你用一個好嘅模型得到嘅結果唔好，咁你嘅提示需要改進。加強溝通。 嘗試用工具同配置：MCP、鈎子、斜線命令。如果你畀錢買咗 Pro Max，咩都試下。就算第一次唔成功，都要保持好奇心。 遇到困難時，改變方法。唔好循環。清晰、簡化、展示、重構。 構建系統，而唔係一次過搞掂：無頭模式、自動化、記錄改進。 如果你正喺度用Claude構建系統，無論係你自己嘅項目定生產系統，呢啲都會決定你係同工具對抗，定係同佢共進退。
先思考
大多數人都認為，使用Claude代碼和其他人工智能工具，你需要做的第一件事就是打字（或開始說話）。但這可能是你一開始就可能犯的最大錯誤之一。實際上，你需要做的第一件事是思考。
十次中的十次，我在計劃模式下得到的輸出結果都比我剛開始說話並把所有東西都輸入Claude代碼時要好得多。還差得遠呢。
對於某些人來說，這說起來容易做起來難。你們可能沒有多年的軟件工程經驗，無法獨立思考這個問題。對此，我有兩個建議：
開始學習。如果你從不學習，哪怕每次只學一點點，你也是在自毀前程。 與 ChatGPT/Gemini/Claude 進行深入的交流，準確描述你想要構建的系統，向 LLM 詢問你在系統設計方面可以採取的各種方案，並最終確定一個解決方案。您和 LLM 應該互相提問，而不僅僅是單向交流。
這適用於所有工作。這也包括非常小的任務，如總結電子郵件。在要求 Claude 構建功能之前，先考慮一下架構。在要求Claude重構某項功能之前，先想想最終狀態應該是什麼樣的。在要求Claude進行調試之前，先想想你對問題的實際瞭解。
在計劃模式下，你掌握的信息越多，你的輸出就會越好，因為輸入就會越好。這種模式是一致的：先思考，再鍵入，比先鍵入，然後希望Claude找出問題所在的結果要好得多。
架構
這就引出了我的下一個觀點——架構。架構，尤其是軟件工程中的架構，有點像給一個人提供輸出，僅此而已。這就為如何獲得輸出留下了很大的迴旋餘地，而這正是人工智能生成代碼的問題所在。
如果你說的是“給我建立一個認證系統”這樣的超級寬泛的事情，而不是“使用現有的用戶模型建立電子郵件/密碼認證，在 Redis 中存儲會話並 24 小時過期，添加中間件以保護 /api/protected 下的所有路由”，你就能看出其中的差別。
計劃模式
點擊兩次 Shift+Tab，你就進入了計劃模式。相信我，這隻需花費你 5 分鐘的時間，但卻能為你節省數小時的調試時間。
CLAUDE.md
CLAUDE.md 是一個標記符文件。Markdown 是一種文本格式，人工智能模型能很好地處理這種格式，尤其是Claude，它比我測試過的大多數其他模型都能處理得更好。
當你啓動Claude代碼會話時，Claude要做的第一件事就是讀取你的 CLAUDE.md 文件。該文件中的每一條指令都會影響Claude如何處理你的項目。它實質上是Claude在每次對話前都會閲讀的入門材料。
大多數人要麼完全忽略它，要麼在裏面塞滿垃圾，讓Claude的工作變得更糟，而不是更好。信息過多或過少都會導致模型輸出變差。
這才是真正重要的：
儘量簡短。Claude一次只能可靠地執行大約 150 到 200 條指令，而Claude代碼的系統提示已經使用了其中的大約 50 條。你添加的每一條指令都會爭奪注意力。如果你的 CLAUDE.md是一本小說，Claude就會開始隨意忽略一些東西，而你卻不知道是哪些東西。讓它與你的項目具體相關。不要解釋組件文件夾是什麼。Claude知道組件是什麼。告訴它一些奇怪的東西，比如真正重要的 bash命令。所有屬於你的流程的東西都應該放進去。告訴它為什麼，而不僅僅是什麼。在這方面，Claude有點像人類。當你告訴它指令背後的原因時，Claude會比你只告訴它做什麼更好地執行指令。“使用 TypeScript嚴格模式”是可以的。而“使用TypeScript嚴格模式，因為我們在生產中遇到過隱含 any 類型的 bug”則更好。“為什麼”為Claude提供了做出判斷的語境，而這是你始料未及的。你會驚訝於這樣做的效果。不斷更新。工作時按下 #鍵，Claude會自動在CLAUDE.md中添加說明。每當你發現自己在同一件事情上糾正了Claude兩次，這就預示着它應該被添加到文件中。隨着時間的推移，你的CLAUDE.md文件就會成為你的代碼庫如何實際工作的活文檔。
糟糕的 CLAUDE.md 看上去就像是為新員工編寫的文檔。好的 CLAUDE.md 看起來就像如果你知道自己明天就會失憶，就會給自己留下的筆記。
上下文窗口的侷限性
例如，Opus 4.5 有一個 200,000 標記的上下文窗口。但大多數人沒有意識到的是：在你使用到 100%（這取決於您是通過應用程序接口還是桌面應用程序使用）。
在 20–40% 上下文使用率左右時，輸出質量開始下降，即使下降幅度不大。如果你曾遇到過Claude代碼壓縮後輸出仍然很糟糕的情況，那就是原因所在。在壓縮之前，模型的質量就已經下降了，而壓縮並不能神奇地恢復質量。（點擊 /compact 進行壓縮）
你發送的每一條信息、Claude讀取的每一個文件、生成的每一段代碼、每一個工具結果，所有這些都會累積起來。一旦質量開始下降，更多的上下文會讓情況變得更糟，而不是更好。因此，以下幾件事實際上有助於避免出現糟糕的語境：
確定對話範圍。每個功能或任務只進行一次對話。不要用同一個對話來構建認證系統，然後再重構數據庫層。上下文會混在一起，Claude會感到困惑。我知道在讀這篇文章的人中，至少有一個會犯這種錯誤。 使用外部內存。如果你正在處理複雜的工作，可以讓 Claude 將計劃和進度寫入實際文件（我使用 SCRATCHPAD.md或plan.md）。這些文件會在不同的會話中持續存在。當你明天回來時，Claude可以讀取文件並從你離開的地方繼續開始，而不是從零開始。附註：如果你有一個文件分級系統，那麼將這些文件保留在盜版頂層。就是讓這些文件在你決定構建的每個任務/功能中都能發揮作用的方法。 複製粘貼重置。這是我經常使用的一招。當上下文變得臃腫時，我會從終端複製所有重要信息，運行 /compact獲取摘要，然後/clear完全清除上下文，然後只粘貼重要信息。新的上下文保留了關鍵信息。這比讓Claude在退化的上下文中掙扎要好得多。知道何時清除。如果對話已經偏離了軌道，或者積累了大量無關的上下文，只需 /clear，然後重新開始。這總比在混亂中掙扎要好。Claude仍然保留着CLAUDE.md，所以你不會丟失項目上下文。十有八九，使用/clear其實比不使用它要好，雖然這聽起來有違直覺。
有效的心智模型
Claude是無狀態的。每一次對話都是從零開始的，除了你明確賦予它的東西。據此制定計劃。
提示就是一切
人們花費數週時間學習框架和工具。他們卻沒有花時間學習如何與實際生成代碼的東西交流。
提示並不是什麼神秘的藝術。它可能是最基本的溝通方式。就像任何交流一樣，清晰的表達比含糊的表達更能取得好的效果。每。每一次。每一次。
真正的幫助
具體說明你想要什麼。“建立一個身份驗證系統”給了Claude創造性的自由，但它用得不好。而“使用現有的用戶模型構建電子郵件/密碼驗證，在 Redis中存儲會話，並添加中間件以保護/api/protected下的路由”則給了Claude一個明確的目標。即使是這樣，也並不完美。告訴它不要做什麼。Claude有傾向性。Claude 4.5 尤其喜歡過度工程化——額外的文件、不必要的抽象、你沒有要求的靈活性。如果你想要最簡單的東西，那就說“保持簡單。不要添加我沒有要求的抽象概念。如果可能，只需一個文件”。另外，一定要交叉引用Claude生成的文件，因為你不想最終產生技術債務，尤其是當你正在構建一個超級簡單的東西，結果卻為一個任務構建了 12 個不同的文件，而這個任務實際上只需要幾行代碼就能解決。 說明原因。“我們需要它快，因為它能在每個請求上運行”，這句話改變了Claude處理問題的方式。“這是一個我們會扔掉的原型”會改變哪些權衡是有意義的。Claude無法讀懂你未提及的約束條件。 記住：輸出就是一切，但它只來自輸入。如果你的輸出很糟糕，那麼你的輸入也很糟糕。這是沒有辦法的事。
你必須記住的是，人工智能的目的是加快我們的速度，而不是完全取代我們，尤其是在非常專業的軟件工程時代。Claude仍然會犯錯。我相信它會繼續犯錯，即使它會隨着時間的推移變得更好。因此，能夠認識到這些錯誤，實際上會解決你的很多問題。
糟糕的輸入 == 糟糕的輸出
當得到糟糕的結果時，人們會責怪模型。“Claude不夠聰明”或“我需要一個更好的模型”。現實情況是：你太差勁了。如果你用 Opus 4.5 這樣的好模型得到了糟糕的結果，那就意味着你的輸入和提示很糟糕。完全正確。
模型很重要。實際上非常重要。但在這一點上，模型的質量是關鍵。瓶頸幾乎總是在人的方面：你如何組織你的提示，你如何提供上下文，你如何清楚地傳達你真正想要的東西。
如果你的成績一直不好，解決的辦法不是更換機型。解決的辦法是在以下方面做得更好：
如何編寫提示：具體 > 含糊；限制性 > 開放性；示例 > 說明。 如何組織請求：將複雜的任務分成幾個步驟；在實施前就架構達成一致；審查輸出結果並進行迭代。 如何提供上下文：要做好這項工作，Claude需要了解什麼？你做了哪些Claude看不到的假設？
也就是說，不同模型之間確實存在差異：
Sonnet更快、更便宜。它非常適合路徑清晰的執行任務——編寫模板、根據特定計劃進行重構、實現已經做出架構決策的功能。Opus運行速度更慢，成本更高。它更適合複雜的推理、規劃和需要Claude深入思考權衡的任務。
可行的工作流程：使用 Opus 進行規劃並做出架構決策，然後切換到 Sonnet（Claude代碼中的 Shift+Tab 鍵）進行實施。這取決於你的任務，有時你也可以使用 Opus 4.5 進行實施。不過，如果你通過 API 使用選項卡來做這件事，那就考慮一下賣腎吧。
您的 CLAUDE.md 將確保兩個模型都在相同的約束條件下運行，因此交接過程是乾淨利落的。
MCP、工具和配置
Claude擁有豐富的功能：MCP 服務器、鈎子、自定義斜線命令、settings.json 配置、技能插件。
你並不需要所有這些。但你應該真正嘗試一下，因為如果你不嘗試，很可能就會浪費時間或金錢。我向你保證，如果你關注Claude代碼的創始人鮑里斯（Boris），Claude至少會有一項你不知道的新功能。
MCP
MCP（模型上下文協議）讓 Claude 可以連接外部服務：Slack、GitHub、數據庫、API。
如果你發現自己經常將信息從一個地方複製到 Claude 中，那麼很可能有一個 MCP 服務器可以自動完成這項工作。有大量的 MCP 市場；如果沒有 MCP，它也只是一種獲取結構化數據的方式，所以你可以為任何你需要添加但目前還不存在的工具創建自己的 MCP 服務器。
如果你能找到一個不存在的 MCP 服務器，我會感到非常驚訝。
鈎子（Hooks）
鈎子可以讓你在 Claude 更改之前或之後自動運行代碼。想讓 Prettier 在Claude接觸的每個文件上運行？鈎子。想要在每次編輯後進行類型檢查？鈎子。這樣就能立即發現問題，而不是任其堆積。
這實際上也有助於消除技術債務。如果你在每一千行後設置一個特定鈎子，你就有了潛在清理代碼的安全功能。當Claude審核你的 PR 時，這應該會很有幫助。
自定義斜線命令
自定義斜線命令只是你重複使用的提示，打包為命令。創建一個 .claude/commands 文件夾，添加包含提示信息的標記文件，現在就可以用 /commandname 運行它們了。
如果你經常運行同類任務——調試、審查、部署——那麼就把它變成命令吧。
如果您有 Pro Max 計劃（我每月支付 200 美元），為什麼不試試 Claude 提供的所有服務呢？看看哪些有效，哪些無效。反正你也付了錢。
還有一點：不要一試就放棄。這些模型基本上每週都在改進。一個月前不行的東西，現在可能就能用了。作為早期採用者，意味着要保持好奇心並重新測試。
當Claude陷入困境時
有時，Claude只是在循環。它嘗試同樣的事情，失敗，再嘗試，再失敗，然後繼續。或者它自信滿滿地實現了一些完全錯誤的東西，而你卻花了二十分鐘試圖解釋原因。
當這種情況發生時，本能的反應就是繼續推動：更多的指導、更多糾正、更多的上下文。但實際上，更好的做法是完全改變方法：
從簡單開始——理清對話。積累的上下文可能會讓對話變得混亂。 /clear給你一個全新的開始。簡化任務。如果Claude正在為一項複雜的任務而苦惱，那麼就把它分解成更小的部分。在合併之前，先讓每一塊都發揮作用。但實際上，如果Claude在複雜的任務中掙扎，那就意味着你的計劃模式不夠充分。 展示而不是講述。如果Claude一直誤解你的意圖，那就自己寫一個最簡單的例子。“輸出應該是這樣的。現在把這個模式應用到其他方面”。Claude非常善於理解成功的指標是什麼樣的，並能真正按照這些指標去做，他知道什麼是好的範例。 要有創意。嘗試不同的角度。有時，你提出問題的方式與Claude的思維方式並不一致。重新構思——“將其作為狀態機來實現”與“處理這些轉換”——可以取得進展。 及早識別循環。這裏的“元技能”就是及早識別你是否陷入了一個循環。如果同樣的事情你已經解釋了三遍，Claude還是不明白，那麼再解釋也無濟於事。改變一些東西。
建立系統
從Claude中獲得最大價值的人並不是將其用於一次性任務。他們正在構建系統，而 Claude 就是其中的一個組成部分。
但Claude代碼遠不止於此。它有一個 -p 標誌，用於無頭模式。它可以運行你的提示，並在不進入交互界面的情況下輸出結果。這意味着你可以編寫腳本：將輸出通過管道輸送到其他工具；將它與 bash 命令相連；將其集成到自動化工作流程中。
企業將其用於自動公關審查、自動支持單回覆、自動記錄和文檔更新。所有這些都會被記錄、審計，並根據哪些有效、哪些無效而不斷改進。
飛輪：Claude犯了一個錯誤，你查看日誌，改進 CLAUDE.md 或工具，Claude下次會做得更好。這個化合物現在，我正在讓Claude改進自己的 Claude.md 文件。經過幾個月的迭代，以這種方式構建的系統比啓動時有了明顯改善——同樣的模型，只是配置更好了。
如果你只是交互式地使用 Claude，那你就失去了價值。想一想，在你的工作流程中，Claude可以在什麼地方運行，而不需要你的監視。
TLDR
打字前先思考。制定計劃比信口開河效果要好得多。 CLAUDE.md是您的槓桿點：保持簡短、具體，說明原因，並不斷更新。這個文件會影響每一次互動。上下文會在 30% 降級，而不是 100%。使用外部存儲器，確定對話範圍，不要害怕使用複製粘貼重置技巧清除並重新啓動。 架構比什麼都重要。不能跳過規劃。如果不先考慮結構，輸出結果就會很糟糕。 輸出來自輸入。如果你用一個好的模型得到的結果不好，那麼你的提示需要改進。加強溝通。 嘗試使用工具和配置：MCP、鈎子、斜線命令。如果你花錢購買了 Pro Max，那就什麼都試試。即使第一次不成功，也要保持好奇心。 遇到困難時，改變方法。不要循環。清晰、簡化、展示、重構。 構建系統，而非一蹴而就：無頭模式、自動化、記錄改進。 如果你正在使用Claude構建系統，無論是你自己的項目還是生產系統，這些都將決定你是在與工具對抗，還是與它共進退。