上线检查清单提示词需严格按《SRE上线规范V3.2》第4.1～4.5条执行，逐条编号粘贴原文并附验证动作，强制用[✓/✗]格式输出，首行必须标注【阻断上线】或【准予上线】。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
写上线检查清单提示词时，必须确保模型能逐项核对生产环境变更的硬性约束，漏掉任何一项都可能引发服务中断或数据丢失。明确限定检查项来源
第一步：在提示词开头直接声明检查依据——【必须严格按《SRE上线规范V3.2》第4.1～4.5条执行，不得自行增删或合并条目】。这条不写清楚，模型会凭经验补全，而它“记得”的规范可能是过期版本。
第二步：把规范中每一条原文用编号+冒号格式粘贴进提示词，例如“4.1.1：数据库迁移脚本需通过review并标记为‘已批准’；4.2.3：新接口必须提供curl测试用例”。模型只认你给的文本，不认你心里想的“常识”。
第三步：在每条后加括号说明验证方式，比如“（验证：登录DBA平台查审批记录截图）”“（验证：运行curl -X POST http://test-api/v1/health -H 'Authorization: Bearer xxx'）”。没写验证动作的条目，模型默认跳过检查。
强制输出结构化结果
方法一：要求用固定符号分隔项与状态。指令写成：“每行格式：[✓/✗] 条款原文｜验证动作｜实际结果（如：[✓] 4.1.1：……｜查DBA平台｜审批单ID#A7721已存在）”。符号不统一，模型就混用对勾、文字“通过”、emoji✅，人工无法批量筛选✗项。
方法二：禁用自由发挥句式。在提示词末尾加一句：【禁止出现‘基本满足’‘大致符合’‘建议关注’等模糊表述，只允许‘✓’或‘✗’开头】。这类软性表达会让开发误判风险等级。
注入兜底校验逻辑
在提示词最后追加三行硬性规则：第一行写“若任一✗项存在，必须在输出首行标注【阻断上线】并换行”；第二行写“若所有项均为✓，首行标注【准予上线】并换行”；第三行写“未标注首行状态的输出视为无效”。没有这三行，模型可能把✗项埋在中间段落里，值班同学扫一眼就放过。
