Vibe Coding 发布故障恢复决策：何时回退，何时向前修复

发布异常时，最响亮的建议通常是“马上回滚”。这对无状态、向后兼容且旧制品随时可用的改动可能正确；对已经写入新格式、执行迁移、发送消息或触发外部动作的版本，盲目回退代码可能让旧 reader 接手它不理解的数据。相反，AI 提议的现场热修也可能在根因未确认时增加第二个变量。恢复决策的第一步不是选 rollback 或 roll-forward，而是停止继续扩大未知状态。

先暂停放量、自动重试、后续迁移和非必要 writer，保留在途任务，不随意删除“坏数据”。记录当前制品 digest、配置与 Flag 代际、schema/回填水位、活跃实例、队列游标、错误指纹和首次异常时间。用Vibe Coding 修复验收与根因闭环区分观察与推断；没有这些事实，模型只会根据错误文本猜最熟悉的恢复动作。

先问系统能否回到旧合同

回退可行性由合同决定，不由部署工具是否有“Rollback”按钮决定。逐层检查：旧制品还能否取得并验证摘要；当前配置是否仍被旧代码支持；数据库是否只做了兼容扩展；新版本是否写入旧代码不能解析的值；事件和任务是否固定消费者版本；外部副作用能否撤销或补偿。任何一项未知，都先标为证据缺失。

Kubernetes Deployment 可以回到先前 revision，但控制器恢复的是 Pod template，不会反转数据库、队列、对象存储和供应商状态。Git revert 创建反向补丁，也只处理版本库中的改动；它既不是制品发布，也不保证语义上撤销已经发生的副作用。因此恢复手册要分别列应用、配置、启用规则、数据和异步工作的动作。

可建立一个简短决策矩阵：若错误仍在扩大且旧合同完整，优先停止新流量并回退；若旧合同已被新数据打破但缺陷局部、修补可快速独立验证，优先 roll-forward；若两者证据都不足，进入隔离和人工决策，不让自动系统任选一个。恢复时间目标、修补复杂度和影响面用于排序，但不能压过数据不可逆性与安全边界。

让 rollback 成为完整发布

回退也要经过候选身份、门禁和观察。先验证旧制品及其配置组合，确认 schema 最低版本和新数据兼容，再逐步摘除坏版本。长连接、后台 worker 和定时任务可能继续运行旧进程，需要用版本化执行租约或队列暂停证明收敛。若通过 Flag 停止新路径，仍要对账已经接受的操作，不能把开关关闭当作副作用消失。

数据库发布次序应按Vibe Coding 数据库迁移编排预先保留兼容窗口。若回退要求数据转换，先在快照或隔离副本验证信息是否可恢复，并记录无法逆转的集合。不要因为自动 down 文件存在就默认安全；未知水位下的反向迁移可能覆盖上线后合法写入。

回退完成后重跑原错误探针和关键用户旅程，确认目标指纹停止新增、旧路径结果正确、队列与数据没有继续偏离。状态写成 rolled-back-observing，观察窗结束后才宣告恢复。回退只是恢复服务的候选动作，不是根因结论，后续仍需保留问题记录和防复发任务。

约束 roll-forward 的范围

向前修复适合旧版本已不兼容、回退耗时更长，或问题能由小型、机制明确的补丁阻断时。先从Vibe Coding 最小复现得到固定失败判据，只允许改动根因机制和必要观测，不顺手重构。候选补丁要在坏版本上让原复现失败转通过，并运行邻近回归；验证证据绑定新的 digest。

紧急不等于跳过边界。权限、金额、删除和迁移热修仍需要另一名 owner 审查，不能由生成补丁的同一 Agent 自批。若补丁需要新增永久重试、扩大超时、忽略异常或关闭门禁才能变绿，应视为掩盖而不是恢复。用编程 Agent 的改动验证门记录哪些检查因事故时限未跑，并把剩余风险公开带入观察窗。

预先写停止条件

恢复动作分小步推进，每步都有成功、失败和暂停条件。出现新错误指纹、数据差异继续增长、观测链断裂、候选身份不明或旧新实例无法区分时，立即停止自动扩展并升级人工处置。Google SRE 的 Release Engineering 强调一致、可重复和自动化的发布实践；自动化在这里应忠实执行已批准决策，而不是替人掩盖不确定性。

一次完整记录包括：冻结时的系统事实、可逆性矩阵、选择理由、执行步骤、每层收敛证明、未处置副作用、当前观察状态和后续 owner。Vibe Coding 原型退出门禁中的可运营要求也应覆盖这种恢复演练。真正的 rollback/roll-forward 能力，不是文档里各有一条命令，而是事故发生后仍能证明系统向哪个合同收敛，以及何时必须停下来。

延伸阅读

• Vibe Coding 修复验收与根因闭环
• Vibe Coding 数据库迁移编排
• Vibe Coding 最小复现
• 编程 Agent 的改动验证门
• Vibe Coding 原型退出门禁