代码库记忆：wiki 还是 RAG

原文：raw/sources/mindstudio-wiki-vs-rag-codebase.md（MindStudio《LLM Wiki vs RAG for Internal Codebase Memory》，2026-04-07）。confidence 标 medium：MindStudio 是 agent 平台厂商，选型建议可能带产品倾向，事实性对比部分仍有参考价值。

核心结论

RAG 赢在规模，wiki 赢在清晰与控制。 逐维对比：wiki 设置成本低（纯 markdown）、可解释性高（人可读可改）、调试容易（改文件 vs 重嵌入）、扩展上限约数百文件；RAG 可扩到数百万文档、擅长语义搜索与混杂内容，但 chunking 破坏代码结构、cosine 相似度答不了关系型问题（“什么依赖这个模块”）、更新要重嵌入、检索是黑盒。

RAG 的辩护（对本库有价值的反方细节）

• 超大代码库真需要 RAG：几十万文件的 monorepo 没人会手工维护 wiki。
• “团队不维护 wiki”是真实约束：wiki 方法需要持续人工策展，做不到时自动 re-indexing 的 RAG 反而更稳健——wiki 的最大缺点是“不主动维护就过时，然后 agent 输出错误指导”。
• 搜索型（“找 X 在哪”）workload 天然适合语义检索，导航型（“系统 Y 怎么运作”）才适合 wiki。

混合模式（实践建议）

1. wiki 管架构知识（conventions/patterns/ADRs），RAG 管代码搜索（找具体实现）
2. wiki 作 RAG 的路由层：index 决定该跑哪条检索查询
3. LLM 自动生成 wiki 初稿、人类编辑维护——不必从零手写

与本库其他来源的关系

与 Vishal Mysore 三方对比的“三者互补”结论一致；为 RAG vs 编译式 Wiki 提供了 RAG 一方的正面辩护与量化边界（数百 vs 数万文件）。