想象你走进一家餐厅，对厨师说：“来一盘鱼香肉丝。”厨师转身进厨房，三分钟后端出菜来——味道不错，但你完全不知道他经历了什么：肉丝是先腌还是先炒？糖醋汁是几勺糖几勺醋？万一咸了，你也不知道该让他少放盐还是多放糖。传统的 AI 提示正是如此：把问题抛给模型，模型“啪”地给出答案，中间过程是一团黑。Chain-of-Thought（思维链）则像一本详细菜谱——备料、火候、分步操作全部写清楚，厨师照着走，每一步都有迹可循，出了岔子也能立刻定位是哪一步出了问题。这项技术的本质，就是让大模型在作答之前，先把推理步骤“摊开在桌面上”，使逻辑链路显式化。

岗位关联

掌握 Chain-of-Thought，是 AI 从业者驾驭大模型推理能力的基本功。无论你在做聊天机器人、智能代理还是教育产品，它都能让模型“想清楚再回答”，显著提升回答质量与系统可解释性。

目录
  1. 可视化演示
  2. 核心原理
  3. 提出背景
  4. 工作方式
  5. 技术变体
  6. 提示模板
  7. 应用场景
  8. 工程实践
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示直接提示跳过推理、CoT逐步推理链与不同任务准确率对比，交互理解思维链提示工程原理。

本节配有交互动效（进入视口后自动加载，约 3KB）。

'+modeData.direct.caption+'

核心原理

你翻开一本好菜谱，会发现它绝不只是“做一道鱼香肉丝”这一句话。真正的菜谱会列出食材，分步写出操作：肉丝切好腌制、热锅凉油、下肉滑炒、调汁收芡。每个步骤清晰可见，即使换了新手厨师也能照着做。Chain-of-Thought 的核心原理正是如此——不是让模型一步跳到答案，而是把推理过程拆成显式步骤，一段一段地生成“思维草稿”。

在技术实现上，CoT 改变了模型的生成方式。标准大模型是自回归的，只能一个 token 一个 token 地往后生成。传统做法是“问题直接接答案”，而 CoT 要求模型先生成中间推理文本，再输出最终答案。这些中间文本不是装饰，而是模型赖以收敛到正确答案的逻辑脚手架。

从概率角度看，CoT 把“问题到答案”的一步式条件概率，分解成了“问题到推理链、推理链再到答案”的链式概率：

菜谱的灵魂在于步骤可循，CoT 的灵魂在于逻辑链路显式化。当推理中间态可见，模型不仅能答对，还能“说清楚为什么”，这正是可解释性提升的根源。

P(y∣x)≈P(z1∣x)×P(z2∣x,z1)×⋯×P(y∣x,z1,…,zn)\displaystyle P(y \mid x) \approx P(z_1 \mid x) \times P(z_2 \mid x, z_1) \times \cdots \times P(y \mid x, z_1, \dots, z_n)
这个公式说的是：最终答案不是凭空冒出来的，而是推理链上每一步条件概率逐层累积的结果。每一步都建立在前一步的基础上，环环相扣。
  1. 问题 xxx 是用户输入的问题，是整个推理链的起点，相当于“客人点的菜名”。
  2. 首个中间步骤 z₁z1z_1 是模型写下的第一句推理，比如“先提取题目中的关键数字”，相当于菜谱里的“备料”环节。
  3. 第 k 步的条件概率P(zk∣x,z1,…,zk−1)P(z_k \mid x, z_1, \dots, z_{k-1}) 表示生成第 k 步时，模型会参考问题与之前所有步骤，每一步都“看着前一步的锅”再做决定。
  4. 链式乘积×\times 把每一步的条件概率串起来，整条推理链的概率是各步概率之积，链路越长，越需要每一步都走稳。
  5. 最终答案概率P(y∣x,z1,…,zn)P(y \mid x, z_1, \dots, z_n) 是推理链走完后答案的概率，答案不再是孤立的输出，而是链条收敛的终点。

提出背景

只会报菜名的厨师会怎样？如果客人点的是“白水煮蛋”，他闭着眼睛也能做；但若点“佛跳墙”，光凭菜名根本无法还原火候与层次。传统 Prompt 就是“报菜名”式交互：把问题抛给模型，它一步到位给出答案。对于简单问题这不是问题，可一旦面对复杂数学题或多步逻辑推理，一步到位的准确率急剧下降。

研究者早就发现了这个痛点。2022 年，有研究团队观察到：如果在提示中要求模型“逐步思考”，并生成中间推理步骤，数学题基准上的准确率可以从约 18% 飙升到 57%。这不是模型变聪明了，而是推理过程被显式化后，模型更容易沿着正确的逻辑路径行走。传统方式“跳步”太多，尤其在小规模模型上，跳到半路就掉进了错误的坑里。

从概率视角看，传统方式与 CoT 的差异可以写成：

CoT 的诞生，本质上是对“一步到答案”的反思。高档餐厅不允许厨师“凭感觉做菜”，而是要求写下标准菜谱；CoT 让模型从“报菜名”走向“写菜谱”，把推理过程变成可检查、可修正的显式步骤。

Pdirect(y∣x)≤PCoT(y∣x)\displaystyle P_{\text{direct}}(y \mid x) \leq P_{\text{CoT}}(y \mid x)
这个不等式表示：在复杂推理任务上，直接生成答案的概率通常小于先推理后答案的概率。任务越复杂，差距越明显。
  1. 传统方式 PdPdirect(y∣x)P_{\text{direct}}(y \mid x) 表示模型不看中间推理，直接根据问题 x 生成答案 y 的概率，就像厨师只听菜名就出锅。
  2. CoT 方式 PCPCoT(y∣x)P_{\text{CoT}}(y \mid x) 表示模型先生成中间推理链再给出答案 y 的整体成功率，相当于照着菜谱一步步做。
  3. 比较符号 ≤≤\leq 表达“后者优于或持平于前者”。简单任务上两者相差无几，越复杂的任务，差距越大。

工作方式

有了菜谱，厨师怎么操作？他会先读菜名确认目标，再备齐食材，然后按编号步骤依次执行：切丝、腌制、滑炒、调味、装盘。每一步的“半成品状态”都是下一步的起点。CoT 的推理过程与此同构：模型先接收问题，再逐步生成推理片段，每一步都以上一步的输出为条件。这个环节不需要额外训练同一个模型，只是改变的提示方式。

在具体生成过程中，模型首先看到问题 x，生成第一个推理片段 z₁，然后以“问题 + 已有推理”为条件生成 z₂，如此循环，直到推理链完整后生成答案 y。整个过程可以看作一条有向的推理链条：

锅里的菜在每一步都有一个可观察的状态，模型脑海中的推理也是。把这个状态用文本显式写出来，就形成了“思维链”。这也是 CoT 名字的由来——像链条一样环环相扣，每一步都承前启后。

x→z1→z2→⋯→zn→y\displaystyle x \rightarrow z_1 \rightarrow z_2 \rightarrow \cdots \rightarrow z_n \rightarrow y
这个序列表达的是 CoT 的工作流：从问题出发，经过多个中间推理节点，最终抵达答案。箭头表示“下一步生成”的依赖关系。
  1. 起点 xxx 是原始问题，例如“一个果园有 12 棵苹果树，每棵结 30 个苹果，一共多少个？”，相当于客人点的菜。
  2. 箭头→\rightarrow 表示“下一步生成”，每一步都以上一步的输出为条件，箭头传递的是信息流。
  3. 推理链z1→z2→⋯→znz_1 \rightarrow z_2 \rightarrow \cdots \rightarrow z_n 是模型的中间思维草稿：先算单棵产量，再算总量，逐步逼近，就像菜谱里“切丝→腌制→滑炒→装盘”的顺序。
  4. 终点 yyy 是推理链跑完后生成的最终答案，此时答案有前后文支撑，而非凭空冒出来。

技术变体

菜谱有不同的写法。有的厨师经验丰富，你只要说“按标准做法来”，他就知道每一步该怎么走，这叫 Zero-shot；有的厨房要求对照老厨师留下的示范菜谱，这叫 Few-shot；还有的餐厅会请三位厨师分别按自己的理解做一遍，再综合投票选出最佳方案，这叫 Self-Consistency。这些变体让 CoT 在不同场景下都能派上用场。

Zero-shot CoT 最简单，只需在提示末尾加一句“让我们一步步思考”，模型就会自动展开推理；Few-shot CoT 在提示中给出一两个带完整推理步骤的问答示例，模型照葫芦画瓢；Auto-CoT 则自动从题库中挑选并生成示例，省去人工标注；Self-Consistency 让模型对同一问题多次采样不同推理路径，再对答案投票，显著提升鲁棒性。以 Zero-shot CoT 为例，其触发方式可以写成：

选哪种菜谱风格，取决于厨房条件：没时间准备示例就用 Zero-shot，能准备示例就用 Few-shot，对准确性要求极高就用 Self-Consistency。技术变体让 CoT 从一种 trick 变成了一个可选的工具箱。

CoTzero(x)=LLM(x, Let’s think step by step)→z1,z2,…,zn,y\displaystyle \mathrm{CoT}_{\text{zero}}(x) = \mathrm{LLM}\big(x,\ \text{Let's think step by step}\big) \rightarrow z_1, z_2, \dots, z_n, y
这个公式展示了 Zero-shot CoT 的全部秘密：不提供任何示例，只用一句“让我们一步步思考”触发模型的推理模式，然后让模型输出完整的推理链加答案。
  1. Zero-shot CoTCoTzero(x)\mathrm{CoT}_{\text{zero}}(x) 表示不提供示例，只靠触发短语来引导推理的方法，相当于对厨师说“请按标准做法来”。
  2. LLM 调用LLM(x, Let’s think step by step)\mathrm{LLM}\big(x,\ \text{Let's think step by step}\big) 表示把原始问题 x 与触发短语拼接后交给大模型，输入决定输出。
  3. 输出序列z1,z2,…,zn,yz_1, z_2, \dots, z_n, y 表示模型输出的是一整段推理链加最终答案，中间步骤可见可查。
  4. 箭头含义→\rightarrow 说明输出顺序是“先推理、后答案”，推理在前保证了答案有迹可循，而不是跳步硬猜。

提示模板

菜谱有固定格式：主料、辅料、步骤编号、小贴士。CoT 提示模板同样有章法，核心目标是把模型的输出“框定”成推理链格式。没有格式的提示，模型容易自由发挥；有了格式，模型就知道该按什么套路输出。

常见模板大致分三类。指令引导型直接在提示中写明“请逐步推理后再回答”；示例示范型给出一两个带完整推理步骤的问答样例，让模型模仿结构；分解引导型要求模型“把问题拆成若干子问题，再依次求解”。以 Few-shot CoT 为例，模板结构可以表示为：

没有格式的菜谱是随笔，有格式的菜谱才能流传。提示模板让 CoT 从偶然行为变成可复用的工程实践，也让团队的 prompt 资产能够沉淀和迭代。

PromptFew-shot CoT=(q1, z1(1), …, a1)⏟示例 1+(q2, z1(2), …, a2)⏟示例 2+qnew\displaystyle \mathrm{Prompt}_{\text{Few-shot CoT}} = \underbrace{\big(q_1,\ z_{1}^{(1)},\ \dots,\ a_1\big)}_{\text{示例 1}} + \underbrace{\big(q_2,\ z_{1}^{(2)},\ \dots,\ a_2\big)}_{\text{示例 2}} + q_{\text{new}}
这个公式说明 Few-shot CoT 模板由三部分拼接而成：两个带推理步骤的示范样例，加上真正要问的新问题。模型根据示范的格式，输出新问题的推理链。
  1. 示例 1(q1, z1(1), …, a1)\big(q_1,\ z_{1}^{(1)},\ \dots,\ a_1\big) 是第一组示范问答：问题 q₁、它的推理步骤 z、最终答案 a₁，相当于菜谱模板一。
  2. 示例 2(q2, z1(2), …, a2)\big(q_2,\ z_{1}^{(2)},\ \dots,\ a_2\big) 是第二组示范，模式与示例 1 相同，进一步强化模型的模仿目标。
  3. 新问题qnewq_{\text{new}} 是真正要问的题目，放在示例之后，模型会照葫芦画瓢，先输出推理链再给出答案。
  4. 加法拼接++ 表示把这些部分按顺序拼接成完整的提示文本，顺序很重要，示例必须在前，新问题在后。

应用场景

什么样的菜需要菜谱？答案是硬菜——工序复杂、火候讲究的菜。CoT 的价值同样集中在需要多步推理的“硬任务”上。在这些任务上，推理链能帮模型理清头绪，避免跳步踩坑。

典型场景包括：复杂数学应用题（列式、计算、验算），多条件逻辑推理（排除干扰项、串联条件推导），多步决策规划（制定计划、评估备选方案），以及代码生成中的思路拆解（先写算法步骤，再逐段实现）。这些任务有一个共同点：答案的正确性取决于中间每一步是否走对。相反，在简单的常识问答或情感分类上，CoT 的提升空间很小。用公式表达：

就像高压锅炖肉又快又烂，但煎蛋还是平底锅好用。CoT 不是万能佐料，而是针对“硬菜”的专属厨具。选对场景，才能把思维链的优势发挥到最大。

ΔAcc=AccCoT−Accdirect>0\displaystyle \Delta \mathrm{Acc} = \mathrm{Acc}_{\text{CoT}} - \mathrm{Acc}_{\text{direct}} > 0
这个公式是 CoT 效果的定量表达：在数学、逻辑、决策类任务上，CoT 的准确率减去传统方式的准确率，结果显著大于零。
  1. CoT 准确率AccCoT\mathrm{Acc}_{\text{CoT}} 表示使用 CoT 提示后在评测集上的正确率，对应“照着菜谱做菜的出菜成功率”。
  2. 直接回答准确率Accdirect\mathrm{Acc}_{\text{direct}} 表示传统一步式提示在同样评测集上的正确率，对应“凭感觉做菜的出菜成功率”。
  3. 差值 ΔAccΔAcc\Delta \mathrm{Acc} 是两个准确率之差，代表 CoT 带来的增益。数学与推理类任务上 ΔAcc 显著为正，简单任务上接近零。

工程实践

私房菜馆的招牌菜全靠大厨手感，一旦开连锁就必须标准化。CoT 从论文走向产品，同样要经历“中央厨房化”：效果评估、成本权衡、系统集成，一个都不能少。否则它永远只是实验室里的漂亮 demo。

效果评估上，要在自己的评测集中对比 CoT 与直接回答的准确率和稳定性，不能只信公开基准；成本上，CoT 会生成大量中间 token，延迟和费用明显上升，需要设置输出上限、缓存常用推理链；系统集成上，可以将 CoT 封装为“先想后答”的推理服务，供上层应用调用。工程上的核心矛盾可以写成效用公式：

菜谱要经受连锁店的批量考验，CoT 要经受生产环境的流量考验。谁能把推理步骤标准化、成本可控化，谁就能在真实业务中把这口锅稳稳端住，让思维链真正成为产品竞争力的一部分。

Utility=α×Accuracy−β×Costtokens(α,β>0)\displaystyle \mathrm{Utility} = \alpha \times \mathrm{Accuracy} - \beta \times \mathrm{Cost}_{\text{tokens}} \quad (\alpha, \beta > 0)
这个公式是工程决策的底层逻辑：CoT 带来的质量提升是收益，token 开销是成本，两者加权相减得到净效用。上线前要算清这笔账。
  1. 收益项α×Accuracy\alpha \times \mathrm{Accuracy} 表示模型质量带来的业务收益，系数 α 把准确率换算成业务价值。
  2. 成本项β×Costtokens\beta \times \mathrm{Cost}_{\text{tokens}} 表示生成 token 量上升带来的时间与费用开销，CoT 的推理链越长，成本越高。
  3. 净效用Utility\mathrm{Utility} 是权衡后的净效用，工程上要选一个让效用最大化的方案，例如限制推理链最大长度、对高频问题提前缓存。

AI 应用场景

数学解题辅导系统

阶段：推理增强生成（应用层 Prompt 设计）

解决的问题：传统教育 App 只会给出答案和简短解析，学生看不懂中间推导过程，遇到变式题依然不会做。CoT 让模型先输出逐步推理，再给出答案，学生能看到“先列式、再计算、后验算”的完整链条，学习效果大幅提升。

具体案例：某在线数学平台接入 LLM 后，在“鸡兔同笼”“行程问题”等应用题上，用 Few-shot CoT 模板引导模型输出解题步骤。学生在错题页点击“查看思路”，看到的不是冷冰冰的答案，而是一步步可回溯的推理过程，教师也能根据错误步骤定位学生的知识盲区。

智能客服多步诊断

阶段：任务型对话系统（多步决策）

解决的问题：传统客服机器人面对“我的账户无法登录且绑定的手机号也换了”这类复合问题，往往一次只答一个点，用户要反复提问。CoT 让模型先拆解问题：确认账号状态→验证身份→重置登录方式→更新绑定手机，按步骤输出处理方案。

具体案例：某银行智能客服使用 Zero-shot CoT 提示，在提示中要求模型“先列出诊断步骤，再输出最终建议”。改造后，复杂工单的一次解决率提升了 22%，用户平均对话轮次从 8 轮降到 4 轮，因为模型学会了“想清楚再回答”，而不是东一榔头西一棒子。

AI 编程助手的思路拆解

阶段：代码生成（逻辑链路显式化）

解决的问题：直接让模型写一段复杂函数，经常出现“代码能跑但逻辑不对”的情况。CoT 让模型先输出算法思路（如“第一步排序、第二步双指针遍历、第三步返回结果”），再生成代码，生成的代码结构与思路高度一致。

具体案例：某 IDE 插件在“解释这段代码”功能中引入 CoT 提示模板，模型先概括函数意图，再逐行分析逻辑，最后给出改进建议。开发者反馈：这种“先结构、后细节”的解释方式，比传统直接输出注释更容易理解，代码评审效率明显提高。

Python 演示

python73 行
# -*- coding: utf-8 -*-"""Chain-of-Thought 演示: 一步一步算给你看模拟大模型"先想后答"的过程:给出算式 -> 按优先级拆解为逐步计算的序列 ->记录每一步中间结果 -> 汇总答案"""import re  def tokenize(expr):    """把算式拆成数字与运算符"""    return re.findall(r'\d+\.?\d*|[+\-*/()]', expr.replace(' ', ''))  def to_rpn(tokens):    """中缀表达式转后缀表达式, 为逐步计算铺路"""    priority = {'+': 1, '-': 1, '*': 2, '/': 2}    output, stack = [], []    for tok in tokens:        if tok[0].isdigit():            output.append(tok)        elif tok == '(':            stack.append(tok)        elif tok == ')':            while stack and stack[-1] != '(':                output.append(stack.pop())            stack.pop()        else:            while stack and stack[-1] != '(' and priority.get(stack[-1], 0) >= priority[tok]:                output.append(stack.pop())            stack.append(tok)    while stack:        output.append(stack.pop())    return output  def evaluate_rpn_with_steps(rpn):    """按后缀顺序逐步求值, 记录每一步中间结果"""    steps, stack = [], []    for tok in rpn:        if tok[0].isdigit():            stack.append(float(tok))        else:            b = stack.pop()            a = stack.pop()            if tok == '+':                c = a + b            elif tok == '-':                c = a - b            elif tok == '*':                c = a * b            elif tok == '/':                c = a / b            steps.append('%g %s %g = %g' % (a, tok, b, c))            stack.append(c)    return stack[0], steps  def chain_of_thought(expression):    """主入口: 打印问题, 思维链步骤与最终答案"""    print('问题: ' + expression)    print('[思维链] 逐步推理开始:')    rpn = to_rpn(tokenize(expression))    result, steps = evaluate_rpn_with_steps(rpn)    for i, s in enumerate(steps, 1):        print('  第%d步: %s' % (i, s))    print('最终答案: %g' % result)    return result  if __name__ == '__main__':    chain_of_thought('(2 + 3) * 4 - 10 / 2')
目的：用“中缀转后缀 + 逐步求值”模拟 CoT 的中间推理过程，让小白直观理解“显式步骤”如何导向正确答案。
  1. expr.replace(' ', '')去掉表达式中的空格，让正则拆解更干净，对应“先整理问题”。
  2. if tok[0].isdigit():判断当前 token 是数字还是运算符，相当于区分“食材”和“操作”。
  3. output, stack = [], []两个容器分别装后缀结果和临时运算符，是转后缀表达式的核心。
  4. while stack and stack[-1] != '(' and priority.get(...) >= priority[tok]:按运算符优先级弹出栈顶元素，相当于决定“先乘除后加减”的做菜顺序。
  5. steps.append('%g %s %g = %g' % (a, tok, b, c))把每一步计算过程记进列表，这正是 CoT 的“思维草稿”。
  6. stack.append(c)把中间结果压回栈中，作为下一步的输入，对应推理链上“前一步的输出是后一步的输入”。

常见误区

误区以为只要在提示里加“请详细解释”“展开说说”，就算用了 CoT。结果是模型输出了大段冗长文字，但推理质量没有提升，反而增加了 token 开销。

正解CoT 的关键不是“说得多”，而是“步骤结构正确”。推理链要求每一步都有清晰的逻辑承接关系，像菜谱的步骤编号一样环环相扣。如果模型输出的是一堆重复、跑题的文字，那只是啰嗦，不是思维链。判断标准很简单：把中间步骤遮住，剩下的推理链是否仍然自洽。

为何常见：因为 CoT 的输出看起来就是“比原来多了中间文本”，新手容易把“长输出”和“显式推理”混为一谈。

误区听说 CoT 能大幅提升准确率，于是所有 prompt 都套上“一步步思考”。结果在情感分类、实体抽取等简单任务上，效果没提升，延迟和成本倒涨了不少。

正解CoT 的收益集中在需要多步推理的复杂任务上，例如数学题、逻辑推理、多步决策。对于一步就能完成的简单任务，CoT 属于“杀鸡用牛刀”，甚至可能因为画蛇添足而引入错误。工程上应该先评估任务的推理复杂度，再决定是否启用 CoT，而不是无脑套用。

为何常见：公开基准的亮眼成绩集中在复杂推理类数据集，容易让人误以为 CoT 是通用增益技巧。

误区认为模型输出的中间步骤是“真实的思考过程”，只要步骤看起来合理，答案就可靠。实际上模型可能编造一套看似严谨、实则错误的推理链。

正解CoT 的中间步骤是模型生成的文本，不是经过验证的逻辑真值。研究者称之为“幻觉推理”——模型可能先有答案倾向，再倒推出合理的步骤。因此在实际应用中，不能因为“有推理过程”就放松对最终答案的校验，关键场景仍需后置规则或人工审核。

为何常见：人倾向于相信“有过程的结果”，而模型生成的步骤在语言上往往非常流畅，极具迷惑性。

误区认为示例越多，模型模仿效果越好，于是塞进十几道题的完整推理过程，结果提示词超长、成本飙升，效果却不升反降。

正解Few-shot CoT 的示例贵精不贵多。研究与实践都表明，2-4 个高质量、覆盖不同题型特征的示例通常就足够，关键在于示例的多样性与清晰度。示例过多会稀释模型的注意力，还可能让上下文窗口逼近上限。就像菜谱示范，与其贴十道相似的菜，不如示范两道风格迥异的硬菜。

为何常见：直觉上“样本多 = 学得好”，但大模型依赖的是示例的模式引导，而不是统计拟合，示例数量存在边际递减甚至负效应。

面试题

Q1. Chain-of-Thought 的核心思想是什么？

单选题 · easy

  • A.让模型一次答出最终答案，拒绝中间过程
  • B.让模型先写推理步骤再给最终答案← 正确答案
  • C.让模型直接给出答案，不做任何解释
  • D.让模型把同一问题反复回答多遍

答案：B。CoT 的核心是让模型先生成中间推理步骤（思维链），再基于推理链给出最终答案。选项 A 是传统一步式 Prompt 的做法，C 是极简模式，D 是自一致性的雏形但并非 CoT 本身，只有 B 准确描述了“先推理后答案”的本质。

Q2. 什么情况下使用 CoT 效果最明显？

单选题 · easy

  • A.多步推理的复杂逻辑难题← 正确答案
  • B.简单的日常问候闲聊
  • C.依赖常识记忆的简单问答
  • D.一步就能完成的匹配任务

答案：A。CoT 的价值在于把复杂的多步推理显式化。复杂逻辑难题需要拆解和递推，正是 CoT 的用武之地；而问候、常识记忆、单步匹配任务本身不需要推理链，用 CoT 只会增加成本且无收益。就像写菜谱对硬菜有用，对煮白水蛋纯属多此一举。

Q3. Zero-shot CoT 的关键技巧是什么？

单选题 · mid

  • A.提供大量标注示例供模型模仿
  • B.提示末尾加“一步步思考”引导← 正确答案
  • C.使用更大的模型参数量生成
  • D.对模型做额外的微调训练改造

答案：B。Zero-shot CoT 的要点是在提示末尾附加一句“让我们一步步思考”（Let's think step by step），不提供任何示例就能触发推理链。A 是 Few-shot 的做法，C 与模型规模无关，D 是微调而非提示技术。它就像对厨师说“按标准做法来”，一句话激发既有经验。

Q4. CoT 为什么能提升模型的可解释性？

单选题 · mid

  • A.它使模型输出内部隐层向量
  • B.它以文字暴露中间推理过程← 正确答案
  • C.它显著减少模型的计算量
  • D.它强制模型调用外部工具

答案：B。CoT 把原本隐藏在参数里的推理过程，以自然语言文本的形式输出出来，用户能看到模型“怎么想”的每一步，因此可解释性提升。A 中的隐层向量不可读，C 与计算量无关，D 是工具调用范式，都与可解释性的本质不符。

Q5. Few-shot CoT 的提示模板通常包含什么？

单选题 · mid

  • A.只包含一个问题没有任何示例
  • B.若干带完整推理步骤的问答示例← 正确答案
  • C.多个只有最终答案的问答对
  • D.随机排列的无关文本片段

答案：B。Few-shot CoT 的模板由“带推理步骤的示例 + 新问题”构成，示例中的推理链是关键。A 是 Zero-shot，C 缺少中间步骤，D 是干扰项。就像给学徒示范菜谱，必须展示完整步骤，而不是只端出成品菜。

Q6. Self-Consistency 提高准确率的机制是什么？

单选题 · hard

  • A.多次独立采样推理路径并对答案投票← 正确答案
  • B.将多个问题合并成一个大问题求解
  • C.对同一条推理链反复修正直到正确
  • D.用更强的模型替换当前推理模型

答案：A。Self-Consistency 的原理是让模型对同一问题多次采样不同的推理路径，然后对最终答案进行多数投票。不同路径可能犯错，但正确答案往往在多次采样中更稳定。B 是问题合并，C 是对单链修正，D 是换模型，都不是投票机制的描述。

Q7. CoT 在工程落地时最需要权衡什么？

单选题 · hard

  • A.生成延迟与 token 成本的大幅上升← 正确答案
  • B.提示词长度能否无限地持续增加
  • C.模型能否支持多语言并行输出
  • D.训练数据是否需要全部重新采集

答案：A。CoT 会先生成大量中间 token 再输出答案，导致延迟和成本显著上升，这是工程落地最直接的代价。B 中提示词长度有限制但非核心矛盾，C 与 CoT 无直接关系，D 中 CoT 是推理时技术，不涉及训练数据。就像写菜谱虽好，但每道菜都写，后厨出菜速度必然变慢。

Q8. 以下哪些属于 CoT 的提示模板类型？

多选题 · easy

  • A.指令引导型模板← 正确答案
  • B.示例示范型模板← 正确答案
  • C.随机噪声型模板
  • D.分解引导型模板← 正确答案

答案：ABD。常见的 CoT 提示模板包括指令引导型（直接要求逐步思考）、示例示范型（提供带推理的样例）、分解引导型（要求拆解子问题）。随机噪声型不存在，属于设计出来的干扰项。三种模板对应不同的“菜谱格式”，各有适用场景。

Q9. 下列哪些任务更适合使用 CoT？

多选题 · mid

  • A.复杂数学应用题← 正确答案
  • B.简单词汇拼写检查
  • C.多步决策规划任务← 正确答案
  • D.单一步骤的文本翻译

答案：AC。CoT 的收益集中在需要多步推理的任务上。复杂数学应用题需要列式、计算、验算，多步决策需要拆解目标、评估选项，都是 CoT 的典型场景。词汇拼写检查与单步翻译属于简单任务，一步即可完成，CoT 收益甚微。

Q10. CoT 工程实践中可能遇到的挑战有哪些？

多选题 · hard

  • A.中间步骤越多 token 成本越高← 正确答案
  • B.推理链过长可能累积偏差错误← 正确答案
  • C.部分任务上提升效果并不明显
  • D.模型无法生成任何中文文本

答案：AB。CoT 的工程挑战包括：中间步骤导致 token 成本上升；推理链过长时错误会逐步累积，一步错步步错；且它在简单任务上提升有限。D 是无关干扰项，CoT 与模型是否支持中文没有关系。这些挑战提醒我们：CoT 要用在刀刃上，并设置必要的成本与质量防护。