跳至主要内容

企業級Claude Code使用指南

翻譯自 Shrivu Shankar 的 "How I Use Every Claude Code Feature"，原作者每月消耗數十億tokens

Enterprise Development

譯者說明

作者既是個人開發者，也在企業團隊負責 AI-IDE 工具建設。這種雙重視角讓他的經驗特別有參考價值——哪些功能適合個人用、哪些適合團隊用，他都說得很清楚。

這篇文章最有價值的幾個點：

  • 反模式警告：明確指出哪些功能是過度設計
  • CLAUDE.md 哲學："從護欄開始，而不是手冊"
  • Scripting 模式：給 AI 原始環境訪問權，而不是抽象化的工具
  • 企業級實踐：GitHub Actions 自動化、日誌分析、持續最佳化的飛輪

我用 Claude Code。用得很多。

作為愛好者，我每週會在虛擬機器中執行它好幾次來做副專案，經常使用 --dangerously-skip-permissions 來快速實現腦海中的任何想法。在工作中，我所在團隊的部分職責是為工程團隊構建 AI-IDE 規則和工具，我們每月僅在程式碼生成上就消耗數十億 tokens。

CLI agent 領域正變得越來越擁擠，在 Claude Code、Gemini CLI、Cursor 和 Codex CLI 之間，真正的競爭似乎是在 Anthropic 和 OpenAI 之間展開。但說實話，當我和其他開發者交流時，他們的選擇往往歸結於一些看似表面的東西——某個"幸運"的功能實現，或者他們就是更喜歡某個系統提示詞的"氛圍"。目前這些工具都相當不錯。我也覺得人們經常過度關注輸出風格或 UI。對我來說，那種"你說得完全對！"的諂媚並不是一個值得注意的 bug；它是一個訊號，說明你過度參與了。總的來說，我的目標是"發射後不管"——委託任務、設定上下文，然後讓它自己工作。我透過最終的 PR 來評判工具，而不是它如何完成的過程。

在過去幾個月堅持使用 Claude Code 後，這篇文章是我對 Claude Code 整個生態系統的反思總結。我們將涵蓋我使用的幾乎每個功能（同樣重要的是，我不使用的功能），從基礎的 CLAUDE.md 檔案和自定義 slash 命令，到強大的 Subagents、Hooks 和 GitHub Actions。這篇文章最終寫得有點長，我建議把它當作參考資料，而不是一口氣讀完。

CLAUDE.md​

在有效使用 Claude Code 時，程式碼庫中最重要的單個檔案就是根目錄的 CLAUDE.md。這個檔案是 agent 的"憲法"，是關於你的特定倉庫如何工作的主要真相來源。

你如何對待這個檔案取決於具體情況。對於我的愛好專案，我讓 Claude 隨便往裡面寫它想寫的東西。

對於我的專業工作，我們 monorepo 的 CLAUDE.md 是嚴格維護的，目前有 13KB（我可以很容易地看到它增長到 25KB）。

  • 它只記錄 30%（任意閾值）或更多工程師使用的工具和 API（否則工具會在產品或庫特定的 markdown 檔案中記錄）
  • 我們甚至開始為每個內部工具的文件有效地分配最大 token 數，幾乎就像向團隊出售"廣告位"。如果你無法簡潔地解釋你的工具，它就還沒準備好放進 CLAUDE.md。

技巧和常見反模式​

隨著時間的推移，我們形成了一套強有力的、有主見的編寫有效 CLAUDE.md 的哲學。

從護欄開始，而不是手冊。你的 CLAUDE.md 應該從小處開始，根據 Claude 做錯的地方來編寫文件。

不要 @-引用文件檔案。如果你在別處有大量文件，你可能會想在 CLAUDE.md 中 @-提及這些檔案。這會透過在每次執行時嵌入整個檔案來使上下文視窗膨脹。但如果你只是提到路徑，Claude 通常會忽略它。你必須向 agent 推銷為什麼以及何時閱讀該檔案。"對於複雜的...使用或如果遇到 FooBarError，請參閱 path/to/docs.md 瞭解高階故障排除步驟。"

不要只說"絕不"。避免純負面約束，如"絕不使用 --foo-bar 標誌"。當 agent 認為它必須使用該標誌時，它會卡住。始終提供替代方案。

將 CLAUDE.md 用作強制函式。如果你的 CLI 命令複雜且冗長，不要寫幾段文件來解釋它們。那是在修補一個人類問題。相反，編寫一個簡單的 bash 包裝器，提供清晰、直觀的 API，並記錄它。儘可能保持 CLAUDE.md 簡短是簡化程式碼庫和內部工具的絕佳強制函式。

這是一個簡化的快照：

# Monorepo

## Python
- 总是...
- 用 <command> 测试
... 还有 10 条...

## <内部 CLI 工具>
... 10 条要点，专注于 80% 的用例...
- <使用示例>
- 总是...
- 绝不 <x>，优先 <Y>

对于 <复杂使用> 或 <错误> 请参阅 path/to/<tool>_docs.md

...

最後，我們保持這個檔案與 AGENTS.md 檔案同步，以保持與我們工程師可能使用的其他 AI IDE 的相容性。

如果你正在尋找更多為編碼 agent 編寫 markdown 的技巧，請參閱"AI Can't Read Your Docs"、"AI-powered Software Engineering"和"How Cursor (AI IDE) Works"。

要點：將你的 CLAUDE.md 視為一組高層次、精心策劃的護欄和指標。用它來指導你需要在哪裡投資更 AI（和人類）友好的工具，而不是試圖讓它成為一本綜合手冊。

緊湊、上下文和清晰​

我建議在編碼會話中至少執行一次 /context，以瞭解你如何使用 200k token 的上下文視窗（即使有 Sonnet-1M，我也不相信整個上下文視窗實際上被有效使用了）。對我們來說，在 monorepo 中開始一個新會話的基線成本約為 20k tokens（10%），剩餘的 180k 用於進行更改——這可以很快填滿。

我最近一個副專案中 /context 的截圖。你幾乎可以把這看作是磁碟空間，在你處理功能時會填滿。幾分鐘或幾小時後，你需要清除訊息（紫色）以騰出空間繼續。

我有三個主要工作流程：

  1. /compact（避免）：我儘可能避免使用這個。自動壓縮是不透明的、容易出錯的，而且最佳化得不好。

  2. /clear + /catchup（簡單重啟）：我的預設重啟方式。我 /clear 狀態，然後執行自定義的 /catchup 命令，讓 Claude 讀取我 git 分支中所有更改的檔案。

  3. "文件化並清除"（複雜重啟）：用於大型任務。我讓 Claude 將其計劃和進度轉儲到一個 .md 檔案中，/clear 狀態，然後透過告訴它讀取 .md 並繼續來啟動新會話。

要點：不要信任自動壓縮。對簡單重啟使用 /clear，對複雜任務使用"文件化並清除"方法來建立持久的外部"記憶"。

自定義 Slash 命令​

我認為 slash 命令只是常用提示詞的簡單快捷方式，僅此而已。我的設定很簡單：

  • /catchup：我之前提到的命令。它只是提示 Claude 讀取我當前 git 分支中所有更改的檔案。
  • /pr：一個簡單的輔助工具，用於清理程式碼、暫存並準備拉取請求。

在我看來，如果你有一長串複雜的自定義 slash 命令，你就建立了一個反模式。對我來說，像 Claude 這樣的 agent 的全部意義在於，你可以輸入幾乎任何你想要的東西，並獲得有用的、可合併的結果。當你強迫工程師（或非工程師）學習一個新的、記錄在某處的基本魔法命令列表才能完成工作時，你就失敗了。

要點：將 slash 命令用作簡單的個人快捷方式，而不是作為構建更直觀的 CLAUDE.md 和更好工具化 agent 的替代品。

自定義 Subagents​

從理論上講，自定義 subagents 是 Claude Code 最強大的上下文管理功能。宣傳很簡單：一個複雜任務需要 X tokens 的輸入上下文（例如，如何執行測試），累積 Y tokens 的工作上下文，併產生 Z token 的答案。執行 N 個任務意味著主視窗中有 (X + Y + Z) * N tokens。

subagent 解決方案是將 (X + Y) * N 的工作分配給專門的 agents，它們只返回最終的 Z token 答案，保持主上下文清潔。

我發現它們是一個強大的想法，但在實踐中，自定義 subagents 會產生兩個新問題：

  1. 它們把守上下文：如果我建立一個 PythonTests subagent，我現在已經對主 agent 隱藏了所有測試上下文。它不再能夠整體推理一個更改。現在它被迫呼叫 subagent 只是為了知道如何驗證自己的程式碼。

  2. 它們強制人類工作流程：更糟的是，它們強制 Claude 進入一個僵化的、人類定義的工作流程。我現在在規定它必須如何委託，而這正是我試圖讓 agent 為我解決的問題。

我更喜歡的替代方案是使用 Claude 內建的 Task(...) 功能來生成通用 agent 的克隆。

我將所有關鍵上下文放在 CLAUDE.md 中。然後，我讓主 agent 決定何時以及如何將工作委託給自己的副本。這給了我 subagents 的所有上下文節省優勢，而沒有缺點。agent 動態管理自己的編排。

在我的"Building Multi-Agent Systems (Part 2)"帖子中，我稱這為"Master-Clone"架構，我強烈傾向於它，而不是自定義 subagents 鼓勵的"Lead-Specialist"模型。

要點：自定義 subagents 是一個脆弱的解決方案。給你的主 agent 上下文（在 CLAUDE.md 中），讓它使用自己的 Task/Explore(...) 功能來管理委託。

Resume、Continue 和 History​

在簡單層面上，我經常使用 claude --resume 和 claude --continue。它們非常適合重啟有問題的終端或快速重啟舊會話。我經常 claude --resume 幾天前的會話，只是為了讓 agent 總結它如何克服特定錯誤，然後我用這些來改進我們的 CLAUDE.md 和內部工具。

更深入一點，Claude Code 將所有會話歷史儲存在 ~/.claude/projects/ 中，以便利用原始歷史會話資料。我有指令碼對這些日誌執行元分析，尋找常見的異常、許可權請求和錯誤模式，以幫助改進面向 agent 的上下文。

要點：使用 claude --resume 和 claude --continue 來重啟會話併發掘隱藏的歷史上下文。

Hooks​

Hooks 非常重要。我不在愛好專案中使用它們，但它們對於在複雜的企業倉庫中引導 Claude 至關重要。它們是確定性的"必須做"規則，補充了 CLAUDE.md 中的"應該做"建議。

我們使用兩種型別：

  1. 提交時阻止 Hooks：這是我們的主要策略。我們有一個 PreToolUse hook，它包裝任何 Bash(git commit) 命令。它檢查 /tmp/agent-pre-commit-pass 檔案，只有當所有測試透過時，我們的測試指令碼才會建立該檔案。如果檔案缺失，hook 會阻止提交，強制 Claude 進入"測試和修復"迴圈，直到構建成功。

  2. 提示 Hooks：這些是簡單的、非阻塞性的 hooks，如果 agent 正在做一些次優的事情，會提供"一次性"反饋。

我們故意不使用"寫入時阻止"hooks（例如，在 Edit 或 Write 上）。在計劃中途阻止 agent 會使其困惑甚至"沮喪"。讓它完成工作，然後在提交階段檢查最終完成的結果，這要有效得多。

要點：使用 hooks 在提交時強制執行狀態驗證（提交時阻止）。避免在寫入時阻止——讓 agent 完成其計劃，然後檢查最終結果。

計劃模式​

對於任何使用 AI IDE 進行的"大型"功能更改，計劃都是必不可少的。

對於我的愛好專案，我專門使用內建的計劃模式。這是在 Claude 開始之前與它對齊的一種方式，定義如何構建某些東西以及它需要停下來向我展示其工作的"檢查點"。定期使用這個功能可以建立一個強大的直覺，瞭解獲得一個好計劃所需的最少上下文是什麼，而不會讓 Claude 搞砸實施。

在我們的工作 monorepo 中，我們已經開始推出基於 Claude Code SDK 構建的自定義計劃工具。它類似於原生計劃模式，但經過大量提示，以將其輸出與我們現有的技術設計格式對齊。它還強制執行我們內部的最佳實踐——從程式碼結構到資料隱私和安全——開箱即用。這讓我們的工程師可以像高階架構師一樣"快速規劃"一個新功能（或者至少這是宣傳）。

要點：對於複雜的更改，始終使用內建的計劃模式，以便在 agent 開始工作之前就計劃達成一致。

Skills​

我同意 Simon Willison 的觀點：Skills 可能比 MCP 更重要。

如果你一直在關注我的帖子，你會知道我已經在大多數開發工作流程中遠離了 MCP，更傾向於構建簡單的 CLI（正如我在"AI Can't Read Your Docs"中所論證的）。我對 agent 自主性的心智模型已經演變為三個階段：

  1. 單一提示詞：在一個巨大的提示詞中給 agent 所有上下文。（脆弱，不可擴充套件）。
  2. 工具呼叫："經典"agent 模型。我們手工製作工具併為 agent 抽象現實。（更好，但建立了新的抽象和上下文瓶頸）。
  3. 指令碼編寫：我們給 agent 訪問原始環境的許可權——二進位制檔案、指令碼和文件——它即時編寫程式碼與它們互動。

考慮到這個模型，Agent Skills 是顯而易見的下一個功能。它們是"指令碼編寫"層的正式產品化。

如果像我一樣，你已經在偏向 CLI 而不是 MCP，那麼你一直在隱式地獲得 Skills 的好處。SKILL.md 檔案只是一種更有組織、可共享和可發現的方式來記錄這些 CLI 和指令碼，並將它們暴露給 agent。

要點：Skills 是正確的抽象。它們將基於"指令碼編寫"的 agent 模型正式化，這比 MCP 代表的僵化的、類似 API 的模型更強大和靈活。

MCP（模型上下文協議）​

Skills 並不意味著 MCP 已經死了（另見"Everything Wrong with MCP"）。以前，許多人構建了糟糕的、上下文繁重的 MCP，其中有數十個工具，只是映象 REST API（read_thing_a()、read_thing_b()、update_thing_c()）。

"指令碼編寫"模型（現在由 Skills 正式化）更好，但它需要一種安全的方式來訪問環境。在我看來，這是 MCP 新的、更專注的角色。

MCP 不應該是一個臃腫的 API，而應該是一個簡單、安全的閘道器，提供一些強大的、高階的工具：

  • download_raw_data(filters...)
  • take_sensitive_gated_action(args...)
  • execute_code_in_environment_with_state(code...)

在這個模型中，MCP 的工作不是為 agent 抽象現實；它的工作是管理身份驗證、網路和安全邊界，然後讓開。它為 agent 提供入口點，然後 agent 使用其指令碼編寫和 markdown 上下文來完成實際工作。

我仍然使用的唯一 MCP 是 Playwright，這是有道理的——它是一個複雜的、有狀態的環境。我所有無狀態的工具（如 Jira、AWS、GitHub）都已遷移到簡單的 CLI。

要點：使用充當資料閘道器的 MCP。給 agent 一兩個高階工具（如原始資料轉儲 API），然後它可以對其編寫指令碼。

Claude Code SDK​

Claude Code 不僅僅是一個互動式 CLI；它也是一個強大的 SDK，用於構建全新的 agents——無論是編碼還是非編碼任務。我已經開始將它用作大多數新愛好專案的預設 agent 框架，而不是 LangChain/CrewAI 等工具。

我以三種主要方式使用它：

  1. 大規模並行指令碼編寫：對於大規模重構、bug 修復或遷移，我不使用互動式聊天。我編寫簡單的 bash 指令碼，並行呼叫 claude -p "in /pathA change all refs from foo to bar"。這比試圖讓主 agent 管理數十個 subagent 任務更具可擴充套件性和可控性。

  2. 構建內部聊天工具：SDK 非常適合為非技術使用者將複雜流程包裝在簡單的聊天介面中。比如一個安裝程式，在出錯時，回退到 Claude Code SDK 只是為使用者修復問題。或者一個內部的"v0-at-home"工具，讓我們的設計團隊在我們的內部 UI 框架中快速編寫模擬前端，確保他們的想法是高保真的，程式碼在前端生產程式碼中更直接可用。

  3. 快速 Agent 原型設計：這是我最常見的用途。它不僅僅用於編碼。如果我對任何 agentic 任務有想法（例如，使用自定義 CLI 或 MCP 的"威脅調查 agent"），我使用 Claude Code SDK 快速構建和測試原型，然後再承諾完整的、已部署的腳手架。

要點：Claude Code SDK 是一個強大的、通用的 agent 框架。使用它進行批處理程式碼、構建內部工具，以及在使用更復雜的框架之前快速原型化新 agents。

Claude Code GHA​

Claude Code GitHub Action（GHA）可能是我最喜歡和最被低估的功能之一。這是一個簡單的概念：只需在 GHA 中執行 Claude Code。但這種簡單性正是它如此強大的原因。

它類似於 Cursor 的後臺 agents 或 Codex 管理的 web UI，但可定製性要高得多。你控制整個容器和環境，讓你可以訪問更多資料，更重要的是，比任何其他產品提供的沙箱和審計控制要強得多。此外，它支援所有高階功能，如 Hooks 和 MCP。

我們用它來構建自定義的"從任何地方發起 PR"工具。使用者可以從 Slack、Jira 甚至 CloudWatch 警報觸發 PR，GHA 將修復 bug 或新增功能並返回一個經過充分測試的 PR。

由於 GHA 日誌是完整的 agent 日誌，我們有一個運營流程，定期在公司層面審查這些日誌，查詢常見錯誤、bash 錯誤或不一致的工程實踐。這建立了一個資料驅動的飛輪：Bugs -> 改進的 CLAUDE.md / CLI -> 更好的 Agent。

$ query-claude-gha-logs --since 5d | claude -p "看看其他 claudes 在哪里卡住了并修复它，然后提交 PR"

要點：GHA 是將 Claude Code 運營化的終極方式。它將其從個人工具轉變為工程系統的核心、可審計和自我改進的部分。

settings.json​

最後，我有一些特定的 settings.json 配置，我發現這些配置對於愛好和專業工作都是必不可少的。

  • HTTPS_PROXY/HTTP_PROXY：這對於除錯非常有用。我會用它來檢查原始流量，以準確檢視 Claude 傳送的提示詞。對於後臺 agents，它也是細粒度網路沙箱的強大工具。

  • MCP_TOOL_TIMEOUT/BASH_MAX_TIMEOUT_MS：我會增加這些。我喜歡執行長時間、複雜的命令，預設超時通常過於保守。我誠實地不確定現在 bash 後臺任務已經存在後是否還需要這個，但我還是保留了它以防萬一。

  • ANTHROPIC_API_KEY：在工作中，我們使用企業 API 金鑰（透過 apiKeyHelper）。它將我們從"按席位"許可證轉變為"基於使用量"的定價，這對我們的工作方式來說是一個更好的模型。

    • 它考慮了開發者使用量的巨大差異（我們見過工程師之間 1:100 倍的差異）。
    • 它讓工程師可以使用非 Claude-Code LLM 指令碼進行修補，所有這些都在我們的單一企業賬戶下。

  • "permissions"：我會偶爾自我審計我允許 Claude 自動執行的命令列表。

要點：你的 settings.json 是進行高階定製的強大場所。

結論​

內容很多，但希望對你有用。如果你還沒有使用像 Claude Code 或 Codex CLI 這樣的基於 CLI 的 agent，你可能應該使用。這些高階功能很少有好的指南，所以學習的唯一方法就是深入研究。

原文資訊
  • 原文作者: Shrivu Shankar
  • 原文標題: How I Use Every Claude Code Feature
  • 釋出時間: 2025年11月