终端党如何用 Aider 完成仓库级重构

Aider 把 AI 编程放进终端：你描述任务，它根据仓库结构修改文件，再用 git 提交记录变更。原文的结论是，它更适合跨文件重构、补测试和架构调整；如果你最需要的是敲代码时随手补全，Cursor 或 GitHub Copilot 更顺手。

这篇评测值得看的，是它区分了两种工作方式：围绕光标补代码，以及围绕任务修改仓库。不过，作者给出的测试证据有限，部分产品比较也有简化，选型时要把体验判断和能力证明分开。

Aider 的优势为什么集中在跨文件修改

原文用一个 Python 重构任务开场：重命名类、更新引用、添加类型提示、编写测试，手工可能需要 45 分钟。这里的 45 分钟只是情境估计，作者没有给出 Aider 完成同一任务的计时结果，不能据此计算提效比例。

Aider 的关键做法是构建仓库地图（repo map），把 git 跟踪代码中的类、函数及其关系压缩成结构摘要。大白话解释，就是先给模型一张项目导航图，让它知道改动可能牵连哪里。

例如，把认证模块从 session cookies 改成 JWT，往往需要同时调整认证逻辑、调用方和测试。作者认为，这类任务最能体现仓库上下文的价值。原文还称，Aider 0.60+ 增加了多文件编辑感知，可以在一次操作中应用涉及多个文件的修改；repo map 支持结合 CONTEXT.md 等自定义上下文文件补充架构说明。

但「读取整个仓库」不等于模型每次都完整理解所有源码。原文自己也承认，在 50K+ 行的大型代码库中，地图可能遗漏必要细节，需要通过 /add 手动指定文件。

仓库地图能帮助模型定位问题，不能保证它理解所有依赖。

原文把 Copilot 概括为只看打开的标签页，把 Cursor 概括为当前文件加部分上下文。这种描述没有附版本和对照过程，不足以支撑全面的产品能力排名。

自动提交让改动可追踪，但检查仍然要做

按照原文描述，Aider 会把修改自动提交到 git，并生成提交说明。这让一次 AI 操作有了明确的记录，方便查看差异、调整提交或回退。

作者建议用 git diff 审查修改，但没有说明查看的是提交前还是提交后的差异。既然改动可能已经自动提交，审查时就要选对比较范围，不能看到工作区干净就认定没有改动。

原文还给出 git reset --hard HEAD~1，用来撤销最近一次提交。它会重置工作区，执行前必须确认最近一次提交确实是要丢弃的内容，并检查是否有未提交修改。自动提交提供的是检查点，正确性仍要靠审查和验证。

Aider 还会在编辑后运行 linter，例如 ESLint、Ruff、golangci-lint，并在检查失败时尝试自动修复。对 TypeScript React 项目而言，这有助于减少格式和静态规则问题，但 lint 通过不能证明交互行为或业务逻辑正确。

原文列出了 /add、/drop、/git、/lint、/test 等命令，也估计 API key、模型选择和 repo-map 配置需要 15-30 分钟。上手成本不只来自安装，还包括学会控制上下文、读懂 diff，以及判断检查结果。

模型、费用和等待时间，决定它适合多大的任务

Aider 支持 15+ 模型提供方，原文列出的包括 OpenAI、Anthropic、Google、DeepSeek、Ollama、Together AI 和 OpenRouter，其中 Ollama 对应本地模型使用路径。

作者推荐 Claude Sonnet 4 或 GPT-4o，预算有限的个人开发者可以考虑 DeepSeek Coder V3；也建议复杂重构用 Claude Sonnet 4，简单修改切换到 GPT-4o Mini。这些是作者的选型建议，文中没有给出模型间的成功率或质量对照。

费用也要按使用方式理解。原文估计，一次较重的 Claude Sonnet 重构会话花费 $0.50-1.00，全职日常使用可按 $20-50/月准备预算，并拿 Copilot 的 $10/月固定订阅作比较。这些数字没有附 token 用量、任务规模和计价日期，适合作为原文的预算参考，不能直接当作当前报价或你的月账单。

作者还提到，每次编辑需要一次完整 API 往返，约 2-5 秒。修改错别字时，这段等待很显眼；涉及多个文件的任务，则更应该看整项工作多久完成、返工多少。

实验性的 Whisper 语音输入也体现了这种取舍：作者认为它能用，但可靠性尚不足以支撑日常工作，打字或粘贴仍然更快。

我的判断

我认同作者按任务选择工具的思路。即时补全服务于连续写代码，终端对话则适合把边界明确的一组修改交出去。两种需求可以共存。

但这篇评测的「实测」部分不够扎实。作者列出 Python FastAPI 后端、TypeScript React 前端和 Rust CLI 三种项目，却没有公布项目大小、具体任务、完成时间、测试通过率或人工修复次数。「一次改完所有受影响位置」「两种工具一起用最优」都应视为经验之谈。

自动提交也不构成对 IDE 工具的绝对优势。团队原本就可以通过分支、手动提交、代码审查和 CI 管理 AI 修改。Aider 的便利在于把提交融入操作流程，能否减少返工仍取决于任务和检查方式。

这篇文章支持你试用 Aider，尚不足以证明它比其他工具更高效。

能拿来做什么

• 在 TypeScript React 项目里，选一个范围明确的跨文件重构试用，例如重命名公共模块并更新引用，同时检查遗漏、误改和人工修复量。
• 把项目架构、模块职责和关键约定整理进 CONTEXT.md；大型仓库再用 /add 指定相关文件，帮助模型获得必要细节。
• 将 ESLint 和测试纳入修改后的验证流程，并审查自动提交中的实际差异，避免只凭提交说明接受结果。
• 如果主要需求是行内补全，可以继续使用 Cursor 或 Copilot；有跨文件重构需求时再引入 Aider，并记录 API 花费和返工时间后决定是否长期使用。