来源：notes/documents/「把一次性判断写成默认规则」的观察与处置方法.md

「把一次性判断写成默认规则」的观察与处置方法

结论：把一次性判断写成默认规则，本质是把「某次上下文里的结论」压缩成「所有上下文的起点」。压缩本身有价值，但如果不告诉后来人这条规则从哪个场景推出来、在什么条件下失效，规则就会从「省决策的工具」变成「遮蔽上下文的墙」。

观察

• 现象：一次具体事件里做出的判断，事后被写进默认配置、工作规范、代码默认值或习惯里，之后不再被单独讨论。
• 典型形态：
  • 一次线上事故后加的兜底逻辑，变成所有调用路径的默认行为。
  • 一次评审里「这个字段先不填」，变成表单的默认空值约定。
  • 一次「先同步再汇报」的处理，变成所有任务的默认执行顺序。
  • 一段一次性的排查脚本，被复制成团队的标准入口。
• 共同点：这些判断在当时都对，而且当时有明确理由；被推广为默认之后，理由消失了，只剩结论。

为什么会发生

• 决策疲劳：重复判断成本高，写成默认值就不必再想第二次。
• 成功即证据：那次判断带来了好结果，于是被默认为普适。
• 传播成本不对称：写一条规则很便宜，删一条规则要解释为什么删。
• 路径依赖：后来的人只看到规则，看不到规则产生的现场。

代价

• 上下文丢失：执行者不知道规则的前提，遇到前提不成立的场景也不敢改。
• 错误蔓延：一次性判断里的近似、妥协和特例被无差别复制到新场景。
• 审查失灵：默认值不显眼，评审时容易被跳过，出问题后才被追溯。
• 组织记忆退化：规则越来越多，但「为什么」越来越少。

什么时候可以升格为默认规则

把一次判断写成默认之前，先问：

• 触发条件是否可复现：只在特定场景成立，还是普遍成立。
• 反例代价是否可控：默认错了会不会造成静默错误或数据损坏。
• 能否被局部覆盖：有显式退出开关比没有更安全。
• 是否有明确的失效条件：日期、版本、数据规模变化时是否应重新评估。
• 这条判断是否依赖已经消失的约束。

四项以上成立，才适合写进默认；否则更适合写成带前提的「建议」。

处置方法

卡片 01：结论旁边回填条件

• 适用场景：要把一次判断固化成默认值、规范或配置。
• 操作步骤：在结论后补一句「因为 X 场景下 Y 成立」，写清适用范围与失效条件。
• 失败信号：规则只有结论、没有前提，后来人不敢改也不知道能不能改。
• 效果指标：一个不了解背景的人能否据此判断自己该不该遵守。

卡片 02：默认值 + 显式出口

• 适用场景：规则会被大量路径自动继承。
• 操作步骤：默认取保守值，同时提供显式覆盖点（参数、开关、标注），让例外不必改规则本身。
• 失败信号：要处理例外只能改默认值，改完又影响所有人。
• 效果指标：最近一次例外的处理方式是走覆盖点，而不是改默认。

卡片 03：设复核时间与失效条件

• 适用场景：规则依赖当时的版本、规模或约束。
• 操作步骤：记录生效时间与复核触发条件，例如依赖升级、量级变化、同类事故复发。
• 失败信号：规则一直存在，但没人知道它还成不成立。
• 效果指标：每条默认规则都能回答「什么情况下应该重新看它」。

卡片 04：区分默认值与硬约束

• 适用场景：把「惯例」和「必须」混在一起表述。
• 操作步骤：明确标注是「默认如此，可覆盖」还是「必须如此，不可绕过」。
• 失败信号：惯例被当成硬约束，或硬约束被当成可选项。
• 效果指标：执行者能区分两类规则的处理方式。

来源

• 本笔记是对本工作区内反复出现现象的归纳，不是外部文献结论；其中的判据为经验规则，待验证。

下一步动作

• 挑 3 条当前在用、但说不清来源的默认规则，补上适用范围与失效条件。
• 给其中一条最容易误伤的规则加一个显式覆盖点。
• 下一次把判断写成默认规则之前，先用上面的判据过一遍。
• 待验证：这套判据能否在实际复盘中区分「该固化的经验」和「过期的妥协」，需要在接下来几次复盘里观察。