02 论证结构:前提、推理与结论
TL;DR:论证由三部分组成:前提(基于什么假设和事实)、推理(从前提到结论的路径)、结论(主张什么)。检验论证不是判断"结论对不对",而是判断前提是否真实、推理是否有效、结论是否从前提出。最常见的失效是"相关当因果"(推理无效)和"前提藏在脑里不检验"(前提未识别)。
概念解释
论证的三个组成部分
| 部分 | 回答什么 | 检验标准 |
|---|---|---|
| 前提 | 基于什么事实和假设? | 是否真实、是否有证据 |
| 推理 | 从前提到结论的路径? | 是否合逻辑、有无跳跃 |
| 结论 | 主张什么? | 是否从前提出、有无超出前提 |
两种推理方式
| 方式 | 逻辑 | 工程例子 | 风险 |
|---|---|---|---|
| 演绎 | 如果前提为真,结论必然为真 | "所有配置发布必须过 schema 校验;这次是配置发布;所以必须过校验" | 前提不为真则结论也不为真 |
| 归纳 | 从有限观察推出一般规律 | "三次试点都降低了延迟,所以全量也会降低" | 观察样本可能不代表全部 |
关键:工程实践中的论证大多数是归纳而非演绎——从有限数据推出一般结论。归纳推理的结论不是"必然为真",而是"可能为真"——这正好需要因果验证和实验来确认。
推理无效的常见模式
| 无效推理 | 例子 | 为什么无效 |
|---|---|---|
| 相关当因果 | "部署频率高的团队失败率低" | 可能是"工程成熟度"同时驱动两者 |
| 事后归因 | "上线后指标变好了,所以是上线导致的" | 时间先后 ≠ 因果 |
| 幸存者偏差 | "成功团队都做了X" | 没看失败的团队是否也做了X |
| 滑坡谬误 | "允许Agent会最终导致人被替代" | 连锁推断缺乏中间证据 |
目录
| 章节 | 说明 |
|---|---|
| 论证拆解模板 | 可复用的模板 |
| 推理有效性的检查 | 常见无效模式 |
| 软件工程示例 | 拆解一个技术论证 |
| 适用边界与误用 | 论证拆解不是什么 |
论证拆解模板
## 论证拆解
### 结论
{一句话主张}
### 前提
1. {前提1} — 证据:{来源}
2. {前提2} — 证据:{来源}
### 推理方式
{演绎 / 归纳}
### 推理路径
{从前提到结论的逻辑链}
### 检查
- 前提是否真实?{是/否/未验证}
- 推理是否有效?{是/否}
- 结论是否超出前提?{是/否}
### 替代解释
{如果不接受这个结论,还有什么解释}
推理有效性的检查
| 检查项 | 问什么 | 命中信号 |
|---|---|---|
| 相关≠因果 | 两个变量一起变,是否有第三个因素同时驱动? | 有混杂因素 |
| 时序 | 原因是否在结果之前? | 时序不清 |
| 反事实 | 没有X,Y会不会也变? | 缺少对照 |
| 样本代表性 | 观察的样本能否代表整体? | 样本偏差 |
核心操作:对每个归纳推理,问"有没有替代解释?" 如果有且无法排除,结论的置信度应降低,需交给 实验设计:AB 测试、灰度与消融实验 来验证。
软件工程示例
主张:"引入 Agent 后代码提交数增加了 30%,说明 Agent 提升了开发效率。"
| 部分 | 内容 | 检查 |
|---|---|---|
| 结论 | Agent 提升了开发效率 | ⚠️ "提交数增加"≠"效率提升" |
| 前提1 | 提交数增加 30% | 需验证数据来源和口径 |
| 前提2 | 提交数代理效率 | ❌ 提交数可能拆小了(Goodhart) |
| 推理 | 提交数↑ → 效率↑ | ❌ 相关当因果 + 代理指标失真 |
| 替代解释 | 提交拆小、新增成员、需求变更 | 未排除 |
结果:论证在推理层和前提2层失效。需要用 因果图与混杂:为什么控制更多变量也会出错 画出混杂,再用实验验证。
适用边界与误用
- 拆解不替代验证:拆解定位了薄弱点,但结论仍需因果分析或实验确认。
- 不需要每个主张都拆解:低风险主张快速判断即可。
- "替代解释"不是抬杠:它是归纳推理的必要检查——不是否定结论,而是确定置信度。
- 演绎推理不需要实验:如果前提为真且推理有效,演绎结论是确定性的——但工程中大多数推理是归纳。
关联笔记
- 批判性思维总览:从主张到可检验论证(三层拆解和五条标准)
- 因果图与混杂:为什么控制更多变量也会出错(推理中的因果陷阱)
- 认知偏差:系统性错误的模式(前提和推理中的系统性偏差)
- 指标与决策复盘:避免 Goodhart 式自欺(代理指标失真)
参考资料
评论 (0)