通义千问日志排查提示词：3招让内容更贴近真实用户

要让通义千问这类模型精准理解你的意图，必须剥除标准化表达，回归一线工程师在服务器告警、接口超时、线上报错时的天然提问方式。避免AI被翻译腔带偏，导致排查建议理论正确却执行无效。

用口语化问题链替换模板化句式

别用“定位根因”这种书面词。真实场景中，你只会手指屏幕质问：“连接池没释放？下游服务挂了？上次这种问题是老接口改了返回值类型。”——所有归因都是试探性猜测，以“是不是”“会不会”“有没有可能是”引导，而非“请分析……并定位……”的公文逻辑。

删掉所有“请……”“建议……”“可考虑……”等虚词。改用：“我看到……”“我试过重启没用”“日志连续三分钟打印这个warn”“翻过GC日志，Full GC高达八秒一次”。主语和动作痕迹必须保留。你说“请分析日志中异常堆栈”，对方觉得你在写周报。你说“这个堆栈我看了五遍，每次执行到第三行就崩”——大家明白你已在现场蹲了一小时。

嵌入真实日志片段特征

方法一：直接粘贴截断的日志行，不做任何清洗。保留时间戳乱码、缩写、拼写错误、不完整括号。例如：

2024-05-22T09:18:33.412Z WARN [OrderSvc] faild to parse user_id=abc123... Caused by: ja va.lang.NullPoinerExcepion

注意，faild拼写错误，NullPoinerExcepion缺字母，省略号后还有未闭合引号——这就是从终端直接复制的原始模样，没人会先格式化再提问。

方法二：混用多种格式的日志。例如在同一个提示词里，同时包含Nginx access.log的空格分隔字段、Spring Boot的JSON格式error日志、以及运维同事随手截图的终端滚动日志——里面甚至残留ANSI颜色代码，如u001b[33mWARNu001b[0m。不用处理。真实场景中没有人先标准化再排查，你拿到的就是这些混乱证据。

【不要清洗日志格式，真实场景没人先做标准化再排查】——这句话值得加粗。

加入上下文约束条件

第一步：明确你的权限边界。“我只有只读账号，不能查数据库，不能curl下游服务”。不说明这点，模型会给出需要写库的方案，但你无法执行。

第二步：说明你已经做过的排查。“已翻过最近2小时的logstash索引，grep了‘timeout’‘504’‘Connection refused’，无匹配；还查看了Prometheus的http_client_errors_total曲线，突增点与日志时间不吻合”。——这表示你已砍掉排查树的前几个分支。

第三步：指出最令你困惑的矛盾点。“奇怪的是，相同请求参数白天成功，凌晨批量跑全部失败，线程池配置未改动”。——这三步必须按顺序，因为你在递进排除。跳过第二步直接问“为什么失败”，对方会认为你没认真看现场。

有时候仅靠以上三步还不够，需要主动补充一个极易忽略的点：你没做什么。例如，“我只查了error级别日志，没看warn和debug”。或者，“我只截了三秒的窗口期”。有时指出自己遗漏了什么，比说明查了什么更有价值——答案往往就在你没看的那部分。

保留非技术干扰信息

别忘了随手丢一句非技术信息：“老板在群里@我催恢复时间，客户等着下单”，或“测试环境复现不了，只有生产有”。别管逻辑上是否多余——这类信息才是触发真实表达节奏的锚点。压力感、环境差异、协作角色会即刻改变提问密度和用词精度。它暗示模型：我现在没时间走标准排查流程，需要你直接给出最可能的方向，越具体越好。

无需解释这句话的作用，直接放进去。真实用户写提示词时不会标注“此处体现紧迫性”，他们只是顺手把刚收到的消息复制粘贴进去。你只需保留，它自然生效。

来源：互联网