benchmark-optimization-loop

用途

Benchmark Optimization Loop 用于把“让它快 20 倍”或“试试 50 轮递归优化”这类请求，转化为一个有边界、可度量的优化循环，从而真正改进系统。它强调先度量、再优化，避免无依据的盲目提速。

必需基线

在开始优化之前，必须先具备以下要素：

• 被优化的操作；
• 必须保持通过的正确性门禁；
• 度量指标：墙钟时间、p95 延迟、行/秒、每次运行成本、内存、错误率；
• 当前基线；
• 搜索预算：最大变体数、最大时间、最大花费、最大数据影响。

如果用户提出不现实的目标，应保留其雄心，但让循环保持有边界且可度量。

循环流程

1. 度量基线。
2. 基于证据识别瓶颈。
3. 生成变体，每个变体只检验一个假设。
4. 使用相同输入形态运行变体。
5. 拒绝未通过正确性、安全性或可复现性的变体。
6. 推广最快且安全的变体。
7. 将获胜路径固化为脚本、命令、测试、配置或文档。
8. 重新运行基线与获胜方案，确认差异。

变体表

按如下方式跟踪变体：

Variant	Hypothesis	Command	Time	Correct?	Notes
baseline	current path	npm run job	120s	yes	stable
batch-500	fewer round trips	npm run job -- --batch 500	42s	yes	winner
parallel-8	more workers	npm run job -- --workers 8	31s	no	rate limited

递归搜索

对于递归或超参数工作：

• 将每次运行持久化到账本；
• 与先前已接受的获胜方案比较，而不仅与上一次运行比较；
• 保留留出集或回放检查；
• 当改进处于噪声范围内、正确性失败、成本超出预算，或搜索开始改变超出其可解释范围的变量时，停止搜索。

除非搜索空间确实已被穷尽，否则应使用“最佳已度量安全变体”这类措辞，而不是“全局最优”。

推广门禁

变体在满足以下条件前不能成为新的默认方案：

• 正确性测试通过；
• 性能差异可重复或已得到解释；
• 回滚方式明确；
• 变更已编码到源码控制或持久化运行手册中；
• 最终总结包含确切的命令与度量结果。