让 AI 接着改老项目，Aider 把每次修改留在 Git 里

把一段函数粘给聊天机器人，它往往能改得像模像样。真正接回项目时，麻烦才开始：接口是不是在别处调用？名字换了，测试和配置有没有跟着变？最后还得自己把聊天里的代码搬回文件。

Aider 想解决的是这段断层。它直接在本地代码仓库里工作，通过对话修改文件，并把改动接到 Git。对已有项目的开发者而言，值得关注的不是又多了一个聊天窗口，而是 AI 写代码终于可以按一次次可回看的修改来管理。

它怎么知道隔壁文件里有什么

Aider 的一个关键设计叫仓库地图。它不会简单把整个项目都塞给模型，而是整理文件里的重要类、函数和调用签名，帮助模型判断哪些模块彼此有关；在上下文预算内，再挑选更相关的部分发送。需要更完整内容时，仍可把具体文件加入对话。官方说明给出了实际的 Python 类与方法地图。

假设要给一个中文资料管理网站补上“按标签筛选”。这是教学情境：改动可能同时涉及列表接口、页面请求和测试。仓库地图的价值，是让模型有线索找到这些关系，避免只盯住你最先贴出的页面组件。它并不等于已经理解所有业务规则；权限怎么继承、空标签怎么处理，仍得由任务说明和现有代码补齐。

Aider 默认会为自己的文件修改生成提交信息并提交，提供 /diff 查看变化、/undo 撤回上一次修改。这让开发者可以继续用熟悉的 Git 工具审阅，而不必靠聊天记录拼回“刚才到底动了什么”。

这里还有一个容易忽略的行为：遇到已有未提交修改的文件，Aider 可能先把这些改动提交，以便和自己的修改分开。对习惯在工作区混放几项任务的人，这会直接影响使用方式。最好先整理当前分支，再让它接手一件边界清楚的事；如果不希望自动提交，官方也提供关闭选项。Git 文档把这些行为写得很明确。

这套机制最适合小步推进：先补一个筛选条件，再检查页面与接口是否一致，再进入下一项。自动产生提交只是留下检查点，不会替你证明功能正确。测试没有覆盖的权限问题，也不会因为有一条漂亮的提交信息而消失。

如果你已经熟悉终端和 Git，希望保留现有编辑器，Aider 的路线很直接：在仓库里启动，选择模型，加入必要文件，再描述一个可以验收的改动。具体安装与凭据配置从官方入门进入即可，不必先学一套新的云端项目管理流程。

Aider 可以连接云端或本地模型，但工具本身不会替你提供模型算力。使用云端时，被加入上下文的代码和请求会交给对应服务；使用本地模型时，运行条件和代码能力又取决于模型与机器。别把“工具开源”读成“任何项目都能免费、离线改好”。

这篇依据官方文档介绍工作方式，没有在真实业务仓库里运行。最值得带走的判断是：如果你的主要痛点是代码来回复制和修改难以回溯，Aider 值得从一个小任务试起；如果还没有可以运行的工程和验收标准，它不会自动把模糊想法变成可靠项目。