Appearance
Performance Optimization 解决的是 AI 凭经验乱优化的问题。真正的性能优化要先测量，建立基线，找出瓶颈，再修具体问题，修完后重新测量确认变化。
AI 优化性能前为什么要先测量：Performance Optimization 怎么用
下载 performance-optimization 中文版 Skill ZIP
页面慢了，AI 可能建议加缓存。
列表卡了，AI 可能建议加 memo。
接口慢了，AI 可能建议改成并发请求。
这些建议有时对，有时只是听起来专业。
performance-optimization 这个技能的核心只有一句话：先测量，再优化。
没有基线，就没有优化
性能问题不能靠感觉修。
你觉得页面慢，可能是首屏图片太大，也可能是接口慢，也可能是 JavaScript 阻塞主线程。你觉得接口慢，可能是数据库缺索引，也可能是外部 API 慢，也可能是日志写入卡住。
如果不测量，AI 只能根据常见经验猜。
给 AI 的第一步应该是：
md
先建立性能基线。
说明当前慢在哪里：首屏、交互、接口、数据库查询，还是构建产物。
不要在没有测量证据前改代码。这能拦住很多过早优化。
前端该测什么
前端性能常见指标包括：
- LCP：最大内容什么时候显示出来。
- INP：用户点击、输入后页面多久响应。
- CLS：页面有没有突然跳动。
- bundle size：首屏要下载多少 JS。
- network waterfall：请求是不是串行等待。
- main thread：主线程是否被长任务占住。
你不用每次都测全套。
如果用户抱怨“打开很慢”，先看首屏和网络瀑布。如果用户说“点按钮卡”，先看交互和主线程。如果页面布局跳动，重点看图片尺寸、字体和异步内容。
后端该测什么
后端性能也要先定位。
常见方向：
- 单个接口响应时间。
- 数据库查询耗时。
- 是否有 N+1 查询。
- 是否一次查了过多数据。
- 外部服务调用耗时。
- CPU、内存、连接池是否到瓶颈。
不要一上来就加 Redis。
如果慢在数据库缺索引，加缓存可能只是把问题藏起来。如果慢在外部 API，没有超时和重试策略，缓存也救不了所有场景。
AI 常见的假优化
AI 很喜欢写这些：
- 到处加
useMemo。 - 到处加缓存。
- 把同步逻辑改成并发。
- 把代码拆成更多文件。
- 改 import 写法，说可以 tree-shaking。
它们不一定错，但必须有证据。
比如 useMemo 本身也有成本。一个很便宜的计算加 memo，可能没有收益，还让代码更难读。
缓存也不是免费午餐。缓存会带来过期、失效、数据不一致、清理策略。没有命中率和瓶颈证据，就不要随便加。
正确的优化节奏
一个稳的性能优化流程是：
- 测量当前表现，记录基线。
- 定位真正瓶颈。
- 只改这个瓶颈相关代码。
- 重新测量，确认确实变好。
- 如果这类问题容易复发，加监控或测试。
这和 AI 编程的小步推进是一致的。
性能优化最怕一口气改很多。改完以后就算变快，你也不知道是哪一处起作用；如果变慢，更不知道怎么回退。
给 AI 的性能优化 Prompt
md
我们按测量优先的方式优化性能。
现象：
[描述用户感受到的慢]
要求：
1. 先判断应该测前端、后端、数据库还是构建产物。
2. 建立当前基线，说明用什么指标。
3. 根据数据定位一个最可能瓶颈。
4. 只针对这个瓶颈做最小改动。
5. 改完后重新测量，说明是否真的改善。
没有测量证据前，不要直接加缓存、memo 或重构。这段 prompt 的价值在于，让 AI 从“优化建议机器”变成“性能排查助手”。
古法编程怎么看性能优化
古法编程不反对优化，反对玄学优化。
能解释为什么慢，能证明哪里变快，能控制复杂度，才算真正优化。
AI 可以帮你读 trace、找查询、改代码。可性能决策要基于数据，不基于语气自信。
你可能还需要
同类技能：
如果你想让 AI 优化性能，先让它拿到基线。没有数据，就先不要改。