地图：七组共 20 个概念

一张地铁图：先看整条线路，再一站一站地乘过去。

先是三个基础：模型默认怎么作答、chain-of-thought 是什么、为什么那些步骤有帮助。然后是六组，每章一组：reasoning model、test-time compute、推理何时有用、思考的代价、为什么推理不等于真相，以及如何用得好。

后面的每个概念都是同一个形状：它的英文名称（记住它——那就是术语）、一幅生活中的画面、一幅图，以及一张卡片，上面有是什么、思路、例子、陷阱和关联等字段。

Single-pass Answer — 一口气脱口而出

一个学生喊出脑子里冒出的第一个数字，另一个学生先在草稿纸上把题算出来——后者对的概率高得多。

默认情况下，模型一遍就生成答案：直接给出回答——说白了就是脱口而出。对简单的问题，这没问题。但凡是需要好几步逻辑的问题，直接跳到答案就是它容易出错的地方，就像一个人匆匆忙忙做难题会犯粗心的错。解决办法就是老师们要求的那条：别只给答案，要把步骤走一遍。

Chain-of-Thought (CoT) — 出声推理，一步一步来

在数学题里把解题过程写出来——按顺序写下每一步——这样推理一目了然，中间的失误会被发现，而不是被埋没。

Chain-of-thought（CoT）是这样一种技巧：让模型在给出最终答案之前，先一步步生成它的推理，而不是只给出答案。当被要求“好好想一想”时，模型会写出中间步骤——顺着这些步骤推下去，得出正确结论的概率，远高于一步跳到结论。这些步骤不只是摆样子：生成它们，正是让模型能够一步步搭出正确答案，而不是靠猜。把思考写在纸面上，思考就变得更好。

Working Memory — 工作就发生在这些步骤里

脑子里算一长串计算容易出错；同样的计算写在纸上，一行一行来，就可靠了——纸替你装着脑子会漏掉的东西。

为什么写出步骤会有帮助？每生成一步，就成为模型接下来一步可以依托的上下文。它实际上是把自己的输出当作 working memory，把一次艰难的跳跃拆成一串小而好办的动作。一个一跳解决不了的大问题，变成一个序列就能解决了。这就是整门课背后的核心洞见：给模型留出推理的空间，而不是要求它立刻给出答案，才能解开难题。

Reasoning Model — 受过训练、作答前先思考的模型

反射式作答的人，和受过训练、会先停下来推理的人之间的差别——思考的习惯已经长进了他们的工作方式里，而不是需要你去要求的东西。

Reasoning model 是专门训练过的模型：在最终答案之前先生成一段内部的思维链——默认就先“思考”，而不是只有被提示时才这样做。标准模型是脱口而出；chain-of-thought 提示是哄它去推理；而 reasoning model 把这个过程内置了。它先产生一段内部推理，再给出答案，在真正需要推演的问题上明显更强。

Speed–Depth Trade-off — 用速度换深度

一位谨慎的专家花一分钟想一想再回答，给出的答案比立刻回答的快手更好——但你得等。

Reasoning model 每个答案要花更多力气和时间，因为在回答之前要生成所有那些内部步骤。这让它比标准模型更慢也更贵，换来的是在难题上更强。这是一个真正的取舍，不是白送的升级：你要为思考的深度付出代价——延迟和 token。所以 reasoning model 并不是简单的“更好”，它是另一种工具。

Tool, not Default — 难题的工具，而不是默认选项

你请深度思考的专家来处理真正棘手的案子，而不是去回答前台的日常问题——用错了地方，就浪费了他们的才能。

当任务真正需要谨慎的多步思考时，reasoning model 是合适的工具；对简单快速的活儿则是错的，它的反复斟酌纯属浪费。用它来给一条消息分类或重新排版，就像雇一位哲学家来接电话：更慢更贵，却没有任何好处，因为这个任务从来不需要思考。它是处理工作中那一块难题的有力工具，而不是在其他一切事情上取代快速模型。

Test-time Compute — 在作答时多花力气

考试时间更多，你会检查答案、换个思路再试、抓出错误——同一个人，仅仅因为被允许多花些时间，就考得更高。

Test-time compute 指的是在作答的那一刻——也就是模型运行的推理阶段——多花一些计算，以换取更好的结果。模型不再是快速的一遍，而是想得更久，生成更多推理，也许尝试几种思路再挑出最好的。reasoning model 背后那个惊人的发现是：让模型在作答时多做点工作，质量就会提升，就像在难题上多给一个人一些时间。你可以靠更多的思考买到更好的答案，而不仅仅是更多的训练。

Effort Dial — 决定想多用力的旋钮

一个调节努力程度的恒温器：难题调高，简单题调低，思考的量正好配得上任务的价值。

Test-time compute 是一个旋钮，不是开关：你可以只花一点思考，也可以花很多，一般来说越多，难题上的结果越好——直到收益递减的那个点。在 API 里，这个旋钮通常叫 reasoning effort 或 thinking budget。它的威力在于，你可以按每个请求的难度来调节力度：真正的难题调高，日常的保持低位。

Train-time vs Test-time Compute — 提升的两条轴

一个学生在考前更用功地学习，同一个学生在考试中被多给了时间——这是取得更好结果的两种不同方式。

从历史上看，模型的进步主要靠训练——更多的数据、更大的模型，一次性在前期完成。Test-time compute 是另一条轴：在推理时更卖力地工作来改进答案，模型每次运行都是如此。这是获得更多能力的第二种方式——不只是更聪明的模型，而是同一个模型想得更久。了解这两条轴，有助于你弄清楚模型的质量——以及它的成本——到底来自哪里。

Multi-step Problems — 思考在哪里能回本

一条转弯很多的复杂路线值得仔细规划；通往隔壁房子的直路则不用——路越难走，思考越值。

推理在多步问题上帮助最大，这类问题真正需要好几步逻辑：数学和计算、多步规划、复杂代码、逻辑谜题，以及错一步就毁掉答案的细致分析。这些恰恰是脱口而出会失败、而逐步推演会成功的任务。问题越难、步骤越多，额外的思考对结果的改善就越大——这就是为什么 reasoning model 在满是真正难题的基准测试上表现出色。

Overthinking — 简单任务一无所获

午饭吃什么，两个选项你都满意，却斟酌良久——所有这番思考得出的是同一个答案，只是更慢。

对于简单直接的任务——给这个分类，提取那个，重新排版这段文字，回答一个基本的事实问题——推理除了延迟和成本，什么也没增加。这里没有多步逻辑可以推演，所以思考是白费力气；一遍就能看出答案。更糟的是，让模型对一个琐碎任务“思考”，偶尔反而会让它更差——它想多了，把本来不需要斟酌的事情搞复杂了。

Difficulty Matching — 让思考的深度匹配难度

好员工在难的决定上花很长时间，简单的立刻回答——按每件事真正的需要来校准力度。

起支配作用的原则是 difficulty matching：让模型思考的力度与问题的难度相称。真正困难、高风险、多步骤的工作，配得上 reasoning model 或更多的 test-time compute；简单、日常、范围明确的工作，交给快速的标准模型。这呼应了模型经济学里的 routing 思想：大多数请求很简单，要的是速度；少数很难，要的是思考。把一切都送给 reasoning model，和把一切都送给前沿模型一样浪费——要校准，别默认。

Reasoning Tokens — 思考越多，token 和钱越多

一个在有人斟酌的整个过程中一直跑着的计价表——想得越久，账单越大，不管多出来的那些思考有没有必要。

所有那些推理步骤都是生成出来的 token——reasoning tokens——你要为它们付费。Reasoning model，或者高档的 test-time compute 设置，会在答案之前产生大量内部思考，其中每个 token 都要花钱。所以推理的每个答案，比一次直接作答明显贵得多。让它在难题上更强的深度，恰恰也是让它更贵的原因。这就是为什么“所有事都用 reasoning model”会毁掉 AI 预算。

Latency — 它更慢，用户能感觉到

那位花一分钟才回答的谨慎专家，在难题上值得等，但如果你只是问现在几点，就让人抓狂。

生成所有那些步骤需要时间，所以 reasoning model 和重度的 test-time compute 给出答案更慢——有时慢得多。这就是 latency。对后台任务没关系；对盯着屏幕等待的用户，长时间的延迟是对体验的真实代价。对于用户预期要花点时间的难题，多出来的几秒是值得的，而对于本该感觉瞬间完成的交互，就不合适了。速度是你拧大思考时所花掉的东西。

Thinking Tax — 别为任务不需要的思考买单

雇一位又慢又贵的深度思考者整天回答简单问题——你付着高价，还要等得更久，而这些答案一个手脚麻利的职员瞬间就能给出。

要避免的浪费，是把推理的成本和延迟花在得不到好处的任务上。把每个请求——简单的和困难的一视同仁——都送进 reasoning model，意味着在整个请求流上缴 thinking tax，而实际上只有一小块需要它。模型经济学里的同一条纪律在这里适用：默认走更便宜、更快、不带推理的路径，只有真正困难、对得起它成本的情况，才升级到推理。在思考能回报你的地方付钱，多一个 token 都不付。

Confidently Wrong — 再长的链条也可能得出错误的答案

一个建立在有缺陷前提上的详尽而自信的论证——每一步都衔接得整整齐齐，结论依然是错的。光鲜不是证明。

推理提高的是难题上答对的概率；它不保证答对。模型可以产生一条冗长、流畅、看起来合理的思维链，却导向错误的结论——链条早期的一个错误被自信地带到了最后，或者推理听起来严谨，其实并不严谨。看得见的步骤让答案感觉更可信，而这恰恰是陷阱：推理越多，看起来越权威，却不一定越正确。

Unfaithful Reasoning — 展示出来的推理，可能并不是真正的原因

有人凭直觉做了决定，事后再编一套听起来合乎逻辑的理由——解释听上去很真，却不是他们真正得出结论的方式。

还有一个更微妙的陷阱：模型展示出来的思维链，并不保证就是真正产生它答案的过程。它可以生成看起来像通向结论之路的推理，而真正的依据其实是别的东西——一种听起来合理的事后编造，而不是忠实的叙述。这叫做 unfaithful reasoning，而一条诚实的链所具备的性质叫做 faithfulness。所以你不能完全相信展示出来的推理，把它当作答案为什么是这样的解释。它是有用的信号，也有助于提高准确度，但并不是一扇能保证看到模型真实逻辑的窗口。

Verify the Answer — 检查结果，别欣赏思考

你检查一个复杂的计算，是独立地确认结果，而不是欣赏演算过程有多整齐——重要的是答案是否正确。

实际的结论是：评判 reasoning model 的输出，看答案是否正确、是否经过现实的核验，而不是看推理看起来多么令人印象深刻。别处讲过的所有纪律依然适用——让它扎根于真实事实，对照来源检查，跑 evals，在高风险的决定上留一个人。推理让难题的答案更有可能是对的；但并不意味着不经核验就可以放心相信。一条自信的思维链，在你检查它落在哪儿之前，依然只是一个自信的猜测。

Routing & Escalation — 只在难的那一部分把思考拧大

你对那一个棘手的步骤全神贯注，其余的一带而过——把力气集中在难点真正所在之处，而不是平均摊开。

统一的做法，是在整个系统里让思考与难度相称。这就是 routing：在真正困难、多步骤、高风险的任务上用 reasoning model 或更多 test-time compute，对简单的大多数用快速的标准模型。你甚至可以混用——快速模型处理日常路径，并把困难的子问题升级给 reasoning model。把斟酌花在问题难的地方，也只花在那里，你就能获得准确度的提升，而不必在所有事情上缴 thinking tax。

Ingredient, not Finished Dish — 推理不能取代核验

一位谨慎的专家更可能是对的，但高风险的决定你仍然要确认——他们的谨慎提高了概率，却不能免去检查的必要。

最后一条纪律把这门课和其余的内容连了起来：推理能提升难题上的质量，但它依然是一个会出错的模型，可能信心十足地出错，所以其他一切依然重要。让它扎根于事实，核验答案，跑 evals，在有后果的决定上留人。推理是获得更好输出的又一种方式——与好的上下文、检索和合适的模型并列——而不是一个神奇的升级，能让你免于围绕它去搭建可靠性。更好的思考是一种更强的食材，而不是一道做好的菜。

一切如何连在一起

一根杠杆，三个后果：它带来收益，它花钱，它还带着风险——用它时，三样都要放在心里。

Chain-of-thought 内置于 reasoning model，而 reasoning model 是 test-time compute 的一种形式。这根杠杆有三个后果：多步问题上的收益，token 和延迟上的代价，以及信心十足地出错或不忠实的推理这一风险。用好它，意味着瞄准收益（difficulty matching、routing），守住预算（没有 thinking tax），并检查结果（verify the answer）。