你是否也遇到过这样的困扰？当让 Gemini 分析一段报错日志时，它给出的回复往往过于模板化、缺乏真实项目里那种带有上下文、推理过程、排查路径甚至略带无奈语气的“人味儿”。

别担心，这篇文章将教你如何一步步把它“调教”成经验丰富的老手。

第一步：把要排查的系统“锚定”给 AI 看

在提示词的开头，明确写出技术栈和部署环境。例如：“你正在排查一个部署在阿里云 ACK 集群上的 Spring Boot 3.2 微服务，采用 MySQL 8.0 主从架构 + Redis 7.2 缓存，日志来自名为 order-service-7c9f5b4d8-xv6qk 的 Pod 容器。”

这一步至关重要。没有具体的环境信息作为依据，Gemini 会默认调用通用的 Java 异常模板，生硬地给出“数据库连接超时”这类结论。而在实际项目中，问题更可能是 RDS 白名单配置遗漏，或是 SLB 健康检查失败导致后端 Pod 被摘除。

第二步：日志，必须让它看到原始面貌

这里有两种可行的方法。

方法一：直接粘贴原始日志全文，包括时间戳、线程 ID、堆栈缩进等细节，一个字符都不要改动。

方法二：如果日志内容过长，就截取三个关键片段：异常头部（如 Exception in thread "xxx"）、根因行（Caused by: xxx）、以及最末尾的业务调用链（如 at com.xxx.order.service.impl.OrderServiceImpl.createOrder(OrderServiceImpl.java:142)）。

注意：千万不要对日志内容进行转述或改写。例如，不要把“java.net.ConnectException: Connection refused”改成“连接被拒绝”。Gemini 对原始错误字符串的模式识别能力，远高于对语义转述的匹配精度。你删掉一个空格或换行，它就可能无法匹配到对应的故障知识图谱。

第三步：让它清楚你当前所处的状态

想象你正坐在工位前，脑子还没完全反应过来，连监控都来不及打开。具体操作可以分为四步。

第一步，让它模拟“刚接到告警、尚未查看监控”的第一反应。例如：“你刚收到告警还没查看监控，第一反应是：① RDS 主库白名单配置遗漏（验证方式：kubectl exec -it order-service-7c9f5b4d8-xv6qk -- telnet rm-xxx.mysql.rds.aliyuncs.com 3306）；② SLB 健康检查失败导致 Pod 被摘除（验证方式：kubectl get pod -o wide | grep order-service-7c9f5b4d8-xv6qk）；③ MySQL 连接串端口写错（验证方式：grep "spring.datasource.url" /app/config/application.yml）。”

第二步，列出三条最有可能的现场原因（按概率从高到低排序），每条附带一句验证动作。就像上面示例那样。

第三步，指出哪条原因最容易被人忽略，并说明原因。例如：“最容易忽略的是第②条，因为 Pod 状态虽然显示为 Running，但 SLB 已经将其剔除，日志中看不到明显错误，只有超时重试的记录。”

第四步，给出一句可以直接复制粘贴到钉钉群里的同步话术。例如：“订单创建失败问题已定位，非代码原因，系 SLB 健康检查失败导致 order-service-7c9f5b4d8-xv6qk 被摘除，运维正在处理，预计 10 分钟内恢复。”

第四步：最后，封禁教科书式的表达

在提示词的末尾加上一句：“禁止出现‘该异常通常表示……’‘建议检查以下配置……’这类泛化表述；所有判断必须绑定本次日志中的类名、行号、IP 或端口号；如果某行日志信息不足，请写‘此处需查 XX 监控面板第 Y 个图表’，而不是‘需要进一步分析’。”

只有这样，Gemini 才能真正像一位面对真实项目的老手那样思考，而不是变成一个只会照本宣科的新手。