一个团队把"新的查询引擎"和"旧版本"做对比：新引擎快 40%，于是上线。三个月后回滚——因为真正的对手不是"旧版本"，而是"另一个候选方案"，而那个方案"比新引擎还快 15%，且运维更简单".
"对照组选错"是实测里最贵的错误：它不会让数字失真，只会让结论"回答了另一个问题"。而"和旧版本比"是最常见的错——因为"旧版本"最容易拿到，而它"不是决策的选项之一".
1. 三种"对照组"的差别
| 对照组 | 回答的问题 |
|---|---|
| 旧版本（现状） | "换了会好多少" |
| 候选方案（竞争者） | "该选哪一个" |
| 理论上限（理想实现） | "还有多少空间" |
第一项回答"迁移收益"，第二项才回答"选型决策"——而"选型"通常需要"两者都答".
"对照组"写在"报告标题"里，是最便宜的防错:
// 三类"标题"（一眼看出"回答了哪个问题"）
1 迁移收益：v2 相对 v1.2 的吞吐提升评估
2 选型对比：A/B/C 三方案在"同机同数据"下的 P99 与运维成本
3 上限评估：当前实现距"理论最优"还有多少
// 判据：标题里"必须有对照对象"
2. "选错对照组"的三种后果
| 后果 | 表现 |
|---|---|
| 选了一个"次优" | 比现状快，但不如另一个 |
| 结论"不可迁移" | 换了场景就变 |
| 反复重测 | 每次"换个人"就"换个对手" |
第一项是"最贵"的："快 40%"听起来很好，而"另一个方案快 60%"会让这个决定"变成三年后的技术债.
"列全选项"有一个"五分钟"的动作，而它常被跳过:
// 三步"列全候选"（选型前，五分钟）
1 写下"这个位置必须满足的 3 个硬指标"（如"支持事务""P99<50ms""可运维"）
2 从"团队已知的方案 + 社区主流 + 现有产品"各取 1–2 个
3 用"硬指标"筛一遍 → 剩下的进"粗筛"
// 判据：候选"≥2"，且"每个都能说清'为什么不选它'"
3. "对照组"的三个选择原则
| 原则 | 说明 |
|---|---|
| 包含"所有可行选项" | 至少 2 个候选 |
| 排除"已淘汰的" | 旧版本只在"迁移评估"里用 |
| 对齐"生产条件" | 同机、同数据、同负载 |
第二项要"说清"："旧版本"作为对照"只用于'值不值得迁'这个问题"第二项的"实操"是"报告标题就写清"："迁移收益评估（对照：v1.2）" 与 "选型评估（对照：A/B/C）"——**两类报告"不能互相替代".
——**而"选型"必须"比候选".
"精测前两名"要"用同一套脚本"，否则"比的是脚本":
// 三条"同脚本"要求
1 同一份压测脚本、同一份数据生成器
2 同一台机器、同一时段（或交替执行）
3 同一组指标（P50/P99/错误率/资源）
// 判据：换候选时"只改'被测对象'，不改'测法'"
4. "多候选"的三种成本控制
| 做法 | 成本 |
|---|---|
| 先"粗筛"（单指标） | 低（每候选 1 小时） |
| 精测"前两名" | 中（每候选 1 天） |
| 全量精测"所有候选" | 高（不建议） |
第二项的"淘汰标准"要"提前写"："粗筛只看'一条硬指标'（如 P99 或'是否支持 X'）"——否则"粗筛"会变成"小型精测"，成本回到原点.
第二项是"标准做法"："三轮淘汰"**——粗筛 5 个 → 精测 2 个 → 决策.
"预热"这件事要"固定成一条规则"，否则"每次结论都不同":
// 三种"预热"策略
1 固定轮次（前 2 轮丢弃）——简单、稳定（推荐）
2 固定时间（预热 60s 后开始计时）——适合"缓存型"
3 不预热（只测"冷启动"）——只在"评估首请求"时用
// 判据：同一份报告里，"预热策略"必须写明
5. "对齐条件"的三种要素
| 要素 | 说明 |
|---|---|
| 同机（同规格、同负载） | 排除"机器差异" |
| 同数据（同规模、同分布） | 排除"数据差异" |
| 同测法（同预热、同并发） | 排除"方法差异" |
第三项最容易被忽略："一个预热了、一个没预热"第三项的"常见伪造"是"缓存差异"："A 跑了三遍（缓存热），B 只有第一遍（冷）"——**于是"B 慢 40%"，而"两者其实一样".
——**于是"快 40%"可能只是"冷启动的差".
"被别人打脸"这件事，最好的防御是"提前请'会用的人'看一眼候选列表":
// 三步"外部校验"（半小时）
1 找一个"不在这项目里"的同事，问"你会考虑哪些方案"
2 把"没列进去的"逐个记下，标注"为什么不选"
3 若"说不出理由" → 补进"粗筛"
// 判据：候选列表"经得起一次外部质疑"
6. 排错：五种"对照组问题"
| 现象 | 成因 | 处理方向 |
|---|---|---|
| 上线后"不如预期" | 只比了旧版本 | 加"候选" |
| 结论"换场景就变" | 条件未对齐 | 固定三要素 |
| 每次结论不同 | 对手不一致 | 写清"对照组" |
| 测了很多但没结论 | 候选太多 | 三轮淘汰 |
| 被别人"打脸" | 漏了关键候选 | 先"列全选项" |
7. 边界：什么情况"只比旧版本"就够
| 场景 | 为什么 | 做法 |
|---|---|---|
| 迁移评估（已定选哪个） | 只需"收益" | 比旧版本 |
| 升级补丁（同产品） | 无"候选" | 比旧版本 |
| 优化调参（同实现） | 只需"改善" | 比旧版本 |
| 无"可选方案"（自研唯一） | 无对手 | 比旧版本 |
最后一条与"沟通"有关的边界："对照组"要写进"结论的第一行"——"在'对照 A/B/C、同机同数据'的条件下，X 的 P99 低 12%"——否则"半年后"没人知道"那个 40% 是跟谁比的"，而"数字脱离条件就没有意义".
判断口径一句话："这次实测的结果，会不会"改变'选哪个'""**。会（选型、替换、重构），必须"包含所有候选 + 对齐条件"；不会（迁移收益、调参、补丁），"比旧版本"就够——而"把'选型'当成'迁移'来测"，就是"快 40% 却选了个次优"的成因.
8. 自测
- 三种"对照组"分别回答什么问题？为什么"选型"需要"两者都答"？
- "选错对照组"的三种后果里，哪一种"最贵"？为什么它"三年后才显现"？
- "旧版本"作为对照组，适用哪个问题？"选型"为什么不行？
- "三轮淘汰"的成本结构是什么？为什么不"全量精测"？
- "对齐条件"的三要素里，哪一项最容易被忽略？它会伪造出什么差异？
- 判断"只比旧版本够不够"的那个问题是什么？
补一句"成本"的账："多测一个候选"的成本是"一天"，而"选错"的成本是"三年"——这个比例说明，'列全候选'这一步"永远值得"，哪怕最后"只精测两个"。而"跳过这一步"的团队，通常会在"回滚时"花"两周"去解释"当初为什么没考虑 X".
而"标题里写清对照对象"，能让"半年后的争论"变成"读一行字就结束"。
而"读一行字"的成本，远低于"重跑一次实测"。
再补一个"组织"视角："选型实测"通常由"想换的人"发起——于是"对照组"很自然地选了"最容易被说服的那一个"，而不是"最强的那个"。这不是"作弊"，而是"确认偏差"：人在立项时已经"有了倾向"，于是"无意识地"把"更强的候选"排除在"可行性"之外（"它要重写，不算"）。所以"外部校验"那半小时很值：它问的不是"你测对了吗"，而是"你还有什么没测".
而这一问，几乎总能问出一个"被忽略的选项"。
9. 一句话总结
"对照组"决定了结论"回答哪个问题"：比旧版本回答"值不值得迁"，比候选回答"该选谁"。而"选型"这类决策，必须"列全可行选项 + 对齐三要素 + 三轮淘汰"——否则你会拿到一个"真实的数字"，却用它回答了一个"不同的问题"。而这类错误，通常在"三年后回滚"时才被记起来。