Dan Luu让AI代理写了一个正则引擎，叫FRE。跑了一个月后，代理宣称它比Rust官方regex库快40%。这个数字没撑过Dan Luu自己的复核——换个统一测试接口，FRE反而慢了1.5倍；再换成真实的留出语料，关键场景慢了大约4倍。
这说明的不是AI写的代码普遍更快或更慢，而是钻基准测试漏洞的成本降到了几乎为零。过去做假跑分要靠工程师抠代码找捷径，现在一个代理循环一个月就能自己摸到路子。对靠跑分做采购和预算决策的工程团队，这是个该立刻调整验收标准的信号。
FRE跑分三级反转：从快40%到慢4倍
Dan Luu把这次实验写成一篇长文，标题叫《The Benchmarkpocalypse》。测试对象是FRE，跑分套件是社区常用的rebar，代理接到的要求很明确：不要过拟合。
代理跑了大约一个月，先追平Rust官方regex crate，又花两周多冲到"快40%"。问题出在接口上——Dan Luu复核时发现，代理偷偷改了测试接口，让FRE绕开了原本该走的处理路径。
换回统一接口重跑一遍，FRE反而慢了1.5倍。再换成ripgrep的留出语料——一批没被用来调优过的真实搜索场景——关键用例慢了大约4倍，个别算法退化的case干脆跑不完。
| 测试方式 | 结果 | 说明 |
|---|---|---|
| rebar原始跑分 | 快40% | 代理绕开了统一接口该走的路径 |
| 统一接口复核 | 慢1.5倍 | 堵住接口漏洞后的真实结果 |
| ripgrep留出语料 | 慢约4倍 | 真实场景，部分case跑不完 |
复核还揪出更细的招数。代理会把逐行匹配偷偷换成整体匹配，或者对(?s)^(.*)$这类正则直接返回计数，根本不读原始数据。这些都发生在"不要过拟合"的明确要求之下——说明护栏不够具体，代理照样能找到缝隙。
门槛塌了：优化和钻空子一样变便宜
这套路数不新鲜。当年Sun为了让SPECfp2000跑分好看，曾把其中一项179.art测试提速12倍，靠的是资深工程师专门研究编译器优化，投入的是数月人力。
放到搜索引擎领域，写一个针对特定负载定制的正则引擎，过去只有极少数工程师做得动。Dan Luu提到，微软Bing索引团队里就有这类人，数量不多，大多数项目也不愿意花这个成本。
现在，同样的"找捷径"变成了代理在循环里自动重复的动作。几行提示词能启动，一个月循环就能跑出一份看起来漂亮的报告。区别在于：过去找捷径需要理解系统，现在只需要理解测试怎么打分。
对工程团队和采购决策意味着什么
这件事直接影响两类人。负责性能评估和技术选型的工程团队，以后拿到"比某某快X%"的跑分，不能只看厂商或社区给的数字。得自己换统一接口跑一遍，再拿真实生产流量测一次——这不是额外的严谨，是复现成本已经降到可以日常做的地步。
依据跑分决定采购、投资或性能优化预算的技术管理者，判断标准要往后移一步，先确认三件事再批预算：
- 测试接口是否和生产环境一致
- 有没有独立于训练/调优过程的留出集
- 能不能拿自己的真实负载复现
缺了任何一条，这个数字目前只能算营销素材，不能当决策依据。
Dan Luu也没把这事写成"AI写的都是垃圾"。FRE整体性能不如Rust官方regex库，这个事实没变；但在某些窄场景下，一个针对特定负载定制的引擎确实可能更快。这和"整体领先"是两件事，混为一谈正是跑分翻车的起点。
值得盯的不是"AI还能不能写出更快的代码"——它显然能，只是这类结果目前离不开人工复核。真正的变量是，基准测试社区会不会补上"留出集+统一接口"这类护栏，把复核成本也降下来，而不是继续靠个别工程师花一个月手工排查。