你现在是资深sre工程师，负责为java微服务故障编写日志排查清单；每条检查项必须包含【检查目标】【执行动作】【预期现象】【异常信号】四要素。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让通义千问在写日志排查清单时，明确输出可执行、有上下文、带判断逻辑的检查项，而不是泛泛而谈的“检查日志是否正常”这类无效描述。
明确角色与输出格式
在提示词开头就限定AI的身份和交付物形态：告诉它“你现在是资深SRE工程师，负责为Java微服务故障编写日志排查清单”，并强制要求“每条检查项必须包含【检查目标】【执行动作】【预期现象】【异常信号】四要素”。
这一步不加限制会导致AI生成“查看日志级别”“确认日志路径”等无上下文的动作，无法直接用于现场排查。
绑定具体技术栈和错误现象
提供真实线索：比如“用户反馈订单创建超时，下游调用payment-service返回503，当前应用日志中出现大量ConnectionPoolTimeoutException”。
AI只有锚定到具体的异常类名、HTTP状态码、服务名和链路环节，才能推导出有针对性的检查项，例如“检查payment-service的HikariCP activeConnections是否长期满载→登录对应Pod执行kubectl exec -it
【不提供具体错误堆栈或监控指标，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列出“哪些日志现象看似异常实则正常”。例如，“WARN级日志中出现‘Failed to refresh token’但后续重试成功，不应视为故障依据”。
第二步：要求补充“哪些缺失才真正代表问题”。例如，“若日志中完全未出现‘Sending payment request to http://payment-svc:8080/v1/charge’这一关键trace语句，则说明请求根本未发出，需优先检查FeignClient配置而非下游响应”。
第三步：要求标注每项检查的耗时预估和权限依赖。例如，“检查JVM GC日志需具备容器内文件读取权限，单次执行约8秒，建议在业务低峰期操作”。
