# 7类逻辑病诊断标准

> 诊断原则：每个问题必须引用原文具体语句，标注严重程度，给出修复方向。

---

## 1. 结论缺失 🔴致命

**定义**：文本通篇是信息罗列或过程描述，没有一句完整的判断句告诉读者"所以呢"。

**识别标准**：
- 全文无"因此/所以/建议/应该/总结来说"等结论性表达
- 开头是"关于XX"/"XX的情况"等主题词而非判断句
- 读者看完无法用一句话转述核心观点

**典型症状**：
- "关于Q2项目进展汇报"（这是标题不是结论）
- 通篇列举数据但不说明数据意味着什么
- 结尾是"以上是本次汇报内容"而非行动建议

**修复方法**：
1. 问自己：如果只说一句话，你要说什么？
2. 把这句话放在最前面
3. 确保它是一个完整的判断句（主语+谓语+判断）

**举例**：
- ❌ "Q2项目进展情况"
- ✅ "Q2项目将延期2周，需要增加2名开发人员才能在7月底前交付"

---

## 2. 以下不统上 🔴致命

**定义**：子论点无法支撑父论点，下一层的内容推导不出上一层的结论。

**识别标准**：
- 删掉子论点后，父论点是否仍然成立？（如果成立→子论点是凑数的）
- 只看子论点，能否推出父论点？（如果不能→逻辑断裂）
- 子论点之间是否回答了父论点隐含的"为什么/怎么做"？

**典型症状**：
- 父论点："我们应该进入X市场" → 子论点之一："团队氛围好"（无关）
- 父论点："项目有风险" → 子论点："同行也在做类似项目"（不构成风险）

**修复方法**：
1. 对每个子论点做"所以呢"测试：子论点→所以→能到父论点吗？
2. 不能到达的，要么换到正确的父论点下，要么删除
3. 补充真正能支撑的子论点

**举例**：
- ❌ "应该加薪"→子论点"我经常加班"（加班≠应该加薪）
- ✅ "应该加薪"→子论点"我的产出超过同级别同事30%且薪资低于市场中位数"

---

## 3. 分类交叉 🟡中度

**定义**：同一层级的并列要点之间存在内容重叠，不满足MECE的"相互独立"原则。

**识别标准**：
- 两个并列项是否有重合的覆盖范围？
- 某个案例是否可以同时归入两个分类？
- 换一种分类维度后重叠是否消失？

**典型症状**：
- 产品问题分为"用户体验差"和"界面不美观"（界面是体验的子集）
- 客户分为"年轻人"和"互联网从业者"（有大量重叠）

**修复方法**：
1. 统一分类维度（只按一个标准切分）
2. 合并重叠项为一个
3. 将子集归入父集下一层

---

## 4. 逻辑跳跃 🟡中度

**定义**：推理链条中跳过了关键中间步骤，从A直接跳到C，缺少B。

**识别标准**：
- 读者需要自行脑补才能理解上下文的连接
- 两段话之间没有因果/递进/转折词连接
- "因为...所以..."中间缺少中间推理

**典型症状**：
- "竞品在做X → 所以我们也必须做X"（缺少：竞品做X获得了什么收益/不做会失去什么）
- "用户留存下降 → 建议重构产品"（缺少：留存下降的原因是什么→原因是否能通过重构解决）

**修复方法**：
1. 在两个节点之间插入缺失的推理步骤
2. 用"之所以A→B，是因为..."补充连接逻辑
3. 如果中间步骤太多，考虑拆分为两个独立论证

---

## 5. MECE不全 🟡中度

**定义**：分类遗漏了重要维度，不满足"完全穷尽"原则，存在盲区。

**识别标准**：
- 用"还有没有其他情况？"测试
- 所有分类加起来是否等于全集？
- 是否存在"其他"分类过于庞大的情况？

**典型症状**：
- 分析营收下降只看了需求侧，没看供给侧
- 人员规划只考虑了招聘，没考虑现有人员能力提升
- 风险分析只列了外部风险，没列内部风险

**修复方法**：
1. 用经典框架检查完整性（如：内/外、供/需、短/中/长期）
2. 补充遗漏维度
3. 确认所有分类加总=全集

---

## 6. 演绎断链 🟢轻微

**定义**：三段论式推理中，大前提或小前提缺失，或结论不严格遵循前提。

**识别标准**：
- 能否还原出完整的"大前提+小前提→结论"结构？
- 大前提是否是普遍接受的/已论证的？
- 小前提是否属于大前提的范畴？

**典型症状**：
- "他是产品经理，所以沟通能力强"（隐含大前提：所有产品经理沟通能力强——未必成立）
- "市场在增长，所以我们能盈利"（市场增长≠个体盈利）

**修复方法**：
1. 补充完整三段论
2. 检验大前提是否成立（如不成立，整个推理要重来）
3. 标注"此处假设XX为前提"

---

## 7. 事实判断混淆 🟢轻微

**定义**：将主观判断当作客观事实陈述，或将未经验证的假设当作已知条件。

**识别标准**：
- 句子是否可被客观验证（可验证=事实，不可验证=判断）？
- 是否使用了"很好/很差/最佳/唯一"等主观评价词但未标注依据？
- 是否将预测/推测表述为确定性事实？

**典型症状**：
- "用户不喜欢这个功能"（事实还是判断？有数据支撑吗？）
- "这是最优方案"（相比什么？评估标准是什么？）
- "市场规模将达到100亿"（预测还是已知？数据来源？）

**修复方法**：
1. 事实：标注数据来源（"据XX报告/据用户调研..."）
2. 判断：明确标注为判断（"我们认为/初步判断..."）
3. 预测：注明假设条件（"假设增速保持15%，则..."）

---

## 诊断报告模板

```markdown
## 🔍 逻辑诊断报告

**整体评级**：[🔴严重 / 🟡需改进 / 🟢基本合格]
**主要问题**：[一句话概括最大的结构性问题]

### 问题清单

| # | 类型 | 严重度 | 原文引用 | 问题说明 | 修复建议 |
|---|------|--------|---------|---------|---------|
| 1 | [病名] | [🔴/🟡/🟢] | "[具体原文]" | [什么问题] | [怎么修] |
| 2 | ... | ... | ... | ... | ... |

### 结构性优点
（必须写：哪些地方逻辑是清晰的）

### 核心诊断
（2-3句话：最关键的问题在哪，修复优先级是什么）
```

---

## 严重程度与优先级

| 级别 | 处理方式 |
|------|---------|
| 🔴致命 | 必须修复，否则读者无法理解你的核心观点 |
| 🟡中度 | 建议修复，会影响说服力但不致于完全不可读 |
| 🟢轻微 | 可以优化，修复后论证更严谨 |

**诊断原则**：
- 一个文本中🔴问题不超过3个（超过说明需要完全重写而非修补）
- 先修🔴再修🟡最后修🟢
- 不是所有文本都需要诊断出问题——逻辑清晰的部分要明确标注✅
