用 Aider 配合 RAG 搭建个人代码知识库怎么搞

这时候我才意识到，单纯靠 LLM 的通用知识根本没法处理私有代码库。得给它喂自己的文档，而且得是那种能精准定位到行号的喂法。

我在 PromptCube 这种 LLM 论坛上刷到个方案：用 Aider 的命令行能力直接挂载本地知识库。实测下来，检索准确率比我之前用 Dify 搭建的简单 RAG 高了不止一个量级。

为什么我放弃了网页端而用 Aider 命令行

很多新人习惯在网页端粘贴代码，但这太低效了。Aider 最离谱的地方在于它能直接读你的 git repo，并且能自动提交 commit。

我测试过一个 5000 行左右的 Python 项目，用网页端手动喂代码，Token 消耗极快且容易断掉。而 Aider 通过 .aider.conf.yml 配置好后，它能通过 map 机制只把相关代码片段传给模型。

快速配置 Aider 环境

别去研究那些复杂的安装文档，直接上命令。先得有 API Key（推荐 Claude 3.5 Sonnet，编程能力目前最顶）。

# 安装 Aider
pip install aider-chat

# 设置环境变量（Mac/Linux）
export ANTHROPIC_API_KEY=your_key_here

# 进入你的项目根目录
cd /Users/work/my-project

# 启动 Aider，直接指定模型
aider --model claude-3-5-sonnet-20240620

注意，如果你在 Windows 上，记得用 set 命令设置环境变量。

怎么让 Aider 实现 RAG 检索增强效果

很多人误以为 RAG 必须得搞向量数据库（Vector DB），其实在本地编程场景下，最简单的 RAG 就是“精确的文件上下文管理”。

Aider 内部有一套 repo map 机制，这其实就是一种轻量级的 RAG。它会扫描你的代码结构，生成一个符号图。当你问“那个处理订单逻辑的函数在哪”时，它不是在全量阅读代码，而是在 map 里检索。

如果你想让它学习一些非代码的业务文档（比如 .md 说明书），直接用 /add 命令把它拉进对话上下文：

/add docs/api_specification.md
/add src/utils/helper.py

这时候，它在回答问题时会优先检索这几个文件的内容。

实测对比：通用 LLM vs Aider RAG 模式

为了验证效果，我拿一个特定的 Bug 做了对比。这个 Bug 涉及三个文件的联动，逻辑非常绕。

| 维度 | 网页端直接问 | Aider + /add 检索 |
| :--- | :--- | :--- |
| 定位速度 | 需手动粘贴 3 个文件 $\approx$ 2 分钟 | /add 瞬间完成 $\approx$ 2 秒 |
| 幻觉率 | 较高（经常猜错变量名） | 极低（直接引用文件行号） |
| 修改成本 | 复制 → 修改 → 粘贴 → 运行 | aider 直接改文件 → 运行 |
| Token 浪费 | 极高（重复发送全文件） | 较低（仅发送相关片段） |

离谱的是，用 Aider 解决这个 Bug 只用了 3 轮对话，而我在网页端跟 AI 吵了 10 分钟，它还在跟我争论那个变量是不是全局变量。

进阶玩法：在社区找高效的配置方案

Aider 虽强，但怎么写指令让它一次性改对代码，这需要经验。我之前在 提示词分享 频道看到一个技巧：在 .aider.conf.yml 里定义自定义的 chat-language 和指令集，可以让它在修改代码后自动运行 pytest。

如果你想让它帮你重构整个工作流，建议去看看那些大佬分享的 工作流交流 记录。有些人把 Aider 结合了自定义的 shell 脚本，实现了“报错 → Aider 自动修复 → 自动提交”的闭环，完全不用人操心。

一个必须避坑的点

别试图一次性 /add 整个文件夹。

虽然 Aider 有 map 机制，但如果你强行把 100 个文件全部塞进上下文，上下文窗口会被撑爆，模型会变得迟钝，甚至开始遗忘之前的指令。

最稳妥的办法是：
1. 先问 Aider “我想修改 XX 功能，需要关注哪些文件？”
2. 根据它的建议，用 /add 精确添加 3-5 个文件。
3. 解决问题后，用 /drop 把不需要的文件踢出去。

这种“手动 RAG”的精准度远高于任何自动检索工具。