企业官网建设流程全解析

最近我在搭一套智能文档分析流程时，做了一组对比测试：同一个问题，分别发给普通模式的模型和开启了Extended Thinking的模型。结果有点出乎意料——普通模式不仅解题过程简略，还在中间一步漏掉了关键条件；开了Extended Thinking后，模型先复述了一遍问题约束，写下两种可能的解法，把其中一条明显错误的方向排除掉，才给出最终答案。

这就是Extended Thinking最直观的价值：让Claude在输出最终回答之前，先进行一次可控长度、可观测的深度思考。它把过去只能靠提示词暗示的"思维链"变成了API里一个显式的配置项，开发者可以给思考过程分配专门的token预算，模型会在预算内展开草稿、做自我检查、尝试备选路径，然后再生成精炼的正式回答。对做AI应用开发、Prompt工程、复杂任务自动化的朋友来说，这个功能几乎属于必装项，值得花点时间搞明白。

1. Extended Thinking到底解决了什么问题

1.1 一句话理解这个功能

把模型的最终回答想象成一份答卷。普通模式是拿到题提笔就写，写到一半发现思路不对，只能硬着头皮改；Extended Thinking则要求模型先打草稿——在草稿纸上列条件、做演算、试错、检查，确认逻辑闭环了，再工整地把答案誊到答题区。

草稿不会被直接展示给用户，但它消耗"纸张"和"时间"，对应到API里就是token预算和响应延迟。这正是Extended Thinking的核心设计：把推理过程和最终输出彻底拆开，让推理成为独立的、有预算约束的、可以被程序读取的中间产物。

1.2 普通思维链提示的问题在哪

很多人之前会在系统提示里写"Let's think step by step"，试图让模型逐步推理。这个土办法确实有效，但它有几个绕不过去的短板：

第一，推理和最终回答混在同一段文本里。模型一边推理一边组织语言，它的注意力要在"想"和"写"之间来回切换，一旦最终答案需要非常精炼，推理过程很容易被压缩成几句口号式的"分析"。

第二，思考长度完全不可控。你没法告诉模型"这道题最多想2000个token，想完就停"。结果就是简单的题目它也可能长篇大论，复杂的题它可能两三句就跳到结论。

第三，也是最隐蔽的问题：模型可能在输出时才临时编造一套"推理"来合理化答案，它并不真的在回答前进行推理。这种先有结论再补解释的现象，会让用户误以为结论已经经过了逻辑验证，实际上没有。

Extended Thinking用工程手段解决这三个问题：推理有独立的位置承载，有明确的token预算，并且在响应结构上保证它先于最终答案产生。它至少让"思考过程"这件事变得可以观测、可以控制、可以审查。

2. Extended Thinking的核心机制：推理Token、预算与签名

2.1 从"边写边想"到"先想后写"

开启Extended Thinking后，请求会多一组配置。模型先生成一段内部推理内容，这段内容对应API响应里的推理块，然后基于这段推理再生成最终文本。你拿到响应时，能同时看到"草稿"和"正式答案"两部分。

从工程角度看，这相当于把原来一次性的自回归解码拆成了两个阶段：推理阶段和答案阶段。推理阶段的token全部计入输出token，也按输出价格计费。这就是为什么开启这个功能后账单会明显变贵——它不是免费的魔法，而是模型真的多写了一段内容。

响应的大致结构长这样（不同版本字段名会有差异，请以官方最新文档为准）：

{ "content": [ { "type": "thinking", "thinking": "复述问题条件……先假设……这里有个陷阱……改用贝叶斯公式……", "signature": "一段用于续接的签名" }, { "type": "text", "text": "根据计算，最终答案是……" } ] }

额外补充一点：如果推理内容触发了隐私保护规则，API可能会返回一个占位块而不是完整草稿。这属于合规设计，不是Bug，不能当作模型出故障。

2.2 budget_tokens：模型能"想"多久

budget_tokens大概是Extended Thinking里最需要理解透的参数。它决定了模型可以生成多少推理token，类似草稿纸的张数。

预算太小时，模型还没把问题想透就得强行收尾，效果与普通模式差距不大；预算太大，模型确实会绕更多的路、做更多的自我检查，但代价是响应变慢、成本上升。我的习惯是先给一个保守值跑通，再逐步往上加，观察答案质量的变化曲线。当预算增加到一定程度后，答案质量往往不再提升，甚至因为想得太多而出现过度修正——那个拐点就是性价比最高的配置。

下面是我常用的预算参考档位：

2.3 签名机制与多轮续接

一个容易被忽略的细节：推理内容不是普通的文本，它带有一个签名。签名存在的意义是保证推理链的完整性和连续性，类似给一份草稿加了个防伪标记。

当你做多轮对话时，如果上一轮产生了推理内容，下一轮请求必须把上一轮的签名回传，否则API会拒绝续接或报签名无效。这其实是一种安全设计——防止有人篡改中间的推理环节来操纵最终输出。实操中常见的报错"signature invalid"，八成就是你在续接时没有正确传递签名。

3. 实操：在API中开启Extended Thinking的完整步骤

3.1 请求配置与最小示例

下面是一个最小化的Python示例，使用官方SDK开启Extended Thinking，字段名以你实际使用的API版本为准：

import anthropic client = anthropic.Anthropic() response = client.messages.create( model="claude-sonnet-4-20250514", max_tokens=8192, temperature=1.0, thinking={ "type": "enabled", "budget_tokens": 4096 }, messages=[ {"role": "user", "content": "你的问题放在这里"} ] )

注意两个细节：

第一，开启thinking后，官方建议把temperature设为1。这个模式下的推理本身已经带有探索性，过低的温度会让思考路径变窄，过高的温度又容易跑偏。

第二，max_tokens要同时覆盖推理token和最终答案token。如果你把总输出限制设得太小，模型可能推理到一半就被截断，最终回答都没生成出来。我见过太多人只把max_tokens设成几百，然后来问"为什么开了思考模式反而没输出"——就是这个原因。

3.2 从响应中读取推理内容

拿到响应的方式很简单：

signature = None for block in response.content: if block.type == "thinking": signature = block.signature print("推理草稿:", block.thinking) elif block.type == "text": print("最终回答:", block.text)

如果你想拿推理内容做二次分析，比如提取关键步骤、做后续任务输入，直接存这个块就行。如果遇到的是隐私遮蔽类型的推理块，API会在响应中保留占位，但你拿不到原始文本，这也是为什么产品设计时不要把推理内容当成可依赖的公开数据。

3.3 多轮对话时的签名回传

续接对话时，把上一轮拿到的signature传给下一次请求：

client.messages.create( model="claude-sonnet-4-20250514", max_tokens=8192, temperature=1.0, thinking={ "type": "enabled", "budget_tokens": 4096 }, thinking_signature=signature, messages=[ {"role": "user", "content": "第一轮问题"}, {"role": "assistant", "content": "第一轮回答摘要"}, {"role": "user", "content": "顺着刚才的思路继续追问"} ] )

不同版本的SDK对签名参数的位置叫法不一样，有的放在thinking配置里，有的是顶级参数，但逻辑是一致的：推理产生了，签名就必须跟着走。我不建议你在续接时丢弃上一轮推理内容只在messages里塞一个assistant文本，那样会切断推理链，模型等于重新开始想。

3.4 预算怎么定才合适

我推荐一个三分法来定预算：

先做端到端实测。从一个较低的预算开始跑，比如2048。如果答案质量不达标，翻倍到4096再跑一次。如果翻倍之后质量提升明显，继续加；如果提升微弱，就停在上一个档位。这种方法比一上来就给大预算更省成本，也能帮你找到"够用"的最小值。

另外，对延迟敏感的应用，预算要往下压。推理token是一步步生成的，预算越大，首个响应token出现的时间越晚。用户体验要求首字快出的场景，该妥协就妥协，不要为了追求完美答案牺牲交互等待。

4. 实战效果：我实测过的三类任务

4.1 数学推理：一道贝叶斯概率题

我用一道经典的贝叶斯题做对比测试：

有两个盒子，A盒中有3枚金币和1枚银币，B盒中有1枚金币和3枚银币。随机选一个盒子，再从其中随机摸出一枚硬币，发现是金币，问这枚硬币来自A盒的概率是多少。

普通模式下，模型直接写出了贝叶斯公式，但中间漏掉了先验概率P(A)=1/2的显式计算，最终给了一个含混的结论。

开了Extended Thinking后，模型的推理流程明显不同。它先在草稿里复述了问题条件，写下了P(A)=1/2、P(G|A)=3/4、P(G|B)=1/4，然后分别计算两条路径的联合概率：

P(A且G) = 1/2 × 3/4 = 3/8 P(B且G) = 1/2 × 1/4 = 1/8

归一化之后得到P(A|G) = (3/8) / (3/8 + 1/8) = 3/4。

关键在于，推理块里能看到模型自己写了一句"等一下，这里需要把两个分支的贡献做归一化，不能只看其中一条路径"。这种自我纠错的痕迹在普通模式里几乎见不到，因为它根本没有空间做这一步。

这题比较基础，但道理是通用的：需要精确公式、多步骤推导、边界条件判断的任务，Extended Thinking的收益最明显。

4.2 代码排查：偶发超时问题的定位

我让某开发者用这个功能排查一个偶发的接口超时问题，那次的对比让我印象很深。普通模式下，模型给出的建议是"增加客户端超时时间并加入重试机制"。这个建议不算错，但完全没有触及问题的核心。

开启思考模式后，模型的诊断逻辑完全不同。它先列出了一张候选清单：网络抖动、客户端重试逻辑缺陷、服务端线程池耗尽、数据库慢查询、网关限流。然后根据给出的日志特征逐项排除——日志里没有数据库慢查询的迹象，所以数据库这条先划掉；超时发生在固定时间窗口，不是随机网络抖动；最终锁定了客户端在短窗口内的重复请求触发了服务端限流。

这个案例给我的启发是：思考模式在"诊断类"任务里的价值，不只在于给出结论，更在于输出一条可验证的排除路径。哪怕它最后锁定的原因不够准确，这种结构化的推理过程本身，对工程师做二次判断也是极有帮助的。

4.3 长文档分析：收益最大但别指望它消灭幻觉

我在多文档综合分析任务上也做了测试。普通模式会快速给出一个概括性的回答，但经常把不同文档里的数据混在一起；开启Extended Thinking后，模型会在推理阶段先摘录各文档的关键信息，再判断哪些信息互相矛盾，最后才组织答案。整体上看，引用准确性和信息归因都上了一个台阶。

但有一件事必须泼冷水：思考模式不能解决幻觉问题。它能让模型多想一会儿，但不能让它"想到的全是真的"。如果模型本身没有见过相关事实，或者文档里根本没有对应信息，它照样会在推理里编造一个合理的解释。因此涉及事实性、时效性的场景，还是得靠外部检索和验证兜底，思考模式只是让错误出现得更少、也更容易被追踪。

5. 常见问题与排查技巧实录

这里单独讲一个被问得最多的坑：模型推理方向跑偏。当你发现它想了一大堆却给出错误答案时，不要盲目加大预算，那只会让它在错误方向上走得更远。正确做法是在系统提示里加入结构约束，例如要求模型：

推理过程中必须依次完成：1. 列出所有已知条件和未知量；2. 写出可能的解法并标记最可疑的一个；3. 对最终结论做一次反向验证；4. 如果发现矛盾，回到第2步修正。

这种约束能把思考过程拧到正确的轨道上，而且它提取出来的结果也更规整，方便程序做后续处理。

6. 几点实测经验与避坑总结

最后分享几个我在实际项目中积累的操作经验。

第一个经验是把Extended Thinking当作"先遣分析器"来用，而不是单纯的答题开关。我会先让模型开启思考模式产出一份结构化推理报告，把这个报告存下来，之后再做总结、问答、生成文档时，普通模式直接引用这份报告就够了。这样既拿到了深度的中间产物，又不用每次都付出思考模式的成本。

第二个经验是关于隐私设计的。推理内容可能包含用户原始输入、模型自身的推测、甚至一些不该展示的中间结论。如果做面向终端用户的产品，千万不能把完整推理草稿直接放在界面上。官方API用占位块做隐私遮蔽，这个设计本身就是给开发者提个醒：思考过程是内部数据，不是展示素材。

第三个经验是控制预期。Extended Thinking是个好东西，但它本质上只改变"思考过程的结构"，不改变"模型知识的边界"。它不会让模型突然变聪明，只是让它更充分地调用已有的能力。你该做检索还是做检索，该搭知识库还是搭知识库，别指望一个参数解决所有问题。

我个人的习惯是，在做任何涉及复杂推理的任务时，先以普通模式跑一遍拿基线答案，再开启Extended Thinking对比一次。如果两次结论一致，说明任务足够简单，后续就不开思考模式；如果两次结论不一致，我会重点检查模型的推理链条，判断哪一次更靠谱。这个流程虽然多花一次请求，但对判断"你的任务到底适不适合开思考模式"非常有效，长期用下来反而省了不少钱。