القائمة
性能分析原则。测量、分析与优化技术。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
务实的编码标准—— 简洁、直接、不做过度设计、不写无用注释（Pragmatic coding standards）
API design principles and decision-making（API 设计原则与决策逻辑）。REST vs GraphQL vs tRPC selection（选择）、response formats（响应格式）、versioning（版本控制）、pagination（分页）。
App Builder（应用构建编排器）主编排器。根据自然语言请求创建全栈应用，确定项目类型、选择技术栈并协调智能体。
Project scaffolding templates（项目脚手架模板）。用于从零创建新项目。包含 12 个技术栈模板。
Architectural decision-making framework（架构决策框架）。Requirements analysis（需求分析）、trade-off evaluation（权衡评估）、ADR documentation（架构决策记录）。Use when making architecture decisions or analyzing system design（用于架构决策与系统设计分析）。
AI（人工智能）运行模式（BRAINSTORM、IMPLEMENT、DEBUG、REVIEW、TEACH、SHIP、ORCHESTRATE）。用于根据任务类型自动调整 AI 行为逻辑。
| name | performance-profiling |
| description | 性能分析原则。测量、分析与优化技术。 |
| allowed-tools | Read, Glob, Grep, Bash |
测量、分析、优化 —— 必须严格遵循此顺序。
执行以下脚本进行自动化性能分析：
| 脚本 | 用途 | 执行命令 |
|---|---|---|
scripts/lighthouse_audit.py | Lighthouse（性能审计工具）审计 | python scripts/lighthouse_audit.py https://example.com |
核心 Web 指标（Core Web Vitals）用于衡量加载与交互质量。
| 指标 | 优（Good） | 劣（Poor） | 衡量维度 |
|---|---|---|---|
| LCP | < 2.5s | > 4.0s | 加载体验 |
| INP | < 200ms | > 500ms | 交互响应 |
| CLS | < 0.1 | > 0.25 | 视觉稳定性 |
| 阶段 | 工具选择 |
|---|---|
| 开发环境（Development） | 本地 Lighthouse |
| CI/CD 流程 | Lighthouse CI（持续集成） |
| 生产环境（Production） | RUM（真实用户监控，Real User Monitoring） |
1. 建立基准（Baseline）-> 测量当前状态
2. 识别瓶颈（Identify）-> 找出性能卡点
3. 实施修复（Fix） -> 进行针对性改动
4. 验证改进（Validate）-> 确认性能提升
| 待解决问题 | 推荐工具 |
|---|---|
| 页面加载速度 | Lighthouse |
| 打包体积（Bundle size） | Bundle analyzer（包分析器） |
| 运行时性能 | DevTools（开发者工具）Performance（性能）面板 |
| 内存占用 | DevTools（开发者工具）Memory（内存）面板 |
| 网络请求 | DevTools（开发者工具）Network（网络）面板 |
| 潜在问题 | 识别指标 |
|---|---|
| 巨大的外部依赖 | 位于打包产物顶部 |
| 冗余/重复代码 | 存在于多个 Chunk（代码块）中 |
| 未使用的代码 | 低覆盖率（Coverage） |
| 缺失分包（Splitting） | 产物呈现为一个巨大的单体文件 |
| 发现的问题 | 对应动作 |
|---|---|
| 库文件过大 | 按需导入（Import specific modules） |
| 依赖项重复 | 去重（Dedupe）、更新版本 |
| 主包代码包含路由逻辑 | 实施代码分割（Code split） |
| 存在未引用的导出 | 启用 Tree shake（摇树优化） |
| 模式 | 含义 |
|---|---|
| 长任务（Long tasks > 50ms） | 会导致 UI 阻塞 |
| 密集的小任务 | 可能存在批处理（Batching）的机会 |
| 布局/绘制（Layout/paint） | 渲染层的瓶颈 |
| 脚本执行（Script） | JavaScript（脚本语言）执行开销过高 |
| 模式 | 含义 |
|---|---|
| 堆内存持续增长（Growing heap） | 可能存在内存泄漏 |
| 被持有的对象过多（Retained） | 检查引用关系 |
| Detached DOM（脱离文档树的 DOM，Document Object Model） | 未被正确清理 |
| 症状表现 | 可能的原因 |
|---|---|
| 首次加载缓慢 | JS 体积过大、渲染阻塞（Render blocking） |
| 交互卡顿 | 事件处理器（Event handlers）逻辑过重 |
| 滚动时的掉帧（Jank） | 布局抖动（Layout thrashing） |
| 内存持续上升 | 内存泄漏、未释放的引用 |
| 优先级 | 动作 | 预期影响 |
|---|---|---|
| 1 | 开启资源压缩（Gzip/Brotli，压缩算法） | 高 |
| 2 | 图片懒加载（Lazy load） | 高 |
| 3 | 路由层级的代码分割 | 高 |
| 4 | 配置静态资源缓存 | 中 |
| 5 | 图片压缩与格式优化 | 中 |
| [FAIL] 禁止（Don't） | [OK] 推荐（Do） |
|---|---|
| 凭空猜测性能问题 | 优先进行性能分析（Profile first，先分析） |
| 进行微比例优化（Micro-optimize） | 优先修复最大的性能卡点 |
| 过早优化 | 在真正需要的时候再优化 |
| 忽视真实用户的体验 | 参考 RUM 数据 |
谨记： 最快的代码是那些根本不需要运行的代码。在着手优化之前，先考虑是否可以移除。