2026年第一季度我几乎每天的工作流都是这样的开一个 tmux、切到一个仓库目录、敲aider然后在 TUI 界面里跟模型讨论怎么改代码。去年这时候我还是 IDE 插件党今年彻底回流到终端原因很简单——Aider-TUI 把让模型改代码这件事做成了纯粹的键盘流没有插件加载、没有满屏 diff 弹窗、没有上下文被 IDE 偷偷吃掉。配合 Gemini 3 和 Qwen-Long 这两个定位完全互补的模型一个管日常高强度重构一个管超长上下文审计基本覆盖了我在终端里遇到的所有编码场景。这篇文章就把我的完整装机过程、两个模型的接入方式、实测对比和踩过的坑一次说清楚。1. 2026年为什么是Aider-TUI的大年趋势与模型格局1.1 从IDE插件回流到终端GUI助手暴露的三个问题过去两年大多数人用 AI 编程都在 IDE 插件里装一个 Copilot 或者类似的扩展开启聊天面板选中代码问问题。这套模式在单文件简单场景下确实好用但用到中大型仓库时会越来越别扭。我分析下来主要是三个问题第一GUI 插件的上下文是被框住的。它优先理解你打开的文件、选中的代码但对整个仓库的全局结构感知很弱。做跨模块重构时插件经常只改一个文件剩下的报错留给你自己处理。第二插件界面堆叠了大量交互元素聊天框、代码建议、内联 diff、改动统计挤在一起鼠标操作成本很高没法像终端操作那样全部用键盘完成。第三插件和 Git 工作流是脱离的。改完代码还要手动 review 一堆变更、写 commit messageAI 只负责生成 diff不负责收尾。Aider-TUI 把这三件事统一了。它本身就是跑在终端的结对编程工具直接读 Git 仓库状态模型给出的修改以 diff 形式落地确认后自动提交。这套逻辑天然适合以 Git 为单一事实来源的开发流程也让我可以完全脱离鼠标操作。1.2 Gemini 3 与 Qwen-Long 在2026年模型生态里的站位到 2026 年模型选择的逻辑已经不是哪个聪明用哪个而是按任务形态选模型。Gemini 3 是 Google 这一代的主力编码模型定位是长上下文 高推理质量对多文件的复杂改动、需要前后文一致的重构任务表现很强Pro 版本给足 token 能处理接近百万级上下文的项目。Qwen-Long 则完全走另一条路它是阿里云百炼平台上的超长文本模型主打千万 token 级别的上下文窗口而且单价很低——它不是为了嵌入式开发、不是为了精细重构而生而是为了把整个仓库塞进去并从中提取信息而生。这两种模型放在同一个 Aider-TUI 里恰好形成互补。我的日常写法是默认接 Gemini 3 Flash 跑常规迭代切到 Gemini 3 Pro 做复杂重构遇到要读超大单文件、给老仓库做全局审计、生成跨模块变更说明时就切到 Qwen-Long。Aider 支持模型热切换实际操作其实就是在 TUI 里用/model命令或者重启时换配置资源一点不浪费。1.3 先想清楚该装谁一个简单的判断框架在往下看配置之前我建议你先按这个框架确定自己的主力模型如果你天天改的是业务代码、要做函数级优化、经常依赖模型读懂意图并动手改那 Gemini 3 是主力Qwen-Long 是备用。如果你手头有大量历史代码需要梳理、有几十万行的单体文件需要理解、或者经常要 AI 基于整个仓库存档生成汇总文档那 Qwen-Long 才是你的日抛模型Gemini 3 只在需要精确修改时上场。这个判断会直接影响后面章节的参数配置别跳过。2. 装机清单与最小配置30分钟跑起第一个Aider会话2.1 安装Aider本体pip与uv两条路Aider 是一个 Python 包安装没有任何特殊依赖但前提是系统里有 Python 3.11 或更高版本。我用的是uv安装方式uv tool install --python 3.12 aider-chat aider --version如果没有uv直接用pip也一样python -m pip install -U aider-chat为什么我推荐uv tool因为aider-chat的依赖比较多LiteLLM、pygit、watchfiles 等用独立工具环境可以把它们和系统 Python 隔离不污染你日常开发用的环境。安装完先跑aider --version验证一下能打印版本号就说明环境没问题。2.2 终端准备tmux、SSH、乱码Aider-TUI 走的是标准的终端文本界面理论上任何支持 ANSI 的终端都能跑。但有一点很容易忽略如果你像我一样经常 SSH 到服务器上干活TERM环境变量一定要正确。我会先在 tmux 里开一个会话再在里面启动 aider这样模型跑长任务时不会因为网络闪断丢失整个会话状态。UTF-8 locale 也是必须的否则中文注释和模型输出会乱码。推荐在启动前加一句export LANGen_US.UTF-8 export LC_ALLen_US.UTF-8别小看这两步。我第一次在服务器上装完就跑结果 TUI 边框全是乱码排查了半天才意识到是 locale 问题白白浪费二十分钟。2.3 第一次启动先记住三个命令再干活在还没有配任何模型之前你可以先跑aider进入默认界面它会自动检测当前目录有没有 Git 仓库没有就帮你初始化一个。进入 TUI 之后不要急着问需求先把三个命令记住/add添加文件到会话。支持通配符比如/add src/*.py。Aider 只会修改你 add 进来的文件这是它控制改动范围的核心机制。/help查看当前版本的完整命令列表。不同版本之间的命令差异其实挺大以/help输出为准。/tokens查看当前会话 token 消耗情况。这个命令是你后续做上下文管理的基础参数调没调好全靠它反馈。熟悉这三个命令以后你的 TUI 工作流基本就立住了add 文件、输入需求、看 diff、确认或拒绝、git 提交。2.4 配置文件骨架用 .aider.conf.yml 统一启动参数我不建议每次启动都敲一长串命令行参数尤其是后面要频繁切换模型时。先把配置文件写好。在 Home 目录或项目根目录创建.aider.conf.yml这是我的最小骨架model: gemini/gemini-3-flash edit-format: diff map-tokens: 4096 max-chat-history-tokens: 8192 auto-commits: true notifications: true watch-files: false解释一下几个关键项edit-format控制模型修改代码的方式diff模式适合大多数场景让模型输出精确的 diff 而不是整个文件覆盖map-tokens是给仓库地图预留的 token 预算这个值太小会导致模型对项目结构感知变弱太大又会挤占对话空间auto-commits打开后Aider 每次修改都会自动生成 git commit如果你不喜欢它替你提交可以先改成 false。配置文件生效后启动命令就只剩一条aider干净利落。3. 接入Gemini 3官方API的接入方式与参数调优3.1 密钥准备与模型标识别把pro和flash搞混Gemini 3 在 Aider 里用的是 LiteLLM 的模型命名规则官方 API 模式下通过环境变量传密钥。我推荐用项目级.env文件而不是全局环境变量避免多个项目互相污染# 项目根目录的 .env GEMINI_API_KEY你的Google_API_Key然后启动时指定模型。这里有个关键点Gemini 3 系列有多个变体在 LiteLLM 里的名字大致是gemini/gemini-3-flash和gemini/gemini-3-pro具体的小版本号比如 preview 后缀以当时官方模型列表为准。我的经验是日常迭代用 flash性价比最高只有做大型重构时才切 pro。aider --model gemini/gemini-3-flash如果你已经写了.aider.conf.yml可以用/model在 TUI 里实时切换/model gemini/gemini-3-pro3.2 首次会话验证用一个真实需求测链路配好密钥后第一次会话不要用hello world这种无用测试直接拿一个小但真实的任务验证全链路。我会在任意仓库里 add 一个文件然后输入给这个文件里所有的公开函数补上 docstring说明参数、返回值和可能抛出的异常保留原始逻辑不做其他改动。这一步有三个意义第一验证模型是否能通过 API 正常访问第二验证edit-format是否生效——如果模型回复一大段代码而不是 diff说明格式配置有问题第三验证 auto-commit 是否按预期工作改完有没有自动生成 commit。3.3 实测表现与参数调优thinking token是个隐藏成本Gemini 3 系列默认带思考模式模型会在真正生成代码之前先输出一段内部推理。这在复杂任务上质量提升很明显但代价是 token 消耗显著上升。我在 TUI 里观察/tokens输出时发现一次中等规模的改动思考 token 经常是实际输出代码 token 的两到三倍。如果你的调用量比较大有几个应对方式简单任务尽量用 flashflash 的思考链比 pro 短省 token 明显。把max-chat-history-tokens调大一点避免对话轮次稍多就把前面的上下文挤掉导致模型反复理解文件。edit-format不要用whole用diff可以让输出更紧凑。另外Git 仓库里的非代码文件图片、二进制千万别 add 进会话模型读不了还会占上下文。我在一个含大量图片素材的项目里吃过亏一开始总觉得模型记忆变差后来/tokens一看上下文被无意义内容占了大半。3.4 Gemini 3接入的三个高频坑坑一模型名带后缀导致启动失败。新模型刚上线时API 里带-preview或日期后缀LiteLLM 版本没跟上就会报 model not found。解法是升级aider-chat到最新版或者查官方模型列表手写全名。坑二代理或防火墙导致请求超时。这个往往不是 Gemini 的问题而是网络环境问题。我的经验是先确认curl能否正常到达 API 端点再排查出现所有模型都超时的现象时基本可以断定是网络链路问题而不是 Aider 或密钥问题。坑三长任务看起来卡住了。模型处理大 diff 时 TUI 会长时间停在waiting for API...状态这是思考模式在跑长推理不一定死掉了。别急着 CtrlC观察两分钟确认是等待还是真超时。4. 接入Qwen-Long把超长上下文用对地方4.1 为什么选OpenAI兼容端点接入路径最短Qwen-Long 是阿里云百炼平台上的模型官方给了一套 DashScope API同时也提供了 OpenAI 兼容模式的端点。对 Aider 来说走 OpenAI 兼容模式是最省事的路径Aider 原生支持--openai-api-base这相当于告诉它你把所有 OpenAI 协议请求发到这个地址。适配成本几乎为零不需要任何额外插件。4.2 模型标识与API基址配置启动命令从技术上讲就一条export DASHSCOPE_API_KEY你的百炼密钥 aider \ --openai-api-base https://dashscope.aliyuncs.com/compatible-mode/v1 \ --openai-api-key $DASHSCOPE_API_KEY \ --model openai/qwen-long这里有个容易踩的坑模型名前缀必须用openai/而不是qwen/。因为 Aider 判断用哪套协议请求是看前缀的openai/前缀自定义--openai-api-base才会走兼容端点。如果写成qwen/qwen-long大部分版本会尝试走直连接口导致认证失败或模型名不识别。为了不用每次敲三条命令我会在.aider.conf.yml里加一个注释掉的分段# ---------- Qwen-Long 模式 ---------- # model: openai/qwen-long # openai-api-base: https://dashscope.aliyuncs.com/compatible-mode/v1切换到 Qwen-Long 时把注释解开把 Gemini 那几行注释掉即可。4.3 用model-settings声明超大窗口不声明就白搭Aider 在不知道模型元信息时会按一个比较保守的通用配置来分配上下文默认可能只有几万 token。Qwen-Long 真正厉害的是千万 token 级窗口但你不告诉 Aider 它是谁它就当普通模型用长上下文优势完全发挥不出来。解决办法是给 Aider 提供一份模型设置文件我用models.json存到项目根目录{ openai/qwen-long: { name: qwen-long, max_context_tokens: 10000000, max_output_tokens: 8192, edit_format: diff } }然后在启动时指定aider --model openai/qwen-long --model-settings-file models.jsonmax_context_tokens我建议填模型的真实能力上限。你可能会担心窗口太大导致代价高但实际上 Qwen-Long 本身按 token 计费单价很低长窗口跑一次审计任务的成本通常比 Gemini 3 Pro 跑一次同量级短任务还便宜。4.4 超长上下文场景Qwen-Long真正发光的地方实测下来Qwen-Long 在下面几类任务里是别的模型没法比的超大单文件理解。我服务器上一个遗留的 PHP 文件有两万多行Gemini 3 Flash 勉强能读但迭代两轮后上下文就撑爆了。Qwen-Long 整包塞进去毫无压力你甚至可以同时再塞几个相关文件。全局变量与配置审计。给老仓库生成一份所有环境变量在哪些地方被使用的清单这个任务信息密度高、逻辑简单非常适合长上下文模型做信息提取。变更说明和架构文档生成。让模型基于整个仓库存档写一份维 README 或模块关系图Qwen-Long 最擅长这种量大但不用深度推理的活。4.5 Qwen-Long的弱项规避它更适合读而不是改要直说一个事实Qwen-Long 不是代码生成专用模型它做精细重构时常常给不出 Gemini 3 级别的精准 diff。它的强项是检索和理解弱项是零误差的代码编辑。我现在的用法是审计用 Qwen-Long执行用 Gemini需要理解全库信息时让 Qwen-Long 输出一份带文件路径和行号的分析报告然后把这份报告当提示词切到 Gemini 3 Pro 去真正改代码。这里还有一个实操细节给 Qwen-Long 的任务指令一定要结构化。比如列出所有调用 XX 函数的位置并判断哪些存在空指针风险按风险等级排序输出 Markdown 表格比分析一下这个项目的安全性结果好十倍。它在超大上下文下不会聚焦目标指令越明确输出质量越高。5. 双模型实战对比同一仓库、同一任务、同一个TUI5.1 测试任务设定既要改代码又要看全局为了公平对比我在一个中型 React TypeScript 仓库约 80 个文件上做了一个双模型测试任务目标是把散落各处的表单校验逻辑抽到 service 层同时给仓库补一份 README 说明模块结构。前者考验精细重构能力后者考验全局理解能力两个任务放在同一个 Aider-TUI 会话里连续执行记录关键指标。5.2 对比结果Gemini 3 Pro vs Qwen-Long对比维度Gemini 3 ProQwen-Long首次理解任务准确度很高能跨文件理解调用关系中上对单文件理解准确跨文件联动较弱Diff 精准度精准少冗余改动能主动保持风格一致一般重构类改动需要多轮纠正全局检索能力强但上下文受限后精度下降极强超大窗口可以把全部源码塞进上下文上下文消耗高思考 token 拖累明显低即使处理长文件也相对从容响应速度快尤其 flash 版本中速处理长 prompt 时首 token 延迟较长综合成本中高低同量级任务仅为前者几分之一5.3 数据背后的三个结论结论一日常迭代别用 Pro。我在测试里发现日常小改动补类型、修 bug、写注释用 Gemini 3 Pro 和 Flash 的结果差别不大但 Pro 的思考 token 消耗翻倍完全不划算。Pro 留给真正的硬骨头。结论二Qwen-Long 在跨文件重构上需要人肉导航。它在拿到精确的文件路径和明确的改动指令时可以完成稳定修改但如果你只给一个笼统目标它容易在某个文件里过度修改产生不必要的变化。这不算错误而是模型定位决定的——它是读多写少的模型。结论三两个模型组合比任何一个单独用都舒服。实际操作中我会让 Qwen-Long 先分析仓库依赖关系给出哪些文件涉及这个校验逻辑的清单然后按这份清单去问 Gemini 3 Pro 做具体改动。这样既利用了 Qwen-Long 的全景视角也保留了 Gemini 3 的精准编辑能力。5.4 根据结果给出选型建议如果你只愿意花五分钟做决定我的建议是这样的日常主力直接上 Gemini 3 Flash改代码质量足够、速度快、成本低。遇到大型重构或逻辑推理要求高的任务临时切到 Gemini 3 Pro。如果你的项目中存在超过一万行的大文件或者经常需要基于全仓库做信息提取那无论主力是谁Qwen-Long 都应该作为第二个模型常备在 Aider 里。6. 进阶Aider-TUI的开箱效率清单与四个高频坑6.1 TUI操作效率把鼠标彻底扔了Aider-TUI 的界面可以完全用键盘操作。我日常最常用的操作串是/add添加文件、输入需求回车、看 diff、按接受或拒绝、然后继续下一轮。如果改错了马上/undoAider 会把最后一次改动回滚并生成一个相反的 commit。/diff可以随时查看当前会话中尚未提交的改动。整套流程下来我基本不碰鼠标思维链路不会被 UI 打断。还有一个值得养成的习惯会话开始先/clear清空上一轮的历史。Aider 的上下文是连续累加的上一轮的讨论会一直留在窗口里占用 token。开新任务不清理后续的回复质量会显著下降。每次切换任务就把会话重启一次上下文干净模型表现也稳定。6.2 上下文管理策略两个参数决定体验上限我强烈建议每个用户都理解两个参数它们共同决定 Aider 在你的仓库上的体验上限map-tokens仓库地图占用的 token。值越大模型对项目的整体结构越清楚但对话空间越小。中小型项目设 4096 够用大仓库可提到 8192。max-chat-history-tokens保留多长的对话历史。默认值在长任务中往往不够设成 8192 到 16384 比较合理否则前面的需求细节会被截断模型失忆。不要盲目把这两个值调到极大它们是此消彼长的关系。我在一个大型 monorepo 里试过同时拉满两个参数结果聊天轮次稍多就把整个上下文撑爆。正确的做法是先用/tokens观察实际消耗再针对项目规模调整。6.3 四个高频坑每一条都是我实际踩过的坑一auto-commit 导致的提交信息混乱。Aider 默认自动提交生成的信息有时过于笼统比如Refactor code。如果项目需要规范的 commit message我建议关掉 auto-commits手动审查 diff 后用/commit 信息提交。坑二API Key 泄露。把密钥直接写在.aider.conf.yml里是危险的因为这个文件通常会进版本控制。我全部改用.env方案并在.gitignore里加入.env和models.json如果里面含个人信息。坑三模型标识错误导致的隐性问题。接入 OpenAI 兼容模型时有些人图省事直接用openai/gpt-4o覆盖基址结果 Aider 用 GPT-4o 的元信息去估算 token 上限实际模型是 Qwen-Long窗口被错误限制长上下文优势消失。正确做法是像 4.3 节那样单独声明模型元信息。坑四会话里混入无关文件。一次会话里 add 的文件越多上下文稀释越严重。我见过有人把整个 src 目录都 add 进去结果模型每个问题都要穷举所有文件响应又慢又差。记住 Aider 的哲学只 add 与当前任务相关的文件需要全局视角时用仓库地图map而不是全量 add。7. 最后说几句实在话这个组合值得你花一个下午搭好拿我实际体验来说Aider-TUI 加 Gemini 3 加 Qwen-Long 这套组合已经是 2026 年我在终端里效率最高的 AI 工作流。Gemini 3 Flash 负责日常编码迭代Pro 在关键时刻顶上Qwen-Long 承担所有把整座仓库读一遍的苦力活。三者都是通过标准化 API 接入Aider 把它们收进同一个 TUI 界面操作上的切换成本极低。一个值得留的备份习惯models.json和.aider.conf.yml最好跟着你的 dotfiles 仓库走换机器之后几分钟就能恢复完整环境不用重新摸索一遍配置。我的取舍经验是不要在配置阶段追求完美把默认配好、能跑起来然后根据/tokens的反馈逐步调优——这比一开始就折腾各种高级参数要高效得多。