2百萬人圍觀的Claude Code 實戰使用指南

　　
來源：AI寒武紀

　　Eyad 曾作為軟件工程師（SWE）在亞馬遜、迪士尼和第一資本工作了7年，交付的代碼觸達數百萬用戶，構建的系統不容有失。現在，他是一家為企業構建智能體的創業公司的CTO，而 Claude Code 是他日常工作的核心驅動力

　　這份初學者指南，濃縮了Eyad使用 Claude 構建處理大型公司復雜工作負載的穩健系統后，所學到的一切。希望能對你有所幫助

　　先思考，后動手

　　大多數人認為，使用 Claude Code 等 AI 工具時，第一步就是開始打字（或說話）。但這恰恰是你能犯下的最大錯誤之一。你真正需要做的第一件事是思考。

　　十次里有十次，我在“規劃模式”下獲得的輸出，都遠勝于我直接開口、把所有想法傾倒給 Claude Code 的結果。兩者效果天差地別。

　　對一些人來說，這可能說起來容易做起來難。你可能沒有多年的軟件工程經驗來自行思考。對此，我有兩點建議：

　　1.開始學習。如果你從不掌握這項技能，你就在限制自己，哪怕每次只學一點點。

　　2.與 ChatGPT/Gemini/Claude 進行深入的來回交流。精確描述你想構建什么，詢問 LLM 在系統設計方面有哪些選項，最終你們共同確定一個解決方案。你和 LLM 應該互相提問，而不是單向灌輸。

　　這一點適用于所有事，包括像總結郵件這樣的小任務。在讓 Claude 構建功能前，先思考架構；在讓它重構代碼前，先思考最終應有的形態；在讓它調試前，先思考你對問題已知的確切信息。你在規劃模式中提供的信息越多，輸入質量就越高，輸出質量也自然會越好。

　　這個模式始終如一：先思考，再輸入，比先輸入、指望 Claude 自己搞明白，能產生好得多的結果。

　　這就引出了我的下一點：架構。尤其在軟件工程中，只給出一個最終目標而不提供過程，就像只告訴一個人目的地卻不給地圖。這為如何到達目的地留下了巨大的“自由發揮”空間，而這正是 AI 生成代碼問題的核心所在。

　　比較一下兩種說法的區別：寬泛的“給我建一個認證系統”，與明確的“使用現有的 User 模型構建郵箱/密碼認證，將 session 存儲在 Redis 中并設置 24 小時過期，同時添加中間件保護 /api/protected 下的所有路由。” 你會發現差異巨大。

　　連按兩次Shift + Tab鍵，即可進入規劃模式。相信我，這會花掉你5分鐘，但能為你省下后續數小時的調試時間。

　　CLAUDE.md：你的項目專屬說明書

　　CLAUDE.md 是一個 Markdown 文件。Markdown 是一種 AI 模型處理得非常好的文本格式，而 Claude 對它的處理能力尤其出色。

　　當你啟動一個 Claude Code 會話時，它做的第一件事就是讀取你的CLAUDE.md文件。文件中的每條指令都會塑造 Claude 處理你項目的方式。這本質上是 Claude 在每次對話前都會閱讀的“入職材料”。

　　大多數人要么完全忽略它，要么用一些垃圾信息把它填滿，結果反而讓 Claude 表現更差。信息過多或過少都存在一個閾值，超過或低于這個閾值都會導致模型輸出質量下降。

　　以下是真正重要的幾點：

　　1.保持簡短。Claude 一次只能可靠地遵循大約150到200條指令，而 Claude Code 的系統提示本身已經占用了約50條。你添加的每條指令都在爭奪它的注意力。如果你的CLAUDE.md像一本小說，Claude 就會開始隨機忽略某些內容，而你無從知曉。

　　2.內容要針對你的項目。不要解釋什么是“components”文件夾，Claude 知道。告訴它那些項目特有的、奇怪的東西，比如那些真正重要的 bash 命令。所有屬于你工作流的東西都應該放進去。

　　3.解釋原因，而不僅僅是做什么。在這方面，Claude 有點像人。當你給出指令背后的原因時，它會比只被告知做什么時執行得更好。“使用 TypeScript 嚴格模式”是可以的，但“使用 TypeScript 嚴格模式，因為我們曾因隱式的 any 類型導致過生產環境的 bug”則更佳。這個“為什么”為 Claude 在處理你未預料到的判斷時提供了上下文。你會驚訝于這種方法的有效性。

　　4.持續更新。在工作時按下#鍵，Claude 會自動將指令添加到你的CLAUDE.md中。每當你發現自己第二次糾正 Claude 同一個問題時，這就是一個信號：它應該被寫進文件里。隨著時間的推移，你的CLAUDE.md會成為一份關于你代碼庫如何運作的活文檔。

　　一個糟糕的CLAUDE.md看起來像為新員工寫的文檔。一個好的CLAUDE.md看起來像你為明天失憶的自己留下的筆記。

　　理解上下文窗口的局限性

　　例如，Opus 4.5 擁有20萬 token 的上下文窗口。但大多數人沒有意識到的是：在遠未達到100%使用率時，模型的性能就開始衰退了。（具體情況取決于你是通過 API 還是桌面應用使用）

　　當上下文使用率達到20-40%左右時，輸出質量就開始下降，即使下降得不明顯。如果你曾遇到 Claude Code 進行壓縮后（通過/compact命令）仍然給出糟糕輸出的情況，這就是原因。在壓縮發生前，模型性能已經退化，而壓縮并不能神奇地恢復質量。

　　你發送的每條消息、Claude 讀取的每個文件、它生成的每段代碼、每個工具的返回結果——所有這些都會累積。一旦質量開始下降，增加更多的上下文只會讓情況變得更糟。以下是一些避免上下文質量糟糕的有效方法：

　　?限定對話范圍。每個功能或任務使用一個獨立的對話。不要在同一個對話中既構建認證系統又重構數據庫層。上下文會混雜在一起，讓 Claude 感到困惑。

　　?使用外部記憶。如果你在處理復雜問題，讓 Claude 把計劃和進展寫到實際文件中（我使用SCRATCHPAD.md或plan.md）。這些文件可以跨會話持久存在。當你第二天回來時，Claude 可以讀取文件，從你離開的地方繼續，而不是從零開始。

　　?復制-粘貼重置法。這是我經常使用的一個技巧。當上下文變得臃腫時，我從終端復制所有重要的內容，運行/compact獲得一個摘要，然后用/clear完全清空上下文，最后只把關鍵信息粘貼回去。這樣既保留了關鍵信息，又獲得了清新的上下文，遠比讓 Claude 在退化的上下文中掙扎要好。

　　?知道何時清空。如果一個對話已經偏離軌道或積累了大量不相關的上下文，直接用/clear重新開始。這比試圖在混亂中繼續工作要好。Claude 仍然會讀取你的CLAUDE.md，所以你不會丟失項目上下文。十次中有九次，使用/clear實際上是更好的選擇。

　　有效的心智模型是：Claude 是無狀態的。每次對話都從零開始，除了你明確提供給它的信息。請據此進行規劃。

　　Prompt 即一切

　　人們花數周時間學習框架和工具，卻花零時間學習如何與那個實際生成他們代碼的東西進行溝通。

　　Prompt 工程不是什么神秘藝術，它可能是最基本的溝通形式。和任何溝通一樣，清晰明確總比含糊不清能獲得更好的結果。每一次都是如此。

　　真正有幫助的做法是：

　　?具體說明你想要什么。“構建一個認證系統”給了 Claude 它會濫用的創作自由。“使用這個已有的 User 模型構建郵箱/密碼認證，將 session 存入 Redis，并添加中間件保護 /api/protected 下的路由”則給了 Claude 一個清晰的目標。

　　?告訴它不該做什么。Claude 有其傾向性。特別是 Claude 4.5 喜歡過度工程化——額外的文件、不必要的抽象、你沒要求過的靈活性。如果你想要最簡化的東西，就說：“保持簡單。不要添加我沒要求的抽象。如果可能，只用一個文件。” 同時，一定要交叉檢查 Claude 的產出，你不想最終背上技術債。

　　?提供“為什么”的背景。“我們需要這個功能速度快，因為它在每個請求上都會運行”會改變 Claude 解決問題的方式。“這是一個我們會扔掉的原型”則會改變它在權衡取舍時的考量。Claude 無法讀懂你心中那些未提及的約束。

　　記住：輸出決定一切，但輸出只來源于輸入。如果你的輸出很差，那說明你的輸入很差。別無他法。

　　壞輸入 = 壞輸出

　　當得到不好的結果時，人們會責怪模型。“Claude 不夠聰明”或者“我需要一個更好的模型”。

　　現實是：問題出在你身上。如果你用像 Opus 4.5 這樣的好模型卻持續得到糟糕的輸出，那意味著你的輸入和你的 Prompt 很差。就是這樣。

　　模型固然重要，但模型質量如今已是基本門檻。瓶頸幾乎總是在人這一邊：你如何構建 Prompt，如何提供上下文，如何清晰地傳達你真正想要什么。

　　如果你持續得到糟糕的結果，解決方法不是換模型，而是提升以下能力：

　　?你如何編寫 Prompt：具體 > 模糊，約束 > 開放，示例 > 描述。

　　?你如何組織請求：將復雜任務分解成步驟，在實現前先就架構達成一致，審查輸出并迭代。

　　?你如何提供上下文：Claude 需要知道什么才能做好這件事？你做了哪些 Claude 看不到的假設？

　　話雖如此，不同模型之間確實存在差異：

　　?Sonnet更快、更便宜。它非常適合執行路徑明確的任務——編寫樣板代碼、根據具體計劃進行重構、實現你已做出架構決策的功能。

　　?Opus更慢、更貴。它更擅長復雜的推理、規劃以及需要 Claude 深入思考權衡的任務。

　　一個有效的工作流是：用 Opus 進行規劃和架構決策，然后切換到 Sonnet (在 Claude Code 中按Shift+Tab) 進行實現。你的CLAUDE.md確保兩個模型在相同的約束下運作，使得交接過程非常順暢。

　　善用工具與配置：MCP、鉤子和命令

　　Claude 擁有大量的功能：MCP 服務器、鉤子（Hooks）、自定義斜杠命令、settings.json配置、技能（Skills）、插件（Plugins）。

　　你不需要全部都用上。但你應該去嘗試和實驗，因為不實驗，你可能就在浪費時間或金錢。

　　?MCP (Model Context Protocol)讓 Claude 連接到外部服務，如 Slack、GitHub、數據庫、API。如果你發現自己總是在從一個地方復制信息到 Claude，很可能有一個 MCP 服務器能自動完成這件事。

　　?鉤子 (Hooks)讓你在 Claude 進行更改前后自動運行代碼。想讓 Prettier 在 Claude 碰過的每個文件上運行？用鉤子。想在每次編輯后進行類型檢查？用鉤子。這能立即捕獲問題，而不是讓它們堆積起來。

　　?自定義斜杠命令是你重復使用的 Prompt，被打包成了命令。創建一個.claude/commands文件夾，添加包含你 Prompt 的 Markdown 文件，然后你就可以用/commandname來運行它們。

　　如果你有 Pro Max 計劃（我每月支付200美元），為什么不試試 Claude 提供的所有功能呢？看看哪些有效，哪些無效。反正你已經付了錢。

　　而且，不要因為某樣東西第一次嘗試失敗就放棄。這些模型幾乎每周都在改進。一個月前行不通的東西，現在可能就可以了。

　　當 Claude 卡住時怎么辦

　　有時 Claude 會陷入循環。它嘗試同樣的事情，失敗，再試，再失敗，如此往復。或者它自信地實現了一個完全錯誤的東西，你得花二十分鐘去解釋為什么錯了。

　　發生這種情況時，人的本能是繼續推進：給更多指令、更多修正、更多上下文。但現實是，更好的做法是徹底改變方法。

　　?清空對話。累積的上下文可能正在迷惑它。/clear給你一個全新的開始。

　　?簡化任務。如果 Claude 難以處理一個復雜任務，把它分解成更小的部分。在組合之前，確保每個部分都能正常工作。但實際上，如果 Claude 在復雜任務上掙扎，這通常意味著你的規劃模式做得不夠充分。

　　?展示而非告知。如果 Claude 一直誤解你的意圖，自己寫一個最小化的例子。“看，輸出應該長這樣。現在把這個模式應用到其余部分。” Claude 非常擅長理解成功的范例并遵循它。

　　?創新思路。嘗試一個不同的角度。有時你描述問題的方式與 Claude 的“思維”方式不匹配。重新表述——比如從“處理這些狀態轉換”變為“將此實現為一個狀態機”——可能會打開僵局。

　　這里的元技能是及早識別出你正處于一個循環中。如果你已經把同一件事解釋了三遍而 Claude 仍然不明白，更多的解釋是無濟于事的。改變點什么吧。

　　構建系統，而非一次性任務

　　從 Claude 獲得最大價值的人，不是用它來完成一次性任務，而是構建以 Claude 為組件的系統。

　　Claude Code 的-p標志支持無頭模式（headless mode）。它會運行你的 Prompt 并輸出結果，而無需進入交互界面。這意味著你可以用腳本調用它，將輸出通過管道傳遞給其他工具，與 bash 命令鏈接，將其集成到自動化工作流中。

　　企業正在用它來實現自動 PR 審查、自動支持工單回復、自動日志記錄和文檔更新。所有這些都被記錄、可審計，并根據有效和無效的反饋隨著時間推移而改進。

　　這是一個飛輪效應：Claude 犯錯 -> 你審查日志 -> 你改進CLAUDE.md或工具 -> Claude 下次做得更好。這種改進是復合式的。我現在正在嘗試讓 Claude 能夠自我改進它的CLAUDE.md文件。

　　如果你只在交互模式下使用 Claude，你就在浪費它的價值。思考一下，在你工作流的哪些環節，Claude 可以在沒有你監督的情況下運行。

　　要點總結

　　先思考，后動手。規劃比直接開聊能產生好得多的結果

　　CLAUDE.md 是你的杠桿點。保持簡短、具體，解釋原因，并持續更新。這個文件影響每一次交互

　　上下文在30%使用率時就開始退化，而不是100%。使用外部記憶，限定對話范圍，并善用“復制-粘貼重置”技巧

　　架構比任何事都重要。你不能跳過規劃。沒有預先思考結構，輸出就會很糟糕

　　輸出源于輸入。如果你用好模型得到壞結果，是你的 Prompt 需要改進。提升你的溝通能力

　　實驗工具和配置。MCP、鉤子、斜杠命令。如果你是付費用戶，把所有功能都試一遍

　　卡住時，改變方法。不要陷入循環。清空、簡化、展示、重新構思

　　構建系統，而非一次性任務。利用無頭模式、自動化，并隨時間記錄和改進。

　　source：

　　https://x.com/eyad_khrais/status/2010076957938188661?s=20