---
date: 2026-07-05 16:09
created: 2026-07-05 16:09
updated: 2026-07-05 17:01
categories:
  - AI 辅助研发
tags:
  - AI-assisted-development
  - knowledge-management
  - MCP
  - LLM-Wiki
  - Codebase-Memory
---

# 1. 从知识到代码：AI 辅助研发的知识与工具链组合拳

本文基于我近期使用 AI 辅助研发的实践经验，不空谈概念，只回答一个具体问题：

> 当团队同时拥有多个基础库、多个业务仓库和大量业务文档时，如何让 AI 不再每次都从零开始读资料、翻代码、猜架构？

我的结论是：要把AI的上下文系统拆成两层：
- **Codebase Memory MCP作为事实层（Fact Layer）**：回答代码里“确实发生了什么”。
- **LLM Wiki 作为知识层（Knowledge Layer）**：沉淀团队对系统“为什么这样设计”的理解。

AI 辅助研发的瓶颈，不是模型会不会聊天，而是它有没有一套可复用、可验证、能持续积累的上下文。代码事实必须可追溯，架构知识必须可解释；二者混在一起，就会变成一团难以校验的“智能摘要”。
## 1.1. 知识管理：先分清“事实”和“解释”

团队知识主要来自两类材料：
1. **文档**：Markdown、TXT、Word、PPT、图片、会议纪要、需求说明等。
2. **代码**：基础库、业务仓库、脚本、配置、API等。

这两类材料解决的问题不同。

文档更接近“人类解释”：它告诉我们业务目标、设计背景、决策过程和历史包袱。代码更接近“机器事实”：它告诉我们真实调用链、真实依赖、真实入口和真实边界。

因此，知识管理的关键不是把所有材料塞进一个向量库，而是让不同类型的知识进入合适的层。

## 1.2. 文档管理：用 LLM Wiki 沉淀可演进的知识

LLM Wiki 的思路来自 Andrej Karpathy 的 [llm-wiki.md](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)。它不是一个具体产品，而是一种知识库模式：让 LLM 读取原始资料，然后持续维护一组结构化、互相链接的 Markdown 页面。

传统 RAG 更像“临时翻书”：每次提问时，系统从原始材料中检索相关片段，再即时拼出答案。它能回答问题，但知识不会自然沉淀。

LLM Wiki 更像“请一个研究助理长期维护笔记”：新资料进入后，LLM 不只是索引它，而是把它整合进已有 wiki，更新主题页、实体页、概览页和综合分析页。矛盾会被标记，旧结论会被修订，知识会越用越厚。

我使用的是 GitHub 上的 [nashsu/llm_wiki](https://github.com/nashsu/llm_wiki) 客户端。它的定位是跨平台桌面应用：把文档转化为结构化、互相关联、可持续维护的知识库。

它的价值主要体现在三点：
- **把资料变成知识**：不是只保存文件，而是提炼出主题、实体、关系和结论。
- **把一次性问答变成长期积累**：每次新增材料或追问问题，都可以反向更新wiki。
- **把个人理解变成团队资产**：Markdown 文件天然适合版本管理、评审、链接和二次加工。

一个生活化类比是：RAG 像每次开会前临时翻资料，LLM Wiki 像有一个长期维护的项目手册。前者适合快速找答案，后者适合积累组织记忆。

## 1.3. 代码管理：用 Codebase Memory MCP 建立代码事实层

[DeusData/codebase-memory-mcp](https://github.com/DeusData/codebase-memory-mcp) 是一个面向 AI 编程助手的 MCP Server，可用于 Claude Code、Codex、Cursor 等工具链。

它的核心作用是：预先解析代码库，构建本地持久化的代码知识图谱，让 AI 查询代码结构关系，而不是每次都依赖 `grep`、全文搜索和逐文件读取。

官方 README 中提到，它使用 Tree-sitter 对多语言代码进行 AST 解析，并在部分语言上结合 Hybrid LSP 做语义类型解析；知识图谱中包含函数、类、调用链、HTTP 路由、跨服务链接等结构化信息。数据在本地处理和持久化，官方说明是代码不会离开本机。

![image.png](https://shinerio.oss-cn-beijing.aliyuncs.com/blog_images/20260705165054335.png)

![image.png](https://shinerio.oss-cn-beijing.aliyuncs.com/blog_images/20260705165042468.png)

### 1.3.1. 工作原理

可以把它理解成“给代码库建立地图”：

```text
代码仓库
│
▼
Tree-sitter / Hybrid LSP 解析源码
│
▼
提取代码实体（File、Class、Function、Route 等）
│
▼
分析代码关系（CALLS、IMPORTS、IMPLEMENTS、HTTP links 等）
│
▼
构建本地持久化知识图谱
│
▼
AI 通过 MCP 查询知识图谱
```

它记录的是**代码事实（Fact）**，而不是 AI 总结出的架构故事。典型事实包括：

- 文件、模块、类、接口、函数等代码实体
- 函数调用关系（CALLS）
- import / module 依赖
- 类型引用和符号解析
- 实现关系（IMPLEMENTS）
- HTTP Route、跨服务 HTTP 调用等框架信息（取决于语言和框架支持）

这类信息的价值在于可验证。AI 不需要先猜“这个函数可能在哪”，而是可以直接问图谱：“谁调用了它？”“它依赖哪些模块？”“这个路由最终进了哪个 handler？”

### 1.3.2. 优势

相比传统的 `grep + Read` 工作流，Codebase Memory MCP 的优势在于：

- **一次解析，长期复用**：代码结构被索引后，可以在后续会话中反复查询。
- **结构化查询更准确**：调用链、依赖关系、入口路径比纯文本搜索更接近代码真实结构。
- **降低 Token 消耗**：官方 README 在结构化查询示例中给出过“约 120x fewer tokens”的说法；它适用于特定结构化查询场景，不能简单理解为所有任务都固定节省 99%。
- **查询速度快**：官方宣称结构化查询可达到亚毫秒级，实际速度仍取决于代码库规模、索引状态和查询类型。
- **本地运行**：使用本地持久化存储，无需外部数据库或 API Key，适合对代码安全敏感的团队。
- **适合多仓协作**：当多个基础库支撑多个业务仓库时，它能帮助 AI 更快理解平台边界、复用路径和跨仓依赖。

一句话总结：它不是让 AI “更会猜”，而是让 AI “少猜一点”。

## 1.4. 二者如何协同

| 维度 | Codebase Memory MCP | LLM Wiki |
| --- | --- | --- |
| 核心对象 | 代码 | 文档与人类解释 |
| 主要方法 | 静态分析 + 结构化图谱 | LLM 阅读、整理、综合与维护 |
| 主要产物 | 代码知识图谱 | Markdown 知识文档 |
| 擅长回答 | “谁调用了谁？”“入口在哪里？”“依赖关系是什么？” | “为什么这样设计？”“模块职责是什么？”“历史取舍是什么？” |
| 可靠性来源 | 可查询、可追溯的代码事实 | 可阅读、可评审、可持续修订的知识文档 |

二者不是竞争关系，而是互补关系。

**Codebase Memory MCP 负责回答“是什么（What）”。**

它告诉 AI：有哪些类、哪些函数、哪些路由、谁调用谁、依赖关系是什么。它让 AI 站在代码事实上说话。

**LLM Wiki 负责回答“为什么（Why）”。**

它沉淀模块职责、设计背景、业务语义、架构取舍和历史上下文。它让 AI 不只是看见代码，还能理解代码背后的意图。

## 1.5. 推荐组合：事实层 + 知识层

如果只用 Codebase Memory MCP，AI 能更快找到代码路径，但仍然可能不知道业务背景和设计取舍。

如果只用 LLM Wiki，AI 能读到架构解释，但仍然可能无法确认当前代码是否已经变化。

所以更稳妥的组合是：

```text
业务文档 / 会议纪要 / 设计文档
        │
        ▼
     LLM Wiki
  形成知识层：背景、职责、设计取舍

代码仓库 / 基础库 / 业务仓库
        │
        ▼
Codebase Memory MCP
  形成事实层：实体、调用链、依赖、路由

        │
        ▼
AI 编程助手
基于“事实 + 知识”进行问答、改造、排障和代码生成
```

这套组合拳的核心不是“多装几个工具”，而是建立一条清晰的知识生产线：

1. 文档进入 LLM Wiki，沉淀为可读、可维护的知识。
2. 代码进入 Codebase Memory MCP，沉淀为可查、可验证的事实。
3. AI 编程助手同时读取两层上下文，减少重复探索，降低幻觉风险，提高跨仓研发效率。