第一百章 旁路
麦景行的消息是晚上九点发来的。
「触发路径找到了，发你。截图比较多，你耐心看。」
路径分析有六张截图，麦景行从调用树往上找，最终定位到了触发条件。
`EVT_OVERRIDE = EVT_BYPASS_CRITICAL` 这行代码，在一个 `if` 分支里：当传感器 S1 和传感器 S2 的读值同时超出正常范围上限，且超出时间持续超过 5 个采样周期，这个分支就会激活。
激活之后，系统从「监督模式」切换到「简化运行模式」。简化模式下，部分保护检查流程被跳过，具体哪些还需要往下展开一层，麦景行在截图里标了注。
「你懂这是什么意思吗？」麦景行发了一条。
「是紧急旁路。」他回，「两路传感器同时异常，通常意味着传感器本身出了问题，不是设备真的在异常工作。这种情况下如果还走完整保护流程，会导致误停机。所以设计上让系统跳过部分保护，维持基本运行。1994 年的工控逻辑，标准做法。」
说白了：传感器失效时，这是个应急保命机制。但维护工程师不知道这是刻意设计的，可能直接把旁路条件注释成普通状态判断。照着注释操作，判断就会被带偏。
「那这是设计特性，不是 bug。」
「对。问题是没有文档，没有任何说明，没人知道它是设计特性。」
他打开船坞。
「工控 C 代码里发现一个紧急旁路机制：两路传感器同时异常时触发，跳过部分保护流程维持基本运行，1994 年设计进去的，没有任何文档说明。我们在做代码注释的可行性评估，遇到了这个情况。怎么处理？」
豆包：
> 这类安全关键路径的注释是设备维护的操作依据，功能说明做不到这个要求。如果这段代码被错误注释，后续维护时可能造成错误操作。建议：在可行性报告里单独列为「安全关键条目」，明确指出需要泉华安全团队确认历史设计意图，不能仅凭代码推断来写注释。
Claude：
> 从可行性评估的角度，这个发现改变了评估范围：G1 代码的注释工作不只是功能描述，还涉及这类路径的安全确认。建议在报告里写明：需要泉华提供原始设计文档或工程师确认。否则注释结论无法保证正确性，建议标注为待确认。
「好，这个方向对。」他把船坞关上，给麦景行发了一条：「先停止展开 G1 第二个函数。这个情况要先告诉方晓晨，不等最后报告。」
「现在就告诉他？」
「现在。」
他起草了一段简短的消息，给项磊。
「请帮我联系方晓晨，有一个情况需要提前同步。在 G1 模块里发现了一段安全关键路径，是 1994 年设计进去的紧急旁路机制，没有任何文档说明。我们在可行性报告里会单独列这类条目，但这部分注释需要泉华安全团队确认原始设计意图，不能仅凭代码分析来写。我想提前告知，合同层面暂时不需要变化，只是让你们知道这个发现。」
项磊回了一条：「要不要等报告一起说？现在提，怕甲方觉得我们在往外推风险。」
「安全关键路径不能等报告。等了，风险就留在我们手里。」
项磊没再问，两分钟后：「发出去了。」
他把手机放下，想到六周的评估窗口刚开始，第一个函数的宏展开就走出了这条路。
旁路本身不是问题，没有文档才是。
周六早上，方晓晨回了一条。
「收到你的消息。这个旁路机制我知道。1994 年有一批设计文档，但当年做归档的人已经退休了，文档存在不知道哪台服务器上。我来让我们的工程院查，如果找到了发给你。如果没找到，我们协议里怎么处理？」
这个问题，他提前没有想过。
文档找不到的情况下，他想到两条路：找在职工程师口头确认，注释标明来源和日期；或者把这个函数标成「需要安全团队专项评审」，注释暂缓，不强行写。再有就是最后的选项，直接跳过，在报告里注明无法确认。
他把这个问题发给麦景行：「你看哪种在技术上更可行，今天下午我来回。」
麦景行的回复来得很快，但不是选项评估。
「等等。陆哥，G3 那个 Python 模块——我顺手翻了一下，这个旁路宏，那里也有。」