性能分析Skill：先测量再优化，用百分位数找到真正的性能瓶颈
- 一句话定位：这是一个把「先测量、后优化」写进规则里的性能分析技能，帮你从「凭直觉改代码」转向「按数据定位瓶颈」。
- 核心方法论：它固化了六步流程——测量、识别、假设、修复、验证、记录，并给出 CPU、内存、I/O 三条剖析路径和瓶颈决策表。
- 强制规范：延迟必须看 p95、p99，不能只看平均值；必须在类似生产的环境中剖析；改动前要留基线，改动后要复测验证。
- 开箱即用的输出格式：每次分析都会产出结构化的「性能发现」，包含严重度、类别、位置、基线值、目标值和优化建议，方便直接贴进工单或复盘文档。
- 适用范围：接口变慢排查、内存与 GC 压力诊断、容量规划与压测设计、CI 性能预算与优化效果验证。
该技能叫什么？如何下载安装 AI 技能提升开发效率？
技能中文名：性能分析Skill 技能英文名：performance-analysis 技能ID：11704
它要解决的问题很具体：团队里最常见的一种浪费，是在没有任何测量的前提下，凭「我感觉这里是瓶颈」去改代码。改完之后，性能没有变好、甚至更差，却因为缺少基线数据而无法证明。性能分析Skill 把性能工程的方法论变成 AI 可以稳定执行的作业规范——它要求在任何操作之前先读项目的 CLAUDE.md（架构、约定、优先级）和根目录下的 CONSTITUTION.md（如果存在，约束所有工作），再基于现有性能基线与监控去分析，而不是从零臆测。
关于「一键安装」提升开发效率的思路，可以按下面三步理解（具体命令与入口以官方说明为准）：
第一步：确认安装前提。
需要你已经在使用支持 AI 技能的客户端或平台；项目侧建议准备好 CLAUDE.md，如有 CONSTITUTION.md 也一并保留；同时尽量提供现有的性能基线与监控数据。这些正是技能在执行前会主动读取的上下文，准备得越充分，第一次分析就越贴近真实情况。
第二步：通过技能入口添加。
在平台的技能库/技能市场中搜索中文名「性能分析」或英文名 performance-analysis，也可以用技能ID 11704 定位条目，然后执行安装或添加操作。安装完成后，技能会被注册到可调用的技能列表中，在对话里提及「性能分析」「性能剖析」「容量规划」等关键词即可触发。具体的安装命令、目录结构、账户权限要求以官方说明为准。
第三步：验证是否生效。 安装后可以做一次快速验证：向 AI 提一个诊断类问题，例如「我们某个接口 p99 从 200ms 涨到 1.2s，帮我看看该怎么排查」。如果技能生效，它的回答应该先要求你建立或提供基线指标，并明确区分应用层、系统层、基础设施层的剖析层次，而不是直接给出一串「试试加缓存」的建议。另一种验证方式是让它输出一份「性能发现」结构，如果能按严重度、类别、位置、基线、目标、建议这几个字段完整给出，说明技能已正常工作。
该技能的主要功能和特点
- 强制「先测量」的黄金规则：技能内置六步流程（测量、识别、假设、修复、验证、记录），并明确列出反模式——无测量优化、用平均值当延迟指标、只在开发环境剖析、忽略尾部延迟、为假设的规模过度工程化、缓存无失效策略。
- 瓶颈决策表：把「症状 → 瓶颈类型 → 调查方法」做成从上到下首次匹配即胜出的判定表。例如「高 CPU、低 I/O 等待」判定为 CPU 限制，「低 CPU、高 I/O 等待」判定为 I/O 限制，「低 CPU、高等待时间」判定为锁争用，「大量小型数据库查询」判定为 N+1 查询。
- 分层剖析框架：把剖析拆成应用层（请求/响应计时、函数剖析、内存分配跟踪）、系统层（每进程 CPU、内存使用模式、I/O 等待、网络延迟）、基础设施层（数据库查询性能、缓存命中率、外部服务延迟、资源饱和），避免只盯一个层次。
- 三类剖析模式的具体指引：CPU 剖析区分采样剖析器、仪器剖析器与火焰图，并强调自身时间、总时间、调用次数；内存剖析覆盖堆快照、分配跟踪、GC 分析，关注堆大小趋势、对象保留、分配速率、GC 暂停时间；I/O 剖析关注延迟百分位、吞吐量与队列深度。
- 可复用的诊断方法论：内置 USE 方法（利用率、饱和、错误）与 RED 方法（速率、错误、持续时间），让「怎么问对问题」变成标准动作。
- 阿姆达尔定律做优先级排序：技能会明确计算「优化哪一段收益最大」，例如 90% 时间在函数 A、10% 在函数 B，优化 A 一半带来 45% 总提升，优化 B 一半只有 5%。
- 容量规划与压测方法论：提供基线建立、斜坡测试、压力测试、浸泡测试四类负载测试方法，以及「所需容量 =（当前负载 × 增长因子）+ 安全边际」的估算公式。
- 结构化输出：所有结论落地为「性能发现」条目，便于跨角色沟通和归档。
和普通工具相比，它强在「纪律」而不是「功能」：一般工具只给你火焰图或监控曲线，它约束你不能在没有基线的情况下动手，并把结论整理成可追踪的结构。
如何使用该技能？
步骤 1：准备上下文并说明目标。 把项目结构、技术栈、现有监控情况交代清楚。示例输入：
「我们这个订单查询接口上线后 p99 从 180ms 涨到 1.1s，日均请求 80 万。现有 Prometheus 监控有 CPU、内存和 QPS 指标，数据库是 PostgreSQL。帮我建立排查计划。」
步骤 2：让技能先建立基线。 它会要求你补齐基线指标，而不是立刻给方案。你需要提供的典型项包括：p50/p95/p99 延迟、吞吐量、错误率、CPU 与内存水位、GC 频率与暂停时间、数据库慢查询数量。基准值缺失时，技能会先帮你设计「怎么量」。
步骤 3：按瓶颈决策表定位类别。 根据症状走判定表，输出瓶颈类型。技能通常会用 USE 方法检查资源层（利用率/饱和/错误），用 RED 方法检查服务层（速率/错误/持续时间），交叉验证后确定主因。
步骤 4：形成假设并按阿姆达尔定律排序。 此阶段技能会明确区分「最大贡献者」和「看起来最可疑但影响很小」的部分，并提示你优先处理占比最高的路径，而不是先做最容易改的那处。
步骤 5：实施针对性优化。 技能内置三类优化模式：快速获胜（启用缓存、补索引、Gzip/Brotli 压缩、连接池、批量操作）、算法改进（降低复杂度、延迟评估、记忆化、分页）、架构变更（水平扩展、异步处理、读副本、缓存层、CDN）。它会结合你的瓶颈类型推荐对应层级的手段，避免一上来就架构改造。
步骤 6：复测验证并对比前后数据。 优化后必须再次测量，与原基线逐项对比。若改善不明显，回到步骤 3。
步骤 7：记录并沉淀为容量规划输入。 把每次发现记录下来，作为后续增长规划与性能预算的依据。
输出说明：技能产出的每条「性能发现」都包含以下字段：
| 字段 | 含义 |
|---|---|
| id | 发现编号，例如 C1、H2 |
| title | 简短标题 |
| severity | 严重、高、中、低 |
| category | cpu、内存、io、网络、查询、算法、容量 |
| location | 文件与行号、端点或具体查询 |
| finding | 测量结果与发现描述 |
| baseline | 当前指标值 |
| target | 修复后的预期指标值 |
| recommendation | 具体优化方法与实施路径 |
示例输出片段：
id: C1
title: 订单列表接口 N+1 查询导致延迟升高
severity: 高
category: 查询
location: /api/orders 列表接口，OrderService 循环调用 getItems()
finding: 单次请求触发 1 + N 次查询，N 平均为 42，数据库等待占请求耗时 78%
baseline: p99 = 1.1s，数据库平均查询次数/请求 = 43
target: p99 < 250ms，查询次数/请求 ≤ 3
recommendation: 改为批量预加载（JOIN 或 IN 批量查询），并按决策表复测对比
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 性能分析Skill（performance-analysis） | 融入开发对话的性能方法论专家 | 测量流程约束、瓶颈决策表、分层剖析指引、容量规划、结构化发现输出 | 低，安装到支持 AI 技能的客户端即可用；无需接入生产探针 | 排查思路梳理、压测方案设计、优化前后验证、性能预算制定 | 优势在于方法论完整、有纪律约束、零侵入；不足是不直接采集数据，实际指标仍需来自你的监控与剖析器 |
| 商业 APM 平台（如 Datadog、New Relic 一类） | 全栈可观测性平台 | 分布式追踪、指标聚合、告警、仪表盘、日志关联 | 中高，需要接入 SDK 或 Agent，按量或订阅计费（以官方定价为准） | 线上长期监控、跨服务链路追踪、告警值班 | 优势是数据完整、可视化强；不足是成本较高、需要改造接入，方法论层面仍需人判断 |
| 语言级剖析器与火焰图工具（如 py-spy、pprof、async-profiler 配合火焰图） | 单进程深度剖析 | 采样/仪器剖析、调用栈可视化、内存分配跟踪 | 中，需要按语言选型并理解火焰图读法 | 定位热点函数、算法级优化、CPU 与内存深挖 | 优势是精度高、开销可控；不足是只覆盖单进程，缺少跨层关联与系统化流程 |
| 数据库慢查询日志与执行计划分析 | 数据库自带诊断 | 慢 SQL 捕获、执行计划、索引建议 | 低到中，需要开启日志并具备数据库权限 | 查询类瓶颈定位、索引优化 | 优势是直接命中查询问题；不足是只覆盖数据库层，无法解释应用层与锁竞争问题 |
从对比可以看出，这几类方案是互补关系：APM 平台解决「有没有数据」，语言剖析器解决「热点在哪」，数据库工具解决「SQL 是否有问题」，而性能分析Skill 解决的是「拿到数据之后按什么顺序判断、怎么避免误判、怎么验证改动确实有效」。
该技能的典型应用场景与实际体验情况
场景一：线上接口突然变慢的后端工程师。 痛点是监控显示 CPU 正常、错误率正常，只有 p99 恶化，团队开始互相猜测是网络还是数据库。使用方式是把症状描述与现有指标一起交给技能，它会引导先用瓶颈决策表判断：低 CPU、高等待时间意味着锁争用或连接池耗尽，而不是算法问题。实际体验上，上手几乎零成本，最大的价值是把「讨论会」压缩成「按表判断」；注意事项是要如实提供指标，如果你只给「感觉慢」，技能会先退回第一步要求补基线。
场景二：内存持续增长、GC 压力变大的服务负责人。 痛点是重启能缓解但找不到根因。技能会指向堆快照、分配跟踪、GC 分析三件套，并要求关注堆大小随时间变化、对象保留、分配速率和 GC 暂停时间，同时提醒你在类似生产的环境中剖析。实际体验上，它给出的是一条可执行的取证清单，而不是笼统的「查查内存泄漏」；注意事项是开发环境的内存表现往往与生产差异很大，结论必须回到生产或压测环境验证。
场景三：为大促做容量规划的技术负责人。 痛点是不确定现有配置能扛多少流量，扩容扩多少也没底。技能会给出基线建立、斜坡测试、压力测试、浸泡测试的组合方案，并按「（当前负载 × 增长因子）+ 安全边际」估算所需容量，比如当前 1000 请求/秒、年增长 50%、安全边际 30%，第一年需求约为 1950 请求/秒。实际体验上，这套结构让容量评审有据可依；注意事项是增长因子与安全边际必须来自真实业务判断，不能套用模板数字。
场景四：把性能预算写进 CI 的团队。 技能的最佳实践部分明确建议在 CI 中设置并强制执行性能预算、持续监控而非只在事故期间监控。使用方式是在每次显著改动后让技能输出「性能发现」清单，前后比对基线值。实际体验上，它更像一份团队规范说明书，能显著减少「优化完没人验证」的情况；注意事项是预算阈值需要结合业务 SLA 自行设定。
该技能能为用户带来的价值
把优化从经验驱动变成证据驱动。 最直接的收益是减少无效改动。技能强制「改动前记录基线、改动后再次测量」，让每一次优化都有可对比的数字，避免出现「改了三天，p99 没变，但代码复杂度上去了」的典型浪费。
用阿姆达尔定律减少无效工作。 大量性能优化失败的原因是没有先确认最大贡献者。技能要求先看占比最高的路径，同样投入一小时，优先优化的收益可能是次要路径的数倍。
用百分位数取代平均值，减少线上误差。 技能明确禁止把平均值当延迟指标，并强调不能忽略 p99、p999。对于有长尾请求的业务，这一条规则往往直接改变团队对「系统是否健康」的判断标准。
降低性能工程的门槛。 USE 方法、RED 方法、瓶颈决策表、三类剖析模式、四类压测方法，这些原本分散在性能工程书籍和经验分享里的知识，被组织成一套随时可调用的作业流程。新人不用先读完一本厚书，也能按步骤完成一次规范的排查。
长期价值在于沉淀标准。 结构化的「性能发现」条目可以跨项目复用、可以进复盘文档、可以作为容量规划的历史输入，团队的性能知识因此从「某个人脑子里」变成「组织可检索的资产」。
常见问题 FAQ
Q1：这个技能怎么安装？需要付费吗？
在支持 AI 技能的客户端或平台的技能库中搜索「性能分析」或 performance-analysis，也可以用技能ID 11704 定位后安装，具体入口与命令以官方说明为准。是否收费取决于你使用的平台政策，本技能详情中未涉及定价信息，请以官方说明为准。
Q2：它会不会直接操作我的代码或生产环境？ 不会。从技能详情看，它的角色是性能分析专家，负责诊断、建立基线、给出建议并验证思路，不包含自动改代码或自动执行生产变更的能力；实际动手仍由你或你的团队完成。
Q3：为什么它一直强调 p95、p99，平均值真的不能用吗？ 平均值会掩盖长尾。少量极慢请求在平均值里几乎看不出来，但它们往往正是用户体验最差的部分。技能把百分位数作为延迟指标的标准，并要求不能忽略 p99、p999，这是为了让你优化的是用户真实感受到的那部分延迟。
Q4：我已经有 APM 平台了，还需要这个技能吗？ 需要，但用途不同。APM 提供数据，这个技能提供判断顺序与验证纪律。数据齐全却没有分析框架时，团队常在多个可疑点之间反复试错；把 APM 指标交给技能，更容易得出「先改哪个、改完看什么指标」的结论。
Q5：适合谁用？小白能用吗？ 适合后端工程师、SRE、架构师、技术负责人，以及需要做容量规划与性能预算的团队。对新手友好之处在于它给了明确的步骤和判定表，照着走就能完成一次规范排查；但前提是你愿意去采集真实指标——如果既没有监控也不打算测，任何性能工具都帮不上忙。