Benchmarking 是一个面向代码库热路径的微基准测试与迭代优化工作流技能。它的基本原则是「编码过程，而非目标数字」——数值会变化，工作流保持固定。
用途
该技能用于对任意代码库中的热路径进行微基准测量，并在测量基础上迭代改进。基准测试不作为 CI 的一部分，而是本地在合并性能改动前的决策工具。它既支持纯函数/映射器/转换的测量，也支持实时页面、标签页、绘制（DOM、RSC、导航）的测量。
主要能力
- 建立 Round 0 基线：在编辑生产代码或添加实验分支之前，先运行相关套件并把基线表格贴到聊天中，并标注 git 状态。
- 强制 Suggest 建议块：每次基准测试后必须输出，包含瓶颈（1–2 句）、是否值得优化、以及恰好 3 条创意想法（分别对应结构/缓存/减少工作三类），并给出单条推荐的下一步。
- 改进循环：Phase A 冻结基线 → Phase B 三个创意假设 → Phase C 尝试轮次（每次尝试后强制用户检查点，每个检查点周期最多 3 次实现尝试）→ Phase D 锁定。
- Ship gate 门槛：正确性（assertSameResults + 现有测试通过）、有意义的收益（真实工作负载 ≥1.15× 或每用户可见操作节省 ≥100µs）、无其他回归（热路径赢但冷路径慢 >10% 需记录或拒绝）、复杂度税（超过约 30 行除非收益 ≥2× 否则拒绝）。
- 预热与迭代规则：始终预热（≥20 次迭代或计时迭代的 10%），默认计时迭代数（廉价 400 次；昂贵如 DOM、zip 用 40–100 次），指标为 µs/op，始终与明确的参考行对比，存在缓存时同时运行冷/热路径。
- 文件约定：新套件命名为 tools/benchmark-<domain>.mjs，共享 harness 为 benchmark-harness.mjs，生产代码从 src/ 导入，实验变体在锁定前保留在同一文件中。
- 锁定后才写性能注释：仅在有需要时注释，只写 WHY 不叙述代码，使用用户可见场景，不把 µs/op 或 Big-O 写进 src/，每个优化点 1–2 行。
使用方式
- 分类工作：是性能调查还是性能改动。调查仅执行运行套件 → Round 0 表格 → Suggest 块后停止；性能改动则进入改进循环的 Step 1–6。
- 确定测量表面：纯函数直接 import src/ 使用 bench / benchSamples；React/Next 客户端组件用 happy-dom 或 jsdom；服务端处理/RSC 数据路径 mock Request；DOM 管道用 happy-dom + HTML fixtures；存储（IDB、SQLite）用 polyfill 或手动追踪；整页/冷启动用实时浏览器 + CDP，Runtime.evaluate + Performance.getMetrics，报告 ms 而非 µs/op。
- 可用命令示例：package.json 脚本 "benchmark": "bun tools/benchmark-run-all.mjs"，或运行 npm run benchmark / bun run benchmark，以及 import 语句如 import { bench, benchSamples, printSection, assertSameResults } from "./benchmark-harness.mjs";。
适用场景
适用于需要在合并性能改动前进行本地性能决策、调查热路径瓶颈、对纯函数或实时页面进行基准测量、以及为性能改动建立可复现基线与迭代流程的场景。支持 React、Next.js、Node/Bun、DOM、IDB 等栈（详见 stacks.md）。
限制
- 基准测试不在 CI 中运行（runner 易抖动）。
- 不在 Round 0 基线进入聊天前开始实验；未经 More ideas + 用户同意不实现第 4 次尝试；未经用户检查点不锁定；不把基准结果作为 golden numbers 提交；不带 assertSameResults 不交付性能改动；不单独使用 console.time；不在 CI 中做基准；不在未指明改进的用户可见操作时优化；不只呈现尝试对尝试的加速，始终显示相对 Round 0；不以只有表格结尾，始终附 Suggest 块和推荐下一步；不在 Suggest 块之前实现（除非用户点名想法）；不在实验期间添加性能注释。
- 具体安装命令、价格、收费与平台信息暂未提供。