同一份代码审计任务，MiniMax M3 花了 0.07 美元找到 13 个问题，最贵的 Claude Opus 4.8 max 花了 3.39 美元也只找到 15 个——便宜模型正在逼近专有模型的能力边界，这个趋势值得每个重度使用 LLM 的开发者认真对待。
引言
大模型的定价，一直有一道隐形的逻辑：贵的就是好的，好的就该贵。这个逻辑最近开始松动。Kilo 上周发布了一次测试：用同一份预埋了 17 个已知问题的 webhook 服务代码，分别让 Claude Opus 4.8 和 MiniMax M3 做代码审计，记录每次运行的费用、耗时和发现问题数。结果有点让人意外——MiniMax M3 花了 0.07 美元，找到了 13 个问题；最便宜的一档花了 1.30，同样找到 13 个；最贵的 max 档花了 3.39，也不过找到 15 个。价格差了将近 50 倍，能力差了 2 个问题。
测试者并没有亲自用过 MiniMax M3，所以无法给出直接的使用体验。但 Claude Opus 从 4.7 升到 4.8 的实际感知并不明显——也许任务场景不同，也许差异在日常场景里还没体现出来。有实际使用经验的读者，欢迎在评论区聊聊效果，这有助于验证结论在更广场景下的成立程度。
测试是怎么设计的
Kilo 的测试设计有一个值得关注的细节：被审计的代码库不是随机找的，而是他们自己写的——一个用 TypeScript、Bun 和 SQLite 实现的 webhook 投递服务，接收事件、存储并向订阅者投递带签名的 payload。更关键的是，他们在代码里故意留了 17 个已知问题，覆盖安全、可靠性、正确性和测试覆盖率四个维度，然后用这份清单作为答题本，逐一核对每次审计报告。
每次运行使用相同的 prompt：
工具统一用 Kilo Code CLI，每次独立会话，不共享上下文，跑完记录 token 数、费用和耗时。
Claude Opus 4.8 跑了四档推理强度：medium、high、xhigh、max。MiniMax M3 没有同等的推理强度控制，只跑了一次默认设置。评分规则也很严格：某个问题必须被明确列为独立发现才算，部分提及不计数。
这个设计的好处是排除了大量干扰变量——输入固定、工具固定、评分标准固定，唯一变量就是模型和推理强度。结论因此可比，也因此刺眼。
数字说话
五次运行，结果如下：
| 模型 | 发现问题数 | 费用 | 耗时 |
|---|---|---|---|
| MiniMax M3 | 13/17 | 0.07 | 5m 03s |
| Claude Opus 4.8 medium | 13/17 | 1.30 | 3m 53s |
| Claude Opus 4.8 high | 13/17 | 1.93 | ~4m 30s |
| Claude Opus 4.8 xhigh | 15/17 | 2.03 | 7m 26s |
| Claude Opus 4.8 max | 15/17 | 3.39 | 9m 24s |
MiniMax M3 的 token 用量也更少——比 Claude Opus 4.8 medium 少了 41%，比 xhigh 少了 53%。价格差来自两头：token 少，单价也低。
最让人意外的不是 M3 便宜，而是 Claude Opus 4.8 max 的表现。它是最贵的一档，比 xhigh 多花了 67%，耗时将近 10 分钟，但发现的问题数和 xhigh 完全一样——而且还漏掉了一个 xhigh 抓到的问题。多花的钱，没买到更好的报告。
如果按「每发现一个问题的费用」来算，MiniMax M3 的性价比遥遥领先，Claude Opus 4.8 max 垫底。
推理档越高，不一定越好
Claude Opus 4.8 的四档推理强度，结果没有呈现一条直线上升的曲线——这是这次测试里另一个值得细看的发现。
medium 和 high 都找到了 13 个问题，从 medium 升到 high，token 只多了 6%，费用却多了 48%，发现数没有任何变化——钱花出去了，什么都没多找到。
从 high 升到 xhigh 才算买到了东西：token 多了 17%，费用只涨了 5%，发现数增加了 2 个，是四档里性价比最好的一跳。但 xhigh 升到 max 就又掉回来了——token 数量甚至略有下降，费用却猛涨 67%，发现数纹丝不动，还丢了一个 xhigh 找到的问题。
更有意思的是 medium 和 high 抓到了一个 xhigh 和 max 都漏掉的 bug：async callback 跑在了 synchronous transaction 里面。推理强度越高，模型花的注意力越多，但注意力的分配方向变了——它在更深的地方挖，却可能错过了某些表层问题。
Kilo 在报告里写道：
这个结论对日常使用有直接的参考价值：如果你的任务是全面覆盖，不一定要拉满推理强度；如果你想要最高性价比的 Claude 单次审计，xhigh 是目前最合理的选择，max 基本没有理由用。
MiniMax M3 漏掉了什么
13/17 意味着有 4 个问题没有被找到。Kilo 的报告里，M3 漏掉的三个分别是：
- 无效 JSON 返回 500 而不是 400
- 数据库初始化代码在 import 时执行，而不是在启动时
- event 路由里有一个 async callback 跑在 synchronous transaction 里
值得一提的是，第三个问题（async callback）恰好是 Claude Opus 4.8 medium 和 high 找到、而 xhigh 和 max 也漏掉的那一个——这不是 M3 独有的盲点，更像是高推理强度模型的共同弱点。
这三个问题有个共同特点：它们不是会直接造成安全漏洞或数据丢失的致命问题，更多属于「代码质量和健壮性」层面。相比之下，M3 抓住的那些——返回 stored secret 的接口、签名计算用了不同的字节串、没有认证的路由——每一个都是真正的生产事故隐患。
换句话说，M3 的遗漏是有规律的：大 blocker 全捕到了，漏的是更细的代码实现问题。这不是随机的运气，更像是模型在有限的注意力下做了某种隐式的优先级排序。
对大多数审计场景来说，这个取舍是合理的。如果你的目标是「上线前最后一道安全检查」，0.07 美元能找到全部高危问题，剩下的 3 个小问题靠 code review 补；如果你需要一份完整详尽的质量报告，那才是 Claude Opus 4.8 xhigh 的用武之地。
价格墙正在松动
这次测试的结论，放进一个更大的背景里看会更清楚：便宜模型追赶专有模型的速度，远比我们预期的快。
一年前，能做代码审计的模型基本只有 Claude 和 GPT-4 这一档。现在 MiniMax M3 在这个任务上和 Claude Opus 4.8 medium 打平，费用是后者的 1/18。这不是孤例——Gemini Flash、Qwen、DeepSeek 这些模型在各自的基准测试上也在持续逼近顶级专有模型的水平。
差距仍然存在，但它在收窄，而且收窄的速度比价格下降的速度更快。Claude Opus 4.8 xhigh 比 M3 多找了 2 个问题，但贵了将近 30 倍。这 2 个问题值不值 30 倍的价格，取决于你的场景——但这个问题本身在一年前根本不需要问，因为那时候根本没有能与之相比的便宜选项。
Kilo 在报告末尾也点到了这个趋势：
这句话的重量，比测试数据本身更大。
按任务选模型
Kilo 的测试给了一个很实用的决策框架，不用再凭直觉选模型：
- 大批量或预算有限的审计 → MiniMax M3。0.07 美元，13/17，5 分钟，主要安全问题全覆盖。
- 快速过一遍，要 Claude → Opus 4.8 medium。1.30 美元，同样 13/17，最快，还额外抓到了 async callback in synchronous transaction 这个高档漏掉的问题。
- 要最完整的单次报告 → Opus 4.8 xhigh。2.03 美元，15/17，性价比最好的高档选择。
- Opus 4.8 max → 基本没有理由用。贵 67%，慢 2 分钟，还不如 xhigh。
背后的逻辑很简单：不同任务对「覆盖率」和「成本」的权衡不一样。一次上线前的快速安全扫描，和一次需要归档留存的完整质量审计，本来就该用不同的模型。问题是过去没有便宜的好选项，只能默认用最贵的。现在选项多了，该想清楚自己真正需要什么。
这也是这次测试真正有价值的地方——不是告诉你哪个模型最好，而是逼着你回答：对你的场景来说，「够用」到底是什么水平。
当然，一个任务、一个代码库不足以说明全部——代码审计只是众多场景里的一种，换成代码生成、重构、调试，结论可能不同。但两件事是清楚的：第一，多个模型在多个基准上都指向同一个方向，便宜模型的追赶不是偶然；第二，别人的测试数据只能给你参考，真正有价值的是拿你自己的任务跑一遍，而不是等别人告诉你答案。
参考资料
[1] Kilo: https://kilo.ai
[2] 发布了一次测试: https://blog.kilo.ai/p/we-audited-the-same-codebase-with
[3] Kilo Code: https://kilocode.ai
