benchmark-optimization-loop

name: benchmark-optimization-loop description: 当用户要求优化性能、尝试多种变体、递归优化、对比延迟/吞吐量/成本，或通过反复测量选出最佳实现时使用。 origin: ECC tools: Read, Write, Edit, Bash, Grep, Glob

基准优化循环

把"快 20 倍"或"试 50 种方案"这类模糊要求，转化为有边界、可测量的优化循环。

前提条件：先有基线

以下要素不具备时，不要开始优化：

• 要优化的操作；
• 必须保持通过的正确性检查（不能为了快而跑错）；
• 指标：耗时、p95 延迟、行/秒、单次成本、内存、错误率；
• 当前基线（baseline）的数值；
• 搜索预算：最多试几个变体、最多花多少时间/钱、对数据的影响上限。

如果用户目标不切实际，保留目标但让循环有边界、可度量。

循环步骤

1. 测量基线。
2. 从数据中找到瓶颈（靠证据，不靠猜）。
3. 生成变体，每个变体只验证一个假设。
4. 用相同的输入跑所有变体。
5. 淘汰未通过正确性、安全性或可复现性检查的变体。
6. 保留最快的合格变体。
7. 把胜出方案固化到脚本、命令、测试、配置或文档中。
8. 重新跑基线和胜出方案，确认差距。

变体记录表

用这种格式追踪每次尝试：

变体        | 假设           | 命令                          | 耗时  | 正确? | 备注
baseline    | 当前方案       | npm run job                   | 120s  | yes   | 稳定
batch-500   | 减少往返次数   | npm run job -- --batch 500    | 42s   | yes   | 胜出
parallel-8  | 增加工作线程   | npm run job -- --workers 8    | 31s   | no    | 被限流

递归搜索

适用于递归优化或超参数调优：

• 每次运行结果都记录到台账（ledger）；
• 和之前选出的最佳方案对比，不只是和上一次对比；
• 保留一个验证集（holdout）或回放检查；
• 以下情况停止搜索：
  • 改进幅度在噪声范围内
  • 正确性检查失败
  • 成本超出预算
  • 搜索同时改了太多变量，无法解释原因

用"当前测量到的最佳安全变体"代替"全局最优"——除非你真的穷举了整个搜索空间。

晋级门禁（Promotion Gate）

一个变体不能成为新默认方案，除非：

• 正确性测试全部通过；
• 性能差距可复现，或有合理解释；
• 回滚方案显而易见；
• 改动已录入版本控制或持久化的运维手册；
• 最终报告包含确切的命令和测量结果。