gemini 1.5 pro 必须基于三类原始数据（带时间戳的异常指标表格、含$request_time等字段的access log或trace json、含堆栈首行的stderr错误日志）和结构化提示词（限定技术栈与分析边界）才能准确定位后台数据异常根因，否则分析不可靠。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要用 Gemini 1.5 Pro 快速定位网站后台数据异常的根本原因，而不是泛泛而谈“可能有缓存问题”或“检查数据库连接”，必须让模型聚焦在真实日志、指标和代码路径上输出可验证动作。
先拿到三类关键原始数据
没有这三样东西，Gemini 1.5 Pro 的分析就是空中楼阁。它无法凭空猜出你用的是 Spring Boot 还是 Django，更不知道你的慢查询是否被 Druid 连接池阻塞了。
第一步：从 APM 或监控系统里导出最近 1 小时内最刺眼的指标截图——不是曲线图，是带时间戳和数值的表格截图，例如 “/api/v2/order/export 接口 P99 响应时间：4280ms（正常应＜300ms）”。
第二步：复制对应时间段内 Nginx 或网关的 access log 片段（至少含 20 行），重点保留 $request_time、$upstream_response_time、$status 字段；如果用了 OpenTelemetry，直接导出 trace_id 开头的完整 span 链路 JSON。
第三步：抓取后端服务的标准错误日志（stderr）中连续报错的 15 行，必须包含堆栈起始行（如 “java.lang.OutOfMemoryError: Java heap space” 或 “redis.clients.jedis.exceptions.JedisConnectionException”）。【漏掉堆栈第一行，Gemini 会误判为业务逻辑异常而非资源耗尽】
用结构化提示词锁定分析边界
Gemini 1.5 Pro 支持超长上下文，但默认会发散。必须用指令强制它进入 SRE 角色并限定技术栈范围。
方法一：填空式模板（推荐用于重复排查）
“你是一名专注 Java 微服务稳定性保障的 SRE，当前处理【订单导出服务】异常，现象是【粘贴第一步抄的指标】。技术栈为【Spring Boot 3.1 + MyBatis-Plus + Redis 7.2 + ShardingSphere-JDBC】。请严格按以下格式回答：① 最可能原因：……；验证方式（命令/代码行）：……；② 次可能原因：……；验证方式：……；③ 排查盲区提醒：……（例如‘注意 ShardingSphere 的 sql.show 是否开启导致日志刷爆磁盘’）。”
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
方法二：三段式指令（适合首次深度分析）
第一段写事实：“当前 /api/v2/order/export 接口 P99 耗时突增至 4280ms，已确认非 CDN 缓存问题（Cloudflare 日志无 5xx）、非网络抖动（同机房其他接口正常）。”
第二段定边界：“请只分析 Java 应用层代码与中间件配置原因，不讨论 Kubernetes Pod 内存 limit 设置、Linux ulimit、前端重试次数。”
第三段要动作：“列出 3 个最可能的根本原因，按概率降序排列；每个原因后紧跟 1 条可立即执行的验证命令，例如 ‘jstack -l
把日志和指标喂给 Gemini 的实操步骤
① 打开 https://gemini.google.com → 点击右上角模型切换器 → 选择 “Gemini 1.5 Pro”。
② 点击输入框旁的「?」图标 → 依次上传三类文件：第一张指标截图（PNG）、第二段 access log（TXT）、第三段错误日志（TXT）。上传顺序不能错，Gemini 会按顺序解析上下文。
③ 在输入框中粘贴你写好的结构化提示词（填空式或三段式），**不要额外加任何解释性文字**，例如删掉“请帮我看看下面这些材料”这种引导句——Gemini 1.5 Pro 已通过文件上传明确知道你要分析什么。
④ 点击发送。等待约 8～22 秒（取决于日志体积），模型将返回带编号的根因列表及每条对应的验证命令。
