两轮验证原则

定义

任何方案或工具在首次跑通后，还需要经历第二轮主动验证（边缘条件测试 + 恢复机制确认），才能被认为真正稳定可用。首次成功只是"可行性证明"，不是"可靠性证明"。

不是什么（反例）

• 不是"凡事要测两遍"——那是操作层面的要求，这里说的是认知层面的校正：首次成功 ≠ 问题已解决
• 不是过度谨慎——不是每次提交都要做完整回归测试，而是在首次跑通后主动制造一次可控的边缘情况
• 容易混淆的是：把"我运行了一次没报错"当作"它已经稳定了"——这是最常见的认知盲区

为什么重要

应用场景

• 工具部署：新 Git 同步方案跑通后，故意制造一个提交错误，确认能否恢复
• 接口联调：接口联通后，验证超时、异常返回、边界数据的处理是否符合预期
• 工作流程改造：新流程走通一次后，找一个非标准情况跑一遍，看流程是否断掉
• IT 系统上线：功能测试通过后，专门做一次故障恢复演练

值得保持的

• 已有 Git 版本管理兜底的习惯，使得折腾时代价可控，可以大胆做边缘测试
• 遇到"差点丢数据"后没有放弃，而是找根因直到真正稳定

待改善的

• 首次跑通后容易进入"已解决"状态，缺少主动做第二轮验证的自觉
• 提交前没有确认 branch 的习惯——这是可以通过检查清单杜绝的低级错误

相关概念

• 系统鲁棒性 — 生活系统设计层面的冗余思维，两者共同指向"不要只优化顺境下的效率"
• 复盘 — 出了问题之后的系统回顾；两轮验证是出问题之前的主动预防
• 永恒困境 — 意外不是会不会发生，而是什么时候发生；两轮验证是在此认知下的行动应对

来源记录

• 2026-05-01：从 iOS Obsidian 同步排障经历中提炼，当时因未确认 branch 导致 main 被覆盖，靠 git reflog 救回