菜单
前后端性能分析技能：定位瓶颈、跑 benchmark、对比优化前后效果。 前端覆盖 Core Web Vitals（LCP/FID/CLS）、Lighthouse 审计、Bundle 分析。 后端覆盖 API 响应时间、数据库查询性能、内存/CPU profiling。 核心原则：基于数据定位瓶颈，不做无依据的"优化"。 触发词：性能优化、太慢了、性能分析、LCP、首屏、响应时间慢、profiling、benchmark。 触发场景：性能相关需求验收、用户反馈慢、性能指标超标、重构后性能回归验证。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | perf-profiling |
| version | 1.0.0 |
| last_updated | "2026-04-08T00:00:00.000Z" |
| repository | https://github.com/312362115/claude |
| description | 前后端性能分析技能：定位瓶颈、跑 benchmark、对比优化前后效果。 前端覆盖 Core Web Vitals（LCP/FID/CLS）、Lighthouse 审计、Bundle 分析。 后端覆盖 API 响应时间、数据库查询性能、内存/CPU profiling。 核心原则：基于数据定位瓶颈，不做无依据的"优化"。 触发词：性能优化、太慢了、性能分析、LCP、首屏、响应时间慢、profiling、benchmark。 触发场景：性能相关需求验收、用户反馈慢、性能指标超标、重构后性能回归验证。 |
优化的前提是度量。不知道慢在哪，就不知道该优化哪。 每次优化都要有"前"和"后"的数据对比，否则不算优化。
性能问题
│
├─ 前端性能？（页面加载慢、交互卡顿、首屏慢）
│ └─ 前端分析流程
│
├─ 后端性能？（API 响应慢、数据库查询慢、CPU/内存高）
│ └─ 后端分析流程
│
└─ 不确定？
└─ 先用浏览器 DevTools Network 面板判断瓶颈在前端还是后端
用 AskUserQuestion 确认：
| 指标 | 含义 | 达标 | 需改进 | 差 |
|---|---|---|---|---|
| LCP | 最大内容绘制 | ≤2.5s | ≤4s | >4s |
| INP | 交互到下一次绘制 | ≤200ms | ≤500ms | >500ms |
| CLS | 累计布局偏移 | ≤0.1 | ≤0.25 | >0.25 |
度量工具：
# Lighthouse CLI（如果可用）
npx lighthouse <url> --output=json --output-path=./lighthouse-report.json
# 或用 Playwright 采集性能数据
# 通过 MCP playwright 工具访问页面并执行 performance API
# Webpack
npx webpack-bundle-analyzer stats.json
# Vite
npx vite-bundle-visualizer
# Next.js
ANALYZE=true next build
关注点：
| 瓶颈 | 诊断方式 | 优化方向 |
|---|---|---|
| 首屏大图/大资源阻塞 LCP | Lighthouse / Network 瀑布图 | 懒加载、压缩、CDN、preload 关键资源 |
| JS Bundle 过大 | Bundle 分析 | Code splitting、tree shaking、动态导入 |
| 未优化图片 | Lighthouse 图片审计 | WebP/AVIF、响应式图片、压缩 |
| 布局抖动导致 CLS | Lighthouse CLS 审计 | 固定尺寸占位、字体预加载 |
| 大量 DOM 操作 | Performance timeline | 虚拟列表、减少重排、requestAnimationFrame |
| 第三方脚本阻塞 | Network + Coverage | 延迟加载、异步加载、移除不必要的三方脚本 |
# 简单测量（单次）
time curl -s -o /dev/null -w "%{time_total}" <api-url>
# 并发测试（如 wrk 可用）
wrk -t4 -c100 -d30s <api-url>
# 或用 Node.js 脚本测量
node -e "
const start = Date.now();
fetch('<api-url>').then(() => console.log(Date.now() - start + 'ms'));
"
记录关键指标：
-- MySQL/PostgreSQL 查询分析
EXPLAIN ANALYZE <your-query>;
// Node.js ORM 慢查询日志
// Prisma: 在 PrismaClient 初始化时开启
const prisma = new PrismaClient({ log: ['query', 'warn', 'error'] });
// Sequelize: 开启 benchmark
const sequelize = new Sequelize({ benchmark: true, logging: console.log });
关注点：
Node.js：
# CPU profiling
node --prof app.js
node --prof-process isolate-xxx.log > processed.txt
# 内存快照
node --inspect app.js
# 然后在 Chrome DevTools 中 Take Heap Snapshot
Python：
# cProfile
python -m cProfile -s cumtime app.py
# memory_profiler
pip install memory_profiler
python -m memory_profiler app.py
| 瓶颈 | 诊断方式 | 优化方向 |
|---|---|---|
| 数据库查询慢 | EXPLAIN ANALYZE | 加索引、优化查询、减少 N+1 |
| 序列化/反序列化开销 | profiling | 减少响应字段、分页、缓存 |
| 外部 API 调用阻塞 | timing 日志 | 并行调用、缓存、超时控制 |
| 内存泄漏 | 内存快照对比 | 排查未释放的引用、闭包 |
| CPU 密集计算 | CPU profiling | Worker 线程、缓存计算结果 |
| 连接池耗尽 | 连接池监控 | 调整池大小、检查连接泄漏 |
在做任何改动之前，必须记录当前性能数据：
## 性能基线（优化前）
| 指标 | 值 | 测量条件 |
|------|-----|---------|
| LCP | 3.8s | 首页，Chrome，4G 模拟 |
| API /users 响应 | p95: 450ms | 100 并发，30s |
| 数据库查询 | 320ms | users 表 10 万行 |
每次优化后，用相同条件重新测量，对比前后：
## 优化效果对比
| 指标 | 优化前 | 优化后 | 改善 |
|------|--------|--------|------|
| LCP | 3.8s | 1.9s | -50% ✅ |
| API /users p95 | 450ms | 120ms | -73% ✅ |
| Bundle 大小 | 2.1MB | 890KB | -58% ✅ |
完整性能分析后，输出报告到 docs/specs/ 或直接在对话中给出：
# 性能分析报告：<模块/页面>
## 问题描述
用户反馈/指标异常的具体描述
## 分析结论
瓶颈在哪，为什么慢
## 优化措施
| # | 措施 | 预期效果 | 实际效果 |
|---|------|---------|---------|
## 性能对比
基线 vs 优化后
## 后续建议
还可以进一步优化的方向
task-execute 执行中发现性能问题 → perf-profiling（分析定位）
refactoring 重构后 → perf-profiling（回归验证，确认性能没退化）
release 发版前 → perf-profiling（性能相关需求的验收）
通用写作技能：以"内容→组件→组合"的方式产出技术文档、产品文档、汇报材料。 覆盖 spec / plan / PRD / 用户手册 / 项目汇报 / 方案路演 / 调研报告 等所有结构化文档场景。 核心理念：组件驱动，不预设模板。先看内容形态，再挑能装这种形态的组件， 组合自然成文——不强制章节结构、不预设"必备模块"。 组件库（HTML / Markdown / 图示）见 references/components.md， 常见组合范式（spec / plan / PRD 等）见 references/templates/——但模板是参考不是规定。 触发词：写文档、写方案、写计划、写 PRD、写汇报、项目总结、写指南、帮我写、文档、方案设计。 即使用户没有明确说"写"，只要意图是"产出一份结构化的文档/报告/材料"，都应触发此技能。 本 skill 只负责"写"，不负责"调研"（调研由 deep-research 承担）和"调度"（流程由 task-start 承担）。
深度调研技能：对任意命题进行系统性调研并输出专业研究报告。 覆盖技术选型、行业分析、学术研究、竞品分析、概念探索等所有调研场景。 核心方法论：快速扫描→假设驱动研究、内外数据结合（先摸清内部现状再对标外部水位）、 反面证据强制搜索、数据来源三级分类、结论置信度分级、多层次报告输出。 采用 Orchestrator-Subagent 架构（Lead+Sub-agent 并行深挖、压缩回传、Scaling Rules 预算控制）， 对齐 Anthropic 官方 Research 工程实践。 包含信息交叉验证、专业图表生成（Diagram Bridge 统一图表体系）、 数据来源分级标注、分析框架自动选择、报告组件驱动（不预设模板，按内容形态调用组件）、质量自检（6 步工作流）。 触发词：调研、研究、分析报告、对比分析、行业报告、技术选型、竞品分析、 市场调研、深度研究、出一份报告、帮我调研一下、了解一下xxx、 评估、诊断、健康度、差距分析。 即使用户没有明确说"调研"，只要意图是"系统性地了解某个命题并形成结论"，都应触发此技能。
MD 文件浏览器预览：GitHub 风格渲染 + 左侧自动目录。 在完成方案设计（specs）或开发计划（plans）的 MD 文件后触发。 询问用户是否要在浏览器中打开预览，确认后执行。 触发词：方案写完、计划写完、review MD、预览文档。 工作流位置：task-start 方案产出后 / 任意 MD 文档完成后
专业图表生成技能：根据需求自动选择合适的图表类型，生成符合设计规范的 PNG 图表。 覆盖 29 种图表：结构图（流程图、泳道图、时序图、架构图、状态图、ER图、类图、思维导图、甘特图、Kanban、Git Graph 等） 和统计图（柱状图、折线图、饼图、雷达图、热力图、散点图、桑基图、漏斗图、瀑布图、矩形树图、柱线混合图等）。 统一工具：HTML/SVG + 内联 JS 布局计算。ER/类图使用 ELKjs 布局引擎。 所有图表遵循统一的设计规范（配色/字体/组件/间距），风格现代简洁。 支持三种输出：PNG（默认）、HTML（富文档嵌入）、DSL（Mermaid 文本，嵌入 MD 文档）。 触发词：画图、画一个、生成图表、流程图、架构图、时序图、柱状图、对比图、关系图。 即使用户没有说"画图"，只要需求中涉及可视化展示（流程、架构、数据对比、关系），都应触发此技能。 被 deep-research 等其他技能调用时，同样遵循本规范生成图表。
项目知识库引擎：持续维护 docs/ 目录作为活的知识库。 灵感来源：Karpathy LLM Wiki — LLM 不只是写文档，而是持续维护知识库。 五个核心操作：Ingest（摄入新信息）、Query（检索知识）、Lint（健康检查）、Index（索引维护）、Synthesize（聚合全局视图）。 触发词：文档检查、清理文档、文档索引、docs 整理、知识库、文档过期了吗、架构文档、用户手册。 触发场景：task-manager 标 done 时自动触发 Ingest、定期 Lint 健检、用户查询项目历史、 task-finish 提醒后触发 Synthesize 更新 architecture/ 或 user-guide/。 即使用户没有说"文档管理"，只要涉及 docs/ 目录的整理/检查/更新，都应触发此技能。
提交前质量门禁：CR 自检（快速/深度）。在 commit 之前触发。 只负责代码质量自检，不负责复盘——复盘在需求标 done 时由 task-manager 触发。 触发词：提交代码、自检、准备提交。 工作流位置：task-start → task-execute → task-finish（自检）→ task-manager（需求关闭时复盘）