企业官网建设流程全解析

skills 开源项目中的android-benchmark-comparison技能，面向"在真实 Android 设备上对比不同配置性能"这一场景，把一次 Android 基准测试（benchmark）变成可复现实验：先验证 workload 与设备条件可比，再解读排名；当排名反转时，用 trace 驱动诊断并给出有边界的默认配置决策。如果你正在为 Android 性能对比结果反复横跳而头疼，这篇指南会用 7 个步骤和 3 个实战案例讲清楚这套方法论。

为什么 Android 基准测试很难下结论？

做过性能对比的团队大概都遇到过这些问题：

• 排名反转：配置 A 昨天比 B 快，今天却慢了——到底信谁？
• "fixed performance mode"的错觉：报告写着"固定性能模式"，但它并不能证明 CPU 核的实际放置（placement）；
• 取整的百分位数：两份报告都给出取整的 p95，却说不清各自跑了哪些 case、重复了几次；
• 幸存者偏差：只拿"最快的那些存活样本"做对比，丢掉失败的运行；
• 多变量混变：一次改动里温度、亮度、后台负载同时变了，没法把差异归因到单一控制项。

android-benchmark-comparison 技能的核心原则只有一句话：把物理设备上的配置对比当作可复现实验——在解读排名或选择默认值之前，先验证 workload 与设备条件是否可比。

技能入口在 skills/android-benchmark-comparison/SKILL.md，同时它也划清了负面边界：如果没有配置对比，不要用它做代码层面的 Compose 性能诊断——那属于compose-performance技能的职责。

受控对比七步法：完整操作清单

第一步：先声明决策，保留证据链

在跑测试之前就要写清楚：决策目标、对比的配置、workload、指标定义、重复次数。运行后必须保留精确的 build 标识、原始结果与 trace，并确认每个计划的 case 和迭代都跑完了——要区分"缺失、失败、排除"三类运行，而不是只拿幸存者比。

第二步：控制并记录设备条件

需要记录并控制的关键变量包括：

技能特别要求：设备专属的命令和 CPU mask（亲和性掩码）应写进项目 runbook，而不是散落在聊天记录里。

第三步：平衡或反转运行顺序

平衡（balanced）或反转（reversed）运行顺序并重复对比，报告 spread（波动幅度）并确认排序在重复中是否保持。红线是：看到结果之后，不许把"慢的那几次迭代"扔掉。

第四步：排名反转时，用 trace 驱动诊断 ⚡

这是整个技能最关键的一步。当排名反转或波动达到"material"（实质性）程度时，暂缓下确定的默认值结论，并给出完整的下一次对比方案，而不只是列第一个阻塞点：

1. 确认下一轮使用相同名称的 cases 和迭代次数；
2. 用平衡或反转的运行顺序重复；
3. 检查时间戳与各测量区间重叠的 trace 数据，定位 placement、争用或热变化；
4. 如果做过 affinity（CPU 亲和性）实验：先探测设备拓扑 → 在测量区间内验证放置 →恢复并验证原始 affinity 设置后才能跑下一轮；
5. 只有经过验证的 affinity 运行才能标记为"受控对比"；
6. 恢复检查不可用时，明确写出这个缺口，并把任何默认值选择保持为**临时（provisional）**状态。

第五步：统计口径别搞错

从未取整的原始观测值计算汇总，只在展示时取整。并且必须显式声明聚合方式——技能里有一句很硬核的提醒："逐次运行的百分位数的均值，不是合并观测值的百分位数"（mean of per-run percentiles is not a percentile of pooled observations）。不要给所有决策都规定同一种统计量，选能回答你决策的那个。

第六步：区分受控实验与真实用户性能

受控实验的结论不能直接等同于"普通用户也会这样"。如果多个条件同时变化，只能报告"对比更受控了"，不能把整个差异归因到某一个控制项。另外，CPU 帧时长（frame duration）证据可以支撑画质/性能权衡，但不能声称它测量了 GPU shader 耗时。

第七步：收尾报告模板

一份合格的对比结论应包含：原始证据位置、完成的 case 数、波动情况、trace 发现、控制项与恢复状态、以及有边界的决策或残余不确定性。还有一个容易忽略的细节：建议在推荐里明确写出 "run order"（运行顺序）——只说"做一次平衡对比"并不能告诉团队具体要平衡或反转运行顺序。

三条不做的事（边界）

技能同样明确了它不会帮你做的事：

• 一次稳定的 benchmark 运行只支撑一个窄观察，撑不起稳健的配置排名；
• 不要把某台设备的 CPU mask、亮度值、迭代次数或汇总统计变成永久默认值；
• 当 trace 和重复覆盖都无法解释反转时：保持默认值不变，或做一个把局限写明的临时决策。

实战案例：三个评测场景拆解

仓库内置了三个评测案例，恰好覆盖"该怎么做、不该怎么做"：

场景 1：证据不足时——声明缺口，不编数字 📋

direct 案例 给出一份缺失关键信息的 benchmark 笔记：没有已完成的 case/迭代计数，也没有原始结果和 trace。正确行为是明确写出证据缺口，把默认值决策保持未决，不发明任何覆盖率数值或因果解释。其判定标准（rubric）要求结论"避免声称 CPU 指标测量了 GPU shader 耗时"，且"不把组合控制项的效果单独归因给 affinity"。

场景 2：排名反转 + 团队想抄近路

novel 案例 模拟了最典型的诱惑场景：quality 0 昨天比 quality 0.25 快、今天却慢了；两份报告都声称"fixed performance mode"、只含取整的 p95、都没列全 case 和迭代；试过一条 affinity 命令但没有任何 trace 验证放置——此时团队想立刻选"那个方便又快的默认值"。技能的期望回答是：推迟决策，并给出完整下一步——相同命名 case/迭代、平衡或反转运行顺序、检查与测量区间重叠的 trace、恢复并验证 affinity。

场景 3：克制测试——不是性能问题就别聊性能

negative 案例 是一个纯 80 列换行检查任务，并明确要求"Do not discuss performance experiments"。它验证的是技能不该被触发时保持安静——这也是该技能在评测矩阵中 Restraint（克制）得分 100% 的含义。

快速上手

• 安装：通过 skills CLI 安装npx skills add chrisbanes/skills，详见 README.md；
• 技能入口：skills/android-benchmark-comparison/SKILL.md；
• 路由提示：README 的 "Benchmarking" 一节写明——对比 Android benchmark 配置或基于测量结果选默认值时，从这里开始；
• 评测机制：想了解技能如何被评分，可参考 evals/README.md。

常见问题

Q：什么时候不该用这个技能？没有配置对比时。它是给"物理设备 + 多配置对比"准备的，代码级 Compose 性能诊断请用compose-performance。

Q：开了 fixed performance mode 就能下结论了吗？不能。固定性能模式不证明 CPU placement，affinity 实验必须"探测拓扑 → 测量区间内验证放置 → 恢复并验证原设置"三步齐全。

Q：可以直接把测出来的 p95 取整值设为默认阈值吗？不建议。技能明确反对把设备专属的 CPU mask、亮度、迭代数或汇总统计变成永久默认值；聚合方式要与决策问题匹配并显式声明。

Q：排名反转还没查清楚，可以先定默认值吗？只能定"临时默认值（provisional）"，并把未解决的反转、缺失的 trace 证据和下一步完整序列写进报告。

一句话总结：Android 基准测试对比的价值不在单次跑分，而在受控条件、可复现顺序和 trace 驱动的归因——android-benchmark-comparison 技能把这套方法论固化成了可以直接执行的清单。