2024 年我做一个需要模型做推理的功能——让大模型解应用题、根据一组规则算出结果、做多步的逻辑判断。我想要的很明确:用户问一个问题,模型干净利落地给出答案。怎么让模型答得准?这件事我没多想,就有了方案:把问题问清楚,然后让它直接给答案,别废话。第一版我做得很顺手——我在 prompt 里把题目写明白,末尾加一句"只输出最终答案,不要任何解释"。本地拿几道简单题一测,答得又快又准,我心里很笃定:让模型答题嘛,问题问清楚、让它直接给结果,这套推理稳了。可等我把真正需要多步推理的题喂给它,一串问题冒了出来。第一种最先把我打懵:一道要算好几步的应用题,我让它"只输出答案",它给的数字明明白白是错的。第二种最难缠:同样一道题,我随手换了个问法,让它"说说你的过程",它居然答对了——题没变、模型没变,只是我让它多说了几句话。第三种最头疼:我把"一步步想"加进 prompt 后,大部分题对了,可有些题,它写出来的推理过程一步步看都对,最后报的那个答案却和过程对不上。第四种最莫名其妙:我让它输出推理过程,用户那边就看到一大段啰里啰嗦的思考,体验很差。我盯着这一连串问题想了很久,才彻底想明白:第一版错在一个根本的认知上。我以为问题问得越干脆、越是要求它直接给答案,模型就答得越准——让它别废话,直接出结果。可大模型是一个"逐 token 生成"的模型:它每生成下一个字,能依据的全部东西,就是你的 prompt 加上它自己已经生成出来的内容。当你要求它"直接输出答案",你等于要求它在一两个 token 之内,凭空完成一道需要好几步推理的题——而它没有一块"内部的草稿纸",它能用来推理、用来承载中间步骤的唯一空间,恰恰就是它生成出来的那些文本本身。你不让它说过程,就是抽掉了它的草稿纸。思维链(Chain of Thought)做的事,本质就是把这块草稿纸还给它:让模型先把推理过程一步步生成出来,把这些生成出来的文字当成它的外部工作记忆,在这个基础上,再得出最终答案。本文从头梳理:为什么"直接要答案"会让模型在多步问题上出错,思维链的本质是什么,怎么用示范教会模型推理,怎么让推理和答案分离以便程序稳定提取,怎么用多次采样投票进一步降低出错,以及一些把它做扎实要避开的工程坑。
问题背景
先把大模型生成答案的方式说清楚。一个大模型,本质是一个逐 token(可粗略理解为逐字、逐词)生成文本的程序。它生成第 N 个 token 时,唯一的依据,是前面已经存在的全部 token——你的 prompt,加上它自己已经生成出来的第 1 到 N-1 个 token。它没有一个独立于输出之外的"内存"或"草稿区"来打草稿。
错误认知是:模型内部有强大的"思考能力",你只要把问题问清楚,它会在内部默默想好,然后把答案吐出来。真相是:模型没有藏在内部的思考过程,它"思考"的唯一介质就是它生成的文本;不让它生成推理过程,就等于不给它思考的空间。把这层认知摆正,第一版的几类问题就都能解释了:
- 直接要答案就出错:多步问题被压进一两个 token 里生成,模型没有承载中间步骤的空间,只能"凭直觉"报一个数,自然容易错。
- 让它说过程就变对:一旦允许它生成推理过程,这些文字成了它的草稿纸,每一步都能基于上一步,问题就被拆解成了它能处理的小步。
- 过程对、答案错:推理过程和最终答案没有清晰分离,答案是模型随口接的,没有真正"读"自己的推理。
- 推理过程暴露给用户:推理过程是给模型自己用的工作记忆,不是给用户看的成品,直接展示就成了体验噪声。
所以让模型推理做对,核心不是把问题问得更狠、逼它直接出结果,而是理解它需要"生成推理过程"这块空间,并围绕这块空间把提示、采样、答案提取都安排好。下面六节,就从第一版"直接要答案"的错讲起。
一、为什么"直接要答案"会让模型在多步问题上出错
第一版的 prompt 里那句"只输出最终答案,不要任何解释",看起来是个无害的、让输出更干净的要求。但对一道需要多步推理的题来说,它是致命的。要理解为什么,得想清楚模型是怎么生成那个答案的。模型逐 token 生成,当它写下"答案是"之后,紧接着要生成的那个 token——也就是答案本身——它能依据的,只有前面的题目和"答案是"这三个字。中间所有的推理步骤,你都不许它写,于是这些步骤根本不存在,它必须一步到位地"猜"出最后那个数。
# 反面教材:要求模型"只给答案",多步问题就容易错
PROMPT = """一个水池,进水管每小时进水 6 立方米,
出水管每小时出水 4 立方米。水池原有水 10 立方米,
容量上限 30 立方米。两管同开,几小时后水池放满?
只输出最终答案的数字,不要任何解释。"""
def ask(client, prompt: str) -> str:
resp = client.chat(messages=[{"role": "user", "content": prompt}])
return resp["content"]
# 模型可能直接吐出一个数字,比如 "4" 或 "5"
# 正确答案是 (30 - 10) / (6 - 4) = 10 小时
# 它没有写中间步骤的空间,只能"凭直觉"报一个数,极易错这道水池题,人来做也要分三步:算每小时净进水(6 减 4 等于 2)、算还需进多少水(30 减 10 等于 20)、算需要的时间(20 除以 2 等于 10)。每一步都依赖上一步的结果。你让模型"只输出答案",等于让它在脑子里把这三步一次算完,还不许打草稿。它做不到,不是因为它笨,而是因为它压根没有"在脑子里默算"这个能力——它的"算",就是"生成文本"这个动作本身。没有文本,就没有算。
这一节要建立的认知是:模型没有一个独立于输出之外的"思考空间",它生成出来的 token,既是它的输出,也是它唯一的工作记忆。这是理解思维链为什么有效的地基。我们习惯把"思考"和"表达"看成两件事——先在脑子里想好,再说出来。但对大模型不是这样,它的"想"和"说"是同一个动作:它通过生成文本来推进推理,生成到哪,就推理到哪。所以"只输出答案、不要过程"这个要求,在多步问题上,不是让输出变干净,而是直接抽掉了它推理的脚手架。明白了这一点,你对待模型的方式就该变了:不要把它当成一个"内部很能算、只是嘴上不说"的对象,而要把它当成一个"必须把话说出来才能想清楚"的对象——那就让它说。
二、思维链的本质:让模型把推理过程生成出来
既然模型的草稿纸就是它生成的文本,那解法就顺理成章了:别再禁止它写过程,反过来,明确地要求它写。这就是思维链最朴素的形态——在 prompt 里加一句话,引导模型先一步步地把推理写出来,再给答案。这种不需要任何示例、仅靠一句引导语就触发推理的做法,叫 zero-shot CoT。
# 思维链:让模型把推理过程生成出来,再得出答案
COT_PROMPT = """一个水池,进水管每小时进水 6 立方米,
出水管每小时出水 4 立方米。水池原有水 10 立方米,
容量上限 30 立方米。两管同开,几小时后水池放满?
请一步一步地思考,先写出推理过程,再给出最终答案。"""
def ask_with_cot(client, prompt: str) -> str:
resp = client.chat(messages=[{"role": "user", "content": prompt}])
return resp["content"]
# 模型这次会先生成类似这样的推理:
# 每小时净进水 6 - 4 = 2 立方米
# 还需要进水 30 - 10 = 20 立方米
# 所以需要 20 / 2 = 10 小时
# 然后才得出答案 10。这段推理文本,就是它的草稿纸就这么一句"请一步一步地思考",效果常常立竿见影。原因不神秘:模型被允许生成推理过程后,它会先写下"每小时净进水 6 减 4 等于 2"。现在,"2"这个中间结果,作为已生成的 token,实实在在地存在于上下文里了。它生成下一步时,就能直接读到这个 2,而不用重新去猜。一道大题,就这样被拆成了一串小步,每一步都站在上一步的肩膀上。第一版里"换个问法让它说过程就对了",背后就是这个机制——你不是改了题,你是把草稿纸还给了它。
这一节的认知是:思维链不是什么高深的"激发模型潜能"的咒语,它就是一件朴素的事——把模型推理需要的工作空间,显式地给它。很多人觉得"让我们一步步思考"这句话很神奇,加上去模型就变聪明了。其实模型的能力一点没变,变的是你给没给它施展能力的地方。这就像让一个人算一道复杂的乘法:你递给他纸笔,他就能稳稳算对;你不给纸笔、要求他心算,他就容易错。递纸笔这个动作,没有提升他的算术能力,只是让他的能力有处落地。思维链就是给模型递纸笔。理解了这个朴素的本质,你就不会迷信某句"魔法提示词",而会去想一个更实在的问题:这个任务,模型需要多大的草稿纸、需要把哪些中间步骤写出来——然后在 prompt 里把这个空间给足。
三、Few-shot 思维链:用示范教会模型怎么推理
zero-shot CoT 那句"一步步思考",好用,但有时不够。当任务的推理方式比较特殊、或者你对推理的格式有要求时,光说"一步步思考",模型可能想得很发散、格式也飘忽。这时更可靠的做法是 few-shot CoT:不只是叫它推理,而是先给它看几个完整的范例——每个范例都包含"问题、推理过程、答案",让模型照着这个样子来。
# Few-shot 思维链:用几个带推理过程的例子做示范
FEWSHOT_PREFIX = """下面是几个解题示范。
问题:小明有 5 个苹果,又买来原有数量 3 倍多 2 个,现在共几个?
推理:买来的是 5 乘 3 再加 2,等于 17 个。
原有 5 个,现在一共 5 加 17,等于 22 个。
答案:22
问题:一本书 240 页,已经读了三分之一,还剩多少页?
推理:已读的是 240 乘三分之一,等于 80 页。
还剩 240 减 80,等于 160 页。
答案:160
现在请用同样的"推理 + 答案"格式,解下面这道题:
问题:"""
def ask_fewshot(client, question: str) -> str:
prompt = FEWSHOT_PREFIX + question
resp = client.chat(messages=[{"role": "user", "content": prompt}])
return resp["content"]这里的关键,是范例里的"推理"那几行。它们在向模型示范两件事:一是推理该有的"颗粒度"——每一步只做一个小动作,不跳步;二是推理该有的"格式"——先推理、后答案,答案用固定的"答案:"开头。模型有很强的模仿能力,看了两三个这样的范例,它解新题时,会自然地沿用这种颗粒度和格式。比起一句空泛的"一步步思考",范例是更具体、更强的引导。
这一节的认知是:对模型来说,"给它看几个做对的例子",往往比"用语言描述要求"更有效——示范是一种信息密度极高的指令。你用语言说"推理要详细、要分步、格式要规整",这些词都是抽象的,模型对"详细"到什么程度、"分步"分多细,理解可能和你不一致。但你直接给它两个范例,"详细到什么程度""分步分多细""格式长什么样",全都具体地、不留歧义地摆在那里了。这是 few-shot 这种方式的普遍价值,不限于思维链——当你发现很难用语言把要求说清楚时,换个思路:别描述要求,直接做一个样品给它看。在思维链里,这个样品就是带推理过程的范例。它教会模型的,不是"算这道题的答案",而是"用什么样的方式去推理"。
四、推理与答案分离:让最终答案能被稳定提取
到这里,模型已经会先推理、后给答案了。但新问题来了:模型返回的是一大段文本,推理和答案混在一起。你的程序要的是那个明确的答案——拿去做判断、存数据库、返回给前端。你不能把一整段话都当答案。第一版"推理过程对、但答案对不上"的问题,有一部分也出在这:答案没有被清晰地标记出来,模型自己写到最后,随口接了个数,你的程序也无从准确地把它摘出来。
# 让推理和答案分离,最终答案放在固定标记后,便于提取
import re
STRUCTURED_PROMPT = """请解下面的题目。先输出完整的推理过程,
最后另起一行,以"答案:"开头,只写最终答案。
题目:{question}"""
def solve_and_extract(client, question: str) -> dict:
prompt = STRUCTURED_PROMPT.format(question=question)
text = client.chat(
messages=[{"role": "user", "content": prompt}],
)["content"]
# 推理过程留作展示和排查,答案按固定标记单独抽出来
m = re.search(r"答案[::]\s*(.+)", text)
answer = m.group(1).strip() if m else None
return {"reasoning": text, "answer": answer}做法是在 prompt 里规定一个清晰的输出结构:推理过程在前,然后另起一行,用一个固定的标记(这里是"答案:")引出最终答案。模型遵循这个结构后,你的程序就能用一个简单的规则——找到"答案:"这个标记,取它后面的内容——稳定地把答案摘出来。推理过程依然完整保留,但它和答案在结构上被清楚地分开了。
这一节的认知是:思维链让模型生成了"推理 + 答案"两部分,而你的程序真正要消费的是答案,所以必须在它们之间划一道程序能识别的界线。这是从"能让模型推理"到"能在系统里用起来"的关键一步。模型的输出是给人看的自然语言,是连续的、没有字段的;而你的程序需要的是结构化的、能被精确定位的数据。这中间的鸿沟,要靠"约定一个输出格式"来填——你和模型约定好答案放在哪个标记后面,模型负责遵守,你的程序负责按这个约定去取。不做这层分离,你就会陷入"模型明明算对了,我的程序却拿错了答案"的尴尬。记住:让模型推理是一回事,让推理的结果能被系统可靠地接住,是另一回事,后者同样需要专门设计。
五、self-consistency:多次采样投票,降低单次出错
前面几节让模型学会了推理,但还有一个现实:模型是概率性的,同一道题,它推理一次,可能某一步走偏,得出错的答案;再推理一次,可能就对了。单次推理,总有翻车的概率。一个能显著提升可靠性的技巧,叫 self-consistency(自洽性):对同一道题,让模型用带随机性的方式,独立地推理很多次,得到很多条推理路径和很多个答案,然后看哪个答案出现得最多,就采纳哪个。
# self-consistency:对同一题多次采样推理,取多数答案
from collections import Counter
def solve_with_voting(client, question: str,
samples: int = 5) -> str:
answers = []
for _ in range(samples):
# 每次独立推理一遍(用较高 temperature 让路径有所不同)
result = solve_and_extract(client, question)
if result["answer"] is not None:
answers.append(result["answer"])
if not answers:
return "无法得出答案"
# 多条独立推理路径中,出现次数最多的那个答案
most_common, count = Counter(answers).most_common(1)[0]
return most_common它为什么有效?因为推理出错往往是随机的——这次在这步错、那次在那步错,错法五花八门,但正确的答案只有一个。于是多次推理之后,各种错误答案是分散的,而正确答案会被反复地、集中地命中。取多数,就是利用"错是分散的、对是集中的"这个规律,把单次的随机失误过滤掉。代价也很直接:本来调一次模型,现在要调五次,token 和延迟都翻了几倍。
把从问题到答案的整条决策路径画出来,就是下面这张图:
[mermaid]
flowchart TD
A[收到一个问题] --> B{需要多步推理吗}
B -->|不需要| C[直接提问 直接取答案]
B -->|需要| D[加入思维链提示]
D --> E[模型先生成推理过程]
E --> F[再从推理得出最终答案]
F --> G{要更高的准确率吗}
G -->|不要| H[按标记提取答案返回]
G -->|要| I[多次采样独立推理]
I --> J[对多个答案投票取多数]
J --> H
这一节的认知是:single-consistency 之所以有效,是因为它把"一次推理对不对"这个赌注,换成了"多次推理里多数对不对"——而后者是一个稳得多的赌注。这背后是一个很通用的工程思想:面对一个不稳定、有随机误差的部件,与其指望它每次都对,不如让它多跑几次,再用某种聚合(投票、取多数、取平均)把随机误差抵消掉。它不要求每一次都对,只要求"对"比"任何一种特定的错"更高频。思维链让单次推理变得更可靠,self-consistency 则在单次的基础上,用冗余进一步把可靠性往上抬一个台阶。当然,它是用成本换可靠性,不该无脑全开——这正引出下一节要讲的工程权衡。
六、把思维链做扎实,要避开的工程坑
前面五节搭出了一套能推理、能提取答案、能投票的方案。但要在生产里真正用好,还有几个坑得专门讲。第一个,是第一版第四类问题:推理过程不该直接甩给用户。推理过程是模型的"草稿纸",是给模型自己、以及给你排查问题用的;用户要的是干净的最终答案。正确做法是,在返回时把推理和答案切开,只把答案展示给用户,推理过程记进日志,留作排查和审计。
# 工程坑:推理过程是给系统用的,不要直接展示给用户
import re
def split_reasoning_and_answer(text: str):
# 以"答案:"为界,把推理段和答案段切开
parts = re.split(r"\n?答案[::]\s*", text, maxsplit=1)
if len(parts) == 2:
reasoning, answer = parts[0].strip(), parts[1].strip()
else:
reasoning, answer = text.strip(), ""
return reasoning, answer
def respond_to_user(text: str) -> dict:
reasoning, answer = split_reasoning_and_answer(text)
return {
"display": answer, # 用户只看到干净的最终答案
"trace": reasoning, # 推理过程进日志,供排查与审计
}第二个坑,是不要无差别地给所有任务都套上思维链。思维链会让输出变长——推理过程本身要占很多 token,这意味着更高的费用、更长的响应延迟。对一道需要多步推理的难题,这个成本花得值;但对一个简单的事实性问题("今天星期几""把这句话翻译成英文"),硬加思维链,就是白白多花钱、多等时间。明智的做法是按任务类型分流:复杂任务走思维链,简单任务直接问。
# 不是所有任务都值得 CoT:简单任务直接答,省 token 省延迟
# 大致需要多步推理的任务,才有必要上思维链
COT_TASK_HINTS = ("计算", "推理", "为什么", "比较", "规划", "证明")
def needs_cot(question: str) -> bool:
return any(hint in question for hint in COT_TASK_HINTS)
def smart_solve(client, question: str) -> str:
if needs_cot(question):
# 复杂任务:走思维链,必要时再加投票
return solve_with_voting(client, question)
# 简单的事实性、分类性问题:直接问,不必铺推理
return ask(client, question)还有几个坑值得点一下。其一,要警惕"推理过程看着对、其实是事后编的"——模型有时会先得出一个答案,再补一段看似合理的推理,这段推理未必是它真正得出答案的路径。所以推理过程可以增强可信度,但不能 100% 当成模型的"真实思路"来全信。其二,推理过程变长,会更快地消耗上下文窗口,多轮对话里尤其要注意。其三,思维链对本身就有较强推理能力的大模型增益明显,对能力很弱的小模型,有时帮助有限甚至会带偏。下面把思维链的几种用法集中对照一下:
思维链的几种用法对照
方式 做法 适合场景
--------------------------------------------------------------
zero-shot CoT 加一句"一步步思考" 通用 改造成本最低
few-shot CoT 给几个带推理过程的范例 格式要求严 任务较固定
推理答案分离 推理 + 固定标记后给答案 答案需被程序提取
self-consistency 多次采样推理 取多数答案 高准确率要求 可接受多花钱
共同前提:都要先给模型"把推理写出来"的空间;
区别只在示范多少 采样几次 答案怎么提取。
这一节这几个坑,串起来是同一个意思:思维链不是一个"打开就好"的开关,它是一笔要算的账——用更多的 token、更长的延迟,去换更高的准确率。账要算,就意味着有的场景值得花、有的不值得:难题值得,简单题不值得;要高可靠的关键判断值得上投票,普通问答不值得。把推理过程剥离出用户视野,是因为它是过程不是成品;按任务分流,是因为成本要花在刀刃上;不全信推理文本,是因为它未必等于模型的真实思路。把思维链当成一个有成本、有适用边界、需要按场景配置的工具,而不是一句包治百病的魔法提示词——这样它才能在你的系统里稳定地发挥价值。
关键概念速查
| 概念 | 说明 |
|---|---|
| 思维链 CoT | 让模型先把推理过程生成出来、再得出答案的提示方法 |
| 逐 token 生成 | 模型一次生成一个 token,只能依据 prompt 和已生成的内容 |
| 草稿纸效应 | 模型生成出来的推理文本,充当它的外部工作记忆 |
| zero-shot CoT | 仅靠一句"一步步思考"即触发推理,无需任何示例 |
| few-shot CoT | 提供几个含推理过程的范例,示范推理的颗粒度与格式 |
| 推理答案分离 | 推理过程与最终答案用固定标记隔开,便于程序稳定提取 |
| self-consistency | 对同一题多次采样推理,取出现最多的答案 |
| temperature | 采样随机度,self-consistency 需较高值产生不同推理路径 |
| 推理过程剥离 | 面向用户只展示答案,推理过程入日志供排查审计 |
| 事后合理化 | 模型的推理文字未必等于它真实得出答案的路径,不宜全信 |
避坑清单
- 不要要求多步问题"只给答案":模型没有内部草稿纸,会被迫一步到位地猜。
- 不要以为模型在内部默默思考:它的思考介质就是生成的文本,不写就没有。
- 不要只用空泛的"一步步思考":格式要求严时,用带推理的范例做 few-shot 更可靠。
- 不要让推理和答案混作一团:用固定标记把答案标出来,程序才能稳定提取。
- 不要依赖单次推理:概率性模型单次会翻车,关键任务用多次采样投票。
- 不要把推理过程直接展示给用户:它是草稿纸,只给用户答案,推理进日志。
- 不要给所有任务都套思维链:简单事实问题硬加 CoT,白费 token 和延迟。
- 不要把推理文本当成模型的真实思路:它可能是先有答案再补的事后合理化。
- 不要忽视 CoT 对上下文窗口的消耗:推理变长,多轮对话里更快撑满窗口。
- 不要无视成本只追准确率:CoT 和投票都是用 token 和延迟换准确率,要按场景算账。
总结
回头看第一版那个"让模型直接给答案"的做法,它的错误很典型。它不在某一行代码,而在一个对大模型的根本误解:以为模型内部藏着一个强大的思考过程,你只管把问题问清楚、催它直接出结果就行。真相是,模型没有独立于输出之外的思考空间,它生成出来的 token 既是输出、也是它唯一的工作记忆。要求它"只给答案、不要过程",就是抽掉了它推理的草稿纸,逼它把一道多步的题一步算完。思维链做的,就是把这块草稿纸还给它——让它先把推理写出来,在写出来的基础上再得答案。
而把思维链做扎实,工程量并不小。它不是加一句"一步步思考"就完事,而是要根据任务用对方式——通用场景用 zero-shot,格式严的用 few-shot 范例;要把推理和答案用固定标记分离,好让程序稳定提取;关键任务要用多次采样投票来抵消单次的随机失误;还要把推理过程从用户视野里剥离、按任务类型决定该不该上 CoT、算清 token 和延迟的成本账。一套真正可靠的推理方案,是这些环节一个不少地拼起来的。
这件事其实很像让一个人算一道复杂的算术题。你要是逼他心算,不许他动笔,他算三五步就容易乱、容易错——不是他不会算,是他没有地方放中间的数。你递给他一张草稿纸,让他把每一步都写下来,他就能一步一步、稳稳地算到底。思维链里那句"请一步步思考",就是递草稿纸这个动作。而 self-consistency,就像让三个人各自独立算一遍这道题,最后看谁的答案一致——一个人偶尔会算错,三个人都在同一个地方错成同一个数,概率就低多了,取多数那个,八成是对的。模型的推理,和人用草稿纸、和多人核对答案,是同一个道理。
这类问题还有一个共同的麻烦:它在简单测试里很难暴露。你在本地拿几道一眼就能算的简单题去测,模型直接给答案也对——因为那些题根本不需要多步推理,一步就到。真正会把"没有草稿纸"这个问题撑开的,是上线后用户问的那些需要七拐八绕、好几步推理的真实难题:这时"直接要答案"的模型就会原形毕露,给出一个看起来煞有介事、其实是错的数字。所以如果你正在做一个需要模型推理的功能,别等用户拿着算错的结果来质疑,才回头怀疑提示词。从一开始就想清楚:这个任务要不要模型推理、要给它多大的草稿纸、答案怎么从推理里干净地取出来——把推理的空间显式地留足,这是这篇文章最想留给你的一句话。
—— 别看了 · 2026