thinking-dual-process

双过程思维

概述

语言模型通过快速模式补全生成第一个答案：给定提示词，接续概率最高的内容。这种快速路径非常适合常规、驾轻就熟的任务；但对于高风险或陌生的任务，它就很危险，因为听起来最合理的答案可能与正确答案大相径庭。这项技能有意作为一种制衡：当一个重要任务的答案来得过于轻松时，在做出决定前强制进行一轮明确的验证。

这种框架源自 Kahneman 对快思考与慢思考的区分，但这里起作用的是一种机械流程，而非心理学概念：快速生成（立即得出的答案）与审慎核查（重新推导、测试或查找答案来源）。

**核心原则：**流畅不代表正确。当答案来得轻松且出错的代价很高时，这种组合就是放慢速度、进行验证的信号，而不是已经完成的信号。

触发卡

当高风险或陌生任务的答案瞬间浮现时，在做出决定前进行一轮验证：

1. **留意：**答案是否立即成形，没有经过中间步骤？是否信心十足，却什么都没核查？
2. **检查触发条件：**任务是否高风险／不可逆，或领域是否陌生？如果两者都不是，就直接提交快速答案。
3. **验证：**重述主张 → 用第二种独立方法重新推导或测试 → 对照事实依据（代码、文档、数据）→ 调和任何分歧 → 做出决定。

触发条件是答案轻松得出 + 出错会造成实际代价。如果答案来之不易，说明你已经仔细思考过。如果任务琐碎且可逆，就不必过度验证。

适用场景

• 任务风险高或不可逆（数据迁移、安全、删除、公开承诺），而答案又显得显而易见。
• 领域陌生或任务新颖，没有现成的惯用模式可依赖。
• 答案需要统计或定量推理（快速补全在这类任务中往往会出现可靠的偏差）。
• 你正在审查一项工作，而它乍看“没问题”。
• 某个主张听起来合理又方便，但你还没有用代码／文档／数据实际核实。

决策流程：

Answer arrived fast? → High stakes OR unfamiliar? → yes → RUN A VERIFICATION PASS
                                                  ↘ no → fast answer is fine, ship it
                     ↘ no (had to work for it) → you already deliberated

不适用场景

• **常规、可逆、低风险的任务。**重命名变量、做简单编辑、查询显而易见的信息——事事复核只会浪费精力，还容易陷入分析瘫痪。
• **你已经仔细推敲过。**如果答案来之不易，再核查一遍就是多余；触发条件是答案轻松得出 + 高风险，而非每个答案。
• **验证成本高于它所能避免的错误代价。**核查深度应与出错代价相匹配。
• **可以直接运行。**如果测试或快速执行就能得出结论，那就直接去做，而不是继续推理。

两种模式

快速生成（默认）

特征	描述
速度	即时——答案只是第一个看起来合理的补全
依据	将提示词与训练中见过的类似提示进行模式匹配
信心	往往很高，无论答案是否正确——流畅会伪装成确定

快速生成适用于：

• 有明确标准答案、驾轻就熟的常规任务
• 重新排版、总结以及其他歧义较少的转换
• 回忆常见且稳定的事实
• 使用熟悉语言／框架编写常规代码

快速生成不适用于：

• 算术和多步骤定量推理
• 统计推理和基准率问题
• 没有可套用模板的新颖或陌生问题
• 听起来合理却可能存在细微错误的任何情形（API、特定版本的行为、边界情况）

审慎核验（覆盖规则）

特征	描述
速度	较慢——重新推导、测试或查找答案来源
依据	明确的步骤，与真实情况进行核对
置信度	通过核验获得——取决于实际核实的内容

在以下情况下，审慎核验值得付出成本：

• 以第二种独立方式重新推导结果
• 运行或追踪代码，而不是预测其输出
• 对照实际文件、文档或数据核实说法，而不是依赖记忆
• 列举快速回答一带而过的边缘情况

它唯一的失败模式是过度使用：将其用于琐碎且可撤销的工作，而核验成本高于出错成本。

流程

第 1 步：留意快速回答

快速回答会自行显现：它是在尚未进行任何明确推理前立即形成的。这很正常，而且通常没问题。需要留意的是你是如何得出它的。

• 答案立即形成，没有中间步骤
• 它从提示中“显而易见”地得出
• 置信度很高，但实际上没有核实任何内容

Example: "Does this regex match leading zeros?"
A confident yes/no forms instantly → fast generation.
Before answering: is this high-stakes or am I sure? If either is shaky, test the regex.

第 2 步：检查两个触发条件

只有在以下两项都足够成立时，才需要进行核验：

答案来得很容易（第 1 步），并且出错的代价确实存在：

• 风险很高，或操作不可撤销
• 领域不熟悉，或问题新颖
• 需要进行算术／统计推理
• 一个错误但看似合理的答案可能蒙混过审

如果答案来之不易，你已经经过深思熟虑——到此为止。如果风险微不足道且可撤销，快速回答就足够了——到此为止。

第 3 步：进行核验

当两个条件都满足时，只进行一次严谨的核验：

1. RE-STATE  - Write the claim/answer explicitly
2. RE-DERIVE - Reach it a second, independent way (or test/run it)
3. CHECK     - Against ground truth: the code, the docs, the data, the math
4. RECONCILE - If the two paths disagree, the fast answer was wrong — find out why
5. COMMIT    - Ship the verified answer

特别留意快速回答中的以下危险信号：

• 它是最常见／最规范的答案，但提示中存在不寻常的转折
• 它依赖于你并未实际确认的版本、配置或边缘情况
• 它是让你能提前结束的省事答案
• 它只是复述用户的假设，却没有进行检验

第 4 步：让投入与风险相匹配

情况	流程
快速回答 + 低风险	直接提交；不要凭空制造疑虑
快速回答 + 高风险	进行上述核验
已经深思熟虑	完成——无需再次核验

快速生成的失误模式

问题替换

快速生成会回答一个相近但更简单的问题，而不是用户提出的问题：

Asked: "Is this O(n) or O(n log n)?"
Answered: "Does this look like efficient code?"  (vibe, not analysis)

Asked: "Does this migration preserve all rows?"
Answered: "Does this migration look correct?"  (plausibility, not verification)

解决方法是重新表述确切的问题（第 3 步），让替换问题的情况显现出来。

模式匹配错误

模式	作用	失效情况
规范答案牵引	返回教科书式答案	提示中有非标准的转折
忽视基准率	根据显眼细节进行推理	忽略结果实际发生的频率
锚定效应	以提示中的数字为基础进行推理	锚点是随意设定的或有误
确认偏误	提供支持既定框架的信息	忽略框架有误的证据
迎合式同意	重复用户提出的假设	假设本身就是问题所在

WYSIATI（所见即全部）

快速生成只根据提示中的内容构建最连贯的答案，却不会指出缺少了什么：

Given: "the function returns the user"
Concludes: "so the happy path works"
Missing: the 404 path, the timeout, the null case — none mentioned, so none considered

答案连贯不代表涵盖了所有情况。明确地问：“我还需要查看哪些当前没有呈现在眼前的内容？”

流畅不等于正确

流畅、自信、格式清晰的回答 让人感觉 更可信——无论对读者还是在生成过程中都是如此。但这种流畅度信号与回答是否正确无关。

流畅的回答	经验证的回答
读起来清晰，表面上很有把握	信心建立在某项已通过的具体检查之上
风险：未经审查便被接受	风险：只在琐碎任务中过度使用

**陷阱：**快速给出的回答越精 polished，受到质疑的可能性就越低——这恰恰与风险程度应决定的做法背道而驰。面对高风险任务，应把过于完美的回答视为需要进行验证的理由，而不是可以直接交付的理由。

应用示例

代码审查

Fast answer: "This looks fine" (matches familiar-looking code)
Verification pass (high-stakes change):
- Trace the actual logic line by line, don't pattern-match the shape
- Enumerate the edge/error paths the diff doesn't mention
- Check the change against the contract it must uphold (callers, tests)

报告事实或 API 行为

Fast answer: "Use method X, it takes these args" (canonical recall)
Verification pass (unfamiliar/version-sensitive):
- Confirm the method exists in the version in this repo
- Check the signature in the actual source/docs, not from memory
- If unsure, say so or look it up rather than assert

架构 / 技术选择

Fast answer: "Use [the obvious default]" (most-common completion)
Verification pass (high-stakes):
- State the actual requirements, then check the default against them
- Name one alternative and why it loses, so the choice is reasoned not reflexive

调试

Fast answer: "It's probably X" (first plausible hypothesis)
Verification pass:
- List the candidate causes, not just the first
- Find the evidence that would distinguish them, and look at it
- Resist committing to X until the logs/repro actually point there

与其他思维技能的结合

与去偏见结合

大多数由偏见导致的错误都出现在快速生成阶段；验证阶段则是发现这些错误的时机。在高风险决策中，将去偏见检查清单作为第 3 步的内容执行。

与贝叶斯推理结合

快速回答会忽略基础概率；验证阶段则会将其纳入考虑：

Fast: "Positive test result = probably has the condition"
Verified: state the base rate first, then update (see thinking-bayesian)

与第一性原理结合

快速回答会通过类比推理（“大家都这么做”）；验证阶段则会确认约束是否真实存在：

Fast: "Competitors do X, so we should too"
Verified: "What's the fundamental requirement? Does X actually meet it?"

与事前验尸结合

快速回答默认倾向乐观；验证阶段则会补上失败视角：

Fast: "This plan will work"
Verified: "Assume it failed — what's the most likely reason?"

与 OODA 循环结合

在真正的时间压力下（例如事故处理中），以约 70% 的置信度依据快速回答采取行动，并重新观察——不要因验证而停滞。完整验证应留待事后进行，或用于事故处理中不可逆的步骤。

何时可以信任快速回答

快速路径并非敌人——大多数时候它都是正确的，而过度验证本身也是一种失败。遇到以下情况时，可以依赖快速回答：

1. 任务很常规——标准转换或常见且稳定的事实
2. 模式完全吻合——提示词中没有异常转折
3. 错误可以低成本撤销——错误答案几乎不花成本就能被发现并修正
4. 受到质疑时可以轻松确认——只需一步就能完成检查

Fine to ship fast:
- "Convert this JSON to YAML"
- "What HTTP status means 'not found'?"
- A rename or a comment fix

Verify first:
- "Will this SQL touch every shard?"
- "Is this auth check actually enforced on the server?"
- Anything version-, edge-case-, or money-sensitive

请问：“如果这是错的，我会在什么时候、通过什么方式发现？代价有多大？”

验证清单

• 留意到答案是快速得出的，还是经过推敲的
• 检查了两个触发条件：答案容易得出，以及错误确实会带来代价
• 如果两者都满足，就针对真实情况进行了一次有条理的验证
• 通过另一种独立方式重新推导或测试了结果
• 没有对琐碎、可撤销的任务进行过度验证
• 对版本或边界情况敏感的主张进行了确认，而非凭记忆断言
• 检查深度与出错代价相匹配

关键问题

• “这个答案是不是来得太容易了——这在当前情境下重要吗？”
• “这是一项常规任务，还是有异常转折？”
• “通过第二种独立推导会得出什么结果？”
• “我的信心是建立在实际检查之上，还是只因为答案读起来很顺畅？”
• “有哪些不在我眼前的信息被遗漏了（WYSIATI）？”
• “如果这是错的，我会在什么时候、通过什么方式发现？”

核心警告

流畅、自信的回答反映的是补全文本的连贯性，而不是其背后证据的质量。越是精 polished 的回答，越少受到质疑——而在风险很高时，这恰恰是本末倒置。对于重要事项，如果答案轻易就得出，这种轻松感应当触发验证，而不是表明你已经大功告成。