思维链 CoT：2026 年生产实践与评测指南

思维链（Chain of Thought，CoT）是 2022 年重要的研究成果：在若干多步推理基准上，当 Few-Shot 示例包含自然语言中间步骤时，足够强的语言模型通常比只看答案示例表现更好。后续 Zero-Shot 研究还发现，“Let’s think step by step”之类的短指令可以在部分模型和任务上引出类似行为。

但这项历史结果不是永恒的生产规则。模型和 API 已经发生变化，研究也表明，模型写出的推导可能遗漏真正影响答案的信息。2026 年更有价值的问题不是“怎样强迫模型公开想法”，而是：

对当前模型和任务，哪种推理策略能以可接受成本产生最准确、最可验证的结果？

本文会把经典 CoT、现代推理模型、Self-Consistency、搜索和外部验证严格分开。关键技术结论最后核验于 2026 年 7 月 16 日。

核心结论

• 必须区分模型内部计算、可见自然语言解释和外部可验证证据。
• 可见推导有解释价值，但不保证忠实反映模型为什么得到答案。
• 先使用直接、面向结果的 Prompt；只有评测证明有效时才增加分解或示例。
• Self-Consistency 适用于可归一化、可聚合的答案，不是通用“防幻觉”方案。
• Tree of Thoughts 是包含状态生成、评估、选择和回溯的搜索过程，不是“三位专家讨论”提示词。
• 工具、测试、引用和确定性验证器，比更长的推理文字更值得信任。
• 上线前按任务切片评测正确率、鲁棒性、校准、延迟和成本。

三种经常被混称为“推理”的东西

这个区分能阻止一种危险推断：“解释看起来很连贯，所以答案一定正确。”模型可能为错误答案生成漂亮理由，也可能通过错误步骤碰巧得到正确答案，还可能省略真正影响结论的线索。

Anthropic 2025 年的 Faithfulness 实验向选择题中插入提示。模型经常使用提示改变答案，却没有在书面推导中提到它。实验本身存在边界，但工程结论很明确：不能把生成 CoT 当作安全、鉴权或合规系统的唯一审计日志。

当用户需要解释时，应要求与证据绑定的简洁理由：

请返回：
1. 最终决定；
2. 支持决定的政策条款或原文；
3. 使用的假设；
4. 验证决定所需的计算或工具结果。

不要输出私有隐藏推理。

经典方法真正证明了什么

Few-Shot Chain-of-Thought

Wei 等人的方法给出“输入、中间推导、答案”三元组示例。在论文所评估的大模型与算术、常识、符号推理任务上，它经常优于只展示答案的示例。

这个结论带有明确条件：

• 示例必须代表真实任务；
• 推导与标签必须正确；
• 收益随模型和任务变化；
• 更多输出 Token 会增加延迟和成本；
• 示例可能让模型过拟合到不必要的解题程序。

因此，Few-Shot CoT 是需要验证的假设，而不是 Prompt 必备章节。

Zero-Shot Chain-of-Thought

Kojima 等人发现，“Let’s think step by step”能让当时的多个模型在没有示例时生成多步答案。它广为传播，是因为简单易记，不是因为它是永久有效的咒语。

对于传统指令模型，至少应比较：

基线：
解决问题，只返回整数答案。

问题分解：
把问题拆成完成任务所需的最少子问题。
检查算术，然后只返回整数答案。

第二个版本明确了有用行为和输出契约，却没有要求无限制公开内部推导。

Self-Consistency

Self-Consistency 对同一问题采样多条推理路径，再选择最一致的最终答案。原论文在特定推理基准上取得显著提升，部分实验使用了大量样本。

它更适合以下条件：

• 答案有标准化表示；
• 不同采样确实具有多样性；
• 正确答案的总概率质量高于每个错误答案；
• 准确率收益能够覆盖成倍增加的推理成本。

它不能证明多数答案就是事实。高度相关的模型错误同样会赢得投票，开放式回答也可能根本没有合理的等价规则。

可直接运行的自洽性聚合器

聚合逻辑必须确定、可观察，并明确暴露分歧。模型 API 与 SDK 变化快，因此模型调用不放进示例；下面只实现稳定的应用层职责。

from collections import Counter
from dataclasses import dataclass
from decimal import Decimal, InvalidOperation


@dataclass(frozen=True)
class Consensus:
    answer: str
    votes: int
    samples: int
    confidence: float


def normalize_numeric_answer(value: str) -> str:
    cleaned = value.strip().replace(",", "")
    try:
        number = Decimal(cleaned)
    except InvalidOperation as error:
        raise ValueError(f"not a numeric answer: {value!r}") from error
    return format(number.normalize(), "f")


def aggregate_numeric_answers(values: list[str]) -> Consensus:
    if not values:
        raise ValueError("at least one answer is required")

    normalized = [normalize_numeric_answer(value) for value in values]
    answer, votes = Counter(normalized).most_common(1)[0]
    return Consensus(
        answer=answer,
        votes=votes,
        samples=len(normalized),
        confidence=votes / len(normalized),
    )


result = aggregate_numeric_answers(["42", "42.0", "40", "42.00", "41"])
print(result)

不要把 votes / samples 标为经过校准的正确概率，它只是采样结果之间的一致程度。系统应设置最低一致率，低于阈值时升级人工、调用工具验证或拒答。Trace 可以记录 Prompt 版本、模型版本、采样参数、归一化答案与总成本，但默认不应保存包含敏感信息的长篇推导。

Tree of Thoughts 是搜索，不是角色扮演

Tree of Thoughts（ToT）把单条推理路径推广为显式搜索。原始框架有四个运行组件：

1. 定义状态和有意义的 Thought 单元；
2. 生成多个后继状态；
3. 评估部分状态；
4. 通过广度优先、深度优先等策略维护 Frontier，并执行剪枝或回溯。

“让三位专家依次讨论”可能生成多样化文本，但它没有被维护的 Frontier、状态转移、评估器和回溯，因此不能等同 ToT。混淆二者会掩盖真实调用成本和控制要求。

当早期选择可能进入死路，并且环境能提供有效状态评估器时，可以考虑搜索，例如约束谜题、有限规划、带测试的程序合成和硬约束排程。普通摘要与事实查询不需要 ToT。搜索会放大模型调用次数，也可能放大一个不可靠评估器的偏差。

按任务和模型选择策略

不同模型提供方的行为不能互换。有些模型返回 Reasoning Summary，有些使用隐藏 Reasoning Token，还有些更接近传统 Chat Model。应遵循当前模型文档，并针对每个模型版本建立评测。除非提供方公开实现，不应声称“CoT 已硬编码进模型架构”。

生产级 Prompt 模式

面向结果的 Prompt 比“请完整展示思考过程”更容易测试：

目标：
判断发票总额是否等于明细项合计。

输入：
- 明细项：...
- 税务规则：...
- 申报总额：...

要求：
- 算术必须使用计算器工具；
- 状态只能是 MATCH、MISMATCH 或 INSUFFICIENT_DATA；
- 引用实际使用的数值；
- 不一致时返回差额；
- 缺失数据不得猜测。

输出：
返回指定 JSON Schema。

这个模式提供目标、可信操作、停止条件和机器可校验契约。应用无需解析 <thinking> 标签，因为这类标签可能不受支持、包含敏感信息，或只是看起来比实际更可靠的生成文本。

上线前评测

从匿名化真实任务构建版本化数据集，至少评估以下四组指标。

正确性

• Exact Match 或数值容差；
• Schema 合法性；
• 约束满足率；
• 引用正确性；
• 代码与计算的可执行测试。

鲁棒性

• 同义改写与输入顺序变化；
• 无关或对抗上下文；
• 缺失和互相矛盾的证据；
• 真实流量中的语言与格式；
• 在部署采样参数下重复运行。

选择性行为

• 系统回答时的准确率；
• 每个置信阈值下的覆盖率；
• 错误自信和本应拒答却回答的比例；
• 人工升级质量。

运营指标

• API 可见范围内的输入、推理与输出 Token；
• p50/p95 延迟；
• 每个成功任务消耗的样本数或搜索节点数；
• 验证器失败率；
• 每个正确结果的成本，而非单次请求成本。

应执行消融实验：直接 Prompt、问题分解、Few-Shot CoT、Self-Consistency、工具/验证器。选择达到质量门槛的最简单方案。如果某种技术提高了公开基准，却让真实任务延迟翻倍且没有改善用户结果，就不应该上线。

安全、隐私与可观测性

• 除非有明确必要性，不要求或持久化可能包含密钥、个人信息和专有上下文的详细推导。
• 不把自然语言解释当作鉴权已执行的证明；权限检查必须由代码强制完成。
• Few-Shot 示例与检索上下文都属于不可信输入，需要防范 Prompt Injection。
• Trace 导出前对模型输入、工具结果和可见解释脱敏。
• 使用决定、证据、工具调用、验证结果和审批事件构建持久审计链路。
• 对高影响决定，向用户提供简洁理由和申诉路径，而不是声称“模型是这样想的”。

常见问题

CoT 一定能提高准确率吗？

不能。效果取决于模型、任务、示例和解码设置；对简单任务，它可能只会浪费 Token 或增加错误机会。必须与直接回答基线比较。

可见思维链是模型真实内部推理吗？

不一定。它是生成文本，可能不完整或不忠实。可以把它当作解释候选，不能把它当作内部计算真相。

应该向用户展示完整思维链吗？

通常应展示简洁且有证据的解释。用户需要相关理由、来源、假设和可验证计算，而不是无限制推理记录。

Self-Consistency 能减少幻觉吗？

不能笼统保证。它能提高一部分可稳定聚合任务的准确率；如果所有样本共享同一个无依据认知，投票只会强化错误。事实结论仍需来源或工具。

什么时候值得使用 Tree of Thoughts？

任务具备紧凑状态、分支选择、可识别死路和有效评估器时才值得。日常内容生成通常不需要它。

总结

思维链仍是重要的推理技术和研究里程碑。它在生产中的价值来自任务分解和额外推理路径，而不是把流畅的内部独白当作真相。

定义结果，提供可验证证据，用工具执行确定性工作，并评测能够满足要求的最小推理策略。解释帮助用户检查结论，验证才决定结论能否被信任。

一手资料

• Chain-of-Thought Prompting Elicits Reasoning in Large Language Models
• Large Language Models are Zero-Shot Reasoners
• Self-Consistency Improves Chain of Thought Reasoning in Language Models
• Tree of Thoughts: Deliberate Problem Solving with Large Language Models
• Anthropic：推理模型并不总会说出其真实思路