这几个月我试了不少 AI 编程工具。从 Copilot 到 Claude Code，从 Cursor 到 Windsurf，每个都认真用了至少一周。不是评测，是真在项目里用——写新功能、修 bug、重构、翻代码库。每个工具都有自己的脾气，有的让你觉得「这东西离不了」，有的让你想摔键盘。

两周前一个做开源的朋友跟我说，试试 Aider。我当时第一反应是：又来？终端里跑的工具，还能有什么花样。Claude Code 我已经用得挺顺了，MCP Server 也搭了一整套，干嘛要换。但他说了一个词让我动了心——「map」。不是地图那个 map，是 Aider 维护的一份代码库地图，它知道自己改了什么文件、改到哪里、还有哪些没改。

我试了。然后两周后的今天，Copilot 插件被我禁用了，Claude Code 退到了特定场景才打开，日常主力编辑器换成了 Neovim + Aider。

先说 Aider 到底是什么

Aider 是个终端 AI 编程助手，Python 写的，开源。跟 Copilot 那种 IDE 内联补全不一样，Aider 是对话式的——你在终端里跟它说话，它帮你改代码。这听起来像 Cursor 对吧？但 Aider 不走 IDE，它直接在你的编辑器外面工作。你用 Vim、Neovim、Emacs、VSCode 都行，Aider 只负责一件事：听懂你的需求，然后去改文件。

核心能力就这几条：

• 读懂你的整个 Git 仓库（不只是当前打开的文件）
• 在对话中直接增删改文件
• 每次修改自动生成 commit
• 支持多个主流模型：GPT-4o、Claude Sonnet、DeepSeek、本地 Ollama 等
• 有一个叫 repo map 的仓库感知机制

听起来不复杂对吧。但真正用起来，你会发现这几条加在一起，跟那些 IDE 插件体验完全不是一个层级。

真正让我留下来的，是那个 repo map

我很难一句话说清楚这个 map 到底怎么工作，但可以给你一个场景。

上周有个任务：前端一个 React 页面加载太慢，需要做懒加载优化。用 Copilot 的时候，我打开一个文件，它帮我补全，但我得自己知道要看哪个文件、改哪个函数、在哪加 Suspense。你得先自己理解代码结构，然后告诉 Copilot 在那个上下文中补全什么。等于先干一遍活，再让 AI 帮你打字。

Claude Code 可以做全局的，但每次跑一个复杂的重构任务，它读整个代码库状态的时间比实际干事的时间还长。Claude Code 的 Agent 模式会遍历整个项目——读 package.json、读目录结构、读关键文件。如果你的项目有几百个文件，启动一次十几秒就没了。而且它读完之后，改着改着可能偏离你原本想改的目标，你还得调 prompt 把它拉回来。

Aider 不一样。我直接在终端敲：

/add src/pages/Dashboard.tsx src/components/Chart.tsx

然后说：

把 Dashboard 里的 Chart 改成懒加载，加载的时候显示一个 Skeleton

Aider 先自动读了一遍我加进去的文件，然后在对话里告诉我它打算怎么改、改哪几行。我确认后它执行，改完自动 git commit。整个对话不到三分钟。

那个 map 机制在这里起了多大作用呢？它不需要每次都重新理解整个项目结构，因为它会给模型提供一个结构化的摘要——哪些文件有什么函数、依赖关系是什么。模型启动时不至于两眼一抹黑。这个摘要不是把所有代码塞给模型，而是精简过的脉络——就像你进一个新项目时先看目录结构和关键接口一样，Aider 先帮模型把地图画好。

我专门做了个测试：在同一个项目里，用 Aider 改一个跨 5 个文件的改动，它花了 4 轮对话完成。用 Claude Code 同样的事，它花了大概 8 轮——因为前几轮都在「理解上下文」。不是说 Claude Code 不好，而是两者的上下文管理策略完全不一样。Aider 的 repo map 有点像是给模型提前准备了 cheat sheet。

跟 Claude Code 的真实对比

Claude Code 我写了七八篇了，说没有感情是假的。从搭建 MCP Server 到子智能体编排，从 Streamable HTTP 迁移到安全审计，Claude Code 在我这边一直是重型武器担当。

但说实话，Claude Code 很多时候像是在跟一个高级实习生工作——它能干很复杂的事，但你得花时间给它铺上下文、等它理解项目结构、等它把一整段代码改完。MCP 协议那一套东西很强，但在日常编码中，大部分时候我不需要「Agent 自动调度一堆工具」，我只是想让 AI 把我当前改的文件里的 bug 修了。

Aider 在定位上更务实。它不试图接管你的整个开发流程。它是一个很听话的「终端搭档」——你告诉它改什么，它改。你告诉它看哪几个文件，它看。你不会感觉它在「抢方向盘」。

我做的对比总结在这个表里，做成图贴出来——画的是 Aider 和 Claude Code 在几个关键维度上的表现差异：

从我的实际体验看，两者在以下场景各有胜负。

Aider 赢的场景：

• 日常增删改一个函数/组件/文件 → 启动即改，延迟最低
• 小范围重构（3-5 个文件内）→ repo map 提供上方文不需要全量扫描
• 跟 Git 工作流深度绑定 → 每个改动自动 commit，方便回溯
• 配合 Neovim/Emacs 使用 → 不离开终端完成所有操作

Claude Code 赢的场景：

• 跨 20+ 文件的架构级重构 → Agent 能主动发现需要改哪些文件
• MCP Server 开发 → 原生 MCP 工具链集成
• 接入外部工具和数据源 → 通过 MCP 协议连接数据库/API/文件系统
• 自主执行复杂任务 → 给它一个目标，它自己规划和执行

所以对于我来说，两者不是替代关系，是互补关系。Aider 管日常编码，Claude Code 管架构大活。各司其职。

Copilot 为什么被我禁用了

这个话题可能会得罪人，但我说实话。

GitHub Copilot 在刚出来的时候确实惊艳。2022 年我第一次用 Copilot，看着它在一个空文件里接着我打了三个字母就补出了整段代码，当时的感觉就是「这玩意儿会改变一切」。事实上它确实改变了——它让内联补全成了 AI 编程的标配功能。

但两年后，Copilot 的进步幅度让我有点失望。它到今天仍然以「当前文件」作为主要上下文。我在一个文件里改了接口签名，另一个文件的调用方它看不见。你让它写一个新组件，它参考不了项目中已有的组件风格。这些问题 Copilot 一直在改进，但改进速度赶不上我对它的期待。

还有一个更现实的问题：Copilot 插件在 VSCode 里占了不小的资源。我开三个项目窗口的时候，Copilot 的进程经常冲到几百 MB 内存。而且它的模型也比较单一，默认是 GPT-4o 的一个优化版本，不能切到 Claude 或者 DeepSeek。我有很多任务在 Claude 上的表现更好。

所以两周前我把 Copilot 禁用了。不是因为它不好用，而是 Aider + Claude Code 的组合在我这覆盖了 Copilot 的所有使用场景，而且做得更好。

同样有坑——Aider 的硬伤

说了这么多好话，下面这些坑是真实的，你可能也会碰到。

坑一：对复杂重构的理解有限。

上周我想把一个 Redux 的 store 拆成几个独立的 slice。Aider 知道要怎么做，但改了三分之一就停了，说「这需要跨多个文件做结构化改动，建议手动完成引导」。它诚实，但也暴露了上限——当改动涉及数据流架构级变化时，Aider 不如你亲自重写。它不擅长「现在有一个入口 A，要改成从 B 和 C 两个新入口进来」这种抽象程度高的任务。你给它具体指令它能执行，但让它自己设计拆分方案，它的方案通常过于简单，忽略了很多边界情况。

坑二：模型输出的稳定性悬在 API 质量上。

Aider 本身不提供模型，只是调用 API。我配的是 Claude Sonnet 4.8。有时候同一个请求，早上好、下午崩；GCP 区的 API 和三方的 API 输出的代码风格都不一样。你可以锁定模型版本，但这种弹性的稳定性问题没法完全消除。有一次 Aider 改完了一个文件，生成的代码直接跑不起来——原因是模型在输出中忘了导入一个依赖模块。Aider 没有内置的编译检查来捕获这种问题。不像 IDE 插件，你改完马上能看到红线。Aider 改完后你得自己手动跑一下编译来确认。

坑三：它真的只是个编辑器。

Aider 没有调试器、没有终端内嵌的测试运行器、没有 Git 可视化。你把 Aider 当编辑器用，就还得配一套别的工具。我换到 Neovim 之后配了一套插件生态，花了两个周末才弄顺手。如果你不习惯终端工作流，Aider 的学习曲线比 Copilot 陡很多。我有个同事试了两天就放弃了——他说「我在终端里打字聊天来改代码？这不跟 90 年代写命令行一样吗？」

坑四：大项目的 repo map 膨胀。

这是个鲜为人知的坑。如果你的项目有几百个文件，Aider 的 repo map 默认会包含所有文件的摘要。这个摘要加起来可能好几 MB，启动速度从秒级降到十几秒。解决办法是在 .aiderignore 里显式排除不需要的目录。

举个例子，我一个用了 NestJS 的项目，光 node_modules 就几万个文件。就算 .gitignore 里排除了，Aider 的 repo map 还是会尝试索引工具链相关的配置文件。后来我加了：

# .aiderignore
node_modules/
build/
dist/
coverage/
*.min.js
*.bundle.js
*.map

启动时间从 12 秒降到了 3 秒。

我是怎么配置的

如果你看了也心痒，给你我的完整配置参考。首先是安装：

# 安装
pip install aider-chat

# 配 API key（我用的 Claude Sonnet 4.8）
export ANTHROPIC_API_KEY=sk-xxxxx

# 常用启动命令
aider --model claude-sonnet-4.8 --auto-commits --map-refresh always

持久化配置 .aider.conf.yml：

model: claude-sonnet-4.8
auto-commits: true
map-refresh: always
git: true
edit-format: udiff

说几个我踩过坑才调对的参数。

--map-refresh always——默认是 auto，只在文件变更时刷新 map。但如果你经常切换分支或 pull 代码，auto 模式可能拿到过时的 map。设成 always 让每次对话都重新扫描仓库结构，代价是启动慢几秒，但 map 更准。

--auto-commits——一开始我对自动 commit 有点抵触，觉得是不是把 git 历史弄脏了。实际用了发现这是 Aider 最好的设计之一。每一步改动自动 commit，你可以随时 git log 看到 AI 改了什么、改的什么文件。不满意的话 git reset 就能回到改动前的状态。比你自己手动 staging 方便太多了。

--edit-format udiff——这个参数控制 Aider 怎么输出改动。udiff 格式的改动更精细，模型给的是行级别的 diff 而不是整个文件覆盖。大文件时这个差异特别明显——udiff 改得快，整个文件覆盖容易出问题。

还有：我建议一开始在空项目或者新功能分支上试 Aider，不要直接在主分支用。因为虽然 Aider 有自动 commit，但刚开始你可能不熟悉它的行为模式。我第一天试用就让它改了一个已经在用的配置文件，虽然它自动 commit 了，我还是慌了半秒钟。先在小项目上跑两天，熟悉了再上主项目。

我的现状

现在我每天的工作流长这样：

1. Neovim 写代码日常用，Aider 做伴——对话改文件。最常见的是 「/add 文件 → 提需求 → 确认 → 继续」这个循环。
2. Claude Code 做「重型任务」——跨 20+ 个文件的 MCP Server 开发、架构级重构、大批量代码迁移。这一块 Aider 干不了，Claude Code 是唯一选择。
3. Copilot 禁用了——插件在 IDE 里占资源，给我的回报不如 Aider 直接

不是说 Aider 比 Claude Code 好——两者做的事情不同。Claude Code 是 Agent，是自主干活的东西；Aider 是搭档，是帮你干活的工具。我现在把两者分得很清楚：Aider 负责「这段代码怎么改」，Claude Code 负责「这个系统怎么搭」。

如果你现在在观望该用什么 AI 编程工具，我的建议是别急着抄作业。先看你日常写代码的模式：

• 如果你大部分时间在一个文件里深耕，Copilot 那种内联补全就够了
• 如果你经常跨 3-5 个文件做改动，Aider 的对话式编辑 + repo map 是甜区
• 如果你需要 AI 自主完成从需求到代码的端到端任务，那还是得上 Claude Code 或者类似的 Agent 平台

Aider 刚好卡在第二个点上——不重、听指挥、不抢方向盘。它不像 Copilot 那样一直打断你给你补全，也不像 Claude Code 那样接管你的终端。它在旁边等着，你叫它它才动。

如果你已经用了一段时间 Aider，欢迎来聊你的配置。我那个 .aider.conf.yml 还在调，想看看别人都开了什么参数。尤其是那些在大型 Monorepo 里用 Aider 的朋友，你们怎么处理 map 膨胀的问题？

又想起一件事：刚才我说的那个懒加载优化，后来 Aider 又帮我改了一次。这次它没按常规思路来。它在我加了 /add 之后看了一下项目里的 webpack 配置，然后直接提议说用 React.lazy 加上 magic comment 做按需分块。我试了一下，构建产物小了 40%。这一个改动省了我一下午。这种时候你会觉得它不像个工具，像个真的有经验的同事坐在你旁边。