绿灯之下：一次被 try/except 藏起来的认知层失效

 绿灯之下：一次被 try/except 藏起来的认知层失效

那天所有测试都是绿的。
一次重构里，15 个认知模块从仓库里被删掉了——感知、推理、记忆流、词汇、领域注意力……它们合起来是一整套认知层。删完之后，程序照常启动，日志照常滚动，测试照常通过。
一处报错都没有。
这就是问题所在。

 一、那 90 行代码
main.py 第 28 到 117 行，长这样：
`python try:     from cognitive.growing_brain import GrowingBrain except ImportError:     GrowingBrain = None `
重复 15 次。每个认知模块一行 try，一个 except，一个 = None。注释里写着四个字：优雅降级。
写下这四个字的时候，它是对的。单体模块不该拖垮整个进程，缺个可选组件降级运行，是常识。
但「优雅降级」有个前提：降级是临时的、可观测的、有告警的。 三者缺一，它就从保险变成创可贴——贴在伤口上，让伤口不再喊疼。
缺的正是告警。
ImportError 被吞掉的那一刻，系统做了一次语义翻译：
- 原文：cognitive.perception 这个库不存在了。
- 译文：Perception = None，也就是「这个功能没启用」。
前者是一个错误，后者是一个合法状态。系统分不清「我关掉了它」和「它已经不存在了」。三十多处引用全部悬空，每一处都在运行，每一处都以为自己只是没开这个开关。

二、不是测试发现的
发现它的是 git status，更准确地说，是 diff 里那一列 D。
测试为什么发现不了？因为测试针对功能。功能被 try/except 摘掉了，测试自然也就没得测——而没得测，覆盖率工具会把它算成「未覆盖」，不是「已失效」。没人看 diff，没人看那一列 D，它就能一直安静下去。
这就是静默失效的形状：系统所有成功信号都还在，只是它们已经不再描述系统的真实状态。
绿灯不等于路对。绿灯只说明没有东西拦住你，拦住你的可能是别的。

 三、同一个形状，在另一层出现过
同一个项目里，还有另一个后台服务：一个自组织网络，节点会随运行自适应增生和剪枝。那几天它的规模从 500 个节点塌到了 82 个。
根因是剪枝。用的是相对阈值——按权重分布分位数剪掉尾部。常规做法。问题在于没有绝对下限：当整个网络放电变弱，权重分布整体下移，相对阈值就跟着往下拽，一刀切在最活跃的那批节点上。
两种故障，一个形状：
- 导入层：错误被 except 翻译成合法状态。
- 参数层：绝对量级被相对判据吞掉。
都是判据失去了绝对参照。前者失去的是「导入失败必须出声」这条硬约束，后者失去的是「权重低于多少就不该活」这条硬底线。
补丁小得可怜：前者把吞掉的 ImportError 记一条 warn、启动时自检；后者加一行 ABS_PRUNE_FLOOR = 0.01。
修复后，塌陷从 500→82 变成 500→480。方向对了，但我没把这个数当结案——480 离 82 还很远，绝对值仍然不好看。止损不等于治本，这句也写在这儿。

 四、三条小规矩
1. 删模块，先查引用。 grep -rn "import xxx" 是最基本的检查，必须做。有两个模块顶着 30 多处引用，差点和那 13 个一起被清掉。
2. 降级必须出声。 except 里不许沉默。哪怕只打一行 log，也比 15 个 = None 强。静默降级是技术债里利率最高的一种。
3. 提交前看 --name-status。 那个 D 列，比测试报告诚实得多。

 五、最后
两个故障，出在同一个项目里，却不是同一双眼睛看到的。
做塌陷分析的时候，视角全在动力学层：剪枝、权重分布、放电频率。判断是对的——相对阈值切掉了最该保留的那批节点，加一条绝对下限就止住了血。
但认知层的静默失效，不落在这个视角里。它只出现在 git diff 的 D 列。
层内正确，层间不完整。这大概是在这个项目里学到最实的一课：你的监控指标，决定了你的盲区形状。
绿灯之下，有 13 个模块已经死了很久。