规划者（Planner）
模型：Opus
策略规划，只读探索。
name: plannermodel: opustools: Read, Grep, Glob模型选择与思维指南
为每个任务选择正确的模型是大多数 Claude Code 用户最快获得投资回报的改进方式。一个任务一个决定 — 不需要过度思考。
| 任务 | 模型 | 工作量 | 每任务估算成本 |
|---|---|---|---|
| 重命名、格式化、样板代码 | Haiku | 低 | ~$0.02 |
| 生成单元测试 | Haiku | 低 | ~$0.03 |
| CI/CD PR 审查（批量） | Haiku | 低 | ~$0.02 |
| 功能开发、标准调试 | Sonnet | 中 | ~$0.23 |
| 模块重构 | Sonnet | 高 | ~$0.75 |
| 系统架构 | Opus | 高 | ~$1.25 |
| 关键安全审计 | Opus | 最高 | ~$2+ |
| 多 Agent 编排 | Sonnet + Haiku | 混合 | 可变 |
工作量级别（Effort Levels）
Section titled “工作量级别（Effort Levels）”effort 参数（Opus 4.6 API）控制模型的整体计算预算 — 不仅是思考 token，还包括工具调用、输出详细程度和分析深度。
机械性操作，无需设计决策
"将 src/ 中的 getUserById 重命名为 findUserById"— 查找替换范围，零推理需求。
明确模式，定义范围，单一关注
"将 api/users.ts 中的 fetchUser() 从回调转换为 async/await"— 模式已知，范围有界。
设计决策，边缘情况，多个关注点
"重新设计支付模块的错误处理：添加重试逻辑、部分失败恢复和幂等性保证"— 架构选择，不仅仅是模式应用。
跨系统推理，不可逆决策（仅 Opus 4.6）
"分析微服务事件管道中 order-service、inventory-service 和 notification-service 之间的竞态条件"— 多服务假设测试，对抗性思维。
Agent 模型分配模式
Section titled “Agent 模型分配模式”根据角色而非重要性为 Agent 分配模型：
执行者（Implementer）
模型：Haiku
机械性执行，有界范围。
name: implementermodel: haikutools: Write, Edit, Bash, Read, Grep, Glob架构审查者
模型：Opus
关键设计审查，只读。
name: architecture-reviewermodel: opustools: Read, Grep, Glob思考模式：何时开启 vs 浪费 Token
Section titled “思考模式：何时开启 vs 浪费 Token”| 场景 | 思考模式 | 原因 |
|---|---|---|
| 重命名 50 个文件 | 关闭 | 零推理 — 纯机械操作 |
| 跨 3+ 服务的 Bug | 开启（高） | 多层假设测试 |
| 样板代码/测试生成 | 关闭 | 重复模式，无决策 |
| 架构迁移 | 开启（最高） | 不可逆决策 |
| 直接的事实性问题 | 关闭（低） | 立即回答就够了 |
| 安全代码审查 | 开启（高） | 需要对抗性推理 |
切换方式：Alt+T（当前会话） / /config（永久设置）
理解 Claude 的思维方式
Section titled “理解 Claude 的思维方式”理解 Claude Code 如何”思考”能让你更加高效。
Claude 的项目视图
Section titled “Claude 的项目视图”┌─────────────────────────────────────────────────────────┐│ 你的项目 │├─────────────────────────────────────────────────────────┤│ ││ ┌─────────────┐ ┌─────────────┐ ┌───────────┐ ││ │ 文件 │ │ Git │ │ 配置 │ ││ │ (.ts,.py) │ │ 历史 │ │ 文件 │ ││ └─────────────┘ └─────────────┘ └───────────┘ ││ │ │ │ ││ ▼ ▼ ▼ ││ ┌─────────────────────────────────────────────────┐ ││ │ Claude 的理解 │ ││ │ - 文件结构与关联 │ ││ │ - 代码模式与约定 │ ││ │ - 最近的更改（来自 git） │ ││ │ - 项目规则（来自 CLAUDE.md） │ ││ └─────────────────────────────────────────────────┘ ││ │└─────────────────────────────────────────────────────────┘Claude 知道什么 vs 不知道什么
Section titled “Claude 知道什么 vs 不知道什么”| 能力 | 说明 |
|---|---|
| 文件结构 | 可以导航和搜索你的文件 |
| 代码内容 | 可以读取和理解代码 |
| Git 状态 | 可以看到分支、提交、变更 |
| 项目规则 | 读取 CLAUDE.md 中的约定 |
| 限制 | 说明 |
|---|---|
| 运行时状态 | 无法看到正在运行的进程 |
| 外部服务 | 无法直接访问你的数据库 |
| 你的意图 | 需要清晰的指令 |
| 隐藏文件 | 默认遵循 .gitignore |
把自己想象成 CPU 调度器。Claude Code 实例是工作线程。你不写代码 — 你编排工作。
┌─────────────────────────────────────────┐│ 你（主线程） ││ ┌────────────────────────────────────┐ ││ │ 职责： │ ││ │ • 定义任务和优先级 │ ││ │ • 分配上下文预算 │ ││ │ • 审查输出 │ ││ │ • 做架构决策 │ ││ │ • 处理异常/升级 │ ││ └────────────────────────────────────┘ ││ │ │ │ ││ ┌────▼───┐ ┌────▼───┐ ┌────▼───┐ ││ │Worker 1│ │Worker 2│ │Worker 3│ ││ │(Claude)│ │(Claude)│ │(Claude)│ ││ │ 功能 │ │ 测试 │ │ 审查 │ ││ └────────┘ └────────┘ └────────┘ │└─────────────────────────────────────────┘实际含义：
- 不要写代码 — 当 Claude 能做时。你的时间用于决策，而非敲击键盘
- 不要微观管理 — 给出清晰的指令，然后审查结果
- 有意地切换上下文 — 像调度器一样批量处理类似任务
- 自己做升级 — 当 Claude 卡住时介入，然后交还
从聊天机器人到上下文系统
Section titled “从聊天机器人到上下文系统”最常见的错误是把 Claude Code 当作聊天机器人 — 输入临时请求，希望得到好的输出。区分随意使用和生产级工作流的关键在于思维转变：
聊天机器人模式：你写好的提示。上下文系统：你构建结构化的上下文，让每个提示都变得更好。
四层持久上下文
Section titled “四层持久上下文”Claude Code 有四层会随时间复合的持久上下文：
| 层级 | 作用 | 何时设置 |
|---|---|---|
| CLAUDE.md | 持久规则、约定、项目知识 | 第 1 周 |
| Skills | 可复用的知识模块，保证一致的工作流 | 第 2 周 |
| Hooks | 自动化护栏（lint、安全、格式化） | 第 2-3 周 |
| 项目记忆 | 跨会话的决策和架构上下文 | 持续 |
这些不是独立的功能，而是同一系统的层级：
- CLAUDE.md 教会 Claude 你的项目需要什么
- Skills 教会 Claude 如何执行特定工作流
- Hooks 自动强制执行护栏
- Memory 跨会话保留决策
转变前后对比
Section titled “转变前后对比”“使用 pnpm，不要用 npm。记住我们的命名约定是…”
(每次会话都要重复。每次都要。复制粘贴上下文。)
CLAUDE.md 自动加载约定。Skills 保证一致的工作流。Hooks 零人工努力强制质量。Memory 将决策传递到未来。
好的提示和差的提示之间差距巨大：
src/auth/login.ts 中的登录函数没有正确验证邮箱地址。加号应该被允许但被拒绝了。登录坏了你提供的上下文越多，Claude 就能更好地帮助你。