我的AI应用中最糟糕的错误不是崩溃。而是那些已经构建、连接、测试、在CI中通过，但在生产环境中从未真正起作用的功能。我已经发现了20多个。你们是怎么抓到这些的？

这个错误总是反复出现，我仍然没有一种干净的方法在发布前捕捉到它。从外表看，它总是看起来一样。模块存在，从正确的地方调用，测试通过，标志开启。但在生产环境中它从未做任何事。没有错误，没有日志，没有任何警报，因为没有任何失败。一些造成伤害的例子。我们的每日后台作业从未运行过一次。调度器将last_run保持在RAM中，所以每日作业需要24小时的正常运行时间而不重启才能首次运行。但每次推送部署都会重启进程，我们一天推送大约5次。我检查时的正常运行时间是20.4小时。因此，那些已经开启超过两周的作业运行了零次。显而易见的修复方法，就在启动时运行，会增加大约20%的大模型调用。实际修复方法是将时间戳存储在磁盘上。我们有一个间隔重复引擎，用于安排复习以便学生记住内容。它运行过，连接过，通过了测试。它的唯一调用者有一个注释说状态是全局的，只有一个学生。这个学生是助手本身。没有任何测试能捕捉到这一点，因为连接是正确的，只是为错误的人工作。当我把它指向真实用户时，我发现间隔没有上限，20次完美复习后下一次是1.08亿年后。另一个存在于每个请求路径上的功能，我所有的审计工具都显示它是活跃的。它从未触发过一次。if语句有两个条件，第二个条件来自一个完全不同的模块中的隐私决策（匿名意味着不持久化），这对我们的所有流量都是假的。阅读该模块本身无法告诉你任何信息，你必须阅读每个条件的判断，并找到谁设置了它。最糟糕的甚至没有失效。我们有一个预取功能，猜测你的下一个问题并预计算答案，以便点击可以立即提供服务。它触发了，被计为一次节省，我们自己的报告说它花费了零代币。然而，每次命中都是一次损失：预计算的答案来自没有上下文和来源的小模型，并替换了完整管道本应说的话。而且无论是否有人点击，每回合都预取3个问题。所以现在我在称任何东西完成之前，大致按顺序问：它是否在真实请求实际经过的路径上。它的判断依赖于什么，这在生产环境中是否为真，而不仅仅在测试数据中。谁读取它的输出，因为计算一个决定并丢弃它看起来与做出它完全一样（我们有一个路由器每回合选择小模型或大模型，而我们的主路由从未读取它）。它是为谁工作的。当它工作时，结果是比正常路径更好还是更差。CI在所有这些中都是绿色的。我有一个从主路由出发的可达性检查，以及每一步有多少请求通过的计数，这可以捕捉到死的功能。错误的人和错误的方向的功能我只通过阅读代码发现过。那么你们是怎么抓到这个的？是否有类似覆盖率但针对真实生产流量的东西，告诉某个分支从未执行过？或者你们只是拒绝在没有计数器证明它触发过的情况下发布功能？