Aider 实战：TaoToken 跑通 Django 迁移脚本仓库任务

🚀 告别海外账号与网络限制！稳定直连全球优质大模型，限时半价接入中。 👉 点击领取海量免费额度

1. 这次要解决什么：Django 迁移冲突 + 补测试

Django 项目跑到中期，最烦的场景之一就是迁移脚本打架：两个分支各自生成了0007_xxx，合并后migrate直接报Conflicting migrations detected，或者makemigrations --check提示模型和迁移不一致。手工改依赖、删文件、重排dependencies，一不小心就把线上库搞乱。

这篇记录的是我用 Aider 以「仓库级任务模式」跑通一个真实仓库任务：修复 Django 迁移脚本冲突，并补齐对应测试。模型走 Kimi K2.7 Code，通过 TaoToken 的 OpenAI 兼容接口调用。Aider 负责读仓库、改文件、跑命令、生成 git diff，我负责审 diff 和拍板。

适合谁：已经在用 Django、手上有多分支迁移冲突、想让 AI 在仓库里直接动手而不是只聊天的后端同学。前置条件很简单——一个能跑python manage.py test的 Django 仓库，Python 3.10+，以及一个 TaoToken 的 Key。下面从拿 Key 到验证测试输出，一步步来。

2. 环境准备与 Aider 安装

先确认本地环境。我用的组合是 Python 3.11 + Django 4.2，Aider 通过 pipx 装，避免污染项目虚拟环境。

python -V # Python 3.11.6 pipx install aider-chat aider --version # aider 0.6x.x

如果你习惯用 pip：

python -m pip install -U aider-chat

Aider 的工作方式是「仓库级」的：它在 git 仓库根目录启动，自动把相关文件加入上下文，改完直接写回文件，并生成可 review 的 diff。所以第一步是确认你在 git 仓库里，且工作区干净——这点很重要，脏工作区会让 diff 检查清单失去意义。

cd your-django-repo git status # On branch fix/migration-conflict # nothing to commit, working tree clean

如果工作区不干净，先git stash或提交。Aider 每次改动都会留下 git 记录，方便你git diff逐条核对，也能一键git checkout -- .回滚。

2.1 复现一个迁移冲突现场

为了让你能跟着复现，我构造一个最小冲突：两个迁移文件都依赖0006，且都试图改同一个字段。

python manage.py makemigrations # 正常生成 0007_order_status.py git checkout -b feature/a # 改 models.py 里 Order.status 的 choices，生成 0007_order_status_a.py git checkout main git checkout -b feature/b # 改同一个字段，生成 0007_order_status_b.py git checkout feature/a git merge feature/b # 冲突：两个 0007 都依赖 0006 python manage.py migrate # django.db.migrations.exceptions.NodeNotFoundError # 或 Conflicting migrations detected

到这一步，仓库里就有两个0007_*文件，dependencies都指向0006。这就是 Aider 要处理的任务。

3. 在 TaoToken 拿 Key 并配置 Aider

Aider 支持 OpenAI 兼容接口，所以只要把 Base URL 指向 TaoToken，用拿到的 Key 就能调用 Kimi K2.7 Code。先去官网注册并创建 Key：

• 官网入口：https://taotoken.net/?utm_source=taotoken_aicg_blog_generate&utm_content=aider_django
• 控制台创建 Key：https://taotoken.net/console?utm_campaign=generate
• Key 管理页：https://taotoken.net/api-keys?utm_campaign=generate

创建后复制 Key，形如sk-...。注意别把 Key 写进仓库文件，用环境变量。

export TAOTOKEN_API_KEY="sk-你的key" export OPENAI_API_BASE="https://taotoken.net/api" export OPENAI_API_KEY="$TAOTOKEN_API_KEY"

Aider 读取OPENAI_API_BASE和OPENAI_API_KEY这两个环境变量。Base URL 用https://taotoken.net/api，不要带路径后缀。模型名按 TaoToken 文档里 Kimi K2.7 Code 对应的标识填，我这边用的是文档给出的 code 模型标识。

aider --model openai/kimi-k2.7-code \ --openai-api-base https://taotoken.net/api \ --openai-api-key "$TAOTOKEN_API_KEY"

如果你不想每次敲参数，写进~/.aider.conf.yml：

model: openai/kimi-k2.7-code openai-api-base: https://taotoken.net/api openai-api-key: sk-你的key auto-commits: false

auto-commits: false是我强烈建议的：让 Aider 改文件但不自动提交，你自己看 diff 再决定。模型和接入细节以官网文档为准：

• 接入文档：https://taotoken.net/doc?utm_campaign=generate
• 模型对话（想先试模型）：https://taotoken.net/models?utm_campaign=generate

3.1 验证 Key 是否通

启动 Aider 后先发一句无副作用的话，确认链路通：

> 只回复 ok，不要改任何文件

如果返回ok，说明 Base URL 和 Key 都正常。若报 401，检查 Key 是否复制完整、环境变量是否在当前 shell 生效；若报 404，检查 Base URL 是否误加了/v1或多余路径。排障时优先看接入文档里的示例。

4. 用 Aider 跑仓库级迁移修复任务

Aider 的仓库级任务模式，核心是让它先读相关文件再动手。启动时把迁移目录和 models 显式加进上下文，比让它自己猜更稳。

aider \ --model openai/kimi-k2.7-code \ --openai-api-base https://taotoken.net/api \ --openai-api-key "$TAOTOKEN_API_KEY" \ orders/migrations/ orders/models.py orders/tests.py

进入交互后，我给的任务描述是这样的（可直接复用）：

仓库里 orders/migrations 下有两个 0007 迁移，dependencies 都指向 0006， 导致 migrate 报冲突。请： 1. 阅读两个 0007 文件，判断哪个字段变更应保留； 2. 合并为一个 0007，修正 dependencies 链，保证线性； 3. 在 orders/tests.py 补一个测试，验证迁移后 Order.status 的 choices 正确； 4. 不要改数据库连接配置，不要动其他 app 的迁移。 改完告诉我你改了哪些文件。

Aider 会先输出它读到的文件内容摘要，然后给出修改方案。我实测下来，它一般会做三件事：把两个 0007 合并成一个、把被合并文件的dependencies改成指向保留的那个、在测试里加MigrationExecutor或直接断言字段 choices。

4.1 关键：让它自己跑迁移检查

光改文件不够，要让 Aider 执行验证命令。在 Aider 里可以直接让它跑：

请执行 python manage.py makemigrations --check --dry-run 和 python manage.py migrate --plan，把输出贴出来

Aider 会调用 shell 并把结果回显。正常输出应类似：

No changes detected

以及migrate --plan列出线性的迁移顺序，没有Conflicting migrations。如果它改完仍报冲突，让它继续：

migrate --plan 仍报冲突，请重新检查 dependencies 链

4.2 git diff 检查清单

因为关了 auto-commits，改完先看 diff。我固定核对这几项：

git diff --stat git diff orders/migrations/ git diff orders/tests.py

检查清单：

• 迁移文件数量：两个 0007 是否合并为一个，被删文件是否真的git rm；
• dependencies：新 0007 是否只依赖 0006，且没有循环；
• operations：字段变更是否只保留一份，没有重复AlterField；
• 测试文件：新增测试是否真的断言了 choices，而不是空跑；
• 无关改动：有没有顺手改了 settings 或其他 app。

任何一项不对，直接git checkout -- <file>回滚该文件，再让 Aider 重做。这一步是仓库级任务的安全阀。

5. 可验证结果与失败分支

改完并核对 diff 后，跑测试拿最终证据：

python manage.py test orders -v 2

预期输出：

test_status_choices_after_migration (orders.tests.MigrationTests) ... ok ---------------------------------------------------------------------- Ran 1 test in 0.0xxs OK

再跑一次迁移检查确认干净：

python manage.py makemigrations --check --dry-run # No changes detected python manage.py migrate --plan # 线性列出 0001 ... 0007，无冲突

到这里，任务闭环：冲突修复 + 测试补齐 + 迁移链线性。

失败分支我也踩过几个：

一是 Aider 合并后dependencies指向了不存在的迁移名，migrate --plan报NodeNotFoundError。处理方式是让它读0006的实际文件名再改，别凭记忆写。

二是测试写成了self.assertTrue(True)这种空断言。发现后我直接要求「断言 Order._meta.get_field('status').choices 包含预期值」，它才补上真实断言。

三是模型误改了settings.py的数据库配置。因为关了 auto-commits，diff 里一眼看到，回滚即可。这也是我不建议开自动提交的原因。

四是 Key 额度或限流导致的 429。这时 Aider 会中断，检查控制台用量即可，重试或换时段。成本与限流以官网为准。

6. 限制、成本与模型选择

Aider 的仓库级任务模式强在「读文件 + 改文件 + 跑命令」闭环，但它不是万能的。迁移冲突里涉及业务语义的取舍（两个分支谁对），它只能给建议，最终要你拍板。测试覆盖度也取决于你给的断言要求，描述越具体，产出越可用。

成本方面，Aider 每轮会把相关文件塞进上下文，仓库越大 token 消耗越高。控制手段：启动时只加必要目录，别整个仓库全加；任务描述聚焦，别让它顺带重构。具体计费和模型可用性以官网为准：

• 官网：https://taotoken.net/?utm_source=taotoken_aicg_blog_generate&utm_content=aider_django
• 接入文档：https://taotoken.net/doc?utm_campaign=generate

模型选择上，Kimi K2.7 Code 在代码仓库任务里对文件依赖和迁移链的理解比较稳，适合这类需要读多文件再改的场景。如果你只是单文件小改，用更轻的模型也能省成本。长期高频跑仓库任务，可以看 Coding Plan：

• Coding Plan：https://taotoken.net/coding-plan?utm_campaign=generate

最后给个实用技巧：把这次的任务描述和检查清单存成仓库里的docs/aider-migration-task.md，下次遇到迁移冲突直接让 Aider 读这个文件再执行，省去重复描述，产出也更稳定。

🚀 告别海外账号与网络限制！稳定直连全球优质大模型，限时半价接入中。 👉 点击领取海量免费额度