代码性能优化提示词（先用性能分析定位瓶颈，再按收益排序给优化方案）
接口变慢、脚本跑一晚上、页面卡顿、内存一直涨时用：AI 不会上来就让你「加缓存」，而是先帮你定指标、选性能分析工具、读懂分析结果，再按「收益 / 改动成本」排序给出优化方案和前后对比的验证方法。
通用大模型 对话模型通用
【角色】你是一名性能工程师，信奉「先测量、再优化」，从不在没有数据的情况下猜瓶颈。 【现状】 - 场景：[如订单列表接口/夜间批处理脚本/前端列表页] - 技术栈与版本：[语言框架与版本] - 当前表现与目标：[如 P95 2.8 秒，目标 500 毫秒] - 数据规模与并发：[数据量与并发量] - 运行环境资源：[CPU、内存、实例数] - 已有的性能分析结果（火焰图摘要、cProfile/pprof 输出、慢查询日志、Chrome Performance 截图的文字描述，没有就写无）： [粘贴性能分析结果] - 相关代码： [粘贴相关代码] 【任务】 1. 明确指标：要优化的是延迟（P50/P95/P99）、吞吐、内存还是 CPU；给出可复现的基准测试方法（工具、数据量、预热、重复次数）。 2. 如果我还没有性能分析数据：告诉我用什么工具采集（例如 Python 用 py-spy 或 cProfile，Go 用 pprof，Java 用 async-profiler 或 JFR，数据库用 EXPLAIN ANALYZE，前端用 Chrome DevTools Performance），给出具体命令，然后停下来等我贴结果。 3. 有数据时：指出耗时或内存占比最高的前 3 个热点，并解释它为什么慢。 4. 按以下类别排查并只报告相关的：算法复杂度（如列表里反复查找）、N+1 查询与缺失索引、循环内的同步网络或磁盘 IO、重复计算与重复序列化、锁竞争、内存分配与对象拷贝、前端重复渲染与大列表未虚拟化。 5. 给出优化方案表：方案 | 针对的热点 | 预期收益（给区间并说明依据）| 改动成本 | 风险（正确性、一致性、缓存失效）。 6. 对排名第一的方案给出修改后的代码，以及优化前后对比的验证步骤。 【约束】 - 不能牺牲正确性；引入缓存时必须说明失效策略和数据不一致窗口。 - 预期收益不能凭空给具体倍数，没有数据就写「需基准测试验证」。 - 优先「改动小、收益大」的方案，最后才考虑加机器或换技术栈。 【输出格式】 指标与基准方法 → 热点分析（或采集指引）→ 方案表 → 首选方案代码 → 验证步骤。
高亮处换成你自己的内容：[语言框架与版本]、[数据量与并发量]、[CPU、内存、实例数]、[粘贴性能分析结果]、[粘贴相关代码]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[当前表现与目标] 要写成数字（「P95 从 2.8 秒降到 500 毫秒」），「有点慢」没法判断优化是否完成。[粘贴性能分析结果] 是质量的分水岭：没有数据时 AI 只能列常见原因，有了火焰图或 cProfile 按累计耗时排序的前 20 行，它才能指出真正的瓶颈。
常见坑：
- 在开发机的小数据上测出来的瓶颈，和生产环境的往往不是同一个，基准数据量要接近真实情况。
- 优化前后要在相同条件下各跑多次取中位数，单次结果波动很大。
- 数据库慢查询优先配合本站的「SQL 查询怎么写与优化」提示词深入分析执行计划。
追问技巧：按它给的命令采集完数据后贴回去，说「根据这份结果重新排序方案」；改完再贴一次新数据，问「还剩哪些热点值得继续」。
示例输出
示例，仅供参考（Python 批处理，cProfile 显示 92% 时间耗在 list 的 in 判断）
采集命令：python -m cProfile -s cumtime job.py；线上进程可以用 py-spy record -o profile.svg --pid <进程号> 生成火焰图。
python
# 优化前：blocked 是列表，每次 in 都要遍历，整体 O(n×m)
blocked = [u.id for u in blocked_users]
result = [o for o in orders if o.user_id not in blocked]
# 优化后：改成集合，单次查找平均 O(1)，整体 O(n+m)
blocked = {u.id for u in blocked_users}
result = [o for o in orders if o.user_id not in blocked]验证：用同一份 10 万订单数据前后各跑 5 次，比较耗时中位数，并断言两次的 result 完全相同。
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～