benchmark-optimization-loop

基准优化循环

使用此技能将"使其快 20 倍"或"尝试 50 次递归优化"转换为可以实际改进系统的有界测量循环。

所需基线

在以下条件存在之前不要优化：

• 正在优化的操作；
• 必须保持绿色的正确性网关；
• 指标：墙钟时间、p95 延迟、行/秒、成本/运行、内存、错误率；
• 当前基线；
• 搜索预算：最大变体数、最大时间、最大支出、最大数据影响。

如果用户要求不切实际的目标，保持雄心但使循环有界且可测量。

循环

1. 测量基线。
2. 从证据中识别瓶颈。
3. 生成每个测试一个假设的变体。
4. 使用相同的输入形状运行变体。
5. 拒绝失败正确性、安全性或可重现性的变体。
6. 提升最快的安全变体。
7. 将获胜路径编码到脚本、命令、测试、配置或文档中。
8. 重新运行基线和获胜者以确认增量。

变体表

像这样跟踪变体：

变体 | 假设 | 命令 | 时间 | 正确？ | 备注
baseline | 当前路径 | npm run job | 120s | 是 | 稳定
batch-500 | 更少的往返 | npm run job -- --batch 500 | 42s | 是 | 获胜者
parallel-8 | 更多工作线程 | npm run job -- --workers 8 | 31s | 否 | 速率限制

递归搜索

对于递归或超参数工作：

• 将每次运行持久化到账本；
• 与先前接受的获胜者比较，而不仅是先前的运行；
• 保留一个验证或重放检查；
• 当改进在噪声范围内、正确性失败、成本超过预算或搜索开始改变比其可以解释的更多变量时停止。

使用"最佳测量安全变体"之类的短语，而非"全局最优"，除非搜索空间实际上是详尽的。

晋升网关

变体在以下情况之前不能成为新默认值：

• 正确性测试通过；
• 性能增量重复或得到解释；
• 回调明显；
• 更改编码在源代码管理或持久运行手册中；
• 最终摘要包括确切的命令和测量。