1. 从一次失败的代码审查说起为什么我们需要 Extended Thinking上周我让 Claude 帮忙审查一个大约 2000 行的 Python 数据处理脚本。脚本本身逻辑不算复杂但涉及多个数据源的合并、清洗和转换。我像往常一样把代码贴进去然后问“请帮我审查这段代码找出潜在的性能瓶颈和逻辑错误。” 几分钟后Claude 的回复来了它指出了几个明显的语法风格问题比如变量命名不规范、缺少类型注解也发现了一个循环内重复计算相同结果的低级错误。这很好但当我运行脚本处理一个稍大的数据集时程序在运行了十几分钟后内存溢出崩溃了。问题出在一个我自认为很“巧妙”的嵌套数据结构上。为了快速匹配不同来源的数据我构建了一个多层嵌套的字典。在小数据量下这没问题。但当数据量指数级增长时这个结构的内存占用也呈指数级膨胀。Claude 的常规回复模式并没有深入“思考”这个数据结构的可扩展性问题它只是基于代码表面进行了审查。如果我当时启用了Extended Thinking功能并给予它足够的“思考预算”结果可能会完全不同。它或许能模拟更大规模数据的处理过程从而提前预警这个内存陷阱。这就是Extended Thinking的核心价值所在。它不是让 AI 变得更聪明而是让它有更多的时间和“脑力”去模拟、推理和验证那些需要多步、深度分析才能发现的问题。对于代码审查、架构设计、复杂问题拆解这类任务常规的、快速的响应往往只能触及表面。而thinking budget就是这个“脑力”的量化指标。它直接决定了 Claude 在给出最终答案前能在内部进行多长时间的思考和推理。那么这个预算到底该设多大是永远拉满以求最佳效果还是精打细算控制成本这绝不是拍脑袋的决定。设得太小可能思考不充分钱白花了问题还没解决设得太大不仅 API 调用成本飙升还可能遇到上下文长度限制导致思考过程中断。接下来我就结合自己近期的实战经验从原理到场景帮你彻底理清thinking budget的调优逻辑。2. 拆解 Extended Thinking它到底在“思考”什么在讨论预算之前我们必须先理解 Extended Thinking 的工作机制。这有助于我们判断在什么情况下需要启用它以及需要它“思考”到什么程度。Claude 的常规响应可以理解为一种“直觉式”或“快速检索式”的答案生成。它基于庞大的训练数据快速匹配问题模式组织语言给出回答。而Extended Thinking 模式则是在生成最终答案前插入了一个强制性的、内部的多步推理过程。你可以把它想象成 Claude 在交卷前强制自己必须在草稿纸上打草稿、验算并且这个草稿过程对你可见取决于你是否开启输出。2.1 思考过程的两个阶段这个内部推理过程通常包含两个关键阶段第一阶段问题拆解与规划。Claude 会首先尝试理解你任务的复杂度和核心要求。例如面对“为这个微服务设计一个数据库 schema”的任务它会先拆解出需要哪些实体用户、订单、商品、实体间的关系一对多、多对多、需要查询哪些字段、预计的数据量和访问模式。它会规划一个思考路径比如“1. 确定核心实体 - 2. 定义关系与约束 - 3. 选择合适的数据类型与索引 - 4. 考虑分库分表策略”。第二阶段模拟推演与验证。这是思考的精华部分。Claude 会沿着规划的路径进行深入的模拟。在数据库设计的例子里它可能会在“脑海”中模拟插入一批数据看主键是否冲突模拟执行几个关键的联表查询评估索引是否有效甚至模拟数据量增长到百万级后现有 schema 可能出现的性能瓶颈。对于代码审查它则会模拟不同输入条件下代码的执行流程追踪变量的变化评估时间复杂度和空间复杂度。2.2 Thinking Budget 如何量化这个过程Thinking Budget 的单位是Token和计算输入输出的 Token 是同一个概念。你可以把它理解为购买 Claude “思考时间”的货币。预算值你通过 API 参数如max_tokens_to_sample或特定平台的thinking_budget滑块设置一个数值比如 4096。消耗过程在 Extended Thinking 模式下Claude 开始它的内部推理。这个推理过程会被计算 Token 消耗。它可能会写下“首先用户的需求是… 这涉及到几个部分… 让我先分析第一部分… 这里有个潜在矛盾… 需要验证…” 这些内部的“自言自语”都在消耗 Thinking Budget。终止条件当发生以下情况之一时思考过程停止Claude 认为它已经得出了足够完善、可靠的结论可以生成最终答案了。思考预算耗尽。这是最常见的人为限制情况。一旦内部推理消耗的 Token 数达到你设置的 budget思考过程会立即被截断Claude 将基于已被截断的、不完整的思考过程来生成最终答案。这很可能导致答案质量下降。触发了模型的总上下文长度限制如 Claude 3.5 Sonnet 的 20万 Token。思考过程本身也会占用上下文窗口如果思考内容过长可能还没到预算上限就先撑满了整个上下文导致无法继续。理解这一点至关重要Thinking Budget 是一个“上限”保障而不是一个“目标”。你提供 4096 的预算是允许它最多使用这么多 Token 来思考但不代表它每次都会用满。一个简单的问题它可能只用 500 个 Token 就想明白了。2.3 与常规模式的核心差异为了更直观我们用一个表格来对比特性常规模式 (无 Extended Thinking)Extended Thinking 模式响应速度快几乎是即时的。慢有明显延迟几秒到几十秒。答案生成方式基于模式匹配和快速联想类似“直觉反应”。基于一个结构化的、多步骤的内部推理链。适合任务问答、摘要、简单代码生成、创意发散。复杂逻辑推理、数学计算、代码调试、系统设计、深度分析。成本仅计算输入和输出 Token。成本 输入 Token 思考过程 Token 输出 Token。显著更高。可解释性低给出的是最终结论。高如果开启思考过程输出可以看到推理的中间步骤更容易信任和验证。稳定性对于复杂问题答案可能不稳定每次略有不同。答案更稳定、可靠因为经过了系统性的推导。简单来说Extended Thinking 是把 AI 从“快思考”系统切换到了“慢思考”系统。对于需要严谨、深度和可靠性的任务后者是必不可少的。3. Thinking Budget 设置实战不同场景下的黄金法则知道了原理我们进入实战环节。设置 thinking budget 没有放之四海而皆准的固定值它完全取决于你的任务复杂度和对答案质量的期望。下面我结合几个典型场景给出具体的设置策略和背后的理由。3.1 场景一深度代码审查与重构建议这是 Extended Thinking 最能大显身手的领域。审查的代码行数、逻辑复杂度、以及你的要求深度共同决定了预算。任务示例“审查这段 500 行的 Go 语言 HTTP 服务代码重点评估其并发安全性、错误处理完备性并提出可落地的重构建议。”复杂度分析并发安全需要分析所有共享变量的访问路径识别潜在的竞态条件。这需要模拟多个 Goroutine 的交错执行顺序思考量巨大。错误处理需要追踪每个可能返回错误的函数调用检查错误是否被正确传递、记录或处理。这是一条条路径的静态分析。重构建议不能只提问题还要给出更好的模式比如用sync.Pool优化对象分配用errgroup管理并发错误这需要知识检索和方案设计。预算设置建议8000 - 15000 Token理由500行代码本身可能只占 2000-3000 Token。但深度审查需要 Claude 在内部“运行”和“推演”代码。它需要为关键函数创建虚拟的输入一步步跟踪状态变化思考“如果这里 panic 会怎样”“如果 1000 个请求同时访问这个 map 会怎样”。这个过程非常消耗 Token。设置 8000 以上的预算是给予它足够的空间去完成这些模拟。我曾在一个复杂的并发模块审查中设置了 12000 的预算Claude 最终消耗了约 9500 Token 进行思考输出了一份极其详尽的报告连一个罕见的边界条件死锁都找了出来物超所值。操作提示注意对于代码审查务必在提示词中明确你的重点如“性能”、“安全”、“可读性”。这能引导 Claude 的思考方向避免它把预算浪费在不重要的代码风格检查上。3.2 场景二系统架构设计与方案评估当你需要 Claude 扮演架构师角色时思考预算就是它的设计时间。任务示例“我们需要设计一个支持每日千万级订单、高并发读写的电商订单系统。请给出核心微服务划分、数据库选型与分库分表方案、以及缓存策略。”复杂度分析这是一个开放式、多维度的问题。Claude 需要权衡 CAP 定理、考虑技术栈的成熟度和团队熟悉度、计算大致的资源需求、设计服务间的 API 契约、评估不同分片策略的优劣。每一个决策点都需要推理。预算设置建议10000 - 20000 Token理由架构设计没有唯一解。Claude 需要探索多个可能的方向比如用 MySQL 还是 PostgreSQL分片键用用户 ID 还是订单时间并在内部进行对比分析。它可能会写下“方案A使用用户ID哈希分片。优点数据分布均匀用户查询快。缺点跨用户的事务复杂。方案B按时间范围分片。优点便于冷热数据分离范围查询快。缺点可能导致热点分片…” 这种多方案对比和权衡的思考过程Token 消耗非常快。对于这种级别的设计不要吝啬预算。我通常会从 15000 开始如果发现它的思考在达到预算前就戛然而止输出显得仓促下次会提高到 20000。操作提示可以要求 Claude 在思考中列出方案的Pros/Cons和适用条件。这能迫使它进行更结构化的深度思考而不仅仅是罗列技术名词。3.3 场景三复杂逻辑推理与数学计算这类任务考验的是 AI 的逐步推导能力。任务示例“一个水池有甲、乙两个进水口丙一个排水口。单开甲注满需6小时单开乙需8小时满池时单开丙排空需12小时。现在水池是空的先同时打开甲和丙2小时后关闭丙同时打开乙。问从开始算起总共需要多少小时水池被注满”复杂度分析这是一个经典的工程问题。Claude 需要分阶段计算第一阶段甲丙的净进水效率和水位第二阶段甲乙的进水效率以及基于剩余容积计算所需时间最后汇总。每一步都涉及分数运算和逻辑判断。预算设置建议2000 - 4000 Token理由虽然问题对人类来说需要几步计算但对 AI 的思考过程而言它需要明确地定义变量、列出方程、执行计算、检查单位。这个过程相对线性但必须确保每一步都准确。2000-4000 的预算足以让它从容地完成整个推导甚至进行验算。设置过低如 500可能导致思考被截断在中间步骤输出一个错误的答案。操作提示对于数学问题在提示词中要求它“分步展示推理过程”至关重要。这不仅能验证其正确性其思考过程本身也是极佳的学习材料。3.4 场景四创意写作与大纲生成你可能觉得创意不需要深度思考但对于结构严谨、设定复杂的创作Extended Thinking 能带来质的提升。任务示例“为一个科幻短片撰写故事大纲。核心设定人类发现所有‘灵感迸发’的时刻其实是高维生物在我们大脑中的‘播种’。要求包含故事三幕结构、主要人物弧光、以及一个颠覆性的结局反转。”复杂度分析这需要构建一个自洽的世界观设计符合逻辑的人物动机并安排一个意料之外、情理之中的反转。Claude 需要先构建高维生物的“播种”机制及其目的再基于此推导出人类社会的可能反应最后设计人物如何发现真相以及反转如何与此前所有伏笔呼应。预算设置建议4000 - 8000 Token理由创意不是胡编乱造最好的创意是严密的逻辑推导在另一个维度上的体现。给予足够的预算Claude 可以从核心设定出发像下棋一样推演多种故事发展的可能性并选择最合理、最具冲击力的一条。我曾为一个类似的悬疑设定设置了 6000 预算Claude 在思考中详细推演了三种不同的“凶手”身份并分析了每种身份下故事的情感张力和逻辑漏洞最终选定的方案令人拍案叫绝。操作提示在创意任务中可以要求 Claude 在思考时进行“可能性评估”比如“如果主角这样选择故事会走向A如果那样选择会走向B。B方案在情感上更强烈但与第三章的伏笔有冲突。” 这能极大提升创作的系统性。4. 避坑指南预算设置中的常见陷阱与优化策略在实际使用中仅仅设置一个预算数字远远不够。以下几个陷阱我几乎每个都踩过希望你能避开。4.1 陷阱一预算不足导致的“思考截断”这是最直接的问题。症状是Claude 给出的最终答案感觉不完整、突然跳跃、或者结论缺乏强有力的推导支撑。案例我让 Claude 分析一个分布式系统中的数据一致性方案Raft vs. Paxos预算只给了 3000。结果它的回答在对比了基本概念后刚提到“Raft 在工程上更易实现因为它…”答案就结束了。关于“为什么更易实现”、“Paxos 的真正复杂性在哪”这些关键点完全没有展开。诊断思考过程在深入分析前就被 budget 强行终止了。解决方案渐进式试探对于不确定复杂度的新任务采用“低起点逐步加”的策略。先设置一个中等预算如 4000运行一次。观察返回答案的深度和思考过程的完整度如果平台提供查看功能。如果感觉意犹未尽下次将预算提高 50%-100% 再试。观察思考痕迹一些 API 或平台允许你查看 Claude 的“思考草稿”。如果草稿的结尾是半句话或者明显在一个推理步骤中间断掉那就是预算不足的铁证。参考任务复杂度回到第 3 部分的场景分析根据任务的规模进行大致估算。宁可稍微设高一点也不要让思考夭折。4.2 陷阱二预算浪费与“过度思考”与不足相反有时 Claude 会在一个简单问题上消耗大量预算进行一些不必要的、循环的思考推高成本却没有提升答案质量。案例我让 Claude 将一段 JSON 数据转换成 Markdown 表格一个非常简单的格式化任务却设置了 8000 的预算。结果它消耗了 5000 Token 在思考上内容充满了“用户需要表格首先我要理解 JSON 结构每个键值对将成为一列… 我需要确保表头正确… 也许用户还希望有排序功能…” 这种对于简单任务来说过于冗长的“内心戏”。诊断任务本身是确定性的、简单的不需要深度推理。过高的预算反而鼓励了 AI 进行无意义的“发散思考”。解决方案明确指令限定范围在提示词中尽可能具体。不要说“分析这段代码”而要说“仅审查这段代码中与数据库连接池配置相关的部分指出配置参数是否合理并给出推荐值”。明确的指令能框定思考范围。区分任务类型对于格式化、简单查询、摘要生成除非是超长文本的深度摘要等任务根本不要开启 Extended Thinking。常规模式更快、更省钱。设置合理的预算上限对于中等复杂度任务如解释一个技术概念2000-4000 的预算通常绰绰有余。不需要一开始就设置上万。4.3 陷阱三忽视上下文长度总限制这是一个硬件层面的限制比预算限制更致命。每个模型都有最大的上下文 Token 数如 128K, 200K。问题你设置了一个 30000 的巨额 thinking budget你的输入提示有 5000 Token。理论上Claude 可以畅快思考。但是如果它在思考过程中生成的中间内容思考草稿非常冗长达到了模型上下文总容量那么思考过程会因为上下文被撑满而被迫停止即使 thinking budget 还没用完。此时你可能会收到类似maximum context length的错误或者得到一个不完整的响应。解决方案心中有数了解你所使用模型的具体上下文限制。如果你的输入问题文档本身就很长例如你提交了一份 50 页的 PDF 要求分析那么留给思考的空间本身就很少了。精简输入在开启深度思考前尽量精简你的问题描述和提供的背景材料。只提供核心、必要的信息。分段处理对于超长文档的分析不要试图一次性让 AI 思考全部内容。可以采用“分而治之”的策略先让 AI 总结各部分要点不开深度思考然后基于摘要再针对具体问题开启深度思考进行深入分析。4.4 策略优化动态调整与成本效益分析经过多次实践我总结出一套动态调整预算的心得从场景基准线开始参考第 3 部分给出的场景建议值作为你的初始设置。执行并评估运行任务仔细评估最终输出结果。如果答案质量高且思考过程完整说明预算设置合理。可以记录下这个“任务类型-预算值”的组合形成自己的经验库。如果答案感觉仓促、不深入将预算提高 1.5 到 2 倍再次尝试。对比两次的结果感受预算增加带来的质量提升是否显著。如果答案质量尚可但思考消耗远低于预算例如预算 8000只用了 2000下次遇到类似任务可以尝试适当调低预算找到质量和成本的最佳平衡点。进行成本核算始终要有成本意识。假设思考预算设置为 8000最终思考消耗了 6000 Token输出答案 1000 Token。那么本次调用的总成本 Token 输入Token 6000 1000。如果这个成本相对于任务的价值比如帮你避免了一个线上 P0 故障来说是微不足道的那么这个预算就是值得的。反之如果只是一个无关紧要的小问题就需要考虑是否值得动用深度思考。5. 高级技巧结合提示词工程最大化 Thinking Budget 的效能预算给了 AI 思考的时间而好的提示词则决定了它思考的方向和效率。两者结合才能发挥最大威力。5.1 使用“思维链”提示引导深度推理这是最有效的方法之一。在问题中明确要求 AI 按照特定步骤思考。普通提示“这个函数的时间复杂度是多少”优化后的“思维链”提示请分析以下函数的时间复杂度。在给出最终答案前请按以下步骤思考识别基本操作找出函数中的所有循环、递归调用和关键操作。计算循环嵌套分析循环的嵌套层次以及每次循环的迭代次数用 n, m 等表示。求和与简化将各步骤的操作次数相加并用大 O 表示法简化。考虑最坏情况说明你的分析是基于平均情况还是最坏情况。最终结论给出时间复杂度例如 O(n^2)。通过这样的提示你相当于为 Claude 的 Extended Thinking 过程提供了一个高效的“思考模板”。它会把宝贵的预算用在执行你指定的、有价值的推理步骤上而不是浪费在漫无目的地“琢磨”该从哪里开始想。5.2 设定明确的输出格式与决策框架对于评估、比较类任务明确的格式要求能迫使思考更结构化。普通提示“对比一下 Redis 和 Memcached我们该用哪个做缓存”优化后的提示请从以下维度对比 Redis 和 Memcached以帮助我们为高并发读写、需要数据持久化的电商商品详情页缓存做选型请以表格形式输出最终结论包含以下列对比维度、Redis 表现、Memcached 表现、对本场景的适用性分析。在思考时请重点关注数据结构的丰富性对我们缓存不同格式商品数据的影响。持久化功能在服务器重启时对缓存命中率的影响。集群模式的支持与扩展难度。这个提示不仅指明了思考方向三个重点还规定了最终输出的结构。Claude 在思考时就会自然地围绕这些维度和格式来组织内部推理使得思考过程更聚焦输出的结论也更具可操作性。5.3 利用“假设分析”挖掘边界情况这对于系统设计和风险评估尤其有用。你可以主动要求 AI 进行“如果…会怎样”的推演。示例提示你设计了这个微服务鉴权方案。现在请在你的思考过程中额外进行以下假设分析假设访问令牌JWT的密钥泄露了你的方案如何将损失和影响降到最低需要增加或修改哪些组件假设某个微服务实例被攻破攻击者获得了该实例的内存访问权限你的方案中哪些敏感信息可能暴露如何加固 请将对这些极端情况的应对思考也纳入你的最终建议中。通过指令引导 AI 主动思考边界和故障模式你能用同样的 thinking budget获得一份更具鲁棒性、更接近生产级要求的方案。这相当于用 AI 进行了一次低成本、高覆盖率的“脑力风暴式”风险评审。经过这些实战的摸索和调整我现在对于 thinking budget 的设置已经形成了一种直觉。对于大多数日常的深度分析任务4000-8000是一个安全且高效的甜点区间。它能应对绝大多数代码审查、设计讨论和复杂问题求解。对于战略级的架构设计或全盘性的项目评估我会毫不犹豫地给到15000 以上。而对于简单的格式化或问答我则会关闭 Extended Thinking让响应又快又省。最关键的是要建立起“预算-任务-质量”之间的关联认知。每一次调用不仅是获取一个答案更是一次调整你与 AI 协作模式的实验。记录下什么预算在什么任务上产生了最佳效果这将是你未来工作中一项宝贵的效率资产。