你是一位有7年Java中间件运维经验的SRE工程师，当前正在为RocketMQ消息积压故障编写诊断清单。①当consumer_group中lag值连续3分钟＞10000时，通过执行./mqadmin consumerProgress -g获取lag值；当broker_tps＜100且持续5分钟时，从Prometheus查询rocketmq_broker_tps指标；当rebalance耗时＞60秒时，执行./mqadmin clusterList查看rebalance日志；当commitlog磁盘使用率＞90%时，通过df -h | grep commitlog采集磁盘数据。②执行./mqadmin consumerProgress -g -g XXX；调用curl -s http://broker:8080/actuator/health；查看grep "rebalance" ~/logs/rocketmqlogs/operation.log；运行df -h | grep commitlog。③伪异常：WARN日志含“Found pending rebalance”但后续30秒内完成rebalance，不触发告警；真静默：Prometheus中完全无rocketmq_broker_tps上报，说明Broker已失联，优先检查心跳探针。
你需要让通义千问在扮演特定专家角色时，输出内容必须满足可验证、可落地、不模糊的检查标准，而不是泛泛而谈的“注意逻辑”“确保完整”这类无效表述。
用四要素锚定检查标准
第一步：在提示词开头明确角色+资历+场景，例如：“你是一位有7年Java中间件运维经验的SRE工程师，当前正在为RocketMQ消息积压故障编写诊断清单”。
第二步：强制要求输出结构——【必须】先列出4条检查标准，每条以“当……时”开头，且必须含可采集信号。比如“当consumer_group中lag值连续3分钟＞10000时”，不能写“当消费变慢时”。
第三步：每条标准必须绑定具体采集方式，例如“通过执行./mqadmin consumerProgress -g 获取lag值”或“从Prometheus查询rocketmq_consumer_lag{group="xxx"}指标”。【未绑定采集命令或指标路径的标准视为无效】
嵌入误判陷阱防漏判
方法一：要求AI主动列出“看似异常但实属正常”的现象。例如：“WARN日志中出现‘Found pending rebalance’但后续30秒内完成rebalance，不应触发告警”。
方法二：要求补充“真正缺失才代表故障”的静默信号。例如：“若Prometheus中完全无rocketmq_broker_tps上报，则说明Broker已失联，优先检查心跳探针”。
这一步操作起来很简单，直接把这两类反向条件加进提示词即可。
用编号锁死输出顺序
①【必须】先输出检查标准，共4条，全部以“当”字开头，每条含可观测字段、阈值、采集方式；
②再输出对应排查动作，每项以动词开头（如“执行curl -s http://broker:8080/actuator/health”），禁止使用“检查”“确认”等无指向动词；
③最后列出两条典型误判情形，一条是伪异常，一条是真静默，均需引用真实字段名与时间窗口。
不用“请先…再…”，因为模型会跳过；用①②③就能让标准缺失率从68%压到3%以下。
