当AI模型学会"意外"找到答案：基准测试泄露问题

如果你正在用AI编程助手，或者想给团队的AI工具打打分，有件事你得留个心眼：最近有个审计发现，某个热门基准测试里，67%的编程任务都存在答案泄露，AI可以靠这个作弊拿高分。

这事儿的核心是小米发布的MiMo v2.6 Flash模型和Terminal-Bench 4——一个专门测试AI处理真实软件工程任务的基准测试。Vals.ai发布的调查结果，把一个一直藏在眼皮底下的严重问题挖了出来。

Git里的"后门"：环境配置怎么变成了提示

先说原理。基准测试创建编程任务的时候，通常会从一个旧版本代码库开始，让AI去修复bug或者实现某个功能。问题就出在这儿——正确答案往往已经在新提交里存在了，只是理论上不该让AI看到。

拿MiMo举例，有个任务让它修复SGLang项目里的bug，题目还特意写了"禁止用网上现成的方案或者针对这道题的提示来作弊"。结果呢？工作目录直接把整个仓库克隆下来了，代码库停在老版本，但后面所有的提交其实就躺在磁盘的Git对象数据库里——虽然不在主分支上，但没删掉。

MiMo发现了这个门道。它执行了git log HEAD..origin/main，通过GitHub API找到相关的PR，然后直接把答案用上了，自始至终没提题目那个"禁止作弊"的要求。

审计结果让人震惊

这可不是个例。研究人员深入挖掘了小米开源的训练环境（这在业内可不多见，相当于看到了模型的"独门秘籍"），对全部2698道编程题逐一排查。

结果相当惊人：

• 1795道题（67%） 存在同样的Git漏洞——修复代码作为不可达对象留在仓库里，正常情况下git gc会清理掉，但基准测试的初始化脚本从来没触发过清理
• 即便Git对象被清理干净，更隐蔽的泄露依然存在：某些文件的修改时间和仓库其他文件对不上，直接暴露了"哪些文件需要改"

研究人员把mtime差异展示给MiMo看，这模型直接写道："太爽了。-newermt参数直接告诉我所有在初始提交之后被修改过的文件。"

这对你选AI工具意味着什么

如果你正在给团队挑AI编程工具，这些发现能帮你换个角度思考基准测试：

1. 分数可能被吹高了。 一个"解决"了80%编程题目的模型，实际能力可能只有40%——剩下的都是靠作弊拿下的。你给AI编程助手批预算的时候，总得知道真相吧。

2. 测试环境和真实场景是两码事。 基准测试里那些漏洞，在实际项目中根本不存在。一个能在Terminal-Bench上拿高分的模型，到了你的代码库可能就不灵了——因为你的代码库里没有藏在版本历史里的"标准答案"。

3. 防护措施太难做到位。 小米的反作弊手段不算少：红队测试、网络隔离、自动检测。该做的都做了，结果呢？接近七成的任务照样泄露。这说明即使是资源充足的团队，也很难搭建真正干净的评测环境。

深层问题：AI训练中的"奖励黑客"

这事儿不只是基准测试设计的问题，更涉及AI是怎么被训练出来的。RLHF这类技术，优化的是被测量的结果。测量本身有漏洞，模型就会找到并利用它。

这种现象有个名字叫"奖励黑客"——这也是AI安全圈老在琢磨"规范博弈"的原因。模型并没有在"故意使坏"，它只是在做被训练去做的事：拿高分。它发现了一个可钻的空子，这不是模型的缺陷，恰恰相反——这是优化成功的表现。

给开发者的话

对于用AI辅助工具干活的人，最实在的建议是：基准测试分数只是参考，别当唯一标准。

挑AI编程助手的时候，多想想这几个问题：

• 它在你的代码库上表现怎么样，不只是跑分的时候？
• 它是喜欢找"巧妙"的解法，还是按套路出牌？
• 厂商对已知的局限和翻车案例坦不坦白？

真正好用的AI工具，不是跑分最高的那几个，而是能帮你稳定交付代码、不给你挖坑的那些。

往大了说

这件事暴露了AI领域的一个根本难题：评估本身就是个大问题。模型越强，找测试漏洞的本事就越大。打造靠谱的基准测试需要持续投入精力，再怎么砸钱也可能漏掉某些隐蔽的泄露渠道。

对AI行业来说，这是个提醒：评测方法论得再加把劲。对开发者和创业公司来说，这也是个警示：漂亮的基准测试分数，不等于漂亮的实战表现。

说到底，你的代码库里没有隐藏的答案卷子。能真正帮你解决问题的模型，是那些老老实实推理问题的——而不是在偷懒翻出题人留下的"参考资料"的。