[!info] related notes

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

反例：如何推翻全称命题与检验论证有效性

一句话定义

反例（counterexample）是一个满足待检验命题或论证相关条件，却让目标结论失败的具体可能情形。

它是逻辑中最有力的工具之一，因为很多普遍性主张只需要一个反例就能被推翻。

推翻全称命题

全称命题：

∀x P(x)

要推翻它，只需找到：

∃x ¬P(x)

例如：

所有鸟都会飞。

找到企鹅就足以说明这个全称命题为假。

关键不是企鹅“很多”，而是全称命题不允许任何例外。

检验论证有效性

一个演绎论证无效，当存在至少一个可能情形：

所有前提都真
且
结论为假

这个可能情形就是该论证形式的反例。

例如：

P → Q
Q
∴ P

取：

P = false
Q = true

则：

P → Q = true
Q = true
P = false

前提全部为真，结论却为假，因此“肯定后件”无效。

形式反例与现实反例

形式反例

只需要构造真值赋值或模型，证明逻辑形式允许失败。

现实反例

用真实世界案例推翻经验性全称命题。

例如：

“只要系统用了 TypeScript，就不会发生运行时类型错误。”

一个来自未验证 API 输入、最终导致运行时错误的真实项目案例，就足以推翻“不会发生”这种全称说法。

为什么反例特别适合检查隐含条件

很多说法看起来像全称命题，其实隐藏了限定条件。

例如：

“缓存一定会提升性能。”

反例：缓存命中率极低且维护缓存本身增加延迟。

这不一定意味着“缓存没用”，而是迫使我们把原命题修正成：

在访问模式、命中率、失效成本等满足一定条件时，缓存可能改善特定性能指标。

好的反例往往不是结束讨论，而是帮助我们找到命题真正的边界。

一个反例不能推翻什么

1. “大多数”

主张：

大多数 A 是 P。

找到一个 A 不是 P，并不能推翻“大多数”。

2. 概率性主张

使用策略 X 通常能降低错误率。

一个失败案例不能证明 X 完全无效。

3. 存在命题

要推翻：

∃x P(x)

不能只找一个 ¬P 的对象。你必须证明整个论域中没有任何 P。

这正是量词决定反驳方式的原因。

反例与“例外证明规则”

日常说“例外证明规则”经常误导。一个真正的反例对严格全称命题不是“例外但规则还成立”，而是说明原规则写得太强。

你需要：

• 放弃该规则；或
• 加入合理限定条件。

例如：

所有请求都必须认证

如果健康检查端点合法匿名访问，那么规则应该改成：

除明确列入公开端点的请求外，受保护资源请求都必须认证。

软件测试与反例思维

测试的很多本质就是主动寻找反例。

规格：

对所有合法输入，函数返回排序后的同元素数组。

测试试图找到：

某个合法输入 x
使函数输出违反规格

属性测试（property-based testing）尤其接近逻辑中的反例搜索。

反例不是“举一个故事”

有效反例必须真的满足原命题的前提条件。

例如有人说：

“所有已认证管理员都可以访问后台。”

你举：

“普通访客不能访问后台。”

这不是反例，因为普通访客根本不满足“已认证管理员”这一前件。

所以构造反例前必须准确重构原命题。

反例测试模板

面对一句强主张：

1. 它到底是全称、存在还是概率命题？
2. 它有哪些限定条件？
3. 什么情况会满足所有前提却违反结论？
4. 这个情况在逻辑上可能吗？现实中存在吗？
5. 如果找到，原命题应被否定还是弱化？

AI 使用场景

让 AI 审查方案时，可以额外要求：

“不要只说明为什么方案成立；构造至少 3 个满足当前前提但会让结论失败的反例候选，并标出它们需要违反哪个隐含假设。”

这比只让模型“检查一下有没有问题”更具区分力。

快速自测

主张：

如果服务使用 HTTPS，它就是安全的。

反例可以是：

• 服务使用 HTTPS；
• 但存在未授权 IDOR；
• 因此“整体安全”仍不成立。

这个反例同时暴露了“安全”一词可能存在的语义扩张。

一句记忆

要击穿一个全称命题，不需要比它讲更多故事；只需要找到一个它不允许存在、却确实可能存在的世界。