让 CC 做性能优化前评估
进阶实战教程：让 Claude Code 在真正优化前先判断是否值得优化、瓶颈在哪里、基线怎么建立、风险和收益如何取舍。
这里不教 CC 怎么优化性能。
那是 让 Claude Code 做性能优化 的内容。
重点只做一件事：优化前评估。
因为很多性能优化不值得马上做。没有瓶颈、没有基线、没有复现、没有验收方式的优化，很容易变成“代码改了很多，但不知道有没有变快”。
性能优化前评估要回答什么
让 CC 先回答：
- 真的有性能问题吗？
- 问题发生在哪个场景？
- 影响多少用户或路径？
- 当前有没有可量化指标？
- 最可能瓶颈在哪里？
- 优化收益是否值得改动风险？
- 哪些优化不该现在做？
评估提示词
请先做性能优化前评估，不要修改文件。 现象： 【页面慢 / 接口慢 / 构建慢 / 交互卡顿】 已知信息： 【设备、浏览器、接口耗时、页面路径、日志、截图等】 请输出： 1. 是否能确认这是性能问题。 2. 还缺哪些证据。 3. 最可能瓶颈排序。 4. 建议记录哪些基线指标。 5. 哪些优化低风险高收益。 6. 哪些优化风险高，不建议现在做。 7. 是否值得进入实际优化阶段。
建立基线清单
让 CC 设计基线：
请为这个性能问题设计优化前基线。 要求： 1. 指标要能重复测量。 2. 区分前端、后端、网络、构建。 3. 每个指标说明如何获取。 4. 给出最低可接受记录方式。 5. 不依赖复杂监控也能执行。
没有基线就先不要动代码。
常见性能问题怎么分类
不要把所有“慢”都当成同一种问题。先让 CC 分类：
| 类型 | 典型表现 | 优先看什么 |
|---|---|---|
| 页面首屏慢 | 打开页面很久才看到内容 | 包体积、接口耗时、首屏资源 |
| 交互卡顿 | 点击、输入、滚动不跟手 | 渲染次数、列表数量、同步计算 |
| 接口慢 | 页面一直 loading | 后端查询、外部服务、网络耗时 |
| 构建慢 | 本地或 CI 打包耗时很长 | 构建配置、依赖、缓存 |
| 偶发慢 | 有时快，有时慢 | 数据量、网络波动、并发、缓存 |
可以这样问：
请先判断这个性能问题属于哪一类。 要求： 1. 不要直接给优化方案。 2. 每个分类都要说明证据。 3. 如果证据不足，请列出最少需要补充哪些信息。 4. 只给最可能的前三类。
分类不清楚时，优化很容易跑偏。
优化前不要让 CC 猜数据
性能问题最怕“感觉慢”。如果没有数据，至少补一个最低版本的记录：
- 页面路径。
- 复现设备和浏览器。
- 第几次访问。
- 操作步骤。
- 大概耗时。
- 控制台错误。
- 接口耗时。
- 构建或测试耗时。
记录不用一开始就很专业，但必须能复现。比如：
页面：订单列表 设备：Windows Chrome 操作：进入页面后切换状态筛选 现象：点击后约 3 秒才刷新列表 接口：/api/orders 大约 2.7 秒 控制台：无明显错误
有了这类信息，CC 才能判断是前端渲染慢，还是接口本身慢。
评估收益和风险
请按收益和风险评估可能的优化方向。 输出表格： 优化方向 预期收益 改动范围 风险等级 验证方式 是否建议现在做
这个表能阻止 CC 一上来做大重构。
输出一份优化前决策
评估结束后，不要只得到一堆分析。让 CC 给一个明确决策：
请根据以上评估，给出优化前决策。 输出： 1. 是否建议现在进入优化。 2. 如果建议，先做哪一个最小优化。 3. 如果不建议，应该先补哪些证据。 4. 当前最不建议做的优化是什么。 5. 优化后用什么指标判断是否成功。
这一步能把“分析”变成“可执行下一步”。
哪些结论应该停止优化
如果评估结果是：
- 没有稳定复现。
- 没有可测指标。
- 问题来自网络或第三方服务。
- 当前瓶颈不在代码。
- 优化成本明显高于收益。
- 业务优先级不支持。
那就应该先停止，不要为了优化而优化。
进入优化阶段的标准
只有满足这些条件，才进入实际优化：
- 问题能复现。
- 有基线指标。
- 瓶颈大致明确。
- 改动范围可控。
- 验证方式明确。
- 有回滚方案。