提示词需锚定真实运维场景，用一线工程师的口语化表达（如“这服务又崩了？”），提供真实日志片段，指定输出格式与角色，并嵌入具体排障细节和明确动作指令。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
用MarsCode写日志分析提示词时，如果生成结果总显得生硬、术语堆砌、像教科书或AI腔，说明提示词没锚定真实运维场景里的表达习惯——比如值班工程师凌晨三点翻着Kibana看ERROR堆栈，嘴里念的是“这服务又崩了？谁改的配置？”，不是“请定位异常请求链路并输出可观测性诊断结论”。
先锁定日志里真正要解决的人话问题
打开你手头正在处理的日志片段（比如Nginx 502错误+下游超时时间戳），别急着写提示词。先手写一句你此刻最想问同事的话，例如：“上游服务挂了但没报错日志，怎么从TCP重传包里看出是它扛不住了？”——这句话就是提示词的原始内核。
把这句话原样塞进MarsCode对话框，后面加一句：“用一线运维同事互相喊话的语气解释，不提‘可观测性’‘链路追踪’这种词，直接说‘怎么看’‘在哪找’‘改哪行’。”
这一步卡住很多人：他们写提示词时默认“专业=术语多”，结果AI真按字面理解，吐出满屏SLO/SLI/MTTR定义。而真实排障现场，没人说SLI，只说“用户点提交按钮后卡三秒以上算失败”。
用具体动作替代抽象要求
方法一：把“更接地气”拆成可执行指令
❌ 不要写：“请让结果更接地气。”
✅ 改成：“用‘你’开头，像在 Slack 里@同事说话：‘你去查 access.log 里 status=502 的那几行，重点看 upstream_addr 字段，如果全是 10.20.30.40:8080，就去那台机器 top 看 Java 进程 CPU’。”
方法二：指定输出载体和角色
在提示词末尾加：“输出格式：钉钉群消息体，带emoji，每句不超过15个字，结尾加?操作入口（如：Kibana链接 / Grafana面板ID）。”
【关键前提】必须提供真实日志片段的前10行和后10行，不能只给错误类型。没有上下文，AI只能编套路话。
植入真实排障中的非技术信号
第一步：回忆最近一次同类故障，记下两个细节——
① 当时你第一眼扫到哪行日志就心里一沉（比如某条 WARN 日志总在 ERROR 前3秒出现）；
② 你顺手截图发群里时，箭头圈住的是哪个字段（比如 timestamp 字段右对齐导致时间显示被截断，实际是时区错）。
第二步：把这两个细节写进提示词，例如：“注意：access.log 中 timestamp 字段靠右显示，实际值比显示多8小时，查时间范围时记得手动+8H。”
第三步：加一句限制：“禁止使用‘建议’‘可以考虑’‘一般情况下’这类模糊表述，所有判断必须带依据，例如‘因为 upstream_response_time > 3s 出现17次，超过阈值15次，所以判定超时’。”
这一步能砍掉70%的AI废话。真实值班现场没人说“可以考虑重启”，只说“现在立刻执行 systemctl restart nginx —— 我刚看到 error.log 里有 connection refused 报错，不是负载问题。”
