边缘场景预案原则
领域：工作 · ●●●●○ · 个人操作系统概念
系统只覆盖典型场景，边缘场景代价会从设计阶段转移到现场
定义
任何系统、流程或预案，如果设计时只考虑了最典型的一种场景，那些没被考虑到的边缘场景并不会因此消失——它们的处理代价只是从设计阶段，转移到了出现问题的那个具体现场，由当时在场的人临时兜底。 系统平时跑得顺，不代表它已经准备好了所有情况。
不是什么（反例）
- 不是"必须穷尽所有可能性才能上线"——边缘场景无法穷举，重点是识别出"高概率会撞上的那几类"边缘场景并提前写清楚可执行路径，而不是追求理论上的完备
- 不是操作失误——现场处理不畅往往不是人不专业，而是流程设计本身就没给这类情况留出路径，责任不能简单归到值班人身上
- 不是"多写文档就够了"——文档只是载体，关键是这条路径有没有真正被培训、被记住、能在紧急时刻被调用出来
为什么重要
系统设计者天然会优先覆盖最常见、最典型的场景，因为那是设计时最容易想到、最容易验证的部分。但真实世界的复杂度不会因为设计简化而消失：没被覆盖的边缘场景一旦出现，处理它的成本不是被消除了，而是被推迟并放大了——从一次可以从容做的设计决策，变成了深夜现场一群人手忙脚乱的应急处理，而且往往缺乏统一口径、缺乏授权、缺乏可追责的流程记录。
应用场景
- 系统/产品设计：上线前问一句"这条流程只覆盖了哪种典型用户，还有哪类人会撞上去却无路可走？"
- 应急预案制定：不要只写"最常见的那种紧急情况怎么处理"，要专门找一次时间讨论"如果是这个但又不完全是，该怎么办"
- 培训组织：光把文档写全不够，要让一线人员真正在非紧急时刻演练过这条边缘路径，而不是等出事才第一次看到
值得保持的
遇到现场卡壳时，没有停在"这个人不专业"的归因上，而是主动往前一步问"是不是系统本来就没给这条路"，这个归因方式本身就是在保护同事、也是在真正找到能改的地方。
待改善的
目前还停留在"事后复盘时能看清楚"的认知层，下一次真正参与系统或流程设计时，需要养成在设计阶段就主动追问"这条路径漏了哪类人"的习惯，而不是等边缘场景真的撞上来才发现。
相关概念
- 两轮验证原则 — 视角互补：两轮验证原则关注"方案跑通后要主动测试边缘条件"（部署后验证），本概念关注"设计阶段就该把边缘场景纳入预案"（设计前覆盖），两者合起来覆盖了从设计到上线的完整链条
- 系统鲁棒性 — 领域呼应：系统鲁棒性关注生活系统关键单点的冗余设计，本概念是同一思路在工作/流程设计层面的具体化
来源记录
- 2026-07-17：提炼自 voicenote 2024-07-23《医院应急事件处理与系统培训不足》——交通事故批量伤员送诊，系统只给"三无人员"开了免费紧急挂号通道，没考虑"有身份、是受害者、但不愿垫付"这类边缘场景，导致分诊现场卡壳