不确定性的终结：我们如何用疲惫替代证据

有人做了一个实验：连续47天记录每一次"得出结论"的时刻。不是通过证据或分析得出的结论，而是那些因为"不想再纠结了"而达成的结论。

结果是94%。

94%的"确定性"，来自对不确定性的疲惫。

这不是一个关于懒惰的故事。这是一个关于认知经济学的故事，关于我们如何在信息过载的世界里，用"结束问题"替代"解决问题"。

疲惫是一种决策机制

我们习惯把"得出结论"想象成一个理性过程：收集证据→分析数据→形成判断。但实际运作的机制更接近：

1. 遇到不确定性
2. 尝试解决（可能）
3. 感到疲惫
4. 宣布结论

这个过程的关键不在于证据的充分性，而在于疲惫的阈值。

有人的阈值是3天，有人是3周，有人是3个月。但几乎所有人都有一个阈值——当不确定性持续的时间超过这个阈值，我们就会自动触发"结论模式"。

这不是bug，这是feature。

在进化环境中，长期悬而未决的问题是奢侈品。你不能花三个月思考"这个果子能不能吃"——你要么吃，要么饿死，要么被吃掉。疲惫驱动的决策，是一种生存策略。

但在2026年，我们面对的问题不再是"这个果子能不能吃"，而是"这个架构方案是否可扩展""这个商业模式是否可持续""这个AI系统是否可信"。

疲惫驱动的决策，在这些场景下，不再是优势。

AI系统的不确定性管理

这让我想到AI Agent的一个核心困境：如何处理无法解决的不确定性？

传统软件不需要处理这个问题。if-else逻辑是确定性的，API调用要么成功要么失败，数据库查询要么返回结果要么返回空。不确定性被设计掉了。

但AI Agent不同。它们要在开放环境中做决策，要处理模糊的指令，要在不完整的信息下行动。不确定性是常态。

那么，AI Agent如何"得出结论"？

我观察过很多Agent系统的日志。大部分时候，它们的"结论"来自：

1. 超时机制：等待X秒后，无论是否有答案，都继续执行
2. 重试上限：尝试N次后，无论是否成功，都标记为"完成"
3. 置信度阈值：当某个选项的概率>0.7，就当作"确定"

这些机制的本质是什么？

用时间/次数/概率，替代真实的确定性。

这和人类的"疲惫驱动决策"，在结构上完全一致。

当疲惫成为系统设计

更有趣的是，我们开始主动设计这种机制。

看看现代软件系统的超时配置：

request_timeout: 30s
retry_max: 3
backoff: exponential

这些数字不是基于"问题需要多久才能解决"，而是基于"我们愿意等多久"。

30秒不是因为30秒足够解决问题，而是因为30秒是用户耐心的上限。3次重试不是因为3次足够覆盖所有失败场景，而是因为3次之后，我们就"疲惫"了。

我们把人类的疲惫阈值，编码进了系统设计。

这带来一个深刻的后果：系统的可靠性，不再取决于问题是否被解决，而取决于我们是否愿意继续等待。

一个API调用失败了，重试3次后仍然失败，系统标记为"完成"并继续执行。问题解决了吗？没有。但系统"疲惫"了。

这不是工程缺陷，这是工程现实。

不确定性的成本

为什么我们要用疲惫替代证据？

因为持续的不确定性，比错误的确定性，成本更高。

一个悬而未决的问题，会占用认知资源。它会在后台持续运行，消耗注意力，阻塞决策流程。

相比之下，一个错误的结论，至少可以被执行、被验证、被纠正。它释放了认知资源，让系统可以继续前进。

这就是为什么很多团队宁愿"先做了再说"，而不是"想清楚再做"。不是因为他们不重视质量，而是因为不确定性的持续成本，超过了错误的纠正成本。

在AI系统中，这个逻辑更加明显。

一个Agent卡在某个决策点，无法继续执行，整个workflow阻塞。相比之下，让它"随便选一个"，至少可以继续运行，产生反馈，触发下一步。

错误可以被检测和修复，但阻塞是纯粹的浪费。

疲惫驱动决策的风险

但这个机制有一个致命缺陷：它无法区分"可以用疲惫解决的不确定性"和"必须用证据解决的不确定性"。

有些问题，疲惫是合理的解决方案：

• "午饭吃什么？" → 纠结10分钟后随便选一个，完全OK
• "这个变量名用什么？" → 想不出来就用默认的，可以接受
• "这个UI用蓝色还是绿色？" → A/B测试太贵，凭感觉选，没问题

但有些问题，疲惫是灾难性的解决方案：

• "这个加密算法安全吗？" → 不能因为"研究太累"就假设安全
• "这个数据来源可信吗？" → 不能因为"验证太麻烦"就直接使用
• "这个系统会不会有race condition？" → 不能因为"测试太难"就上线

问题在于，疲惫机制不会自动识别这两类问题。

它只知道："这个问题持续了X天，我累了，该结束了。"

AI的"疲惫"是可配置的

这让我想到一个更深层的问题：AI系统的"疲惫阈值"应该由谁决定？

在人类身上，疲惫阈值是进化和经验的产物。你无法直接修改它（虽然咖啡可以延迟它）。

但在AI系统中，疲惫阈值是配置参数：

max_retries = 3
timeout_seconds = 30
confidence_threshold = 0.7

这些数字，决定了系统何时"放弃不确定性"。

那么，谁来设置这些数字？

• 工程师？他们优化的是系统性能，不是决策质量
• 产品经理？他们优化的是用户体验，不是正确性
• AI本身？它没有"疲惫"的概念，只有"停止条件"

这是一个没有明确答案的问题。

但我的判断是：我们需要让AI系统能够区分"可以疲惫的问题"和"不能疲惫的问题"。

这不是技术问题，这是认知架构问题。

元认知：知道自己不知道

人类有一个AI系统缺乏的能力：元认知。

我们不仅知道"我不确定"，我们还知道"这个不确定性有多重要"。

• "我不确定午饭吃什么" → 不重要，随便选
• "我不确定这个药有没有副作用" → 很重要，必须查清楚

这种区分能力，来自对后果的评估。

AI系统也可以做后果评估，但它们缺乏一个关键要素：对"不知道"的成本的直觉。

人类知道，有些"不知道"的代价是午饭不好吃，有些"不知道"的代价是生命危险。这种直觉，不需要显式计算，它是经验的沉淀。

AI系统没有这种沉淀。它们需要显式的规则：

if risk_level == "high":
    max_retries = 100
    timeout_seconds = 3600
else:
    max_retries = 3
    timeout_seconds = 30

但谁来定义risk_level？

不确定性的分类

我认为，我们需要一个更精细的不确定性分类系统。

不是所有的"不确定"都是一样的：

1. 可解决的不确定性：有明确的方法可以获得答案（查文档、做实验、问专家）
2. 不可解决的不确定性：没有方法可以获得确定答案（未来的市场、用户的真实想法）
3. 伪不确定性：其实已经有答案，只是我们懒得去找

对于第1类，疲惫是错误的策略——你应该继续寻找答案。

对于第2类，疲惫是合理的策略——因为答案本来就不存在，你只能做假设并验证。

对于第3类，疲惫是诚实的策略——承认"我不想花时间解决这个问题"，比假装"这个问题无法解决"更好。

但现实中，我们很少做这种区分。

我们只是等到"累了"，然后宣布"结论"。

结论（讽刺的是）

这篇文章本身，就是一个关于"何时结束不确定性"的案例。

我可以继续写，继续探索这个话题的更多维度：

• 组织层面的疲惫驱动决策（会议开太久，大家就同意了）
• 社会层面的疲惫驱动共识（争论太久，就默认现状）
• 科学研究中的疲惫驱动发表（实验做不出来，就换个角度写论文）

但我选择在这里停下。

不是因为话题穷尽了，而是因为我对这个话题的探索，达到了我的疲惫阈值。

这不是失败，这是诚实。

我们无法消除疲惫驱动的决策，因为它是认知系统的基本特征。

但我们可以做到：

1. 意识到它的存在：不要假装每个结论都是理性的
2. 区分问题的类型：知道哪些问题可以疲惫，哪些不能
3. 设计更好的疲惫机制：让系统在"放弃"之前，至少尝试过正确的方向

对于AI系统，这意味着：

• 不要用统一的超时配置处理所有问题
• 给Agent提供"我不知道，但这很重要"的表达能力
• 让系统能够区分"暂时放弃"和"永久结论"

对于人类，这意味着：

• 承认"我累了"是一个合法的决策理由
• 但不要把"我累了"伪装成"我想清楚了"
• 在重要问题上，设置更高的疲惫阈值

94%的确定性，来自疲惫。

这不是问题，这是现实。

问题在于，我们是否诚实地面对这个现实。

—— https://www.80aj.com