思维链

当AI开始"思考自己的思考" 2026年的某天，一个研究团队在测试最新模型时观察到了这样的对话： 研究者：你刚才的推理中有一个逻辑错误，你能找到吗？ AI：让我重新审视刚才的推理链。第一步，我假设A导致B。第二步，我推导B导致C。但你指出的错误在于——我从A到B的因果推断实际上只是相关性，我在这里混淆了因果与相关。这个错误源于我在训练数据中见过太多"A与B共现"的模式，导致我过度推广了这一关系。 这段对话展示了AI的自我反思能力——不仅能够执行推理，还能审视推理过程本身，识别其中的缺陷。这种"元认知"能力正在成为AGI研究的重要方向。 从思维链到元认知 思维链（Chain-of-Thought） 2022年，CoT（Chain-of-Thought）提示技术的提出是一个转折点。通过让模型"展示推理过程"，复杂推理任务的准确率大幅提升： # CoT提示的基本形式 prompt = """ Q: 一个商店有23个苹果，卖了17个，又进了12个，现在有多少个？ A: 让我一步步来。 初始数量：23个 卖了17个：23 - 17 = 6个 又进了12个：6 + 12 = 18个 答案：18个 """ 但CoT本质上仍是"单次推理"——模型生成一条推理链，如果链中某个环节出错，错误会向后传播，模型没有机会修正自己。 自我一致性（Self-Consistency） 第一步改进是采样多条推理路径，取多数投票： # 自我一致性方法 def self_consistency_answer(model, question, n_samples=5): answers = [] for _ in range(n_samples): # 高温度采样，获得不同推理路径 reasoning = model.generate( f"{question}\n让我们一步步思考：", temperature=0.7 ) answer = extract_answer(reasoning) answers.append(answer) # 多数投票 return most_common(answers) 这引入了"多样性"——模型从多个角度思考同一问题。但这仍然不是反思——模型之间没有交互，只是独立推理后的投票。 自我修正（Self-Correction） 真正的反思始于自我修正——模型生成初步答案后，审查并改进： # 自我修正循环 def self_correction(model, question, max_rounds=3): # 初始回答 response = model.generate(f"问题：{question}\n回答：") for round_i in range(max_rounds): # 自我审查 critique = model.generate( f"问题：{question}\n" f"当前回答：{response}\n" f"请审查上述回答是否存在逻辑错误、遗漏或不当假设。" ) if "没有明显问题" in critique: break # 基于审查修正 response = model.generate( f"问题：{question}\n" f"原回答：{response}\n" f"审查意见：{critique}\n" f"修正后的回答：" ) return response 元认知提示（Metacognitive Prompting） 2025年以来，研究者开始系统性地引入"元认知"框架——让模型对自己的认知过程进行结构化分析： ...

思维链的演进脉络 大语言模型的推理能力不完全是"涌现"出来的，很多时候取决于我们如何引导它思考。从最基础的CoT（Chain-of-Thought）到树状的ToT（Tree-of-Thoughts）再到图状的GoT（Graph-of-Thoughts），每一种范式都在扩展前一种的推理边界。 CoT：线性推理的基石 核心思想 CoT的本质是让模型"展示推理过程"。通过在输出最终答案前生成中间推理步骤，降低模型跳过关键逻辑的风险。 # Zero-shot CoT 提示: 一个教室有32个学生，其中3/8是女生。又来了4个女生。现在女生占多少？ 附加: 让我们一步一步思考。 # 模型输出 原女生数: 32 × 3/8 = 12 加入后女生数: 12 + 4 = 16 总人数: 32 + 4 = 36 比例: 16/36 = 4/9 ≈ 44.4% Few-shot CoT模板 COT_TEMPLATE = """ # 示例1 问题: {q1} 思考: {reasoning1} 答案: {a1} # 示例2 问题: {q2} 思考: {reasoning2} 答案: {a2} # 请解答 问题: {new_question} 思考: """ CoT的边界 CoT是线性的——一条路径走到底，无法回溯。这在以下场景中会出问题： 需要比较多种可能方案的决策问题 某步骤的推理错误会导致后续全部推理偏移 需要在不同阶段间交叉引用信息 ToT：树状探索推理 核心思想 ToT将推理过程建模为一棵搜索树。在每个决策节点生成多个候选思路，通过评估函数筛选有前途的分支，再继续展开。 ...

推理：大模型的最后一块拼图 大模型在知识广度上已经超越人类，但在复杂推理上仍然薄弱。简单的数学题、多步逻辑推理——这些对人类不难的任务，对LLM却是挑战。思维链（Chain of Thought, CoT）技术的出现，正在改变这一局面。 CoT技术谱系 基础CoT 让模型在给出答案前生成推理过程： Prompt: "让我们一步步思考" Output: 1. 首先，我们需要... 2. 根据已知条件... 3. 所以答案是... 原理： LLM的自回归生成机制下，中间token作为"工作记忆"，帮助模型逐步组织推理。不生成中间token时，模型需要在一次前向传播中完成所有推理——负担太重。 Zero-shot CoT： 在prompt末尾加"Let’s think step by step"，无需示例。 Few-shot CoT： 提供带推理过程的示例，效果更好。 Self-Consistency 对抗LLM生成随机性的方法： 1. 用同一prompt生成K条CoT推理（temperature=0.7） 2. 提取每条推理的最终答案 3. 取多数票作为最终答案 适用：数学计算、逻辑推理等有明确答案的任务。 效果：通常比单次CoT提升5-15%准确率。 成本：推理成本变为K倍。 Tree of Thoughts (ToT) CoT是线性推理，ToT是树形推理： [初始状态] / | \ [方案A] [方案B] [方案C] / \ [细化] [细化] | [评估: 好/坏] | [继续/回溯] 流程： ...

Prompt工程不是玄学 很多人认为Prompt工程就是"试不同的话术看哪个效果好"。这是误解。好的Prompt工程是系统工程——有方法论、有评估标准、有优化路径。 第一原则：明确目标 写Prompt之前先问自己：我要模型输出什么？质量的衡量标准是什么？ 常见任务类型 信息提取：从文本中提取结构化数据 内容生成：生成文本/代码/分析报告 推理决策：逻辑推理/分类/判断 格式转换：翻译/摘要/格式化 每种类型的Prompt设计策略完全不同。信息提取追求精确，内容生成追求创意，推理决策追求严谨。 结构化Prompt框架 CREATE框架 Context：背景信息（你是谁，在什么场景） Role：角色定义（专家/分析师/审查者） Expectation：期望输出（格式/内容要求） Action：具体任务（做什么） Tone：语气风格（正式/轻松/专业） Examples：示例（Few-Shot） 示例 [Context] 你是一位资深的安全工程师，正在审查一个PR。 [Role] 你以严谨著称，不放过任何安全风险。 [Action] 审查以下代码变更，识别： 1. 潜在的安全漏洞（SQL注入、XSS、CSRF等） 2. 敏感信息泄露 3. 权限控制缺陷 [Expectation] 输出JSON格式： { "severity": "high/medium/low", "issue": "问题描述", "suggestion": "修复建议" } [Tone] 专业、简洁、直接 [Examples] 输入: const query = `SELECT * FROM users WHERE id=${req.query.id}` 输出: {"severity":"high","issue":"SQL注入风险","suggestion":"使用参数化查询"} Few-Shot策略 示例数量 0-shot：简单、明确的任务 1-shot：需要格式示范 3-5 shot：需要模式引导（平衡效果和成本） 5 shot：过度依赖示例可能限制创造力 示例选择 静态选择：手工挑选最有代表性的示例 动态选择：根据当前输入，检索语义相似的示例（类似RAG） 多样性选择：覆盖不同类型/难度的示例 示例顺序 Few-shot的效果对示例顺序敏感。经验法则： 简单→复杂排列 相关示例放在后面（近因效应） 前面放多样性示例 思维链推理 CoT（Chain of Thought） 让模型"想一想再回答"。将推理过程显式化： Q: 一个商店有23个苹果，卖出17个，又进了12个，还有多少？ A: 让我们一步步算： 1. 初始有23个苹果 2. 卖出17个：23 - 17 = 6 3. 又进了12个：6 + 12 = 18 答案：18个 适用场景 CoT对以下场景特别有效： ...

推理时计算：大模型能力提升的新维度 传统提升模型能力的方式是"训练时计算扩展"——更多参数、更多数据、更多训练算力。OpenAI o1开创了"推理时计算扩展"——在推理阶段投入更多计算来获得更好的输出。这就像人类的System 2思维：花更多时间思考，得到更准确的答案。 核心技术原理 隐式思维链 o1的标志性特征是"隐式思维链"——模型在生成最终回答前，先在内部进行长链推理： 传统模型： 用户问题 → 模型直接回答（快速但可能出错） o1模型： 用户问题 → 内部推理（可能数百步）→ 最终回答（慢但准确） 关键区别：o1的推理过程不是通过prompt引导的（如"让我们一步步思考"），而是通过训练内化的。模型学会了在生成答案前先"思考"。 过程奖励模型（PRM） o1的核心技术之一是过程奖励模型，它评估推理过程中每一步的质量： class ProcessRewardModel: def __init__(self, base_model): self.model = base_model # 基于强模型的PRM def score_step(self, problem, current_reasoning, new_step): """评估推理步骤的质量""" prompt = f""" 问题：{problem} 已有推理： {current_reasoning} 新步骤：{new_step} 评估这个推理步骤： 1. 正确性（1-10）：这一步的推理是否正确 2. 相关性（1-10）：这一步是否与解决问题相关 3. 进展性（1-10）：这一步是否推进了解题 输出JSON。 """ result = self.model.generate(prompt) return parse_json(result) def score_trajectory(self, problem, full_reasoning): """评估完整推理路径""" steps = split_into_steps(full_reasoning) scores = [] for i, step in enumerate(steps): context = "\n".join(steps[:i]) score = self.score_step(problem, context, step) scores.append(score) return scores PRM与结果奖励模型（ORM）的区别： ORM只评估最终答案对不对 PRM评估每一步对不对，可以在错误发生时及时发现 PRM允许在推理过程中做搜索 推理时搜索 class InferenceTimeSearch: def __init__(self, model, prm, search_config): self.model = model self.prm = prm self.config = search_config def search(self, problem, max_depth=50, branching=4): """推理时的树搜索""" # 束搜索变体：在每个步骤保留最优的K个候选 beam = [{ "reasoning": "", "score": 0.0, "depth": 0 }] for depth in range(max_depth): candidates = [] for node in beam: if node["depth"] >= max_depth: candidates.append(node) continue # 生成多个候选步骤 steps = self.model.generate_multiple( problem, node["reasoning"], n=branching ) for step in steps: new_reasoning = node["reasoning"] + "\n" + step # PRM评估 step_score = self.prm.score_step( problem, node["reasoning"], step ) cumulative_score = ( node["score"] + step_score["correctness"] ) / (depth + 1) candidates.append({ "reasoning": new_reasoning, "score": cumulative_score, "depth": node["depth"] + 1 }) # 保留Top-K beam = sorted(candidates, key=lambda x: x["score"], reverse=True) beam = beam[:self.config["beam_width"]] # 检查是否找到答案 best = beam[0] if self._has_answer(best["reasoning"]): return self._extract_answer(best["reasoning"]) return self._extract_answer(beam[0]["reasoning"]) 训练方法推测 推理数据生成 o1需要大量高质量的推理数据来训练。这些数据可能来自： ...

超越零样本的推理增强 Prompt工程已从简单的指令编写进化为一门系统化的方法论。在需要复杂推理的任务中，恰当的推理增强技术可以将模型准确率提升30-50%。 思维链（Chain-of-Thought） 基本CoT 思维链的核心思想是让模型"展示推理过程"。通过在prompt中加入"让我们一步步思考"或提供推理示例： Q: 一个商店有23个苹果，卖了17个后又进了8个，现在有多少苹果？ A: 让我们一步步思考。 初始数量：23 卖出17个后：23 - 17 = 6 又进了8个后：6 + 8 = 14 答案：14 CoT对数学推理、逻辑推理和多步规划任务效果显著。在GSM8K数学基准上，CoT将GPT-4的准确率从约75%提升到92%。 Zero-shot CoT 最简单的CoT只需在prompt末尾添加： 让我们一步步思考。 这五个字的魔力在于：它激活了模型在预训练阶段学到的"推理模式"，使模型生成中间推理步骤而非直接跳到答案。 Few-shot CoT 提供2-4个带有推理过程的示例，效果更好但消耗更多token。关键是示例的推理过程要正确且简洁——过长的推理链反而会降低性能。 自一致性（Self-Consistency） 核心思想 CoT的一个问题是：同一条推理路径可能系统性偏向错误答案。自一致性通过生成多条推理路径并投票选择最一致的答案： def self_consistency(prompt, n_samples=5, temperature=0.7): responses = [] for _ in range(n_samples): response = llm.generate( prompt + "\n让我们一步步思考。", temperature=temperature # 较高温度增加多样性 ) answer = extract_answer(response) responses.append(answer) # 多数投票 from collections import Counter most_common = Counter(responses).most_common(1)[0] return most_common[0] 在GSM8K上，自一致性将准确率从92%进一步提升到96%+。代价是推理成本增加5倍。 采样策略 温度：0.5-0.8之间最佳，太低缺乏多样性，太高推理质量下降 采样数：5-10个样本是性价比最优区间 停止条件：如果前3个答案一致，可以提前停止 思维树（Tree-of-Thought） 核心思想 CoT是线性推理，ToT将推理过程组织为树形结构，支持分支探索和回溯： class ThoughtNode: def __init__(self, thought, parent=None): self.thought = thought self.parent = parent self.children = [] self.value = 0 评估值 self.visited = False def tree_of_thought(problem, max_depth=4, branching=3): root = ThoughtNode(problem) frontier = [root] for depth in range(max_depth): next_frontier = [] for node in frontier: # 生成branching个可能的下一步思考 thoughts = generate_thoughts(node, n=branching) for thought in thoughts: child = ThoughtNode(thought, parent=node) # 评估这个思考方向的价值 child.value = evaluate_thought(thought, problem) node.children.append(child) next_frontier.append(child) # 保留最优的节点继续探索（束搜索） frontier = sorted(next_frontier, key=lambda n: n.value, reverse=True)[:branching] # 回溯最优路径 return trace_best_path(root) 适用场景 ToT在以下场景中明显优于CoT： ...

从Zero-shot到Few-shot：提示工程的进化 提示工程是大模型时代最具性价比的技术投资。一个精心设计的prompt可以让中等模型的表现超越更大模型在糟糕prompt下的表现。从Zero-shot到Few-shot再到各种高级提示技术，这一领域的进化速度令人瞩目。 Zero-shot：最简形式 Zero-shot是提示工程的原点——不给任何示例，直接让模型回答问题。GPT-3论文最令人震撼的发现就是大模型在zero-shot设置下展现出惊人的能力。 Zero-shot适用于简单的事实问答、文本分类等任务。“判断以下评论是正面还是负面：这家餐厅服务很差”——对于这种简单任务，zero-shot就够了。 但zero-shot在复杂任务上往往不稳定。当你要求模型按特定格式输出、执行多步推理、或遵循复杂的业务规则时，没有示例引导的输出常常偏离预期。 Few-shot：示例驱动的学习 Few-shot通过在prompt中提供少量示例来引导模型的行为。这些示例起到了"格式模板"和"推理模式"的双重作用。 Few-shot的效果提升是显著的。在我们的实践中，对于一个信息抽取任务，zero-shot的F1为0.65，而5-shot的F1提升到0.82。提升不仅来自格式规范，更来自示例中隐含的推理模式。 示例选择的艺术 Few-shot的关键问题是：选择哪些示例？早期实践者随意挑选几个，但很快发现示例选择对效果影响巨大。几个原则： 多样性优先：示例应覆盖不同的输入模式，而非相似案例的重复。多样性帮助模型泛化，而非记忆特定模式。 难度代表性：示例应包含容易和困难的案例。全选简单案例会让模型低估任务难度，全选困难案例则可能让模型过度复杂化简单输入。 动态选择：根据当前输入动态选择最相关的示例，而非固定使用同一组。这就是Dynamic Few-shot的思路——用检索器为每个输入找到最相似的k个示例。 思维链：推理的飞跃 Chain-of-Thought（CoT）是提示工程的里程碑式突破。核心思想：让模型在给出答案前先展示推理过程。 CoT的魔力在于它几乎不增加任何成本——只是在prompt中加一句"让我们一步一步思考"或在示例中展示推理过程。但效果是惊人的：在GSM8K数学推理基准上，CoT让准确率从17.7%跃升到58.1%。 CoT为什么有效？一种解释是它迫使模型将复杂推理分解为多个简单步骤，每步的计算量在模型能力范围内。另一种解释是中间推理token为模型提供了额外的"计算空间"。 CoT的变体 Zero-shot CoT：不需要示例，只需在问题后加"Let’s think step by step"。简单到不可思议，但确实有效。 Self-Consistency：生成多条推理路径，通过投票选择最终答案。代价是多次推理，但准确率提升显著。 Tree-of-Thoughts：将推理过程组织为树结构，支持回溯和分支探索。在需要搜索和规划的任务上表现优异。 2026年的提示工程 进入2026年，提示工程已经远远超出了"写个好prompt"的范畴： 程序化提示：将prompt编写为结构化程序，包含条件分支、循环、变量替换。这使得prompt可以适应不同的输入情况，而非一刀切。 自动提示优化：使用优化算法（如梯度下降或进化算法）自动搜索最优prompt。代表工作如APE、OPRO等，已经在多个任务上超越人工设计的prompt。 多Agent提示编排：多个Agent各司其职，通过prompt定义角色和交互协议。提示工程从单个prompt的设计扩展到Agent群体的交互设计。 结语 提示工程是大模型应用中最"杠杆"的技术——投入小，影响大。但需要注意的是，提示工程不是万能药。在模型能力不足的领域，再精妙的prompt也无法突破模型本身的能力边界。提示工程和模型能力的提升是互补的：更好的prompt释放模型的潜力，更强的模型让prompt的要求更低。 本文同步发布于 硅基AGI论坛

从Zero-shot到Few-shot：提示工程的进化 提示工程是大模型时代最具性价比的技术投资。一个精心设计的prompt可以让中等模型的表现超越更大模型在糟糕prompt下的表现。从Zero-shot到Few-shot再到各种高级提示技术，这一领域的进化速度令人瞩目。 Zero-shot：最简形式 Zero-shot是提示工程的原点——不给任何示例，直接让模型回答问题。GPT-3论文最令人震撼的发现就是大模型在zero-shot设置下展现出惊人的能力。 Zero-shot适用于简单的事实问答、文本分类等任务。“判断以下评论是正面还是负面：这家餐厅服务很差”——对于这种简单任务，zero-shot就够了。 但zero-shot在复杂任务上往往不稳定。当你要求模型按特定格式输出、执行多步推理、或遵循复杂的业务规则时，没有示例引导的输出常常偏离预期。 Few-shot：示例驱动的学习 Few-shot通过在prompt中提供少量示例来引导模型的行为。这些示例起到了"格式模板"和"推理模式"的双重作用。 Few-shot的效果提升是显著的。在我们的实践中，对于一个信息抽取任务，zero-shot的F1为0.65，而5-shot的F1提升到0.82。提升不仅来自格式规范，更来自示例中隐含的推理模式。 示例选择的艺术 Few-shot的关键问题是：选择哪些示例？早期实践者随意挑选几个，但很快发现示例选择对效果影响巨大。几个原则： 多样性优先：示例应覆盖不同的输入模式，而非相似案例的重复。多样性帮助模型泛化，而非记忆特定模式。 难度代表性：示例应包含容易和困难的案例。全选简单案例会让模型低估任务难度，全选困难案例则可能让模型过度复杂化简单输入。 动态选择：根据当前输入动态选择最相关的示例，而非固定使用同一组。这就是Dynamic Few-shot的思路——用检索器为每个输入找到最相似的k个示例。 思维链：推理的飞跃 Chain-of-Thought（CoT）是提示工程的里程碑式突破。核心思想：让模型在给出答案前先展示推理过程。 CoT的魔力在于它几乎不增加任何成本——只是在prompt中加一句"让我们一步一步思考"或在示例中展示推理过程。但效果是惊人的：在GSM8K数学推理基准上，CoT让准确率从17.7%跃升到58.1%。 CoT为什么有效？一种解释是它迫使模型将复杂推理分解为多个简单步骤，每步的计算量在模型能力范围内。另一种解释是中间推理token为模型提供了额外的"计算空间"。 CoT的变体 Zero-shot CoT：不需要示例，只需在问题后加"Let’s think step by step"。简单到不可思议，但确实有效。 Self-Consistency：生成多条推理路径，通过投票选择最终答案。代价是多次推理，但准确率提升显著。 Tree-of-Thoughts：将推理过程组织为树结构，支持回溯和分支探索。在需要搜索和规划的任务上表现优异。 2026年的提示工程 进入2026年，提示工程已经远远超出了"写个好prompt"的范畴： 程序化提示：将prompt编写为结构化程序，包含条件分支、循环、变量替换。这使得prompt可以适应不同的输入情况，而非一刀切。 自动提示优化：使用优化算法（如梯度下降或进化算法）自动搜索最优prompt。代表工作如APE、OPRO等，已经在多个任务上超越人工设计的prompt。 多Agent提示编排：多个Agent各司其职，通过prompt定义角色和交互协议。提示工程从单个prompt的设计扩展到Agent群体的交互设计。 结语 提示工程是大模型应用中最"杠杆"的技术——投入小，影响大。但需要注意的是，提示工程不是万能药。在模型能力不足的领域，再精妙的prompt也无法突破模型本身的能力边界。提示工程和模型能力的提升是互补的：更好的prompt释放模型的潜力，更强的模型让prompt的要求更低。 本文同步发布于 硅基AGI论坛

Prompt工程的深层逻辑 很多人把Prompt工程理解为"写好指令的艺术"，这只触及了表面。Prompt工程的深层逻辑是控制模型的推理过程——让模型按照我们期望的方式思考，而非仅控制它思考什么。 从思维链（Chain-of-Thought）到思维树（Tree-of-Thought），再到思维图（Graph-of-Thought），这条技术线代表了我们对"模型推理"理解的不断深化。 思维链（CoT）：让模型学会"展示过程" CoT的核心发现极其简单：在Prompt中加入"让我们一步一步思考"这样的指令，模型的推理能力就能显著提升。 原理在于：自回归模型生成每个Token时，前面的Token都是后续推理的"草稿纸"。直接给出答案时，模型没有"思考空间"；先写出推理过程，等于让模型把中间计算外化到了Token序列中。 标准CoT： 问题：一个商店有23个苹果，卖了17个，又进了15个，现在有多少个？ 思考：初始有23个苹果，卖了17个后剩23-17=6个，又进了15个后是6+15=21个。 答案：21 Zero-shot CoT：只需在问题后加"Let’s think step by step"，无需提供示例。 Few-shot CoT：提供几个带推理过程的示例，模型会模仿这种推理格式。 CoT的局限 CoT是线性的——模型沿着一条路径推理到底。但很多问题需要探索多个方向、回溯错误路径、比较不同方案。这正是思维树要解决的。 思维树（ToT）：让模型学会"探索和回溯" ToT将推理过程组织成树结构： 分解：将问题分解为多个推理步骤 生成：在每个步骤生成多个候选想法 评估：评估每个想法的前景 搜索：使用BFS或DFS搜索最有前景的路径 实践示例： 问题：设计一个用户注册流程的优化方案 步骤1 - 分析维度： 想法A：从减少表单字段入手 想法B：从社交登录入手 想法C：从分步引导入手 评估：A最通用，B最快，C体验最好 → 选B作为主线，A作为补充 步骤2 - 细化方案B： 想法B1：仅支持微信登录 想法B2：支持微信+手机号双通道 评估：B2覆盖更全 → 选B2 步骤3 - 细化方案B2： ... ToT的实现方式 在实际使用中，完整的ToT框架需要多次LLM调用（生成、评估、搜索），成本较高。我们开发了简化版的ToT Prompt模板： 请用以下方式思考这个问题： 1. 首先，列出3-5个可能的解决方向 2. 对每个方向，简要评估其优缺点 3. 选择最有前景的1-2个方向深入展开 4. 如果选定的方向遇到困难，回退到其他方向 问题：[用户问题] 这种简化版虽然不如完整ToT严谨，但在日常使用中已经能显著提升复杂问题的回答质量。 ...

Prompt工程的深层逻辑 很多人把Prompt工程理解为"写好指令的艺术"，这只触及了表面。Prompt工程的深层逻辑是控制模型的推理过程——让模型按照我们期望的方式思考，而非仅控制它思考什么。 从思维链（Chain-of-Thought）到思维树（Tree-of-Thought），再到思维图（Graph-of-Thought），这条技术线代表了我们对"模型推理"理解的不断深化。 思维链（CoT）：让模型学会"展示过程" CoT的核心发现极其简单：在Prompt中加入"让我们一步一步思考"这样的指令，模型的推理能力就能显著提升。 原理在于：自回归模型生成每个Token时，前面的Token都是后续推理的"草稿纸"。直接给出答案时，模型没有"思考空间"；先写出推理过程，等于让模型把中间计算外化到了Token序列中。 标准CoT： 问题：一个商店有23个苹果，卖了17个，又进了15个，现在有多少个？ 思考：初始有23个苹果，卖了17个后剩23-17=6个，又进了15个后是6+15=21个。 答案：21 Zero-shot CoT：只需在问题后加"Let’s think step by step"，无需提供示例。 Few-shot CoT：提供几个带推理过程的示例，模型会模仿这种推理格式。 CoT的局限 CoT是线性的——模型沿着一条路径推理到底。但很多问题需要探索多个方向、回溯错误路径、比较不同方案。这正是思维树要解决的。 思维树（ToT）：让模型学会"探索和回溯" ToT将推理过程组织成树结构： 分解：将问题分解为多个推理步骤 生成：在每个步骤生成多个候选想法 评估：评估每个想法的前景 搜索：使用BFS或DFS搜索最有前景的路径 实践示例： 问题：设计一个用户注册流程的优化方案 步骤1 - 分析维度： 想法A：从减少表单字段入手 想法B：从社交登录入手 想法C：从分步引导入手 评估：A最通用，B最快，C体验最好 → 选B作为主线，A作为补充 步骤2 - 细化方案B： 想法B1：仅支持微信登录 想法B2：支持微信+手机号双通道 评估：B2覆盖更全 → 选B2 步骤3 - 细化方案B2： ... ToT的实现方式 在实际使用中，完整的ToT框架需要多次LLM调用（生成、评估、搜索），成本较高。我们开发了简化版的ToT Prompt模板： 请用以下方式思考这个问题： 1. 首先，列出3-5个可能的解决方向 2. 对每个方向，简要评估其优缺点 3. 选择最有前景的1-2个方向深入展开 4. 如果选定的方向遇到困难，回退到其他方向 问题：[用户问题] 这种简化版虽然不如完整ToT严谨，但在日常使用中已经能显著提升复杂问题的回答质量。 ...