你是一名有三年SRE经验的运维工程师，负责日均百万请求的电商订单系统；输出标准回滚操作清单，覆盖从发现异常到服务恢复的全部动作；必须包含触发条件、执行命令（含具体参数）、验证方式三项硬性约束，并按T+0秒｜T+60秒｜T+120秒｜T+180秒｜T+300秒时间节点组织，每节点分“动作｜命令/按钮｜预期响应”三栏，含失败兜底逻辑，且所有操作须可通过CI/CD按钮或一行命令完成。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
回滚预案提示词要按角色视角生成
你需要让DeepSeek输出可直接落地的发布回滚预案，但同一份提示词在SRE、开发、测试三类角色手中产出内容偏差极大——SRE关注命令可执行性与熔断路径，开发聚焦代码版本切换逻辑，测试则紧盯验证用例覆盖度。
第一步：在提示词开头锁定身份，例如“你是一名有三年SRE经验的运维工程师，负责日均百万请求的电商订单系统”。不写明具体职责和系统规模，模型会默认输出通用模板，漏掉灰度比例、Apollo配置中心回滚路径等关键项。
第二步：任务描述必须含“标准回滚操作清单”“覆盖从发现异常到服务恢复的全部动作”两个硬词。只写“帮我写个回滚步骤”，模型可能只给3条模糊建议，无法支撑真实故障处置。
第三步：插入【不可省略的硬性约束】：必须包含“触发条件（如错误率>15%持续2分钟）”“执行命令（含具体参数，如curl -X POST http://config-center/v1/rollback?env=prod&version=2.3.1）”“验证方式（curl -s http://api/order/status | jq '.version'）”三项。缺一不可，否则生成的步骤在告警时刻无法直接执行。
回滚预案提示词要按执行场景拆解
生产环境回滚不是单点操作，而是分阶段推进的动作链。提示词必须强制模型按时间线组织内容，从T+0秒（发现告警）开始，到T+300秒（确认恢复）结束。
方法一：用时间节点驱动结构
在提示词中明确要求：“按以下时间节点组织内容：T+0秒｜T+60秒｜T+120秒｜T+180秒｜T+300秒；每个节点下分‘动作’‘命令/按钮’‘预期响应’三栏，用竖线分隔。”
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
方法二：绑定失败兜底逻辑
追加指令：“若curl命令返回404或超时，立即执行降级动作：①将DNS权重切至备用集群；②通知值班同学启用熔断开关。”这句必须写进提示词，否则模型不会主动补全故障蔓延时的逃生路径。
方法三：禁用人工干预动作
写明“禁止生成任何需要登录服务器手动修改文件的步骤；必须所有操作均可通过CI/CD平台按钮或一行命令完成”。这条约束能直接过滤掉“vi /etc/nginx/conf.d/app.conf”这类不可自动化的伪步骤。
回滚预案提示词要按验证维度嵌套
一份合格的回滚预案，验证环节不能只靠一句“检查服务是否正常”。必须把验证拆成三层：基础连通性→业务功能→数据一致性。
① 基础连通性验证：curl -I http://api/order/status → 预期返回HTTP/1.1 200 OK，超时即失败。
② 业务功能验证：curl -s http://api/order/status | jq '.version' → 必须精确匹配上一稳定版本号，如"2.3.0"，不能只写“返回旧版本”。【注意：若返回值含空格或引号包裹，jq解析会失败，必须提前用sed处理】
③ 数据一致性验证：curl -s "http://data-check/v1/compare?from=2.3.0&to=2.3.0" | jq '.diff_count' → 预期返回0，非0需触发数据修复流程。
