夜雨聆风一条病毒推文引发的争论
前几天，一条推文在 X 上疯传：那些说"LLM 正在制造又慢又臃肿的代码"的人，早晚会被打脸——因为 AI 很快会用超级优化的汇编语言重写一切。
Dan Luu——前微软必应搜索索引工程师、写过 CPU 微码、拿过 SIGIR 最佳论文奖的人——看了直摇头。他在新博客里回了一句话：软件没有理由再这么慢了。 不是靠汇编，而是靠一个更根本的变化：性能优化的成本，已经下降了几个数量级。
一位读者在他的上一篇文章下留言：过去需要稀缺技能的性能工作，如今"任何人只要能打几句提示词就能做"。这句话引来亚马逊 CTO 办公室的 Marc Brooker 回应：
完全同意你的结论。为特定工作负载量身定制的动态软件，而不是面向一类工作负载的通用软件，看起来是一个非常可能的方向。
Dan Luu 决定亲自验证。他把这个判断拆成一系列实验，全部用 AI 编码代理完成。
实验一：让代理写一个编译器
故事的起点是 FRE——一个由 AI 代理连续优化了一个月的正则引擎。代理在 rebar 基准套件上跑得太久，一度严重过拟合，直到作者警告"我们有留出基准"，它才开始泛化。
既然 FRE 的 AOT 原生编译版本在长查询上表现不错，一个自然的想法是：让 ripgrep 跑着普通匹配器的同时，在另一个线程里悄悄编译原生代码，编译完再切换过去。对短查询这是亏的（浪费一个线程），但 Dan Luu 在乎的是跑几十秒甚至几分钟的查询——长查询实测提速 2 到 4 倍。
这套"正则引擎原生代码编译器"的代码手术，对人类来说是不小的工作量。但 Dan Luu 只做了件事：打了几句话，代理就去干完了。在更有代表性的留出查询上，AOT 生效的查询整体提速约 7%。"不是惊天动地的结果，但对花几分钟打字给 codex 来说，不算差。"
实验二：世界最强的 Azul 游戏 AI
更夸张的例子在游戏 AI 上。对 Azul 桌游一无所知的 Dan Luu，用 LLM 搓出了一个该游戏世界最强的 AI——比第二名强出一大截。
第二名的作者是专业团队，用了集群机器做实验；而 Dan Luu 主要在自己的笔记本上跑，估计投入的时间少了两个数量级。他的 AI 是多线程的，第二名是单线程的；由于他同时有原生代码版和"骇人的 shared wasm 内存 + JavaScript 版"，两版需要完全不同的多线程算法（小网络用 minimax，大网络用 MCTS）。这种工程量，手工做是相当大的工程。
"调试非确定性多线程算法的 replay 日志，手工做大概要几天到一周，而代理可以轻松循环做这种苦活。" 他还发现：对这类游戏 AI，速度每翻一倍，大约涨 100 Elo。光加多线程就能在大型机器上碾压同水平的对手；再叠上 10-20 个"普通人懒得手工做"的优化，差距就大得没法追了。
实验三：性能工程师输给了模型
Jamie Brandon 在准备性能工程师面试时，做了 Anthropic 那份现在已经公开的 performance takehome。他做完后让 Claude 接着他的进度继续优化——结果好得多。他复盘 Claude 做的事：一部分优化他自己想到了但没来得及做；另一部分，"是些疯狂的东西，除非我要在这上面耗几周，否则我永远不会去试。"
Jamie Brandon 是正经的性能工程师，最后也拿到了想要的 offer。但在一个边界清晰的优化问题上，他承认自己打不过一个好模型——Dan Luu 试了把同样的任务从头交给代理，得分与"接着 Jamie 进度做"几乎一样。
工作负载特化：几分钟的 2%
最贴近 Brooker 预测的实验，是在写这篇文章之前临时起意做的：让代理基于他的实际 ripgrep 查询日志做工作负载特化优化。从启动到完成，只花了约 2 分钟。第一轮优化后，特化版本在留出集上比标准 ripgrep 快 2%，而且还在持续变快。
2% 对个人使用不算什么，但"几分钟的人工时间"换来的持续改进，任何人都愿意要。Dan Luu 指出，对 Marc Brooker 这样在亚马逊的人、或 pgrust 的 Michael Malis 来说，正确的做法不是一次性优化，而是跟客户合作，用客户的数据做针对性优化，然后规模化——"针对你工作负载的定制软件"正在从预测变成现实。
Michael Malis 还点出另一个角度：过去很多软件（比如 JIT 编译器）之所以稀缺，是因为"写一个 JIT 太难了，性价比不划算"。LLM 降低了门槛，让团队敢做过去想都不敢想的软件。他的 pgrust 就是这句话的注脚。
附录里的真相：agent 的查询有多慢
文章附录藏着一个有趣的数据集——codex 在 Dan Luu 机器上跑出的 ripgrep 查询统计：
- • 模式长度 p50 是 55 个字符，p90 是 119 个字符，远长于人手敲的 grep
- • 查询耗时 p99 接近 1 分钟，p999 接近 10 分钟，最长的一次快 2 小时
- • 94% 的模式只出现过一次，但文件访问有很高的局部性
- • 约 45% 的被搜文件是纯 ASCII，55% 含 Unicode
换句话说，当你的电脑被 agent 卡到风扇狂转时，真相可能是：一个代理正在用 119 字符的正则、对着整个磁盘跑 10 分钟级的搜索。慢的从来不是语言，是 workload。 这也解释了为什么"为 AI 时代的真实负载做特化优化"如此有价值。
社区的声音：支持与质疑
HN 上 485 条评论吵成一团。支持者贡献了生动的案例：有人让 ChatGPT 写 CRDT，再拿所有手写实现做基准让它优化，获得了巨大的性能提升——"关键是他有明确的目标函数"；有人用 codex sol 把水文计算代码从 Python 移植到 Rust，快了 5 倍以上，内存降到十分之一；还有人在做 SafeRE——一个目标是在 Java 里保证线性时间、防 ReDoS 的 agent 优化正则项目。
质疑者同样有理有据："慢是一种感觉，不是事实"——很多人感知到的慢其实是网络往返，300ms 的等待被全球托管放大了；基准永远不等于真实世界，缓存行为常常出人意料；SOTA 模型的实验设计能力还很差，开放式自我改进循环没有人类搭框架就跑不动。有人一针见血："写高效代码从来不是语言问题，是内存和缓存的问题。"还有人提醒：超优化（superoptimization）80 年代就有了（Massalin、STOKE），AI 带来的真正新东西，是搜索程序的"随机过程"现在有了一个极其擅长提议的 LLM。
结语：性能不再是专家专利
Dan Luu 多年来的立场是：不应该责怪写慢代码的开发者——性能是众多专业知识之一，让每个人都精通它不现实。但现在结论要更新了：一个不懂性能、但会用 LLM 的普通程序员，应该能写出性能过得去的软件。"获得不错的性能，不再是一项专业技能。"
当然，代理没有 Jamie Brandon 的判断力，在开放式问题上会做得更差；直接跟 LLM 说"优化"，它会做出一堆需要你拦截的坏事。成本降了，判断力反而更值钱了。 但方向已经很清楚：为你的工作负载定制性能，以前是少数人的特权，现在是人人可用的日常操作。软件，确实没有理由再这么慢了。
本文基于 Dan Luu《There's no reason for software to be slow anymore》及 HN 讨论（485 条评论）撰写。