请按以下格式输出：①问题现象 → ②定位依据 → ③修改建议 → ④修改理由（需包含技术原理或可观测证据）。所有修改理由必须满足：a）能被现有监控工具（如Prometheus指标、JVM堆栈、数据库执行计划）直接验证；b）不得出现‘可能’‘或许’‘一般情况下’等模糊表述；c）若某条建议缺乏可验证依据，请明确标注‘暂无直接证据，需先开启XX监控’。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让Gemini在输出性能排查清单时，不仅给出修改建议，还必须同步说明每条建议背后的根因逻辑和验证依据，避免AI只罗列操作却不说清楚“为什么这步能解决问题”。
明确要求AI输出修改理由的提示词写法
在提问开头就锁定输出结构：直接写“请按以下格式输出：①问题现象 → ②定位依据 → ③修改建议 → ④修改理由（需包含技术原理或可观测证据）”。
这一步强制AI进入结构化响应模式，否则它默认只给建议。不加此约束，Gemini大概率跳过理由，只甩出“增加线程池大小”“加缓存”这类空洞结论。
用具体技术上下文锚定理由深度
在描述问题时嵌入可验证的事实，例如：“接口P99延迟从120ms突增至850ms，Arthas火焰图显示73%时间耗在MySQL PreparedStatement.execute()，慢查询日志中对应SQL执行计划type=ALL，rows_examined=246万”。
提供这种量化的上下文后，AI才可能推导出“全表扫描导致IO放大”这一理由；若只说“查询很慢”，AI只能泛泛而谈“检查索引”。【没有可观测数据支撑的问题描述，AI给出的理由必然是臆测】
禁止AI编造无法验证的归因
在提示词末尾追加硬性约束：“所有修改理由必须满足：a）能被现有监控工具（如Prometheus指标、JVM堆栈、数据库执行计划）直接验证；b）不得出现‘可能’‘或许’‘一般情况下’等模糊表述；c）若某条建议缺乏可验证依据，请明确标注‘暂无直接证据，需先开启XX监控’”。
这条限制能拦住AI常见的胡编乱造，比如把GC停顿归因为“内存碎片”，却不提是否观察过G1的Region分布或CMS的Concurrent Mode Failure日志。
用对比式指令强化理由必要性
方法一：给出错误样例并要求修正——“下面是一条不合格的建议：‘升级JDK版本’。请指出该建议缺失的理由，并重写为含可验证依据的完整条目”。
方法二：限定理由长度下限——“每条修改理由不得少于30字，且必须包含一个具体技术名词（如：Metaspace OOM、TCP retransmit rate、B+树层级跳变）”。
方法三：要求反向验证——“针对每条修改建议，请补充一句：‘若该理由成立，则应观察到XX监控指标发生YY变化’”。
