企业官网建设流程全解析

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-Thought（CoT，思维链）提示是一种让大语言模型（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 Prompting

Chain-of-Thought 的核心思想是：不要求模型直接给出答案，而是先引导它逐步写出推理过程，再基于推理过程得出最终结论。其底层动机在于，LLM 在隐式"跳跃"推理时更容易出错，而把中间步骤显式化可以：

• 让模型把"速度换精度"，把复杂计算拆解为可追踪的中间结果；
• 使错误的定位成为可能——推理链可被人工或程序逐行核查；
• 让"show your work"式的输出天然具备可审计性。

该技术在本仓库 prompt-engineering-patterns 技能中属于"Core Capabilities"的第二大能力，文档明确列出了其覆盖的子技术：Zero-Shot CoT（"Let's think step by step"）、Few-Shot CoT（带推理痕迹的示例）、Self-Consistency（多次采样推理路径）以及验证（Verification）步骤。

适用与不适用的边界（源自原文档 "When to Use CoT"）：

判断要点：只有当"过程"本身承载信息量时，CoT 才有价值。简单的 1+1 不需要推理链，而"分阶段规划一个多智能体协作流程"则必须显式推理。

二、基础技术：Zero-Shot CoT 与 Few-Shot CoT

2.1 Zero-Shot CoT：一行触发词

Zero-Shot CoT 是最轻量的变体——不提供任何示例，只在问题后追加一句触发短语即可。

def zero_shot_cot(query): return f"""{query} Let's 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: # "Let's 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 即为"Let's 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: Let's 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: Let's 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: Let's think step by step:"""

示例构建的三个关键纪律（与同技能下 few-shot-learning.md 的"Example Construction Best Practices"完全一致）：

1. 格式一致性：所有示例必须使用完全相同的格式（"Q:/A:"、缩进、编号规则），不一致的格式会直接污染模型对输出格式的认知；
2. 输入输出对齐：示例必须精确示范目标任务本身，避免"问题与答案关系模糊"的反例；
3. 难度梯度：示例难度应覆盖简单、中等、复杂三档，让模型学会从易到难地组织推理。

若要动态挑选最相关的示例，可参考该参考文档提供的 SemanticExampleSelector 实现，用 embedding 余弦相似度选取与当前查询最接近的示例注入提示。

三、Self-Consistency：用投票对冲单条推理链的风险

单条推理链可能因一步走错而全盘皆错。Self-Consistency 的思路是：同一个问题采样 n 条推理路径，对最终答案做多数投票，并给出置信度。原文档给出的核心实现：

import openai from collections import Counter def self_consistency_cot(query, n=5, temperature=0.7): prompt = f"{query}\n\nLet's think step by step:" responses = [] for _ in range(n): response = openai.ChatCompletion.create( model="gpt-5.4", messages=[{"role": "user", "content": prompt}], temperature=temperature ) 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 }

参数作用与取值建议：

confidence（出现最多的答案占比）本身就是一个非常有用的副产品：当confidence偏低时，说明模型对答案缺乏共识，此时应当触发人工介入或降级策略。这与本仓库 details.md 中"置信度分级 + 降级回退"的错误恢复模式（ResponseWithConfidence）思路一脉相承。

四、进阶模式：Least-to-Most 与 Tree-of-Thought

4.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 = f"""Break 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 = f"""Given 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_depth=3, branches_per_step=3): 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, depth=0) # Evaluate each branch best_path = None best_score = -1 for thought in initial_thoughts: path, score = self.explore_branch(problem, thought, depth=1) if score > best_score: best_score = score best_path = path return best_path def generate_thoughts(self, problem, context="", depth=0): prompt = f"""Problem: {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 = f"""Problem: {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：控制每层的分支数，典型 2～4，过大易发散且显著增加 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} Let's solve this step by step:""" reasoning_response = get_llm_response(reasoning_prompt) # Step 2: Verify the reasoning verification_prompt = f"""Original 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, what's 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 = f"""The 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, threshold=0.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] = reasoning

threshold（典型 0.8～0.9）需要在"缓存命中率"与"误复用错误推理"之间权衡。这一思路与本仓库 prompt-templates.md 的CachedTemplate、以及 details.md 中"对重复使用的 system prompt 启用 prompt caching"的策略互为补充：前者缓存推理结果，后者缓存固定前缀，两者共同压低延迟与成本。

7.2 自适应推理深度（Adaptive Reasoning Depth）

不同问题需要的推理步数差异很大。原文档提供了"从浅到深、按需加深"的自适应策略：

def adaptive_cot(problem, initial_depth=3): depth = initial_depth while depth <= 10: # Max depth response = generate_cot(problem, num_steps=depth) # Check if solution seems complete if is_solution_complete(response): return response depth += 2 # Increase reasoning depth return response # Return best attempt

is_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

在工程化层面，本仓库的 优化脚本 提供了可立即运行的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 Pitfalls

9.1 六条最佳实践（源自原文档）

1. Clear Step Markers：使用编号步骤或明确分隔符，如 "1."、"Step N:"，帮助模型维持结构；
2. Show All Work：不要省略步骤，即使是很显然的中间计算；
3. Verify Calculations：显式加入验证步骤（见第五节）；
4. State Assumptions：把隐含假设显式化，减少歧义；
5. Check Edge Cases：考虑边界条件（0、负数、空输入、极端数值）；
6. 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 任务时，推荐的资料调用路径是：

1. 阅读本参考文档 chain-of-thought.md 建立模式全集；
2. 需要与示例搭配时，查阅 few-shot-learning.md 与 few-shot-examples.json；
3. 需要与结构化输出结合时，参考 details.md 的 "Chain-of-Thought with Self-Verification" 模式（将推理链固化为## Steps / ## Answer / ## Verification三段格式）；
4. 需要做收益验证时，直接运行或改造 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