Busabase × AiderAider 知识库
Aider 天然会留下很强的代码证据：仓库上下文、diff、测试和带归属的 Git commit。Busabase 补上 Git 不负责的部分：这次修改对业务意味着什么、谁负责，以及其他团队和 Agent 能否把它当成当前事实。
四类工件，四种职责
不要把 repo map 或聊天记录变成第二套事实源。
Aider 为编辑仓库压缩上下文。持久知识链应让每种工件继续留在最适合它的系统。
| 工件 | 能证明什么 | 长期归属 |
|---|---|---|
| Repository map | 哪些 symbol 和依赖帮助了模型 | Aider session context |
| 聊天与 mode 历史 | 计划如何变成修改 | Aider history |
| Diff、测试与 commit | 代码究竟改了什么 | Git 与 CI |
| 已接受影响 | 下游现在可以依赖什么 | Busabase |
计划与编辑都不等于批准
Ask、architect、code 分开的是推理和改文件，不是判断与权威。
Ask mode 只讨论；architect mode 先提出方案，再由 editor model 转成修改；code mode 直接编辑文件。它们都不会自动指定业务负责人，也不会让运营结论成为 canonical。
探索问题
保留选项与未解决假设。
提出并转译方案
把方案和最终 diff 关联起来。
修改仓库文件
进入正式状态前完成测试和审核。
Git 原生证据
把 Aider commit 当作不可变证据，不要当成最终决定记录。
Aider 可以用描述性消息提交修改、隔离已有 dirty work、标记作者、展示 diff 和撤销变更。知识库应链接准确仓库与 revision，而不是复制源码。
没有原生 MCP client
Aider 与 Busabase 并排运行，不伪装成同一个 tool surface。
Aider 官方文档没有 MCP client。让 Aider 专注仓库；在同一终端使用 busabase-cli，或由代码调用 REST API，读取记录并提交待审核更新。
编辑、测试、提交
负责仓库执行与代码工件。
读取与提议
负责需要审核的结构化状态。
修改档案
只提升一份决定包，不搬运整段编码对话。
审核者不应为了理解结论而重放完整 session。
| 字段 | 审核问题 |
|---|---|
| change_key | 哪条持久结论正在变化？ |
| repo_revision | 哪份代码状态生成了证据？ |
| request | 最初要求的结果是什么？ |
| implementation_refs | 由哪些 diff、文件或 Pull Request 承载？ |
| verification | 哪些测试、lint、构建或运行检查通过？ |
| impact | 用户或运营状态发生什么变化？ |
| owner | 谁有权接受这项影响？ |
| decision | 接受、有条件接受、拒绝或已替代？ |
| effective_at | 下游从何时可以依赖？ |
两条审核链
Code review 保护仓库，record review 保护所有读取结论的流程。
干净的 diff 仍可能写错策略、部署假设、支持承诺或运营状态。
仓库审核
实现能否工作，是否应该进入这个 branch？
记录审核
结论是否有证据、负责人且仍然有效？
实际问题
Aider 知识库常见问题
Busabase 会取代 Git 吗？
不会。Git 负责源码、commit、branch 和代码历史；Busabase 把这些工件连接到已审核运营决定。
Aider 能通过 MCP 使用 Busabase 吗？
官方没有记录 Aider 的 MCP client。请在旁边使用 busabase-cli，或从代码调用 REST API。
要把聊天记录复制进 Busabase 吗？
通常不要。只提升决定、证据引用、负责人和当前状态。
Aider commit 会自动被批准吗？
不会。它只记录一份代码状态，仓库审核与记录审核仍是两次决定。
关闭 Git 集成怎么办？
必须提供其他不可变 revision 与验证链，不能把未版本化 working tree 当成持久证据。
从一项已验证修改开始
代码继续留在 Git，只提升需要共享信任的后果。
选择一项已有稳定 revision 且验证完成的 Aider 修改，整理精简影响档案，再由负责人审核后交给其他 Agent 使用。