一句话

在报告或依据一个性能数字之前，用七问核对它：瓶颈、调参、物理上限、错误、可复现、端到端意义、工作是否真的发生。

何时用

• 适合：PR 前后对比、回归声明、hillclimb 测量、库或配置选型这类要拿数字说话的场合。
• 不适合：用户只要粗略估计时跑一次就够（仍要核对第 4、7 问并说明只有一次）；选型比较绝不能当粗略估计。

怎么用

/benchmark-checklist 这个 40% 的提速写进 PR 之前先核一遍

1. 先写下你打算 ship 的那句话（含数据集和分位数），七问都在检验它。
2. 跑之前读测量脚本，用 uptime、nproc 看机器忙不忙；忙就让两侧交替吃同样的噪声。
3. 逐问用运行证据回答：命名 limiter（profile 或系统计数，不靠读代码猜）、两侧按生产调参、算物理上限、数错误、ABAB 交替至少各 5 次取中位数和极差、量端到端占比、确认工作真的在计时区内发生。
4. 报告先给结论：faster / slower / no measurable difference / inconclusive，附次数、极差、limiter。

产出

• 一个判定加证据；PR 正文只放一个主数字，运行明细放链接的工件里。

要点与坑

• 说不出 limiter、一侧没调参、或没核第 4、7 问时，结论必须写 inconclusive 并点名缺什么。
• 是 pstack-原则集 的可执行版；Perf issue 和 Hillclimb 剧本内部已跑它。
• 不依赖 Cursor 特性，Devin CLI 里可直接照搬七问。

关联

• 同类：ctk-verify-this · 原理：pstack-原则集 · 宿主：pstack-poteto-mode
• 所属：00-pstack-概览 · 工作流：W6-高风险加固层