基准测试优化循环 是做什么的？
使用此技能将“让它快20倍”或“尝试50次递归优化”转化为一个有边界、可测量的循环，从而真正改善系统。
前置基线
在以下条件具备前，请勿进行优化：
- 待优化的操作；
- 必须保持通过的正确性检查；
- 指标：挂钟时间、p95延迟、行/秒、每次运行成本、内存、错误率；
- 当前的基线值；
- 搜索预算：最大变体数、最大时间、最大花费、最大数据影响。
如果用户提出了不切实际的目标，保留其雄心，但必须让循环变得有边界且可测量。
优化循环
- 测量基线。
- 根据证据识别瓶颈。
- 生成每次只测试一个假设的变体。
- 使用相同的输入规模运行所有变体。
- 拒绝未通过正确性、安全性或可重现性检查的变体。
- 推广最快的安全变体。
- 将获胜路径记录到脚本、命令、测试、配置或文档中。
- 重新运行基线及获胜者以确认差异。
变体记录表
按如下方式追踪变体：
变体 | 假设 | 命令 | 耗时 | 正确？ | 备注
baseline | 当前路径 | npm run job | 120s | 是 | 稳定
batch-500 | 减少往返次数 | npm run job -- --batch 500 | 42s | 是 | 获胜者
parallel-8 | 更多工作进程 | npm run job -- --workers 8 | 31s | 否 | 受到速率限制
递归搜索
对于递归或超参数调优：
- 每次运行都持久化到运行记录中；
- 与前一个已接受的获胜者进行比较，而不仅仅是前一次运行；
- 保留一个留出集或者回放校验；
- 当出现以下情况时停止：改进幅度在噪声范围内、正确性检查失败、成本超出预算、或者搜索开始改变太多变量以至于无法解释。
使用诸如 “经过测量的最佳安全变体” 这样的措辞，除非搜索空间确实是穷尽的，否则不要使用“全局最优”。
升级门槛
一个变体在成为新的默认配置之前，必须满足：
- 正确性测试通过；
- 性能差异是可重复的或有合理解释；
- 回滚路径清晰明确；
- 变更已纳入版本控制或持久的运行手册中；
- 最终总结中包含确切的命令和测量值。