跳转至

03. 论证与结构：让输出可审计

很多 Prompt 失败，不是因为模型“笨”，而是因为你只管要结论，却没管要“过程证明”。你拿到了一个结论，但你看不到支撑它的逻辑链路——就像给你一个没有电路图的黑盒子，一旦短路，你根本不知道是哪根线搭错了。

本章要把“逻辑显性化”写进 Prompt 协议。我们要强制模型交付：结论、证据、依据、前提、失效条件。这就是把“黑盒”变成“白盒”的过程。

章节插图占位：论证结构像电路图

你卡在哪？这章救什么？

  • 卡点：模型一本正经胡说八道。它给出的方案看似完美，但落地时发现前提条件根本不存在（比如假设了无限预算），或者逻辑上有巨大的跳跃。
  • 解药：不再接受单纯的“文本回答”，强制要求输出“结构化论证表格”。
  • 交付物：
    1. 最小论证单元 (C-E-R-F)：把每个观点锁死在证据上。
    2. 前提表：把“默认假设”挖出来暴晒。
    3. 反驳预案：强制模型左手搏右手，提前暴露弱点。
    4. 可审计 Prompt 模板：直接能跑的 CLI 命令。

核心工具：最小论证单元 C-E-R-F

让模型输出“可审计”内容的最小原子结构是 C-E-R-F。不要让它写作文，让它填空：

  1. Claim (结论)：一句话命题，必须是可证伪的。
  2. Evidence (证据)：直接引用输入材料中的原话、数据行或代码片段。禁止概括，要原文。
  3. Reason (依据)：为什么这个证据能支持这个结论？不要长篇大论，要 checklist。
  4. Failure (失效条件)：在什么情况下这个结论会崩塌？这一步是防“伪正确”的防火墙。

实战：技术决策审计 Prompt

这是本章的核心资产。把这段 Prompt 存下来，专门用于让模型做技术选型、方案评估或逻辑推演。

命令行执行示例

直接在终端运行，把输出存为 Markdown 文件进行代码 Review 级别的审查：

mkdir -p out
cat <<'PROMPT' | <LLM_CLI> > out/audit_report.md
你是一个偏执的技术审计师。请基于输入材料，输出一份严格的论证结构报告。

硬性约束：
1) 必须只输出 Markdown 表格和清单。不要写前言，不要写总结。
2) 证据必须引用原文。如果材料没提，直接写‘缺证据’，禁止脑补常识。
3) 禁止使用模糊词（可能、大概、应该）。不确定就标‘待验证’。

请按以下顺序输出 4 个部分：

### 1. 前提大起底 (Premise Table)
列出所有隐含假设（资源、权限、环境、时间）。
| ID | 前提描述 | 依据（材料原话） | 崩塌后果（高/中/低） |
| :--- | :--- | :--- | :--- |

### 2. 论证骨架 (C-E-R-F Structure)
| ID | 子结论 (Claim) | 证据 (Evidence) | 依据 (Reason) | 失效条件 (Failure) |
| :--- | :--- | :--- | :--- | :--- |

### 3. 自我反驳 (Rebuttal Plan)
攻击你自己的结论，找出最脆弱的点。
| Risk ID | 攻击点 | 击穿哪个结论 | 补救措施/熔断阈值 |
| :--- | :--- | :--- | :--- |

### 4. 待验证清单
- <具体的行动项 1>
- <具体的行动项 2>

输入材料：
<在此处粘贴你的技术文档、会议纪要或数据片段>
PROMPT

进阶技巧：从证据矩阵到论证链

不要一上来就写论证。按照以下流水线操作，成功率翻倍：

  1. 前置步骤：先用 02-facts.md 里的方法清洗出证据矩阵。垃圾进，垃圾出；没有干净的证据，不要做论证。
  2. 拆解结论：把你的大目标拆成一个个小的子结论（Nodes）。
  3. 绑定证据：每个 Node 必须至少挂钩一条 Evidence。挂不上的，要么删掉，要么标为“假设”。
  4. 压力测试：对每个 Node 问“什么情况下它是错的？”，填入失效条件。

图示化：论证链路图

当逻辑太复杂时，你需要一张图。不要让模型直接画图（它画不好），让它生成描述，或者你自己用下面的 Prompt 生成一张底图，然后把文字填进去。

图片生成 Prompt 配置块

image_prompt:
technical schematic blueprint, abstract logic flow diagram, nodes and connectors, high contrast white lines on dark blue background, circuit board aesthetic, minimal geometric shapes representing arguments and evidence, clean lines, engineering precision, data flow visualization

negative_prompt:
text, letters, numbers, watermark, signature, handwriting, messy, blurry, low resolution, organic shapes, people, faces, 3d render, shadows, gradients

params:
aspect_ratio=16:9, quality=high

避坑指南：你也可能被骗

有了结构不代表就万事大吉。模型是顺着你的话说的，它极擅长“伪造逻辑”。请对照下表进行人工审查：

1. 强行因果 (Correlation is not Causation)

  • 症状：模型说“因为 A 发生了，所以 B 变好了”，但材料里 A 和 B 只是同时出现。
  • 修复：在 Prompt 里加一条禁令——“没有明确机制描述或对照组证据，禁止使用‘因为/导致’，只能用‘伴随/相关’。”
  • 审查：看到“导致”两个字，立刻去找对应的“机制证据”。找不到就打回。

2. 前提隐形 (Hidden Premises)

  • 症状：方案看着特顺，一执行就废。因为它默认你显卡无限、带宽免费、用户全是专家。
  • 修复：前提表（Premise Table）必须是必填项。如果模型留白，就是不合格。
  • 审查：重点看“资源”、“权限”、“时间”这三栏有没有被填满。

3. 概念漂移 (Drifting Definitions)

  • 症状：上一段的“用户”指注册用户，下一段的“用户”变成了日活用户。结论自然是错的。
  • 修复：要求先输出“术语定义表”。
  • 审查：抽查 3 个节点，看同一个名词的单位和定义是否完全一致。

论证质量自检清单

在采信模型的输出前，问自己 5 个问题：

  1. 可证伪吗？ 结论是不是个算命式的废话（如“未来可能变好”）？必须是“如果是 X 则 Y，否则 Z”。
  2. 颗粒度对吗？ 证据是定位到了具体哪一行、哪句话，还是笼统的“全文”？
  3. 常识还是证据？ 依据是来自材料，还是模型自己脑补的“公理”？脑补的统统标为“待验证”。
  4. 反驳够狠吗？ 反驳预案是不是无关痛痒？必须要求至少 2 条能把整个方案推翻的致命风险。
  5. 能回滚吗？ 触发熔断条件写清楚了吗？没有熔断机制的方案就是赌博。

下一章 04-language.md 我们将解决“怎么说人话”的问题，把这些硬核的逻辑翻译成打动人的表达。