最成功的 Claude Code 部署在配置、工具和組織結構上都展現出一系列可識別的模式。本文是「Claude Code 規模化應用」系列文章的一部分，該系列涵蓋了為企業規模構建 Claude Code 的工程組織提供的最佳實踐。
Claude Code 已在生產環境中部署於擁有數百萬行程式碼的單一儲存庫（monorepos）、數十年的舊系統、橫跨數十個儲存庫的分散式架構，以及擁有數千名開發者的組織中。這些環境帶來了小型、簡單程式碼庫所沒有的挑戰，例如每個子目錄的建置指令都不同，或是散佈在沒有共享根目錄的資料夾中的舊程式碼。
本文涵蓋了我們觀察到並成功推動 Claude Code 規模化採用的模式。「大型程式碼庫」一詞用於指代廣泛的部署：擁有數百萬行程式碼的單一儲存庫、數十年來建置的舊系統、分散在獨立儲存庫中的數十個微服務，或上述任何組合。這也包括了團隊通常不與 AI 編碼工具聯想在一起的語言的程式碼庫，例如 C、C++、C#、Java、PHP。（在這些情況下，Claude Code 的表現比大多數團隊預期的要好，尤其是在最近的模型發布之後。）雖然每個大型程式碼庫的部署都受到其特定的版本控制、團隊結構和累積慣例的影響，但這裡的模式在它們之間是通用的，並且是考慮採用 Claude Code 的團隊的良好起點。
Claude Code 的程式碼庫導航方式與軟體工程師相同：它會遍歷檔案系統、讀取檔案、使用 grep 尋找所需內容，並追蹤程式碼庫中的引用。它在開發者的本機機器上運行，不需要建置、維護或上傳程式碼庫索引到伺服器。
RAG 驅動的 AI 編碼工具透過嵌入整個程式碼庫並在查詢時檢索相關區塊來工作。在大規模應用中，這些系統可能會失敗，因為嵌入管道無法跟上活躍的工程團隊。當開發者查詢索引時，它反映的是幾週、幾天甚至幾小時前的程式碼庫。檢索到的結果可能是一個團隊兩週前重新命名的函式，或是一個在上個衝刺階段被刪除的模組的引用，而且沒有任何過時的跡象。
代理式搜尋（Agentic search）避免了這些失敗模式。沒有嵌入管道或中央索引需要維護，因為數千名工程師會提交新程式碼。每個開發者的執行個體都從即時程式碼庫中工作。
但這種方法有一個權衡：當 Claude 有足夠的起始上下文知道從何處開始尋找時，它的效果最好。這意味著 Claude 導航的品質取決於程式碼庫的設定方式，透過 CLAUDE.md 檔案和技能來疊加上下文。如果你要求它在一個包含十億行程式碼的程式碼庫中尋找一個模糊模式的所有實例，那麼在工作開始之前，你就會達到上下文窗口的限制。投入程式碼庫設定的團隊會看到更好的結果。
關於 Claude Code 最常見的誤解之一是，它的能力完全由使用的模型定義。團隊專注於模型的基準測試以及它在測試任務上的表現。實際上，圍繞模型的生態系統——即「線束」（harness）——比模型本身更能決定 Claude Code 的表現。
線束由五個擴充點組成：CLAUDE.md 檔案、Hooks、Skills、Plugins 和 MCP Servers，每個都有不同的功能。團隊建置它們的順序很重要，因為每一層都建立在之前一層的基礎上。另外兩個功能，LSP 整合和子代理，則完善了設定。接下來，我們將解釋這些組件和功能的作用：
CLAUDE.md 檔案是第一步。這些是上下文檔案，Claude 在每個會話開始時都會自動讀取：根檔案用於宏觀視角，子目錄檔案用於局部慣例。它們為 Claude 提供了做好任何事情所需的程式碼庫知識。由於它們在每個會話中都會載入，無論任務為何，保持它們專注於廣泛適用的內容將防止它們拖慢效能。
Hooks 使設定能夠自我改進。大多數團隊將 Hooks 視為防止 Claude 出錯的腳本，但它們更有價值的用途是持續改進。一個停止 Hook 可以反思會話期間發生的事情，並在上下文仍然新鮮時提出 CLAUDE.md 更新。一個啟動 Hook 可以動態載入團隊特定的上下文，以便每個開發者都能獲得其模組的正確設定，而無需手動配置。對於自動檢查，如程式碼風格檢查和格式化，Hooks 可以確定性地強制執行規則，並產生比依賴 Claude 記住指令更一致的結果。
Skills 能夠按需提供正確的專業知識，而不會使每個會話都臃腫。在擁有數十種任務類型的龐大程式碼庫中，並非所有專業知識都需要存在於每個會話中。Skills 透過漸進式揭露（progressive disclosure）來解決這個問題，將那些原本會佔用上下文空間的專門工作流程和領域知識卸載，並僅在任務需要時載入。例如，安全審查技能在 Claude 評估程式碼的漏洞時載入，而文件處理技能則在程式碼變更並需要更新文件時載入。
Skills 也可以限定在特定路徑，因此它們只會在程式碼庫的相關部分啟動。負責支付服務的團隊可以將其部署技能綁定到該目錄，這樣在 monorepo 的其他地方工作時就不會自動載入。
Plugins 分發有效的方法。大型程式碼庫的一個挑戰是，好的設定可能會停留在小圈子裡。Plugin 將 Skills、Hooks 和 MCP 配置捆綁成一個單一的可安裝套件，因此當新工程師在第一天安裝該 Plugin 時，他們將立即擁有與已經使用 Claude 的人相同的上下文和功能。Plugin 更新可以透過受管理的市場（managed marketplaces）在組織內分發。
例如，我們合作的一家大型零售組織建置了一個將 Claude 連接到其內部分析平台的技能，以便業務分析師可以在不離開工作流程的情況下提取績效數據。他們在廣泛推廣給業務部門之前，將其作為 Plugin 分發。
語言伺服器協議（LSP）整合為 Claude 提供了開發者在其 IDE 中所擁有的相同導航能力。大多數大型程式碼庫的 IDE 已經運行著 LSP，支援「跳至定義」和「尋找所有引用」。將此功能暴露給 Claude，可以提供符號級別的精確度：它可以追蹤函式調用到其定義，追蹤跨檔案的引用，並區分不同語言中同名函式。沒有它，Claude 會對文本進行模式匹配，並可能找到錯誤的符號。我們合作的一家企業軟體公司在其 Claude Code 推出前，就在整個組織部署了 LSP 整合，特別是為了確保 C 和 C++ 在規模化應用中的導航可靠性。對於多語言程式碼庫來說，這是最有價值的投資之一。
MCP Servers 擴展了一切。MCP Servers 是 Claude 連接其無法觸及的內部工具、數據源和 API 的方式。最先進的團隊建置了暴露結構化搜尋作為 Claude 可直接調用的工具的 MCP Servers。其他團隊則將 Claude 連接到內部文件、票務系統或分析平台。
Subagents 將探索與編輯分開。Subagent 是一個獨立的 Claude 執行個體，擁有自己的上下文窗口，它接收一個任務，完成工作，然後只將最終結果返回給父代理。一旦線束到位，一些團隊會啟動一個只讀的 Subagent 來映射一個子系統並將發現寫入文件，然後讓主代理根據完整的圖景進行編輯。
下表總結了每個組件的作用、載入時間以及我們經常看到的錯誤：
如何為大型程式碼庫配置 Claude Code，很大程度上取決於該程式碼庫的結構。儘管如此，我們觀察到的部署中始終出現了三種模式。
Claude 在大型程式碼庫中提供協助的能力，受限於其尋找正確上下文的能力。每個會話載入過多的上下文會降低效能，而過少的上下文則會讓 Claude 盲目導航。最有效的部署會預先投入資源，使程式碼庫對 Claude 來說是可讀的。有幾種模式始終出現：
一個注意事項：在某些邊緣情況下，即使是階層式的 CLAUDE.md 方法也會失效，例如擁有數十萬個資料夾和數百萬個檔案的程式碼庫，或使用非 Git 版本控制的舊系統。我們將在後續系列文章中探討它們的挑戰。對於舊系統，請參閱 AI 如何打破 COBOL 現代化的成本障礙。
隨著模型的演進，為當前模型編寫的指令可能會對未來的模型產生反作用。曾經引導 Claude 解決它過去難以解決的模式的 CLAUDE.md 檔案，在下一代模型發布時，可能會變得不必要，甚至會產生限制。例如，一個告訴 Claude 將每次重構分解為單一檔案變更的 CLAUDE.md 規則，可能對早期模型有所幫助，但會阻止更新的模型進行它能很好處理的協調式跨檔案編輯。
一旦這些限制不再存在，為彌補特定模型限制（無論是模型推理能力還是 Claude Code 本身的工具限制）而建置的 Skills 和 Hooks 就會變成額外的負擔。例如，一個用於強制執行 Perforce 程式碼庫中 p4 edit 的 Hook，一旦 Claude Code 增加了原生的 Perforce 模式，就變得多餘了。
團隊應該預期每三到六個月進行一次有意義的配置審查，但在主要模型發布後效能似乎停滯不前時，也值得進行一次審查。
單純的技術配置並不能推動採用。那些做得好的組織也在組織層面進行了投資。
推廣速度最快的部署，在廣泛訪問之前就進行了專門的基礎設施投資。一個小型團隊，有時甚至只有一個人，就已經將工具連接好，以便開發者在第一次接觸 Claude 時，它已經融入了他們的開發流程。在一間公司，有幾位工程師建置了一套 Plugin 和 MCP，這些在第一天就可用了。在另一間公司，一個專門管理 AI 編碼工具的團隊在推廣開始前就已經準備好了基礎設施。在這兩種情況下，開發者的第一次體驗都是富有成效的，而不是令人沮喪的，從那裡採用就開始傳播。
今天從事這項工作的大多數團隊都隸屬於開發者體驗或開發者生產力部門，這通常是負責新工程師入職和建置開發者工具的職能。在一些組織中，一個新興的角色是代理管理器（agent manager）：一個結合了產品經理和工程師職能的職位，專門負責管理 Claude Code 生態系統。對於沒有專門團隊的組織來說，最低可行版本是 DRI（直接負責人）：一個人負責 Claude Code 配置、設定決策權、權限策略、Plugin 市場和 CLAUDE.md 約定，並負責保持它們的最新狀態。
自下而上的採用會產生熱情，但如果沒有人來集中化有效的方法，可能會變得分散。你需要有一個個人或團隊來組建並推廣正確的 Claude Code 約定（例如標準化的 CLAUDE.md 層級結構或精選的 Skills 和 Plugins）。沒有這些工作，知識將停留在小圈子裡，採用也會停滯不前。
在大組織中，尤其是在受監管的行業中，治理問題會很早就出現，例如：誰控制哪些 Skills 和 Plugins 可用，如何防止數千名工程師獨立重複建置相同的功能，如何確保 AI 生成的程式碼與人類生成的程式碼一樣經過相同的審查流程？為了及早解決這些問題，我們建議從定義一組批准的 Skills、必需的程式碼審查流程和有限的初始訪問開始，並隨著信心的建立而擴展。
我們觀察到最順利的部署發生在那些早期建立跨職能工作組的組織，這些工作組匯集了工程、資訊安全和治理代表，共同定義需求並建置推廣路線圖。
Claude Code 是圍繞著傳統軟體工程環境設計的，其中工程師是主要的程式碼庫貢獻者，儲存庫使用 Git，程式碼遵循標準的目錄結構。大多數大型程式碼庫都符合這種模式，但非傳統的設定，例如包含大型二進位資產的遊戲引擎、使用非常規版本控制的環境，或由非工程師貢獻程式碼庫，都需要額外的配置工作。我們的指南假設採用傳統設定，並且我們描述的模式在我們的許多客戶中都得到了驗證。任何剩餘的複雜性都需要針對您的程式碼庫、工具和組織進行特定判斷。這就是 Anthropic 的應用 AI 團隊直接與工程團隊合作，將這些模式轉化為您組織特定需求的領域。