編輯 | 聽雨

小編最近刷到一篇讓程序員直呼“醍醐灌頂”的文章——出自軟件工程師兼安全工程師 Shrivu Shankar。他基于日常使用 Claude Code 的真實經驗，分享了從個人項目到企業級開發的全套智能體最佳實踐。

Shrivu 不只是講理論，他講述了管理智能體上下文、批量處理任務、快速原型、自動生成 Pull Request 的實操技巧，還結合 Hooks、Skills、MCP、SDK 等高級特性，告訴你如何把 AI 真正融入日常工程工作流。

圖片

知名開源公司創始人 Simon Willison 也高度評價：“Shrivu 的指南非常實用，既適合個人，也適合為大型團隊進行智能體配置。”尤其對 MCP 的看法，他說得很精煉：“與其構建臃腫的 API，不如把 MCP 設計成簡單、安全的網關，只提供少量強大的工具。”

圖片

如果你想知道 Claude Code 的每個功能該怎么用、什么時候用、如何最大化價值，小編為你整理了文章的精華內容，它將是你最實用的參考手冊。

我如何使用Claude Code的每個功能

我真的很常用 Claude Code。

作為一個業余開發者，我每周都會在虛擬機中運行它幾次，開啟 --dangerously-skip-permissions 模式，隨心所欲地「即興編碼」各種想法。在工作中，我的團隊負責為公司工程團隊構建 AI IDE 的規則與工具，我們每月光代碼生成就消耗數十億個 token。

CLI 智能體的競爭正在白熱化——Claude Code、Gemini CLI、Cursor、Codex CLI……我感覺真正的競爭是在 Anthropic 和 Open AI 之間。

但老實說，開發者之間的選擇往往取決于一些“表面因素”——比如某個功能實現的“運氣”，或者他們更喜歡哪種系統提示的“語氣”。到現在為止，這些工具都已經相當不錯了。

我也注意到，很多人過度關注輸出風格或 UI。對我來說，Claude 里那種“你太對了！”式的奉承并不是 bug，而是一個信號：說明你給的上下文太多了。我的目標是「發射即忘」（shoot and forget）——設定上下文，交代任務，讓它自己去完成。評判工具的標準，是最終提交的 PR，而不是它中間的過程。

在過去幾個月深入使用 Claude Code 后，這篇文章是我對它整個生態系統的總結。我會覆蓋幾乎所有我使用的功能（以及我不用的功能），從核心的 CLAUDE.md 文件、定制命令、到 Subagents、Hooks、GitHub Actions 等強大特性。

CLAUDE.md

在 Claude Code 中，最重要的文件就是項目根目錄下的 CLAUDE.md。它是智能體的“憲法”——描述你的代碼庫該如何被理解和操作。

• 對于個人項目，我讓 Claude 自己隨意在里面寫。
• 對于公司項目，我們嚴格維護 monorepo 的 CLAUDE.md，目前有 13KB（預計會漲到 25KB）。

它只記錄被超過 30% 工程師使用的工具和 API，其他工具則單獨寫在對應庫的 markdown 文檔里。我們甚至給每個內部工具的文檔分配“token 上限”，就像賣廣告位一樣——如果你講不清楚，就別進 CLAUDE.md。

編寫 CLAUDE.md 的技巧與反模式

• 從“防錯”開始，而不是寫手冊。CLAUDE.md 應該從 Claude 容易出錯的地方開始補充，而不是從零開始詳盡記錄。
• 不要直接 @ 文件文檔。如果你 @ 引用了其它文檔，Claude 會每次都把整份文件嵌入上下文，浪費 token。但僅僅寫路徑 Claude 又會無視它。正確做法是告訴 Claude 什么時候該去讀那份文檔，例如：

“如果遇到 FooBarError 或復雜用法，請參見 path/to/docs.md。”

• 不要只寫“永遠不要”。單純寫“Never use --foo-bar”會讓模型卡住。應同時提供替代方案。
• 把 CLAUDE.md 當作“約束工具”。如果命令太復雜，不要寫長篇解釋，而是寫一個簡單的 bash 包裝器，讓命令變得直觀，再記錄它。保持 CLAUDE.md 精簡，是推動團隊改進工具的好方式。

示例結構如下：

最后，我們還會維護一個 AGENTS.md，用于與其他 AI IDE（如 Cursor）兼容。

要點總結：把你的 CLAUDE.md 當作一份高層次、經過精心篩選的指引，而不是一本面面俱到的使用手冊。它的作用，是幫助你識別出哪些地方需要投入更多精力，去打造對 AI 與人類 都更友好的工具和流程。

Compact、Context 與 Clear

我建議在中途運行一次 /context，看看 200k token 的上下文是如何被使用的（即使是 Sonnet-1M，我也不完全相信 100 萬 token 都被有效利用）。

在我們的 monorepo 中，一個新會話的“空載成本”約 20k tokens（10%），剩余 180k 負責執行修改——很快就會被填滿。

我的三種主要工作流：

1. /compact（避免）自動壓縮上下文太黑箱、容易出錯、不可靠。
2. /clear + /catchup（簡單重啟）我默認的重啟方式：清除狀態，然后運行 /catchup 讓 Claude 重新讀取本分支修改的文件。
3. “Document & Clear”（復雜重啟）對大型任務，我讓 Claude 把計劃與進展寫入一個 .md 文件，然后清空狀態，讓它讀回這個文件繼續。

要點總結：不要依賴自動壓縮。小任務用 /clear 重啟，大任務用“記錄 + 清理”的方式保留上下文記憶。

自定義 Slash 命令

我把 Slash 命令看作是常用提示語的簡單快捷方式，僅此而已。我的配置非常精簡：

• /catchup：前面提到過的命令，用來讓 Claude 讀取當前 Git 分支中所有被修改的文件。
• /pr：一個小幫手，用于清理代碼、暫存修改并準備創建 Pull Request。

在我看來，如果你維護著一長串復雜的自定義斜杠命令，那其實是一種反模式。像 Claude 這樣的智能體，本意就是讓你幾乎能“隨口輸入”任何自然語言請求，并得到一個有用、可合并的結果。一旦你要求開發者（甚至非技術人員）必須去學習一份記錄在某處的“魔法命令清單”才能完成工作，那就違背了智能體設計的初衷。

要點總結：把斜杠命令當作簡單、個性化的快捷方式來使用，而不是用它們去替代一個更直觀的 CLAUDE.md 文件或更完善的智能體工具體系。

自定義子代理

理論上，自定義子代理是 Claude Code 中最強大的上下文管理功能之一。它的設計邏輯很簡單：一個復雜任務需要 X 個 token 的輸入上下文（例如測試運行方式），在執行過程中積累 Y 個 token 的工作上下文，最終產出 Z 個 token 的結果。如果要運行 N 個這樣的任務，那么主會話窗口就要處理 (X + Y + Z) * N 的上下文負載。

而子代理（subagent）機制的解決思路是：把 (X + Y) * N 的繁重計算外包給專門的子代理，讓它們只返回最終的 Z 結果，從而保持主會話上下文的整潔。

聽起來很美好，但在實際使用中，我發現自定義子代理帶來了兩個新的問題：

1.它們會“封鎖”上下文。

例如我創建了一個 PythonTests 子代理，那么所有與測試相關的上下文就被隔離在它的內部。主代理再也無法從整體上推理一個改動，因為它必須調用子代理才能知道如何驗證自己的代碼。

2.它們強加了“人類式工作流”。

更糟的是，這種機制迫使 Claude 遵循我人為定義的流程。我在告訴它“你必須這樣分工合作”，而這恰恰是我希望 AI 自主解決的問題。

我更喜歡的替代方案是使用 Claude 內置的 Task(...) 功能來克隆出通用代理的副本。我會把所有關鍵上下文寫在 CLAUDE.md 文件里，然后讓主代理自行決定何時、如何委派任務給自己的副本。這樣既保留了子代理帶來的上下文節省優勢，又避免了它的僵化問題，讓智能體能夠動態自我調度。

在我的另一篇文章《Building Multi-Agent Systems（Part 2）》中，我稱這種架構為 “主控–克隆（Master-Clone）”模型，并且我明確更偏愛這種方式，而不是自定義子代理所鼓勵的 “主導–專家（Lead-Specialist）”模型。

（文章鏈接：https://blog.sshh.io/p/building-multi-agent-systems-part）

要點總結：自定義子代理是一種脆弱的解決方案。更好的做法是：把核心上下文放入 CLAUDE.md，讓主代理通過自己的 Task/Explore(...) 功能自主管理任務分配與協作。

Resume、Continue 與 History 功能

在日常使用中，我經常使用 claude --resume 和 claude --continue 這兩個命令。它們非常適合在終端出錯后快速重啟，或恢復舊的會話。有時我會恢復幾天前的一次會話，只是為了讓 Claude 總結它當時是如何解決某個特定錯誤的，然后把這些經驗更新進我們的 CLAUDE.md 或內部工具中。

更深入一點來說，Claude Code 會把所有會話歷史記錄保存在 ~/.claude/projects/ 目錄下，這意味著你可以直接訪問那些原始的歷史會話數據。我寫了一些腳本來對這些日志進行元分析，尋找常見的異常、權限請求和錯誤模式，以幫助優化智能體的上下文提示與行為策略。

要點總結：使用 claude --resume 和 claude --continue，不僅可以重啟中斷的會話，還能夠挖掘歷史日志中被埋沒的上下文信息，持續改進你的智能體配置與工作流。

Hooks（鉤子機制）

Hooks 的作用非常強大。雖然我在個人項目里幾乎不用它們，但在大型企業級代碼倉庫中，它們是引導 Claude 行為的關鍵工具。你可以把它們理解為 CLAUDE.md 文件中“應該做的建議（should-do）”之外的“必須遵守的規則（must-do）”。

我們主要使用兩種類型的 Hook：

1.提交阻斷鉤子（Block-at-Submit Hooks）

這是我們最主要的策略。我們有一個 PreToolUse 鉤子，它會包裹所有的 Bash(git commit) 命令。當 Claude 嘗試提交代碼時，它會先檢查 /tmp/agent-pre-commit-pass 文件。這個文件只有在所有測試通過后、由測試腳本生成。如果文件不存在，鉤子就會阻止提交，迫使 Claude 進入一個“測試—修復”循環，直到構建通過為止。

2.提示鉤子（Hint Hooks）

這類鉤子不會中斷流程，而是在 Claude 做出不太理想操作時，提供一次性提示或反饋。它們屬于“提醒而非強制”的機制。

我們刻意不使用“寫入時阻斷鉤子”（block-at-write），例如在 Edit 或 Write 操作中直接中斷 Claude 的執行。這樣做只會讓智能體感到混亂甚至“挫敗”，更有效的做法是：讓它完整執行完計劃，再在提交階段檢查最終結果。

要點總結：使用 Hook 的最佳實踐是：

• 在提交階段執行狀態驗證（block-at-submit），確保結果可靠。
• 避免在寫入階段中斷，讓智能體先完成計劃，再評估最終產物。

規劃模式（Planning Mode）

在使用 AI IDE 時，規劃（Planning） 對于任何較大的功能變更都至關重要。在我的個人項目中，我完全依賴 Claude 的內置規劃模式。這個模式的作用，是在 Claude 開始工作前，與它對齊目標：既定義要如何構建功能，也明確中途的檢查點（inspection checkpoints）——即它需要暫停并向我展示階段性成果的地方。

經常使用這種模式，可以培養出一種直覺：了解在不給 Claude 過多上下文的情況下，什么信息是“最小但足夠”的，既能讓它制定出合理的計劃，又不會讓執行階段“跑偏”。

在我們的企業級 monorepo（單體代碼庫）中，我們已經開始基于 Claude Code SDK 構建自定義的規劃工具。它的工作方式與原生規劃模式類似，但我們在提示詞中加入了大量約束，讓輸出內容與團隊的技術設計文檔格式保持一致。此外，它還內置了團隊最佳實踐——從代碼結構到數據隱私、安全規范，全都自動遵循。這讓工程師們可以像一位高級架構師一樣去“共創規劃”，（至少理論上是這樣）。

要點總結：在進行復雜變更時，一定要使用內置的規劃模式，先與 Claude 明確計劃與檢查節點，再讓它正式開始執行工作。

技能（Skills）

我非常認同 Simon Willison 的觀點：Skills也許比 MCP 更重要。

如果你一直關注我的文章，就會知道我在多數開發工作流中，已經逐漸放棄 MCP，轉而傾向于構建一些簡單的 CLI 工具（正如我在《AI Can’t Read Your Docs》中所論述的那樣）。

（文章鏈接：??https://blog.sshh.io/p/ai-cant-read-your-docs）??

我對智能體自主性的理解，已經演化為以下三個階段：

1.單提示階段（Single Prompt）

把所有上下文一次性塞進一個超大的提示中（問題是脆弱、不具擴展性）。

2.工具調用階段（Tool Calling）

 經典的智能體模型。我們手工編寫工具，為智能體抽象現實世界（更好一些，但會帶來新的抽象層和上下文瓶頸）。

3.腳本化階段（Scripting）

我們讓智能體直接訪問底層環境——包括二進制文件、腳本和文檔，它可以即時編寫代碼與這些資源交互。

在這種模型下，Agent Skills 就成了非常自然的下一步演進。它們實際上是對“腳本化層（Scripting Layer）”的正式產品化。

如果你和我一樣，早就更傾向于使用 CLI 而非 MCP，那么你其實早就在享受 Skills 帶來的好處。SKILL.md 文件只是讓這些 CLI 和腳本更有組織、更易共享、更易被發現，并以一種標準方式暴露給智能體。

要點總結：Skills 是一種正確的抽象。它們把“基于腳本的智能體模型”正式化，這種模式比 MCP 所代表的僵化、類 API 模式更加健壯、靈活、實用。

MCP

引入 Skills 并不意味著 MCP 已死（參見我之前的文章《Everything Wrong with MCP》）。（文章鏈接：??https://blog.sshh.io/p/everything-wrong-with-mcp）??

過去，很多人濫用 MCP —— 構建了大量臃腫、上下文極重的 MCP 接口，里面塞滿了幾十個功能雷同的小工具，比如：read_thing_a()、read_thing_b()、update_thing_c()……這些接口不過是把 REST API 生硬地“翻譯”了一遍。

如今，“腳本化”模型（也就是 Skills 所正式化的那一層）顯然更優，但它仍然需要一種安全訪問運行環境的方式。而這，正是 MCP 新的、更加聚焦的使命。

在我看來，一個現代化的 MCP 不應再是龐大繁瑣的 API 集合，而應該是一個簡單、安全的環境網關（secure gateway），僅提供少量但功能強大的高級工具，例如：

• download_raw_data(filters…) —— 下載原始數據；
• take_sensitive_gated_action(args…) —— 執行敏感操作；
• execute_code_in_environment_with_state(code…) —— 在帶狀態的環境中運行代碼。

在這種模型下，MCP 的職責不再是為智能體抽象現實世界，而是管理認證、網絡與安全邊界，然后“讓開道路”，為智能體提供一個受控的入口，讓它用自己的腳本和 Markdown 上下文去完成真正的工作。

目前，我只保留了一個 MCP：用于 Playwright。這很合理——Playwright 是一個復雜且有狀態的環境。至于那些無狀態工具（如 Jira、AWS、GitHub），我已經全部遷移到更簡單的 CLI 方案中。

要點總結：把 MCP 當作數據網關（data gateway）來使用。給智能體提供一到兩個高層工具接口（例如原始數據導出 API），然后讓它在此基礎上，通過腳本化方式自主完成工作。

Claude Code SDK

Claude Code 不僅僅是一個交互式 CLI，它同時也是一個功能強大的 SDK，可以用來構建全新的智能體——無論是用于編程任務，還是非編程場景。

如今，在我大多數新的個人項目中，我已經默認使用 Claude Code SDK，取代了 LangChain、CrewAI 等傳統框架。

我主要有三種使用方式：

1.大規模并行腳本執行

當我需要進行大規模重構、批量修復 bug 或代碼遷移時，我不會使用交互式聊天，而是編寫簡單的 Bash 腳本，通過類似 claude -p "in /pathA change all refs from foo to bar" 的命令并行調用。這種方式比讓主智能體去管理幾十個子代理任務更高效、更可控。

2.構建內部聊天工具

SDK 非常適合把復雜流程包裝成簡潔的聊天界面，供非技術用戶使用。例如，一個安裝器在遇到錯誤時，可以自動調用 Claude Code SDK 來修復問題；或者我們構建了一個類似 “v0-at-home” 的內部工具，讓設計團隊用自然語言“共創”前端原型，并在我們的自研 UI 框架中實時生成高保真、可直接用于生產的代碼。

3.快速原型開發

這是我最常見的用法——而且不局限于編程。當我有一個新的智能體想法時（比如一個使用自定義 CLI 或 MCP 的“威脅調查智能體”），我會先用 Claude Code SDK 快速構建并測試原型，在驗證可行后再決定是否開發完整的部署版本。

要點總結：Claude Code SDK 是一個通用型智能體框架。你可以用它來：

• 批量處理代碼任務，
• 構建內部自動化聊天工具，
• 或者快速驗證新的 Agent 概念。

在嘗試更復雜的框架之前，Claude Code SDK 往往已經足夠強大。

Claude Code GHA（GitHub Action）

Claude Code 的 GitHub Action（簡稱 GHA）大概是我最喜歡、也最容易被忽視的功能之一。它的概念非常簡單：在 GitHub Action 里運行 Claude Code。但正是這種“簡單”，讓它變得異常強大。

它有點像 Cursor 的后臺智能體，或 Codex 的托管式網頁界面，但 Claude Code GHA 的自定義能力遠超它們。你可以完全控制容器和運行環境，這意味著你能獲得更高的數據訪問自由度，同時在沙箱隔離與審計安全上擁有業界最強的能力。此外，它還支持所有高級特性，比如 Hooks 和 MCP。我們團隊用它構建了一個自定義的 “PR-from-anywhere（隨處發起 PR）” 工具鏈。用戶可以直接在 Slack、Jira，甚至 CloudWatch 警報 中觸發一個 PR 請求，然后 GHA 就會自動修復 bug 或添加功能，最終返回一個已測試通過的完整 Pull Request 。

更妙的是，GHA 的日志記錄了智能體的完整執行過程。我們在公司層面建立了一套運維流程，定期審查這些日志，查找常見錯誤、bash 異常或不符合工程規范的操作。這形成了一個數據驅動的改進飛輪：Bugs → 改進 CLAUDE.md / CLI → 更強的智能體。

甚至可以直接運行類似這樣的命令：

圖片

讓 Claude 自己分析過去幾天的所有智能體運行記錄，找出其他 Claude 卡住的問題、修復它們，并自動提交一個改進 PR。

要點總結：Claude Code GHA 是讓 Claude Code 真正進入工程體系的關鍵工具。它讓 Claude 從一個個人助手，升級為你團隊中可審計、可追蹤、可自我改進的核心基礎設施。

.json 配置

最后，我整理了一些在個人項目和專業工作中都非常關鍵的 settings.json 配置：

• HTTPS_PROXY / HTTP_PROXY：非常適合調試使用。我會用它來查看 Claude 發送的原始請求和提示詞。對于后臺智能體來說，它也是一種強大的精細化網絡沙箱控制工具。
• MCP_TOOL_TIMEOUT / BASH_MAX_TIMEOUT_MS：我會調高這些超時時間，因為我喜歡運行長時間、復雜的命令，而默認超時往往太保守。現在 bash 后臺任務流行了，我不確定是否還必須，但我習慣保留以防萬一。
• ANTHROPIC_API_KEY：在工作中，我們使用企業級 API Key（通過 apiKeyHelper 管理）。這樣可以將許可模式從“按席位付費”轉為按使用量付費，更符合我們團隊的實際工作方式。

  它還能應對工程師使用量的巨大差異（我們觀察到工程師之間有 1:100 的使用差異）。   同時，允許工程師在單一企業賬戶下自由嘗試非 Claude Code 的 LLM 腳本。

• “permissions”：我會定期自我審計，檢查允許 Claude 自動執行的命令列表。

要點總結：settings.json 是高級自定義的強大入口，可以幫助你根據工作流靈活調整網絡、超時、權限等核心參數。

網友：沒有工具比Claude Code改變我編程方式更多

這篇文章的 Hacker News 評論區也非常熱鬧，很多網友都在分享自己對Claude Code、MCP、CLI 使用和 VS Code 集成的實用經驗。

有網友十分認同作者對MCP的看法：

與其構建臃腫的 API，MCP 應該是一個簡單、安全的網關，提供少量強大的高級工具……MCP 的工作不是抽象現實給智能體，而是管理認證、網絡和安全邊界，然后退到一邊。

圖片

也有一些開發者分享，自己已經用輕量 CLI 替代 MCP，因為 CLI 更靈活、易于定制，而 MCP 更像是標準化、安全的內部網關。

“我發現 CLI 對 Claude 更容易，尤其是在規劃時指導它給用戶添加提示。我們的認證、日志、基礎設施狀態都是 CLI 可用的，用起來感覺不錯。”

“今天我的大部分集成都是純 CLI，而不是 MCP。CLI 可以做任何事，但 MCP 仍然作為標準存在，方便平臺采用統一接口。”

“我唯一的 MCP 是代碼解釋器。我最近嘗試做一個 MCP “代理”，讓智能體在代碼解釋器內調用 MCP。但總體上我仍不怎么用 MCP。”

圖片

還有網友表示：“編程15年，沒有工具比Claude Code改變我編程方式更多。”

圖片

有網友認為，直接用 Codex + GPT5 或 Claude Code CLI 比在 Cursor 更好，原因是Cursor 對輸出有限制，可能為了省 token。

也有人稱在 VS Code 用 Claude 和 Codex，效果很好。選中代碼 Cmd-L，效果不錯。

不少網友在評論區表示：Claude Code 比 Cursor 更好用。

“Claude CLI 輸出質量高，每天都給我價值。”

“Claude 編程能力比 Cursor 強。界面并不關鍵，我也喜歡 Cmd-L，但 Claude 寫代碼更好。Anthropic 專注于技能，而 Cursor 團隊……不太清楚。”

“Claude Code 比 Cursor 高效很多。計劃和工具使用更好。”

那么，如果你還沒有使用像 Claude Code 或 Codex CLI 這樣的 CLI 智能體，現在是時候嘗試了。

針對這些高級功能的指南非常少，所以唯一的學習方式就是親自上手，深入實踐。

希望這篇文章對大家有所幫助，歡迎在評論區聊聊你的看法。

參考鏈接：??https://blog.sshh.io/p/how-i-use-every-claude-code-feature??

本文轉載自??51CTO技術棧??，作者：聽雨