深度思考模式
上周调试一个复杂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