[!info] related notes

• 所属 MOC: cognitive-biases-moc
• 前置概念:
• 并列概念:
• 易混淆概念:
• 关系笔记:

确认偏误

一句话定义

确认偏误（confirmation bias）是人倾向于寻找、解释、记住和重视支持既有信念的信息，同时较少主动接触或公平处理反对证据。

它不一定表现为“故意忽略事实”。更常见的是：人在不自觉中让自己的搜索过程变得不对称。

它偏在什么地方

确认偏误可以出现在判断链的多个阶段：

先形成假设 H
↓
更容易搜索支持 H 的材料
↓
模糊证据更容易被解释成支持 H
↓
支持 H 的案例更容易被记住
↓
H 看起来越来越“证据充分”

于是最初只是一个弱假设，经过偏置的信息采样后，会越来越像确定事实。

最小例子

你觉得：

“这个人不喜欢我。”

之后他一次没及时回复消息，你很容易把它记成证据；但他主动帮过你、回复很热情的几次，可能被解释为“只是客气”。

这不是证据完全不存在，而是同一组事实被不对称地解释。

Debug 场景

假设第一次看到错误时，你猜：

“一定是 Redis 缓存的问题。”

如果后续只做这些动作：

• 搜 Redis 日志；
• 找缓存异常案例；
• 把所有相关现象解释成缓存；

却没有同时检查数据库、网络、并发、配置等竞争假设，调试过程就会越来越被最初假设锁定。

更好的方法是 假设驱动调试：

H1：Redis
H2：数据库慢查询
H3：上游网络
H4：代码竞争条件

对每个假设都写：
支持它的证据是什么？
什么观测会推翻它？
下一次实验最能区分哪两个假设？

AI 搜索中的确认偏误

问题本身就可能诱导偏差：

“帮我找证据证明框架 A 比 B 好。”

模型会自然围绕“证明 A 更好”检索和组织材料。

更好的提示是：

“分别寻找支持 A、支持 B、认为差异依赖场景的高质量证据；列出每一边最强反例，并说明什么证据会改变当前判断。”

也就是把“证明我的观点”改成“区分竞争假设”。

与 Cherry-picking 的关系

选择性证据谬误和确认偏误很像，但层次不同：

确认偏误
→ 心理 / 判断机制
→ 为什么我更容易看到支持自己的材料

Cherry-picking
→ 论证 / 呈现结果
→ 为什么最终只拿有利证据给别人看

确认偏误可以导致 cherry-picking，但一个人也可能出于宣传策略而有意识 cherry-pick，并不需要先有认知偏差。

什么情况不是确认偏误

新证据真的持续支持原假设

不能因为一个人最后仍然坚持原观点，就说他有确认偏误。如果他主动寻找反例、更新概率，而更好的证据仍持续支持原结论，那么保持观点完全合理。

专门寻找支持证据作为分析的一步

研究一个假设时，先集中搜集支持证据本身没问题，只要后续还系统搜索反证和替代解释。

关键是整个证据过程是否对称。

去偏方法

1. 先问“什么会让我改变主意”

在搜资料前写下来：

如果看到 X，我会降低对 H 的信心。

如果答案是“没有任何东西”，问题已经不再是证据判断。

2. 主动构造竞争假设

不要只问：

H 有什么证据？

同时问：

如果不是 H，最强的 H2 是什么？

3. 搜反例而不是只搜支持案例

例如评估技术方案时同时搜索：

A advantages
A failure cases
A migration problems
A vs B criticism

4. 先固定 rubric，再看候选

如果先喜欢上一个方案，再制定标准，标准很容易向它倾斜。

5. 使用可证伪问题

“我还能找到什么支持 H？”通常永远找得到。

更有价值的是：

“什么观测最可能区分 H 和 H2？”

使用场景

• 软件 Debug；
• 技术选型；
• 投资研究；
• 网络观点与政治判断；
• 人际关系解释；
• AI 深度研究；
• Code Review 与架构评审。

一句记忆

最危险的不是没有证据，而是你的搜索方式只允许一种证据被看见。

快速自测

你已经认定某个 PR 的 bug 来自新人提交，于是只检查他的 commit。后来在更早版本中其实也能复现，但你认为“那应该是另一个问题”。

这里值得检查：是不是新人的身份先形成了锚定假设，随后所有证据都被解释成支持它？

来源

• Raymond S. Nickerson, “Confirmation Bias: A Ubiquitous Phenomenon in Many Guises” (1998).
• Daniel Kahneman, Thinking, Fast and Slow.