Claude Code 在大型程式碼庫中的最佳實踐

基於 Claude 官方部落格 · 閱讀原文

講解:AI隨風隨風 B站 抖音 小紅書 YouTube

一、核心認知:決定成敗的不是模型本身,而是"Harness"

成功的 Claude Code 大規模部署,決定性因素不僅在於模型本身,更在於圍繞模型構建的生態系統。

這個生態系統被作者稱為"鞍具"(Harness)——就像一匹好馬需要好的鞍具才能發揮潛能一樣,Claude Code 也需要精心搭建的鞍具才能在百萬行程式碼的倉庫中高效工作。

鞍具生態系統全景圖

鞍 具 (Harness) Claude Code 的生態系統 = 五層核心 + 兩大擴充套件能力 CLAUDE.md 上下文檔案 告訴規矩和結構 Hooks 鉤子 自動化的手腳 Skills 技能 專業工作流包 Plugins 外掛 打包分發 MCP 伺服器 連線內部系統 LSP 整合 符號級程式碼導航 Subagents 子代理 · 探索與編輯分離 建議構建順序:CLAUDE.md → Hooks → Skills → Plugins → MCP → LSP + Subagents 注:Skills 和 MCP 用虛線框表示 — 它們按需載入,不是始終在上下文中

鞍具元件速查表

元件 是什麼 何時載入 最適用場景 常見誤區
CLAUDE.md Claude 自動讀取的上下文檔案 每次會話 專案特定約定、程式碼庫知識 把應放在 Skill 中的可複用專業知識放進來
Hooks 在關鍵時刻執行的指令碼 由事件觸發 自動化一致行為、捕獲會話學習 用提示詞做應該自動執行的事情
Skills 針對特定任務型別的打包指令 按需載入,當相關時 跨會話和專案的可複用專業知識 把所有內容都載入到 CLAUDE.md 中
Plugins 打包的技能、鉤子和 MCP 配置 配置後始終可用 在組織內分發有效的設定 讓好的設定停留在部落知識中
LSP* 通過語言特定伺服器提供即時程式碼智慧 配置後始終可用 符號級導航和型別語言中的自動錯誤檢測 認為它是自動啟用的
MCP 伺服器 連線外部工具和資料的介面 配置後始終可用 讓 Claude 訪問無法直接觸及的內部工具 在基礎配置還沒搞好之前就構建 MCP 連線
Subagents* 針對特定任務的獨立 Claude 例項 被呼叫時 將探索與編輯分離、並行工作 在同一會話中執行探索和編輯

二、五層鞍具元件詳解

① CLAUDE.md — 最基礎、最重要的配置

CLAUDE.md 是每個會話開始時自動讀取的檔案,相當於給 Claude 的一張"小紙條"。最佳實踐是分層配置

CLAUDE.md 分層配置與自動載入示意 展示 CLAUDE.md 在專案中的分層結構以及 Claude 移動時自動載入沿途檔案的機制 CLAUDE.md 分層配置與自動載入 Claude 移動到子目錄時,自動疊加沿途所有 CLAUDE.md 的上下文 專案目錄結構 📁 專案根 / 📄 CLAUDE.md ← 全域性架構 + 陷阱 📁 src/ 📄 CLAUDE.md ← src 約定 📁 api/ 📄 CLAUDE.md ← API 規範 📁 payments/ 📄 CLAUDE.md ← 支付規則 📁 tests/ 📄 CLAUDE.md ← 測試命令 Claude 的上下文疊加過程 場景 A:在根目錄啟動 讀取:根目錄 CLAUDE.md(1 層上下文) 場景 B:移動到 src/ 目錄 讀取:根目錄 CLAUDE.md + src/CLAUDE.md ↑ 上下文自動疊加(2 層) 場景 C:移動到 src/api/ 目錄 讀取:根目錄 + src/ + api/ 三個 CLAUDE.md ↑ 上下文自動疊加(3 層) Claude 同時瞭解全域性架構 + 原始碼約定 + API 規範 場景 D:移動到 src/payments/ 目錄 讀取:根目錄 + src/ + payments/ 三個 CLAUDE.md ↑ 部署 Skill 可繫結到此路徑,僅在此時載入 關鍵設計原則 • 根目錄只放最重要的指標和陷阱,保持精煉 • 子目錄放本地約定,Claude 會自動向上查詢 • 在子目錄初始化任務,而非從根目錄開始
左側:分層目錄結構,每個子目錄維護自己的 CLAUDE.md;右側:Claude 移動時自動疊加上下文的過程。

② Hooks — 自動化的手腳

Hooks 是在關鍵事件(會話開始/結束、檔案寫入前/後)觸發自動執行的指令碼。

會話結束 Hook
自動記錄本次會話的教訓到經驗檔案中
檔案寫入前 Hook
自動執行 lint/format 檢查
檔案寫入後 Hook
自動更新相關文件或生成變更日誌
⚠️ 常見誤區
用 Hook 寫指令指導 Claude(那是 CLAUDE.md 的工作)

③ Skills — 可複用的專業知識包

核心設計理念:漸進式披露(Progressive Disclosure)— 只在需要時才載入特定 Skill,節省上下文空間。

安全審查
需要做安全審查時載入
文件更新
需要更新 API 文件時載入
部署流程
需要執行部署時載入
路徑繫結
繫結到 pay-ments/ 目錄,僅在此時載入

④ Plugins — 組織級分發的利器

把 Skills、Hooks 和 MCP 配置打包成一個可安裝的包,在團隊內部一鍵分發。

⑤ MCP Servers — 連線內部系統的橋樑

讓 Claude 能訪問內部分析平臺、CI/CD 系統、知識庫等外部資源。

⚠️ 常見誤區:基礎配置(CLAUDE.md)沒做好就上 MCP。應該 CLAUDE.md → Hooks → Skills → 再 MCP。

構建優先順序金字塔

鞍具構建優先順序金字塔 從底層基礎設施到頂層擴充套件,展示鞍具元件的構建優先順序和依賴關係 鞍具構建優先順序金字塔 從底層往上逐級構建,每一層都是上層的基礎 MCP Servers + Subagents 擴充套件外部連線 & 子代理 Plugins(外掛) 打包 Skills + Hooks + MCP → 一鍵分發 Skills(技能) 按需載入的專業工作流 · 漸進式披露 Hooks(鉤子) 事件觸發的自動化指令碼 · lint · format · 經驗記錄 CLAUDE.md(上下文檔案) 每條會話自動讀取 · 程式碼庫的"地圖"和"規矩" · 一切的基礎 程式碼庫可導航性(目錄結構清晰 · .ignore 排除噪音 · 輕量級程式碼地圖) 構建順序與理由 1. CLAUDE.md → 沒有上下文地圖,Claude 只能盲搜,一切無從談起 2. Hooks → 自動化檢查替代手動指令,降低出錯機率 3. Skills → 把專業知識做成可複用工具,而非每次手寫指令 4. Plugins → 驗證過的配置打包分發,賦能更多團隊成員 5. MCP + Subagents → 連線內部系統, 處理複雜探索任務 ⚠ 在底層做好之前,不要跳到頂層 ⚠ 頂層缺少底層支撐時效果極差

兩大額外能力

LSP 整合

讓 Claude 進行符號級別的程式碼導航,而不是基於文本匹配。

  • "轉到定義"
  • "查詢所有引用"
  • 區分不同語言中的同名函式
  • 在 C/C++ 大型程式碼庫中尤其關鍵
⚠️ 常見誤區:認為 LSP 是自動整合的。需要手動安裝對應的外掛和語言伺服器。

Subagents(子代理)

Subagent 是一個獨立的 Claude 例項,擁有自己的上下文視窗。

核心價值:將探索和編輯分離。

  1. 派一個只讀子代理"繪製"子系統地圖
  2. 主代理基於地圖做出精確修改
✅ 避免在同一個上下文中同時做探索和編輯,防止上下文汙染

三、核心工作原理:Agentic Search

Claude Code 像一名人類軟體工程師那樣工作——它遍歷檔案系統、讀取檔案、用 grep 搜尋、追蹤引用。它在本地機器上執行,不需要構建和維護程式碼索引。

Claude Code 的 5 步工作流

Claude Code 工程師式工作流 展示 Claude Code 如何像工程師一樣逐步理解和修改程式碼 Claude Code 如何像工程師一樣工作 從讀文件到改程式碼,一步步理解然後行動 1 讀文件 — 獲取上下文地圖 自動讀取 CLAUDE.md,瞭解專案架構、關鍵陷阱、程式碼約定 2 看結構 — 遍歷檔案系統 檢視目錄結構、檔案組織方式,找到相關程式碼所在位置 3 搜程式碼 — grep + LSP 雙模式 用 grep 搜關鍵詞、用 LSP 做符號級搜尋(定義/引用),精準定位 4 讀原始碼 — 深入理解實現 開啟相關檔案,理解資料流、函式呼叫關係、業務邏輯 5 做修改 — 基於理解編輯程式碼 基於前 4 步積累的理解,精確修改程式碼,而非盲目編輯 關鍵洞察 1. 如果 CLAUDE.md 沒寫好,第 1 步就缺失 → Claude 只能"盲搜",效率極低 2. 如果沒有 LSP,第 3 步只能用文本 grep → 返回大量噪音,浪費上下文

四、三種核心配置模式

模式一

讓程式碼庫易於導航

  • CLAUDE.md 精煉分層
  • 從子目錄初始化
  • 按子目錄限定測試命令
  • 使用 .ignore 排除無關檔案
  • 構建 Code Map
  • 執行 LSP
模式二

主動維護配置

為舊模型寫的規則可能成為新模型的制約。

建議每 3-6 個月或新模型釋出後做一次配置審查。
模式三

分配所有權

  • 基礎設-施投入先行
  • 專人負責(Agent Manager)
  • 跨職能工作組

Code Map — 程式碼庫地圖

Code Map 是一個輕量級 Markdown 檔案,在專案根目錄用一行描述一個業務模組(如認證、支付、訂單),讓 Claude 不用自己摸索「該去哪個模組找程式碼」。要寫的是業務邊界清晰的模組,而不是 components/handlers/ 這類技術子目錄。

Code Map 模組級對比示意 對比沒有 Code Map 時 Claude 摸索業務模組,與有 CODE_MAP.md 時直奔目標模組 沒有 Code Map → Claude 需要自己摸索模組邊界 $ 任務:修一個支付相關的 bug... $ 先摸清有哪些業務模組... auth/ (跟支付有關嗎? 開啟看看...) payments/ (應該是這兒? 進去看看...) billing/ (還是這兒? 也開啟...) orders/ (訂單和支付什麼關係? 看看) notifications/ (應該無關? 不確定...) infra/ (先跳過) 浪費大量 Token 在摸索業務邊界上 VS 有 Code Map → Claude 一目瞭然該去哪個模組 CODE_MAP.md # Code Map — 業務模組一覽 auth/ — 認證與授權(OAuth, JWT, 許可權) payments/ — 支付處理(閘道器、退款、對賬) billing/ — 賬單與訂閱(週期計費、發票) orders/ — 訂單生命週期(下單、取消、履約) notifications/ — 訊息通知(郵件、推送、Webhook) infra/ — 基礎設施(K8s, CI/CD, 監控) 需要細節時,再進入對應模組的 CLAUDE.md → Claude: "payments 和 billing 有什麼區別? 都開啟看看..." Claude: "支付 bug → 根據 CODE_MAP.md 去 payments/ 模組" 加一個 CODE_MAP.md,描述業務模組邊界 —— 立竿見影 一行程式碼不用寫;模組內的細節留給各模組自己的 CLAUDE.md

文章還強調一種分層做法:根目錄 CLAUDE.md 提供全域性上下文,CODE_MAP.md 列出模組路線圖,各子模組下的 CLAUDE.md 負責該模組內的約定與細節——先選模組,再讀細節。

CODE_MAP 與 CLAUDE.md 分層資料夾結構示意 展示根目錄 CLAUDE.md、CODE_MAP.md 與各子模組 CLAUDE.md 的分層目錄結構 分層做法:CODE_MAP.md → 子目錄 CLAUDE.md 頂層回答「去哪個模組?」· 下一層回答「在這個模組裡怎麼幹?」 專案目錄結構示例 📁 專案根 / 📄 CLAUDE.md ← 全域性架構 · 陷阱 · 程式碼約定 📄 CODE_MAP.md ← 模組地圖 · 一行一個業務模組 📁 auth/ 📄 CLAUDE.md 認證模組:OAuth · JWT · 許可權 📁 payments/ ← Claude 從 CODE_MAP 選中此模組 📄 CLAUDE.md 測試命令 · 關鍵檔案 · 業務規則 gateway.ts · refund.ts · … 📁 billing/ 📄 CLAUDE.md 賬單模組:訂閱 · 發票 · 週期計費 📁 orders/ → 📄 CLAUDE.md · … 頂層 根目錄檔案 CLAUDE.md 全域性上下文 CODE_MAP.md 去哪個模組? 會話開始先讀這兩份 子模組層 各模組目錄下 auth/CLAUDE.md payments/CLAUDE.md billing/CLAUDE.md … 每個模組各一份 進入模組後再載入 payments/ → 支付處理模組 讀取順序:根 CLAUDE.md → CODE_MAP.md 選模組 → 子目錄 CLAUDE.md 讀細節

配置演進生命週期

舊配置 新模型釋出 能力提升 配置審查 移除過時約束 迴圈週期:每 3-6 個月或新模型釋出後
舊規則如"每個重構拆分成單檔案更改" → 新模型完全可以協調多檔案編輯,過時規則應當移除。

五、實施路線圖

文章推薦的 8 步實施路線圖,按優先順序排序:

1 投資基礎設施 小團隊預搭建 CLAUDE.md + 基本 Hooks + Skills 2 從 CLAUDE.md 開始 根目錄 + 子目錄分層配置 3 逐步新增 Hooks 先自動化檢查 → 再自我改進 4 建立核心 Skills 圍繞團隊最常用的複雜任務建立 5 通過 Plugins 分發 打包已驗證配置,賦能新成員 6 擴充套件 MCP + Subagents 連線內部系統,使用子代理探索 7 定期審查(每 3-6 月) 移除過時配置 8 明確所有權 DRI / Agent Manager
關鍵提示:步驟 1 最關鍵(小團隊搭基礎設施),步驟 2 是所有配置的基礎。步驟 3-6 按順序推進,7-8 持續迭代。

六、常見誤區 vs 正確做法

常見誤區 vs 正確做法 對比 Claude Code 使用中的常見誤區和對應的正確做法 常見誤區 vs 正確做法 避免這些坑,讓 Claude Code 發揮最大效果 誤區 正確做法 把所有專業知識塞進 CLAUDE.md 導致上下文過載,每次會話都載入大量無關資訊 CLAUDE.md 保持精煉,專業知識做成 Skill 漸進式披露:按需載入,節省上下文空間 基礎沒做好就上 MCP MCP 連線不穩定,Claude 連基本上下文都沒有 先做好 CLAUDE.md → Hooks → Skills 基礎打好後,再擴充套件 MCP 連線內部系統 認為 LSP 是自動整合的 不裝外掛和語言伺服器,只用文本 grep,結果噪音巨大 手動安裝 LSP 外掛 + 語言伺服器 符號級搜尋精準定位,節省大量上下文 用 Hook 寫指令指導 Claude 做事 Hook 應該做自動化,不是當指令用 指令放 CLAUDE.md,自動化放 Hook Hook = 自動化指令碼(lint/format/記錄經驗) 好的配置停留在"部落知識"層面 每個人自己摸索,新成員上手困難 打包成 Plugin 組織級分發 驗證過的配置一鍵安裝,新成員零配置上手 在同一會話中同時探索和編輯 探索產生的噪音干擾編輯的精確性 用 Subagent 探索,主代理編輯 探索和編輯分離,避免上下文汙染 從倉庫根目錄啟動,讓 Claude 面對百萬行程式碼 在子目錄初始化,縮小任務範圍

三個最重要的決定

1 CLAUDE.md 分層設計
根目錄全域性 + 子目錄本地,按需取用
2 從子目錄而非根目錄啟動
縮小範圍,節省上下文
3 基礎設施先投
小團隊先搭建好體驗,再大規模推廣

七、案例速覽 + 企業落地檢查清單

大型零售組織

構建連線內部分析平臺的 Skill,打包成 Plugin 分發
啟示:標準配置應當共享

企業軟體公司

組織範圍內部署 C/C++ LSP 整合,作為推廣第一步
啟示:LSP 在大型程式碼庫中至關重要

Perforce 使用者

用 Hook 攔截檔案寫入執行 p4 edit(後因原生支援移除)
啟示:配置需隨平臺進化更新

支付服務團隊

將部署 Skill 繫結到 pay-ments/ 路徑
啟示:Monorepo 中用路徑繫結精準載入

企業落地檢查清單

核心金句:"成功的 Claude Code 大規模部署,決定性因素不僅在於模型本身,更在於圍繞模型構建的生態系統。"
本課件基於 Claude 官方部落格文章整理 · 閱讀原文:How Claude Code Works in Large Codebases