用途：用于审查自己产出的性能数字——PR 前后对比、回归声明、爬山调优框架、库或配置选型。原则是先解释数字，每个问题都要用一次运行中的证据回答，而非凭对代码的猜测。用户只要粗略估计时，一次运行即可，但仍需检查错误与“工作是否真的发生”两项，并说明只有一次运行；选项之间的取舍绝不算粗略估计。
使用方式：运行前先写下预期声明（如“导出在 6 万行数据集上 p50 快 30%”），阅读测量脚本，注意它计时什么、计数什么、忽略什么；用 uptime 看负载、nproc 看核数，若机器繁忙无法停止，则让 A、B 两侧交错运行以承受相同噪声，并在报告中说明。
主要检查项：一、名称限流器，在不报告的运行中做 profile（如 node --cpu-prof、py-spy、perf、strace -c），注意负载生成器是否先饱和。二、是否调优：两侧都按生产方式运行（release 构建、生产标志与环境、批处理与事务设置、连接池、缓存冷热、相同版本与数据），若一侧用默认值，则是比较配置而非实现。三、是否突破物理极限：用算术核对磁盘与网络带宽、每秒操作数乘以每操作成本与核数、节省时间与被改动部分耗时（移除占运行 10% 的部分最多快约 11%）。四、是否出错：统计失败与非成功响应，并检查输出正确性。五、是否可复现：每侧至少跑 5 次并交错 A、B、A、B，报告中位数与范围，差距小于运行间波动视为无差异，接近时用秩和检验。六、是否重要：任何微观结果旁测量用户等待的端到端路径，报告微观结果占整体比例。七、工作是否真的发生：确认计时区间内请求到达服务器、行被写入、字节被读取、代码使用了结果，警惕惰性代码与超时。
报告要求：先给结论（更快、更慢、无差异或不确定），给数字带单位、运行次数、范围与限流器，例如“p50 41 ms → 33 ms，每侧 7 次中位数，之后范围 32–35 ms，受限于单核 JSON 解析”。若声称有差异却无法命名限流器、一侧未调优、或无法检查第四与第七项，则结论为不确定并指出缺口。PR 正文只保留一个主要数字，其余证据放到链接工件或笔记中。
限制：资料未提供具体安装命令、收费方式与支持平台，这些事实暂未提供。