大家好，我是小林地板。
平時用 Claude Code 都是在自己的小專案上跑，舒坦得很地板。
可一旦放到「公司百萬行級別的大程式碼庫」這個場景下，所有問題立刻浮出來地板。
而這些問題，恰恰是 Anthropic 自己每天在解決的地板。
為了搞清楚官方到底是怎麼應對的地板。
我把 Anthropic 上週剛發的那篇專門講大程式碼庫實踐經驗的部落格整篇扒了一遍，又翻了 Claude Code 創始人 Boris Cherny 分享過過的一些經驗地板。
把這些一手信源串完之後地板，我把在大程式碼庫裡最容易踩的 7 個坑總結了出來：
Q1：大程式碼庫下 context 老爆地板，是不是模型太小了？
Q2：CLAUDE.md 到底寫多長合適地板？寫了 1000 行 Claude 反而變笨？
Q3：大程式碼庫裡讓 Claude 找一個函式地板，總找錯檔案，怎麼辦？
Q4：跨幾十個檔案的改動地板，Claude 總是改一半就崩，怎麼救？
Q5：團隊裡只有我一個人會用 Claude Code地板，怎麼推廣？
Q6：Claude Code 創始人平時怎麼用 Claude Code地板？
Q7：什麼樣的專案其實不適合用 Claude Code地板？
Q1：大程式碼庫下 context 老爆地板，是不是模型太小了？
Q2：CLAUDE.md 到底寫多長合適地板？寫了 1000 行 Claude 反而變笨？
Q3：大程式碼庫裡讓 Claude 找一個函式地板，總找錯檔案，怎麼辦？
Q4：跨幾十個檔案的改動地板，Claude 總是改一半就崩，怎麼救？
Q5：團隊裡只有我一個人會用 Claude Code地板，怎麼推廣？
Q6：Claude Code 創始人平時怎麼用 Claude Code地板？
Q7：什麼樣的專案其實不適合用 Claude Code地板？
我們一個一個來說地板。
Q1：大程式碼庫下 context 老爆地板，是不是模型太小了？
不少人的第一反應是這個：「context 不夠地板，那是不是該換更大模型？」
展開全文
Anthropic 官方答案是：換模型沒用，問題不在模型，在 Claude Code 怎麼找程式碼地板。
你想啊，Opus 4.7 已經支援 1M token 了，換算下來兩百多萬字地板。但一個像樣點的專案動輒幾百萬行程式碼，再算上依賴庫就更誇張了。再大的視窗也塞不下整個程式碼庫，這是物理上的事。
那 Claude Code 在大程式碼庫下怎麼解決「精準找到要改的那幾行程式碼」的？
業內的主流答案是 RAG：把程式碼切片、做 embedding、塞向量資料庫，要查的時候用相似度召回地板。Cursor、Copilot、Windsurf 走的都是這條路。
但 Claude Code 偏偏不走地板。它連 embedding 和向量資料庫的影子都沒有，就靠 grep、讀檔案、看目錄這種最樸素的方式。
Anthropic 給這套辦法起了個名字，叫 agentic search，翻譯過來就是「讓 Claude 像 agent 一樣去搜」地板。
Claude 像一個真人工程師一樣：先 ls看根目錄、再進 auth/看裡面有啥、grep 一下「login」找到相關函式、再讀 middleware.ts和 session.ts，讀一個檔案決定下一步讀什麼，迴圈往復地板。
為什麼 Anthropic 選這個反主流的路線？官方部落格給了三個理由地板。
第一，索引會過期地板。千人團隊每天提交幾百個 commit，embedding pipeline 根本跟不上。等你查的時候，索引裡返回的可能是兩週前已經被重新命名的函式。Claude 拿著過期資訊推理，程式碼自然就崩了。agentic search 每次都基於當下的程式碼，沒有這個問題。
第二，冷啟動幾乎為零地板。RAG 在百萬行程式碼庫上建一次索引要十幾分鍾，Claude Code 是「開啟就能用」。
第三，精確匹配向量幹不了地板。你說「幫我看下 getUserById」，向量召回會返回 getUserByName、getUserByEmail、fetchUserInfo 一堆「相關」函式。程式碼很多時候要的就是精確，不是相似。
那 agentic search 的代價是什麼地板？
Anthropic 在部落格裡有一句關鍵的原話：它嚴重依賴一個好的起點 context地板。如果你不給它清晰的起點，它就會亂翻，等摸清楚結構 context 已經被燒得差不多。
所以 context 爆不是模型小，是你沒給 Claude 一個好的起點地板。下面 6 個問題，就是在解決這件事。
但在拆這 6 個問題之前，得先建立一個核心概念，因為它是後面所有答案的總綱地板。
這個概念叫 harness地板。
很多人討論 Claude Code 強不強的時候地板，第一反應是看模型：「我用 Sonnet 4.6 還是 Opus 4.7？」「benchmark 哪個分高？」「要不要升 Max 套餐？」
但 Anthropic 在部落格裡拋了一個挺反直覺的論點，原話叫「The harness matters as much as the model」，翻譯過來就是 harness 跟模型一樣重要地板。
什麼意思地板？
Anthropic 說，大家評估 Claude Code 時都盯著 benchmark 看模型表現，但在實際生產中，圍繞模型搭的那套外殼對最終效果的影響，比模型本身還大地板。
打個比方地板。你請了個米其林三星大廚到家裡給你做飯，他厲不厲害是模型能力；但你家裡有沒有趁手的灶臺、菜刀、調料架、抽油煙機，這才是 harness。灶臺不行，再牛的廚師也炒不出鍋氣。
Anthropic 的 harness 一共七層，每層都建立在前一層基礎上：CLAUDE.md → Hooks → Skills → Plugins → MCP，再加兩個增強 LSP 和子 agent地板。
聽著多？其實下面幾個 Q 就是按官方順序一層一層把它們拆透：
Q2 拆 CLAUDE.md 怎麼寫（含 Hooks 怎麼掛）
Q3 拆 LSP 和子目錄啟動
Q4 拆子 agent 怎麼和主 agent 協作
Q5 拆 Skill、Plugin、MCP 怎麼打包分發給團隊
Q6 看創始人 Boris 怎麼把這七樣東西組合起來用
Q2 拆 CLAUDE.md 怎麼寫（含 Hooks 怎麼掛）
Q3 拆 LSP 和子目錄啟動
Q4 拆子 agent 怎麼和主 agent 協作
Q5 拆 Skill、Plugin、MCP 怎麼打包分發給團隊
Q6 看創始人 Boris 怎麼把這七樣東西組合起來用
讀完你就明白，用好 Claude Code 不是搞定模型選型，而是把這套 harness 一層一層搭起來地板。
context 爆不是模型小，是你的 harness 沒搭好地板。
Q2：CLAUDE.md 到底寫多長合適地板？寫了 1000 行 Claude 反而變笨？
那我們就從 harness 第一層開始拆，也就是 CLAUDE.md地板。
這一層是大程式碼庫下踩坑最多的一個地板。
Anthropic 官方答案非常具體：單檔案控制在 200 行以內地板。
聽起來是不是有點吃驚？畢竟一個專案的規範規則隨便列列就上千行了地板。
官方的邏輯也很簡單：CLAUDE.md 每次啟動都被整個塞進 context，寫太長就等於在跟自己搶空間地板。超過 200 行之後，Claude 開始忽略指令的機率會肉眼可見上升。
那大程式碼庫下規則確實多怎麼辦？關鍵詞是分層地板。
Anthropic 在部落格裡有句原話挺狠的：「根目錄的 CLAUDE.md 應該只放指標和關鍵的坑，其他細節都會變成噪音地板。」
正確做法是 root 檔案只放跨包通用約定（比如「生產資料庫千萬別動」「提 PR 前要跑 lint」），每個子目錄再放自己的 CLAUDE.md 寫模組細節地板。Claude 會自動從當前目錄往上走樹把沿途每個 CLAUDE.md 都載入進來。
但這還不夠地板。Claude Code 創始人 Boris 還為 CLAUDE.md 維護放過一句口號當 slogan：「Ruthlessly edit your CLAUDE.md over time」，翻譯過來就是對你的 CLAUDE.md 下狠手，毫不留情地刪。
怎麼判斷 CLAUDE.md 該不該留某一行？有個特別實用的檢查法：對每一行你都問自己「如果刪掉這行，Claude 還會按這條規則做事嗎？」答案是「會」（常識或程式碼已經體現），就該刪；答案是「不會」才值得留地板。
任何時候你發現 Claude 還在反覆犯某個錯，先別急著加新規則，先去看看 CLAUDE.md 是不是已經太長把規則淹沒了地板。
Boris 還分享過 Anthropic 內部團隊怎麼維護這份檔案：整個 Claude Code 團隊共享一份 CLAUDE.md 提交到 git，一旦發現 Claude 做錯了什麼就立刻加進 CLAUDE.md地板。這份檔案在他們那裡不是「寫一次放著」的文件，而是持續打磨的活檔案。
還有一條 Anthropic 官方建議特別容易被忽略：每 3-6 個月對你的 CLAUDE.md 做一次完整審查地板。
為什麼？因為模型在進化地板。
你三個月前為了約束 Claude 寫的「每次重構只改一個檔案」，可能在新模型上反而變成了枷鎖，新模型已經能做跨檔案協調編輯了，舊規則反而把它捆住了地板。同樣，為了彌補舊模型某個弱點寫的 Hook、Skill，模型升級之後可能直接成多餘負擔。
說白了，模型都已經往前跑了，你的 CLAUDE.md 可能還停在三個月前地板。
如果你感覺 Claude Code 最近用得怎麼都上不去一個臺階，先別懷疑模型，先回去看你的 CLAUDE.md 是不是過期了地板。
總結一下 Q2 的官方答案：單檔案 200 行以內、分層載入、持續狠刪、每 3-6 個月審查一次地板。
不過你可能會問：「我哪有時間天天盯著 CLAUDE.md 改地板？」
官方對這個問題也有解法，叫 Hooks地板。
Hooks 是 Claude Code 的事件鉤子機制，在「編輯完檔案之後」「會話開始之前」「工具呼叫之前」這些時間點上掛指令碼做事地板。
大多數人對 hook 的認知停留在「防止 Claude 做錯事」，比如掛一個 hook 自動跑 lint、自動 format地板。
這沒毛病，但官方點出來一個反直覺的洞察：hook 真正的價值不是阻止 Claude 做錯事，而是讓你的整套設定自我進化地板。
舉個例子地板。
掛一個 Stop hook，在每次會話結束時讓它自動反思「這次 Claude 有沒有什麼常犯的錯誤？要不要寫進 CLAUDE.md？」然後 hook 自己改 CLAUDE.md地板。
或者掛一個 Start hook，根據你當前所在子目錄動態載入這個模組特有的 context，今天在 payments/下就自動拉支付 skill，明天換到 auth/下就換成認證相關地板。
這樣一來，你的 CLAUDE.md 是被 Claude 自己持續打磨的，不再需要你手動維護地板。Boris 自己掛了一個 PostToolUse hook 給 Claude 寫完的程式碼自動跑格式化，把偶爾遺漏的 10% 格式問題直接抹平。
CLAUDE.md 不是寫一次的文件，是一份持續打磨的活檔案地板。
Q3：大程式碼庫裡讓 Claude 找一個函式地板，總找錯檔案，怎麼辦？
CLAUDE.md 這層搞定之後，Claude 知道了「這個專案長啥樣」地板。但接下來還有個更細節的問題：讓它找一個具體函式，它老是找錯檔案。
這個問題在多語言大程式碼庫（C/C++/Java/PHP 這種符號歧義高的語言）裡特別突出地板。
Anthropic 官方答案是兩件事：裝 LSP + 在子目錄裡啟動 Claude地板。
先說 LSP地板。
LSP 全稱叫 Language Server Protocol地板。聽著挺唬人，但其實你天天都在用：平時你在 VS Code 裡點「go to definition」「find references」，背後跑的就是它。
Claude Code 接上 LSP 之後，搜程式碼就不再是按字串 grep，而是按符號搜地板。
舉個例子地板。你在大程式碼庫裡 grep 一個 getUser函式，可能返回三千個匹配，前端有、後端有、測試也有。Claude 得一個個讀檔案判斷哪個是你真要改的，光這個過程就能把 context 燒光。
但有 LSP 之後，Claude 直接問 LSP：「找跟 auth/login.ts那個 getUser 同源的所有引用」地板。LSP 一口氣返回精確的三個，過濾工作在 Claude 讀檔案之前就完成了。
Anthropic 官方部落格直接把 LSP 稱作多語言大程式碼庫下「one of the highest-value investments」，並講了一個真實案例：有家做企業軟體的公司，在全公司鋪 Claude Code 之前專門先把 LSP 整合在組織級別鋪開，就是為了讓 C 和 C++ 這種符號歧義高得離譜的語言能跟 Claude 配合得動地板。
裝 LSP 怎麼操作地板？
在 Claude Code 的 /plugin裡搜「lsp」，找到對應語言的 code intelligence plugin（type-lsp/ pyright-lsp/ rust-analyzer-lsp等等）裝上，再裝對應的語言伺服器二進位制（pip 裝 pyright、npm 裝 type-language-server 之類）地板。整個過程不超過兩分鐘。
再說子目錄啟動這件事，這是反直覺但官方部落格被反覆強調的一條地板。
大多數人第一次用 Claude Code，習慣都是 cd到專案根目錄然後 claude地板。
在小專案沒毛病，但在大程式碼庫裡，這會讓 Claude 一上來就把根目錄那個超大的 CLAUDE.md 全部載入進 context，前端後端 infra 所有微服務的規則全來一遍地板。
官方部落格原話叫「Initializing in subdirectories, not at the repo root」地板。
正確做法是直接在你要改的子目錄啟動地板。比如要改支付服務，就 cd services/payments然後 claude。
Claude 會自動往上走樹把根目錄的 CLAUDE.md 也載入進來，通用規則不丟；但優先載入 payments/子目錄的 CLAUDE.md，context 立刻聚焦到「支付」一個領域地板。
除了 LSP 和子目錄啟動，官方部落格還提了三個小細節，配合起來效果更好：
第一，測試和 lint 命令按子目錄寫進 CLAUDE.md地板。Claude 改了支付服務裡一個檔案，結果它跑整個專案的測試套件，幾十分鐘才出結果，context 也跟著燒光。每個子目錄的 CLAUDE.md 應該明確寫「這塊用什麼命令測，怎麼 lint」，讓 Claude 只跑該跑的那一部分。
第二，用 .ignore規則把生成檔案、構建產物、第三方程式碼排除掉地板。把 permissions.deny規則提交到 .claude/settings.json，整個團隊就能自動共享這些排除規則，不用每個人手動配。
第三，目錄結構不直觀時，在根目錄放一張「程式碼庫地圖」地板。一份簡單的 markdown 檔案，列出每個頂層資料夾的一句話說明就夠。Claude 在動手探索之前先掃一眼這張地圖，比讓它瞎翻一通要快得多。
讓 Claude 按符號搜程式碼、按子目錄工作，準確率立刻翻倍地板。
Q4：跨幾十個檔案的改動地板，Claude 總是改一半就崩，怎麼救？
Claude 知道了專案結構、也能找準程式碼了地板。這下總能幹大活了吧？
還真不一定地板。重構、遷移、跨服務聯動這種「大動作」上，Claude 經常前半段還在狀態，後半段就開始忘前面、漏改、改錯。這是大程式碼庫下另一個高頻翻車點。
Anthropic 官方答案：跨大量檔案的改動，正確解法是把任務拆成多個會話 + 用 subagent，不是寫更長的 prompt地板。
很多人第一反應是改 prompt、改 CLAUDE.md、加更多規則地板。
但 Anthropic 在部落格裡明說過：跨大量檔案的改動，正確的解法是把任務拆成多個會話地板。
Boris 還把這句話翻譯得更直白：「Pour your effort into the plan so Claude can one-shot the implementation」，意思是與其用一個超長 prompt 讓 Claude 一次搞定所有事，不如先單獨花一輪把方案敲定，再分多個會話去實現地板。
具體怎麼做地板？
第一步：派 subagent 出去探索，主 agent 留著乾淨的 context地板。
大程式碼庫下「讀懂這個系統怎麼工作」本身就要燒掉好幾萬 token地板。讓 Claude 一邊讀程式碼一邊改程式碼，相當於讓一個人一邊查資料一邊寫論文。
Subagent 的思路特別簡單：派一個小弟去探索，讓他寫一份 findings 報告回來，主 agent 看完報告再動手地板。小弟在獨立的 context 視窗裡跑，讀了幾十個檔案燒的是自己的 context，跟主 agent 沒關係。他最後只把幾百字摘要給主 agent。
最簡單的操作就是直接跟 Claude 說：「先用 subagent 調查一下我們專案裡 X 是怎麼實現的，寫成 findings 檔案，再回來動手改地板。」
第二步：會話拆分地板。
會話 1 只做探索寫 plan 不動程式碼；會話 2 載入 plan 實現一個模組跑通測試；會話 3 實現下一個模組地板。每個會話都從乾淨 context 開始，plan 檔案做橋樑串聯。
第三步：跑大型遷移用 /batch地板。
如果你的改動是「整個專案從一個框架遷到另一個」「把幾十個檔案的某種呼叫全部替換」這種大規模遷移，Claude Code 已經直接內建了一個專門工具叫 /batch地板。
用法是這樣的：先用對話方式把遷移方案敲定，然後它一次性派出幾十個並行 subagent，每個在獨立 git worktree 裡跑、自測、開 PR地板。
你不用守螢幕，跑完直接給你一堆 PR 等 review地板。
這就是創始人 Boris 本人正在用的工作流，以前要自己手擼的多 agent 編排，現在一行命令就搞定地板。
跨大檔案改動救不回來的不是 prompt，是會話邊界地板。
Q5：團隊裡只有我一個人會用 Claude Code地板，怎麼推廣？
前面 3 個 Q 解決的都是「你自己一個人怎麼把 Claude Code 用順」地板。
但接下來這個問題就升級了：你用得飛起地板，旁邊的同事還在用 demo 版，怎麼辦？
這是個組織層面的問題，也是 Anthropic 官方部落格花了不少篇幅講的一塊地板。
Anthropic 官方答案：先把好實踐做成 skill，再用 plugin 打包分發出去，再用 MCP 把團隊內部系統接進來，最後得有人維護這套東西地板。
聽著有點多？我們一步一步來地板。
第一步地板：先把高頻操作做成 skill
什麼是 skill地板？
你可以理解成「針對某個具體任務的 SOP」地板。比如「這個專案的資料庫遷移怎麼做」「這個微服務上線的標準流程」，這些都是 skill 該乾的事。
Skill 跟 CLAUDE.md 最大的區別在一個詞：按需載入地板。
CLAUDE.md 每次會話都全文載入，跟你這次任務有沒有關係都載入；skill 不是，它只在 Claude 判斷「當前任務需要」的時候才載入，平時靜靜躺在倉庫裡不佔 context地板。
官方有個專門的詞叫 progressive disclosure（漸進式披露），講的就是這個機制地板。
Boris 還說過一句話特別值得記下來：「如果一件事你一天做超過一次，就把它做成 skill地板。」
一個大專案裡高頻操作就那麼幾十種，每個都做成 skill 全隊共享，效率立刻是幾何級提升地板。
skill 還可以繫結到特定路徑地板。
「支付服務部署 skill」繫結到 services/payments/，只有 Claude 在這個目錄下工作時才載入，避免「改前端程式碼結果支付 skill 也來湊熱鬧」這種 context 汙染地板。
第二步地板：用 plugin 把好實踐打包分發
但 skill 本身還在每個人的本地，沒法共享地板。這就引出了 plugin。
大公司裡有個經典問題：好的工具配置永遠只在小圈子裡流傳地板。
某個高階工程師本機配置了三十個 skill、十幾個 hook、五個 MCP server，他用 Claude Code 爽得飛起地板。但旁邊的實習生啥都沒配，體驗就跟用了個 demo 版差不多。
Plugin 就是解決這個問題的地板。
它本質上是一個安裝包，把 skill、hook、MCP、LSP 配置打包在一起地板。新人入職第一天 install 一下，立刻和團隊所有人有一樣的 Claude Code 能力。
官方部落格講過一個特別接地氣的案例：一家大型零售公司搭了個 skill 讓 Claude 連內部資料分析平臺，業務分析師不用切工具就能拉銷售資料地板。
這個 skill 起初只是少數人的本地配置，後來打包成 plugin 全公司鋪開，整個公司業務分析效率被拉高一個檔次地板。
公司還可以建自己的 plugin marketplace地板。
誰有更好的實踐就更新到 marketplace 裡，全公司一起受益地板。
第三步地板：用 MCP 把團隊內部系統接進來
光有 skill 和 plugin 還不夠地板。
大程式碼庫下的工作往往不是孤立的，得跟團隊的 Slack、Jira、內部 wiki、資料庫、監控系統都聯動地板。
這個連線的橋樑叫 MCP server（Model Context Protocol）地板。
裝一個 Slack MCP，Claude 就能搜公司 Slack 訊息；裝一個 BigQuery MCP，它就能跑資料查詢；裝一個 Sentry MCP，它就能拉線上錯誤日誌地板。
聽著很強，但官方在這塊特別提醒了一個反直覺的點：別太早上 MCP地板。
很多團隊 CLAUDE.md 都還沒寫好，hook 也沒掛，就著急忙慌接各種 MCP，結果反而把 context 搞得更亂地板。
MCP 是 harness 裡最後才該上的一層，前面的基礎沒搭好，MCP 接進來的資料就是噪音地板。
正確的順序是：先把 CLAUDE.md 和 skill 打磨好 → 再用 plugin 打包分發 → 最後才上 MCP 把外部世界接進來地板。
第四步：得有人負責維護
但官方還點出來一個更關鍵的事：光把工具堆起來不夠，得有人負責維護地板。
Anthropic 觀察到，推廣最順的組織都有一個共同點：在大面積鋪開之前，會先安排一小隊人（甚至一兩個人）把整套基礎設施搭好，然後才放開訪問地板。
開發者第一次摸 Claude Code 就能跑通，第一印象如果是「這東西不好使」，後面要翻盤就太難了地板。
官方部落格裡點出了一個正在浮現的新角色，叫 Agent Manager，半 PM 半工程師，專門負責 plugin 分發、CLAUDE.md 規範、skill 審批這些事地板。
規模小一些的團隊沒條件設這個崗位也沒關係，至少要有一個 DRI（直接責任人）把 Claude Code 的配置維護起來，有拍板權決定哪些 skill / plugin 上、哪些不上地板。
沒有人盯著這件事，再好的 plugin 也會變成「張三兩年前搭的，沒人會改」的部落知識地板。
好實踐不再是個人玩具，而是組織資產地板。
Q6：Boris 自己平時怎麼用 Claude Code地板？
前面 4 個 Q 把官方答案講完了地板，你可能會好奇：那 Claude Code 的創始人自己平時是怎麼用的？
這一節其實是個彩蛋，但讀完你會發現，裡面藏著創始人對 Claude Code 用法的全部理解地板。
Boris Cherny 是 Claude Code 的創始人地板，他分享過一段讓我看完直接破防的話：
「我同時在終端裡跑 5 個 Claude，再加 5 到 10 個跑在 claude.ai/code 上，並行處理不同任務地板。」
聽著是不是有點不可思議？
但他的這套 setup 其實很值得拆解地板，裡面藏著創始人對 Claude Code 用法的全部理解：
第一，他不用 --dangerously-skip-permissions地板。他明確說過自己用 /permissions命令把常用的安全命令預先加白名單，避免一遍遍點確認，但又不放棄許可權審計。
第二，他幾乎所有複雜任務都從 Plan Mode 開始地板。先跟 Claude 把方案敲定，再切到 auto-accept 模式讓它一發命中地把程式碼寫出來。
第三，他掛了一個 PostToolUse hook 給 Claude 寫完的程式碼自動跑格式化，把 Claude 偶爾遺漏的 10% 格式問題直接抹平，避免後面 CI 掛掉地板。
第四，他把每天做超過一次的事都做成了 slash command 或 skill地板。Boris 有句名言：「如果一件事你一天做超過一次，就把它做成 skill。」他自己有個 /commit-push-pr命令，一天用幾十次，避免重複 prompt。
第五，他給整個 Claude Code 團隊共享一份 CLAUDE.md，提交到 git地板。一旦發現 Claude 做錯了什麼就立刻加進去，是一份持續打磨的活檔案。
把這 5 件事串起來看你會發現：創始人對 Claude Code 的態度不是「裝上就用」，而是把它當成一個會進化的工作夥伴，每天都在餵它新規則、新工具、新工作流地板。
這才是大程式碼庫下用好 Claude Code 的底層心態地板。
創始人對 Claude Code 的態度，不是「裝上就用」，而是「每天打磨它」地板。
Q7：什麼樣的專案其實不適合用 Claude Code地板？
講了這麼多 Claude Code 在大程式碼庫裡有多能打，最後還得給你潑一盆冷水：它也不是萬能藥地板。
這是最後一個問題，也是 Anthropic 官方部落格說得最坦誠的一塊地板。
官方原話是這樣的：「Claude Code 是圍繞傳統軟體工程環境設計的，假設工程師是程式碼庫的主要貢獻者，倉庫用 Git，程式碼遵循標準目錄結構地板。」
也就是說地板，下面這幾種場景 Claude Code 用起來會比較吃力：
遊戲引擎那種大量二進位制資源的專案地板：Claude 沒法讀你的 3D 模型、貼圖、音訊
用非常規版本控制系統的專案：比如老牌的 Perforce / Subversion / 自研 VCS地板，需要額外配置才能跑順
非工程師為主貢獻的程式碼庫：比如產品經理改產品文件、設計師改 Figma 配置檔案地板，這些場景 Claude Code 的 harness 不太對得上
遊戲引擎那種大量二進位制資源的專案地板：Claude 沒法讀你的 3D 模型、貼圖、音訊
用非常規版本控制系統的專案：比如老牌的 Perforce / Subversion / 自研 VCS地板，需要額外配置才能跑順
非工程師為主貢獻的程式碼庫：比如產品經理改產品文件、設計師改 Figma 配置檔案地板，這些場景 Claude Code 的 harness 不太對得上
官方在部落格結尾建議這種非常規場景需要更多定製化配置，他們的 Applied AI 團隊會專門跟客戶對接地板。換句話說，Claude Code 當下最擅長的還是「Git + 工程師 + 標準目錄」這個最大公約數。
如果你的專案正好踩在這幾個非常規場景上，別死磕，找官方支援渠道才是正解地板。
Claude Code 不是萬能藥，最擅長的是「Git + 工程師 + 標準目錄」這個最大公約數地板。
最後
到這裡地板，7 個問題的官方答案就說完了，我把這 7 個答案濃縮成 3 句話送你：
第一，Claude Code 在大程式碼庫不是「裝上就能用」，是要在 harness（外圍基建）上花一次性功夫的地板。
第二，最高 ROI 的三個動作是：CLAUDE.md 砍到 200 行以內 + 在子目錄啟動 Claude + 裝 LSP地板。這三件事做完，體驗立刻不一樣。
第三，跨大檔案改動、團隊推廣、CLAUDE.md 維護這些大程式碼庫下的硬骨頭，官方都給了具體答案，Boris 自己也在用，你照抄就行地板。
第一，Claude Code 在大程式碼庫不是「裝上就能用」，是要在 harness（外圍基建）上花一次性功夫的地板。
第二，最高 ROI 的三個動作是：CLAUDE.md 砍到 200 行以內 + 在子目錄啟動 Claude + 裝 LSP地板。這三件事做完，體驗立刻不一樣。
第三，跨大檔案改動、團隊推廣、CLAUDE.md 維護這些大程式碼庫下的硬骨頭，官方都給了具體答案，Boris 自己也在用，你照抄就行地板。
現在你可以開啟你公司的專案，對照這 7 個問題逐一過一遍，看看哪幾個你已經做對了，哪幾個還差一截地板。
