performance-optimization

用途

Performance Optimization 用于回答一个核心问题：我们该信任哪个工件、真正的瓶颈在哪里、以及最值得先尝试的最小调优动作是什么。它的目标不是罗列通用的 React、SQL、缓存或游戏性能技巧，而是把性能抱怨分类，将当前工件规范化为一份调优简报，选定一个主要模式，命名一个瓶颈，推荐一到两个高杠杆改动，然后验证前后影响并正确路由剩余工作。

何时使用

慢交互、页面加载、路由切换、API 热路径、查询计划、内存增长、包体积回退或帧预算抱怨，且瓶颈尚未隔离。
以 trace、Lighthouse/CWV 报告、火焰图、查询计划、压测差异、profiler 截图、基准笔记或利益相关者仪表盘形式到达的性能包。
跨域性能请求，涉及 CLI/开发工作流、Web/全栈、产品/运维、营销/内容性能或游戏相关路由，且下一责任方仍不明确。
需要一份有边界的调优简报，而不是通用性能技巧堆砌。

何时不使用

主要任务是推出仪表盘、告警、指标、trace 或日志管道 → 使用 monitoring-observability。
主要任务是复现正确性 bug、隔离回归或理解行为为何错误 → 使用 debugging。
主要任务是在没有性能证据的情况下进行安全的结构清理、分解或 codemod 规划 → 使用 code-refactoring。
主要任务是选择组织级测试层、合并/发布门禁或基准策略 → 使用 testing-strategies。
瓶颈明显位于 Unity/Unreal/Godot 捕获内部，且引擎专属解读是主要工作 → 使用 game-performance-profiler。
瓶颈已隔离，下一任务是栈专属实现细节；在框定调优简报后路由到实现技能。

使用方式

该技能按以下步骤工作：

框定抱怨：记录表面（CLI/开发、前端/页面加载、API/服务、数据库、异步/容量、报告/仪表盘、运行时/游戏、未知）、症状（高延迟、低吞吐、内存增长、CPU 饱和、慢查询、大包体积、弱 CWV、帧尖峰、未知）、决策目标（p50/p95/p99 延迟、吞吐、包体积、内存上限、帧预算、CWV 指标或基准时长）、环境（本地、CI 基准、预发、生产、目标设备/硬件、混合/未知），以及这是回归、慢性热点还是模糊抱怨。
从现有工件出发：选择用户当前实际拥有的包，如浏览器 trace/DevTools 录制、Lighthouse/WebPageTest/CWV 报告、APM trace/火焰图/profiler 输出/基准差异、EXPLAIN/查询计划/慢查询工件、profiler 截图/统计叠加/引擎捕获、电子表格/仪表盘/报告摘要或尚无可用工件。输出为 Intake Packet，包含当前工件、为何足够（或不足）、下一步需收集的缺失上下文。规则：如果当前工件已能缩小下一步决策，不要强迫用户进入理想测量流程。
选择一个主要调优模式：interaction-and-rendering、page-load-and-bundle、api-latency-and-hot-paths、database-plan-and-data-access、throughput-and-capacity、memory-and-allocation、runtime-frame-budget、unknown-needs-better-measurement。规则：一个主要模式，可选一个次要模式，不要把所有优化轴混在一起。
在提出修复前命名瓶颈：把证据转化为一句瓶颈陈述，例如“端点在数据库工作返回后，CPU 受限于 JSON 序列化”“搜索查询计划在做宽排序+过滤，因为复合索引不匹配谓词”“交互延迟主要由一个长任务加上结果面板的布局抖动主导”“帧尖峰与目标硬件上的资产流式突发对齐”“CWV 报告显示 LCP 由图片负载和渲染阻塞脚本成本主导，而非服务器延迟”。避免“整体性能很差”这类模糊陈述。
推荐一到两个高杠杆改动：优先选择直接攻击已命名瓶颈的最小可信动作。按模式候选：interaction-and-rendering 可减少重渲染范围、推迟非关键工作、避免布局抖动、虚拟化重列表、削减同步主线程工作；page-load-and-bundle 可拆分路由/模块、减少 JS、优化资产交付、压缩/调整图片、削减第三方成本、积极缓存；api-latency-and-hot-paths 可移除阻塞工作、缓存昂贵响应、降低序列化成本、并行化安全的下游调用、预计算重转换；database-plan-and-data-access 可修复查询形状、添加/调整索引、移除 N+1 访问、提前下推过滤、改变分页策略、减少行宽；throughput-and-capacity 可调整并发限制、队列形状、工作池大小、连接池大小、批大小或缓存命中路径；memory-and-allocation 可减少抖动、限制缓存、适当复用缓冲区/对象、流式而非缓冲、缩小负载；runtime-frame-budget 可减少每帧工作、分散昂贵任务、降低绘制/过度绘制压力、推迟流式突发、简化昂贵效果；unknown-needs-better-measurement 不要猜测，索取能区分可能原因的最便宜工件。经验法则：最多推荐两个候选改动，除非下一步是收集更好证据。
说明权衡与路由：每个调优建议都应包含可能变差的部分，例如缓存可能改善延迟但增加陈旧度或内存压力；批处理可能改善吞吐但损害尾延迟；分页/索引更改可能加速一个查询但复杂化写入；懒加载或拆分可能改善初始加载但增加后续交互延迟；图片压缩或资产简化可能降低质量或需要内容/设计签字。需要时路由实现：组件/状态架构清理 → react-best-practices、state-management 或 design-system；模式/索引/数据模型重设计 → database-schema-design；遥测推出或持续告警 → monitoring-observability；基准门禁策略 → testing-strategies；引擎专属 profiler 解读 → game-performance-profiler；正确性优先复现或环境漂移 → debugging。
验证前后影响：验证包应包含基线指标和环境、改变的变量、可比条件下的后指标、主要瓶颈是否移动或消失、残余风险/后续测量。

输出格式

Performance Brief

Surface:
Symptom:
Decision target:
Primary mode:
Current artifact:

Bottleneck Hypothesis

Primary bottleneck:
Confidence:
Why:

Highest-Leverage Changes

Tradeoffs / Risks

Verification Plan

Baseline:
After:
Guardrail:

Route-outs

示例

示例 1：API + DB 延迟回归。输入：“我们的订单搜索端点在添加更多过滤器后突然变慢。我们有 EXPLAIN ANALYZE 输出和慢查询日志。”预期形状：分类为 database-plan-and-data-access，次要模式为 API，使用当前工件而非先要求通用遥测，隔离最热查询或序列化层，提出一到两个针对性改动，然后定义前后验证。

示例 2：营销/内容性能报告。输入：“我们的落地页 CWV 报告显示 LCP 和 INP 较差。我们有 Lighthouse 和字段数据，但还没有 profiler trace。”预期形状：分类为 page-load-and-bundle，把报告视为真实 intake packet，区分可能的资产/渲染阻塞原因与遥测缺口，推荐一到两个有边界的下一步，并注明何时值得收集额外 trace。

示例 3：路由到可观测性设置。输入：“我们需要仪表盘、trace 和告警，以便在用户抱怨前捕获慢端点。”预期形状：路由到 monitoring-observability，而不是假装主要任务已经是优化。

示例 4：路由到游戏引擎 profiler 技能。输入：“Unreal 在 Steam Deck 上卡顿，我有 Insights 捕获。你能帮忙解读吗？”预期形状：承认更广泛的性能上下文，但把引擎专属捕获解读路由到 game-performance-profiler。

最佳实践

从用户已有的工件出发；将其规范化为调优简报，而不是丢弃。
先测量，再调优。
在开处方前命名一个主要瓶颈。
保持建议有边界：一到两个高杠杆动作胜过巨大清单。
验证影响时比较同类环境。
明确说明权衡，尤其是缓存、一致性、内存和内容质量成本。
把遥测设置、调试、重构和引擎专属 profiler 阅读路由到相邻技能，而不是吸收一切。

限制

该技能不负责监控可观测性搭建、正确性调试、无性能证据的代码重构、测试策略制定或引擎专属 profiler 解读。它依赖用户提供的现有工件；如果尚无可用工件，会要求最便宜的能区分原因的证据，而不是猜测。具体收费、价格、平台支持等信息暂未提供。