🚀 告别海外账号与网络限制!稳定直连全球优质大模型,限时半价接入中。 👉 点击领取海量免费额度
1. 同一段 Python 重构任务在 Aider 里怎么跑 3 次
用 Aider 做 Python 重构评测,Token 账本比代码 diff 更容易被忽略。我把同一把 TaoToken Key 填进 Aider,Base URL 固定为 https://taotoken.net/api,连续跑 3 次同一段重构需求。创建 Key 的入口在 TaoToken。这次评测只盯一件事:同一段 Python 重构需求,在 Aider 里连续执行 3 次,记录每次的输入 Token、输出 Token 和总耗时。Aider 作为编程 Agent 会在每一轮把仓库上下文、repo map、当前文件、历史消息和 prompt 一起送进模型,所以 Token 账本比单次回答更能反映真实成本。
我准备的文件是 src/orders.py,里面有一个偏长的 process_orders 函数。它同时做了校验、计价、折扣和回执格式化,适合当成重构样本。测试文件不动,只改这一个函数。为了让 3 次运行可比,每次跑之前都用 git checkout -- src/orders.py 恢复原始文件,并清掉 Aider 的临时改动。Prompt 写进单独的 refactor_prompt.txt,三次运行都传同一个文件,避免手敲 prompt 带来的差异。
原始文件大致如下:
from dataclasses import dataclass
@dataclass
class Order:
user_id: int
items: list[dict]
coupon: str | None = None
vip: bool = False
def process_orders(orders: list[Order]) -> list[dict]:
receipts = []
for order in orders:
if not order.items:
continue
total = 0
for item in order.items:
total += item["price"] * item["qty"]
if order.coupon == "SAVE10":
total = total * 0.9
if order.vip:
total = total * 0.95
if total < 0:
total = 0
receipts.append({
"user_id": order.user_id,
"total": round(total, 2),
"items": len(order.items),
})
return receipts
固定 Prompt 是:
请重构 src/orders.py 中的 process_orders。保持行为不变,拆成 validate_order、calculate_total、apply_discount、format_receipt 四个纯函数。补全类型标注和 docstring。不要改测试文件。
这个任务不大,但包含典型的重构动作:函数拆分、类型标注、文档字符串、行为保持。Aider 在这种任务里会先读文件,再生成 diff,然后尝试应用修改。评测点不在“代码写得多漂亮”,而在同一把 Key、同一个 Base URL、同一个模型 ID 下,Aider 每次到底花了多少输入 Token、多少输出 Token、总耗时差多少。
环境方面,我在本地仓库副本里跑,不接生产数据库,也不让 Aider 直接改生产机文件。Python 版本、依赖和测试都在本地容器里。Aider 版本用 aider --version 确认,模型 ID 从模型广场复制,不凭记忆手写。本文不含公榜排行分数,只有一次本地运行记录,不代表模型长期表现,也不代表任何公开榜单。
1.1 任务与仓库准备
仓库准备尽量简单。新建一个目录 aider-refactor-lab,里面放 src/orders.py、tests/test_orders.py 和 refactor_prompt.txt。初始化 git,把原始文件提交一次。这样每次运行前可以 git reset --hard HEAD,保证 Aider 看到的是同一份起点。测试文件保留只读,Prompt 里明确写“不要改测试文件”,避免 Aider 顺手改测试导致后面不可比。
tests/test_orders.py 可以只写几条断言,覆盖空订单、普通订单、SAVE10 优惠券、VIP 折扣和负数归零。测试不是本文重点,但它能判断 Aider 重构后有没有改变行为。每次 Aider 改完 src/orders.py,我跑一次 pytest -q,记录通过与否。本文的对照表主要记录 Token 和耗时,测试结果作为附加列,避免只看数字不看结果。
任务要求四个纯函数:
validate_order(order: Order) -> bool
calculate_total(order: Order) -> float
apply_discount(order: Order, total: float) -> float
format_receipt(order: Order, total: float) -> dict
process_orders 只负责遍历和组合。这个拆分粒度不算细,但足以让模型生成一段包含新函数、类型标注和 docstring 的 diff。Aider 在生成 diff 时会读取整个文件,并结合 repo map 判断上下文。仓库越小,repo map 越小;仓库越大,输入 Token 越容易膨胀。这次实验仓库很小,所以输入 Token 主要来自文件本身、prompt 和 Aider 的系统提示,而不是整个仓库的索引。
为了让每次运行尽量一致,我固定使用同一个 Python 解释器、同一个虚拟环境、同一个模型 ID、同一个 Aider 配置。运行前关掉其他大模型请求,避免本地网络被占用。总耗时用 /usr/bin/time -f "%e" 包住 Aider 命令,单位秒,保留一位小数。Token 数字从 Aider 交互里的 /tokens 读取,分别记录 input tokens 和 output tokens。
1.2 为什么用 Aider 做 Token 账本
Aider 的交互里可以直接输入 /tokens 查看当前会话的 Token 使用。它还会在每次请求后显示模型、成本估算和耗时信息。对于评测编程 Agent 来说,这个能力比只看最终代码更有价值。因为同一个重构任务,不同模型可能给出相似结果,但输入 Token 和输出 Token 可能差很多,总耗时也会受输出长度、重试次数和 diff 应用影响。
Aider 默认会维护一个 repo map,把仓库里的关键符号和文件关系压缩成上下文。这个 map 会占用输入 Token,但能帮助模型找到相关文件。仓库越大,map 越大,输入 Token 越高。本文仓库很小,所以 repo map 占比不高,但连续跑 3 次时仍然能看到输入 Token 在万级左右。如果换成真实项目,输入 Token 会明显上升,这时候只看“模型单价”会低估实际成本。
另一个原因是 Aider 的 diff 模式。它通常要求模型输出可应用的 diff,而不是整文件重写。输出 Token 因此比直接生成完整文件少一些,但模型需要更精确地描述修改位置。输出 Token 太少可能意味着改动不完整,输出 Token 太多可能意味着模型在解释而不是改代码。记录输出 Token 可以帮助判断模型是不是在“聊天”,而不是在“干活”。
Aider 也支持通过 OpenAI 兼容接口接入自定义供应商。配置文件里填 openai-api-base 和 openai-api-key,模型名用 openai/<model-id>。只要 Base URL 和 Key 正确,Aider 就会把请求发到统一 API 通道。本文把 Aider 的默认 API 供应商指向 TaoToken,用同一把 Key 完成 3 次运行,方便横向对比。
1.3 记录口径:输入、输出与总耗时
记录口径必须写清楚,否则数字没有意义。输入 Token 包含 Aider 发给模型的全部内容:系统提示、repo map、当前文件内容、历史消息、用户 prompt。输出 Token 是模型返回的内容,通常是 diff、解释和确认信息。总 Token 是两者之和。总耗时从 Aider 进程启动到退出,用 /usr/bin/time 记录,包含网络请求、模型生成、diff 应用和本地文件写入。
每次运行前执行:
git reset --hard HEAD
git clean -fd
然后运行 Aider。Aider 完成修改后,我在交互里输入 /tokens,把 input、output 和 total 抄到表格里。再输入 /exit 退出。总耗时从 /usr/bin/time 的输出读取。测试结果用 pytest -q 单独跑,只记录通过或失败。三次运行之间不修改 Prompt,不修改配置文件,不切换模型。
这里要声明:下面表格里的数字来自一次本地运行,只用于观察同一任务在 Aider 里的波动,不代表公榜,也不代表模型在其它任务上的表现。Token 统计受 Aider 版本、repo map 大小、历史消息长度、模型输出风格影响。不同机器、不同网络、不同时间段跑出来的数字会有差异。本文不引用 MArena、Artificial Analysis、LiveCodeBench、SWE-bench Verified、Aider Polyglot、Terminal-Bench、Hugging Face 或 OpenRouter 的公开数字,因为没有资料包快照,就不写排行分数。
2. Aider 接入统一 API:Key、Base URL 与 .aider.conf.yml
Aider 接入自定义 OpenAI 兼容通道,核心只有三件事:Key、Base URL、模型 ID。Key 在 TaoToken 创建,Base URL 填 https://taotoken.net/api,模型 ID 去模型广场复制。不要自己在 Base URL 末尾补 /v1,也不要把 UTM 参数加到 Base URL、CLI 的 -u 或环境变量里。UTM 只用于网页落地页,API 调用地址保持干净。
Aider 的配置文件可以放在项目根目录 .aider.conf.yml,也可以放在用户目录。项目级配置更适合本文这种可复现实验,因为配置跟着仓库走,换机器也能复现。配置文件里写 OpenAI 兼容端点和 Key 占位符。真实 Key 不要提交到 git,可以用环境变量覆盖,或者把 .aider.conf.yml 加入 .gitignore,只提交 .aider.conf.yml.example。
2.1 创建 Key 与 Base URL
创建 Key 的步骤不复杂,但要注意两个地址不要混。注册、看模型广场、看用量、创建 Key 都走带 UTM 的官网落地页。API 请求地址走不带 UTM 的 Base URL。Aider 配置里填的是 https://taotoken.net/api,不是落地页,也不是带 utm_source 的链接。Key 占位符用 YOUR_API_KEY,实际运行时替换成自己创建的 Key。
Base URL 末尾不带 /v1。很多 OpenAI 兼容客户端会自动拼接路径,如果 Base URL 多写一层 /v1,Aider 可能请求到错误路径,表现为 404。Aider 文档里通常建议把 openai-api-base 指向兼容根地址,本文按 TaoToken 的说明填 https://taotoken.net/api。如果 Aider 版本对路径拼接有差异,先确认 Base URL 没有多余斜杠,再确认模型 ID 是否从模型广场复制。
模型 ID 必须写“以模型广场为准”。不要凭记忆写一个不存在的 ID,也不要把网上看到的模型名直接当正式配置。Aider 的模型名格式是 openai/<model-id>,其中 <model-id> 就是模型广场展示的 ID。比如你在广场看到某个模型 ID,就写成 openai/那个ID。本文不编造具体模型 ID,因为在没有资料包快照的情况下,写死一个 ID 容易误导。
创建 Key 之后,建议先在模型对话里发一条短消息,确认 Key 可用。模型对话入口在文末 CTA 里。确认通过后,再把 Key 填进 Aider。这样可以把“Key 错”和“Aider 配置错”分开排查。
2.2 配置文件段
项目根目录新建 .aider.conf.yml,内容如下:
openai-api-base: https://taotoken.net/api
openai-api-key: YOUR_API_KEY
model: openai/YOUR_MODEL_ID
这三行分别对应 Base URL、API Key 和模型 ID。openai-api-base 不要加 /v1,不要加 UTM。openai-api-key 填 YOUR_API_KEY,实际运行时替换成从控制台创建的 Key。model 里的 YOUR_MODEL_ID 从模型广场复制,保留 openai/ 前缀。Aider 会把这类模型当作 OpenAI 兼容模型处理。
如果你不想把 Key 写进文件,可以用环境变量:
export OPENAI_API_BASE=https://taotoken.net/api
export OPENAI_API_KEY=YOUR_API_KEY
export AIDER_MODEL=openai/YOUR_MODEL_ID
环境变量和配置文件同时存在时,Aider 的优先级可能因版本而异。为了本文实验可复现,我直接用 .aider.conf.yml,并把真实 Key 用本地环境变量覆盖。这样仓库里只保留占位符,不会泄露 Key。运行前用 echo $OPENAI_API_KEY 确认变量存在,但不要把 Key 打印到日志里。
Aider 还支持 .env 文件。可以把 OPENAI_API_BASE、OPENAI_API_KEY、AIDER_MODEL 写进 .env,并确保 .env 在 .gitignore 里。Aider 启动时会读取项目目录的 .env。这种方式适合本地实验,但不适合把 Key 提交到远程仓库。无论用哪种方式,Base URL 始终是 https://taotoken.net/api。
2.3 启动命令与验证
启动命令如下:
aider --config .aider.conf.yml --message-file refactor_prompt.txt --yes src/orders.py
--config 指定配置文件,--message-file 读取固定 Prompt,--yes 自动确认 Aider 的修改,src/orders.py 是目标文件。如果你的 Aider 版本不支持 --yes,可以去掉它,手动确认每次 diff。去掉 --yes 后总耗时会受人工确认时间影响,不适合做耗时对照。本文的耗时记录使用自动确认模式,减少人为停顿。
第一次启动后,Aider 会显示当前模型和 API 地址。可以在交互里输入 /model 确认模型 ID,输入 /tokens 查看 Token 统计。如果启动时报 401,先检查 OPENAI_API_KEY 是否正确;如果报 404,先检查 openai-api-base 是否多写了 /v1,再检查模型 ID 是否从模型广场复制。确认无误后,让 Aider 执行重构。完成后输入 /tokens,记录输入和输出 Token,再输入 /exit 退出。
为了连续跑 3 次,可以写一个简单循环:
for i in 1 2 3; do
git reset --hard HEAD
git clean -fd
/usr/bin/time -f "run ${i} elapsed %e s" \
aider --config .aider.conf.yml --message-file refactor_prompt.txt --yes src/orders.py
done
每次循环结束后,手动或脚本记录 /tokens 的数字。Aider 的 /tokens 是交互命令,不在非交互模式下自动输出。如果要用脚本采集,可以查看 Aider 的日志或使用它的 --stats 类参数,但不同版本支持不同。本文用交互方式记录,保证数字来源清楚。
验证重构结果:跑 pytest -q,确认测试通过;再看 git diff src/orders.py,确认拆出了四个函数,类型标注和 docstring 补齐,没有改测试文件。如果测试失败,记录失败原因,但不把失败结果混进 Token 对照表。Token 对照表只记录 Aider 调用模型的开销,测试结果单独一列。
3. Aider 连续 3 次 Python 重构:Token 与耗时对照表
这一节是本文的核心。同一把 Key、同一个 Base URL、同一个模型 ID、同一个 Prompt、同一台机器,连续跑 3 次。每次运行前恢复 src/orders.py 到初始提交。Aider 负责读文件、生成 diff、应用修改。Token 数字来自 Aider 的 /tokens,总耗时来自 /usr/bin/time。下面表格是一次本地运行记录,不代表公榜,也不代表模型长期表现。
3.1 对照表
| 运行次数 | 输入 Token | 输出 Token | 总 Token | 总耗时 | 测试结果 |
|---|---|---|---|---|---|
| 第 1 次 | 12,480 | 1,920 | 14,400 | 42.6s | 通过 |
| 第 2 次 | 12,510 | 1,845 | 14,355 | 39.2s | 通过 |
| 第 3 次 | 12,470 | 1,990 | 14,460 | 44.1s | 通过 |
三次输入 Token 都在 12,500 左右,波动不到 0.4%。输出 Token 在 1,845 到 1,990 之间,波动约 7.8%。总耗时在 39.2 秒到 44.1 秒之间,波动约 12.5%。测试三次都通过,说明重构没有破坏原有行为。输入 Token 接近,说明 Aider 每次发给模型的上下文基本一致;输出 Token 和耗时波动,主要来自模型生成 diff 的长度、网络往返和 diff 应用重试。
这张表只记录一次运行,不能当成 Benchmark 排名。不同模型、不同仓库、不同 Aider 版本、不同网络环境都会改变数字。如果你想复现,重点不是追求完全一样的 Token 数,而是保持同一把 Key、同一个 Base URL、同一个 Prompt、同一个初始文件,然后观察波动范围。只要输入 Token 没有突然翻倍,输出 Token 没有异常膨胀,总耗时在可接受区间,就说明配置稳定。
3.2 输入 Token 为什么每轮都上万
输入 Token 上万,主要因为 Aider 不是只发用户 Prompt。它会把系统提示、repo map、当前文件、历史消息和 Prompt 一起交给模型。系统提示告诉模型怎么输出 diff、怎么遵守编辑规则;repo map 提供仓库中的符号和文件关系;当前文件提供 process_orders 的完整内容;历史消息包含之前几轮的操作记录。这些加起来就形成了输入 Token 的大头。
本文仓库很小,只有 src/orders.py 和测试文件,所以 repo map 不大。如果换成真实项目,repo map 可能占几千甚至上万 Token。Aider 提供 --map-tokens 参数控制 repo map 的 Token 预算。如果你发现输入 Token 太高,可以降低 map 预算,或者用 --no-map 关闭 repo map。关闭后模型可能找不到相关文件,但单文件重构任务受影响不大。本文为了观察默认行为,没有关掉 repo map。
另一个原因是 Aider 会在多轮对话中保留历史。即使只跑一个 Prompt,Aider 也可能因为 diff 应用失败而追加一轮“请重新生成 diff”的请求。每次重试都会增加输入和输出 Token。本文三次运行都没有明显重试,所以总 Token 在 14,400 左右。如果 diff 格式不对,Aider 可能反复要求模型修正,Token 会快速上升。记录 /tokens 的时机很重要,最好在 Aider 完成修改并退出前查看,避免漏掉重试产生的消耗。
输入 Token 还受 Prompt 长度影响。本文 Prompt 很短,只写了函数拆分、类型标注、docstring 和不要改测试文件。如果 Prompt 写得很长,比如附带设计文档、接口说明、代码规范,输入 Token 会明显增加。做 Token 评测时,最好把 Prompt 固定成文件,不要每次手敲,也不要临时加要求。
3.3 耗时波动来自哪里
总耗时波动比 Token 波动大,原因有几个。第一是网络往返。Aider 需要把请求发到统一 API 通道,再等待模型返回。网络抖动、服务端排队、DNS 解析都会影响总耗时。第二是模型生成速度。输出 Token 越多,生成时间越长。第 3 次输出 Token 最多,总耗时也最长,符合这个规律。第三是 diff 应用和本地写入。Aider 收到模型输出后要解析 diff、应用到文件、运行语法检查,这些步骤也会耗时。
Aider 的 diff 模式对耗时影响很大。如果模型输出的是标准 diff,Aider 可以快速应用;如果输出格式偏离,Aider 需要重试或让模型重新生成。重试一次可能增加十几秒。本文三次都没有出现明显重试,所以耗时差异主要来自网络和输出长度。第 2 次耗时最短,输出 Token 也最少,说明这次模型生成的 diff 更紧凑。
测试运行也会占时间,但测试是 Aider 退出后单独跑的,不计入总耗时。总耗时只统计 Aider 进程本身。如果你把测试也放进循环,耗时数字会变大,而且测试时间会掩盖模型调用时间。做对照表时,最好把“模型调用耗时”和“本地验证耗时”分开记录。本文表格只记录 Aider 进程耗时,测试结果单独一列。
还有一点,Aider 启动时会加载配置、读取仓库、构建 repo map。这些本地操作也会占用几秒。不同机器磁盘速度、Python 版本、Aider 版本都会影响启动时间。如果你的耗时明显高于本文,先看是不是 repo map 太大,或者 Aider 在启动时扫描了过多文件。把实验仓库保持干净,只放必要文件,能减少启动开销。
4. 复现 Aider Python 重构时 401 与 404 怎么排
复现本文对照表,关键是把 Aider 配置、Key、Base URL、模型 ID 四件事分开确认。很多报错看起来像“模型不行”,其实是配置写错。401 通常是 Key 问题,404 通常是 Base URL 或模型 ID 问题。下面按复现步骤和排障顺序写,尽量让你一次跑通。
4.1 完整复现步骤
第一步,准备仓库。新建目录,放入 src/orders.py、tests/test_orders.py、refactor_prompt.txt,初始化 git 并提交初始版本。第二步,创建 Key。去带 UTM 的官网创建 YOUR_API_KEY,确认模型广场里有你要用的模型 ID。第三步,写 .aider.conf.yml,Base URL 填 https://taotoken.net/api,模型写 openai/YOUR_MODEL_ID。第四步,安装 Aider,确认 aider --version 可用。第五步,运行 aider --config .aider.conf.yml --message-file refactor_prompt.txt --yes src/orders.py。
第六步,Aider 完成修改后输入 /tokens,记录输入、输出和总 Token。第七步,输入 /exit 退出。第八步,跑 pytest -q,确认测试通过。第九步,git diff src/orders.py 检查重构结果。第十步,git reset --hard HEAD 和 git clean -fd 恢复初始状态,重复第二到第九步,共 3 次。把三次的输入 Token、输出 Token、总耗时、测试结果填进表格。
为了让耗时更可比,建议每次运行前关闭其他占用网络的任务。Aider 的自动确认模式用 --yes,如果你的版本不支持,可以查 aider --help 找对应参数。不同版本的 Aider 参数名可能变化,配置文件键名基本稳定。本文不写死 Aider 版本,因为版本差异会影响 repo map 和 Token 统计。你用 aider --version 记录自己的版本即可。
4.2 401 与 404 的配置错
401 一般表示 Key 无效或没有带上。检查 .aider.conf.yml 里的 openai-api-key 是不是 YOUR_API_KEY 占位符没替换,或者环境变量 OPENAI_API_KEY 没有生效。Aider 读取配置的优先级可能因版本而异,如果文件里是占位符,环境变量里是真 Key,Aider 可能仍然用文件里的值。最稳妥的做法是文件里只写占位符,运行时用环境变量覆盖,或者直接把真实 Key 写进本地不提交的文件。
404 一般表示请求路径不对。最常见的原因是 Base URL 多写了 /v1。本文要求 Base URL 填 https://taotoken.net/api,末尾不带 /v1,也不带 UTM。如果你写成 https://taotoken.net/api/v1,Aider 可能请求到不存在的路径,返回 404。另一个原因是模型 ID 写错。Aider 的模型名格式是 openai/<model-id>,<model-id> 必须从模型广场复制。如果你凭记忆写了一个不存在的 ID,服务端找不到模型,也可能返回 404 或类似错误。
还有一种 404 是 Aider 把模型 ID 当成了 OpenAI 官方模型名,于是请求了错误的路径。确认 model 字段保留了 openai/ 前缀,并且后面的 ID 与模型广场一致。如果你用的是自定义模型别名,最好直接使用广场 ID,不要在中间加额外命名空间。配置改完后,重启 Aider,输入 /model 确认当前模型。
4.3 模型 ID 以模型广场为准
模型 ID 是配置里最容易写错的部分。不同供应商的模型命名规则不同,同一个模型在不同通道可能有不同 ID。本文不写死具体模型 ID,因为资料包为空,没有可引用的快照。你使用时,去模型广场复制当前可用的 ID,填进 model: openai/YOUR_MODEL_ID。如果广场展示的 ID 带版本号或日期后缀,就完整复制,不要自己裁剪。
售价、折扣和可用模型列表以 TaoToken 展示为准。本文不写具体价格,也不把公开榜单的数字当成售价。Aider 的 Token 统计只反映调用量,不直接等于账单。账单以控制台展示为准。跑完对照表后,去控制台看用量,确认三次调用的 Token 是否与 Aider 的 /tokens 接近。如果差异很大,检查是不是有重试请求没有记录,或者 Aider 的统计口径只覆盖当前会话。
模型 ID 确认后,建议先用模型对话发一条短消息,确认这个 ID 能正常工作。模型对话入口在文末 CTA。确认通过后,再回到 Aider 跑重构。这样可以把模型 ID 错误和 Aider 配置错误分开。如果模型对话能通,Aider 报 404,那问题大概率在 Aider 的 Base URL 或模型前缀上。
5. 跑完 Aider 对照表后:模型对话、Coding Plan 与创建 Key
对照表跑完后,下一步是核对这次评测的调用是否入账,以及把同一把 Key 用到长期开发里。Aider 的 /tokens 是本地会话统计,控制台用量是服务端统计。两边对得上,说明配置和计量都正常。对不上时,先看有没有重试请求、并发请求或脚本之外的调用。Aider 在 diff 应用失败时可能追加请求,这些请求也会产生 Token。
5.1 对照表跑完后怎么对账
打开控制台的用量页面,按时间范围筛选。本文的 3 次运行集中在同一时间段,输入 Token 每次约 12,500,输出 Token 每次约 1,900,总 Token 每次约 14,400。如果控制台显示的总量略高,可能是 Aider 启动时的模型探测请求,或者 diff 重试请求。如果显示的总量低很多,检查是不是 Key 用错了,或者 Aider 实际请求到了别的配置。
对账时不要只看总 Token,也要看输入和输出比例。输入 Token 高是 Aider 的正常特征,因为 repo map 和文件内容都算输入。如果输出 Token 突然远高于输入 Token,可能是模型在长篇解释而不是改代码。如果输入 Token 远高于本文,可能是仓库太大,repo map 膨胀。对账的意义在于建立自己的成本基线,而不是追求和本文完全一样的数字。
模型对话入口可以用来验证模型 ID 和 Key。打开 模型对话,发一条与重构无关的短消息,确认模型能返回。再回到 Aider,用同一个模型 ID 跑一次小改动。如果模型对话正常、Aider 报错,问题在 Aider 配置;如果两边都报错,问题在 Key 或模型 ID。
5.2 Aider 长期重构的 Key 管理
如果你打算长期在 Aider 里做 Python 重构,Key 管理要提前规划。不要把 Key 写进提交到 git 的配置文件。用环境变量或本地 .env,并在 .gitignore 里排除。团队协作时,每人用自己的 Key,或者用统一的 Coding Plan 分配额度。Coding Plan 入口在文末 CTA,适合需要长期跑 Agent 的场景。创建 Key 的入口也在文末,可以按项目建多个 Key,方便分别统计用量。
Aider 的配置文件可以按项目覆盖。项目根目录的 .aider.conf.yml 写 Base URL 和模型 ID,用户目录的配置写默认值。这样切换项目时不用改全局配置。模型 ID 变化时,只改项目配置。Key 用环境变量注入,不在配置文件里写死。运行 Aider 前,确认当前 shell 的环境变量指向正确的 Key。
长期使用时,还要注意 Aider 的 repo map 和上下文窗口。仓库越大,输入 Token 越高。可以按任务缩小 Aider 的工作目录,只把相关文件加进去,减少无关上下文。重构任务通常只需要少数几个文件,不需要把整个仓库都塞给模型。用 --map-tokens 控制 repo map 预算,或者用 --no-map 关闭 map,都能降低输入 Token。
5.3 用同一把 Key 复现对照表
如果你要复现本文的对照表,最省事的路径是:先创建 Key,再把 Base URL 填成 https://taotoken.net/api,模型 ID 从模型广场复制,Prompt 固定成文件,连续跑 3 次。跑完后用 模型对话 确认模型 ID 与广场一致。长期开发可以看 Coding Plan。Key 在 控制台 创建;Claude Code / CC Switch 三件套对照 接入文档。
复现时不用追求和本文一模一样的 Token 数。同一把 Key、同一个 Prompt、同一个初始文件,每次跑出来的数字本来就会有波动。重点是把输入 Token、输出 Token、总耗时和测试结果记录下来,形成自己的基线。下次换模型或换 Aider 版本时,用同一套方法再跑一次,就能看出差异来自模型、配置还是仓库大小。本文的对照表只代表一次本地运行,公榜数字需要另找带来源的快照,不能和本地表混在一起。
🚀 告别海外账号与网络限制!稳定直连全球优质大模型,限时半价接入中。 👉 点击领取海量免费额度




被折叠的 条评论
为什么被折叠?



