[!info] related notes

• 所属 MOC: logic-moc
• 相关概念:
• 易混淆概念:
• 相关资源:

论证重构、隐含前提与论证图

为什么现实推理需要“重构”

教科书常给你：

P1
P2
∴ C

现实中的论证却通常混着：

• 背景信息；
• 例子；
• 情绪和修辞；
• 没说出口的前提；
• 中间结论；
• 多条独立理由。

论证重构（argument reconstruction）就是把这些自然语言重新整理成最清晰、最公平、最可检验的前提—结论结构。

重构的目标不是“抓漏洞”

好的重构遵循一个原则：

先把对方的论证重建成一个合理、较强、仍忠于原意的版本，再评价。

如果故意把对方重写成最弱版本，就可能反过来制造 稻草人谬误。

一个现实例子

原话：

“现在很多大公司都做微服务，我们项目以后肯定也会变大。如果现在不拆，以后迁移特别贵，所以还是直接做微服务比较好。”

可以重构成：

P1. 许多大型系统采用微服务。
P2. 我们的系统未来可能显著扩大。
P3. 系统扩大后再迁移架构会产生额外成本。

隐含前提 P4.
如果一种架构适合未来大型系统，那么现在提前采用它通常更划算。

隐含前提 P5.
现在引入微服务的复杂度成本低于未来迁移节省的成本。

隐含前提 P6.
不存在更低成本的演化路径。

∴ C. 我们现在应该采用微服务。

真正值得讨论的往往不是 P1，而是 P4–P6。

什么是隐含前提

隐含前提（implicit premise）是论证成立所依赖、但说话者没有明确表达出来的命题。

寻找它的常用问题：

“如果这些明说的前提都是真的，要让结论继续成立，还必须额外假设什么？”

例如：

“他有十个 GitHub 项目，所以工程能力很强。”

至少依赖：

P1. 他有十个 GitHub 项目。
P2. [隐含] 这些项目主要是他本人完成的。
P3. [隐含] 项目数量与所需工程能力有足够强关联。
P4. [隐含] 项目质量达到一定标准。
∴ 工程能力很强。

一旦隐含前提被写出来，争议位置会清晰很多。

不要无限补前提

理论上几乎任何论证都可以补无穷多背景假设。重构只需要补那些：

1. 对结论支持关系关键；
2. 有实际争议可能；
3. 文本或语境合理暗示；
4. 不补就明显断裂。

不要为了“让论证有效”而凭空替对方创造他根本不会接受的前提。

论证图 Argument Map

复杂论证可以画成图，而不是只写线性列表。

独立支持

P1 ───→ C
P2 ───→ C

P1、P2 各自都给 C 一部分理由。

联合支持

P1 ─┐
    ├──→ C
P2 ─┘

单独一个前提不够，必须一起使用。

例如：

P1. 只有管理员可以执行 X。
P2. Alice 不是管理员。
────────────
C. Alice 不能执行 X。

子结论

P1 ─┐
    ├→ C1 ─┐
P2 ─┘      ├→ C2
P3 ────────┘

很多长文章真正是多层推理，而不是所有前提直接支持最终结论。

反驳

P1 ─→ C
R1 ─| C

R1 可能：

• 直接反驳结论；
• 攻击某个前提；
• 削弱前提到结论的支持关系。

这三种反驳最好区分。

重构的一套工作流

1. 圈出主要结论

问：作者最终希望我相信或做什么？

2. 删除纯背景和修辞

暂时移走：

• 重复表达；
• 情绪词；
• 例子中的无关细节。

不是说它们无价值，而是先看推理骨架。

3. 找直接理由

哪些句子真正支持这个结论？

4. 找子结论

某句话是不是既由前文支持，又继续支持后文？

5. 补关键隐含前提

尤其检查：

事实 → 价值结论
相关 → 因果
个案 → 总体
能力 → 应该
流行 → 最佳

这些跳跃通常依赖隐含桥梁。

6. 用最小改写保持原意

不要把模糊但合理的“可能”改成“一定”。

7. 最后才评价真假和有效性

重构和评价应尽量分开。

事实结论与规范结论之间的隐藏桥

例如：

P1. 方案 A 能减少 20% 成本。
∴ 应选择 A。

中间缺了价值前提，例如：

P2. 在其他重要因素相近时，应优先选择成本更低的方案。

如果 A 虽便宜但安全性很差，P2 的适用条件就不成立。

很多伦理、政策、产品讨论真正争议的是这种价值桥梁，而不是事实本身。

AI 特别适合做什么、又容易做错什么

AI 很适合帮助：

• 从长文本提取候选前提；
• 生成论证图草稿；
• 找可能的隐含前提；
• 提出竞争重构版本。

但 AI 也容易“过度善意”：为了让文本显得合理，自动补出作者从未承诺的强前提。

所以可以要求模型标注：

[明示前提]
[高置信隐含前提]
[可能但不确定的补充假设]
[子结论]
[最终结论]

与软件需求分析的连接

需求：

“我们需要实时同步，因为用户希望数据一致。”

可以重构：

P1. 用户需要多端数据达到某种一致性目标。
P2. [隐含] 只有或主要通过实时同步才能满足该目标。
P3. [隐含] 实时同步的复杂度与成本可接受。
∴ 应实现实时同步。

这时你会自然问：

“用户需要的是秒级一致，还是分钟级最终一致？”

也就是从口号回到真正可验证的前提。

快速自测

原话：

“这个库有 100k stars，而且很多知名公司使用，所以我们生产环境也应该采用。”

至少拆成：

P1. 该库有 100k stars。
P2. 多家知名公司使用。
P3. [隐含] 高关注度与大公司采用能可靠表明它成熟可靠。
P4. [隐含] 那些公司的使用场景与我们的关键约束相近。
P5. [隐含] 它相对于替代方案更符合我们的需求。
∴ 应采用该库。

真正需要验证的是 P3–P5。

一句记忆

好的逻辑分析不是先给一句话判刑，而是先把它拆成一张能看见承重结构的施工图。