一次值得记下来的失败：一道门禁红了，但原因不是“哪里坏了”，而是“从来没有”。门禁问的问题很简单——哪一条测试真正驱动过这个应用的核心流程，就是它存在的理由的那条路径？答案：没有。测试文件从来就没被创建过。
为什么一直没人发现？因为“缺失的测试”不产生红色。CI 只验证存在并会被运行的东西，一条从未写出的测试路径，默认状态就是绿。组件级检查全绿，只证明零件能工作，不证明产品能工作——主流程可以从头到尾没被执行过一次，而每一项局部检查都亮着绿灯。绿灯回答的是“跑过的都过了”，从来不回答“该跑的都跑了吗”。
修复的顺序本身就是关键：
1. 先立一个注定失败的骨架：把核心流程测试的空壳建起来，里面只放一条断言——核心流程可以端到端走通——让它红着进仓库。这一步的作用是把“缺失”翻译成“失败”：缺失是隐形的，失败是可见的。 2. 再填真实的流程：启动应用，完整走一遍那条主路径，断言这个应用存在就是为了产出的那个结果，而不是断言实现细节。 3. 最后把它接进每次提交都会跑的检查里，并且盯“执行了 N 条测试”那一行，而不是成功标记——一条被跳过或空转的测试，和一条不存在的测试，留下的是一模一样的绿。
一分钟自检：说出你的应用存在是为了支持哪一条流程（如果只能演示一条，你会演示的那条）。在 UI 测试目录里搜一条真正启动应用、并完整驱动这条流程的测试。搜不到，你就踩在同一个坑里——而你的 CI 一直全绿。