AI 编程工具已经能帮我们改很多代码，但性能优化这类任务，不能只丢一句“帮我把项目变快”。如果没有指标、日志和对比基线，Cursor、Claude Code、Codex 很容易把问题改成另一种问题：页面看似快了，接口却多查了几次数据库；代码看似简洁了，缓存却让数据延迟更新。
更稳的做法，是先把“慢”量化，再让 AI 在明确边界内小步优化。本文放在 AI编程工具专题 和 老达AI实践专题 里，适合个人开发者、小团队和站长维护项目时对照使用。
先判断：你要优化的是哪一种慢
性能优化最怕一上来就改代码。你需要先把慢分成几类：
- 接口慢：某个 API 的 p95、p99 延迟高，用户提交后等待明显。
- 数据库慢：慢查询、N+1 查询、缺索引、一次拉取太多字段。
- 前端慢：首屏加载、图片体积、JS 包过大、交互响应迟钝。
- 任务慢：批处理、爬取、导入导出、AI 调用队列耗时过长。
- 体感慢：实际耗时不夸张，但缺少 loading、进度提示或状态反馈。
这一步最好不要让 AI 直接猜。你可以先整理访问日志、数据库慢查询、浏览器 Performance 面板截图、接口监控或简单计时结果，再让工具判断优先级。之前写过 AI编程报错日志怎么整理，性能问题也一样：先给证据，AI 才能少走弯路。
给 AI 的第一条指令：只做性能画像，不改代码
我建议第一轮先让 Cursor、Claude Code 或 Codex 做只读分析。提示词可以这样写：
请先不要修改代码。
阅读当前性能问题相关文件，帮我输出一份性能画像：
1. 哪些接口、组件、查询或任务可能导致慢；
2. 每个问题需要什么证据验证；
3. 优先级排序；
4. 哪些改动风险较高，暂时不要碰。
输出后等待我确认。这个步骤的价值，是把 AI 从“马上动手改”拉回“先定位”。如果你正在处理前端页面，也可以结合 AI编程前端页面验收 的方法，把布局、交互和控制台错误一起看，避免只盯一个指标。
接口耗时：先找最慢路径，不要全站乱改
接口性能优化要从真实请求路径开始。比如订单列表慢，不要让 AI 先重构整个服务层，而是让它回答：
- 这个接口调用了哪些服务、查询和外部 API？
- 有没有循环里查数据库、重复请求或无用字段？
- 有没有分页、筛选、排序边界？
- 有没有缓存可以用，缓存失效条件是否清楚？
- 改动后怎么证明 p95 或平均耗时下降？
如果没有监控系统，也可以先加临时计时日志，但要约束 AI：日志字段要清楚，不能打印密钥、手机号、订单号等敏感信息；验证完要移除临时噪声，或改成正式可控的 debug 日志。
数据库慢查询：让 AI 先解释执行计划
数据库优化不是简单加索引。加错索引会拖慢写入，改错查询会影响结果。比较稳的流程是：
- 先贴出慢查询 SQL、耗时、返回行数和表结构。
- 让 AI 判断是否存在全表扫描、N+1 查询、无效排序或字段过多。
- 让 AI 给出最小改动方案，不直接改业务逻辑。
- 在测试库跑对比，记录改动前后的耗时和结果数量。
- 确认回滚方式，再合并到主分支。
如果项目已经有迁移脚本，索引变更也要走脚本，不要让 AI 临时在数据库里手动改。可以参考 AI编程数据库迁移 的思路，把性能优化也纳入版本管理和回滚记录。
前端加载：图片、包体积和交互响应分开看
前端性能问题常常被一句“页面慢”混在一起。让 AI 优化前，最好先拆成三个问题：
- 首屏资源：图片是否过大，是否缺少压缩、懒加载和合理尺寸。
- 脚本体积：是否一次加载太多依赖，是否有可延迟的模块。
- 交互响应：点击、输入、筛选、滚动时是否触发了重复计算或重复请求。
给 AI 的要求也要具体：只优化一个页面或一个组件；保留视觉效果；不要顺手重做设计；改完必须给出截图或性能指标对比。尤其是 WordPress、后台工具、落地页这类项目，视觉和稳定性同样重要，不能为了分数牺牲可读性。
让 AI 小步优化：一次只改一个性能假设
性能优化最好按“假设、改动、验证、记录”推进。比如：
- 假设：订单接口慢是因为 N+1 查询。
- 改动：把循环查询改成批量查询。
- 验证：同一组测试数据下，请求次数减少，返回结果一致。
- 记录：写明改了哪里、为什么、怎么回滚。
不要同时让 AI 改查询、缓存、组件渲染和图片策略。一次改太多，指标变好也不知道是哪一步有效，指标变差更难回退。这里可以复用 AI编程上线检查 里的发布前清单，把性能改动当成一次小版本上线处理。
回归检查：快了不等于对了
性能优化后的验收至少包含四类结果：
- 功能结果：页面、接口、任务输出和原来一致。
- 性能结果：关键指标有明确下降或稳定改善。
- 异常结果：空数据、超大数据、失败请求仍然可控。
- 运维结果：日志、缓存、索引和配置不会给后续维护埋坑。
如果是 AI 编程工具生成的改动，还要让它解释 diff。重点看有没有删掉必要校验、扩大权限、绕过错误处理、引入全局状态。性能优化不应该用“少做检查”来换速度。
一份可直接复用的性能优化提示词
你是一个谨慎的性能优化助手。
目标：优化 [具体页面/接口/任务] 的性能。
已知证据：[贴日志、耗时、截图或慢查询]。
约束：
- 先分析，不要直接改代码；
- 一次只提出 1-3 个最小改动；
- 不改变业务结果和权限逻辑；
- 改动后必须说明验证命令、对比指标和回滚方式；
- 不打印敏感数据。
请先输出性能画像和推荐优先级。这段提示词适合放进 Cursor、Claude Code、Codex 的任务说明里。更完整的任务边界写法，可以对照 AI编程需求文档怎么写，把性能目标、验证指标和禁止改动范围提前写清楚。
老达点评：性能优化不是炫技，是减少不确定性
AI 编程让性能优化门槛降低了，但真正稳定的流程仍然很朴素：先量化，后定位；先小改，后验证；先证明有效，再合并发布。Cursor、Claude Code、Codex 都可以成为很好的性能排查助手，但前提是你别让它们在没有证据的情况下大范围重构。
对普通项目来说，先把最慢的 20% 路径优化掉，往往比重写架构更有价值。把指标、日志、diff 和回归结果留下来，下一次再遇到慢接口、慢页面、慢任务时，你就不是从零开始，而是在一个越来越清晰的 AI 编程工作流里继续迭代。
