看了三篇评测，装上一个新工具，三天后弃用。弃用不是因为工具差，而是评测回答的问题是"它有什么功能"，你需要的是"在我这套约束下它是否更优"。这两件事之间差着一整层：场景、熟练度、硬件、维护成本、退出成本。
下面给一套能拿来就用、也能事后复现的判断流程。
1. 评测的失真源
| 失真源 | 具体表现 | 应对 |
|---|---|---|
| 厂商基准 | 挑最好的场景、开最优参数 | 只看方法不看结论数字 |
| 单一场景 | 只测 hello world 或最大规模 | 补中间态与真实数据规模 |
| 作者熟练度 | 对新工具是第一次用，对旧工具用了三年 | 学习期单独计，别混进比较 |
| 硬件差异 | NVMe 与机械盘、核数、网络 | 同机对比，或明确归一化 |
| 版本漂移 | 评测针对半年前的版本 | 记录版本号与配置 |
先认这一条：任何"快 N 倍"的说法，缺了同机、同数据、同版本，都只能当候选线索，不能当依据。
2. 先定义"要它解决什么问题"
| 问题类型 | 判据 | 不该看的东西 |
|---|---|---|
| 替代现有工具 | 同任务耗时、返工次数 | 功能列表长度 |
| 补能力缺口 | 能否做到当前做不到的事 | 微基准跑分 |
| 降本 | 单位任务成本（含人力） | 峰值性能 |
| 降心智负担 | 每周卡点数、查文档次数 | 任何吞吐数字 |
# 写在纸上的一句话，写完再装工具
问题：CI 里跑集成测试从 9 分钟压到 5 分钟内，且不增加 flaky 率。
判据：同一套测试、连续 10 次取中位；flaky 率不高于当前值 +1 个百分点。
不成立条件：需要重写超过 20% 的测试夹具。 # 提前写，防止事后找理由
没有"不成立条件"的评测，结论一定会偏向新工具——因为人会为已投入的时间找理由。
3. 可复现的比较方法
| 必须固定 | 允许变化 | 说明 |
|---|---|---|
| 机器、核数、磁盘 | 工具版本（要记录） | 跨机比较基本无意义 |
| 数据集与任务集 | 配置中可调项（要记录） | 配置不作弊也别自废 |
| 轮次与预热方式 | 运行顺序（可打乱抵消） | 冷热混测等于没测 |
| 度量口径 | 并发度（要报告） | 口径不同结论必冲突 |
# 最小可比脚本：每轮清缓存、跑 N 次、取中位而非均值
for i in 1 2 3 4 5; do
sync; echo 3 > /proc/sys/vm/drop_caches 2>/dev/null || true
/usr/bin/time -f "%e" ./run_task.sh "$DATASET" 2>> times.txt
done
sort -n times.txt | awk '{a[NR]=$1} END{print "median=" a[int((NR+1)/2)]}'
取中位而不是均值：一次 GC 或一次邻居抢占就能把均值拉偏，而它不代表你日常的体验。样本少于 5 轮时，"差 10%"这种结论根本站不住。
4. 任务型基准 vs 微基准
| 类型 | 能回答 | 用在哪 |
|---|---|---|
| 微基准 | 单个操作的极限 | 排除明显不行的候选 |
| 任务型基准 | 端到端时间与产物质量 | 做决策依据 |
| 混合负载 | 日常真实形态 | 判断稳定性与退化 |
微基准差 2 倍，端到端常常只差 5%：端到端里还有解析、IO、序列化、排队。反过来也成立——微基准看起来差不多，端到端差一倍，通常是内存或并发模型在起作用。所以顺序是：微基准筛掉候选，任务型基准做结论。
5. 冷启动与热路径必须分开测
| 指标 | 冷启动 | 热路径 |
|---|---|---|
| 首次可用时间 | 含加载、编译、建索引 | 不适用 |
| 单次操作耗时 | 前若干次偏高 | 预热后稳态 |
| 内存峰值 | 常出现在启动与建索引阶段 | 稳态占用 |
# 冷：进程起、跑一次、退出，重复三次，取最差值（最差值才是用户感受到的）
for i in 1 2 3; do cold_run.sh; done
# 热：常驻进程，先预热 20 次（丢弃），再测 100 次
warm --iterations 20 > /dev/null && warm --iterations 100
把冷热混在一起平均，会得到两个都不准的数：既看不出启动有多慢，也看不出稳态有多快。CLI 工具几乎全是冷路径，服务型工具才关心热路径——先确认你的使用形态属于哪种。
6. 把"安装体验"和"长期维护"计入
| 成本项 | 量化方式 | 一年量级（按团队 5 人估） |
|---|---|---|
| 初始配置 | 小时数 × 人数 | 数十小时 |
| 升级破坏 | 每年升级次数 × 回归工时 | 数十小时，且不可预期 |
| 文档质量 | 查文档耗时、示例是否可跑 | 持续小额支出 |
| 维护活跃度 | 最近提交、issue 首响 | 决定"要不要准备替代品" |
| 排查支持 | 出问题能否搜到答案 | 事故时按小时计 |
这些不进基准，但决定工具在半年后还在不在。判断维护活跃度只看两件事：近三个月是否有发布、issue 里有没有维护者回复。两个都没有，等于你接手了维护。
7. 适配成本三档与退出成本
| 档位 | 含义 | 典型投入 | 决策倾向 |
|---|---|---|---|
| 即插即用 | 配置一下即可 | 数小时 | 直接试，不值得评测 |
| 需改流程 | 团队工作方式要调整 | 数天到数周 | 需要明确的收益假设 |
| 需改架构 | 数据模型、部署形态要动 | 数周以上 | 按项目立项评估 |
# 退出检查清单，安装前就要能回答
1. 数据能否完整导出？格式是开放的吗？
2. 配置能否迁移到替代品？有没有私有 DSL？
3. 能否与旧方案并行跑一段时间（双跑期）？
4. 卸载后残留什么（插件、hook、索引目录）？
第 4 条最容易被忽略：装的时候顺手挂上的 git hook、CI 插件、编辑器扩展，卸载时没人清，半年后变成"不知道为什么构建慢"。
8. "更快"与"更省心"的权重由使用频次决定
| 使用频次 | 该优先 | 理由 |
|---|---|---|
| 每天多次 | 速度与稳定性 | 单次省 10 秒，一年是几十小时 |
| 每周几次 | 稳定性与可预测性 | 速度差异被稀释 |
| 每月一次 | 文档与上手成本 | 每次都要重新学，等于每次都付学费 |
| 一次性 | 用手上已有的 | 学习成本收不回来 |
同一对工具在不同频次下会得出相反结论，这不是矛盾，是权重不同。写结论时必须把频次作为前提写进去，否则结论无法被别人复用。
9. 把主观体验量化
# 一周使用日志：每天一行，只记卡点，不记感受形容词
日期 | 做了什么任务 | 卡点描述 | 卡了多久 | 绕路方式（换回旧工具/查文档/放弃）
11-04 | 批量重命名 | 找不到批量入口 | 12min | 换回 xargs
11-05 | 导入配置 | 文档示例过期 | 25min | 搜 issue 找到新写法
| 指标 | 采集方式 | 判据 |
|---|---|---|
| 卡点数/周 | 日志计数 | 第 2 周未下降即不适配 |
| 绕路次数 | 换回旧工具的次数 | 超过总任务数 20% 说明能力不匹配 |
| 放弃次数 | 直接不做 | 任何一次都值得单独看 |
"用起来别扭"是可测量的：把它拆成卡点次数与时长。新鲜感通常在第一周掩盖卡点，第三周开始放大卡点——所以试用期不能短于两周。
10. 小组试用：人数与周期
| 参数 | 建议 | 理由 |
|---|---|---|
| 人数 | 3–5 人 | 再多口径对不齐 |
| 周期 | 2–4 周 | 越过新鲜感，又不到遗忘 |
| 任务 | 真实待办，不用构造样例 | 构造样例必然偏乐观 |
| 记录 | 同一模板 | 否则无法合并结论 |
| 汇报 | 只报卡点与结论，不报感受 | 感受无法聚合 |
人数超过 5 人时，讨论会退化成"谁用得熟谁说了算"；周期短于两周时，测的是学习曲线而不是工具。
11. 结论的写法
结论模板：
在【条件：频次/数据规模/团队规模/已有生态】下，【工具 A】优于【工具 B】，
主要因为【机制原因，不是"更快"】。
该结论在【条件变化】时不成立，届时应重评。
已验证的反面证据：【列出你专门找过的反例】。
| 反面证据来源 | 怎么找 |
|---|---|
| 负面 issue | 搜 "slow" "memory" "broken" + 版本号 |
| 迁移回退案例 | 搜 "migrated away from" |
| 边界规模 | 找"数据量大了之后"的讨论 |
| 团队内部 | 问已经用过又弃用的人 |
收集反面证据是义务，不是可选项：只找支持证据的评测，结论一定过于乐观，而且会在三个月后被人用一次事故推翻。
12. 排错与边界
| 现象 | 原因 | 处置 |
|---|---|---|
| 两次测出来差很多 | 缓存/邻居/顺序未控制 | 打乱顺序、清缓存、加轮次 |
| 新工具全面更好但没人用 | 适配成本落在别人身上 | 把成本算进决策 |
| 试用结论互相矛盾 | 口径不同、任务不同 | 统一模板与任务集 |
| 上线后性能不达标 | 只测了热路径或只测了小数据 | 补冷路径与目标规模 |
| 情形 | 要不要评测 | 说明 |
|---|---|---|
| 一次性任务 | 不要 | 用手上工具，学习成本收不回 |
| 生态已确定（公司强制栈） | 不要 | 评测不改变结论，只消耗时间 |
| 项目已无维护 | 不要 | 直接排除 |
| 无法造出真实数据 | 谨慎 | 结论只能当方向，不能当依据 |
13. 自测
- 为什么"快 2 倍"在没有同机同数据的条件下不能作为依据？
- 微基准与任务型基准各自该在流程的哪一步用？
- 冷启动数据被平均进热路径后，会掩盖什么？
- 适配成本三档里，哪一档需要"立项"而不是"试用"？
- 试用期为什么要跨过两周？
- 结论模板里"不成立条件"这一行，防止的是什么？