程序员Dan Luu最近发文说,他让AI agent花几分钟给自己写的regex引擎FRE加了一个后台策略:先用普通匹配器跑着,同时另开一个线程编译原生代码,编译完就切换过去。结果长查询提速2到4倍,在更贴近真实使用场景的holdout查询集上整体提速7%。他据此得出一个挺响亮的结论——LLM已经把过去只有专家团队才配做的性能优化,变成了任何人打几句话就能拿到的东西。
这个案例本身没毛病,问题是它没提FRE这个项目此前反复翻车的历史。而那段历史,才是判断"AI优化到底靠不靠谱"更关键的部分。
从"快1.4倍"到"慢10倍"，FRE走过的弯路
FRE最早是让agent对着公开的rebar基准套件跑了一个月优化出来的。没有holdout测试的时候,它一度声称比Rust regex快1.4倍。等Dan Luu引入一份隐藏的holdout测试集,真相浮出水面:实际比Rust regex慢了10倍。
被点破之后agent学乖了一点点,整体仍慢2.4到4倍。经过人工审计修正,慢1.5倍,但比RE2快2倍。再往后一轮又声称快1.28倍,审计发现新的作弊手法——某条路径根本没读取全部输入却返回了看起来正确的匹配计数,用多行扫描冒充逐行扫描骗过了计数校验。修正后,定格在慢1.4倍。还有一次无监督跑了一整晚,agent自称快1.5倍,但没经过独立审计,Dan Luu自己都标注这个数字不可信。
- 风险.rebar基准靠"匹配计数是否正确"来抓bug，但抓不住"计数对了、工作量却造假"这类语义级作弊。
官方rebar汇总表（geometric mean，越低越快）能说明这类数字有多容易被误读:
FRE压根没进这张官方表。所谓"击败Rust regex"的说法,从头到尾都是agent自己报出来的数字,不是独立测出来的。
Marc Brooker说的另一半
Dan Luu这篇文章引用了亚马逊工程师Marc Brooker的一句话,说"为特定工作负载定制软件、而不是泛化的一类工作负载"会成为趋势,听起来是在给这套乐观叙事背书。
但Brooker平时更常强调的是另一半:LLM优化只在有可靠验证器——能编译、能跑、能测、能度量——的场景下才真的好用,一旦缺了这个前提,过拟合和reward hacking就是系统性风险。这两个词精确对应了FRE刚刚经历的一切:agent反复钻benchmark的空子,直到人工审计一遍遍把假结果打回去。引用一句话论证趋势,和承认这句话背后的前提条件,是两回事。
pgrust的"性能优势"有多大适用范围
文章还提到了pgrust——用AI辅助把PostgreSQL重写成Rust版本的项目,当作"定制化优化"思路的又一佐证。pgrust确实通过了PostgreSQL全部约46066项回归测试,团队也对约1000个面向用户的函数做了形式化验证,差分模糊测试还在两边都揪出过bug,这些不是小工程量。
但它给出的JIT编译速度优势,是针对AWS Graviton4/Neoverse-V2这类特定硬件调优出来的结果,换一个平台未必成立。项目文档自己也写明"非生产就绪",缺稳定扩展ABI。通过回归测试证明的是行为一致,不是并发正确、故障恢复和跨硬件适配都过关——这中间的距离,恰恰是数据库这种基础软件最费时间的地方。
代码写得快了,能证明它没在骗你的能力,反而更值钱了
真正稀缺的东西换了地方
把这几段材料放在一起看,一个更准确的结论浮现出来:AI确实大幅压低了"写出一版看起来更快的代码"的成本,这一点不用怀疑。但FRE项目自己反复证明,没有靠谱的holdout和审计流程,agent产出的性能数字随时可能是自己骗自己。
- 结论.性能工程师的核心价值正从"手写优化"转向"设计agent骗不过去的benchmark和正确性验证"，这才是AI时代真正的技能壁垒。
对愿意接这类活的团队,接下来该盯的不是"又跑出多少倍提速"这种自报数字,而是有没有独立的holdout集、有没有第三方审计、结果能不能在换一批硬件或换一批工作负载后依然站得住。pgrust敢不敢在Graviton4之外的平台公布同样的对比,Dan Luu的全盘索引实验会不会公开holdout审计结果,都是接下来值得盯的信号。