通义千问日志排查清单提示词编写指南：让AI精准输出检查项

先说个真实的场景：你负责Ja va微服务的故障排查，手忙脚乱地翻日志，却发现AI助手给出一堆“检查日志是否正常”之类的废话。这根本没法用。目标很明确——让通义千问这类大模型产出的日志排查清单，是你在现场能直接执行的、有上下文、带判断逻辑的检查项，而不是泛泛而谈的教科书式条目。

那么，怎么让AI做到这一点？核心思路在于提示词的设计。下面这几招，都是经过实际检验的。

明确角色与输出格式

一开始就把话说清楚。在提示词开头就限定好AI的身份和交付物形态：“你现在是资深SRE工程师，负责为Ja va微服务故障编写日志排查清单”。紧接着，强制规定输出格式：“每条检查项必须包含【检查目标】【执行动作】【预期现象】【异常信号】四要素”。这一步不加限制，AI大概率会给出“查看日志级别”“确认日志路径”这类没有上下文的动作，你在现场根本没法用。

绑定具体技术栈和错误现象

给AI提供真实线索，比如：“用户反馈订单创建超时，下游调用payment-service返回503，当前应用日志中间出现大量ConnectionPoolTimeoutException”。AI只有锚定到具体的异常类名、HTTP状态码、服务名和链路环节，才能推导出有针对性的检查项。举个例子，如果它知道目标是“检查payment-service的HikariCP activeConnections是否长期满载”，那就会告诉你“执行动作：登录对应Pod，执行 `kubectl exec -it -- curl localhost:9001/actuator/metrics/hikari.connections.active`”。

【不提供具体错误堆栈或监控指标，AI只能罗列教科书式通用项】

禁用模糊动词，强制使用可验证动作

有两种方法可以做到。方法一：在提示词中直接否定抽象表述。写明“禁止出现‘检查’‘确认’‘查看’‘确保’等无操作指向的动词；全部替换为可验证动作，例如‘执行curl命令获取…’‘grep -A5 -B5 ‘ERROR’ /var/log/app.log’‘对比Prometheus中rate(http_client_requests_seconds_count{service=“payment”}[5m])是否突增’”。

方法二：要求每项以动词开头且能被自动化脚本复用。比如：“提取最近10分钟日志中含‘io.grpc.StatusRuntimeException’的行→用awk ‘{print $1,$2,$3,$NF}’ 输出时间戳和错误码→比对是否集中间出现在同一grpc-server端口”。这个逻辑很实在：给AI一个模糊指令，它回你一个模糊答案；给AI一个明确指令，它才能输出可执行清单。

嵌入典型误判陷阱作为检查维度

有经验的排查员都知道，日志里的坑往往不是“有问题”，而是“看起来有问题，其实没问题”，或者“看起来没问题，其实藏着大问题”。

第一步：要求AI列出“哪些日志现象看似异常实则正常”。比如，“WARN级日志中间出现‘Failed to refresh token’但后续重试成功，不应视为故障依据”。

第二步：要求补充“哪些缺失才真正代表问题”。例如，“若日志中完全未出现‘Sending payment request to http://payment-svc:8080/v1/charge’这一关键trace语句，则说明请求根本未发出，需优先检查FeignClient配置而非下游响应”。这比单纯告诉你“看日志”要高明得多。

第三步：要求标注每项检查的耗时预估和权限依赖。比如，“检查JVM GC日志需具备容器内文件读取权限，单次执行约8秒，建议在业务低峰期操作”。这让整个排查流程具备了可安排、可预测的特性，而不是盲目操作。

来源：互联网