夜雨聆风性能优化，正在从“奢侈品”变成“日用品”
过去，一个只提升 2% 性能的想法，可能因为需要数天验证而被放弃。现在，AI 编码代理正在把这类工作的成本压缩到几句话、几轮实验和几分钟的人类时间。
软件为什么越来越慢？
一个常见答案是：开发者不在乎性能。但性能工程师 Dan Luu 提出了另一个更现实的解释——不是大家不知道软件可以更快，而是过去把它变快，往往太贵了。
实现 JIT 编译器、重写多线程算法、搭建可复现的性能基准、验证一个只带来几个百分点收益的优化……这些工作既耗时间，又依赖稀缺经验。对绝大多数项目来说，它们并非做不到，只是不值得做。
如今，LLM 和编码代理正在改变这笔账。
性能优化过去是一门“成本生意”
性能工程中有大量这样的判断：
这个改动也许能快 2%，但实现、调试和验证要花好几个人日，值得吗？
大型搜索引擎、数据库和游戏引擎可能愿意为这 2% 投入资源，因为微小收益乘以巨大规模，就能换来可观的成本下降。普通项目则往往选择加机器、缩小目标，或者干脆接受现状。
真正昂贵的还不只是写代码，而是完整的试验过程：找到瓶颈、提出假设、实现方案、运行基准、分析回归、排除偶然性，最后确认优化没有破坏正确性。
AI 编码代理最先改变的，正是这部分“工程摩擦”。
案例一：几句话，改造一个正则引擎
Dan Luu 曾让编码代理持续优化一个名为 FRE 的正则引擎。后来，他又提出一个新实验：在 ripgrep 执行普通匹配器的同时，用另一个线程编译原生代码；编译完成后，再切换到更快的执行路径。
如果由人手工完成，这会是一场不小的代码手术。但他只花了几分钟描述需求，代理便完成实现，并使用真实查询运行基准。
结果并非全面碾压：几个简单的长查询获得了 2—4 倍加速；在一组更有代表性的留出查询中，适合启用 AOT 的查询整体约快 7%。
7% 并不惊艳，却足以说明变化：过去可能因为投入产出比太低而不会启动的实验，现在可以低成本地先做出来，再用数据判断要不要继续。
案例二：没有游戏 AI 经验，也能挑战顶级水平
另一个更夸张的案例来自 Azul（花砖棋）AI。
Dan Luu 并不熟悉游戏 AI，却借助 LLM 构建出一个极具竞争力的程序。决定差距的并不只是“AI 策略”，还有大量传统性能工作：原生代码、WebAssembly、共享内存、Minimax、MCTS，以及针对不同版本重写的多线程算法。
多线程程序最麻烦的地方之一，是问题难以稳定复现。为此，代理还实现了从调试日志重放执行过程的能力，让非确定性 bug 可以被追踪和验证。
这种辅助设施如果全部手写，可能要耗费数天甚至一周。对代理而言，它却很适合被放进循环：运行、发现重放不完整、补充日志、再次验证，直到结果可靠。
作者观察到，在这个特定游戏中，速度每翻一倍，棋力大约能增加 100 Elo。于是，十几个过去“嫌麻烦、不值得做”的小优化叠加起来，就足以形成巨大差距。
更大的变化：软件开始为每一种工作负载定制
传统软件通常为“一类用户”设计。未来的软件，却可能根据某个客户、某台机器，甚至某个人的真实使用方式持续优化。
Dan Luu 用自己的 ripgrep 历史查询做了一次尝试。代理在一组查询上优化，再用另一组留出查询验证。第一轮之后，定制版本在留出集上比标准 ripgrep 快约 2%。
2% 对个人使用而言并不重要。真正重要的是，启动实验只用了几分钟，而且代理可以继续迭代。
当试错成本足够低，过去只会发生在超大规模系统中的“工作负载定制”，就可能进入普通团队和个人项目：数据库可以围绕客户查询模式调整，搜索工具可以围绕本机文件分布优化，前端也可以持续压低 LCP、INP 等真实体验指标。
但 AI 不会自动带来正确答案
这篇文章最容易被忽略的部分，恰恰是它对 AI 局限的提醒。
FRE 早期曾严重过拟合公开基准。代理在知道测试题的情况下，可以把数字做得非常漂亮，却未必真正提升通用性能。直到加入留出集，优化才开始具有更好的泛化能力。
这意味着，AI 可以大幅降低实现成本，却不会替我们解决实验设计问题。要让优化可信，至少需要：
明确而可重复的性能指标； 与训练和调优数据隔离的留出集； 正确性测试与回归测试； 对真实工作负载的持续采样； 人类对过拟合、测量噪声和风险的判断。
边界清晰、反馈快速的任务，是当前代理最擅长的场景；目标模糊、难以测量的开放问题，仍需要有经验的人搭好“赛道”。
从“请不起专家”到“先让代理跑一轮”
过去，顶级性能工程师稀缺且昂贵，大多数团队不可能为每个小问题配置专家。现在，一个编码代理未必拥有专家在开放问题上的判断力，却已经能在边界明确的优化任务中完成大量实现、测试与验证工作。
这不会让性能专家失去价值。相反，他们的价值可能从亲手完成每一次代码改造，转向设计更好的基准、识别真正的瓶颈、决定优化方向，并让多个代理安全地并行试验。
变化的核心不是“AI 比所有专家更强”，而是：原本不值得启动的性能实验，现在值得试一次了。
Codex 的搜索行为，和人类很不一样
Dan Luu 还分析了自己机器上的 ripgrep 使用记录。结果显示，代理生成的搜索模式比人类手写的复杂得多：模式长度中位数达到 55 个 Unicode 码点，P90 达到 119。
正则表达式中的交替分支也明显更多。很多查询会把函数名、测试名或数值条件展开成很长的表达式。
这些查询中，约 94% 的模式只出现一次，但被搜索文件具有较强的访问局部性。查询耗时的长尾也很明显：P99 接近 1 分钟，P999 接近 10 分钟，最长查询甚至接近 2 小时。
这说明未来的软件优化，不能只参考“人类通常怎样使用工具”。AI 代理正在形成新的工作负载，而新的工作负载，也会催生新的编译器、索引器和执行策略。
写在最后
“软件再也没有理由变慢”当然是一句带有挑衅意味的话。现实中，性能仍要与功能、可靠性、开发速度和维护成本权衡。
但有一件事确实发生了变化：性能优化不再天然等于一项昂贵的专家工程。
当实现、试错和验证的成本下降几个数量级，我们会开始尝试更多过去被放弃的想法。即使每个想法只带来 2%、5% 或 7% 的改进，持续叠加后，也可能重塑软件的性能上限。
未来真正稀缺的，也许不再是“把优化代码写出来”的能力，而是知道该测什么、如何证明它有效，以及怎样防止一个漂亮的数字欺骗我们。
作者：Dan Luu原文：There's no reason for software to be slow anymore
本文根据原文整理与改写，案例和数据均来自作者个人实验，不应直接视为所有项目或所有编码代理的普遍结论。
