跳转至

Aider：Repository Map 与 Architect Editor 分工

为什么值得单独看

Aider 有两个机制很适合放在一起看。Repository Map（仓库映射）会用有限的 Token 预算挑出仓库结构，让 Model 看到聊天文件之外的相关符号。Architect（架构师）模式则先出方案，再编辑文件，这两个阶段还能选用不同模型和编辑格式。前一个机制决定 Context 里放什么，后一个机制决定怎样把建议交给 Editor 落到文件上。

这两个机制能降低大型代码库的操作难度，却补不上所有证据缺口。信息仍可能漏掉。Map（映射）压缩以后可能丢掉关键文件，Architect 也可能拿着残缺的上下文出方案，Editor 甚至会把正确建议改错。本文只讲锁定源码中可以核对的选择过程和交接过程。模型表现不错、生成提交或测试碰巧通过一次，都不能证明 Task 做对了。

Aider Repository Map 与 Architect Editor 分工

机制一：Repository Map；机制二：Architect 与 Editor

RepoMap.get_repo_map 先检查 Token 预算，也检查有没有其他文件。预算为零，或者其他文件一个都没有，它就直接跳过 Map。检查通过后，这个函数收下聊天文件、其他文件、用户提到的文件和标识符，再调用标签排序逻辑。若当前没有聊天文件，它还会从 Context 窗口里扣掉预留空间，把剩余容量拿来扩大仓库视图。

Repository Map 会把候选符号和引用排好顺序，再投进 Context，让每个 Token 尽量多带一些有用信息。它不包含完整文件，也不能保证每项依赖都会入选。配置本身不够。map_tokens、Context 窗口、用户提到的线索和排序结果会一起决定模型看见什么，所以复现实验还要保存最终 Map 或它的哈希，以及预算 Config。

ArchitectCoder 继承 AskCoder，它会先给出架构建议或修改建议。等 Response 完整返回后，如果内容不为空，并且没有开启自动接受，它就会问用户要不要继续改文件。用户批准后，代码再从主模型配置里选择 editor_model。没有独立 Editor 时，它就继续用主模型，同时设置 editor_edit_format，然后新建一个 Coder，把 Architect 的 Message 交给 Editor 执行。

交接以后，自然语言方案和结构化编辑 Protocol（协议）由两个阶段分别处理。Architect 负责分析，Editor 负责应用 Diff（差异）或整文件格式，但它们也可能指向同一个模型对象。有没有人工 Confirmation，要看 auto_accept_architect 的实际值。只有有效配置关闭了自动接受，而且确认交互确实发生过，才能说「Architect 模式有人审」。

Editor 做完以后，会把总成本和 Aider 生成的提交哈希交回 Architect，当前消息也会移回上文。提交也会骗人。提交哈希能把 Artifact（产物）追溯到某次编辑，说明那次编辑形成了 Git 对象，但它证明不了需求已经满足，也排除不了测试被改坏的可能。Git 记录和任务 Score 必须分开看。

从哪里开始读源码

先读 RepoMap.get_repo_map，核对哪些条件会让函数提前返回，预算什么时候会放大，以及代码怎样调用 get_ranked_tags_map。如果还要解释排序，就继续查看标签图、Cache 和排名实现，同时记下哪些文件算 chat_files，哪些算 other_files。只看最终 Map 文本，你很难查出文件是在哪一步漏掉的。

再读 ArchitectCoder.reply_completed。空回复怎么处理、人工怎样确认、Editor 模型和编辑格式怎么选、新 Coder 怎么建、建议怎么交出去、提交哈希怎么收回来，都集中在这里。然后沿着代码查到模型配置，确认 editor_model 是独立模型，还是主模型的别名。

把两段源码连成因果链

要找到 Repository Map 真正接进模型 Context 的位置，就查最终 Map 文本进了哪一次 Query，别停在 map_tokens 这项配置上。教学实现应保存候选文件、符号排序、预算怎样裁剪以及最终内容哈希，再把哈希关联到 Architect 请求。错误来源才查得清。方案若漏了依赖，复核者才能继续判断：源文件没被扫描，排名太低，预算把它裁掉了，还是模型忽略了已经收到的信息。

Architect 会把一份能追到来源的建议消息交给 Editor。交接记录至少要写明 Architect 模型、输入 Map、原始建议、确认决定、Editor 模型、编辑格式和新 Coder 标识。用户拒绝后，就不能创建 Editor。哪怕两个阶段使用同一模型，也要分别留下 Call 边界，不能因为模型 ID 相同，就把规划和编辑挤成一次说不清的请求。

文件 Diff、Command 结果和提交哈希把 Editor 的动作连到最终产物。提交虽然给出了不可变引用，未追踪文件、工作树残留和外部副作用仍要另行收集。做最小实验时，可以让 Architect 给出正确建议，却故意让 Editor 改错一行，再在另一轮里让 Map 漏掉关键符号。前一种错在交接，后一种错在 Context 选择。这两类失败不能混。

沿一次任务走完整链

  1. 入口确定聊天文件、其他仓库文件、提及文件与标识符，并计算 Map 预算。
  2. RepoMap 对符号与引用排序，生成受上下文窗口约束的仓库投影。
  3. Architect 读取任务、聊天文件和 Map，输出可执行的修改建议。
  4. 根据有效配置等待用户确认或自动接受，再选择 Editor 模型与编辑格式。
  5. Editor Coder 接收建议，修改文件并可能运行命令、测试或创建 Git 提交。
  6. 外部验收比较最终差异、测试与需求，独立决定任务是否通过。

记录里至少要留下 Map 预算、最终 Map、Architect 原始建议、确认决定、Editor 模型与格式、文件 Diff、命令和提交哈希。只留最终提交，你就分不出错误发生在 Context 选择、规划还是编辑。只留聊天也不够，因为它证明不了磁盘究竟变成了什么样。

它补充了六条主课程的什么

Aider 这个扩展样本讲清两件事：怎样压缩代码 Context，怎样把规划和编辑分开做。六条一级主线还会覆盖更完整的 Runtime、Session、Permission 和产品 Surface。这里不做综合排名，也不要求所有 Harness（位于模型外部，负责输入装配、工具、权限、状态和产品表面的程序）照搬 Repository Map。你真正可以带走的是三组问题：Context 投影怎么生成，遗漏怎么查出来，两个角色交接时怎样留下来源。

独立核对时，Map 和 Architect 建议属于运行 Trace，文件 Diff 和 Git 对象则是环境产物。Evaluator 要读取冻结任务和最终产物，不能因为 Architect 给了建议、Editor 正常结束或 Git 生成提交，就直接算通过。

什么时候值得采用

代码任务如果符号关系很多，完整仓库又放不进 Context，Repository Map 会比较合适。项目若只有少量文件，主要内容不是代码，语言不受解析器支持，或者依赖主要藏在 Runtime 配置里，Map 可能花了成本仍漏掉核心事实。预算也不能无限扩大，因为更多符号会挤掉任务、History 和 Tool Result 的空间。效果要按具体任务验证。

如果方案要先复核、编辑格式要专门处理，或者不同模型适合分担不同角色，可以采用 Architect/Editor 分工。改动非常小时，多一次调用反而会增加延迟和误差，自动接受也会拿掉人工检查。本文只覆盖锁定源码中的 Map 和交接机制，不评价 Aider 的所有 Mode、真实模型质量或任何部署的默认安全。迁移时沿用这些问题和记录方法即可，不必照搬类名。

最容易误判的地方

Map 最大的风险在于选错信息。预算不足、解析失败或图排名较低，都可能让关键实现缺席，模型却容易把眼前这份投影当成完整仓库。角色名称也会制造错觉。叫作 Architect 和 Editor，并不能证明背后用了不同模型，也不能证明有人审过方案。

也别把 Git 当成完成门槛。自动提交便于追查，却仍可能收进错误改动、漏掉未追踪文件，甚至通过修改测试来凑出绿色结果。运行信号不够。命令返回零、提交已经生成以后，你还得结合冻结任务、禁止项和独立测试来解释。

怎样亲手核对

你可以准备一项跨三个文件的受控任务，把关键符号放在聊天文件之外，再分别用充足和极小的 Map 预算运行。记录最终 Map 有没有带上这个符号，也记录符号缺席后方案发生了什么变化。这个实验只验证 Context 怎样投影，单个模型跑出的结果不能代表普遍性能。

做 Architect 实验时，先关掉自动接受，确认用户拒绝后代码不会创建 Editor。然后批准一次，固定独立的 editor_model 和编辑格式，再检查 Editor 收到的内容是否等于 Architect 的建议。这一步不能省。最后用外部测试验收文件产物，并故意造出一个「提交成功但需求做错」的案例，确认门禁不会把提交本身算成通过。

读完后做四个判断

问题 1

Repository Map 是完整源码吗？

答案： 不是，它是受预算和排序约束的符号投影。

问题 2

Architect 与 Editor 一定使用不同模型吗？

答案： 不一定，没有独立 Editor 时会回退主模型。

问题 3

Architect 模式一定有人确认吗？

答案： 不一定，自动接受配置会改变这条边界。

问题 4

生成 Git 提交能否计为完成？

答案： 不能，仍需按任务契约验证差异、测试和副作用。