让 Claude Code 做性能优化

Claude Code 性能优化教程：教你如何让 CC 先定位瓶颈、建立基线、提出小步优化方案，再通过指标和体验验证优化是否真的有效。

性能优化最怕一句话：

帮我优化一下性能。

这句话太宽，Claude Code 很容易开始猜：改缓存、改循环、改渲染、改请求、改构建配置，最后改了一堆，却不知道到底有没有变快。

正确做法是：先建立问题、指标和范围。

先判断是哪类性能问题

性能问题大致分几类：

不要把所有性能问题混在一起优化。

第一步：让 CC 先只读定位

提示词：

请先只读分析当前项目可能的性能问题，不要修改文件。

现象：
【描述慢在哪里，比如页面首次加载慢、列表滚动卡、接口响应慢】

请输出：
1. 可能相关的文件和模块。
2. 当前最可能的瓶颈。
3. 需要哪些数据才能确认。
4. 不建议先动哪些地方。
5. 建议的最小排查顺序。

要求：
- 不要直接优化。
- 不要做大范围重构。
- 不要凭感觉改缓存或改架构。

这一步是为了阻止 CC 直接进入“想当然优化”。

第二步：建立基线

性能优化必须有对比。

前端可以记录：

• 首屏时间。
• 资源体积。
• 接口耗时。
• 页面交互是否卡顿。
• Lighthouse 或浏览器 Performance 数据。

后端可以记录：

• 接口平均耗时。
• 慢 SQL。
• 请求量。
• 错误率。
• CPU / 内存。

可以让 CC 帮你设计基线：

请根据这个性能问题，设计一份优化前基线记录。

要求：
1. 指标尽量具体。
2. 不要求复杂监控，优先使用当前项目已有手段。
3. 区分必须记录和可选记录。
4. 说明每个指标如何帮助判断优化是否有效。

没有基线，就不要急着改。

第三步：让 CC 给优化计划

性能优化计划要按收益和风险排序。

提示词：

/plan

请根据当前性能问题和基线，给出小步优化计划。

要求：
1. 每一步只解决一个明确瓶颈。
2. 按低风险、高收益优先排序。
3. 每一步说明要改哪些文件。
4. 每一步说明如何验证是否有效。
5. 不要做无法验证的大重构。
6. 如果需要取舍，请先说明利弊。

好计划应该像这样：

第一步：减少列表重复计算。
影响文件：xxx。
风险：低。
验证：输入搜索和分页时观察渲染次数或交互卡顿。

第二步：延迟加载非首屏资源。
影响文件：xxx。
风险：中。
验证：对比首屏资源体积和页面加载表现。

第四步：小步执行

执行时要求 CC 不要顺手改太多：

按计划只执行第一步优化。

要求：
1. 只修改第一步涉及的文件。
2. 不要顺手重构其他代码。
3. 保持功能行为不变。
4. 修改后解释每个改动为什么能改善性能。
5. 给出验证方式。

性能优化比新增功能更需要克制。因为“看起来更优雅”的代码，不一定真的更快。

第五步：验证是否真的有效

让 CC 做优化后复核：

请对这次性能优化做验收。

要求：
1. 对比优化前基线。
2. 说明哪些指标变好了，哪些没有变化。
3. 确认功能行为是否保持一致。
4. 如果没有明显改善，请建议回滚还是继续排查。
5. 不要只说“理论上会更快”。

如果没有指标改善，就不要把它当成成功优化。

常见错误

不要这样做：

• 没有复现就优化。
• 没有基线就优化。
• 一次改多个瓶颈。
• 优化同时重构代码风格。
• 把“减少代码行数”当成性能提升。
• 只听 CC 总结，不看实际结果。

性能优化的核心是证据，不是感觉。

前端性能提示词

请帮我分析这个页面的前端性能问题。

现象：
【页面路径 + 具体慢在哪里】

要求：
1. 先找可能的性能瓶颈，不要修改。
2. 重点检查组件重复渲染、列表渲染、图片资源、接口请求和首屏资源。
3. 给出低风险优化计划。
4. 每个优化点必须有验证方式。

后端性能提示词

请帮我分析这个接口的性能问题。

接口：
【接口路径或方法名】

现象：
【响应慢 / 数据量大 / 某些条件慢】

要求：
1. 先梳理调用链。
2. 重点检查数据库查询、循环处理、外部请求、缓存和错误重试。
3. 不要直接改数据库结构。
4. 先给出排查计划和风险点。

验收结果

学完后，应该能做到：

• 不再用一句“优化性能”开始任务。
• 能让 CC 先定位瓶颈和建立基线。
• 能把优化拆成小步。
• 能用指标判断优化是否有效。
• 能在无效优化时及时回滚或重新定位。