尧图网站建设 
Chain-of-Thought 提示工程实战指南从 Zero-Shot 到 Tree-of-Thought 的可复现推理方案【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents导读Chain-of-ThoughtCoT思维链提示是一种让大语言模型LLM显式输出中间推理步骤的技术能够显著提升模型在复杂数学、逻辑推理和多步规划任务上的表现。本文以 agents24 仓库中 prompt-engineering-patterns 技能 的 chain-of-thought 参考文档 为骨架结合同技能下的 few-shot 学习、提示词优化脚本与模板库源码系统讲解 Zero-Shot CoT、Few-Shot CoT、Self-Consistency、Least-to-Most、Tree-of-Thought 等主流变体并给出数学、代码调试、逻辑推理三大领域的可直接套用的模板、性能优化手段与质量评估指标。读完本文你将掌握一套可在生产 LLM 应用中落地、可验证、可量化的推理提示工程方案。一、什么是 Chain-of-Thought PromptingChain-of-Thought 的核心思想是不要求模型直接给出答案而是先引导它逐步写出推理过程再基于推理过程得出最终结论。其底层动机在于LLM 在隐式跳跃推理时更容易出错而把中间步骤显式化可以让模型把速度换精度把复杂计算拆解为可追踪的中间结果使错误的定位成为可能——推理链可被人工或程序逐行核查让show your work式的输出天然具备可审计性。该技术在本仓库 prompt-engineering-patterns 技能中属于Core Capabilities的第二大能力文档明确列出了其覆盖的子技术Zero-Shot CoTLets think step by step、Few-Shot CoT带推理痕迹的示例、Self-Consistency多次采样推理路径以及验证Verification步骤。适用与不适用的边界源自原文档 When to Use CoT推荐使用 CoT建议跳过 CoT数学与算术问题简单事实性查询逻辑推理任务直接查表/检索多步规划创意写作代码生成与调试需要简洁输出的任务复杂决策实时、延迟敏感的应用判断要点只有当过程本身承载信息量时CoT 才有价值。简单的 11 不需要推理链而分阶段规划一个多智能体协作流程则必须显式推理。二、基础技术Zero-Shot CoT 与 Few-Shot CoT2.1 Zero-Shot CoT一行触发词Zero-Shot CoT 是最轻量的变体——不提供任何示例只在问题后追加一句触发短语即可。def zero_shot_cot(query): return f{query} Lets think step by step: # Example query If a train travels 60 mph for 2.5 hours, how far does it go? prompt zero_shot_cot(query) # Model output: # Lets think step by step: # 1. Speed 60 miles per hour # 2. Time 2.5 hours # 3. Distance Speed × Time # 4. Distance 60 × 2.5 150 miles # Answer: 150 miles这一模式在本仓库的 优化脚本 中也被视为一种可自动生成的提示变体generate_variations中的 Variation 2 即为Lets solve this step by step.\n\n prompt说明它已被纳入工程化的提示优化流程而不仅仅是学术技巧。2.2 Few-Shot CoT用带推理痕迹的示例做示范Few-Shot CoT 在 Zero-Shot 基础上进一步提供问题 → 分步推理 → 答案的完整示例让模型模仿示例中的推理风格。原文档给出了经典的数学应用题示例few_shot_examples Q: Roger has 5 tennis balls. He buys 2 more cans of tennis balls. Each can has 3 balls. How many tennis balls does he have now? A: Lets think step by step: 1. Roger starts with 5 balls 2. He buys 2 cans, each with 3 balls 3. Balls from cans: 2 × 3 6 balls 4. Total: 5 6 11 balls Answer: 11 Q: The cafeteria had 23 apples. If they used 20 to make lunch and bought 6 more, how many do they have? A: Lets think step by step: 1. Started with 23 apples 2. Used 20 for lunch: 23 - 20 3 apples left 3. Bought 6 more: 3 6 9 apples Answer: 9 Q: {user_query} A: Lets think step by step:示例构建的三个关键纪律与同技能下 few-shot-learning.md 的Example Construction Best Practices完全一致格式一致性所有示例必须使用完全相同的格式Q:/A:、缩进、编号规则不一致的格式会直接污染模型对输出格式的认知输入输出对齐示例必须精确示范目标任务本身避免问题与答案关系模糊的反例难度梯度示例难度应覆盖简单、中等、复杂三档让模型学会从易到难地组织推理。若要动态挑选最相关的示例可参考该参考文档提供的 SemanticExampleSelector 实现用 embedding 余弦相似度选取与当前查询最接近的示例注入提示。三、Self-Consistency用投票对冲单条推理链的风险单条推理链可能因一步走错而全盘皆错。Self-Consistency 的思路是同一个问题采样 n 条推理路径对最终答案做多数投票并给出置信度。原文档给出的核心实现import openai from collections import Counter def self_consistency_cot(query, n5, temperature0.7): prompt f{query}\n\nLets think step by step: responses [] for _ in range(n): response openai.ChatCompletion.create( modelgpt-5.4, messages[{role: user, content: prompt}], temperaturetemperature ) responses.append(extract_final_answer(response)) # Take majority vote answer_counts Counter(responses) final_answer answer_counts.most_common(1)[0][0] return { answer: final_answer, confidence: answer_counts[final_answer] / n, all_responses: responses }参数作用与取值建议参数含义典型取值影响n采样条数310越大投票越稳但成本与延迟线性上升temperature采样随机性0.50.8过低导致路径趋同、失去投票意义过高引入噪声extract_final_answer从推理链中抽取最终答案—依赖稳定的输出格式建议在提示中明确 Answer: 前缀confidence出现最多的答案占比本身就是一个非常有用的副产品当confidence偏低时说明模型对答案缺乏共识此时应当触发人工介入或降级策略。这与本仓库 details.md 中置信度分级 降级回退的错误恢复模式ResponseWithConfidence思路一脉相承。四、进阶模式Least-to-Most 与 Tree-of-Thought4.1 Least-to-Most Prompting先拆解再逐个子问题求解Least-to-Most 分三个阶段工作拆解Decomposition→ 顺序求解Sequential Solving→ 最终整合Final Integration。每个子问题的解都会作为上下文拼接进下一个子问题的提示中形成脚手架式推理def least_to_most_prompt(complex_query): # Stage 1: Decomposition decomp_prompt fBreak down this complex problem into simpler subproblems: Problem: {complex_query} Subproblems: subproblems get_llm_response(decomp_prompt) # Stage 2: Sequential solving solutions [] context for subproblem in subproblems: solve_prompt f{context} Solve this subproblem: {subproblem} Solution: solution get_llm_response(solve_prompt) solutions.append(solution) context f\n\nPreviously solved: {subproblem}\nSolution: {solution} # Stage 3: Final integration final_prompt fGiven these solutions to subproblems: {context} Provide the final answer to: {complex_query} Final Answer: return get_llm_response(final_prompt)从源码结构看本技能参考文档中的 StatefulTemplate 与 Least-to-Most 是天然互补的前者维护init → processing → complete的多步状态模板可以把逐步求解的状态管理工程化避免每一步提示手工拼接。4.2 Tree-of-Thought (ToT)分支探索 启发式评分当问题存在多条可行路径如规划、谜题、推理题时ToT 把推理建模为一棵搜索树每一步生成多个候选思维用评分函数评估各分支择优继续深入。原文档给出了一个可运行的骨架class TreeOfThought: def __init__(self, llm_client, max_depth3, branches_per_step3): self.client llm_client self.max_depth max_depth self.branches_per_step branches_per_step def solve(self, problem): # Generate initial thought branches initial_thoughts self.generate_thoughts(problem, depth0) # Evaluate each branch best_path None best_score -1 for thought in initial_thoughts: path, score self.explore_branch(problem, thought, depth1) if score best_score: best_score score best_path path return best_path def generate_thoughts(self, problem, context, depth0): prompt fProblem: {problem} {context} Generate {self.branches_per_step} different next steps in solving this problem: 1. response self.client.complete(prompt) return self.parse_thoughts(response) def evaluate_thought(self, problem, thought_path): prompt fProblem: {problem} Reasoning path so far: {thought_path} Rate this reasoning path from 0-10 for: - Correctness - Likelihood of reaching solution - Logical coherence Score: return float(self.client.complete(prompt))关键设计决策branches_per_step控制每层的分支数典型 24过大易发散且显著增加 token 消耗max_depth控制搜索深度需要与问题复杂度匹配评分维度Correctness / Likelihood / Logical coherence本身就是一份推理质量 rubric建议在真实落地时让评分模型输出分数 理由便于追溯为什么选中某条分支。五、验证步骤让推理链可纠错CoT 的一个常见风险是推理过程看起来很顺但结果错误。显式加入验证环节Verification Step可以显著提升最终正确率。原文档的实现分三步先生成推理与答案再要求模型逐项核查逻辑错误、算术、合理性最后在发现错误时要求修正def cot_with_verification(query): # Step 1: Generate reasoning and answer reasoning_prompt f{query} Lets solve this step by step: reasoning_response get_llm_response(reasoning_prompt) # Step 2: Verify the reasoning verification_prompt fOriginal problem: {query} Proposed solution: {reasoning_response} Verify this solution by: 1. Checking each step for logical errors 2. Verifying arithmetic calculations 3. Ensuring the final answer makes sense Is this solution correct? If not, whats wrong? Verification: verification get_llm_response(verification_prompt) # Step 3: Revise if needed if incorrect in verification.lower() or error in verification.lower(): revision_prompt fThe previous solution had errors: {verification} Please provide a corrected solution to: {query} Corrected solution: return get_llm_response(revision_prompt) return reasoning_response在本仓库 details.md 中CoT 自验证被工程化为更结构化的提示模板明确要求模型按## Steps、## Answer、## Verification三段式输出把验证固化为输出格式的一部分prompt-optimization.md 的失败分析章节同样建议当出现逻辑类错误时追加Before responding, verify your answer is logically consistent指令——验证步骤因此既是运行时纠错机制也是提示迭代的修复手段。六、领域专用模板数学、代码调试与逻辑推理原文档为三个高价值领域各提供了一套带占位符的模板可直接参数化复用。6.1 数学问题模板math_cot_template Problem: {problem} Solution: Step 1: Identify what we know - {list_known_values} Step 2: Identify what we need to find - {target_variable} Step 3: Choose relevant formulas - {formulas} Step 4: Substitute values - {substitution} Step 5: Calculate - {calculation} Step 6: Verify and state answer - {verification} Answer: {final_answer} 该模板的六步结构与原文档 Best Practices 中的Show All Work、Verify Calculations、State Assumptions一一对应适合用于需要完整解题过程的评测或教学场景。6.2 代码调试模板debug_cot_template Code with error: {code} Error message: {error} Debugging process: Step 1: Understand the error message - {interpret_error} Step 2: Locate the problematic line - {identify_line} Step 3: Analyze why this line fails - {root_cause} Step 4: Determine the fix - {proposed_fix} Step 5: Verify the fix addresses the error - {verification} Fixed code: {corrected_code} 模板把读报错 → 定位 → 根因 → 修复 → 验证五步流程显式化恰好契合 CoT 对过程可审计的要求。在本仓库的 agent 生态中这类模板可直接服务于 debugger 类 agent 的推理环节。6.3 逻辑推理模板logic_cot_template Premises: {premises} Question: {question} Reasoning: Step 1: List all given facts {facts} Step 2: Identify logical relationships {relationships} Step 3: Apply deductive reasoning {deductions} Step 4: Draw conclusion {conclusion} Answer: {final_answer} 逻辑推理模板强调前提 → 事实列举 → 关系识别 → 演绎 → 结论的链式结构对防止用结论反证前提的循环逻辑原文档 Common Pitfalls 之一有直接约束作用。七、性能优化缓存与自适应推理深度7.1 推理缓存Reasoning Cache对语义相近的重复问题可以缓存历史推理链命中后直接复用。原文档给出的实现基于 embedding 余弦相似度class ReasoningCache: def __init__(self): self.cache {} def get_similar_reasoning(self, problem, threshold0.85): problem_embedding embed(problem) for cached_problem, reasoning in self.cache.items(): similarity cosine_similarity( problem_embedding, embed(cached_problem) ) if similarity threshold: return reasoning return None def add_reasoning(self, problem, reasoning): self.cache[problem] reasoningthreshold典型 0.80.9需要在缓存命中率与误复用错误推理之间权衡。这一思路与本仓库 prompt-templates.md 的CachedTemplate、以及 details.md 中对重复使用的 system prompt 启用 prompt caching的策略互为补充前者缓存推理结果后者缓存固定前缀两者共同压低延迟与成本。7.2 自适应推理深度Adaptive Reasoning Depth不同问题需要的推理步数差异很大。原文档提供了从浅到深、按需加深的自适应策略def adaptive_cot(problem, initial_depth3): depth initial_depth while depth 10: # Max depth response generate_cot(problem, num_stepsdepth) # Check if solution seems complete if is_solution_complete(response): return response depth 2 # Increase reasoning depth return response # Return best attemptis_solution_complete通常可通过启发式规则是否出现最终答案、是否覆盖全部子问题或轻量评分模型实现。这种渐进加深与 details.md 的 Progressive Disclosure四级递进直接指令 → 加约束 → 加推理 → 加示例在设计哲学上完全一致——从简单开始仅在必要时增加复杂度。八、质量评估如何度量一条推理链的好坏CoT 不是加了提示词就算成功必须用量化指标验证收益。原文档给出了五维评估框架def evaluate_cot_quality(reasoning_chain): metrics { coherence: measure_logical_coherence(reasoning_chain), completeness: check_all_steps_present(reasoning_chain), correctness: verify_final_answer(reasoning_chain), efficiency: count_unnecessary_steps(reasoning_chain), clarity: rate_explanation_clarity(reasoning_chain) } return metrics指标考察内容建议实现方式coherence步骤之间逻辑连贯用 LLM 评分或检查步骤间引用关系completeness是否覆盖全部必要步骤对照问题要素做 checklist 匹配correctness最终答案正确性与 ground truth 精确/模糊匹配efficiency是否有多余步骤统计非必要步骤占比clarity解释是否清晰LLM 评分或人工抽样在工程化层面本仓库的 优化脚本 提供了可立即运行的evaluate_prompt它会并行跑完测试集聚合出avg_accuracy、avg_latency、p95_latency、avg_tokens、success_rate五个指标并基于calculate_accuracy精确匹配 词重叠部分匹配给每条推理链打分——建议把evaluate_cot_quality的维度接入其测试用例实现推理质量 工程指标双轨评估。同一技能的 prompt-optimization.md 还补充了consistency相同输入多次输出的一致性与 P95 延迟指标这些对推理提示尤为重要推理链越长一致性越难保证越需要量化监控。九、Best Practices 与 Common Pitfalls9.1 六条最佳实践源自原文档Clear Step Markers使用编号步骤或明确分隔符如 1.、Step N:帮助模型维持结构Show All Work不要省略步骤即使是很显然的中间计算Verify Calculations显式加入验证步骤见第五节State Assumptions把隐含假设显式化减少歧义Check Edge Cases考虑边界条件0、负数、空输入、极端数值Use Examples先给示例展示推理模式再让模型模仿。9.2 五大常见陷阱Premature Conclusions过早下结论跳过推理直接给答案CoT 失去意义Circular Logic循环逻辑用结论反证推理过程逻辑推理模板的事实 → 关系 → 演绎 → 结论顺序可有效规避Missing Steps缺失步骤跳步会导致中间错误难以定位与 Best Practice 2 对应Overcomplicated过度复杂堆砌无关步骤反而干扰判断需用efficiency指标约束Inconsistent Format格式不一致推理中途改变步骤结构会破坏模型的自洽性Few-Shot 示例必须保持格式统一。十、在 prompt-engineering-patterns 技能中的定位与使用方式在 SKILL.md 中Chain-of-Thought 是六大核心能力之一其技能触发词明确包含 use chain-of-thought见文件头部 frontmatter 的description字段。当使用本技能处理 CoT 任务时推荐的资料调用路径是阅读本参考文档 chain-of-thought.md 建立模式全集需要与示例搭配时查阅 few-shot-learning.md 与 few-shot-examples.json需要与结构化输出结合时参考 details.md 的 Chain-of-Thought with Self-Verification 模式将推理链固化为## Steps / ## Answer / ## Verification三段格式需要做收益验证时直接运行或改造 optimize-prompt.py。此外CoT 与同技能下的 prompt-templates.md模板系统、prompt-optimization.md迭代优化、system-prompts.md系统提示组合可以构成一条完整的设计 → 实现 → 评估 → 迭代生产链路而仓库中的 ai-engineer agent 将advanced prompting techniques: chain-of-thought, tree-of-thoughts, self-consistency列为自己的核心能力说明 CoT 系列技术在本仓库中是被当作生产级 LLM 应用工程的标配手段来对待的。小结Chain-of-Thought 提示的核心价值在于把不可见的推理过程显式化从而同时获得更好的准确率、可审计性和可优化性。本文沿着原文档的脉络从 Zero-Shot/Few-Shot 基础变体到 Self-Consistency 投票、Least-to-Most 拆解、Tree-of-Thought 搜索、验证纠错等进阶模式再到领域模板、性能优化与质量评估给出了完整且可复现的工程方案。在实际项目中建议按先 Zero-Shot 建立基线 → 不行再 Few-Shot 示例 → 复杂任务叠加验证与自一致性 → 用质量指标量化收益的路径渐进落地避免一上来就上最复杂的 ToT。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Chain-of-Thought 提示工程实战指南：从 Zero-Shot 到 Tree-of-Thought 的可复现推理方案
Chain-of-Thought 提示工程实战指南从 Zero-Shot 到 Tree-of-Thought 的可复现推理方案【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents导读Chain-of-ThoughtCoT思维链提示是一种让大语言模型LLM显式输出中间推理步骤的技术能够显著提升模型在复杂数学、逻辑推理和多步规划任务上的表现。本文以 agents24 仓库中 prompt-engineering-patterns 技能 的 chain-of-thought 参考文档 为骨架结合同技能下的 few-shot 学习、提示词优化脚本与模板库源码系统讲解 Zero-Shot CoT、Few-Shot CoT、Self-Consistency、Least-to-Most、Tree-of-Thought 等主流变体并给出数学、代码调试、逻辑推理三大领域的可直接套用的模板、性能优化手段与质量评估指标。读完本文你将掌握一套可在生产 LLM 应用中落地、可验证、可量化的推理提示工程方案。一、什么是 Chain-of-Thought PromptingChain-of-Thought 的核心思想是不要求模型直接给出答案而是先引导它逐步写出推理过程再基于推理过程得出最终结论。其底层动机在于LLM 在隐式跳跃推理时更容易出错而把中间步骤显式化可以让模型把速度换精度把复杂计算拆解为可追踪的中间结果使错误的定位成为可能——推理链可被人工或程序逐行核查让show your work式的输出天然具备可审计性。该技术在本仓库 prompt-engineering-patterns 技能中属于Core Capabilities的第二大能力文档明确列出了其覆盖的子技术Zero-Shot CoTLets think step by step、Few-Shot CoT带推理痕迹的示例、Self-Consistency多次采样推理路径以及验证Verification步骤。适用与不适用的边界源自原文档 When to Use CoT推荐使用 CoT建议跳过 CoT数学与算术问题简单事实性查询逻辑推理任务直接查表/检索多步规划创意写作代码生成与调试需要简洁输出的任务复杂决策实时、延迟敏感的应用判断要点只有当过程本身承载信息量时CoT 才有价值。简单的 11 不需要推理链而分阶段规划一个多智能体协作流程则必须显式推理。二、基础技术Zero-Shot CoT 与 Few-Shot CoT2.1 Zero-Shot CoT一行触发词Zero-Shot CoT 是最轻量的变体——不提供任何示例只在问题后追加一句触发短语即可。def zero_shot_cot(query): return f{query} Lets think step by step: # Example query If a train travels 60 mph for 2.5 hours, how far does it go? prompt zero_shot_cot(query) # Model output: # Lets think step by step: # 1. Speed 60 miles per hour # 2. Time 2.5 hours # 3. Distance Speed × Time # 4. Distance 60 × 2.5 150 miles # Answer: 150 miles这一模式在本仓库的 优化脚本 中也被视为一种可自动生成的提示变体generate_variations中的 Variation 2 即为Lets solve this step by step.\n\n prompt说明它已被纳入工程化的提示优化流程而不仅仅是学术技巧。2.2 Few-Shot CoT用带推理痕迹的示例做示范Few-Shot CoT 在 Zero-Shot 基础上进一步提供问题 → 分步推理 → 答案的完整示例让模型模仿示例中的推理风格。原文档给出了经典的数学应用题示例few_shot_examples Q: Roger has 5 tennis balls. He buys 2 more cans of tennis balls. Each can has 3 balls. How many tennis balls does he have now? A: Lets think step by step: 1. Roger starts with 5 balls 2. He buys 2 cans, each with 3 balls 3. Balls from cans: 2 × 3 6 balls 4. Total: 5 6 11 balls Answer: 11 Q: The cafeteria had 23 apples. If they used 20 to make lunch and bought 6 more, how many do they have? A: Lets think step by step: 1. Started with 23 apples 2. Used 20 for lunch: 23 - 20 3 apples left 3. Bought 6 more: 3 6 9 apples Answer: 9 Q: {user_query} A: Lets think step by step:示例构建的三个关键纪律与同技能下 few-shot-learning.md 的Example Construction Best Practices完全一致格式一致性所有示例必须使用完全相同的格式Q:/A:、缩进、编号规则不一致的格式会直接污染模型对输出格式的认知输入输出对齐示例必须精确示范目标任务本身避免问题与答案关系模糊的反例难度梯度示例难度应覆盖简单、中等、复杂三档让模型学会从易到难地组织推理。若要动态挑选最相关的示例可参考该参考文档提供的 SemanticExampleSelector 实现用 embedding 余弦相似度选取与当前查询最接近的示例注入提示。三、Self-Consistency用投票对冲单条推理链的风险单条推理链可能因一步走错而全盘皆错。Self-Consistency 的思路是同一个问题采样 n 条推理路径对最终答案做多数投票并给出置信度。原文档给出的核心实现import openai from collections import Counter def self_consistency_cot(query, n5, temperature0.7): prompt f{query}\n\nLets think step by step: responses [] for _ in range(n): response openai.ChatCompletion.create( modelgpt-5.4, messages[{role: user, content: prompt}], temperaturetemperature ) responses.append(extract_final_answer(response)) # Take majority vote answer_counts Counter(responses) final_answer answer_counts.most_common(1)[0][0] return { answer: final_answer, confidence: answer_counts[final_answer] / n, all_responses: responses }参数作用与取值建议参数含义典型取值影响n采样条数310越大投票越稳但成本与延迟线性上升temperature采样随机性0.50.8过低导致路径趋同、失去投票意义过高引入噪声extract_final_answer从推理链中抽取最终答案—依赖稳定的输出格式建议在提示中明确 Answer: 前缀confidence出现最多的答案占比本身就是一个非常有用的副产品当confidence偏低时说明模型对答案缺乏共识此时应当触发人工介入或降级策略。这与本仓库 details.md 中置信度分级 降级回退的错误恢复模式ResponseWithConfidence思路一脉相承。四、进阶模式Least-to-Most 与 Tree-of-Thought4.1 Least-to-Most Prompting先拆解再逐个子问题求解Least-to-Most 分三个阶段工作拆解Decomposition→ 顺序求解Sequential Solving→ 最终整合Final Integration。每个子问题的解都会作为上下文拼接进下一个子问题的提示中形成脚手架式推理def least_to_most_prompt(complex_query): # Stage 1: Decomposition decomp_prompt fBreak down this complex problem into simpler subproblems: Problem: {complex_query} Subproblems: subproblems get_llm_response(decomp_prompt) # Stage 2: Sequential solving solutions [] context for subproblem in subproblems: solve_prompt f{context} Solve this subproblem: {subproblem} Solution: solution get_llm_response(solve_prompt) solutions.append(solution) context f\n\nPreviously solved: {subproblem}\nSolution: {solution} # Stage 3: Final integration final_prompt fGiven these solutions to subproblems: {context} Provide the final answer to: {complex_query} Final Answer: return get_llm_response(final_prompt)从源码结构看本技能参考文档中的 StatefulTemplate 与 Least-to-Most 是天然互补的前者维护init → processing → complete的多步状态模板可以把逐步求解的状态管理工程化避免每一步提示手工拼接。4.2 Tree-of-Thought (ToT)分支探索 启发式评分当问题存在多条可行路径如规划、谜题、推理题时ToT 把推理建模为一棵搜索树每一步生成多个候选思维用评分函数评估各分支择优继续深入。原文档给出了一个可运行的骨架class TreeOfThought: def __init__(self, llm_client, max_depth3, branches_per_step3): self.client llm_client self.max_depth max_depth self.branches_per_step branches_per_step def solve(self, problem): # Generate initial thought branches initial_thoughts self.generate_thoughts(problem, depth0) # Evaluate each branch best_path None best_score -1 for thought in initial_thoughts: path, score self.explore_branch(problem, thought, depth1) if score best_score: best_score score best_path path return best_path def generate_thoughts(self, problem, context, depth0): prompt fProblem: {problem} {context} Generate {self.branches_per_step} different next steps in solving this problem: 1. response self.client.complete(prompt) return self.parse_thoughts(response) def evaluate_thought(self, problem, thought_path): prompt fProblem: {problem} Reasoning path so far: {thought_path} Rate this reasoning path from 0-10 for: - Correctness - Likelihood of reaching solution - Logical coherence Score: return float(self.client.complete(prompt))关键设计决策branches_per_step控制每层的分支数典型 24过大易发散且显著增加 token 消耗max_depth控制搜索深度需要与问题复杂度匹配评分维度Correctness / Likelihood / Logical coherence本身就是一份推理质量 rubric建议在真实落地时让评分模型输出分数 理由便于追溯为什么选中某条分支。五、验证步骤让推理链可纠错CoT 的一个常见风险是推理过程看起来很顺但结果错误。显式加入验证环节Verification Step可以显著提升最终正确率。原文档的实现分三步先生成推理与答案再要求模型逐项核查逻辑错误、算术、合理性最后在发现错误时要求修正def cot_with_verification(query): # Step 1: Generate reasoning and answer reasoning_prompt f{query} Lets solve this step by step: reasoning_response get_llm_response(reasoning_prompt) # Step 2: Verify the reasoning verification_prompt fOriginal problem: {query} Proposed solution: {reasoning_response} Verify this solution by: 1. Checking each step for logical errors 2. Verifying arithmetic calculations 3. Ensuring the final answer makes sense Is this solution correct? If not, whats wrong? Verification: verification get_llm_response(verification_prompt) # Step 3: Revise if needed if incorrect in verification.lower() or error in verification.lower(): revision_prompt fThe previous solution had errors: {verification} Please provide a corrected solution to: {query} Corrected solution: return get_llm_response(revision_prompt) return reasoning_response在本仓库 details.md 中CoT 自验证被工程化为更结构化的提示模板明确要求模型按## Steps、## Answer、## Verification三段式输出把验证固化为输出格式的一部分prompt-optimization.md 的失败分析章节同样建议当出现逻辑类错误时追加Before responding, verify your answer is logically consistent指令——验证步骤因此既是运行时纠错机制也是提示迭代的修复手段。六、领域专用模板数学、代码调试与逻辑推理原文档为三个高价值领域各提供了一套带占位符的模板可直接参数化复用。6.1 数学问题模板math_cot_template Problem: {problem} Solution: Step 1: Identify what we know - {list_known_values} Step 2: Identify what we need to find - {target_variable} Step 3: Choose relevant formulas - {formulas} Step 4: Substitute values - {substitution} Step 5: Calculate - {calculation} Step 6: Verify and state answer - {verification} Answer: {final_answer} 该模板的六步结构与原文档 Best Practices 中的Show All Work、Verify Calculations、State Assumptions一一对应适合用于需要完整解题过程的评测或教学场景。6.2 代码调试模板debug_cot_template Code with error: {code} Error message: {error} Debugging process: Step 1: Understand the error message - {interpret_error} Step 2: Locate the problematic line - {identify_line} Step 3: Analyze why this line fails - {root_cause} Step 4: Determine the fix - {proposed_fix} Step 5: Verify the fix addresses the error - {verification} Fixed code: {corrected_code} 模板把读报错 → 定位 → 根因 → 修复 → 验证五步流程显式化恰好契合 CoT 对过程可审计的要求。在本仓库的 agent 生态中这类模板可直接服务于 debugger 类 agent 的推理环节。6.3 逻辑推理模板logic_cot_template Premises: {premises} Question: {question} Reasoning: Step 1: List all given facts {facts} Step 2: Identify logical relationships {relationships} Step 3: Apply deductive reasoning {deductions} Step 4: Draw conclusion {conclusion} Answer: {final_answer} 逻辑推理模板强调前提 → 事实列举 → 关系识别 → 演绎 → 结论的链式结构对防止用结论反证前提的循环逻辑原文档 Common Pitfalls 之一有直接约束作用。七、性能优化缓存与自适应推理深度7.1 推理缓存Reasoning Cache对语义相近的重复问题可以缓存历史推理链命中后直接复用。原文档给出的实现基于 embedding 余弦相似度class ReasoningCache: def __init__(self): self.cache {} def get_similar_reasoning(self, problem, threshold0.85): problem_embedding embed(problem) for cached_problem, reasoning in self.cache.items(): similarity cosine_similarity( problem_embedding, embed(cached_problem) ) if similarity threshold: return reasoning return None def add_reasoning(self, problem, reasoning): self.cache[problem] reasoningthreshold典型 0.80.9需要在缓存命中率与误复用错误推理之间权衡。这一思路与本仓库 prompt-templates.md 的CachedTemplate、以及 details.md 中对重复使用的 system prompt 启用 prompt caching的策略互为补充前者缓存推理结果后者缓存固定前缀两者共同压低延迟与成本。7.2 自适应推理深度Adaptive Reasoning Depth不同问题需要的推理步数差异很大。原文档提供了从浅到深、按需加深的自适应策略def adaptive_cot(problem, initial_depth3): depth initial_depth while depth 10: # Max depth response generate_cot(problem, num_stepsdepth) # Check if solution seems complete if is_solution_complete(response): return response depth 2 # Increase reasoning depth return response # Return best attemptis_solution_complete通常可通过启发式规则是否出现最终答案、是否覆盖全部子问题或轻量评分模型实现。这种渐进加深与 details.md 的 Progressive Disclosure四级递进直接指令 → 加约束 → 加推理 → 加示例在设计哲学上完全一致——从简单开始仅在必要时增加复杂度。八、质量评估如何度量一条推理链的好坏CoT 不是加了提示词就算成功必须用量化指标验证收益。原文档给出了五维评估框架def evaluate_cot_quality(reasoning_chain): metrics { coherence: measure_logical_coherence(reasoning_chain), completeness: check_all_steps_present(reasoning_chain), correctness: verify_final_answer(reasoning_chain), efficiency: count_unnecessary_steps(reasoning_chain), clarity: rate_explanation_clarity(reasoning_chain) } return metrics指标考察内容建议实现方式coherence步骤之间逻辑连贯用 LLM 评分或检查步骤间引用关系completeness是否覆盖全部必要步骤对照问题要素做 checklist 匹配correctness最终答案正确性与 ground truth 精确/模糊匹配efficiency是否有多余步骤统计非必要步骤占比clarity解释是否清晰LLM 评分或人工抽样在工程化层面本仓库的 优化脚本 提供了可立即运行的evaluate_prompt它会并行跑完测试集聚合出avg_accuracy、avg_latency、p95_latency、avg_tokens、success_rate五个指标并基于calculate_accuracy精确匹配 词重叠部分匹配给每条推理链打分——建议把evaluate_cot_quality的维度接入其测试用例实现推理质量 工程指标双轨评估。同一技能的 prompt-optimization.md 还补充了consistency相同输入多次输出的一致性与 P95 延迟指标这些对推理提示尤为重要推理链越长一致性越难保证越需要量化监控。九、Best Practices 与 Common Pitfalls9.1 六条最佳实践源自原文档Clear Step Markers使用编号步骤或明确分隔符如 1.、Step N:帮助模型维持结构Show All Work不要省略步骤即使是很显然的中间计算Verify Calculations显式加入验证步骤见第五节State Assumptions把隐含假设显式化减少歧义Check Edge Cases考虑边界条件0、负数、空输入、极端数值Use Examples先给示例展示推理模式再让模型模仿。9.2 五大常见陷阱Premature Conclusions过早下结论跳过推理直接给答案CoT 失去意义Circular Logic循环逻辑用结论反证推理过程逻辑推理模板的事实 → 关系 → 演绎 → 结论顺序可有效规避Missing Steps缺失步骤跳步会导致中间错误难以定位与 Best Practice 2 对应Overcomplicated过度复杂堆砌无关步骤反而干扰判断需用efficiency指标约束Inconsistent Format格式不一致推理中途改变步骤结构会破坏模型的自洽性Few-Shot 示例必须保持格式统一。十、在 prompt-engineering-patterns 技能中的定位与使用方式在 SKILL.md 中Chain-of-Thought 是六大核心能力之一其技能触发词明确包含 use chain-of-thought见文件头部 frontmatter 的description字段。当使用本技能处理 CoT 任务时推荐的资料调用路径是阅读本参考文档 chain-of-thought.md 建立模式全集需要与示例搭配时查阅 few-shot-learning.md 与 few-shot-examples.json需要与结构化输出结合时参考 details.md 的 Chain-of-Thought with Self-Verification 模式将推理链固化为## Steps / ## Answer / ## Verification三段格式需要做收益验证时直接运行或改造 optimize-prompt.py。此外CoT 与同技能下的 prompt-templates.md模板系统、prompt-optimization.md迭代优化、system-prompts.md系统提示组合可以构成一条完整的设计 → 实现 → 评估 → 迭代生产链路而仓库中的 ai-engineer agent 将advanced prompting techniques: chain-of-thought, tree-of-thoughts, self-consistency列为自己的核心能力说明 CoT 系列技术在本仓库中是被当作生产级 LLM 应用工程的标配手段来对待的。小结Chain-of-Thought 提示的核心价值在于把不可见的推理过程显式化从而同时获得更好的准确率、可审计性和可优化性。本文沿着原文档的脉络从 Zero-Shot/Few-Shot 基础变体到 Self-Consistency 投票、Least-to-Most 拆解、Tree-of-Thought 搜索、验证纠错等进阶模式再到领域模板、性能优化与质量评估给出了完整且可复现的工程方案。在实际项目中建议按先 Zero-Shot 建立基线 → 不行再 Few-Shot 示例 → 复杂任务叠加验证与自一致性 → 用质量指标量化收益的路径渐进落地避免一上来就上最复杂的 ToT。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考