Chain-of-Thought
Chain-of-Thought Prompting
⭐ 简洁
3 个要素
⏱️ 5 分钟学习
📦 组成要素
P
问题 Problem
明确问题
S
步骤 Steps
要求逐步推理
C
结论 Conclusion
给出最终结论
✅ 适合
算法设计、逻辑推理
📖 详细说明
Prompt 框架:Chain-of-Thought(思维链)
Chain-of-Thought 框架概述
Chain-of-Thought(CoT) 是一个强调逐步推理和过程透明的 Prompt 框架,特别适合复杂算法设计和逻辑推理场景。
核心思想:要求 AI 一步步思考(think step-by-step),而不是直接给答案。这让 AI 能够:
- 拆解复杂问题
- 显示推理过程
- 提高答案准确性
- 便于验证逻辑
特点
| 特点 | 说明 |
|---|---|
| 学习曲线 | 低,只需加一句"请一步步思考" |
| 适用场景 | 算法设计、逻辑推理、问题求解 |
| 框架复杂度 | ⭐ 简洁(可用于增强其他框架) |
| 有效性 | ⭐⭐⭐⭐ 很高 |
| 迭代性 | 中等 |
| 组合性 | 强(可与其他框架组合) |
CoT 的优势
✅ 提高准确性 - 研究表明 CoT 能显著提升复杂任务的正确率 ✅ 过程透明 - 可以验证 AI 的推理是否合理 ✅ 易于学习 - AI 的思路变成你的学习材料 ✅ 易于组合 - 可以和任何框架组合使用 ✅ 适合调试 - 看不懂答案时,查看推理过程
CoT 的局限
❌ 响应较长 - 需要展示所有推理步骤 ❌ 有时过度 - 简单问题可能显得繁琐 ❌ 不保证正确 - 推理过程长也不保证每步都对
模板
问题:[你的问题]
要求:请按以下步骤一步步思考和回答:
1. [第一步:理解问题]
2. [第二步:分析关键点]
3. [第三步:推导方案]
4. [第四步:验证答案]
最后给出总结答案。
或更简单的版本:
问题:[你的问题]
要求:请一步步思考,展示完整的推理过程,然后再给最终答案。
相关框架比较
| 维度 | Chain-of-Thought | BROKE | CRISPE |
|---|---|---|---|
| 强调 | 推理过程 | 明确约束 | 深度洞察 |
| 组合性 | 强(可增强其他框架) | 独立使用 | 独立使用 |
| 答案长度 | 长(包含推理) | 短(直接答案) | 中等 |
| 适用问题 | 复杂逻辑 | 明确需求 | 复杂分析 |
| 学习成本 | 极低 | 低 | 中 |
应用实践
实践1:算法设计与分析
问题描述:设计一个高效的数据结构来解决问题
问题:
设计一个 LRU(Least Recently Used)缓存,需要支持:
- get(key) - O(1) 时间复杂度
- put(key, value) - O(1) 时间复杂度
- 最多缓存 N 个键值对
请用 Java 实现。
要求:
1. 分析问题的关键点
2. 解释为什么需要用哪些数据结构(HashMap、LinkedList)
3. 逐步展示实现思路
4. 给出完整的 Java 代码
5. 分析时间和空间复杂度
预期回答:
- AI 会分析为什么 LRU 需要快速查找(HashMap)和维护顺序(LinkedList)
- 展示 HashMap 和 Double-LinkedList 的组合设计
- 逐步实现 get 和 put 操作
- 解释每步的时间复杂度
实践2:性能优化诊断
问题描述:分析为什么代码性能差
问题:
以下代码在处理 100万条数据时很慢,为什么?应该怎么优化?
```java
List<User> users = database.queryAllUsers(); // 100万条
List<String> activeEmails = new ArrayList<>();
for (User user : users) {
if (user.isActive() && user.getEmail() != null) {
activeEmails.add(user.getEmail());
}
}
要求:
- 一步步分析瓶颈在哪
- 分析当前代码的时间复杂度
- 提出改进方案(可以考虑数据库、流处理等)
- 给出改进后的代码
- 预期的性能提升
**预期回答**:
1. AI 会分析 queryAllUsers() 的成本、内存占用
2. 指出"在应用层过滤"的问题
3. 建议"在数据库层过滤"
4. 给出 SQL 和 Stream 两种优化方案
---
### 实践3:架构决策验证
**问题描述**:验证架构方案的合理性
```text
问题:
我设计的微服务通信方案是:
1. 服务间使用 REST 调用
2. 每次调用都同步等待响应
3. 如果被调用方超时,调用方等待 30秒
这个设计有什么问题?有更好的方案吗?
要求:
1. 分析我的方案的潜在问题
2. 逐步推导问题会如何演变(级联失败)
3. 解释异步或消息队列方案的优势
4. 给出改进的架构方案
5. 对比不同方案的优缺点
预期回答:
- AI 分析同步调用的级联失败风险
- 展示"一个慢服务导致整体瘫痪"的场景
- 推荐异步调用、消息队列、断路器等模式
- 给出具体的实现示例
Chain-of-Thought 最佳实践
✅ 做这些事
-
明确要求展示步骤
✅ 请一步步思考,最后给答案 ✅ 分析问题、给出方案、验证答案 -
对复杂问题特别有效
- 算法设计
- 逻辑推理
- 决策分析
-
结合其他框架
[Role] ... [Background] ... 要求:请一步步思考,展示推理过程
❌ 避免这些事
-
对简单问题过度使用
- ❌ "写一个 getter 方法,请一步步思考"
- ✅ "简单问题直接答"
-
不指定步骤数
- ❌ "请思考"
- ✅ "请分成5个步骤回答"
-
对工程化问题不够明确
- ❌ 只要求推理,不要求代码
- ✅ 既要求推理过程,也要代码实现