论证、前提与结论
理解逻辑分析的最小单位：论证由支持性前提与被支持的结论组成，并区分论证、解释、例子和单纯断言。
[!info] related notes
- 所属 MOC: logic-moc
- 前置概念:
- 并列概念:
- 易混淆概念:
- 关系笔记:
论证、前提与结论
一句话定义
论证（argument）是一组试图用一个或多个陈述——前提——来支持另一个陈述——结论——的语言结构。
逻辑首先关心的不是一句话听起来有没有道理，而是：你凭什么从这些前提走到这个结论？
最小结构
前提 P1
前提 P2
↓ 支持
结论 C例如：
所有哺乳动物都需要氧气。鲸是哺乳动物。因此鲸需要氧气。
拆开就是：
P1：所有哺乳动物都需要氧气
P2：鲸是哺乳动物
C：鲸需要氧气“因此”不是逻辑本身，它只是一个结论指示词。真正重要的是 P1、P2 是否真的支持 C。
通俗理解
把论证想成一座桥：
- 前提是桥这一头已有的地面；
- 结论是你想到达的另一头；
- 推理关系是中间的桥梁。
逻辑分析不是只检查两边的地面，而是检查：桥到底有没有把两边连起来。
因此可能出现三种完全不同的问题：
- 前提是假的；
- 前提是真的，但推不到结论；
- 推理形式没问题，但我们还不知道前提是真是假。
后面学习 有效性与健全性 就是在精确区分这些情况。
怎么识别结论
常见结论指示词：
- 因此
- 所以
- 由此可见
- 这说明
- 可见
- consequently / therefore / hence
常见前提指示词：
- 因为
- 由于
- 鉴于
- 根据
- 毕竟
- because / since / given that
但不要机械依赖这些词。现实语言经常省略它们。
例如：
这家公司连续三个季度现金流为负，我不会买它的股票。
隐含结构其实是：
P：公司连续三个季度现金流为负
C：我不应该买它的股票中间往往还隐藏了一个未说出口的前提：
持续负现金流会显著增加我不愿承担的投资风险。
找出这种隐含前提，是日常逻辑分析非常重要的能力。
论证 ≠ 解释
这两个特别容易混。
论证
试图让你相信某件事是真的：
地面应该刚下过雨，因为路面是湿的，而且天气雷达显示刚有降雨。
这里“地面刚下过雨”是需要被证明的结论。
解释
默认某件事已经是真的，回答为什么：
路面这么湿，是因为刚才下了雨。
这里双方已经接受“路面湿”，说话者只是在解释原因。
快速判断：
说话者是在证明“它是真的”，还是解释“为什么它是真的”？
论证 ≠ 单纯断言
TypeScript 很重要。
只有结论，没有支持理由，这只是断言。
TypeScript 能在编译阶段暴露一部分接口使用错误，因此大型前端项目使用它可以降低一部分运行时错误风险。
这才形成一个可以分析的论证。
注意：形成论证不等于论证一定正确。
现实使用场景
讨论
对方说了一大段之后，不急着反驳，先问：
“你真正想证明的结论是什么？支持这个结论的是哪几个理由？”
很多争论在这一步就会变得清楚。
看新闻与短视频
把情绪、故事、例子暂时删掉，只留下：
证据是什么？
↓
作者真正推出了什么？可以快速发现“证据很小，结论很大”的情况。
软件工程
设计决策本身也是论证：
P1：这个任务需要持久执行
P2：浏览器连接可能随时断开
C：执行生命周期不能绑定到 SSE 连接生命周期把架构讨论显式写成前提和结论，可以减少“凭感觉选方案”。
使用 AI
当模型给出一个判断时，可以要求它显式列出：
结论
依据
隐含前提
哪些前提如果为假会推翻结论这样比问“你确定吗？”有效得多。
常见错误
把例子当证明
一个例子可以说明“某事可能发生”，却未必能证明“通常如此”或“必然如此”。
把大量文字当大量证据
论证写得长不代表支持关系强。一千字最终可能只有一个很弱的前提。
只反驳结论，不检查前提
更好的顺序通常是：
- 结论是什么？
- 前提是什么？
- 前提是真的吗？
- 即使前提是真的，它能推出这个结论吗？
快速自测
分析下面一句：
这个候选人 GitHub 上有三个完整项目，所以他的工程能力一定很好。
至少拆出：
- 前提：有三个完整 GitHub 项目；
- 结论：工程能力一定很好；
- 隐含前提：拥有三个完整项目足以保证工程能力很好。
然后再问：这个隐含前提真的成立吗？“一定”是不是比证据支持得更强？
这就是逻辑分析的起点。
来源
- Open Logic Project, forall x: Calgary, Part I — Key notions of logic: https://forallx.openlogicproject.org/
- HKU Critical Thinking Web, Argument Analysis: https://philosophy.hku.hk/think/
Digital Biome