# 策展 · X (Twitter) 🔥🔥

> 作者：nash_su - e/acc (@nash_su) · 平台：X (Twitter) · 日期：2026-05-16

> 原始來源：https://x.com/nash_su/status/2055541927508881654

## 中文摘要

# Claude Code 在大型程式庫中的運作方式：最佳實踐與入門指南

Claude Code 已在數百萬行規模的單體倉庫、數十年歷史的遺留系統、橫跨數十個倉庫的分散式架構，以及擁有數千名開發者的組織中投入生產。這些環境帶來了小型程式庫所沒有的挑戰——無論是每個子目錄中不同的建置指令，還是散落在資料夾中、沒有共享根目錄的遺留程式碼。

本文涵蓋了我們觀察到的、在規模化採用 Claude Code 時取得成功的模式。我們所說的「大型程式庫」涵蓋多種部署場景：數百萬行的單體倉庫、歷經數十年建置的遺留系統、跨獨立倉庫的數十個微服務，或以上任意組合。這還包括團隊通常不認為與 AI 程式開發工具相關的語言，如 C、C++、C#、Java、PHP。（在這些情況下，Claude Code 的表現通常超出團隊預期，尤其是在最近的模型版本中。）雖然每個大型程式庫的部署都受其特定版本控制、團隊結構和累積的慣例影響，但這裡的模式具有普適性，是考慮採用 Claude Code 的團隊的良好起點。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778975500647-diaHIazMibIAAAu3Kjpg.jpg)

Claude Code 如何導航大型程式庫

Claude Code 導航程式庫的方式與軟體工程師相同：它遍歷檔案系統、讀取檔案、使用 grep 精確搜尋所需內容，並跨程式庫追蹤引用。它在開發者的本地機器上執行，無需建置、維護或上傳程式庫索引到伺服器。

> 基於 RAG 的 AI 程式開發工具透過嵌入整個程式庫並在查詢時檢索相關片段來運作。在大型規模下，這些系統可能失敗，因為嵌入管道無法跟上活躍工程團隊的步伐。當開發者查詢索引時，它反映的是數週、數天甚至數小時前存在的程式庫狀態。檢索結果可能返回團隊兩週前重新命名的函式，或引用上個衝刺（sprint）中刪除的模組，且沒有任何跡象表明它們已過時。

Agent 式搜尋避免了這些失敗模式。沒有嵌入管道或集中式索引需要維護，即使數千名工程師提交新程式碼。每個開發者的實例都基於即時程式庫工作。

但這種做法有一個權衡：當 Claude 有足夠的起始上下文知道去哪裡查找時，它表現最佳。這意味著 Claude 的導航品質受程式庫設定方式的影響——透過 `CLAUDE.md` 檔案和技能來分層提供上下文。如果你要求它在十億行程式庫中查找所有模糊模式的實例，你會在工作開始前就觸及 context window 限制。投資於程式庫設定的團隊會看到更好的結果。

## 工具鏈與模型同樣重要

關於 Claude Code 最常見的誤解之一是，其能力完全由所使用的模型決定。團隊關注模型的基準測試及其在測試任務上的表現。實際上，圍繞模型建構的生態系統——即工具鏈——對 Claude Code 效能的影響比模型本身更大。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778975500635-ediaHIa5HIb0AEXwPjpg.jpg)

工具鏈由五個擴充點建構——`CLAUDE.md` 檔案、鉤子（hooks）、技能、plugin 和 MCP 伺服器——每個都有不同功能。團隊建構它們的順序很重要，因為每一層都建立在前一層之上。另外兩個能力——LSP 整合和子 Agent——完善了整個設定。以下是每個組件和能力的說明：

CLAUDE.md 檔案：首要步驟

這些是 Claude 在每個會話開始時自動讀取的上下文檔案：根檔案用於全域概覽，子目錄檔案用於局部約定。它們為 Claude 提供做好任何事情所需的程式庫知識。由於它們無論任務如何都會在每個會話中載入，保持它們聚焦於廣泛適用的內容，可以防止它們成為效能拖累。

鉤子：使設定自我改進

大多數團隊將鉤子視為防止 Claude 做錯事的腳本，但它們更有價值的用途是持續改進。停止鉤子可以反思會話中發生的事情，並在上下文仍新鮮時提出 `CLAUDE.md` 更新。啟動鉤子可以動態載入團隊特定的上下文，使每個開發者無需手動設定就能獲得其模組的正確設定。對於 linting 和格式化等自動化檢查，鉤子確定性地執行規則，比依賴 Claude 記住指令產生更一致的結果。

技能：按需提供專業知識，不膨脹每個會話

在包含數十種任務類型的大型程式庫中，並非所有專業知識都需要在每個會話中出現。技能透過漸進式披露解決這個問題，將專門的工作流和領域知識卸載，僅在任務需要時載入。例如，安全審查技能在 Claude 評估程式碼漏洞時載入，而文件處理技能在程式碼變更需要更新文件時載入。

技能還可以限定到特定路徑，因此僅在程式庫的相關部分啟用。擁有支付服務的團隊可以將部署技能綁定到該目錄，這樣當有人在單體倉庫的其他地方工作時，它永遠不會自動載入。

plugin：分發有效的内容

大型程式庫的一個挑戰是，好的設定可能停留在小圈子內。plugin 將技能、鉤子和 MCP 設定打包成一個可安裝的包，因此當新工程師第一天安裝該 plugin 時，他們將立即擁有與長期使用 Claude 的人相同的上下文和能力。plugin 更新可以透過託管市場在整個組織中分發。

例如，我們合作的一家大型零售組織建構了一個技能，將 Claude 連接到他們的內部分析平台，使業務分析師無需離開工作流即可拉取效能資料。他們在向業務部門廣泛推廣之前，將其作為 plugin 分發。

語言伺服器協定（LSP）整合：賦予 Claude 與 IDE 相同的導航能力

大多數大型程式庫的 IDE 已經執行著 LSP，支援「轉到定義」和「查找所有引用」。將這一能力暴露給 Claude，使其獲得符號級別的精度：它可以追蹤函式呼叫到其定義，跨檔案追蹤引用，並區分不同語言中同名的函式。沒有它，Claude 會進行文字模式匹配，可能定位到錯誤的符號。我們合作的一家企業軟體公司在 Claude Code 推廣之前，就在全組織部署了 LSP 整合，專門用於使 C 和 C++ 導航在大型規模下可靠。對於多語言程式庫，這是最高價值的投資之一。

MCP 伺服器：擴充一切

MCP 伺服器是 Claude 連接到內部工具、資料源和 API 的方式，這些是它無法直接存取的。最成熟的團隊建構了 MCP 伺服器，將結構化搜尋作為 Claude 可以直接呼叫的工具暴露出來。其他團隊將 Claude 連接到內部文件、工單系統或分析平台。

子 Agent：將探索與編輯分離

子 Agent 是一個獨立的 Claude 實例，擁有自己的 context window，它接受任務、完成工作，並僅將最終結果返回給父 Agent。一旦工具鏈就位，一些團隊會啟動一個唯讀子 Agent 來映射程式庫結構，而主 Agent 則專注於編輯任務。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778975500642-ediaHIaCkaUAA4LZkjpg.jpg)

結論與主張

1. 投資於程式庫設定：`CLAUDE.md` 檔案、鉤子和技能的正確設定是成功的關鍵。團隊應優先建構這些基礎層。

1. 工具鏈比模型更重要：不要只關注模型基準測試。圍繞模型建構的生態系統——包括 LSP 整合、plugin 和 MCP 伺服器——對實際效能的影響更大。

1. 漸進式採用：從 `CLAUDE.md` 檔案開始，然後添加鉤子，再引入技能，最後擴充到 plugin 和 MCP 伺服器。每一層都建立在前一層之上。

1. 避免 RAG 陷阱：對於大型、活躍的程式庫，基於嵌入的檢索系統會因過時而失敗。Agent 式搜尋從即時程式庫工作，避免了這些問題。

1. 利用 LSP 整合：對於多語言程式庫，這是最高價值的投資之一。它使 Claude 能夠像開發者一樣精確導航程式碼。

1. 使用子 Agent 進行探索：將探索任務（如映射程式庫結構）委託給子 Agent，可以釋放主 Agent 的 context window 用於實際編輯工作。

1. 透過 plugin 分發最佳實踐：將成功的設定打包為 plugin，使整個組織都能受益，避免好的做法停留在小圈子內。

> 最終，Claude Code 在大型程式庫中的成功取決於團隊如何建構其工具鏈。那些投資於正確設定——從 `CLAUDE.md` 檔案到 LSP 整合——的團隊，將看到顯著更好的結果。模型本身很重要，但圍繞它建構的生態系統才是決定性的因素。

本文是使用 WisMe.ai 基於 Claude 官方部落格文章的中文改寫。

原文位址：https://claude.com/blog/how-claude-code-works-in-large-codebases-best-practices-and-where-to-start

## 標籤

Claude Code, CLI, 教學資源, Anthropic, Claude
