optimize

optimize skill 概览

optimize skill 是做什么的

optimize skill 是一份面向 UI 场景的性能优化指南，聚焦于前端性能问题的定位与改进。它会帮助 agent 判断为什么某个界面会让人感觉加载慢、操作卡、掉帧、顿挫或整体很“重”，并围绕加载、渲染、动画、图片和 bundle 体积提出有针对性的修复建议。如果你需要的是 optimize for Performance Optimization，而不是泛泛的代码审查，这个 skill 很适合。

哪些人适合安装 optimize

如果你在做 web app、产品 UI、落地页、dashboard 或交互式前端，并且想把“感觉有点慢”变成可量化、可落地的优化动作，就适合安装 optimize。它尤其适合开发者、产品工程师，以及使用 AI 辅助编码、能看出性能问题但暂时定位不到根因的工作流。

真实要解决的任务

大多数用户并不想听性能理论；他们真正想知道的是：

• 到底慢在哪里
• 应该怎么测
• 大概率是什么原因
• 先改哪些最有价值
• 改完之后怎么验证是否真的变好了

optimize skill 的设计就是围绕这条工作流展开的，而不是堆一堆泛化的性能建议。

为什么这个 skill 和普通 prompt 不一样

普通 prompt 往往会直接开始猜问题。optimize 更好的地方在于：它会先做测量、瓶颈隔离和优先级判断，再给出修复建议。这样能减少过早优化，也让输出更适合真实项目落地。

包含什么，不包含什么

这个 skill 的边界很明确，也因此更实用：它提供的是一套结构化的前端性能诊断与修复路径。当前 repo 快照里并没有附带脚本、benchmark 或框架专属自动化能力，所以你应该预期它提供的是指导和决策支持，而不是开箱即用的自动化工具。

如何使用 optimize skill

optimize 的安装与调用

使用下面的命令安装：
npx skills add https://github.com/pbakaus/impeccable --skill optimize

安装后，你可以让 agent 对某个明确目标使用 optimize，比如某个页面、流程、组件或应用区域：

• Use optimize on our homepage load performance
• Use optimize for checkout jank on mobile
• Use optimize on the dashboard bundle size

首次使用前，最合适的安装上下文

从 repo 现有信息来看，只有 SKILL.md，所以相比研究仓库结构，准备好实际场景上下文更重要。使用 optimize 之前，建议先整理好：

• 出问题的 URL、route 或 component
• 设备上下文：desktop、低端 mobile、慢网、特定浏览器
• 具体现象：加载慢、输入延迟、掉帧、CLS、bundle 过大
• 你已经拿到的测量结果，例如来自 Lighthouse、DevTools、RUM 或 profiler 的输出

如果没有这些上下文，skill 依然能提供帮助，但建议会更泛，可靠性也会下降。

先读这个文件

优先查看：

• SKILL.md

因为这个 skill 本质上是单文件指南，所以没有额外的规则或资源需要先读。这有利于快速上手，但也意味着你需要在 prompt 里提供更多项目级证据，效果才会更好。

optimize 需要什么输入，效果才好

想把 optimize usage 用好，关键在于提供具体证据。高质量输入通常包括：

• 当前指标：LCP、INP/FID、CLS、FCP、TTI、FPS、memory、CPU
• 范围边界：单个页面、单次交互、单段动画，或单个构建产物
• 如果已有判断，也可以附上怀疑原因
• 约束条件：不能迁移 framework、不能改 CDN、不能改 image pipeline 等
• 成功目标：比如“在 mobile 上把 LCP 降到 2.5s 以下”，就比“让它更快一点”更有效

把模糊请求改写成高质量 optimize prompt

较弱的写法：

• Make my app faster

更强的写法：

• Use optimize on our React product page. Mobile Lighthouse shows LCP 4.1s, CLS 0.18, bundle is 1.2MB JS, hero image is 2.4MB, and filtering interactions feel laggy on low-end Android. Prioritize fixes by impact and implementation cost, explain likely causes, and suggest how to re-measure after each change.

为什么这类写法更有效：

• 它定义了明确目标
• 它包含了测量数据
• 它限定了平台范围
• 它要求做优先级排序，而不是罗列一堆建议

一套实用的 optimize 工作流

一份好的 optimize guide 通常会按这个顺序展开：

1. 先测基线。
2. 把加载问题和运行时问题分开。
3. 找出最大的瓶颈。
4. 先做影响最大的修复。
5. 重新测量。
6. 只有在这之后，再处理次级优化项。

这也正是该 skill 最核心的建议：优化前后都要测，不要盲改。

optimize 最擅长处理哪些问题

这个 skill 特别适合处理：

• 首屏或初始页面加载慢
• 图片很多的页面
• JavaScript 或 CSS 体积过大
• 交互迟钝
• 动画卡顿
• layout thrashing 和 reflow 导致的 jank
• 网络请求过多

这些也是源内容里覆盖最明确的场景。

让 skill 输出什么格式最有用

为了提高决策质量，建议让 optimize 按结构化格式输出：

• diagnosis
• ranked bottlenecks
• recommended fixes
• expected impact
• tradeoffs
• verification plan

相比“列一些优化思路”，这种格式更适合你判断什么应该先做、什么值得上线。

能明显提升 optimize 使用效果的提示

建议让 skill 明确区分：

• 实验室指标（lab metrics）和真实用户症状
• desktop 与 mobile 的性能表现
• 首次访问与重复访问
• 网络瓶颈型问题与 CPU 瓶颈型问题
• 一次性高开销工作与重复性高开销工作

这些区分经常会直接改变正确解法。比如，图片压缩更适合网络受限的页面，而修复 layout thrash 更有助于提升运行时流畅度。

常见适配边界

这个 skill 的强项是“先给指导”，而不是深入到某个生态内部细节。如果你需要精确到 framework 内部机制、特定 bundler 命令，或者自动打补丁，就要把 optimize 和你自己代码库里的 repo 级上下文结合使用。它最适合在“已有足够证据可供推理”的前提下使用，而不适合默认假设它已经了解你的技术栈。

optimize skill 常见问题

optimize 适合新手吗？

适合，前提是你能提供症状和指标。这个 skill 的结构对新手比较友好，因为它从测量和优先级排序开始，而不是一上来就给结论。不过如果你是完全入门阶段，可能仍然需要先学会如何收集 DevTools 或 Lighthouse 数据，才能拿到更高质量的建议。

什么时候应该用 optimize，而不是普通 coding prompt？

当“性能优化”本身就是任务核心时，就应该用 optimize，而不是把它当成顺带提一句的要求。比如任务是“修复卡顿”“提升加载速度”或“降低 bundle 体积”，那么这个 skill 会比通用 prompt 更合适，因为它本来就是围绕“先诊断、后优化”的性能工作流构建的。

optimize 能替代 profiling 工具吗？

不能。optimize skill 是对 Lighthouse 和浏览器 profiler 这类工具的补充，不是替代品。它擅长帮助你解读结果、判断优先级，并把原始信号整理成可执行的行动方案。

optimize 只适用于 web 性能吗？

从源内容来看，它主要面向 UI 和 web 风格的性能问题：Core Web Vitals、图片、网络负载、渲染和动画。对于 backend 查询调优或基础设施延迟，它并不是首选。

什么情况下 optimize 不太合适？

以下情况建议跳过 optimize：

• 你没有明确的 UI 目标
• 问题完全在 backend
• 你想在没有测量的前提下直接拿“最佳实践”
• 你需要框架级实现细节，但又不给任何项目上下文

在这些场景下，输出很可能会过于泛化，难以支撑你做出有把握的改动。

这个 repo 里有额外参考资料或自动化能力吗？

当前快照里没有。仓库证据显示只有一个 SKILL.md，也没有支持目录。这让安装和上手都更简单，但同时也意味着，最终效果会更依赖你的 prompt 质量和本地测量数据。

如何提升 optimize skill 的效果

给 optimize 更好的证据，而不是更宽泛的目标

想最快提升 optimize 输出质量，最有效的方法不是提更大的目标，而是给更精准的输入：

• 精确页面或 route
• 指标数值
• 截图或复制出来的 profiler 结果
• 受影响的设备/网络环境
• 最近的性能回退或你怀疑的变更点

“首页很慢”得到的建议，通常不如“mobile LCP 在加入 autoplay video 和新的 analytics tag 后，从 2.6s 回退到 4.0s”来得有用。

让它按影响和成本做优先级排序

性能工作很容易迅速变得噪声很大。你可以明确要求 optimize 按以下维度对建议排序：

• 对用户体验的影响
• 置信度
• 实施成本
• 回归风险

这样能避免低价值的清理工作挤占真正的大收益项，比如超大图片或过量 JavaScript。

把加载优化和渲染优化分开看

一个常见失败模式，是把所有性能建议混在一起。更好的做法是一次只让 optimize for Performance Optimization 聚焦一个通道：

• loading：images、payloads、request count、code splitting
• rendering：reflows、paint cost、animation strategy、main-thread work

这样拆开之后，下一步通常会清晰很多。

尽早提供约束条件

直接告诉 skill 哪些事情你改不了：

• 不能迁移 CDN
• 不能重写 framework
• 这个 sprint 里不能改 image format
• 必须保留现有 animation 行为
• bundle 必须兼容 legacy browser targets

约束越明确，建议就越现实，也越能减少无效输出。

让 optimize 解释每个修复为什么重要

如果第一轮回答显得过于泛，可以继续要求它补充：

• 每个修复针对的是哪个瓶颈
• 它应该改善哪个指标
• 应该如何验证收益
• 存在哪些 tradeoff，比如 CPU 与带宽、流畅度与画质之间的取舍

这样更容易判断建议是否可信，也更容易正确实施。

第一轮之后继续迭代

最好的 optimize guide 使用方式，本质上是迭代循环：

1. 先拿到初始诊断
2. 先实施一到两个最高优先级修复
3. 收集新的测量结果
4. 带着前后对比数据再次运行 optimize

这样一来，这个 skill 就不再只是一次性给建议的工具，而会变成真正可用的优化闭环。

需要避免的常见失败模式

以下做法会明显削弱结果质量：

• 一上来就要“所有性能优化建议”
• 完全不给指标
• 把 backend、infra 和 frontend 问题混在一个请求里
• 不提供设备和网络上下文
• 在没有确认瓶颈前就先要修复方案

当问题边界清晰、且有证据支撑时，这个 skill 的表现最好。

如何拿到更接近可执行方案的输出

如果你想尽快得到能直接动手的改动建议，可以明确要求：

• 一份 top-3 fix list
• 结合你当前技术栈的代码级示例
• 一份测量检查清单
• 一份回滚或验证计划
• “这周最先该做什么”，而不是完整审计报告

这种提问方式更利于落地，因为它会把建议直接转化为可排期、可交付的实施计划。