双模型编程实测：省下费用后仍卡在流程

便宜 25 倍的模型接手编码，任务却没有跟着变快。作者让 Claude 负责规划和审查，让 Xiaomi 的 MiMo-V2.6-Pro 写代码，跑了两周后发现：拖慢交付的，不只是模型生成速度，还有等待审查、重复检查和返工。

这次实验值得看的，是作者把成本和耗时拆开了。对正在尝试「强模型指挥、便宜模型执行」的程序员来说，它回答了两个实际问题：钱究竟省在哪里，时间又漏在了哪里。

52 分钟的任务，模型只忙了不到一半

作者在 2026 年 10 月 11 日至 23 日间，向自己的 14 个仓库派发了 95 个工单，其中 62 个完成合并。任务大多是 Python，不能直接当成前端开发的成绩单。

流程由作者编写的约 10,000 行标准库 Python 调度器负责：Claude 写工单，MiMo 在独立的 git worktree 和分支里实现、运行项目检查，再由 Claude 审查 diff，决定返工或本地合并。macOS seatbelt 沙箱限制执行端只能写对应 worktree，推送仍由作者把关。

已合并任务从派发到合并的耗时中位数是 52 分钟，MiMo 实际工作的时间不到一半。作者能完整重建其中 33 个任务的时间线，另外 4 个跨夜任务被排除。

首次审查就通过的任务尤其能说明问题：MiMo 工作中位数为 16 分钟，端到端却用了 42 分钟。

多出来的 26 分钟，大部分花在调度器没有查看队列上。原来的指令要求执行 sleep 595，醒来再检查、审查、合并。这原本是为了节约 Claude token，却让执行端每次完成后，都可能空等近 10 分钟。合并还要 rebase 到最新代码，并重跑完整测试。

模型已经交卷，流程却还在睡觉。

作者也比较了 MiMo 和自己 Claude Code 记录中的 Claude Opus 5.5 调用。典型调用速度接近，MiMo 的慢调用更慢，拉高了平均值；一次 MiMo 尝试的调用次数中位数是 37 次，耗时中位数是 15 分钟。但两边任务不同，这只能粗看速度，不能证明质量相当。

省下的钱，要看缓存读取和上下文

62 个合并任务中，MiMo 执行侧按公开标价折算共花费 $14.22；同样的 token 若套用 Claude Opus 5.5 价格，则是 $355。按作者实际 token 构成计算，价差约为 25 倍。

这里最关键的数字是：97.8% 的 token 属于缓存读取，输出只占 0.56%。

代理每次调用都要重新读取上下文，因此总量更接近「调用次数 × 上下文大小」，而不是代码行数。比较这种工作流，缓存读取单价往往比输出单价更有参考价值。

单个合并任务的费用中位数，MiMo 为 $0.17，同量 token 按 Opus 价格折算为 $3.83。即使经过 4 轮及以上审查，MiMo 执行侧仍便宜很多。

上下文长度还会放大差异。MiMo 每个任务从独立 worktree 开始，上下文约为作者长期 Claude 会话的三分之一。作者据此推测，如果直接在原有规划会话里让 Claude 实现，费用还会更高，但这部分没有实际对照账单。

调度端同样会消耗昂贵 token：一个 300K-token 的 Claude 会话轮询 10 次，仅反复查看任务有没有完成，就可能读入 3M token。

这些金额都不是实际付款。作者使用订阅，标价只是比较尺子；价格核对日期为 2026 年 10 月 25 日，MiMo 取自 OpenRouter，Anthropic 取自其定价页。Xiaomi 的 Token Plan 页面没有说清缓存命中如何占用月度额度，不能直接把 25 倍价差理解为订阅能多用 25 倍。

首轮通过率只有 39%，返工暴露了什么

62 个合并任务里，只有 24 个首次审查通过，占 39%；其余需要再来 1 至 6 轮。每多一轮，就多一次实现、审查和等待。

作者整理出的反馈集中在五类：

• 失败被当成成功，例如缺少列、join 匹配到零行、找不到按钮，却继续返回成功。
• 数据边界处理不足，例如重复行、日期两边分别是 object 和 str，以及 pandas 把 NA、NULL 股票代码读成 NaN。
• 测试缺少约束力，例如只检查固定标题、写进仓库真实输出目录，或在 60 秒限制下运行了 113 秒。
• 新行为没有测试，或者操作手册仍在描述旧行为。
• 匹配条件过宽，例如 selected 也命中 unselected，或者直接点击页面第一个 OK 按钮。

作者认为，这些问题并不难处理，只是工单没写，执行模型也没有主动寻找。他把更强模型的部分价值归结为：更经常主动补查遗漏。这是经验判断，原文没有同任务对照来证明。

针对这些损耗，作者派发了三项改动：用状态变化后立即返回的阻塞等待命令替换 sleep 595；检查通过后自动启动 Claude Sonnet 审查；把五类问题写进自查提示，并要求工单包含 Failure modes。

自动审查采用 headless restricted mode：没有 shell，文件读取限制在审查 worktree，也没有 MCP servers。但审查器在沙箱外运行，相关改动仍用了 9 轮；连续 4 轮发现仓库内文件可以经由 PATH 被执行，最终作者移除了 PATH 查找。这个任务消耗 127M token，MiMo 标价约 $1.02；同量 token 按 Opus 价格折算，会超过前面全部 62 个任务的 MiMo 费用。另两项改动均在两轮审查后合并。

我的判断

我认可作者先查流程空档的思路。生成速度只是交付时间的一部分，队列、审查和合并检查都可能吃掉省下来的时间。只盯模型响应快慢，很容易优化错地方。

但「便宜 25 倍」的适用范围要收窄：这是已合并任务的 MiMo 执行侧标价比较，没有包含 Claude 规划、审查和轮询的完整成本，也没有给出全部 95 个工单的总投入。62 个合并结果说明方案能工作，尚不足以证明它全面优于 Claude 独立完成。

这也是单人、14 个仓库、两周、主要使用 Python 的经验。与复杂调度器相比，普通团队可以先在现有 CI 和审查流程里记录时间、补足工单，再决定是否增加自动路由。

作者希望把首轮通过率从 39% 提到约 60%，并把典型任务缩短 20 至 25 分钟。这仍是目标，不是已经验证的收益。

能拿来做什么

• 给 AI 编程任务记录派发、开始执行、检查完成、审查开始和合并时间，先分清等待与执行各占多少。
• 在工单中补上失败条件和验证办法，例如按钮不存在时如何报错、选择器如何避免误匹配、新行为由什么测试覆盖。
• 比较模型成本时，同时查看缓存读取、调用次数和上下文长度，并把规划与审查模型的消耗算进去。
• 如果已有轮询调度，优先尝试状态变化通知；自动审查和合并后的完整检查仍应保留。