让 Claude "思考"还是直接"给答案"？我摸出来的分水岭

大概一年半前我做过一个医疗 FAQ 智能客服，核心任务是”从 800 条标准问答里召回最相关的 3 条”。0-shot + 结构化 prompt 跑下来准确率 92%，客户验收通过。

上线一个月后我想着优化一下，加了 <thinking> 让模型”先分析问题意图再选择答案”。心想这肯定更稳吧，结果一跑——84%。

整整掉了 8 个点。我反复看了很多 case 才搞明白：这类任务本质上是”语义相似度召回”，模型在 embedding 层面其实已经做对了判断，你硬让它”逐步推理”，它反而会被自己推出来的中间结论带偏。

这事给我上了一课。CoT（Chain of Thought）不是越多越好，更不是万能。这篇说一下我现在怎么判断。

什么时候 CoT 是神器

先说有用的场景。我经验里 CoT 确实能显著提升效果的几类任务：

一、数学和数值推理。不管多简单，只要涉及”一步算错全盘错”的计算，让它一步步来就对了。实测一个三步应用题，直接问正确率 73%，加 <thinking> 后 94%。这个提升是稳的。

二、多跳问答。“根据 A 文档里的 X 和 B 文档里的 Y 推出 Z”这种。模型需要先把中间结论落到纸面，不然容易幻觉。

三、合规 / 规则判断。比如”判断这份合同是否违反下面 7 条规则”。你不让它一条一条过，它会漏。让它显式地说”规则 1: 符合；规则 2: 不符合，因为…”准确率直接上去。

四、复杂决策树。客服分流、工单分类有 20 多种类别且存在嵌套层级的时候，CoT 能让模型稳得多。

这些任务的共同点：有可拆分的中间步骤、有客观验证路径、犯错代价高。给它展开的空间，它会自己纠偏。

什么时候 CoT 反而添乱

这些是我踩过坑的：

一、纯召回 / 纯匹配任务。像我开头说的那个 FAQ 项目。模型其实一眼就知道答案，你让它”分析再选”是在给它添乱。

二、简单分类。三到五个类别、边界清楚的那种。加 CoT 会让模型过度理由化——“这条评论包含了正面情绪但也有一丝失望所以应该是…”结果越想越歪。直接判断快又稳。

三、创作 / 生成任务。让它写一个故事前先 <thinking> 梳理一下人物？没必要。创作是发散的，强行收窄到”先想后写”反而让输出变得程式化。

四、高吞吐短响应场景。API 客服实时应答，延迟要求 500ms 以内，你加一段思考就是 500+ tokens 的开销，用户体验直接崩。这时候宁可损失 2-3 个点的准确率也要快。

判断逻辑大致是：任务能不能”一眼看出对错”？能的话，CoT 大概率添乱。需要”想一下才能判断对错”的，CoT 才有意义。

<thinking> 标签的正确用法

决定要用 CoT 之后，怎么用也有讲究。我看过太多人把这个标签用歪了。

错误用法一：标签里塞”万能咒语”。

1
2
3
4

<thinking>
请仔细思考这个问题，考虑所有可能的情况，
确保你的回答准确无误。
</thinking>

这种写法 Claude 看了基本等于没看。空洞的”请认真思考”对输出没任何指导作用。

错误用法二：要求固定的思考步骤但步骤不匹配任务。

1
2
3
4
5

<thinking>
1. 分析用户意图
2. 检索相关信息
3. 组织回答
</thinking>

这种模板如果和真实任务路径对不上，反而在限制模型。比如任务是个简单数值题，它会被迫走”分析用户意图”这一步，浪费 token 还可能走偏。

我现在的写法：任务依赖型，而不是通用型。

合规判断场景：

1
2
3
4
5

<thinking>
先把合同里所有可能涉及规则的条款列出来，
对每一条规则判断：符合 / 不符合 / 不适用。
所有规则过完再给最终结论。
</thinking>

数学题场景：

1
2
3
4

<thinking>
逐步列出计算过程，每一步明确说明依据的条件和得到的中间值。
算完后回头验算一遍。
</thinking>

具体、可执行、紧贴任务。不是给模型”打气”，是给它”操作手册”。

那个”让它思考反而更错”的 case

再讲个我印象深的反例。某金融客户要做”判断一条新闻是利好还是利空”。

0-shot 准确率 81%，我觉得还能更高，加了一段：

1
2
3
4

<thinking>
先分析这条新闻涉及的主体是谁、事件性质是什么、
短期影响和长期影响分别如何、最后综合判断利好利空。
</thinking>

测下来 76%。反复看了 case 之后我发现问题：金融新闻的”利好利空”很多时候是情感驱动的市场反应，不是严密因果推理的结果。

你让模型去分析”长期影响”，它经常会推出一个”虽然短期看是利空但长期利好”的结论，结果跟市场真实反应完全相反。真实市场就是看短期情绪，不看你的长期理性推理。

后来我把 thinking 拿掉，改成一条简短的 hint：”从市场短期情绪反应的角度判断”，准确率回到 81% 并稳定在那。

这个教训是：CoT 的前提是任务本身有”可推理”的结构。没有这个前提，你强行推理就是在制造噪声。

Extended Thinking 模式怎么看

Claude 后来出的 extended thinking 模式（就是那个可以看到完整思考链、token 消耗翻倍的那个）我也用过不少。

值得开的场景：

• 复杂代码生成（写一个有设计模式考虑的完整模块）
• 多文档综合分析
• 需要调试的 bug 排查
• 棋类 / 规则类博弈决策

不值得开的场景：

• 所有短平快任务
• 写营销文案、客服回复
• 文档抽取（大部分情况）
• 简单的代码 review

成本上，extended thinking 的 token 消耗能达到常规的 2-5 倍。我自己项目里的原则是：能用 Sonnet 常规模式解决的事，不开 thinking；必须开的时候，先用 Opus 试，效果 OK 再考虑降级。Claude 家族那篇里有更细的模型选型讨论。

还有个细节：extended thinking 模式下，prompt caching 的表现和常规模式有些差异，具体的我在缓存深度指南里提过。

我的决策树

简化一下我现在的判断流程：

1. 先 0-shot 跑 baseline，记录准确率和延迟
2. 分析错误 case：错的地方是”不会”还是”没想到”？
   • “不会”（知识 / 能力不够）→ 换更强的模型，或者加 few-shot，CoT 救不了
   • “没想到”（漏掉一步推理）→ 上 CoT 可能有效
3. 如果任务天然是”一眼看对错”的类型 → 跳过 CoT
4. 如果任务需要多步推理且每步可验证 → 上 CoT，写任务依赖型 thinking
5. CoT 之后再评估一次准确率和延迟，权衡是否值得

顺便说一句，CoT 和 few-shot 不是互斥的。有时候我会写 3 条带 thinking 过程的示例，让模型学会”怎么思考”。这种组合在复杂推理上特别猛。few-shot 的数量和顺序我在另一篇里细讲了。

最后

CoT 这个东西，两年前大家吹它是灵丹妙药，现在业内已经慢慢意识到它是一把双刃。用对了提升显著，用错了不但浪费 token 还损失精度。

核心就一句话：不是所有问题都需要”想一下”才能答。你问一个人”1+1 等于几”，他想 30 秒再回答你，你反而怀疑他是不是有啥毛病。模型也一样。