Claude Context：大型 codebase 的 AI Coding 關鍵不是塞更多 context，而是先建立可檢索的語意記憶層

這篇 Threads 講的是大型 codebase 裡 AI coding tool 最常見的失效點：不是模型不夠強，而是它沒有真正的全局視野。

小專案裡，AI 只看幾個檔案還能猜得差不多；但專案一大，問題就變成「相關資訊散在整個 repo」。你問鑑權邏輯、退款流程、某個 callback 怎麼串，AI 如果只能沿著目錄盲翻，很容易給出一個語氣很肯定、但和真實實作對不上的答案。

Claude Context 的價值就在這裡。它不是把整個 codebase 硬塞進 context，而是先把 repo 建成可檢索的語意記憶層。當 AI 需要理解某個問題時，再用 semantic search 把相關 code fragment、關聯模組、上下游路徑撈出來，交給模型做推理。

根據 zilliztech/claude-context 的 README，它是一個 MCP plugin，目標是為 Claude Code 與其他 AI coding agents 加上 semantic code search，讓 agent 能從整個 codebase 中找出相關程式碼。它使用 vector database 儲存 codebase embedding，而不是每次都把整包目錄載入模型。

核心能力

把整個 codebase 變成 Claude / coding agent 可檢索的 context
用 semantic search 從數百萬行程式碼中找到相關片段
透過 MCP 接到 Claude Code
也支援 Codex CLI、Gemini CLI、Qwen Code、Cursor 等 MCP client
需要 Node.js 20+，且目前不相容 Node.js 24
使用 OpenAI API key 做 embedding
使用 Zilliz Cloud / Milvus 作為向量資料庫

為什麼這比「塞更多 context」更合理

大型 repo 的問題不是 AI 完全看不懂 code，而是它不知道該先看哪裡。把整個 repo 塞進 context 有三個問題：

成本高無關檔案也會吃 token。
雜訊高模型讀到太多不相關內容，反而更容易失焦。
不可持續每次提問都重新探索 codebase，長期效率很差。

Claude Context 這類工具代表另一條路線：先建索引，再按問題取局部上下文。這和 RAG 的精神很像，但場景更聚焦在 codebase understanding。

對 AI coding 的實際意義

如果一個 agent 要回答「退款流程怎麼走」，它需要的不是全 repo，而是：

payment / refund domain 的 service
controller / route
callback handler
transaction model
authorization middleware
test cases
相關 config 或 feature flag

好的 codebase memory layer 應該能把這些相關片段找出來，而不是讓 AI 在 src/ 裡盲逛。

Threads 提到官方評估在檢索效果接近的前提下，token 用量可降約 40%。這個數字不同專案會變，但方向合理：如果檢索層能更準，就能少餵無關檔案。

我的判斷

Claude Context 的重點不是「Claude 專用工具」，而是 AI coding 工具正在補一個很核心的中介層：codebase memory layer。

未來成熟的 AI coding workflow 很可能會分成三層：

repo indexing / memory layer 負責持續理解 codebase、建索引、找相關上下文。
agent reasoning layer 負責規劃、修改、測試、解釋。
governance / review layer 負責權限、安全、驗收、避免 agent 做錯。

沒有第一層，AI 很容易在大專案中迷路；只有第一層也不夠，因為 semantic search 找到片段後，還需要 agent 正確推理與驗證。

對 BigIntTech 來說，這類工具值得留意。工多多、Silver Spoon、齊家這種長期 codebase，未來若要讓 agent 穩定回答跨模組問題，單靠 grep 或臨時讀檔不夠，應該逐步導入「repo 索引 + semantic / graph retrieval + agent」的架構。

來源：