深度思考模式
上週除錯一個複雜bug,試了好幾種方法都沒解決。後來想起用think harder模式,Claude花了2分鐘深度分析,一次性找到了根本原因。
今天聊聊這個深度思考模式。
什麼是深度思考模式
深度思考模式(Extended Thinking)讓Claude在回答前先深度推理。就像老工程師解決問題前會先分析、權衡、預判風險,再動手。
工作原理
啟用深度思考後,Claude會:
- 分析階段:理解問題複雜度和約束
- 推理階段:探索多種方案
- 評估階段:權衡優劣
- 執行階段:選最優方案
關鍵特點:
- 專門的"思考預算"(thinking budget)
- 用專門的token配額思考
- 能看到思考過程
- 適合複雜推理任務
為什麼需要深度思考
簡單任務用標準模式就夠了。但遇到這些情況就需要深度思考:
❌ 标准模式:快速回答,可能漏掉边界情况
✅ 深度思考:全面分析,考虑各种可能
典型場景:
- 架構設計要權衡多個因素
- 複雜效能最佳化
- 要考慮多種邊界情況的演算法
- 大規模程式碼重構
- 系統性診斷
思考模式的層級體系
Claude Code有漸進式思考層級,用關鍵詞觸發:
1. think - 基礎思考模式
觸發方式：
think: 如何优化这个数据库查询？
思考預算： 約4,000 tokens
適用場景：
- 需要簡單推理的問題
- 程式碼審查和建議
- 基本的架構決策
- 常見的bug診斷
特點：
- 快速響應
- 成本較低
- 適合日常開發任務
- 提供基本的推理過程
示例：
你: think: 这个函数有什么潜在问题？
function processUsers(users) {
return users.map(user => {
return {
id: user.id,
name: user.name.toUpperCase(),
email: user.email.toLowerCase()
}
})
}
Claude: [思考过程]
让我分析这个函数的潜在问题：
1. 缺少空值检查
2. 没有处理users为空的情况
3. name和email可能为undefined
4. 没有错误处理机制
[给出改进方案...]
2. think hard - 中等深度思考
觸發方式：
think hard: 如何重构这个复杂的组件？
思考預算： 約10,000 tokens（megathink級別）
適用場景：
- 中等複雜度的架構設計
- 效能最佳化分析
- 第三方API整合方案
- 多檔案的程式碼重構
- 複雜的業務邏輯實現
特點：
- 更深入的分析
- 考慮更多邊界情況
- 提供多種方案對比
- 成本適中
示例：
你: think hard: 设计一个用户权限系统，支持角色、组织层级和资源级别的权限控制
Claude: [深度思考过程]
我需要考虑以下几个维度：
1. 数据模型设计
- 用户、角色、权限的关系
- 组织层级的继承机制
- 资源权限的粒度控制
2. 性能考虑
- 权限查询的优化
- 缓存策略
- 批量权限检查
3. 扩展性
- 新增权限类型的灵活性
- 支持自定义权限规则
- 与现有系统的集成
4. 安全性
- 防止权限提升攻击
- 审计日志
- 默认拒绝原则
[详细设计方案...]
3. think harder - 高強度思考
觸發方式：
think harder: 解决这个分布式系统的一致性问题
思考預算： 約16,000+ tokens
適用場景：
- 複雜的系統架構設計
- 分散式系統問題
- 大規模效能最佳化
- 安全漏洞分析
- 複雜演算法實現
特點：
- 非常深入的推理
- 探索多個解決方向
- 詳細的權衡分析
- 預見潛在問題
- 成本較高
示例：
你: think harder: 我们的微服务系统在高并发下出现数据不一致，如何彻底解决？
当前架构：
- 10个微服务
- MySQL主从复制
- Redis缓存
- 消息队列：RabbitMQ
Claude: [超强思考过程]
这是一个涉及多个层面的复杂问题，我需要系统性地分析：
## 1. 问题根源分析
a) 缓存一致性问题
- Cache-Aside模式的固有延迟
- 缓存失效策略的时序问题
- 分布式缓存的同步延迟
b) 数据库层面
- 主从复制延迟
- 事务隔离级别设置
- 乐观锁vs悲观锁的选择
c) 消息队列
- 消息顺序性问题
- At-least-once vs Exactly-once
- 消费者幂等性保证
## 2. 解决方案矩阵
[分析7-8种可能的解决方案]
## 3. 推荐方案及实施路径
[详细的实施计划...]
## 4. 风险评估与缓解
[潜在风险和应对措施...]
4. ultrathink - 終極思考模式
觸發方式：
ultrathink: 设计一个可扩展的AI推理平台架构
思考預算： 約32,000 tokens（最大）
適用場景：
- 複雜的系統架構從零設計
- 關鍵系統的遷移方案
- 重大技術決策
- 系統性的效能問題排查
- 複雜的演算法最佳化
特點：
- 最深度的推理能力
- 全面的方案探索
- 詳盡的利弊分析
- 長時間的思考過程
- 最高的成本
警告：
⚠️ ultrathink模式仅在必要时使用
- 单次请求可能消耗大量tokens
- 处理时间可能超过几分钟
- 适合关键决策，不适合日常开发
示例：
你: ultrathink: 我们要从单体应用迁移到微服务架构，设计完整的迁移方案
现有系统：
- 10年历史的Rails应用
- 200万行代码
- 50+ 数据库表
- 日活100万用户
- 团队15人
Claude: [终极思考模式]
这是一个需要极其谨慎的重大技术决策，让我进行全面深入的分析：
## 第一部分：现状评估（深度分析）
### 1.1 技术债务盘点
### 1.2 业务模块依赖分析
### 1.3 团队能力评估
### 1.4 业务影响分析
## 第二部分：迁移策略制定
### 2.1 Strangler Fig模式详解
### 2.2 服务拆分原则
### 2.3 数据库拆分策略
### 2.4 分阶段迁移计划
## 第三部分：技术方案设计
### 3.1 微服务框架选型
### 3.2 服务间通信方案
### 3.3 数据一致性保证
### 3.4 监控和可观测性
### 3.5 CI/CD流程设计
## 第四部分：风险管理
### 4.1 技术风险识别
### 4.2 业务连续性保证
### 4.3 回滚机制设计
### 4.4 团队培训计划
## 第五部分：实施路线图
### 第一阶段（1-3个月）：...
### 第二阶段（4-6个月）：...
### 第三阶段（7-12个月）：...
## 第六部分：成功指标与KPI
[详细的度量标准...]
[超过15000字的详细方案...]
思考模式對比表
| 特性 | think | think hard | think harder | ultrathink |
|---|---|---|---|---|
| 思考預算 | ~4K tokens | ~10K tokens | ~16K tokens | ~32K tokens |
| 響應時間 | 快速 | 中等 | 較慢 | 很慢 |
| 分析深度 | 基礎 | 中等 | 深入 | 極深 |
| 適用複雜度 | 簡單任務 | 中等任務 | 複雜任務 | 極複雜任務 |
| 成本 | 低 | 中 | 高 | 很高 |
| 日常使用頻率 | 高 | 中 | 低 | 很低 |
| 推薦場景 | 程式碼審查 | 架構設計 | 系統最佳化 | 重大決策 |
使用示例與效果對比
案例1：資料庫查詢最佳化
任務： 最佳化一個慢查詢
標準模式
你: 这个查询很慢，帮我优化
SELECT * FROM orders
WHERE user_id = 123
AND status = 'pending'
Claude: 可以添加索引：
CREATE INDEX idx_user_status ON orders(user_id, status);
優點： 快速、直接 缺點： 只給出基本建議，沒有深入分析
think模式
你: think: 这个查询很慢，帮我优化
Claude: [思考]
需要考虑：
1. 查询频率
2. 数据量
3. 索引策略
4. 是否需要覆盖索引
建议：
1. 添加复合索引
2. 避免SELECT *
3. 考虑分页
[提供详细的优化方案]
優點： 考慮多個因素，給出更全面的方案 缺點： 可能仍未考慮某些邊界情況
think hard模式
你: think hard: 优化这个慢查询，考虑各种场景
Claude: [深度思考]
全面分析：
1. 当前执行计划分析
2. 索引策略（单列、复合、覆盖）
3. 查询改写可能性
4. 分区表的必要性
5. 缓存策略
6. 读写分离的可行性
7. 不同数据量下的性能预测
提供3种方案：
- 短期快速优化
- 中期架构调整
- 长期扩展方案
優點： 全面、專業、有深度 成本： 更多的思考時間和token消耗
案例2：前端效能最佳化
標準模式響應
建议：
1. 使用React.memo
2. 添加loading状态
3. 使用虚拟滚动
think模式響應
[分析组件渲染次数、状态更新频率]
建议：
1. 组件层面优化（memo、useMemo、useCallback）
2. 状态管理优化
3. 懒加载策略
4. 代码分割
[具体实现代码]
think harder模式響應
[全面的性能审计]
## 1. 性能问题诊断
- 使用Profiler分析渲染瓶颈
- 识别不必要的re-render
- 网络请求优化空间
- Bundle大小分析
## 2. 多维度优化方案
- 组件级优化
- 状态管理重构（Context vs Redux vs Zustand）
- 网络层优化（GraphQL、缓存策略）
- 构建优化（Tree shaking、Code splitting）
- 运行时优化（Web Workers、懒加载）
## 3. 实施计划
- Phase 1: 快速收益优化（1-2天）
- Phase 2: 架构调整（1周）
- Phase 3: 持续监控和优化
## 4. 性能指标设定
- LCP、FID、CLS目标
- 自定义业务指标
- 监控方案
成本分析
Token消耗與費用
Claude Sonnet 4.5的定價（2025年）：
- 輸入token： $3 / 百萬tokens
- 輸出token： $15 / 百萬tokens
- 思考token： 計入輸出token計費
重要提示：
💰 思考过程的所有token都会被计费！
你看到的只是思考总结，实际消耗可能更多。
實際成本示例
示例1：中等複雜任務
输入：2,000 tokens（问题描述）
思考：10,000 tokens（think hard模式）
输出：3,000 tokens（最终答案）
成本计算：
- 输入成本：2,000 × $3 / 1,000,000 = $0.006
- 输出成本：(10,000 + 3,000) × $15 / 1,000,000 = $0.195
- 总成本：$0.201（约1.4元人民币）
示例2：複雜架構設計（ultrathink）
输入：5,000 tokens
思考：32,000 tokens（ultrathink模式）
输出：8,000 tokens
成本计算：
- 输入成本：$0.015
- 输出成本：(32,000 + 8,000) × $15 / 1,000,000 = $0.600
- 总成本：$0.615（约4.3元人民币）
成本最佳化策略
1. 根據任務選擇合適的模式
✅ 简单任务 → 标准模式或think
✅ 中等任务 → think hard
✅ 复杂任务 → think harder
✅ 关键决策 → ultrathink
2. 漸進式使用
先用标准模式尝试
↓ 如果结果不满意
使用think模式
↓ 仍然需要更深入分析
使用think hard
↓ 极少数情况
使用ultrathink
3. 批次處理相關問題
❌ 多次单独提问（浪费上下文token）
✅ 一次性提出相关问题（共享上下文）
成本收益對比
| 場景 | 不用深度思考 | 使用深度思考 | ROI |
|---|---|---|---|
| 除錯複雜bug | 可能走彎路，浪費2小時 | 花費$0.2，節省1.5小時 | 極高 |
| 架構設計 | 可能方案有缺陷，後期返工 | 花費$0.5，避免重大問題 | 很高 |
| 簡單重新命名 | 即時完成 | 不必要的成本 | 負收益 |
| 程式碼審查 | 可能遺漏問題 | 花費$0.1，發現潛在bug | 高 |
何時使用深度思考
推薦使用的場景
1. 架構設計決策
✅ ultrathink: 设计一个可扩展的多租户SaaS架构
✅ think harder: 选择合适的状态管理方案（Redux vs MobX vs Zustand）
✅ think hard: 设计数据库schema，支持复杂的业务关系
2. 效能最佳化
✅ think harder: 解决复杂的性能瓶颈
✅ think hard: 优化大数据量的查询
✅ think: 改进单个函数的性能
3. 複雜問題診斷
✅ think harder: 排查分布式系统的间歇性故障
✅ think hard: 诊断内存泄漏问题
✅ think: 找出简单的逻辑错误
4. 程式碼重構
✅ think harder: 重构大型遗留系统
✅ think hard: 重构复杂的业务模块
✅ think: 重构单个函数或类
5. 安全審計
✅ think harder: 全面的安全审计和渗透测试方案
✅ think hard: 识别潜在的安全漏洞
✅ think: 审查单个功能的安全性
不推薦使用的場景
1. 簡單的CRUD操作
❌ think: 创建一个简单的用户注册表单
✅ 直接问：创建一个用户注册表单
2. 常規的程式碼生成
❌ think hard: 写一个Hello World程序
✅ 直接问：写一个Express路由
3. 簡單的格式化和重新命名
❌ think: 重命名这个变量
✅ 直接操作或简单要求
4. 文件查詢
❌ think: React Hooks的用法是什么？
✅ 直接问：解释React Hooks
決策流程圖
开始
↓
问题是否涉及多个系统/模块？
├─ 是 → 是否需要权衡多个方案？
│ ├─ 是 → 是否关键决策？
│ │ ├─ 是 → ultrathink
│ │ └─ 否 → think harder
│ └─ 否 → think hard
└─ 否 → 是否需要考虑边界情况？
├─ 是 → think
└─ 否 → 标准模式
實際案例：複雜問題的解決過程
案例：電商系統的庫存超賣問題
問題背景
一个电商系统在促销活动中出现了库存超卖问题：
- 高并发场景（QPS 5000+）
- 使用Redis缓存库存
- MySQL存储订单数据
- 微服务架构
- 已有的悲观锁方案影响性能
第一步：使用think模式初步分析
你: think: 我们的电商系统出现库存超卖问题，用了悲观锁后性能很差，怎么办？
Claude: [思考过程]
库存超卖通常由以下原因引起：
1. 缓存与数据库不一致
2. 并发控制不当
3. 事务隔离级别问题
悲观锁性能差的原因：
1. 锁竞争激烈
2. 持锁时间过长
初步建议：
1. 考虑乐观锁（版本号机制）
2. 使用Redis的原子操作（DECR）
3. 预扣库存机制
需要更多信息来提供详细方案。
結果： 給出了方向，但不夠具體。
第二步：使用think hard深入分析
你: think hard: 详细分析库存超卖问题的解决方案
当前架构：
- Nginx → API Gateway → 库存服务 → Redis + MySQL
- 日常QPS 500，促销时达到5000+
- 库存服务使用Spring Boot
- Redis单机，MySQL主从
Claude: [深度思考过程]
## 问题根源深度分析
### 1. 并发控制层面
a) 当前方案（悲观锁）的问题
- SELECT FOR UPDATE导致行锁竞争
- 平均锁等待时间：50ms
- 在5000 QPS下，大量请求超时
b) 缓存层的问题
- Cache-Aside模式的读-改-写不是原子的
- Redis单机成为瓶颈
- 缓存失效时的缓存击穿问题
### 2. 方案对比分析
#### 方案A：Redis原子扣减 + 异步同步DB
**优点：**
- 性能极高（Redis DECR是O(1)）
- 天然防超卖
- 实现简单
**缺点：**
- Redis故障时数据丢失风险
- 需要额外的数据一致性保证机制
**适用性：** ⭐⭐⭐⭐⭐
#### 方案B：乐观锁 + 重试
**优点：**
- 无锁竞争
- 数据库直接保证一致性
**缺点：**
- 高并发下重试次数多
- 用户体验可能受影响
**适用性：** ⭐⭐⭐
#### 方案C：预扣库存 + 延迟确认
**优点：**
- 用户体验好
- 削峰填谷
**缺点：**
- 实现复杂
- 需要定时任务释放预扣
**适用性：** ⭐⭐⭐⭐
### 3. 推荐方案：Redis + 异步同步 + 补偿机制
#### 3.1 实现细节
```lua
-- Redis Lua指令碼，保證原子性
local stock = redis.call('GET', KEYS[1])
if tonumber(stock) >= tonumber(ARGV[1]) then
redis.call('DECRBY', KEYS[1], ARGV[1])
return 1
else
return 0
end
3.2 异步同步方案
- 使用消息队列（Kafka）记录扣减
- 异步worker批量更新数据库
- 每分钟对账一次
3.3 补偿机制
- 定时任务对比Redis和MySQL
- 发现不一致时告警
- 自动或人工介入修正
4. 性能预估
- 预期QPS：10,000+
- 平均响应时间：< 10ms
- 超卖概率：< 0.001%
5. 风险与缓解
- Redis故障 → 主从 + 哨兵
- 消息丢失 → Kafka持久化
- 数据不一致 → 定时对账
[详细的代码实现...]
**結果：** 非常詳細的方案，包含多個視角的分析。
#### 第三步：針對特定問題使用think harder
你: think harder: Redis主从切换时如何保证库存数据不丢失？
Claude: [超深度思考]
这是一个分布式系统的经典难题，涉及CAP理论的权衡...
1. Redis主从切换的数据丢失场景
场景1：异步复制延迟
時間線：
T1: Master執行 DECR stock, 庫存=99
T2: 複製延遲，Slave仍然是100
T3: Master宕機
T4: Slave提升為Master，庫存=100（資料丟失！）
场景2：网络分区
[分析5-6种可能的数据丢失场景]
2. 解决方案矩阵
方案1：Redis Sentinel + WAIT命令
DECR stock
WAIT 1 1000 # 等待至少1個從節點確認，超時1秒
优点： 保证数据已同步到从节点 缺点： 性能下降约30% 可靠性： ⭐⭐⭐⭐
方案2：Redis Cluster + 强一致性配置
方案3：双写Redis + MySQL，以MySQL为准
方案4：Redis + Raft协议（使用Redis 7.0新特性）
方案5：混合方案（关键库存用方案1，普通库存用方案3）
3. 推荐方案及实施
[超详细的实施方案，包含：]
- 配置详解
- 监控指标
- 故障演练
- 回滚计划
- 性能测试结果
4. 成本收益分析
- 开发成本：2人周
- 性能影响：-15%（可接受）
- 可靠性提升：从99.9%到99.99%
- ROI评估：高
[...]
**結果：** 深入到系統級別的分析，考慮了極端情況。
#### 最終實施效果
採用think hard模式提供的方案後：
- ✅ QPS從500提升到8000+
- ✅ 平均響應時間從100ms降到8ms
- ✅ 超賣率從0.5%降到0.001%
- ✅ 促銷活動零事故
**關鍵收穫：**
1. 第一步的think模式給出了方向
2. think hard提供了可實施的詳細方案
3. think harder解決了方案中的關鍵難點
4. 漸進式使用，控制了成本
## 最佳實踐建議
### 1. 漸進式使用策略
遵循"最小必要原则"：
第一次尝试：标准模式 ↓ 结果不满意 第二次尝试：think模式 ↓ 仍需更深入 第三次尝试：think hard ↓ 极少数情况 最后选择：think harder或ultrathink
### 2. 明確你的問題
**不好的提問：**
```text
❌ ultrathink: 优化这个函数
function add(a, b) {
return a + b;
}
好的提問：
✅ think hard: 设计一个高性能的分布式缓存系统
需求：
- 支持10万QPS
- 数据一致性要求高
- 需要支持TTL和LRU
- 支持集群模式
- 故障自动恢复
3. 提供充分的上下文
深度思考模式的效果很大程度取決於你提供的上下文：
✅ 完整的上下文包括：
1. 当前系统架构
2. 技术栈
3. 性能指标
4. 约束条件（成本、时间、人力）
5. 具体的问题表现
6. 已经尝试过的方案
示例：
你: think hard: 优化我们的推荐系统
上下文：
- 当前：基于协同过滤，计算耗时3秒
- 用户量：100万，物品量：10万
- 技术栈：Python + Pandas + Scikit-learn
- 要求：响应时间 < 500ms
- 团队：2个后端，1个算法
- 预算：可以使用云服务
- 尝试过：缓存热门推荐（效果有限）
4. 分解複雜問題
對於超級複雜的問題，即使用ultrathink，也建議分解：
❌ 一次性问：
ultrathink: 设计一个完整的视频网站
✅ 分步骤问：
Step 1 - think harder: 设计视频存储和CDN分发架构
Step 2 - think harder: 设计推荐系统
Step 3 - think hard: 设计用户交互功能
Step 4 - think: 优化前端性能
5. 學會看"思考過程"
Claude的思考過程本身就是寶貴的學習資源：
💡 从思考过程中学习：
- 问题分析的框架
- 权衡的维度
- 专业的思维方式
- 潜在风险的识别方法
6. 迭代最佳化
不要期望一次就得到完美答案：
第一轮：think hard - 获得整体方案
↓ 发现某个细节需要深入
第二轮：think harder - 深入某个子问题
↓ 实施后发现新问题
第三轮：think - 针对性优化
7. 成本意識
在商業專案中使用時，要有成本意識：
✅ 高价值场景：
- 技术选型（影响长期）
- 架构设计（成本高昂）
- 性能优化（业务关键）
- 安全审计（风险重大）
❌ 低价值场景：
- 简单的代码生成
- 常规的bug修复
- 基础的文档编写
8. 結合專業知識
深度思考不是萬能的，要結合你的專業知識：
Claude的优势：
✅ 全面的分析框架
✅ 多方案对比
✅ 识别潜在问题
人类的优势：
✅ 业务理解
✅ 团队情况
✅ 历史经验
✅ 直觉判断
最佳方式：
Claude提供方案 + 人类决策
實用技巧總結
快速參考卡
┌─────────────────────────────────────────────┐
│ 快速决策：我应该用哪个模式？ │
├─────────────────────────────────────────────┤
│ │
│ 日常开发任务 → 标准模式 │
│ 需要简单分析 → think │
│ 架构设计 → think hard │
│ 复杂系统优化 → think harder │
│ 重大技术决策 → ultrathink │
│ │
│ 时间紧急 + 简单问题 → 标准模式 │
│ 时间充足 + 复杂问题 → think harder │
│ 关键决策 + 成本不敏感 → ultrathink │
│ │
└─────────────────────────────────────────────┘
提示詞模板
1. think模式模板
think: [问题描述]
上下文：[简要说明]
期望：[你希望得到什么]
2. think hard模式模板
think hard: [问题描述]
背景：
- 当前状况
- 技术栈
- 约束条件
需求：
- 功能需求
- 性能要求
- 其他要求
请提供：
1. 问题分析
2. 多方案对比
3. 推荐方案及理由
3. ultrathink模式模板
ultrathink: [重大技术决策]
## 系统现状
[详细描述当前架构、技术栈、规模等]
## 问题与挑战
[列出所有已知问题和未来挑战]
## 约束条件
- 时间：[项目时间线]
- 成本：[预算限制]
- 团队：[人力资源]
- 技术：[技术限制]
## 期望输出
1. 全面的问题诊断
2. 多种方案的详细对比
3. 推荐方案的完整设计
4. 实施路线图
5. 风险评估和缓解策略
6. 成功指标定义
常見誤區與避坑指南
誤區1：過度使用深度思考
❌ 错误做法：
每个问题都用ultrathink
✅ 正确做法：
根据问题复杂度选择合适的模式
简单问题用标准模式
复杂问题才用深度思考
誤區2：期望一次完美
❌ 错误期望：
用了ultrathink就能得到完美方案
✅ 现实情况：
深度思考提供的是深入分析和多个方案
仍需要人类判断和迭代优化
誤區3：忽視成本
❌ 不看成本：
频繁使用ultrathink，月底账单爆炸
✅ 成本意识：
记录使用情况
评估ROI
控制预算
誤區4：上下文不足
❌ 模糊提问：
think hard: 优化性能
✅ 详细描述：
think hard: 优化用户列表页面的加载性能
当前情况：
- 加载时间：5秒
- 数据量：10万用户
- 技术栈：React + REST API
- 瓶颈：数据库查询慢
目标：< 1秒
誤區5：忽視思考過程
❌ 只看结果：
快速浏览最终答案就去实施
✅ 学习过程：
仔细阅读思考过程
理解分析框架
学习权衡方法
總結
深度思考模式讓Claude像資深工程師一樣分析問題、權衡方案、預見風險。
核心要點
- 四個層級: think → think hard → think harder → ultrathink
- 思考預算: 4K → 10K → 16K → 32K tokens
- 使用原則: 根據問題複雜度選模式
- 成本意識: 思考過程也計費
- 漸進策略: 從低到高試
- 學習價值: 思考過程本身值得學
使用建議
深度思考很強大,但要正確用:
- ✅ 關鍵決策時用,物有所值
- ✅ 提供充分上下文
- ✅ 學習思考過程
- ✅ 結合專業知識做決策
- ❌ 別為簡單問題過度使用
- ❌ 別期望一次就完美
- ❌ 別忽視成本
掌握深度思考模式,讓Claude Code成為你的高階技術顧問!
進一步學習
- Agent模式 - 瞭解如何讓Claude自主探索和解決問題
- CLAUDE.md配置 - 為專案定製Claude的行為
- 最佳實踐 - 學習更多提示詞技巧
參考資料
本文參考了以下資料和官方文件：
- Building with extended thinking - Claude Docs
- Extended thinking tips - Claude Docs
- The "think" tool: Enabling Claude to stop and think
- Claude Code: Best practices for agentic coding
- Unlock Claude Code's Thinking Modes: From 'think' to 'ultrathink'
- What is UltraThink in Claude Code
- Claude Code Thinking Levels: From Think to Ultra-Think
- Claude 3.7 API Pricing Guide 2025
- Claude Pricing: A 2025 Guide To Anthropic AI Costs