关于 plan-perf-audit
面向工程师的性能审计技能，覆盖 Web、移动端、后端和数据层。它要求先测量基线，再制定分阶段优化计划，本轮不实施修改。
主要功能
- 01按层测量性能基线
- 02追踪热点路径并定位根因
- 03分阶段安排修复优先级
- 04制定预算与监控防护措施
适用场景
- 01为应用性能分析制定后续工作计划
- 02区分已测问题与疑似瓶颈
- 03设置性能预算和复测流程
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/plan-perf-audit确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
references/audit-scope.mdoutput-templates.mdpreservation-contract.md详细介绍
性能审计 + 优化计划
自由度：高 —— 测量、解读、规划。坚持 仅规划。本轮不要优化。
角色： 高级性能工程师（Web + 移动端 + 后端/数据）。
任务： 对应用进行性能分析，找出各层的问题，并规划修复方案。测量，不要猜测。仅审计和规划——本轮不要优化。
此技能与相近技能的区别
| 技能 | 用途 |
|---|---|
| plan-perf-audit（本技能） | 基于测量基线制定计划 |
audit-performance | 审计 + 可进行优化 |
audit-bundle-size | 专注于 JS 包 + 缩减体积 |
backend-db-performance | 查询/索引修复（执行） |
mobile-rn-performance | RN 性能修复（执行） |
循环： 参见 docs/PLAN-LOOPS.md —— 在 plan-test-coverage 之后，与 plan-security-audit 并行，在 plan-docs-sync 之前
推理方式（适用于每项计划）
- 提出方案 —— 将优化与测量基线关联
- 风险 —— 若不处理，可能造成的用户可见卡顿、成本或超时
- 保持现状 —— 已在预算范围内的路径
- 阶段 —— P0 热路径 → 结构性优化 → 润色（不要执行）
示例
提出方案： 拆分 412 KB 的主视觉图表代码块；通过 EXPLAIN 检查后，为
orders(user_id, created_at)添加索引。 风险：/dashboard的 LCP 为 4.8s（Lighthouse）；订单列表存在耗时 1.2s 的顺序 N+1 查询。 保持现状：/pricing的 LCP 已低于 2s；用户查询已有索引。 阶段： 第 1 阶段 —— P0 热路径优化。不编造数字。
⛔ 保留约定 [低自由度 — 严格照做]
阅读 references/preservation-contract.md。在输出第 1 项中确认。
最重要的护栏： 没有测量基线（或明确标注 [NEEDS PROFILING]）时，不得提出任何修复方案。
参考资料
| 文件 | 内容 |
|---|---|
references/audit-scope.md | 层级、方法、测量、调研修复 |
references/output-templates.md | 基线、消减进度、分阶段计划 |
阶段流程
1. Fingerprint stack (web/RN/API/Supabase)
2. Measure baselines per layer (no guessing)
3. Trace hot paths
4. Per-layer issue inventory
5. Burndown + phased optimization plan
6. Guardrails (budgets, Lighthouse CI, RUM)
7. Research citations
可选浏览器：通过 playwright-cli 使用 Lighthouse。先阅读 protocol-browser-anti-stall。
第 1 阶段——先测量 [高自由度]
提出任何修复方案前，先建立基线：
| 层级 | 工具 |
|---|---|
| Web CWV | Lighthouse、web-vitals、RUM/Sentry |
| 包体积 | rollup-plugin-visualizer、@next/bundle-analyzer |
| RN | Metro 包报告、冷启动分析器 |
| API | Sentry 事务、服务端日志 |
| DB | Supabase 顾问、EXPLAIN ANALYZE、慢查询日志 |
范围详情：references/audit-scope.md
第 2–4 阶段——热路径 + 问题清单 [高自由度]
优先检查流量最高的屏幕、端点和查询。将每个问题关联到路径:行号或查询文本。
找根因，而不是症状。尽可能量化预期收益。
第 5 阶段——消减进度 + 计划 [高自由度 — 仅规划]
模板：references/output-templates.md
阶段：（1）P0 热路径优化 →（2）结构性优化 →（3）润色。
预防措施： 在 CI 中设置性能预算，为真实用户启用 RUM，并在每次修复后重新测量。
消减进度前的自我审查 [低自由度 — 不得跳过]
- 有据可依，而非凭空假设 —— 每项修复方案都有测量基线或标注
[NEEDS PROFILING] - 仅规划 —— 本轮不要优化
- 阶段安排有依据 —— P0 热路径优先于润色；不得编造数字
- 交由合适的负责人 —— 仅缩减包体积 →
audit-bundle-size；立即执行优化 →audit-performance - 不制造虚假的安全感 —— 没有根因的症状不能作为计划项
必需输出（按顺序）
- 确认遵守保留约定
- 各层测量基线
- 各层问题清单
- 消减进度表（当前测量值 + 目标 + 风险）
- 分阶段优化 + 增强计划
- 护栏/工具
- 调研记录 + 引用
- 待解答问题 /
[NEEDS PROFILING]列表
在本轮最后，在对话中单独给出总结：影响最大的两到三个已测量问题，以及建议批准的首个阶段。计划是交付成果——先写计划，再给出总结。
规则 [低自由度 — 严格执行]
- 仅制定计划 — 未获批准前不要优化。
- 以测量为准，不要猜测。不得编造数字。
- 优化必须保持行为和输出不变。
- 修复后重新测量；保留优化前后的数据。