性能剖析Skill：遵循「测量—分析—优化」的固定顺序，把性能问题从猜测变成可验证的结论
- 它是什么：性能剖析Skill（英文名 performance-profiling，技能ID 12167）是一套内置在 AI 助手里的性能工程方法论与执行流程，核心原则只有一句话——“测量、分析、优化，按此顺序”。
- 能做什么：覆盖核心 Web 指标（LCP / INP / CLS）判定、四步剖析工作流、包体积分析、运行时与内存剖析、常见瓶颈对照和快速见效的优先级清单。
- 特色能力：自带运行时脚本
scripts/lighthouse_audit.py，可直接对目标网址跑一次 Lighthouse 性能审核，把“凭感觉优化”变成“拿数据说话”。 - 适合谁用：前端工程师、全栈开发者、独立开发者，以及需要给线上页面做性能审查、但又不想每次都手动打开一堆工具的人。
- 一句话价值：让你在动手改代码之前，先知道瓶颈到底在哪里——因为最快的代码是不运行的代码，优化前先移除。
1. 该技能叫什么？如何下载安装 AI 技能提升开发效率？
技能基本信息
| 项目 | 内容 |
|---|---|
| 中文名 | 性能剖析Skill |
| 英文名 | performance-profiling |
| 技能ID | 12167 |
| 官方描述 | 性能剖析原则。测量、分析和优化技术。 |
| 声明可用的工具权限 | Read（读取文件）、Glob（文件匹配）、Grep（内容检索）、Bash（执行命令） |
它到底解决什么问题
大多数性能优化工作都以错误的方式开始：先猜测、再改代码、最后发现没有变快，甚至连“有没有变快”都说不清。这个技能把工程实践中被反复验证的顺序固化成流程：
- 先有基线：没有测量结果，就没有优化依据；
- 再找瓶颈：用剖析工具定位到具体环节，而不是逐行检查代码；
- 只改关键点：修最大的问题，不做微优化；
- 最后验证：改完必须复测，确认改进真实存在。
同时它还给出了明确的判定标准（例如 LCP < 2.5s 为 Good、> 4.0s 为 Poor），让“快”和“慢”从主观感受变成可以对照的客观指标。
一键安装 AI 技能的思路与步骤
安装前提
- 你使用的 AI 编程助手或客户端需要支持“AI 技能（Skill）”机制，能够按技能ID或技能包导入能力；
- 由于技能声明了 Bash 权限并包含
scripts/lighthouse_audit.py脚本，本地需要具备可执行 Python 脚本的运行环境； - 技能会读取项目文件（Read / Glob / Grep），建议在具体项目目录下启用，而不是在整个磁盘根目录下使用。
安装步骤（通用流程）
- 打开你所使用 AI 助手或客户端中的「技能 / Skill」管理入口（常见形式为技能市场、技能中心或插件管理）；
- 通过技能ID 12167 或技能名 performance-profiling 搜索并添加该技能；
- 按提示确认授予其声明的工具权限（读取文件、文件匹配、内容检索、执行命令）；
- 确认脚本目录
scripts/已在技能包内正确加载，以便后续执行lighthouse_audit.py； - 保存并启用技能。
不同平台的具体入口名称、按钮位置与授权方式存在差异，具体以官方说明为准。本文不提供任何未经确认的下载链接或价格信息。
验证是否生效
启用后，可以用一句自然语言请求做快速自检，例如：
“用性能剖析技能，说明你的四步剖析工作流，并告诉我 LCP 的 Good 阈值是多少。”
如果技能生效，它应当能明确回答出 BASELINE → IDENTIFY → FIX → VALIDATE 这四个步骤，以及 LCP < 2.5s 为 Good。若回答含糊或答不上来，通常说明技能未被正确加载或权限未授予。
进一步验证脚本能力，可以请求：
“运行 lighthouse_audit.py 对 https://example.com 做一次性能审核。”
预期它会调用 Bash 执行 python scripts/lighthouse_audit.py https://example.com 并返回性能审核结果。
2. 该技能的主要功能和特点
- 核心 Web 指标判定标准内置：直接给出 LCP、INP、CLS 三个指标的 Good / Poor 阈值与各自衡量的维度（加载、交互性、稳定性），避免“凭感觉判断页面快不快”。
- 分阶段测量建议：明确开发阶段用本地 Lighthouse、CI/CD 阶段用 Lighthouse CI、生产环境用 RUM（真实用户监控），解决“只在本地跑一遍就以为线上也快”的常见误区。
- 四步剖析工作流：BASELINE（测量当前状态）→ IDENTIFY（找到瓶颈）→ FIX（做出有针对性的更改）→ VALIDATE（确认改进），把优化变成可复现的闭环。
- 按问题选工具的对策表：页面加载→Lighthouse；包大小→包分析器；运行时→DevTools 性能面板；内存→DevTools 内存面板；网络→DevTools 网络面板。不用再纠结“这个症状该看哪个面板”。
- 包体积分析清单：把“大型依赖项放在包顶部、重复代码出现在多个块、未使用代码、缺失分割导致单个大块”等特征与对应动作（按需导入特定模块、去重并更新版本、路由代码分割、树摇）一一对应。
- 运行时与内存剖析解读：长任务（> 50ms）代表 UI 阻塞、许多小任务可能意味着批处理机会、布局/绘制是渲染瓶颈、脚本耗时是 JavaScript 执行问题；内存侧则关注增长堆（疑似泄漏）、大型保留对象、分离的 DOM 节点未清理。
- 按症状反查病因：初始加载慢→大体积 JS 与渲染阻塞；交互慢→重事件处理程序；滚动卡顿→布局抖动；内存持续增长→泄漏与保留引用。
- 带优先级的“快速见效”清单：启用压缩 → 懒加载图像 → 路由代码分割 → 缓存静态资产 → 优化图像，并标注高/中影响，让团队先做性价比最高的事。
- 反模式警示：不要猜测问题、不要做微优化、不要过早优化、不要忽略真实用户数据，四条反面清单直接写在技能里，用来纠正团队习惯。
和普通工具相比，它的差异化优势在哪里？
Lighthouse、DevTools 这类工具本身非常强大，但它们只提供“数据面板”，不提供“决策路径”：面对一堆瀑布图和火焰图，经验不足的人依然不知道该先改哪里。这个技能的价值在于把工具输出的解读能力和优化优先级判断一起交付给 AI 助手，你不需要先成为性能专家，也能按照固定流程从测量走到验证。
3. 如何使用该技能？
以下为分步骤使用指南，输入示例均可直接参考改写。
步骤一：先建立基线（BASELINE）
在项目目录下唤起技能，用自然语言描述你的目标与现状，例如：
“用性能剖析技能帮我建立性能基线。项目是 React 单页应用，首页首屏加载慢，请告诉我该测哪些指标、用什么工具测。”
预期输出：它会给出 LCP / INP / CLS 三个指标及其阈值，并根据你的场景（开发 / CI / 生产）推荐对应测量方式。
如需直接拿到页面数据，可请求执行运行时脚本：
“运行 scripts/lighthouse_audit.py 对 https://example.com 做一次审核，然后把结果按 LCP、INP、CLS 三项整理成表格，并标注每一项处于 Good 还是 Poor。”
技能对应执行：python scripts/lighthouse_audit.py https://example.com。
步骤二：定位瓶颈（IDENTIFY）
把现象描述清楚，让技能把“症状”映射到“病因”和“工具”：
“页面首次加载需要 6 秒，但点击按钮后响应还算正常。按性能剖析技能的思路，我应该先看哪个方向？”
预期输出：它会指向“初始加载慢”的典型原因（大型 JS、渲染阻塞），并建议先用 Lighthouse 看加载链路、用包分析器看产物体积。
涉及代码时，可以配合 Grep / Glob 让技能直接读项目：
“帮我检查这个项目的依赖入口文件，找出体积最大的依赖，并判断是否存在全量导入整个库的情况。”
步骤三：做出有针对性的修改（FIX）
按照技能给出的“快速见效优先级”行动，例如：
“按优先级给出三步改造方案：一是启用压缩，二是路由代码分割，三是图片懒加载。分别说明改哪里、大概影响多大。”
预期输出：会给出高影响优先的动作顺序（压缩 → 图片懒加载 → 路由代码分割 → 静态资源缓存 → 图片优化），并对应到具体代码位置建议。
步骤四：验证改进（VALIDATE）
改完后必须复测，这是该技能最强调的一环：
“改完代码后，再跑一次 lighthouse_audit.py，和之前的基线对比，告诉我 LCP 和 CLS 是否有改善，改善是否达到 Good 阈值。”
预期输出：给出改造前后的数值对比，并判断是否越过 < 2.5s（LCP）、< 0.1（CLS）等阈值。
输入输出小结
| 你的输入类型 | 技能给你的输出 |
|---|---|
| 现象描述（“加载慢”“滚动卡”“内存涨”） | 症状 → 病因 → 推荐工具 的对照结论 |
| 请求执行脚本 | 调用 python scripts/lighthouse_audit.py <网址> 并整理结果 |
| 项目代码路径 | 读取依赖入口、识别大依赖与重复依赖 |
| 改造后的复测请求 | 基线与现状的对比判定 |
提示：像“帮我优化一下性能”这样的模糊请求，通常只会得到泛泛而谈的答案。把页面地址、指标现状、目标阈值说清楚，输出质量会明显提升。
4. 同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 性能剖析Skill（本次介绍） | AI 助手内的性能剖析方法论 + 流程编排 | 核心指标阈值、四步工作流、包分析清单、运行时/内存解读、快速见效优先级、Lighthouse 审核脚本 | 需支持 Skill 的客户端；需授予文件读取与命令执行权限；脚本需 Python 环境 | 想要“照着流程走”就能完成一次完整性能排查的开发者 | 优势：把工具解读和优先级判断交给 AI，上手门槛低，流程闭环完整；不足：本身不采集 RUM 生产数据，深度火焰图分析仍需 DevTools 配合 |
| Lighthouse / Lighthouse CI | 官方自动化性能审核工具 | 生成性能、可访问性、最佳实践、SEO 报告，支持 CI 集成 | 需命令行安装或浏览器内置；CI 需额外配置 | 开发阶段自查、流水线卡点 | 优势：数据权威、指标标准一致；不足：只产出报告，不告诉你“先改哪一处” |
| Chrome DevTools 性能与内存面板 | 浏览器级运行时剖析 | 火焰图、长任务、布局/绘制耗时、堆快照、分离 DOM 检测 | 浏览器内置，零安装；但学习曲线陡 | 深度定位运行时卡顿与内存泄漏 | 优势：细节最丰富、最贴近真实执行；不足：数据密度高，新手容易迷失，缺乏优化优先级建议 |
| 包分析器（如打包产物体积分析工具） | 产物体积可视化 | 展示各依赖体积占比、重复模块、未使用代码 | 需接入构建流程并安装依赖 | 减小包体积、定位大依赖 | 优势：对“包太大”这类问题极其直观；不足：只覆盖包体积一个维度，无法解释交互卡顿与内存问题 |
| WebPageTest / PageSpeed Insights 等在线测速服务 | 外部网络条件测速与评分 | 多地区、多设备、多网络条件的加载测量与建议 | 零安装，浏览器打开即用 | 上线前验收、跨地域体验评估 | 优势：无需本地环境；不足：受网络环境影响波动较大，且不便嵌入日常开发流程 |
如何选：如果你已经有工具但缺乏“下一步该做什么”的判断，用性能剖析Skill 做流程串联；如果你需要最细的火焰图细节，回到 DevTools；如果你要在流水线上做卡点，用 Lighthouse CI。
5. 该技能的典型应用场景与实际体验情况
场景一：前端工程师接手“首页加载 6 秒”的历史项目
痛点：代码是别人写的，依赖一大堆，不知道从哪下手，改了几天没有明确收益。 使用方式：先用技能跑一次基线，拿到 LCP 数值；再用包分析清单对照“大型依赖项、重复代码、未使用代码、缺失分割”四项逐一核对；按快速见效优先级（压缩 → 图片懒加载 → 路由分割）依次改造；最后复测对比。 实际体验：上手几乎没有门槛，因为你不需要先懂火焰图，只要按四步顺序走。效果上最明显的是它会把注意力从“逐行审查代码”强制拉回“先测再说”。注意事项：包分析的具体工具需要结合项目构建体系，技能给的是判断清单和方法，不是一键改代码。
场景二：独立开发者上线前做一次性能自查
痛点：没有性能团队，也没有预算，全凭“自己打开感觉还行”。
使用方式：请求执行 python scripts/lighthouse_audit.py https://example.com，把 LCP / INP / CLS 三项对照 Good / Poor 阈值逐项判断，优先处理落到 Poor 区间的那一项。
实际体验：脚本调用是最省事的一环，一次请求就能拿到结构化结果。注意事项：本地测量受机器性能与网络影响，最好固定环境多次测量；线上真实体验仍应以 RUM 数据为准，这也是技能里明确写到的分阶段原则。
场景三：团队处理“滚动时卡顿、内存持续增长”的疑难问题
痛点：用户反馈卡，但本地复现不稳定，团队里没人能说清是渲染问题还是内存泄漏。 使用方式：把症状描述给技能——“滚动时卡顿、长时间使用后内存持续增长”，它会先按症状表给出方向（滚动卡顿指向布局抖动；内存增长指向泄漏与保留引用），再指导在 DevTools 性能面板看长任务与布局/绘制耗时，在内存面板看增长堆、大型保留对象和分离的 DOM。 实际体验：症状到病因的对照表非常实用，能快速缩小排查范围，避免在错误的面板里浪费时间。注意事项：内存部分最终仍需人工读取堆快照、确认引用链，技能负责指路而非替代分析。
场景四：技术负责人制定“性能优化第一批任务”
痛点：优化需求一堆，团队不知道先做哪个，容易陷入“微优化”消耗。 使用方式：直接请求技能输出“按优先级排序、并标注影响的优化清单”，它会给出启用压缩（高）、懒加载图像（高）、路由代码分割（高）、缓存静态资产（中）、优化图像（中）的执行顺序，同时用反模式清单规避“过早优化”“猜测问题”。 实际体验：这张优先级表最大的价值不是技术含量，而是统一团队语言——所有人对“先做哪个”有共同依据。注意事项：优先级是通用建议，具体项目仍需结合自身瓶颈数据调整。
6. 该技能能为用户带来的价值
- 把优化从“猜”变成“测”：四步工作流强制先建立基线，收益是可量化的——优化前后可以拿出 LCP、INP、CLS 的具体数值做对比，而不是“感觉快了一些”。
- 降低性能优化的门槛：不需要先读完几十篇性能文章，只要会描述症状，就能拿到“病因方向 + 该看哪个工具 + 该改哪一处”的建议，新人也能独立完成一次完整排查。
- 减少无效劳动：反模式清单直接点明“不要微优化、不要过早优化、不要猜测问题”，避免团队把时间花在对整体体验没有感知收益的地方。
- 统一判定标准：LCP < 2.5s、INP < 200ms、CLS < 0.1 这些阈值写死在技能里，评审时有共同语言，减少“我觉得还行”的争论。
- 缩短定位瓶颈的时间：症状到病因的对照表、按问题选工具的对策表，把“该先看哪里”这一最耗时的决策环节压缩成一两句话。
- 长期价值：技能传递的是一种可复用的工程习惯——“最快的代码是不运行的代码，优化前先移除”。习惯一旦建立，后续每一个项目都会受益，而不只是修好这一次的慢页面。
7. 常见问题 FAQ
Q1：这个技能怎么安装？需要什么前提条件？
A：在支持 AI 技能机制的客户端或助手中，通过技能ID 12167 或技能名 performance-profiling 搜索添加，并按提示授予它声明的 Read / Glob / Grep / Bash 权限。由于包含 scripts/lighthouse_audit.py 脚本，本地需要可执行 Python 脚本的环境。各平台入口与授权细节存在差异，以官方说明为准。
Q2：它是收费的吗？
A：技能详情中未提及任何价格或订阅信息，本文无法确认收费情况。请以你所使用平台的官方说明与技能页面标注为准。
Q3：安装了这个技能，是不是就能自动帮我把页面变快？
A：不是。它的定位是“性能剖析原则与技术”，提供的是判定标准、工作流、工具选择建议和优化优先级判断，帮助你更快找到瓶颈并做对事情。真正的代码修改、依赖升级、构建配置调整仍需要你（或 AI 助手在读取项目代码后给出建议）来完成。
Q4：它和 Lighthouse、DevTools 是什么关系？会不会重复？
A：不重复，是互补。Lighthouse 和 DevTools 负责采集数据，这个技能负责解读数据并决定下一步做什么，并且它自身就能通过 scripts/lighthouse_audit.py 调用 Lighthouse 完成审核。典型用法是：技能编排流程 → 用 Lighthouse 看加载、用包分析器看体积、用 DevTools 看运行时与内存 → 回到技能判断优先级 → 复测验证。
Q5：什么情况下不适合用这个技能？
A：如果你需要的是线上真实用户的分阶段 RUM 数据看板，或者需要极细粒度的火焰图逐帧分析，这些能力不在该技能的范围内，应直接使用对应的监控平台与 DevTools。此外，技能明确反对“过早优化”——在没有实际性能需求时，不建议为了“可能变快”而提前改造代码。