代码优化最怕先改后测。AI 可以提出候选方案，但你必须先提供性能基线、调用场景和不可破坏的约束，才能判断一段改动是否真的值得合并。
先建立优化问题
| 信息 | 内容 |
|---|---|
| 基线 | 当前耗时、内存、请求量和测试环境 |
| 瓶颈 | 最慢函数、重复 I/O、N+1 查询或大对象复制 |
| 约束 | 正确性、兼容性、可读性和上线风险 |
| 验证 | 优化后必须重复的基准与回归测试 |
提示词模板
请基于以下性能数据分析可能瓶颈，并给出按收益/风险排序的优化候选。
不要改变业务语义；每项说明假设、改动范围、预期影响和验证办法。
如缺少数据，请先列出需要补测的指标。
代码与数据：[粘贴]改动后必须复测
比较同一环境下的 P50/P95、内存和错误率；再跑回归测试。只要收益不稳定或可读性明显下降，就不应为了“优化”而合并。代码质量审查可结合AI 代码评审提示词一起做。
