答案是：提供具体服务名、数据库实例id、中间件集群标识的可执行清单，每项含检查位置、预期结果、异常动作，动词开头，一行一项，2分钟内可完成。● 登录dba平台→查prod-order-db实例→确认activeconnections ≤ 85% ● 执行kubectl get pods -n payment | grep gateway-v2.4.1 → 确认ready为2/2 ● 访问sentinel控制台→payment-gateway集群→redis-call规则→确认熔断开关为on
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要一份能直接贴在运维看板上、让值班工程师扫一眼就懂的上线检查清单，而不是堆满术语的AI生成模板。
先砍掉“正确但没用”的废话
删掉所有类似“请确保系统稳定性”“注意风险控制”这种空泛表述——它既不能指导操作，也无法被验证。
把“检查数据库连接池状态”改成“登录DBA平台→查prod-order-db实例→确认ActiveConnections ≤ 85%”。
【关键前提】必须提供本次上线涉及的具体服务名、数据库实例ID、中间件集群标识——没有这些，模型只能编造通用条目。
用真实运维动作倒推提示词结构
方法一：按巡检路径写提示词
“你是一名刚交接班的SRE，手上有3个待上线服务：payment-gateway-v2.4.1、user-profile-api-1.9.3、notification-svc-3.0.0。现在你要检查这3个服务在K8s prod集群中的运行状态，请输出一份可逐项打钩的清单，每条包含：①检查位置（如‘kubectl get pods -n payment’）②预期结果（如‘READY状态为2/2’）③异常时立即执行的动作（如‘若READY不是2/2，立刻kubectl logs -c main’）。”
方法二：用故障案例锚定检查项
“参考去年11月因redis连接超时未降级导致订单失败的真实事故，在本次payment-gateway-v2.4.1上线清单中，必须包含：检查熔断器开关状态（路径：Sentinel控制台→payment-gateway集群→流控规则→redis-call规则→确认开启）、验证降级返回值（curl -v http://localhost:8080/fallback/test →响应体含\"code\":200,\"data\":\"mock\"）。”
强制模型输出“人话”格式
第一步：明确禁用词汇
在提示词末尾加一句：“禁止出现‘建议’‘应当’‘需关注’等模糊动词；所有条目必须以动词开头，例如‘执行’‘比对’‘确认’‘截图存档’。”
第二步：指定物理载体
“输出格式严格按以下结构：一行一个检查项，每项用‘●’开头，不编号，不换行，不加粗，不使用markdown语法。示例：● 执行kubectl get cm -n payment | grep ‘config-v2.4.1’ → 确认返回非空”
第三步：塞入真实约束条件
“本次上线窗口为今晚23:00–23:30，所有检查项必须能在2分钟内完成单次验证——若某项耗时超过90秒，请拆分为前置检查（上线前）和实时检查（上线后）两个条目。”
