Apophenia Guard
"Apophenia: the spontaneous perception of connections and meaningfulness of unrelated phenomena. In debugging, it's the voice that says 'this must be related' when it absolutely isn't."
What It Does
You've been debugging for an hour. You've formed a theory. Every new piece of evidence seems to confirm it. You're deep in the code, cross-referencing logs, following a trail that feels inevitable —
And you're wrong. You've been wrong since minute twelve. Everything after that was confirmation bias wearing a lab coat.
Apophenia Guard is a cognitive bias interceptor that monitors debugging reasoning for the twelve most common cognitive traps that waste developer time, and intervenes before you spend three hours proving a hypothesis that a fresh pair of eyes would dismiss in three minutes.
The Twelve Cognitive Traps
1. Confirmation Bias
The trap: Seeking evidence that supports your theory while ignoring evidence that contradicts it.
CODEBLOCK0
Intervention: Force an inversion. State the opposite hypothesis and spend 5 minutes looking for evidence that supports it.
2. Recency Bias
The trap: Assuming the bug was introduced by a recent change because it was recently discovered.
CODEBLOCK1
Intervention: Check the last known good state. Binary search through history. The bug's discovery date is not its birth date.
3. Narrative Fallacy
The trap: Constructing a story that explains the symptoms, then treating the story as fact.
CODEBLOCK2
Intervention: Strip the narrative. List only what you've observed (not inferred). If the observation list is shorter than the theory, you're writing fiction.
4. Availability Heuristic
The trap: Assuming the cause is something you've seen before, because it's easily recalled.
CODEBLOCK3
Intervention: Pretend you've never seen this type of bug before. What would a first-principles investigation look like?
5. Anchoring
The trap: The first piece of evidence disproportionately shapes all subsequent reasoning.
CODEBLOCK4
Intervention: Deliberately start from a different symptom. If you started from the error log, start from the user report. If you started from the code, start from the data.
6. Sunk Cost Trap
The trap: Continuing down a debugging path because you've already invested time, not because it's productive.
CODEBLOCK5
Intervention: Time check. If you've been on the same theory for > 30 minutes without new supporting evidence, the theory is probably wrong. Start over. The time is already spent.
7. Fundamental Attribution Error
The trap: Blaming the system (framework, OS, compiler, hardware) when the bug is in your code.
CODEBLOCK6
Intervention: 99.9% of bugs are in your code. Check your code first. Check it again. Then check the framework.
8. Clustering Illusion
The trap: Seeing a pattern in random or coincidental events.
CODEBLOCK7
Intervention: Calculate the actual base rate. How many Tuesdays didn't have failures? What's the expected distribution? Random events cluster naturally — it doesn't mean anything.
9. Einstellung Effect
The trap: A known solution prevents you from seeing a better one (or the actual one).
CODEBLOCK8
Intervention: Describe the problem to someone (or rubber duck) without mentioning your solution. Let the problem define the solution space, not the other way around.
10. Survivorship Bias
The trap: Only examining the cases that failed while ignoring the cases that succeeded.
CODEBLOCK9
Intervention: Compare a failing case with a succeeding case side by side. The difference is more informative than either case alone.
11. Occam's Broom
The trap: Sweeping inconvenient evidence under the rug (Occam's Razor in reverse).
CODEBLOCK10
Intervention: Make a list of EVERYTHING you've dismissed. Revisit each item. If your theory requires ignoring more than one data point, it's probably incomplete.
12. The XY Problem
The trap: Debugging your attempted solution instead of the original problem.
CODEBLOCK11
Intervention: Stop. State the original problem in one sentence. If you can't, you've drifted. Return to the symptom. Start fresh from there.
The Guard Process
CODEBLOCK12
Output Format
CODEBLOCK13
When to Invoke
- - At the start of any debugging session (set the guard before bias sets in)
- When you catch yourself saying "I'm sure it's..."
- When debugging has exceeded 30 minutes without resolution
- When the explanation is getting more complex instead of more clear
- When you feel frustrated (frustration amplifies every cognitive bias)
Why It Matters
The hardest bugs aren't hard because the code is complex. They're hard because the debugging is biased. A developer with perfect reasoning and a simple set of tools will outperform a developer with every debugging tool and a biased mind.
Apophenia Guard doesn't help you find bugs. It helps you stop finding bugs that aren't there.
Zero external dependencies. Zero API calls. Pure cognitive bias detection.
模式幻觉防护
模式幻觉：自发感知无关现象之间的关联和意义。在调试中，它表现为一种声音，告诉你这肯定有关联，而实际上毫无关系。
功能说明
你已经调试了一个小时。你形成了一个理论。每一条新证据似乎都在证实它。你深入代码，交叉引用日志，沿着一条看似必然的线索追踪——
但你错了。从第12分钟开始你就错了。此后的每一步都是穿着白大褂的确认偏误。
模式幻觉防护是一个认知偏误拦截器，它监控调试推理过程中的十二种最常见认知陷阱，这些陷阱浪费开发者的时间，并在你花三个小时证明一个新鲜视角三分钟就能推翻的假设之前进行干预。
十二种认知陷阱
1. 确认偏误
陷阱： 寻找支持你理论的证据，同时忽略反驳它的证据。
检测信号：
├── 这证明了！出现次数多于这很奇怪……
├── 矛盾证据被当作噪音或无关而忽略
├── 调查在第一个假设之后收窄而非扩大
└── 你没有尝试反驳自己的理论——只试图证明它
干预： 强制反转。陈述相反的假设，花5分钟寻找支持它的证据。
2. 近因偏误
陷阱： 假设bug是由最近的变更引入的，因为它最近才被发现。
检测信号：
├── 昨天还能用 → 只调查今天的提交
├── 忽略bug一直存在的可能性
├── 混淆我们发现的时间与它开始的时间
└── 未检查旧版本中是否存在该bug
干预： 检查最后一个已知正常状态。通过历史进行二分查找。bug的发现日期不是它的出生日期。
3. 叙事谬误
陷阱： 构建一个解释症状的故事，然后将故事当作事实。
检测信号：
├── 一定是这样发生的……
├── 解释连贯、详细且未经测试
├── 你能描述bug的生命周期，但未验证任何步骤
└── 故事比证据更有说服力
干预： 剥离叙事。只列出你观察到的（而非推断的）。如果观察列表比理论短，你就是在写小说。
4. 可得性启发
陷阱： 假设原因是之前见过的，因为它容易被回忆起来。
检测信号：
├── 我以前见过这个——肯定是竞态条件
├── 在检查症状之前就跳到诊断
├── 你首先使用的工具是针对你假设的原因的
└── 从不同的项目/语言/上下文中进行模式匹配
干预： 假装你从未见过这种类型的bug。基于第一性原理的调查会是什么样子？
5. 锚定效应
陷阱： 第一条证据不成比例地塑造了后续所有推理。
检测信号：
├── 你的整个调查都追溯到你注意到的第一个异常
├── 你从未质疑第一条线索是否相关
├── 一切始于我看到……驱动着叙事
└── 未探索其他起点
干预： 刻意从不同的症状开始。如果你从错误日志开始，就从用户报告开始。如果你从代码开始，就从数据开始。
6. 沉没成本陷阱
陷阱： 因为已经投入了时间而继续沿着调试路径前进，而不是因为它有效。
检测信号：
├── 我已经搞了两个小时了，肯定快了
├── 不愿放弃你已经投入的理论
├── 调查越来越复杂，而非越来越聚焦
├── 新证据需要越来越复杂的解释才能符合理论
└── 你在添加本轮以拯救模型
干预： 时间检查。如果你在同一个理论上花了超过30分钟而没有新的支持证据，这个理论很可能是错的。重新开始。时间已经花掉了。
7. 基本归因错误
陷阱： 当bug在你的代码中时，归咎于系统（框架、操作系统、编译器、硬件）。
检测信号：
├── 一定是[库/框架/操作系统]的bug
├── 在检查你的逻辑之前，就有关于运行时行为的复杂理论
├── 这不应该可能 → 暗示平台有问题
└── 你在重新阅读自己的代码之前先阅读框架源代码
干预： 99.9%的bug在你的代码中。先检查你的代码。再检查一遍。然后检查框架。
8. 聚类错觉
陷阱： 在随机或巧合事件中看到模式。
检测信号：
├── 总是在星期二失败（样本量：2个星期二）
├── 只发生在以7结尾的用户ID上
├── 相关性被视为因果性，没有机制解释
└── 小样本量被解释为趋势
干预： 计算实际基准率。有多少个星期二没有失败？预期分布是什么？随机事件自然聚类——这并不意味着什么。
9. 思维定势效应
陷阱： 已知的解决方案阻止你看到更好的（或真正的）解决方案。
检测信号：
├── 你立即采用了熟悉的修复模式
├── 修复应该有效但无效，你仍在不断优化它
├── 你从未考虑过这可能是一个完全不同的问题
└── 你的解决方案词汇来自之前的项目/语言
干预： 向某人（或橡皮鸭）描述问题，不要提及你的解决方案。让问题定义解决方案空间，而不是反过来。
10. 幸存者偏误
陷阱： 只检查失败的案例，而忽略成功的案例。
检测信号：
├── 只调查失败的请求，不调查成功的
├── 出错的有什么不同？而不问
│ 正常工作的有什么相同？
├── 调查中没有对照组
└── 假设失败案例具有代表性
干预： 将失败案例与成功案例并排比较。差异比任何一个案例本身都更有信息量。
11. 奥卡姆扫帚
陷阱： 把不方便的证据扫到地毯下（反向奥卡姆剃刀）。
检测信号：
├── 那条日志可能无关
├── 忽略那个——这是已知问题（真的是吗？）
├── 不符合的证据未经验证就被标记为噪音
└── 解释要求你忽略部分数据
干预： 列出你所有忽略的内容。重新审视每一项。如果你的理论要求忽略超过一个数据点，它可能是不完整的。
12. XY问题
陷阱： 调试你尝试的解决方案，而不是原始问题。
检测信号：
├── 你无法再描述原始症状
├── 调查已从为什么X失败？
│ 转向为什么我对X的修复不起作用？
├── 你离用户可见的问题有好几层抽象
└── 如果我能把这个正则写对……（问题不是正则形状的）
干预： 停下来。用一句话陈述原始问题。如果你做不到，你已经偏离了。回到症状。从那里重新开始。
防护流程
持续监控：
├── 追踪每个假设活跃了多长时间
├── 统计支持当前理论的证据与反对的证据
├── 监控调查广度（收窄太快 = 偏误）
├── 当调查深度超过证据深度时发出标记
└── 在每个推理步骤检查陷阱特征
干预触发条件：
├── 假设活跃超过30分钟且无新支持证据
├── 反对证据计数 > 0 且理论未调整
├── 调查广度在任何时候 < 2个备选方案
├── 理论复杂度增长快于证据基础
└── 任何陷阱特征检测置信度 > 70%
干预格式：
├── 命名陷阱
├── 显示触发检测的证据
├── 建议具体的反制措施
└── 提供从不同入口点重新开始的选项
输出格式
╔══════════════════════════════════════════════════════════════╗
║ ⚠ 模式幻觉防护：干预 ⚠ ║
╠══════════════════════════════════════════════════════════════╣
║ ║
║ 检测到陷阱：确认偏误 + 沉没成本 ║
║ ║
║ 证据： ║
║ ├── 当前假设已活跃47分钟 ║
║ ├── 3个观察支持理论 ║
║ ├── 2个观察反驳理论（被当作噪音忽略） ║
║ ├── 调查已收窄到1个文件（开始时为12个） ║
║ └── 理论复杂度已增加两次，无新数据 ║
║ ║
║ 建议操作： ║
║ ├── 暂停：陈述你实际证明的内容（而非假设的） ║
║ ├── 反转：花5分钟尝试反驳你的理论 ║
║ ├── 比较：找一个工作案例，与失败案例进行差异对比 ║
