Claude Code 斜杠命令（五）：模型与推理控制
系列目录
AI 辅助编程最容易踩的坑之一，是用同一套默认设置应对所有任务。写个简单的注释和重构一个复杂的多层架构，背后所需的推理深度相差数十倍。盲目使用高算力会浪费金钱，盲目节省算力会让结果质量下降。Claude Code 提供了一组命令，让你精确控制模型选择和推理深度，在速度与质量之间找到最佳平衡。
/model：选择合适的大脑
/model 命令用于在当前会话中切换底层语言模型。
/model claude-opus-4-8
/model claude-sonnet-4-6
/model claude-haiku-4-5
可选模型一览
| 模型 | 模型 ID | 定位 | 适用场景 |
|---|---|---|---|
| Claude Opus 4.8 | claude-opus-4-8 |
最强推理，高成本 | 复杂架构设计、深度调试、长程 agent 任务 |
| Claude Sonnet 4.6 | claude-sonnet-4-6 |
速度与智能的平衡 | 日常编码、代码审查、中等复杂任务 |
| Claude Haiku 4.5 | claude-haiku-4-5 |
最快响应，低成本 | 简单补全、格式化、重复性操作 |
何时换模型
换成 Opus：当你在处理以下任务时——
- 从零设计一套微服务架构
- 调试一个跨越多个抽象层的 bug
- 需要模型对代码做深度语义理解
换成 Haiku：当任务足够简单时——
- 批量生成 JSDoc 注释
- 将一批函数名从 camelCase 转为 snake_case
- 快速回答"这个 API 参数叫什么"
切换命令立即生效，不需要重启会话。
/effort：精确控制推理深度
/effort 是本文的重点。它控制模型在响应前"思考"多少，也直接影响 Token 消耗和响应延迟。
/effort low
/effort medium
/effort high
/effort xhigh
/effort max
/effort ultracode
/effort auto
各级别适用场景对比
| 级别 | 推理深度 | 延迟 | Token 消耗 | 典型场景 |
|---|---|---|---|---|
low |
极浅 | 最快 | 最少 | 简单问答、格式转换、单行补全 |
medium |
适中 | 快 | 较少 | 日常 bug 修复、写单元测试、代码解释 |
high |
深（默认） | 适中 | 适中 | 多文件重构、API 设计、代码审查 |
xhigh |
很深 | 较慢 | 较多 | 复杂算法实现、跨模块依赖分析 |
max |
极深（仅 Opus） | 慢 | 多 | 正确性优先的关键任务，不计成本 |
ultracode |
多 Agent 编排 | 最慢 | 最多 | 大规模并行 agent 工作流 |
auto |
自适应 | 不确定 | 不确定 | 让模型自行判断所需深度 |
实际场景举例：
# 写单元测试 — low 就够了
/effort low
"为 parseDate 函数写5个边界测试用例"
# 重构 auth 模块 — high 比较稳妥
/effort high
"将 auth.js 中的 callback 风格全部改为 async/await，保持功能不变"
# 设计新的缓存架构 — max 确保推理充分
/effort max
"设计一套支持多级缓存的系统，需要考虑 Redis、本地内存和 CDN 的协同"ultracode：多 Agent 工作流编排
ultracode 是一个特殊级别，它会启动多 Agent 并行工作模式。模型不再以单一对话的形式思考，而是将任务拆解成多个子任务，分发给多个并行运行的 agent 分别处理，最后汇总结果。
适用于：
- 需要同时修改项目中数十个文件的大规模重构
- 并行运行多组测试并综合分析结果
- 跨越多个独立模块的代码迁移任务
这个模式延迟高、成本高，但对于真正需要"大规模并行推理"的任务，效果是普通模式无法比拟的。
auto 模式的行为
/effort auto 让模型根据你的提问内容自行判断需要多少推理深度。简单的问题会自动用低 effort，复杂问题会自动加深。
这个模式的缺点是不可预测性较强——你无法提前知道这次请求会花多少时间和 Token。在成本敏感的场景下，建议手动指定级别。
/fast：快速模式开关
/fast 命令开启或关闭"快速模式"（fast mode）。
/fast # 切换 fast mode（开启/关闭）
Fast mode 不等同于 /effort low。主要区别在于：
/effort low：降低推理深度，但模型仍然在进行完整的思考流程，只是思考步骤更少/fast：系统级别的优化，跳过部分内部处理步骤，牺牲一定的响应质量换取更快的响应速度
在实践中，/fast 更适合用于"我只需要一个大概的答案，不需要精确"的探索性对话。例如：
/fast
"这个设计模式叫什么名字？" # 快速确认概念，不需要深度解释
"Python 里怎么读 JSON 文件？" # 已知的简单问题，快速获得提示
如果你需要精确的代码生成或复杂的技术分析，关闭 fast mode。
/plan：计划模式，防止 AI 直接动手
/plan 开启计划模式（plan mode）。
/plan
计划模式的核心作用：让 Claude 只输出"我打算怎么做"，而不直接执行任何文件操作或代码修改。
这是一个重要的安全机制。在没有 plan mode 的情况下，一个含糊的需求可能导致 AI 直接开始修改文件——而你并不确认它理解了你的意图。启用 plan mode 后，Claude 会先呈现完整的执行计划，等你确认再继续。
典型工作流：
/plan
"帮我把项目从 CommonJS 迁移到 ESM"
# Claude 输出：
# 1. 修改 package.json，添加 "type": "module"
# 2. 将所有 require() 改为 import
# 3. 将 module.exports 改为 export default / export
# 4. 更新 Jest 配置以支持 ESM
# 5. 检查所有动态 require() 调用...
# 你确认计划 → 退出 plan mode → Claude 开始执行
这个模式特别适合：
- 影响范围大的重构（修改数十个文件）
- 不可逆操作（删除、重命名、修改配置）
- 你对 AI 将要做的事情不够确定的时候
选择策略决策树
费用影响说明
effort 级别直接影响 Token 消耗，而 Token 是计费的基本单位。
以下是大致的相对消耗比例（实际数值因任务不同而有所差异）：
| 级别 | 相对 Token 消耗 |
|---|---|
low |
1x |
medium |
2–3x |
high |
4–6x |
xhigh |
8–12x |
max |
15–25x |
ultracode |
50x+ |
对于高频使用 Claude Code 的团队，合理设置 effort 可以显著降低月度费用。建议的策略是：为常用的任务类型建立默认 effort 规范，而不是每次都使用默认的 high。
常见误区
误区一：默认 high 就是最好的选择
很多人觉得"反正高 effort 结果更好，那就一直用 high"。但对于简单任务，high 不会带来更好的结果——只会让你等更久、花更多钱。写一个 getter 函数，low 和 max 的输出质量几乎没有区别。
误区二：ultracode 就是"更强的 max"
ultracode 不是单纯的更高推理深度，而是完全不同的工作方式（多 Agent 并行）。用 ultracode 回答一个简单问题，结果可能还不如 medium——因为多 Agent 协调本身会引入额外的复杂性。
误区三：plan mode 会拖慢工作效率
初学者常常跳过 plan mode，觉得多一步确认太麻烦。但在实际使用中，一次因为误解需求而导致的大规模回滚，消耗的时间远超过几次 plan mode 确认。在影响范围不明确时，plan mode 是值得的。
掌握这四个命令的组合使用，你就能让 Claude Code 在每个任务上都以合适的代价给出合适质量的答案。下一篇将介绍如何通过并行 Agent 进一步提升开发效率。
实操清单
- 尝试
/model切换模型，感受不同模型的响应风格 - 为简单任务（写注释、格式转换）设置
/effort low - 为中等任务（bug 修复、单元测试）使用默认
/effort medium - 重要模块重构时使用
/effort high或xhigh - 大范围修改前执行
/plan先确认执行计划再放行 - 探索性对话时开启
/fast体验加速效果 - 建立团队内部的 effort 使用规范，降低月度费用