AI Agent 寫程式時最常見的問題,不是模型完全不會寫,而是它不知道這個程式碼庫真正長什麼樣。
它可能不知道入口檔案在哪裡,不知道某個 helper 已經存在,不知道測試命令怎麼跑,也不知道團隊約定哪些目錄不能碰。於是每次開新會話都要重新解釋專案背景,或者讓 Agent 反覆 grep、反覆讀檔案、反覆把無關內容塞進上下文。
這就是「程式碼庫記憶工具」要解決的問題。
不過這類工具不是同一種東西。CLAUDE.md、AGENTS.md 是規則檔案;Cursor 做的是 IDE 內索引;Serena 更像給 Agent 加一組語義程式碼工具;codebase-memory-mcp 走的是持久知識圖譜;RepoPrompt 偏人工上下文打包;Sourcegraph 則更適合企業級多倉庫程式碼理解。
先給結論
| 工具/路線 | 最適合 | 主要價值 | 不適合 |
|---|---|---|---|
CLAUDE.md / AGENTS.md |
幾乎所有專案 | 保存專案規則、命令、禁區、協作約束 | 自動理解複雜呼叫關係 |
| Cursor codebase indexing | Cursor 使用者、IDE 內開發 | 讓聊天和編輯能引用目前專案索引 | 跨工具共享、複雜 Agent 編排 |
| Serena MCP | 大型程式碼庫、語義導航、重構 | symbol 級檢索、引用查找、語義編輯 | 只想寫簡單提示詞的小專案 |
codebase-memory-mcp |
多工具共享程式碼索引 | 透過 MCP 暴露持久程式碼知識圖譜 | 不想維護額外服務的使用者 |
| RepoPrompt / RepoPrompt CE | 需要人工精確控制上下文 | 選擇檔案、CodeMap、diff,組裝可審查上下文 | 想完全自動索引的團隊 |
| Sourcegraph / Cody | 企業多倉庫、大規模程式碼理解 | 集中索引、搜尋、權限、跨倉庫上下文 | 個人小專案、輕量本地工作流 |
我的建議:
- 小專案:先寫
AGENTS.md或CLAUDE.md。 - 中型專案:規則檔案 + IDE 索引。
- 大型單倉庫:規則檔案 + Serena 或
codebase-memory-mcp。 - 多倉庫團隊:規則檔案 + MCP 索引工具 + Sourcegraph 這類平台。
- 高風險改動:再加 RepoPrompt 這類人工上下文打包工具,先讓人審上下文,再讓 Agent 動手。
不要一開始就堆滿工具。程式碼庫記憶的目標不是「讓 Agent 知道一切」,而是讓它在目前任務裡少猜、少讀錯、少浪費上下文。
先區分三種「記憶」
1. 規則記憶
代表:CLAUDE.md、AGENTS.md、GEMINI.md、README 裡的 AI section。
它們記錄技術棧、常用命令、測試方式、目錄說明、禁止修改的檔案、程式風格、提交和驗證規則。這種記憶最便宜也最穩定,缺點是不會自動理解程式碼關係。
2. 檢索記憶
代表:Cursor codebase indexing、Sourcegraph、程式碼搜尋、向量索引、知識圖譜。
它們回答:函式在哪裡定義、誰呼叫了介面、哪些檔案可能相關、某個設定在哪裡出現、跨倉庫依賴在哪裡。適合中大型程式碼庫,但需要索引、刷新、權限和忽略規則。
3. 操作記憶
代表:Serena MCP、帶語義編輯能力的 Agent 工具、程式碼智能 MCP server。
它們不只是找到程式碼,還提供更接近 IDE 的工具,例如查 symbol、查引用、看 outline、替換函式體、重命名 symbol、做更小粒度的編輯。適合複雜重構和大倉庫導航,但安裝和配置更複雜。
CLAUDE.md / AGENTS.md:最基礎,也最應該先做
如果一個專案沒有任何程式碼庫記憶,第一步不該是上複雜索引,而是先補一份專案規則檔案。
|
|
這類檔案適合保存「專案怎麼做事」:用 pnpm 還是 npm、測試命令、哪些目錄是生成物、哪些檔案不能改、改 API 後要跑什麼檢查、AI 最後怎麼回報。
它的優勢是簡單、可提交到 Git、團隊共享、跨工具可讀。缺點是它不會告訴 Agent 函式在哪裡被呼叫。它是地基,不是完整程式碼索引。
站內這篇已經講過多專案記憶怎麼分層:/zh-tw/2026/07/08/claude-code-multi-project-memory-team-workflow/。
Cursor codebase indexing:適合 IDE 內閉環
Cursor 的 codebase indexing 更適合已經在 Cursor 裡日常開發的人。它會為目前程式碼庫建立索引,讓聊天、編輯和 @Codebase 這類上下文引用更容易命中相關檔案。
適合 IDE 內開發、在編輯器裡直接問功能位置、根據目前專案補程式、不想維護 MCP server、團隊主要都用 Cursor 的場景。
邊界也要清楚:索引主要服務 Cursor 內部工作流,跨工具共享有限;大倉庫要注意索引範圍和 ignore;不能只依賴它表達專案規則,仍然需要 AGENTS.md;生產設定、密鑰和生成物目錄要排除。
如果你已遇到 Claude Code token 暴漲、MCP 返回過多、上下文越來越亂,請記住:索引不是越多越好,真正有價值的是和目前任務相關的上下文。相關排查可看:/zh-tw/2026/07/08/claude-code-token-usage-spike-troubleshooting-faq/。
Serena MCP:適合大程式碼庫的語義導航和重構
Serena 更接近「給 AI Agent 用的 IDE 能力」。它透過 MCP 提供語義程式碼檢索、編輯、重構和除錯工具。
它適合大型 Python、Java、TypeScript、Go 等程式碼庫;Agent 經常找錯函式、讀錯檔案;需要查 symbol、引用、宣告和實作;需要更安全地做跨檔重構;也適合讓 Claude Code、Codex、OpenCode、Gemini CLI 等 MCP 客戶端共享同一套工具。
Serena 的優勢在於 symbol 級操作。普通 Agent 常靠全文搜尋和行號編輯,複雜專案裡容易誤傷。語義工具能讓它更像 IDE 一樣工作。
如果只是寫小腳本、改單頁應用、一兩個檔案的 bug,普通搜尋和編輯已經夠用。MCP 本身排障可以看:/zh-tw/2026/07/08/mcp-tool-call-failure-troubleshooting-faq/。
codebase-memory-mcp:適合多工具共享持久程式碼記憶
DeusData/codebase-memory-mcp 會把程式碼庫索引成持久知識圖譜,再透過 MCP 提供給支援 MCP 的 Agent。
它適合同時使用 Claude Code、Codex、Cursor、Aider、OpenCode 等多個工具;希望多個 Agent 共享同一個程式碼索引;專案較大,Agent 經常重複讀同一批檔案;想減少上下文裡塞大量原始碼;想要本地化、可重複的程式碼查詢能力。
優勢是「持久」和「跨工具」。缺點是要維護安裝更新、索引刷新、MCP 配置、權限範圍、忽略規則和客戶端相容性。
如果只是偶爾讓 AI 改兩行程式,沒必要上它。如果每天在多個 Agent 之間切換,它會更有價值。站內已有單獨教程:/zh-tw/2026/06/22/codebase-memory-mcp-code-intelligence-guide/。
RepoPrompt:適合人工精確控制上下文
RepoPrompt 和 RepoPrompt CE 的思路不是讓系統自動讀完整倉庫,而是幫使用者組裝一份可審查的上下文。
它適合想明確控制模型看到哪些檔案、複雜需求前需要人工選關鍵檔案、擔心自動索引帶入無關內容、想把檔案、CodeMap、目錄結構、Git diff 一起交給 AI 的場景。高風險重構、架構評審、程式碼審查都適合。
穩定流程是:人先選入口檔案、相關模組和 diff;RepoPrompt 生成上下文包;AI 做設計、審查或修改建議;真正寫程式前再縮小範圍。
Sourcegraph:適合企業多倉庫
Sourcegraph 更偏企業級程式碼理解平台,強調大型程式碼庫和多倉庫環境的索引、搜尋、權限和程式碼演進控制。
它適合多倉庫企業團隊、大型 monorepo、跨服務遷移、需要權限/審計/SSO/集中搜尋、Agent 需要理解不止目前本地倉庫、安全合規要求高的組織。
個人開發者通常不需要一上來用 Sourcegraph。它的價值在規模。
不同專案怎麼選
個人小專案
|
|
先寫清命令、目錄和禁區,再讓 Agent 小步修改。重點不是記住所有檔案,而是別用錯命令、別誤刪檔案、別改無關目錄。誤刪防護可以看:/zh-tw/2026/07/10/ai-coding-avoid-accidental-file-deletion/。
中型業務專案
|
|
規則檔案負責穩定約束,IDE 索引負責日常問答,Serena 負責更複雜的語義導航。
大型單倉庫
|
|
大型單倉庫最怕 Agent 把整個專案當成一坨文字。應該按模組拆:根目錄寫全局規則,子目錄寫局部規則,MCP 工具查 symbol 和依賴,重要任務先做只讀影響面分析,修改時只改小範圍。
如果還會用 Claude Code subagent,可以把「程式碼檢索」和「專項審查」拆成不同角色:/zh-tw/2026/07/10/claude-code-subagent-project-fit-guide/。
多倉庫團隊
|
|
多倉庫團隊最重要的是統一規則和權限。這時程式碼庫記憶已經不是個人效率工具,而是工程治理的一部分。
選型時看這 7 個問題
- 程式碼庫有多大?
- Agent 主要問題是「不知道規則」,還是「找不到程式碼關係」?
- 你只用一個 IDE,還是同時用 Codex、Claude Code、Cursor、Aider?
- 是否需要團隊共享同一份規則和索引?
- 是否有密鑰、生產設定、客戶資料等敏感檔案?
- 是否經常做跨檔重構和遷移?
- 你能接受維護額外 MCP server 或企業平台嗎?
規則混亂就先寫 AGENTS.md / CLAUDE.md。找不到程式碼就考慮 Cursor 索引、Serena 或 codebase-memory-mcp。多倉庫治理就考慮 Sourcegraph。高風險任務上下文要可審查,就考慮 RepoPrompt。
常見錯誤
把記憶檔案寫成專案百科
CLAUDE.md 和 AGENTS.md 不應該塞所有歷史背景,只寫會影響操作的穩定規則。
索引範圍太大
不要把這些目錄交給 Agent 當主要上下文:
|
|
索引工具要配合 .gitignore、.cursorignore、工具自己的 ignore 檔或 MCP 配置使用。
把搜尋結果當事實
程式碼檢索只能說明「找到了一些相關內容」,不代表結論一定正確。Agent 仍然需要讀入口檔案、查呼叫鏈、看測試和設定、跑最小驗證並回報不確定性。
忘了權限和隱私
接入前要確認是否上傳程式碼、索引存在何處、是否共享、是否包含 .env 和客戶資料、MCP server 是否限制工作目錄、日誌是否會列印敏感內容。
工具太多,規則太少
先把規則寫清楚,再加索引工具。
推薦落地路線
- 給專案加一份簡短
AGENTS.md或CLAUDE.md。 - 寫清技術棧、命令、目錄、禁區和驗證方式。
- 配好
.gitignore、.cursorignore或索引排除規則。 - 日常 IDE 開發先用 Cursor / 內建索引。
- Agent 經常找錯程式碼時,再加 Serena 或
codebase-memory-mcp。 - 高風險改動前,用 RepoPrompt 這類工具人工打包上下文。
- 多倉庫團隊再考慮 Sourcegraph 或企業程式碼搜尋平台。
總結
AI Agent 程式碼庫記憶工具沒有唯一答案。它們解決不同層次的問題:
CLAUDE.md/AGENTS.md解決專案規則。- Cursor indexing 解決 IDE 內上下文。
- Serena MCP 解決語義導航和重構工具。
codebase-memory-mcp解決跨工具持久程式碼記憶。- RepoPrompt 解決人工可審查上下文打包。
- Sourcegraph 解決企業級多倉庫程式碼理解。
真正穩的組合,通常不是選一個「最強工具」,而是先用規則檔案打底,再按程式碼庫規模增加索引、語義工具和團隊治理能力。