optimize

optimize 技能概览

optimize 技能是做什么的

optimize 技能用于帮助代理诊断并改进 UI 性能问题，而不是靠猜测去做一些所谓的“提速优化”。它适合用于网站或应用出现加载慢、卡顿、掉帧、臃肿、响应迟缓等情况，重点关注通常最影响体验的几个方面：加载、渲染、动画、图片、bundle 体积，以及运行时行为。

谁适合使用 optimize

这个 optimize 技能最适合开发者、产品工程师、前端专项人员，以及需要对现有界面做一次务实性能排查的 AI 辅助编码工作流。它在你已经有明确页面、组件或交互表现需要检查时最有价值；如果你只是想要一些泛泛的性能建议，它就没那么合适。

这个技能真正解决的任务

用户通常不只是想“让它更快一点”。他们真正需要的是：

• 找到真实瓶颈，
• 避免过早优化，
• 选择对用户体验影响最大的改动，
• 并验证改动后性能是否真的改善。

这正是 optimize for Performance Optimization 比宽泛提示词更强的地方：它会把工作导向测量、瓶颈识别和有针对性的修复，而不是产出一堆泛化建议。

optimize 技能的差异化价值

这个技能最核心的区别在于范围控制很严格。它不会把性能当成一个模糊的大问题来谈，而是拆成可衡量的类别，比如 Core Web Vitals、加载时间、bundle 体积、动画流畅度、CPU 开销、内存使用和网络负载。这样一来，optimize 的使用路径在真实仓库里就更容易落地执行。

如何使用 optimize 技能

如何安装 optimize

通过你的 skills 工作流使用这个技能：

npx skills add pbakaus/impeccable --skill optimize

安装后，打开：

• SKILL.md

这个仓库提供的辅助材料比较精简，因此 SKILL.md 就是 optimize 使用指南和工作流的主要事实来源。

实际场景中什么时候调用 optimize

当用户提出类似下面的问题时，就可以调用 optimize：

• “页面加载很慢”
• “滚动时感觉很卡”
• “动画会掉帧”
• “bundle 太大了”
• “移动端性能很差”
• “能不能改善 Core Web Vitals？”

当任务涉及一个已有 UI，并且存在可观察到的性能变慢现象时，它非常适合。对于纯后端延迟、数据库调优或基础设施成本优化，这个技能就不是强项。

optimize 技能需要什么输入

如果你能提供以下信息，optimize 技能效果会最好：

• 目标页面、路由或组件，
• 具体哪里感觉慢，
• 问题出现的位置或场景，
• 设备或浏览器环境，
• 你已经拿到的测量数据，
• 以及你的约束条件。

好的输入示例：

• “Optimize the product listing page on mobile Safari; LCP is high and scroll stutters.”
• “Optimize our React dashboard initial load; bundle grew after adding charts.”
• “Optimize modal open/close animation; it drops frames on mid-range Android devices.”

较弱的输入：

• “Make the app faster.”

把模糊需求改写成高质量的 optimize 提示词

更强的 optimize 使用方式通常是：

1. 先说清目标对象。
2. 描述具体症状。
3. 提供证据。
4. 说明限制条件。
5. 要求按优先级给出修复建议。

示例提示词：
“Use the optimize skill on our /pricing page. Problem: slow first load on 4G and layout shifts after hero image loads. Current signals: LCP 4.1s, CLS 0.19, JS bundle increased after adding testimonials carousel. Constraints: keep design unchanged, no framework migration. Please identify likely bottlenecks, rank fixes by impact, and propose code-level changes.”

这种提示词能给代理足够上下文去做真正的性能分诊，而不是输出一份模板化建议清单。

先测量，再修复

这个技能里最关键的一条原则，本质上就是：先测前后数据，再谈优化。在实际使用中，这意味着你的 optimize 工作流应该从现状评估开始：

• Core Web Vitals：LCP、INP/FID、CLS
• 首次绘制与可交互时间，
• bundle 和静态资源体积，
• 帧率与运行时开销，
• 请求数量和 waterfall 模式。

如果跳过这一步，输出质量会明显下降，因为代理只能靠猜测去推断瓶颈。

optimize 技能通常会检查哪些方面

从源码内容来看，optimize 技能主要围绕这些性能维度展开：

• 加载性能，
• 渲染性能，
• 图片优化，
• 动画流畅度，
• JavaScript 和 CSS 体积，
• 网络与载荷效率。

因此，它特别适合做前端性能审计，以及制定有针对性的修复方案。

optimize 的推荐使用流程

一个实用的工作流是：

1. 确定哪个页面或交互存在性能问题。
2. 收集测量数据或可复现信息。
3. 带着目标和症状调用 optimize。
4. 审查它提出的瓶颈判断和修复建议。
5. 先落地高收益、低风险的改动。
6. 重新测量。
7. 针对剩余瓶颈继续迭代。

这个顺序更贴近用户真正关心的结果：用更少的无效重构，换来更快的实际改善。

想更快上手，建议这样读仓库

对于这个技能，除了 SKILL.md 之外几乎没有太多额外结构，所以最好的阅读路径很简单：

1. 先看 SKILL.md 了解范围和工作流
2. 优先看 “Assess Performance Issues” 这一节
3. 再看 loading、rendering 等优化分类

这是一个相对紧凑的技能，上手门槛不高；但也正因为内容精简，你需要自己补上工具链和仓库内的具体证据。

高质量的 optimize 输出应该长什么样

一个有用的 optimize 结果，通常应该包含：

• 最可能的瓶颈是什么，
• 它为什么会影响用户体验，
• 应该如何验证，
• 可以采取哪些修复方案，
• 以及这些方案的优先级排序。

例如，“convert oversized hero images to AVIF/WebP” 这种建议，如果能配上“当前图片宽度为 3000px，但在移动端实际只以 360px 渲染，正在拖慢 LCP”，价值就会高很多。

一开始就该说明的常见约束

为了获得更好的 optimize 安装与使用效果，最好提前告诉代理你必须保留哪些条件，比如：

• 框架选择，
• 视觉设计，
• SEO 行为，
• 动画风格，
• 浏览器支持范围，
• analytics 脚本，
• 或第三方组件。

性能建议会因为你能不能删代码、延后脚本、调整图片分发方式、简化 UI 行为而发生明显变化。

optimize 技能 FAQ

做性能优化时，optimize 比普通提示词更好吗？

通常是的，前提是你面对的是一个真实的 UI 性能问题。普通提示词往往会直接跳到随机修复建议上，而 optimize 技能更有用，因为它会先围绕诊断来组织任务，再进入有针对性的干预。

optimize 只适用于前端 Web 应用吗？

大体上是。optimize 技能的中心非常明确，就是 UI 性能：加载速度、渲染、动画、图片、bundle 体积，以及用户感知到的流畅度。对于数据库、队列或服务器调优，它并不是首选工具。

使用前必须先有 Lighthouse 或 Web Vitals 数据吗？

不必须，但有的话帮助很大。你仍然可以用基于症状的输入来使用 optimize，不过最好的结果通常来自实际测量数据，或者至少一条稳定的复现路径。

新手也能用 optimize 技能吗？

可以，前提是能把页面和症状描述清楚。这个技能会提供结构化思路，但新手通常仍然需要额外帮助来收集证据，以及落地和框架相关的修复方案。

什么情况下不该使用 optimize？

遇到以下情况时，可以跳过这个 optimize 指南：

• 问题纯粹是后端延迟，
• 问题本质上不是性能而是可用性，
• 你需要的是架构层面的扩展建议，
• 或者你根本没有明确的目标页面、流程或症状可供检查。

optimize 技能会自动修改代码吗？

这个技能本身更偏向指导与分析。在 AI 编码工作流里，它可以驱动代码修改，但这些修改的质量取决于你提供了多少仓库上下文、测量数据和约束信息。

如何改进 optimize 技能的使用效果

给 optimize 一个具体目标，而不是整个应用

想提高 optimize 结果质量，最快的方法就是缩小范围。比如“Optimize checkout page submit flow on low-end Android” 远比“optimize my app”有效。目标越清晰，猜测越少，输出也越容易直接执行。

同时提供用户可感知症状和技术信号

最好把定性和定量信息配在一起：

• “scroll stutters after opening filters”
• “INP regressed to 280ms”
• “hero image loads late”
• “bundle grew by 400 KB after adding editor”

这种组合能帮助 optimize 技能把指标和根因更好地关联起来。

让它给出分级排序的建议

一个好的提示词应该要求代理区分：

• 高影响、见效快的 quick wins，
• 中等投入的改进项，
• 以及侵入性较强的改动。

这样 optimize for Performance Optimization 会更利于决策，尤其适合无法承担大规模重写的团队。

提前说明会影响修复方案的约束

在以下条件成立时，性能建议会明显不同：

• 必须使用 SSR，
• 设计不能改，
• 第三方脚本必须保留，
• 图片质量必须维持较高水准，
• 或动画表现本身就是产品体验的一部分。

如果你不说明这些限制，optimize 技能可能会给出技术上成立、但在你环境里根本无法采用的建议。

要求给出优化前后的验证步骤

不要停留在“把修复方案应用上去”这一步。应该要求这个技能明确说明改完之后要重新测什么：

• 哪个指标应该改善，
• 去哪里检查，
• 以及什么样的阈值算成功。

这是提升 optimize 使用质量时最实用的一项升级。

留意 optimize 常见失效模式

在以下情况下，optimize 技能最容易表现不佳：

• 提示词里没有明确目标，
• 没有提供任何测量数据，
• 多个页面的症状混在一起，
• 或者要求代理一次性优化所有东西。

另一个常见失效点是过度盯着 bundle 体积不放，而真实问题其实是布局抖动、媒体资源过大，或脚本执行成本过高。

不要只要建议清单，要它解释根因

如果你第一次拿到的结果很泛，可以继续这样追问：
“Use the optimize skill again, but identify the top two likely root causes for this page and explain why they are more probable than the others.”

这样能把输出从 checklist 模式推向真正的诊断模式。

第一次优化后继续迭代

在实际工作中，最佳的 optimize 使用方式通常是循环迭代：

1. 先修掉最大瓶颈，
2. 重新测量，
3. 暴露出下一层约束，
4. 再次优化。

性能问题很少一次就彻底解决；把这个技能当作循环工具来用，而不是一次性命令，它的价值会更大。