> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/prompt_engineering_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/prompt_engineering_guide/di-er-bu-fen-he-xin-ji-shu-pian/06_chain_of_thought/6.6_reasoning_decision_framework.md).
# 6.6 Reasoning 模型决策框架：何时使用与最佳实践
Reasoning 模型（如 OpenAI GPT-5.6 Sol / Terra / Luna、o 系列、Claude 的 Adaptive Thinking）代表了 LLM 推理范式的重大进步。然而，这些模型的高成本和长延迟特性决定了它们并非适用于所有场景。本节深入探讨 Reasoning 模型的工作原理、应用条件和决策框架。
> **注意**：OpenAI 于 2026-07-09 发布 GPT-5.6 系列；Sol 面向前沿能力，Terra 平衡能力与成本，Luna 面向高吞吐。Claude 的思考配置与模型版本绑定：Opus 5 的 thinking 默认开启，关闭时受 `effort` 限制（仅 `high` 及以下接受 `type: "disabled"`）；Sonnet 5 默认启用 Adaptive Thinking，并移除了手动 Extended Thinking；Fable 5 / Mythos 5 的 Adaptive Thinking 常开，二者已于 2026-07-01 恢复访问，Mythos 5 仍限获批客户。Opus 4.8 / 4.7 不再支持手动 Extended Thinking，Opus 4.6 与 Sonnet 4.6 上的 `type: "enabled"` + `budget_tokens` 仍可用但已 deprecated。模型选择以[快变事实核验表](/prompt_engineering_guide/fu-lu/h_volatile_facts.md)、官方文档和自有评测为准，不能把某个型号的配置泛化到整个系列。
## 6.6.1 Reasoning 模型的核心机制
### 传统模型 vs Reasoning 模型
下图展示了传统模型与 Reasoning 模型在执行方式上的关键差异：
```mermaid
graph TB
subgraph Traditional["传统模型（GPT-4、Claude）"]
Input1["用户输入"]
Process1["直接生成响应
单步推理"]
Output1["输出"]
Input1 --> Process1
Process1 --> Output1
Latency1["延迟: 1-5 秒"]
Cost1["成本: 标准价格"]
end
subgraph Reasoning["Reasoning / Frontier 模型（GPT-5.6 Sol、o3、Adaptive Thinking）"]
Input2["用户输入"]
Thinking["内部思考过程
多步骤推理链"]
Verification["验证与回溯"]
Output2["最终答案"]
Input2 --> Thinking
Thinking --> Verification
Verification --> Output2
Latency2["延迟: 取决于推理预算与负载"]
Cost2["成本: 通常高于标准模型"]
end
Traditional -.->|适合快速、简单任务| Use1["简单问答、内容生成"]
Reasoning -.->|适合复杂、深层分析| Use2["科学推理、代码调试"]
style Traditional fill:#e3f2fd
style Reasoning fill:#f3e5f5
style Latency1 fill:#c8e6c9
style Latency2 fill:#ffcdd2
style Cost1 fill:#c8e6c9
style Cost2 fill:#ffcdd2
```
*图 6-5：传统模型与 Reasoning 模型的执行方式对比*
### 内部思考机制对比
```
【传统模型执行流程】
输入: "2+2 等于多少?"
直接计算: "2+2 等于 4"
Token 消耗: ~20 tokens
耗时: 0.5 秒
成本: $0.00001
【Reasoning 模型执行流程】
输入: "证明：对于任意正整数 n，n(n+1)(2n+1)/6 的求和公式是否成立?"
内部思考过程（对用户隐藏）:
步骤 1: 理解问题的数学含义
步骤 2: 识别这是一个归纳法证明问题
步骤 3: 尝试多种证明方法
步骤 4: 验证每种方法的正确性
步骤 5: 选择最清晰的证明路径
步骤 6: 检查逻辑严密性
思考 Token 消耗: 可能显著高于普通生成，具体取决于模型和推理预算
输出 Token 消耗: 与最终答案长度相关
总 Token 消耗: 输入、输出和推理 token 共同决定
耗时: 随模型、负载、推理力度和输出长度变化
成本: 通常高于标准模型；上线前应按真实流量测算
质量: 在复杂任务上通常更稳，但必须用自有评测集验证
```
## 6.6.2 何时应该使用 Reasoning 模型
### 任务特征评估矩阵
以下矩阵展示了评估是否使用 Reasoning 模型的关键维度：
```
适合 Reasoning 模型的任务特征：
┌─────────────────────────────────────────────────────────┐
│ 高复杂度 + 高准确率要求 + 容许延迟 = 强烈推荐使用 │
└─────────────────────────────────────────────────────────┘
【维度 1：任务复杂度】
低 ← ─────────────── → 高
复杂度低的任务 中等复杂度 复杂度高的任务
✗ 不推荐 ⚠️ 可选 ✓ 强烈推荐
- 事实查询 - 需要多步思考 - 科学问题证明
- 翻译 - 需要分析比较 - 数学问题求解
- 信息提取 - 需要逻辑推理 - 代码调试复杂问题
- 简单问答 - 需要创意组合 - 法律论证
- 需要因果分析 - 战略规划
【维度 2：准确率需求】
低 ← ─────────────── → 高
准确率需求低 中等准确率需求 极高准确率需求
✗ 不推荐 ⚠️ 可选 ✓ 强烈推荐
- 娱乐内容 - 一般商业分析 - 医学诊断辅助
- 灵感激发 - 基础教育 - 法律意见书
- 头脑风暴 - 技术文档 - 金融合规审查
- 概念解释 - 代码审查 - 论文撰写
【维度 3：时间容限】
实时 ← ─────────────── → 延迟容限
需要实时响应 中等延迟容限 大延迟容限
✗ 不推荐 ⚠️ 可选 ✓ 强烈推荐
- 聊天应用 - 邮件自动回复 - 离线报告生成
- 实时翻译 - 内容审核 - 学术论文审阅
- 问题答疑 - 代码补全 - 研究分析
- 客服对话 - 自动化测试
【维度 4：成本敏感度】
不敏感 ← ────────── → 极度敏感
成本不敏感 中等成本敏感 成本极度敏感
✓ 推荐 ⚠️ 可选 ✗ 不推荐
- 关键业务 - 普通商业应用 - 大批量生成
- 高利润业务 - 中等规模应用 - 成本驱动的应用
- 医疗诊断 - 教育应用 - 日常内容生成
- 法律合规 - 技术支持 - 实时翻译
```
### 决策框架与具体场景
以下决策树帮助你系统地评估是否使用 Reasoning 模型：
```mermaid
graph TD
Start["新任务
评估是否使用 Reasoning 模型"]
Start --> Q1{"任务复杂度
是否≥7/10?"}
Q1 -->|否| Use_Standard["使用标准模型
更经济高效"]
Q1 -->|是| Q2{"准确率需求
是否>90%?"}
Q2 -->|否| Consider["考虑使用标准模型
配合 Chain-of-Thought"]
Q2 -->|是| Q3{"能否容许
30 秒以上延迟?"}
Q3 -->|否| UseStandard_COT["使用标准模型
+ 强化 CoT 提示"]
Q3 -->|是| Q4{"成本预算
是否充足?"}
Q4 -->|否| UseOptimized["成本优化方案：
只对关键请求使用
其余使用标准模型"]
Q4 -->|是| UseReasoning["✓ 使用 Reasoning 模型
GPT-5.6 Sol / Terra / Claude Thinking"]
Start --> Metrics["关键评估指标"]
Metrics --> M1["复杂度: CoT 步骤数
≥5 步 → 推荐"]
Metrics --> M2["准确率: 基线准确率
<80% → 推荐"]
Metrics --> M3["延迟: P99
业务可接受 → 推荐"]
Metrics --> M4["成本: ROI
≥5 倍 → 推荐"]
Use_Standard --> End["执行决策"]
Consider --> End
UseStandard_COT --> End
UseOptimized --> End
UseReasoning --> End
style UseReasoning fill:#f3e5f5,stroke:#6a1b9a,stroke-width:3px
style Use_Standard fill:#c8e6c9,stroke:#2e7d32,stroke-width:3px
style UseOptimized fill:#fff9c4,stroke:#f57f17,stroke-width:3px
```
*图 6-6：是否采用 Reasoning 模型的决策树*
## 6.6.3 动态复杂度检测与自动化决策
### 自动化的复杂度评估策略
实现动态复杂度检测需要多个评估维度的综合分析：
```
【为什么需要动态复杂度检测】
现实场景: 不是每个任务都能提前标记为"简单"或"复杂"
问题:
- 用户的请求多样化，无法预先分类
- 同一类型的请求也存在复杂度差异
- 手动判断成本高，且容易出错
- 需要自动化系统在运行时判断
解决: 使用启发式规则和小模型进行快速复杂度评估
【复杂度检测维度 1：关键词分析】
低复杂度信号:
- 事实查询关键词: "什么是", "定义", "怎么拼写"
- 简单操作: "翻译", "列出", "总结"
- 单一主体: 只涉及一个对象/概念
高复杂度信号:
- 逻辑推理: "为什么", "如何证明", "有什么影响"
- 多步骤: "首先...然后...最后"
- 比较分析: "对比", "权衡", "优缺点"
- 假设情景: "假如", "如果...会怎样"
- 数学/科学: 包含公式、定理、计算
```
示例检测:
```python
def detect_complexity_by_keywords(query):
simple_keywords = ["什么是", "定义", "翻译", "列出"]
complex_keywords = ["为什么", "证明", "对比", "假如"]
if any(kw in query for kw in simple_keywords):
return "low" # 复杂度低
elif any(kw in query for kw in complex_keywords):
return "high" # 复杂度高
else:
return "medium"
```
【复杂度检测维度 2：数学符号密度】
```
公式/符号出现率:
0 个符号 → 复杂度低 (纯文本)
1-3 个符号 → 复杂度中 (一些技术内容)
4+ 个符号 → 复杂度高 (数学/科学)
符号类型权重:
微积分符号 (∫, ∂, ∇) → +2
统计符号 (Σ, μ, σ) → +1.5
逻辑符号 (∃, ∀, ⇒) → +1.5
基础算术 (+, -, ×, ÷) → +0.5
```
【复杂度检测维度 3：多步骤指标】
```python
def count_logical_steps(query):
"""估计任务需要的逻辑步骤"""
indicators = {
"首先": 1,
"然后": 1,
"最后": 1,
"但是": 0.5, # 表示比较
"其次": 1,
"分别": 1,
"并且": 0.5, # 多维分析
}
step_count = sum(query.count(kw) * weight for kw, weight in indicators.items())
if step_count == 0:
return "single_step" # 单步骤 → 简单
elif step_count <= 2:
return "few_steps" # 2 步以内 → 中等
else:
return "many_steps" # 超过 2 步 → 复杂
```
【复杂度检测维度 4：依赖性分析】
```
问题依赖的外部因素:
依赖数 = 0 → 自包含 → 简单
依赖数 = 1-2 → 中等
依赖数 = 3+ → 复杂
什么算“依赖”：
- 需要查询外部数据库
- 需要调用多个 API
- 需要访问多个不同的知识领域
- 需要实时信息（股票价格、天气等）
示例:
“北京明天的天气是什么？”
依赖: 1 (实时天气数据) → 中等
“基于历史股价数据，预测科技股明年的涨跌，
并比较三大互联网公司的相对价值“
依赖: 3 (历史数据、预测模型、公司数据) → 高
```
【集成的复杂度评分系统】
```python
class ComplexityDetector:
def __init__(self):
self.weights = {
"keywords": 0.3,
"math_density": 0.2,
"logical_steps": 0.3,
"dependencies": 0.2
}
def assess_query(self, query):
"""综合评估查询复杂度（0-10 分）"""
## 维度 1：关键词分析
keyword_score = self.analyze_keywords(query) # 0-10
## 维度 2：数学符号
math_score = self.count_math_symbols(query) # 0-10
## 维度 3：逻辑步骤
step_score = self.count_steps(query) # 0-10
## 维度 4：依赖性
dependency_score = self.analyze_dependencies(query) # 0-10
## 加权求和
total_score = (
self.weights["keywords"] * keyword_score +
self.weights["math_density"] * math_score +
self.weights["logical_steps"] * step_score +
self.weights["dependencies"] * dependency_score
)
return total_score # 0-10
def recommend_model(self, complexity_score):
"""基于复杂度推荐模型"""
if complexity_score < 3:
return "haiku" # 最简单的任务
elif complexity_score < 5:
return "sonnet" # 标准模型
elif complexity_score < 7:
return "adaptive_or_extended_low" # 中等推理
elif complexity_score < 8.5:
return "gpt-5.6-terra" # 能力与成本平衡
else:
return "gpt-5.6-sol" # 前沿能力优先
```
【实时决策流程】
```
用户输入
↓
[快速复杂度评估] < 100ms
├─ 关键词扫描
├─ 符号计数
├─ 结构分析
└─ 依赖评估
↓
[复杂度评分] (0-10)
↓
[模型推荐决策树]
├─ score < 3 → Haiku (最便宜)
├─ score 3-5 → Sonnet (均衡)
├─ score 5-7 → Adaptive Thinking/Extended Thinking Low (推理力)
├─ score 7-8.5 → GPT-5.6 Terra（平衡能力与成本）
└─ score > 8.5 → GPT-5.6 Sol 或 o3-pro（按质量、延迟和成本评测选择）
↓
[模型调用] + [成本追踪]
```
【常见场景的复杂度示例】
```
【场景 1】
查询: “什么是区块链？”
- 关键词: “什么是” (简单) → 2 分
- 数学符号: 0 → 0 分
- 逻辑步骤: 0 → 0 分
- 依赖: 0 → 0 分
- 总分: 0.3×2 + 0.2×0 + 0.3×0 + 0.2×0 = 0.6 分 → 推荐: Haiku
【场景 2】
查询: “请为我的创业公司制定 1 年的产品路线图，
考虑市场趋势、竞争对手分析、技术可行性。“
- 关键词: “为什么”隐含、比较、多个维度 → 6 分
- 数学符号: 0 → 0 分
- 逻辑步骤: “首先分析...然后制定...” → 6 分
- 依赖: 市场数据、竞争数据、技术评估 → 7 分
- 总分: 0.3×6 + 0.2×0 + 0.3×6 + 0.2×7 = 5.0 分
- 推荐: Claude Adaptive Thinking（目标模型支持时）或 GPT-5.6 Terra
【场景 3】
查询: “请证明：对任意正整数 n，1+2+...+n = n(n+1)/2”
- 关键词: “证明” → 8 分
- 数学符号: +, =, n → 6 分
- 逻辑步骤: 多步数学论证 → 8 分
- 依赖: 数学知识库（内部） → 3 分
- 总分: 0.3×8 + 0.2×6 + 0.3×8 + 0.2×3 = 6.6 分
- 推荐: Claude Adaptive Thinking 或 GPT-5.6 Terra；若评测要求极高再升级到 GPT-5.6 Sol
```
【生产实施建议】
1. **快速评估层**
* 在接收查询的 100ms 内完成（与上面流程图的预算一致）
* 使用简单的规则和正则表达式
* 成本几乎为零
2. **精细化评估**
* 对于 score 4-6 之间的“边界情况”
* 可以先用 Sonnet 进行“预分析”
* 再决定是否升级到 Reasoning 模型
3. **反馈循环**
* 记录用户反馈：对于推荐的模型，实际效果如何
* 调整权重和阈值
* 每月评估一次检测准确率
4. **成本优化**
```python
# 决策逻辑
if complexity_score < 5:
use_cheap_model() # 立即决定
else:
# Edge case: use Sonnet for quick evaluation
initial_response = sonnet.process(query)
if initial_response.confidence < 0.7:
# If Sonnet is uncertain, upgrade to the selected reasoning model
final_response = reasoning_model.process(query)
else:
final_response = initial_response
```
## 6.6.4 何时不应该使用 Reasoning 模型
### 成本陷阱分析
```
【反面案例 1：简单任务的过度推理】
任务: “提取文章中的关键词”
❌ 错误做法（直接使用高预算推理模型）:
输入: “文章内容（500 tokens）”
模型内部思考: “让我深度分析这篇文章的语义...”
思考 Token: 远高于任务本身需要
输出: [“关键词 1”, “关键词 2”, ...] (150 tokens)
成本: 明显高于标准模型
耗时: 明显变长
质量提升: 通常有限，需用自有评测集验证
ROI 分析: 成本和延迟增加，但收益不一定覆盖投入
✓ 正确做法（使用 Claude Sonnet 4.6）:
成本: 更低
耗时: 更短
质量: 对关键词抽取这类任务通常已经足够
对比: 先用标准模型建立基线，再决定是否只对少量疑难样本升级
【反面案例 2：大批量任务】
任务: 每天处理 100,000 个客户评论的情感分析
❌ 错误做法（全部使用高预算推理模型）:
日成本: 随流量线性放大
年成本: 可能超出业务预算
性能: 未必比标准模型带来足够增益
问题:
- 成本过高
- 延迟过长，吞吐受限
- 实时性差
✓ 正确做法（混合策略）:
- 90%用 Sonnet (简单评论): 成本低、速度快
- 10%用推理模型 (复杂评论): 提高疑难样本质量
预算方法: 用真实输入/输出长度、推理 token、并发和重试率建立成本模型
处理时间: 通过批处理、并发和缓存优化
【反面案例 3：实时应用】
任务: 聊天应用中的实时问题回答
❌ 错误做法（默认使用高预算推理模型）:
用户期望: 即时回复 (<2 秒)
实际响应时间: 可能明显超过交互容忍范围
用户体验: ⭐⭐ (差)
流失风险: 上升
✓ 正确做法（分层策略）:
- 简单问题用 Sonnet 回复 (<2 秒)
- 复杂问题标记为“正在深入分析...”
- 后台用推理模型处理，稍后推送结果
- 用户体验: ⭐⭐⭐⭐ (好)
```
### 避免的反模式
```
反模式 1: “一刀切”策略
❌ 所有请求都使用高成本推理模型
→ 导致成本爆炸
→ 大量浪费
反模式 2: 完全忽视 Reasoning 能力
❌ 即使是复杂问题也坚持使用便宜模型
→ 导致准确率不足
→ 用户体验差
反模式 3: 没有监控成本与效果
❌ 上线 Reasoning 模型后不跟踪 ROI
→ 无法判断是否值得
→ 难以优化
反模式 4: 错误的问题分类
❌ 根据输入长度而非复杂度选择模型
❌ 根据用户等级而非任务特征选择模型
→ 选择决策不科学
反模式 5: 忽视缓存与优化
❌ 不使用 Prompt Caching
❌ 不利用并发处理
❌ 不进行批处理
→ 浪费成本优化机会
```
## 6.6.5 Reasoning 模型的内部思考过程
### Claude Adaptive Thinking vs OpenAI 推理路线 对比
```mermaid
graph TB
subgraph AdaptiveThinking["Claude Adaptive Thinking（推荐）"]
AT1["特点"]
AT2["可返回摘要化 thinking block
取决于模型与配置"]
AT3["开发者可观察摘要
不是原始完整 CoT"]
AT4["思考 Token 有成本
计入总 Token"]
AT5["推理预算自动调整
无需手动配置"]
end
subgraph O1Model["OpenAI o1"]
O1A["特点"]
O1B["隐藏的思考过程
response 中不显示"]
O1C["无法观察
内部推理"]
O1D["思考与输出
统一计费"]
O1E["推理预算固定
按模型内置"]
end
subgraph O3Model["OpenAI o3"]
O3A["特点"]
O3B["增强的推理
更多思考步骤"]
O3C["支持低/中/高
推理模式"]
O3D["成本跨度大
从低到极高"]
O3E["速度-质量
灵活权衡"]
end
subgraph Comparison["对比维度"]
C1["思考过程可见性"]
C2["Token 消耗"]
C3["推理能力"]
C4["成本范围"]
C5["使用灵活性"]
end
AdaptiveThinking -.-> Comparison
O1Model -.-> Comparison
O3Model -.-> Comparison
style AdaptiveThinking fill:#e3f2fd
style O1Model fill:#fff3e0
style O3Model fill:#f3e5f5
```
*图 6-7：Claude Adaptive Thinking 与 OpenAI o1、o3 的推理机制对比*
### 推理预算配置
```
【Claude Thinking 推理配置】
不同厂商和模型的参数名不同，可能是 `thinking` 类型、推理 effort、reasoning budget 或专门的模型 ID。以下是定性选型，不是固定 SLA；实际延迟、成本和质量必须按你的输入、输出、推理 token、模型版本和并发负载评测。
low
├─ 适合场景: 中等复杂度，需要快速结果
├─ 成本/延迟: 低于更高推理档
├─ 质量: 高于普通回答的概率更高，但需评测验证
└─ 用例: 代码审查、文档总结
medium
├─ 适合场景: 复杂分析，可容许一定延迟
├─ 成本/延迟: 中等
├─ 质量: 适合多数复杂专业任务的候选配置
└─ 用例: 技术方案设计、研究分析
high
├─ 适合场景: 高难度问题，质量要求至关重要
├─ 成本/延迟: 高
├─ 质量: 更适合疑难样本或关键决策
└─ 用例: 科学问题、法律论证、论文审阅
max
├─ 适合场景: 极高难度，不限制成本
├─ 成本/延迟: 极高
├─ 质量: 只应在关键少量任务上使用并人工复核
└─ 用例: 前沿研究、关键决策、学位论文
【OpenAI 最新模型选择】
GPT-5.6 Sol (前沿能力优先)
├─ 适合高复杂度、代码、研究和多步骤推理
├─ 用高价值疑难样本验证收益
└─ 不作为所有请求的无条件默认
GPT-5.6 Terra (能力与成本平衡)
├─ 适合多数复杂生产工作流
├─ 用作 Sol 的成本敏感候选
└─ 按质量、延迟和总成本与其他模型比较
GPT-5.6 Luna (高吞吐与效率优先)
├─ 适合批量、低延迟子任务
├─ 只承接经评测确认的低风险路径
└─ 失败或低置信度请求路由到 Terra/Sol
GPT-5.5 / GPT-5.4 (历史迁移与兼容基线)
├─ 仅用于存量系统回归、迁移对比或合同兼容
└─ 新工作流不再把它们写成当前默认候选
o3-pro (最高质量推理)
├─ 属于较旧的 o 系列高强度推理路径
├─ 质量高，但延迟和成本更高
└─ 适用: 极难推理、历史兼容或专门评测
```
## 6.6.6 完整决策树与实施指南
### 多维决策树
```mermaid
graph TD
Root["任务收到
开始评估"] --> Step1{"第一步：
评估任务复杂度"}
Step1 -->|复杂度<5 分
简单任务| Path1["路径 A
简单任务"]
Step1 -->|复杂度 5-7 分
中等难度| Path2["路径 B
中等任务"]
Step1 -->|复杂度>7 分
复杂任务| Path3["路径 C
复杂任务"]
Path1 --> Dec1["建议: 标准模型
Haiku 4.5（<3 分）
或 Sonnet 4.6（3-5 分）"]
Path2 --> Step2{"第二步：
评估准确率需求"}
Path3 --> Step3{"第二步：
评估质量要求"}
Step2 -->|准确率需求<80%| Dec2["标准模型
Claude Sonnet 4.6"]
Step2 -->|准确率需求 80-95%| Step4{"能否容许
20-30 秒延迟?"}
Step2 -->|准确率需求>95%| Step4
Step3 -->|质量要求不极端| Step5{"能否容许
30-60 秒延迟?"}
Step3 -->|质量要求极高| Dec5["优先评估 GPT-5.6 Sol
必要时比较 o3-pro"]
Step4 -->|能容许| Dec3["Claude Thinking
或 GPT-5.6 Terra"]
Step4 -->|不能容许| Dec4["标准模型
+ 强化 CoT"]
Step5 -->|能容许| Dec6["优先评估 GPT-5.6 Sol
按成本再看 Terra"]
Step5 -->|不能容许| Dec7["标准模型
进行优化"]
Dec1 --> Implement["执行并监控"]
Dec2 --> Implement
Dec3 --> Implement
Dec4 --> Implement
Dec5 --> Implement
Dec6 --> Implement
Dec7 --> Implement
Implement --> Monitor["监控指标：
成本、准确率、延迟"]
Monitor --> Review{"评估是否
达到目标?"}
Review -->|是| Success["✓ 保持现有配置"]
Review -->|否| Optimize["↻ 调整参数重试"]
style Dec1 fill:#c8e6c9
style Dec2 fill:#c8e6c9
style Dec3 fill:#fff9c4
style Dec4 fill:#c8e6c9
style Dec5 fill:#ffccbc
style Dec6 fill:#f3e5f5
style Dec7 fill:#c8e6c9
style Success fill:#a5d6a7,stroke:#2e7d32,stroke-width:2px
```
*图 6-8：Reasoning 模型选型与监控的多维决策树*
### 基准测试数据对比
```
【模型性能对比测试模板】
测试任务:
1. MATH-L4 (高难度数学问题)
2. Code Debug (复杂代码调试)
3. Logic Puzzle (逻辑推理)
┌──────────────────────┬──────────┬──────────┬──────────┬────────────┐
│ 模型 │ 质量 │ 延迟 │ 成本/题 │ 适用性 │
├──────────────────────┼──────────┼──────────┼──────────┼────────────┤
│ Haiku │ 自测填写 │ 自测填写 │ 自测填写 │ 简单任务 │
│ Sonnet (标准) │ 自测填写 │ 自测填写 │ 自测填写 │ 通用任务 │
│ Claude Thinking │ 自测填写 │ 自测填写 │ 自测填写 │ 复杂分析 │
│ GPT-5.6 Terra │ 自测填写 │ 自测填写 │ 自测填写 │ 能力成本平衡 │
│ GPT-5.6 Sol │ 自测填写 │ 自测填写 │ 自测填写 │ 高复杂度任务 │
│ GPT-5.6 Luna │ 自测填写 │ 自测填写 │ 自测填写 │ 高吞吐子任务 │
│ o3-pro │ 自测填写 │ 自测填写 │ 自测填写 │ 历史兼容/专门评测 │
└──────────────────────┴──────────┴──────────┴──────────┴────────────┘
【成本-效益分析】
收益递减曲线应由自己的评测数据生成：
核心洞察：
- 从标准模型升级到推理模型时，质量收益通常递减，成本和延迟通常上升
- 只看平均分会掩盖长尾风险，应单独分析失败样本和高价值样本
- 是否值得升级取决于业务损失函数，而不是通用排行榜
最优选择取决于具体场景的质量需求阈值
```
## 6.6.7 提示词优化：与 Reasoning 模型协作
### 专为 Reasoning 模型设计的提示词
```
【原则 1：明确任务要求】
❌ 不好的提示词（模糊）:
“解释这个数学问题”
✓ 好的提示词（明确）:
"请证明以下数学定理，使用你的思考过程：
- 清晰陈述假设条件
- 解释每一步的逻辑
- 验证边界情况
- 提供反例（如果存在）"
原因: Reasoning 模型需要明确的推理目标，
才能有效分配思考预算
【原则 2：要求显示推理步骤】
❌ 不好的提示词:
“这道代码有 bug 吗？修复它。”
✓ 好的提示词:
"请分析以下代码的问题：
1. 首先，逐行追踪执行流程
2. 识别可能的边界情况
3. 列出所有潜在的 bug
4. 对每个 bug 进行验证
5. 提供完整的修复方案"
原因: 显式要求推理步骤能够引导
Reasoning 模型更深入地思考
【原则 3：设定质量标准】
❌ 不好的提示词:
“写一个研究论文摘要”
✓ 好的提示词:
"请撰写学位论文摘要，满足：
- 准确性：引用的所有数据来自原始论文
- 完整性：覆盖研究目标、方法、结果、结论
- 学术性：使用专业术语，避免主观表述
- 创新性：突出研究的新贡献
- 字数：200-250 字内
请深入思考每个部分的组织逻辑，
确保论述的严密性。"
原因: 明确的质量标准和约束条件能够
帮助 Reasoning 模型更好地规划推理
【原则 4：避免干扰思考过程】
❌ 不好的做法:
“我认为答案是 X，你能证实吗？”
→ 可能引导模型确认而非独立思考
✓ 好的做法:
"请独立分析这个问题，
不受任何预设答案的影响。"
原因: 确保 Reasoning 模型进行真正的
独立推理，而非确认偏见
```
### 费用优化提示
【成本优化提示词】
场景: 使用 Claude Adaptive Thinking 处理一系列任务
推荐方案:
```yaml
system: |
你是一个深度思考的分析师。
对于以下任务，请：
1. 首先明确关键问题
2. 识别必要的思考步骤
3. 进行深入分析
4. 验证结论
思考预算: 您有 10,000 个思考 Token
- 对最关键的问题分配 80%预算
- 对验证和检查分配 20%预算
- 避免在已确认的部分重复思考
user: "分析这份财务报告..."
```
【推理预算分配规则】
预算分配策略:
```
总预算 = 20,000 tokens
问题分类:
├─ 分析阶段 (40%) = 8,000 tokens
│ ├─ 理解题意
│ ├─ 识别关键信息
│ └─ 列出假设
│
├─ 推理阶段 (40%) = 8,000 tokens
│ ├─ 主体分析
│ ├─ 多角度验证
│ └─ 考虑边界情况
│
└─ 验证与输出 (20%) = 4,000 tokens
├─ 逻辑检查
├─ 矛盾查验
└─ 结论推敲
```
## 6.6.8 实施案例
### 案例 1：金融风险评估
【背景】 任务: 评估高风险贷款申请 特征: 涉及多个风险因素的综合判断 准确率要求: >99% 实时性: 可容许 1-2 分钟延迟 成本预算: 充足
【方案选择】 评估过程: 复杂度: 8.5/10 (多维度风险分析) 准确率需求: >99% (关键业务) 延迟容限: 1-2 分钟 (充足) 成本预算: 充足
结论: ✓ 优先评估 GPT-5.6 Sol，必要时比较 Terra、o3-pro 或 Claude Thinking
【实施方案】 选择: Claude Thinking 或 GPT-5.6 Sol（按自有评测比较质量、成本、延迟和可审计性）
提示词设计:
```yaml
system: |
你是高级金融风险分析师。
对于以下贷款申请，请进行深度风险评估：
评估框架：
1. 申请人信用风险
- 历史征信记录分析
- 还款能力评估
- 负债率计算
2. 项目风险
- 抵押物价值评估
- 行业前景分析
- 市场风险识别
3. 宏观经济风险
- 利率趋势
- 经济周期影响
- 政策风险
4. 综合风险结论
- 风险评级
- 建议额度
- 特殊条款
深度思考指导：
- 充分考虑历史类似案例
- 识别隐藏的风险信号
- 验证所有关键假设
- 考虑黑天鹅事件
user: |
申请人: 张三
...详细贷款信息...
```
【结果】
* 评估时间: 在业务可接受的离线审批窗口内
* 推荐额度: $500,000
* 风险评级: B+ (可接受)
* 特殊条款: 季度业绩报告核实
* 成本: 按实际输入、输出和推理 token 估算
* 用户反馈: 评估透彻，理由充分
【ROI 分析】
* 年申请数: 1,000
* 年成本: 用生产日志中的 token、重试率和人工复核成本计算
* 收益: 以减少坏账、减少审查时间和提升一致性衡量
* ROI: 必须用真实业务数据回算
### 案例 2：法律文件审查
【背景】 任务: 审查合同条款的法律合规性 特征: 需要综合法律知识和详细分析 准确率要求: >98% 实时性: 可容许 5 分钟延迟 成本预算: 中等
【方案选择】 结论: ✓ 使用成本敏感的推理模型候选，并用合同评测集验证收益
【实施】 预算: 标准预算 (自动)
提示词:
```yaml
system: |
你是资深企业法律顾问。
请审查以下合同，在以下方面提供专业意见：
1. 合规性检查
- 与当前法律的一致性
- 国家/地方法规要求
- 行业标准
2. 风险识别
- 对我方的风险条款
- 对对方的风险条款
- 争议解决机制的公平性
3. 改进建议
- 需要修改的条款
- 建议的修改文本
- 优先级排序
4. 谈判策略
- 可以让步的条款
- 必须坚守的条款
- 替代方案
user: |
合同内容...
```
【结果】
* 审查时间: 取决于合同长度、模型和推理预算
* 识别的关键风险: 3 个
* 建议修改: 8 处
* 质量: 用律师标注集和上线后抽检验证
* 成本: 按输入/输出 token、模型价格和人工复核成本估算
【成本对比】
* LLM 成本: 只覆盖模型调用，不包含人工复核、数据清洗和系统运行
* 人工律师成本: 需要按地区、合同类型和复核深度估算
* 节省: 用实际工时减少量与质量指标共同计算
## 6.6.9 监控与持续优化
### 关键指标追踪
```
建立监控仪表板:
[Reasoning 模型性能仪表板]
┌─────────────────────────────────────┐
│ 模型: Adaptive Thinking（Claude） │
├─────────────────────────────────────┤
│ 月度请求数: 2,500 │
│ 质量指标: 自有评测集趋势 │
│ 延迟指标: P50/P95/P99 │
│ 成本指标: 每类任务平均成本 │
│ 成本效益比: 按业务收益回算 │
├─────────────────────────────────────┤
│ 用户满意度: 4.7/5.0 │
│ 问题率: 0.3% │
│ 推荐度: 95% │
└─────────────────────────────────────┘
定期评估周期:
- 日监控: 实时错误告警
- 周评估: 性能趋势分析
- 月评审: ROI 与成本评估
- 季规划: 策略调整与优化
```
## 6.6.10 小结与最佳实践
```
Reasoning 模型决策框架总结：
█ 核心判断标准
├─ 任务复杂度 ≥ 7/10
├─ 准确率需求 > 90%
├─ 可容许延迟 > 20 秒
└─ 成本预算充足
█ 不使用 Reasoning 的信号
├─ 简单任务 (CoT 能解决)
├─ 大批量处理 (成本爆炸)
├─ 实时应用 (延迟太长)
└─ 成本极度敏感的场景
█ 最佳实践
├─ 使用分层策略 (只对关键任务用 Reasoning)
├─ 配置适当的推理预算
├─ 提供明确的推理目标
├─ 持续监控成本-性能指标
└─ 定期评估 ROI 与优化空间
█ 模型选择建议
├─ Claude Thinking: 可返回摘要化 thinking block，是否可用取决于目标模型
├─ GPT-5.6 Sol: 前沿能力优先的复杂任务候选
├─ GPT-5.6 Terra: 能力与成本平衡的生产候选
├─ GPT-5.6 Luna: 高吞吐、低延迟子任务候选
├─ o3-pro: 极高准确率要求或历史兼容需求，再按质量和延迟权衡
└─ 考虑组合使用多个模型进行成本优化
```