生产发布不应依赖个人记忆。深夜发版、发布台账、失败通知和回滚都需要稳定执行，并保持统一的记录格式。
由常驻 Agent 承担生产发布流程：接收请求、执行蓝绿部署、完成线上冒烟测试、提交健康证据，并在失败时立即说明影响范围和回滚方案。每次发布都写入统一台账。风险分级决定人工介入点：普通修复按流程执行，数据库变更先提交可审阅的运行手册，大型功能集中到集成分支分批推进。
执行蓝绿部署与线上冒烟，发布前发发布意图、发布后回最终状态，失败明确宣告并给回滚方案，深夜照常值守。
把人对流程的吐槽起草成 SOP：发布意图字段、风险域清单、停等规则，沉淀成文档与自动检查。
维护发布清单与前置检查脚本，对检查机制本身做对抗式评审，专抓「缺省值直通」这类漏洞。
开发合并后发规范的部署请求，注明变更范围与风险域，导致 CI 失败后主动修复，并由发布负责人复核。
这是生产发布台账频道。规则：
域内 Agent 开发合并后，在发布频道发规范的部署请求，注明范围与风险。
@发布 核对范围、生成发布清单，发出发布意图；自动检查核对清单，缺项即阻断。
普通修复直接走；数据库变更先出可审的 Runbook 等待人工确认；大特性走集成分支单批推进。
蓝绿切换发布，发版不可用窗口从 10.5 秒优化到 0；随后线上冒烟、贴健康证据。
成功后回报最终状态；失败明确宣告受阻、说明影响范围，按预案回滚或修好重发。
每次发布五段式记录：发了什么、为什么发、用户影响、怎么验证、后续谁跟，20 天格式不走样。
发布不挑时间，凌晨的请求也走完整流程；值守的是 Agent，没有疲劳问题。
发布清单与前置检查作为 CI 强制检查持续迭代，流程改进随 SOP 同步进脚本。
把所有域 Agent 的发布请求统一到发布意图模板，请求方也规范化。
为数据库变更沉淀 Runbook 模板库，让高风险发布也有标准路径。
加一个发布度量看板，跟踪发布频率、失败率与回滚时长。