章节索引5 个标题 · 点击展开＋
大家好，我是孟健。
在第一道统计接口修复题里，单次花费只要约 0.010 美元的 MiMo Flash 行为测试 36 项全过、类型检查一次通过，定位更高的 MiMo Pro 同样全过，但在生成的补丁质量上并没有拉开明显差距。
平时写代码，我的主力环境是 Codex 配 Claude Code。但做一人公司，精细算账是每天的必修课。面对新发布的 MiMo-V2.6-Flash、MiMo-V2.6-Pro，以及大家常用的 DeepSeek V4.1 Flash，拿来做日常代码补丁修复时该如何取舍，值得用实测数据对照一番。
行业跑分看多了容易眼花，模型好不好用，归根结底得看具体的交付表现。这篇文章我不评选什么“全能总冠军”，而是通过联网 API 获取两款 MiMo 与 DeepSeek 的补丁，再放到本地无网沙箱中执行验收。测试围绕两道真实业务代码题展开，记录实际账单、耗时与测试结果。
01 先看公开分项，别被综合总分一笔带过#
新模型发布，大家最先看到的往往是综合榜单。比如小米发布文章里贴出的 Artificial Analysis（AA）榜单快照，MiMo-V2.6-Pro 拿到了 46 分：
但在代码这件事上，综合分高并不等于补丁修复能赢。如果仔细拆开小米官方披露的分项评测表，局面其实互有胜负：
在偏向终端交互和生成质量的基准上，MiMo Pro 确实亮眼，例如 Terminal Bench 4.0 拿下 34.9（DeepSeek 为 26.8），ProgramBench 拿到 26.5（DeepSeek 为 20.3）。但到了侧重真实软件工程代码修复的 DeepSWE v1.1 上，标示的数据则是 DeepSeek V4.1 Flash 以 74.2 分领跑，MiMo Pro 拿下 71.9，MiMo Flash 为 67.9。
02 搬进隔离沙箱，拿冻结源码考真实边界#
为了做具体对比，我准备了两道冻结的真实产品源码任务。测试没有引入自主 Agent 循环，而是将只读源码挂入无外网 Docker 沙箱，由执行脚本模拟外部依赖；三款模型根据上下文返回标准补丁，沙箱仅负责执行验收，模型本身并非离线运行。
这两道题目的考点并不在于写一个花哨的页面，而在于能否处理好工程边界：
- 第一题：并发统计接口（ShipSolo 仓库）。原始基线通过率只有 16/36。这里面不仅包含请求缓存、并发合并与凭据隔离，还涉及真实公历日期校验（例如闰年与不同月份天数边界）以及错误脱敏；正因日期和跨月边界场景用例覆盖细致，能够清晰反映出模型在边界处理上的疏漏。
- 第二题：无头浏览器渲染（ShipSite 仓库）。原始基线通过率 8/15。主要验收服务端在页面截图遇到超时后的晚到资源清理、关闭失败以及异常退出时的资源回收处理，本次并未对常驻服务的长时间内存指标做实测。
三款模型均通过 AIHubMix 网关接入，保留原生思考（DeepSeek 设为 high，MiMo 保持默认，二者不代表等同的推理算力）。主阶段每题每模型独立生成两次，输出上限统一设为 32768 tokens。生成的候选补丁在沙箱中跑两遍单元测试并执行一次原生 TypeScript（tsc）严格编译。由于测试为小样本且依赖模拟环境，结论不代表生产修改建议。
03 拆解首题交付，拉开差距的是账单与等待#
在第一道并发统计任务的首轮测试中，三款模型生成的补丁均完成了 36/36 项行为测试，并通过了 TypeScript 编译检查。
虽然首轮测试均达到当前的验收标准，但各模型的等待耗时与对应的单次调用账单表现各异：
- DeepSeek V4.1 Flash：耗时约 188 秒，单次账单约 0.024 美元
- MiMo-V2.6-Flash：耗时约 226 秒，单次账单约 0.010 美元
- MiMo-V2.6-Pro：耗时约 494 秒，单次账单约 0.024 美元
这里需要先说明，账单包含当时调用时的特定缓存与路由状态，并不代表各官方固定的定价倍率；而耗时也是包含网关处理的完整等候时间，不能简单等同于引擎纯粹的吐字速度。
在同样通过当前验收的这组样本中，Flash 该次账单费用更低，DeepSeek 带来了较少等待，而 Pro 未在测试通过情况上拉开差距。
值得注意的是，在比对补丁 diff 时，三款模型除了完成题目要求的统计与日期校验，都不约而同修改了一处题外的实时查询异常脱敏逻辑。这种偶发现象提示我们，即便通过了自动化测试，仔细人工审查 diff 依然很有必要。
04 碰壁长输出截断，类型报错后看单轮修复#
来到第二道包含异步清理逻辑的无头浏览器截图题，各模型在交付过程中遇到了不同问题。
在初始的 32k 限制下，第一轮测试就集体遇到了天花板： DeepSeek 跑了 240 多秒，因为触发长度上限（length 截断）交卷失败；MiMo Flash 更是把 32768 个 token 的预算几乎全花在了深度推理思考上，思考占了 32767 个 token，最后只挤出 1 个 token 的答案就戛然而止，没能交出完整补丁。
紧接着用相同配置进行第二次测试，两款模型均拿下了 15/15 行为测试并通过类型检查。在长思考链调用中，两次调用的结果出现了明显差异。
为了排查长思考下的交付情况，我保持原输入不变，统一将输出上限追加至 64k（65536 tokens）并开启流式响应，对每款模型进行了一次诊断测试：
DeepSeek 花了 300 多秒交付，15 项行为与编译全绿。 而 MiMo Flash 虽然用 400 秒交付了补丁，沙箱里 15 项行为测试也同样拿了满分，但在最后一关 TypeScript 编译门禁处被当场拦下。
查看报错信息，问题发生在对已检查的浏览器绑定 env.BROWSER 的处理上：由于未用局部常量固定引用，异步闭包未能保留 TypeScript 的类型收窄，导致严格编译未通过。在要求类型检查的场景下，这份补丁不能算作验收合格。
我把当前的补丁代码连同编译器的报错提示原文原样打包，直接喂回给 MiMo Flash。
随后将报错信息反馈给模型，API 大约 14 秒返回了修改代码。它将校验后的对象赋给局部常量 const 保持类型收窄。放回本地沙箱复验，行为测试通过 15/15，TypeScript 编译也顺利通过。
在公开测试中，Kingy 曾用 OpenCode 测试 MiMo，Pro 取得了 23/23 全通，而 Flash 为 21/23。当时 Flash 漏掉了要求的 summary 子命令，但其自行生成的测试脚本却全部显示通过。需要说明的是，该测试中 Pro 与 Flash 的路由不同，且未同题对比 DeepSeek。
从我的工程实践来看，模型自带的自测容易产生遗漏，不能完全依赖其自我核验。想要摸清代码质量，配置独立的执行环境做行为断言和类型检查是更稳妥的做法。
至于 MiMo Pro，在两题主实验共计四次请求中，仅统计题首轮成功交付，其余三次遇到了一次渠道错误与两次 600 秒超时；在截图题 64k 追加测试中，请求耗时 25 分钟截止时仅输出思考流、未返回正文。由于缺少完整的 usage 数据，尚不能判定具体原因是 token 耗尽、代码生成受阻还是网关异常，这反映出当前小样本测试下的渠道稳定性风险。
05 落地日常流水线，我的实用取舍建议#
跑完这几轮对比，针对日常代码补丁和缺陷修复场景，我的结论很明确：
第一，具备完备测试流程的常规补丁，可以考虑尝试 MiMo Flash。 在这组测试中，MiMo Flash 单次成本约 0.010 美元，调用耗时较短。虽然测试中遇到了一次闭包类型收窄的返工，但在配合明确类型报错重新调用后完成了修复。如果项目本身具备自动化类型检查和单测门禁，它是一个兼顾成本与速度的备选方案。
第二，在本次渠道测试中，DeepSeek 展现了较少的等待耗时。 在当前的网关环境下，DeepSeek 的端到端响应耗时整体较短，其完整生成的候选补丁均通过了 TypeScript 编译。尽管日常使用依然需要执行外部验收，但在这组样本中它的响应相对稳定。
第三，关于 MiMo Pro，建议结合实际任务与所用渠道表现综合评估。 MiMo Pro 在部分公开基准上具备分项优势，但在本次两道题的实测中并未展现出明显优于更小模型的交付效果，且受到了网关超时与错误的影响。建议开发者根据自己的具体任务和渠道表现先行测试，再决定是否承担相应的等待与调用成本。
最后分享两个在代码接入层绝对不要偷懒的实践细节：
一是在网关层关注返回的 `finish_reason`。如果状态为 length，代表生成内容达到了 max_tokens 限制被截断（本次测试中可观察到思考内容占据较多输出）。遇到此类情况，可以根据需要调整 token 预算或拆分任务，并设置好单次费用上限。
二是建立独立的外部验收门禁。正如本次测试中 Flash 在返工前后与沙箱编译器的配合所示，将断言与类型检查放在外部独立运行，能更准确地捕捉模型自我评估容易忽略的漏洞，让日常代码修补更有保障。
Related