降级到确定性路径的前提是该路径一直被维护，而非只在故障时才存在

概念解释

设计文档里写着「生成失败则回到表单」。表单如果只在故障时被编译进页面，平时没人点、没人测、数据模型已经跟生成管道分叉，故障那天它就是一条死路。退路要在平时被维护（fallback path must be maintained in peacetime）：确定性路径是主产品的一部分，不是抽屉里的应急包。

「有退路」是运行时的性质，不是架构图上的箭头。

机制

生成一旦成为主路径，流量、测试、设计资源都跟着走主路径。退路的字段、权限、文案停止与主数据模型同步，形成隐蔽的腐烂。故障把人第一次推到退路上，暴露的是几个月的不同步：缺字段、提交 500、权限不够、文案还在说「即将上线」。

人在压力下对生疏界面更差。一条平时从不露面的路径，没有机会形成技能。航空里备用仪表要定期通电；软件里的退路同样需要通电，否则备用本身是未测代码。

怎么研究

查退路的真实流量、最后一次测试日期、与主路径的 schema 差异。故障演练：在工作日把生成关掉，看退路完成率、缺陷数、用户是否找得到入口。自变量：退路是否在成功路径上也可达（例如「跳过智能，直接填表」一直在）、是否纳入每次发布的回归。因变量：演练完成率、缺陷年龄。

长期零流量的退路，先验就应当被当成已腐烂，除非有自动契约测试在跑。

边界

法规要求必须保留的纸质或离线流程，即使流量为零也得维护，成本要单独列，不能靠「没人用」删掉。原型阶段可以允许退路简陋，但一旦生成承接真实任务，简陋就变成事故。多租户里某些租户从未开通生成，他们的「主路径」其实就是别人的退路——维护责任更重。这条不讨论降级阶梯怎么排，只讨论排好的那一层会不会在抽屉里烂掉。

怎么落地

• 成功路径上提供「不用智能，走原表单」的常驻入口，让退路每天有流量。
• 退路纳入与主路径同一套回归：schema、权限、提交。生成管道改字段，退路同一提交必须绿。
• 定期关生成做演练，演练失败当发布阻断，不当成「那天运气不好」。
• 验证：看退路近三十天的成功提交数。为零，再看契约测试。两者皆无，退路按不存在处理，产品说明里删掉「失败可回表单」。再抽一次故障演练录像，数有多少人找不到入口。

延伸

• 同组：L1.06.1 失败时需回到确定性路径 · L1.06.2 降级顺序需预先定义 · L1.06.3 静默失败比明确失败更有害 · L1.06.4 失败分为无输出、错误输出与部分输出，三者需要不同的降级路径 · L1.06.5 最危险的是看起来正常的错误输出，它不触发任何降级机制 · L1.06.7 降级需保留用户已输入的内容，让用户从头再来是最常见的降级失败 · L1.06.8 超时与限流是可预期失败，其说明方式应与模型出错区分开
• 相邻：L4.09 技能退化 · L4.05 可中断与可回退 · L1.02 能力边界的表达
• 站内检索：rotting fallback · peacetime maintenance · manual path regression