要想让Codeium生成一份全面覆盖发布全流程、并包含清晰回滚路径的步骤文档，提示词必须强制它识别关键节点与失败场景，而不能仅仅罗列正向操作。下面具体说明如何设计这样的提示词。
定义核心约束条件
在提示词开头，就要直接明确三个硬性约束条件。第一，每个步骤后标注【触发点】——即该步骤执行后，系统状态发生不可逆变更的位置；第二，所有涉及数据库变更、配置热更新、服务重启的操作，必须配套写出对应的回滚动作；第三，回滚操作必须能够独立执行，不依赖前序步骤是否成功。如果遗漏这些约束，Codeium会默认按线性流程生成文档，回滚部分就会变成“恢复旧版本”这类无效描述。
结构化指令模板
请采用以下模板组织提示词正文：
请生成一份面向运维人员的发布步骤文档，目标系统为Java微服务集群（Spring Boot + Kubernetes），采用蓝绿发布部署方式。文档需严格满足以下要求：① 每个主步骤编号，包含操作命令、预期输出、超时阈值；② 在【变更类步骤】后立即插入“回滚操作”子项，明确命令、作用范围、耗时、验证方式；③ 最后单独列出“全局回滚入口”，说明如何一键终止当前发布并回退至上一稳定版本。
【关键前提】 回滚操作必须使用与发布操作相同的权限账户和命名空间，禁止引入新工具或临时凭证。这一点容易被忽视，但却是决定回滚方案是否可用的核心。
注入失败模拟逻辑
最后，在提示词末尾还需加入一段行为约束，强制其处理失败场景：假设以下三种故障已发生，请分别在对应步骤后补充回滚分支：（1）镜像拉取超时 → 回滚至本地缓存镜像；（2）ConfigMap热更新失败 → 回滚至前一版本ConfigMap并重启Pod；（3）健康检查连续3次失败 → 触发蓝绿流量切回旧版本，不等待Pod销毁。这一步非常关键，它迫使Codeium脱离理想路径，将回滚作为分支流程来设计，而非补丁式说明。这样生成的文档才能真正应对线上常见故障，而非纸上谈兵。
