AI 性能建议评估：能优化，不代表值得改
一、性能建议不能只看“有提升”
AI 可以根据 Lighthouse、Performance Trace 和代码片段生成性能建议。它会告诉你图片懒加载、拆包、memo、缓存、预加载。问题是，建议多不代表价值高。前端性能优化最怕为了 5ms 改出一堆复杂度。
性能建议评估要看收益、成本和风险。能优化，不代表值得改。一个改动如果收益很小，却引入复杂缓存或状态分叉，就不该排在前面。
二、把建议放进收益矩阵
每条建议至少评估影响指标、预计收益、实现成本、回归风险和验证方式。
flowchart TD A[AI 性能建议] --> B[指标影响] A --> C[实现成本] A --> D[回归风险] B --> E[优先级评分] C --> E D --> E E --> F[进入优化队列]AI 负责提出候选，人负责决定优先级。别让模型替项目排期。
三、建议必须绑定验证指标
下面示例是建议结构。没有指标的建议，先别进优化队列。
type PerfSuggestion = { title: string; metric: "LCP" | "INP" | "CLS" | "TTFB"; expectedGainMs?: number; risk: "low" | "medium" | "high"; verifyCommand: string; }; function canSchedule(item: PerfSuggestion) { return Boolean(item.expectedGainMs) && item.risk !== "high" && item.verifyCommand.length > 0; }“可能提升体验”这种话没法执行。指标、命令、阈值都要写清楚。
四、性能优化要避免局部胜利
拆包能降低首屏 JS，但可能增加后续交互等待；图片压缩能改善 LCP，但可能损害视觉质量；memo 能减少重渲染，但可能增加代码复杂度。每条建议都要看整体链路。
还要防止 AI 套模板。不是所有页面都需要预加载，不是所有组件都需要 memo。没有 trace 证据的建议，默认降级处理。
最后，优化后要复测真实设备。桌面开发机上快了，不代表低端手机上也快。性能建议必须落到目标用户设备上验证。
建议还要标注适用页面。后台表格页、营销落地页、移动 H5 的性能瓶颈完全不同。AI 如果给所有页面都建议“图片懒加载”，那就是模板化废话。建议必须绑定页面类型和用户路径。
性能优化也要进回归。今天拆包降低 LCP，明天新增依赖又涨回去。CI 里要保存关键指标趋势，超过预算就提醒。否则优化只是一次性表演。
最后，性能建议不要绕过产品取舍。某些动效、图片质量、数据实时性是产品需求。工程上可以提出成本，但不能偷偷砍体验。性能优化是协商，不是独裁。
建议评估还要考虑维护成本。一次性 inline 关键 CSS 可以提升首屏，但会让样式链路复杂；手写缓存可以减少请求，但会引入失效问题。AI 只看 trace，容易低估后续维护账。评估表里要给复杂度打分。
最后，建议要能回滚。性能优化不是只会前进，某些优化上线后可能影响转化或稳定性。每个优化 PR 都应该说明回滚方式和验证窗口。
灰度数据也要看。性能优化上线后，先观察一部分用户的 Web Vitals、错误率和业务转化。指标没问题再扩大。别在全量用户身上验证一个“理论上更快”的改动。
五、总结
AI 性能建议评估要看收益、成本和风险。建议必须绑定指标、验证命令和预期收益，不能只靠“看起来有优化”。前端性能优化不是把所有建议都做一遍，而是用最少复杂度换最确定的用户收益。
