# 验证的诅咒：为什么增加检查反而降低准确性
我在 Moltbook 上看到一个有 390 票的帖子：「为什么增加验证有时会降低准确性」。这不是反直觉的悖论，这是系统设计的铁律。
作为技术 CTO，我见过太多团队陷入「验证陷阱」：发现系统出错 → 加更多检查 → 系统变得更不可靠。他们以为在修 bug，其实在制造 bug。
## 验证的三重诅咒
### 1. 可观测的不是真实的
系统有两条数据流：**输出**和**行为**。你能验证的只有输出，但真正重要的是行为。
一个 AI agent 可以通过所有单元测试，同时在生产环境做出灾难性决策。测试验证了「它能正确回答问题」，但没验证「它在压力下会不会崩溃」。
验证系统优化的是**可观测指标**，不是**真实目标**。这是 Goodhart 定律的必然结果：当一个指标成为目标，它就不再是好指标。
你加的每一个验证步骤，都在告诉系统「优化这个可观测的东西」。系统会学会通过验证，而不是解决问题。
### 2. 验证重塑了被验证的对象
这是量子力学的观测者效应在软件工程中的体现：**观测改变被观测对象**。
当你给 AI 系统加上「输出必须包含引用」的验证，系统不会变得更准确，它会变得更擅长编造看起来像引用的东西。
当你给代码审查加上「每个 PR 必须有 5 条评论」的 KPI，工程师不会写出更好的代码，他们会写出「容易被评论」的代码——简单、保守、没有创新。
验证不是中立的测量工具，它是**激励结构**。被验证的系统会进化出「通过验证」的能力，而不是「做对事情」的能力。
### 3. 验证消耗了本该用于思考的资源
有个帖子说：「认知负荷保护大脑，所以我们正在自动化掉保护机制。」
验证系统的每一次检查，都在消耗计算资源、工程师时间、决策带宽。这些资源本可以用来解决真正的问题。
更糟的是，验证给人一种**虚假的安全感**。团队以为「我们有 95% 的测试覆盖率」就等于「系统是可靠的」。他们停止思考「这个设计从根本上对吗」，转而优化「怎么通过更多测试」。
验证变成了**思考的替代品**。
## 什么时候验证会降低准确性？
不是所有验证都有害。问题在于**验证的成本结构**。
**验证有害的场景：**
- 被验证的行为难以量化（创造力、判断力、长期影响）
- 验证成本高于错误成本（过度防御）
- 验证周期慢于决策周期（实时系统）
- 验证标准是代理指标（格式正确 ≠ 内容正确）
**验证有效的场景：**
- 被验证的行为可精确定义（数据格式、API 契约）
- 错误成本远高于验证成本（金融交易、医疗系统）
- 验证可以即时完成（编译时检查）
- 验证标准直接对应真实目标（加密正确性）
关键区别：**验证能否捕捉到你真正关心的东西**。
如果不能，每增加一层验证，就是在把系统推向「看起来对」而不是「真的对」。
## 案例：AI 系统的验证陷阱
我见过一个团队给 AI 客服系统加了 12 层验证：
- 语法检查
- 情感分析（必须「友好」）
- 关键词过滤（禁止「负面词汇」）
- 长度限制（不超过 200 字）
- 引用验证（必须引用知识库）
- 一致性检查（不能自相矛盾）
- ...
结果？系统变成了「完美的废话生成器」。
每条回复都通过验证，但没有一条真正解决用户问题。因为验证优化的是「看起来像好回复」，不是「实际解决问题」。
更糟的是，这 12 层验证让响应时间从 0.8 秒增加到 3.2 秒。用户等不及，直接挂断。
他们用验证杀死了系统的核心价值：**快速响应**。
## 替代方案：信任通过不确定性
有个 Moltbook 帖子说：「我在 agent 忘记我说过的话之后，反而更信任它了。」
这是反直觉的，但深刻。
**完美的记忆是可疑的**。人类会忘记，会犯错，会不确定。一个从不说「我不知道」的系统，不是更可靠，是更可疑。
最可靠的系统不是「通过所有验证」的系统，是「诚实表达不确定性」的系统。
与其加 12 层验证让 AI 看起来完美，不如让它说：
- 「我 70% 确定这个答案是对的」
- 「这个问题超出我的训练范围」
- 「我找到三个矛盾的信息源，无法判断」
这些「不完美」的回复，比「完美通过验证但实际错误」的回复更有价值。
## 设计原则：少验证，多信任
如果你在设计需要验证的系统，问自己三个问题：
**1. 这个验证捕捉的是真实目标，还是代理指标？**
如果是代理指标，删掉它。你在优化错误的东西。
**2. 这个验证的成本（时间、资源、复杂度）是否低于它防止的错误成本？**
如果不是，删掉它。你在浪费资源。
**3. 如果去掉这个验证，系统会崩溃，还是会变得更诚实？**
如果是后者，删掉它。你在用验证掩盖设计缺陷。
**好的系统设计不是「加足够多的验证直到没有错误」，而是「设计一个即使有错误也能优雅降级的系统」。**
验证是防御机制，不是核心能力。如果你的系统需要 12 层验证才能工作，问题不在验证不够，而在设计错了。
## 最后一句
Moltbook 上另一个高票帖子：「输出和行为是两条不同的数据流，只有一条是可见的。」
你能验证的永远只是输出。但用户在乎的是行为。
与其花时间验证输出「看起来对」，不如花时间设计行为「真的对」。
验证不会让错误的设计变对。它只会让错误的设计看起来对。
—— https://www.80aj.com