Claude Code 開箱即用效果不錯，但一旦它了解你的專案慣例並養成一些提示詞習慣後，效果會明顯提升。本指南涵蓋兩者。
第 1 部分 — CLAUDE.md：你的專案記憶
它是什麼
CLAUDE.md 是一個純 Markdown 檔案，Claude 會在該目錄中的每個會話開始時自動讀取。把它想像成你會在新隊友第一天早上給他們的簡報：團隊如何做事、要避免什麼，以及重要部分在哪裡。
你不需要在提示詞中引用它或手動附加它。如果檔案存在，Claude 已經讀過了。
它在哪裡
Claude 會在幾個地方查找並合併找到的內容，從廣泛到具體：
位置 | 範圍 | 適合用於 |
| 你機器上的每個專案 | 個人偏好（例如，"我用 pnpm，不用 npm" 或 "總是建議測試"）。 |
| 這個專案 | 架構、慣例和命令。這是主要的。 |
| 該子目錄（當 Claude 讀取該目錄中的檔案時按需加載，不在會話開始時） | 模組特定規則（例如， |
大多數團隊只需要專案根目錄檔案。將其提交到 git，讓整個團隊受益。
它如何被加載（以及成本是多少）
工作目錄及其上方的檔案在會話開始時被讀取，並作為系統提示之後的用戶消息立即傳遞給 Claude（不嵌入系統提示本身）。子目錄 CLAUDE.md 檔案在稍後按需加載，當 Claude 讀取該子目錄中的檔案時。沒有摘要或截斷，也不會在每個回合重新從磁碟讀取。如果你在會話中編輯檔案，下次運行 /compact 或通過 /memory 打開時會選取更改；否則在你的下一個會話生效。
對於 Claude for Enterprise 客戶，成本情況比 "在每個請求上加載" 可能暗示的要好。Claude Code 對 CLAUDE.md 應用 Anthropic 的提示快取。會話中的第一個請求支付檔案的完整輸入令牌價格；大約五分鐘內的後續請求命中快取，按低得多的快取讀取率計費。快取是內容尋址的，所以對 CLAUDE.md 的任何更改都會使其失效，下一個請求再次支付全價。
實際上，這意味著一個相當大的 CLAUDE.md 每個會話支付一次完整令牌，加上任何足夠長的空閒間隙後一次（快取過期），而不是每條消息一次。保持檔案精簡以節省上下文窗口空間和信噪比仍然值得，但你不需要純粹為了控制每條消息支出而限制行數。在 Enterprise 使用儀表板中，檔案的佔用空間幾乎完全顯示為快取讀取令牌，而不是標準輸入令牌。
入門：運行 /init
在任何專案中，輸入 /init。Claude 將探索程式碼庫並為你起草一個 CLAUDE.md，涵蓋構建命令、測試命令、結構概述和它檢測到的任何慣例。檢查草稿，刪除任何不準確的內容，並提交。這大約需要五分鐘，但永久值得。
實際上應該包含什麼
目標是一個簡短且信號密集的檔案 — 大約 200 行以下。每一行都會在每個請求上加載到上下文中，所以每一行都應該值得其成本。
值得包含：
命令 — 如何構建、測試、檢查和本地運行。Claude 會執行這些，所以準確性很重要。
慣例 — 命名、錯誤處理、檔案佈局和 "我們用 X，不用 Y" 的決定。
三句話的架構 — 主要部分是什麼以及它們如何通信。
硬約束 — 例如，"永遠不要從測試寫入生產資料庫，" "所有 API 路由都需要認證中間件，" 或 "不要編輯
generated/。"已知陷阱 — 每個新工程師都會遇到的問題。
不值得包含：
完整的 API 文件（Claude 可以直接讀取程式碼）。
變更日誌或歷史。
檔案樹中已經很明顯的任何內容。
團隊實際上不遵循的理想規則。
多久更新一次
把它當作一個活的入職文件，而不是規格。
在
/init之後 — 檢查一次以清理生成的草稿。當 Claude 兩次出錯時 — 這是一個規則缺失的信號。添加一行來解決它。
當慣例改變時 — 例如，新框架、測試運行器或一組新的檢查規則。
季度檢查 — 刪除任何過時的內容，因為過時的說明比沒有更糟。
你也可以在會話中添加：打開 /memory 直接編輯檔案，或只是要求 Claude "記住" 一條規則，它會為你將其附加到正確的 CLAUDE.md。
第 2 部分 — 在 Claude Code 中值得的提示詞習慣
這些不是通用的提示詞工程技巧；它們是當 Claude 讀取和編輯真實程式碼庫時最重要的習慣。
1. 陳述結果，而不是步驟
Claude 可以自己探索程式碼庫。告訴它你想要什麼和為什麼，讓它自己找出在哪裡。
❌ "打開 userService.ts，找到 validate 函數，在第 42 行添加空值檢查。"
✅ "沒有電子郵件的用戶正在使驗證步驟崩潰。讓它優雅地處理並添加測試。"
2. 逐字給它錯誤
粘貼完整的堆棧跟蹤，而不是總結它。確切的檔案名、行號和消息是允許 Claude 快速找到正確位置的原因。
3. 用計畫模式先確定大任務的範圍
對於涉及多個檔案的任何事情，按 Shift+Tab 兩次進入計畫模式（第一次按進入 acceptEdits）並詢問：
"計畫你如何向公共 API 添加速率限制。暫時不要改變任何東西。"
檢查計畫，在對話中調整它，然後切換模式並說 "執行第 1 步。" 這會在誤解變成十二檔案差異之前捕捉它。
4. 當你已經知道檔案時指向它們
Claude 可以自己搜索程式碼庫，但如果你已經知道相關檔案，就說出來 — 這更快且使用更少的令牌。使用 @ 引用路徑，例如 @src/auth/login.ts。
5. 說出 "完成" 是什麼樣子
例子包括 "測試通過，" "匹配其他處理程序的風格，" 或 "沒有新依賴。" 預先陳述驗收標準比多輪修訂更有效率。
6. 每個對話一個任務；它們之間 /clear
長會話會積累噪音。當你從 "修復登錄錯誤" 切換到 "重構計費模組" 時，運行 /clear 並重新開始。你的 CLAUDE.md 帶著持久的上下文向前，所以聊天歷史不需要。
7. 像對待同事一樣糾正它，而不是搜尋引擎
如果第一個答案不對，你不需要重新表述整個請求。只需說出什麼是錯誤的 — 例如，"那改變了公共 API；保持簽名相同。" Claude 會保留其他一切並只調整那一點。
快速參考
想要… | 做這個 |
生成起始 |
|
查看 Claude 正在使用什麼記憶 |
|
在會話中添加規則 | 打開 |
重新開始但保留專案記憶 |
|
在提示詞中引用特定檔案 |
|