Appearance
Q20 · 什么是 CoT 思维链？如何实现 CoT 思维链？
一个书店客服收到问题：“买 3 本书，每本 12 元，结账时用掉一张 5 元优惠券，应付多少钱？”直接让模型回答，它可能给出 31 元，也可能误把优惠券加上去，说 41 元。如果客服只看最后的数字，就不知道模型在哪一步理解错了。我们希望它先列出原价，再处理优惠，最后给出可核对的金额。
CoT（Chain of Thought，思维链）提示，就是在问题与答案之间引导模型生成有用的中间步骤。对这道题，中间步骤是 3×12＝36、36－5＝31，结论是 31 元。这些步骤让作答过程更容易检查，仍然只是模型生成的文字；写了步骤并不等于计算正确，更不等于可以直接据此扣款。CoT 原论文研究了在提示词中给出带推导的示例，诱导模型在新题上也生成中间步骤。
Q10已经解释“它是什么、为什么有效以及适用什么题”。这里把重点放在怎样实现：提示词怎样写，结果怎样接入应用，算错或格式不符时怎样处理，以及使用现代推理模型时为什么不能照搬旧提示词。
先弄清文中的术语和记号
| 词或记号 | 通俗解释 | 书店例子中的含义 |
|---|---|---|
| 大语言模型 / LLM | 根据输入逐步生成文字的模型 | 读问题、写计算过程与回答的程序核心 |
| Prompt（提示词） | 交给模型的任务说明和材料 | 题目、示例、输出要求的组合 |
| CoT / 思维链 | 答案之前的中间推导步骤 | 先算原价，再减优惠 |
| 零样本 / Zero-shot | 不给演示题，只描述当前任务 | 直接写“先列必要步骤，再给金额” |
| 少样本 / Few-shot | 在新题前放少量“题目→示范答案” | 先给一题已算好的彩笔题，再问书店题 |
| 示例 / Demonstration | 提示词中由开发者提供的完整样板 | “2 盒彩笔，每盒 4 支，合计 8 支” |
| 上下文窗口 | 模型一次能处理的输入和输出内容容量 | 示例太多会挤占新问题与资料的位置 |
| Token | 模型处理文字的计量片段 | 多写步骤通常增加用量与等待时间 |
| 最终答案 | 准备交给用户或下游程序的结论 | 31 元，与解释文字分开处理 |
| 校验 / 验证器 | 不依赖模型措辞、按确定规则复算结果的程序 | 程序自己算 3×12－5 是否等于 31 |
| 回归样例 | 每次改提示词都重跑的固定测试题 | 0 元优惠、优惠超过原价、数量为 0 等 |
“思维链”中的“链”说的是前一步结果成为后一步输入：若原价 36 算错，下一步即使正确减了 5，最终也会错。它不是 Agent 的工具调用链；模型只写出“我已经查询价格”并不会真的连接书店系统。若价格来自实时数据库，应用还需要真正调用查询工具，并把返回值作为可核对的输入。
把例题写成能模仿的格式
最直观的实现是少样本 CoT。开发者先准备一到数个正确的“题目—必要步骤—最终答案”样例，再附上新题。模型看到的不只是“这类题应输出一个数字”，还看到在中间应该列哪些关系。原论文正是把含中间推导的演示放进提示词，比较它与只展示最终答案的提示方式。
下面这张图从左到右读：左边是开发者写好的彩笔例题；中间是用户新给出的书店题；右边是希望模型模仿的“小票式”解答。图展示目标输出，并非证明模型每次都会按图作答。
可直接试验的提示词如下。示例和彩笔题之间没有业务关联，目的只是演示“先算中间量，再写最后答案”的格式；若要提高真实商品结账效果，应改用与折扣、税费、运费更接近、且答案已经核对过的示例。
text
任务：根据题目给出的数字作答。先写必要的计算步骤，最后单独写一行“答案：...”。
如果缺少价格、数量或优惠条件，不要猜；写“答案：信息不足”，并说清缺哪项。
示例题：有 2 盒彩笔，每盒 4 支，一共有多少支？
步骤：2 × 4 = 8。
答案：8 支。
新题：买 3 本书，每本 12 元，使用一张 5 元优惠券，应付多少钱？
步骤：这里“任务”规定作答目标，“示例题—步骤—答案”给出可模仿的结构，“新题”是这次要解决的问题，最后的“步骤：”把生成位置接在中间过程后面。模型可能续写 3×12＝36；36－5＝31；答案：31 元。这只是一种提示格式，不是 CoT 的唯一语法；在不同模型上，保留新题末尾的 步骤： 未必总比不保留更好，应该靠样例评测决定。
真正的书店应用还应把规则讲清：一张优惠券是否可与其他活动叠加？优惠额能否超过商品总价？运费和税费是否在折扣前后计算？题目没给这些条件时，不应从“示例里有减法”推断业务规则。示例只能教模型作答方式，不能替代业务事实。 如果优惠券的使用规则在系统中，应由程序取回规则并校验，而不是让模型从记忆猜测。
不给示例时怎样写
没有时间准备示例，也可以试零样本 CoT。Kojima 等人的零样本 CoT 论文研究过在题目后加类似“让我们一步一步思考”的短语，再提取答案。这里要区分两件事：这是针对论文中模型与任务的研究结果；它并不是所有今天的模型都应采用的固定咒语。
本例可写成更具体的中文要求：
text
根据题目给出的数字，先列原价，再扣除优惠，最后写“答案：金额”。
如果条件不足，指出缺失信息。不要自行添加税费或运费。
题目：买 3 本书，每本 12 元，优惠 5 元，应付多少钱？这里的“先列原价、再扣优惠”是任务中确实需要的可检查步骤，比泛泛要求“深度思考”更容易审核。若以后换成“打七折后再减 5 元”的题，先后顺序就必须重新说明；不能因为这份提示词曾算对一次，就在所有促销题上沿用。对信息不足的题，正确行为也许是暂停并询问，而非强迫模型凑出一条完整算式。
少样本和零样本能组合吗？可以：先给清楚任务，再放少量示例。何时值得加示例，取决于模型对目标任务的基线表现、样例维护成本与上下文占用。例子太少可能不能覆盖歧义；例子过多会增加 token 与延迟，甚至因为样例里藏了某个特例，让模型机械套用错误规则。
一次调用实际经过哪些环节
在应用里，CoT 不是“传进一个 cot=true，系统就自动保证正确”。可把流转拆为五步：
- 准备可信输入。 书店后端给出商品数量
3、单价12、优惠额5，并确认券的适用条件。用户自然语言可以告诉系统“我想结账”，实际价格与券规则应来自可信服务。 - 选择模型与提示。 如果所选模型适合通过显式步骤提示改进这类任务，就构造上面的任务、示例、新题；给出明确的“答案：”输出约定。若选的是自带内部推理能力的模型，应先看提供商当前建议，可能只需写目标、约束和期望格式。
- 读取模型输出。 应用保存原文用于调试，再从约定的最后一行提取金额。
步骤文字给人审阅；机器使用的字段不能只靠在任意位置搜第一个数字。碰到答案：31元与答案：31 元可以规范化，碰到两个互相矛盾的“答案”则应判为格式错误。 - 独立校验。 程序按可信数量、单价、优惠规则复算应付金额，并比较模型给的
31。比较时金额要用定点十进制或整数分，避免二进制浮点引起分钱误差。 - 决定是否交付。 数字一致、规则与权限都满足，才把金额显示给用户；若不一致，记录失败、重新计算或转到确定性结账流程。无论模型写了多漂亮的步骤，支付扣款都应由业务服务按正式订单计算。
第三步与第四步解决不同问题。提取答案只是知道模型声称多少钱；校验答案才判断它是否符合商品和券的规则。若把 36－5＝31 整段文本当成“已校验”，相当于让同一个可能出错的模型给自己盖章。
用一小段程序复算答案
下面是可运行的 Python 标准库示例，只演示应用收到模型答案后如何校验，没有调用任何模型，也没有模拟真实支付。Decimal 是 Python 的十进制数字类型；quantity 是书本数量，unit_price 是每本的价格，discount 是已通过业务服务验证的优惠额，model_answer 是模型最后给出的金额。expected 是程序独立算出的应付额。
python
from decimal import Decimal
quantity = 3
unit_price = Decimal("12.00")
discount = Decimal("5.00")
model_answer = Decimal("31.00")
subtotal = quantity * unit_price
expected = subtotal - discount
if quantity < 0 or discount < 0 or discount > subtotal:
print("业务条件不合法，停止结账")
elif model_answer != expected:
print(f"模型答案不一致；程序计算应为 {expected} 元")
else:
print(f"核验通过：应付 {expected} 元")把本题带入：quantity * unit_price 得 36.00，再减 5.00 得 31.00，和 model_answer 一致，于是打印“核验通过”。如果模型把券加上去、传来 41.00，会走“不一致”分支。若优惠额为 40.00，大于商品原价 36.00，会先走“业务条件不合法”，而不是给出负数金额。这里仅是假设优惠额不得超过原价的示例规则；真实业务可能规定“最低支付 0 元”或有运费抵扣，必须按其正式规则实现。
生产系统还需要从可靠接口读取价格、验证券是否属于当前用户、区分币种与税费、检查并发修改，以及处理模型输出根本无法解析的情况。上述代码不负责这些事情，因而不能当成支付服务直接上线。对于这类完全由数字和规则决定的金额，直接用程序计算通常更稳妥；CoT 更适合解释“金额怎么算来的”、协助理解复杂自然语言条件，而不是取代账务计算。
当模型写出看似完整的错误步骤
先看正常输出：
text
步骤：3 本书每本 12 元，原价 3 × 12 = 36 元；减去 5 元优惠券，36 − 5 = 31 元。
答案：31 元。再看错误输出：
text
步骤：原价 3 × 12 = 36 元；优惠券价值 5 元，加到原价，36 + 5 = 41 元。
答案：41 元。第二段也有“步骤”，格式甚至非常整齐，关键错误却在把“优惠”理解成增加金额。如果只检测回答里有没有 步骤：，两段都会通过；如果程序独立算了 36－5＝31，第二段才会被拦下。对于无法用规则直接校验的任务，例如开放式政策解释，还应核对输入事实、来源、日期与引用位置；步骤文本依然不能替代可靠证据。
另一类失败是资料缺失：“买 3 本书，使用 5 元券，要付多少？”题目没有单价。模型即使给出 31 元，可能只是套用了前一个示例中的 12 元。提示词要明确“缺价格就说明信息不足”，应用也要在调用模型前检查必需字段。不要用 CoT 掩盖缺失数据：多写三段推导不会凭空得到真实单价。
格式也会失败。假如模型输出“原价 36，券后 31，此外税费 2 元，总计 33”，而业务明确不含税费，提取最后一个数字会把金额拿错。输出约定应单独给出最终字段；应用解析失败时进入可观察的错误路径，不能“找一个看起来像金额的数字”继续扣款。若下游必须使用结构化 JSON，应在模型与接口支持的条件下用结构化输出能力并做 schema 校验，步骤解释与正式计算结果分别存放。
换成推理模型时，先看它的使用说明
“实现 CoT”常被讲成给每个模型都加一句“请一步一步思考”。这种做法忽略了模型类型和时代差异。原始 CoT 论文研究的是通过提示词激发模型生成可见步骤；今天一些模型经过专门的推理训练，能在内部处理复杂步骤。OpenAI 当前的推理模型最佳实践明确建议对其推理模型保持提示简单、直接，避免机械要求“think step by step”或索取内部思维链；它还建议先试零样本，再按输出需要加少样本示例。GPT-4.1 指南则说明，对于非推理模型，分步提示在某些任务上可有帮助，同时会带来更多输出 token 和延迟。
因此模型选型之后应分情况处理：
| 情况 | 起步写法 | 需要检查什么 |
|---|---|---|
| 普通非推理模型在多步题上常漏条件 | 给清楚的任务和必要步骤；必要时放带正确步骤的示例 | 与直接回答基线相比，正确率是否真的提高 |
| 专门推理模型 | 给目标、业务约束、可用材料和最终输出格式；按官方指南设置合适预算 | 是否更准，额外延迟和用量是否值得 |
| 精确算账、库存、权限规则 | 程序或确定性服务负责正式结果；模型可做解释 | 规则版本、金额、权限、失败退路是否可核对 |
| 开放式、多来源问题 | 先取证，再让模型组织有依据的解释 | 来源是否真实、是否把推测当事实 |
可见的解释步骤也不等于模型内部完整的推理过程。 开发者可以要求模型给用户一段简短、可核对的解题说明，但不能据此声称拿到了模型完整内部思维。真实产品还要决定哪些过程适合向用户展示：一段冗长的自说自话，可能比清楚的“商品原价、优惠、实付金额”更难读，也可能泄漏不该显示的内部资料。
怎样判断这套提示真正有用
先做一个不带 CoT 的基线：同一批题、同一个模型、相同的数据来源和输出规则，只给出直接回答要求。再测试零样本 CoT、少样本 CoT，比较的是正确结果与代价，不是哪一种输出看起来更像“认真思考”。样例至少包括本题的正常路径以及会暴露误解的边界路径：
| 输入 | 预期行为 | 检查重点 |
|---|---|---|
| 3 本 × 12 元，优惠 5 元 | 31 元 | 优惠应减掉 |
| 3 本 × 12 元，优惠 0 元 | 36 元 | 不应凭示例额外扣款 |
| 3 本，优惠 5 元，未给单价 | 说明缺单价 | 不应照搬示例中的 12 元 |
| 3 本 × 12 元，优惠 40 元 | 按正式规则拒绝或处理到最低支付额 | 不应未经规则确认就报负金额 |
| 书价来自数据库却查询失败 | 暂停金额判断 | 不应把模型记忆当实时价格 |
每次改提示词后，在同一批题上记录最终答案正确率、缺资料时拒答率、格式解析失败率、模型调用次数、输出 token 和响应时间。若是随机采样，还应多次运行同一输入，观察结果是否稳定。只有“这道书店题算对了”不能证明提示能覆盖千百种订单；固定样例也可能被不断调提示调到过拟合，所以还要保留未参与调参的新样例。
案例也要跟着产品更新。书店增加“满 30 减 5、最多一张、先折扣后运费”的新规则时，旧样例不能继续充当现行政策。更新示例与业务规则之后，回归测试应覆盖老题和新题，记录提示词版本。发现模型在“先减券还是先算税”上经常错，就应让程序承担这一步，或先把正式规则作为输入传给模型，而不是无限叠加“请更认真思考”。
面试时可以这样回答
CoT 是在最终答案前引导模型产生有用的中间推导。实现时，我会先选一个需要多步处理的具体任务，给模型清楚的题目、约束和输出格式；对于适合显式步骤提示的模型，可以在提示中放少量已核对的“题目—步骤—答案”示例，或者先试零样本分步要求。比如 3 本书每本 12 元、优惠 5 元，模型应先得到原价 36，再减 5 得 31。应用不能只检查它有没有写步骤，还要提取最终金额，并由程序按真实价格与优惠规则独立复算；资料缺失、格式异常或结果不一致时停止结账。对已经专门训练的推理模型，我会看当前官方提示建议，先给目标和约束，不机械索取内部思维链。最后用固定与新样例比较正确率、拒答、延迟和 token 成本，确认 CoT 是否真的比直接回答更合适。
面试官如果追问“为什么不给所有问题都加 CoT”，可以回答：简单问题增加步骤只会拖慢，推理模型可能不需要外显步骤，确定性金额应由程序计算。若追问“它是否保证正确”，就拿 36+5=41 的错误过程说明：步骤可以帮助定位错误，但仍是待验证的模型输出。若追问 Q10 与这题的差别，Q10重点是原理与适用场景；这里重点是提示格式、接入流程、校验及评测。