想借助Gemini高效诊断性能瓶颈，第一步并非仓促撰写提示词，而是要精准锁定异常现象，并准备好最直观的监控指标截图。CPU使用率曲线、GC频率、SQL平均响应时间、HTTP 5xx错误率——这些才是真正值得关注的数据。这一步无法省略——缺少具体指标，Gemini只能依据模糊描述进行泛化推测，最终结论必然偏离实际。

将截图中最醒目的数值记录下来，比如“/api/order/list接口的P95耗时从120ms骤升至2800ms”“Full GC每3分钟触发一次”“Redis连接池耗尽告警持续了47分钟”。这些精确的数值，是后续深入分析的基础。

先锁定问题现象再写提示词

打开监控系统（如Prometheus+Grafana、Datadog或APM工具），直接截取异常指标。这一步不可或缺——没有具体指标截图，Gemini只能基于模糊描述进行泛化推测。

把截图中最刺眼的数字摘录下来，例如“/api/order/list 接口P95耗时从120ms突增至2800ms”“Full GC每3分钟触发一次”“Redis连接池耗尽告警持续47分钟”。

用结构化模板约束输出范围

一个有效的方法是采用三段式指令，将提示词拆分为三个部分：

第一段，陈列事实：“当前现象是【粘贴刚才抄录的指标】，已排除【简述已验证项，如‘确认非网络抖动，CDN日志无异常’】”。

第二段，划定分析边界：“请只分析Java Spring Boot服务端代码层原因，不讨论K8s资源配额、Linux内核参数、前端重试逻辑”。

第三段，明确期望的输出动作：“列出3个最可能的根本原因，按概率降序排列；每个原因后紧跟1条可立即执行的命令或代码检查点，例如‘grep -r ‘new Thread’ ./src/main/java/ | grep -v test’”。

另一种是填空式提示词，适合反复复用：

“你是一名拥有5年Java高并发经验的SRE。现在处理一个【服务名】性能问题，现象是【粘贴指标】。技术栈限定为【Spring Boot 3.2 + MyBatis + Redis 7】。请严格按以下格式回答：① 最可能原因：……；验证方式：……；② 次可能原因：……；验证方式：……；③ 排查盲区提醒：……（例如‘注意Druid连接池maxActive配置是否被动态覆盖’）。”

禁用开放式提问词

删除所有“为什么”“有哪些可能”“怎么优化”这类发散型提问方式。将“为什么接口变慢”改为“对比上周同时间段trace，/api/order/list在doFilter→service→mapper三层中，哪一层耗时增幅超300%？”

将“怎么优化SQL”改为“给出EXPLAIN ANALYZE结果中Seq Scan占比＞80%的3张表的索引重建语句，要求覆盖WHERE user_id = ? AND status IN (‘A’,‘B’) AND create_time > ?条件”。

这一步操作非常简单：直接把你原本写的“请分析性能问题”整行删掉，替换成带有具体路径、参数、阈值的指令句。效果立竿见影。