Claude Code 的 Opus Plan 模式：让 AI 先思考再动手

上周在用 Claude Code 重构一个老项目时，我犯了个错误：直接让 Claude 开始改代码，结果它改了十几个文件，测试全挂了。回滚之后，我换了个方式——先让它进入 Plan 模式，把整个重构方案写成文档，我审核通过后再执行。这次一次成功。

这让我意识到，AI 编程工具最大的问题不是写不出代码，而是”想都不想就开始干”。

Plan 模式解决什么问题

传统的 AI 编程助手（包括 Claude Code 的默认模式）工作方式是：你说一句话，它立刻开始改代码。这在处理简单任务时没问题，但遇到复杂场景就容易翻车。

想象一下这个场景：你让 Claude 给 API 添加分页功能。它可能会：

• 修改路由处理函数
• 更新数据库查询
• 调整返回格式
• 修改前端调用代码

如果它对现有架构理解有偏差，可能会破坏现有的缓存层，或者忽略了 ORM 的约定，或者重复实现了已有的工具函数。等你发现问题时，已经改了一堆文件。

Plan 模式的核心思路是：把”思考”和”执行”分开。

在 Plan 模式下，Claude 只能读代码、搜索文件、查资料，但不能修改任何东西。它会先写一份详细的实施计划，你审核通过后，它才开始真正动手。

Opus Plan：两个模型的最佳组合

Claude Code 最近推出了一个叫 opusplan 的模型配置，这是个很聪明的设计。

它的工作方式是：

• 规划阶段：使用 Opus 4.6（最强推理能力）
• 执行阶段：自动切换到 Sonnet 4.6（速度快、成本低）

为什么这样设计？因为规划和执行需要的能力不一样。

规划需要：

• 深度理解代码库的架构
• 识别潜在的依赖关系和冲突
• 权衡不同实现方案的利弊
• 预见可能的边界情况

执行需要：

• 快速生成代码
• 准确实现既定方案
• 处理语法细节

Opus 4.6 在规划方面的能力是目前最强的。它能把复杂任务拆解成独立的子任务，并行运行工具和子代理，精准识别阻塞点。但它也更贵、更慢。

Sonnet 4.6 在执行方面足够好，而且快得多。当方案已经确定，只需要”照着做”时，用 Sonnet 就够了。

这种组合让你既能享受 Opus 的智慧，又不用为每一行代码都付 Opus 的价格。

Plan 模式的实际工作流程

让我用一个真实案例来说明 Plan 模式是怎么工作的。

假设你要给一个电商系统添加”用户收藏商品”功能。

第一步：激活 Plan 模式

在 Claude Code 中按两次 Shift+Tab，或者输入 /plan 命令。底部会显示 ⏸ plan mode on。

如果你想用 Opus Plan 模式，输入 /model 选择 “Use Opus in plan mode, Sonnet 4.6 otherwise”。

第二步：描述任务

你可以这样说：

我想添加用户收藏商品的功能。用户可以收藏商品，查看收藏列表，取消收藏。需要考虑并发场景，避免重复收藏。

第三步：Claude 提问

这是 Opus Plan 模式的一个重要特性——它会主动问你问题，而不是自己瞎猜。

它可能会问：

• 收藏数据存在哪里？独立表还是用户表的关联？
• 需要记录收藏时间吗？
• 商品被删除后，收藏记录怎么处理？
• 收藏列表需要分页吗？
• 前端是 React 还是 Vue？

你回答这些问题，帮助 Claude 理解你的真实需求。

第四步：Claude 生成计划

Claude 会创建一个 plan.md 文件，里面包含：

## 实施方案

### 1. 数据库设计
创建 favorites 表：
- user_id (外键)
- product_id (外键)
- created_at
- 唯一索引：(user_id, product_id)

### 2. 后端 API
- POST /api/favorites - 添加收藏
- GET /api/favorites - 获取收藏列表（支持分页）
- DELETE /api/favorites/:id - 取消收藏

### 3. 前端组件
- FavoriteButton 组件
- FavoriteList 页面

### 4. 需要修改的文件
- backend/models/favorite.js (新建)
- backend/routes/favorites.js (新建)
- frontend/components/FavoriteButton.jsx (新建)
- frontend/pages/FavoriteList.jsx (新建)

### 5. 注意事项
- 使用数据库唯一索引防止重复收藏
- API 需要身份验证中间件
- 前端需要乐观更新提升体验

第五步：你审核和修改

这是最关键的一步。你打开 plan.md，仔细审核：

• 数据库设计合理吗？
• API 设计符合现有规范吗？
• 有没有遗漏的边界情况？
• 实现方案是否过度设计？

你可以直接在文件里添加注释：

### 2. 后端 API
- POST /api/favorites - 添加收藏
  **注：这里应该用 PUT，因为是幂等操作**
- GET /api/favorites - 获取收藏列表（支持分页）
  **注：使用游标分页，不要用 offset**

然后告诉 Claude：

我在 plan.md 里加了一些注释，请根据注释更新计划。

Claude 会读取你的注释，更新计划。这个过程可能重复 3-5 次，直到你满意为止。

第六步：执行

当计划完善后，你退出 Plan 模式（再按 Shift+Tab），然后说：

按照 plan.md 执行实施。

如果你用的是 Opus Plan 模式，这时会自动切换到 Sonnet 4.6 来执行。Claude 会严格按照计划文件来实施，不会自作主张。

为什么这个工作流这么有效

我用了几个月 Plan 模式后，发现它解决了 AI 编程的几个核心问题：

1. 防止”想当然”

AI 经常会基于不完整的信息做假设。Plan 模式强制它先把假设写出来，你可以在执行前纠正。

2. 保持架构一致性

通过审核计划，你能确保新代码符合现有的架构模式和编码规范。

3. 减少返工

一次性把方案想清楚，比改了一半发现方向错了要高效得多。

4. 知识传递

计划文档本身就是很好的技术文档，记录了”为什么这样做”。

5. 控制成本

Opus Plan 模式让你只在需要深度思考的时候用 Opus，执行时用更便宜的 Sonnet。

什么时候应该用 Plan 模式

不是所有任务都需要 Plan 模式。我的经验是：

适合用 Plan 模式：

• 多文件修改（超过 3 个文件）
• 架构级别的改动
• 不熟悉的代码库
• 有多种实现方案需要权衡
• 涉及数据库 schema 变更
• 需要考虑向后兼容性

不需要 Plan 模式：

• 修复明显的 bug
• 添加简单的工具函数
• 调整样式和布局
• 重命名变量或函数
• 添加日志或注释

简单说：如果你自己动手前也会先想一想方案，那就用 Plan 模式。

一些实用技巧

技巧 1：用好”深度研究”指令

在 Plan 模式下，你可以让 Claude 先深度研究代码库：

深入研究通知系统的实现，理解所有细节和特殊情况，把发现写到 research.md

“深入”、”所有细节”这些词很重要，否则 Claude 会浅尝辄止。

技巧 2：提供参考实现

如果你见过类似功能的好实现，直接贴给 Claude：

这是另一个项目里的分页实现（贴代码），参考这个写一个适合我们项目的方案。

有具体参考比让它从零设计要靠谱得多。

技巧 3：分阶段执行

对于大型任务，可以把计划拆成多个阶段，每个阶段单独执行和测试：

先只执行计划的第 1、2 步，其他的等我测试通过后再做。

技巧 4：保留计划文档

把 plan.md 和 research.md 提交到 Git。它们是很好的技术文档，记录了设计决策的上下文。

写在最后

Opus Plan 模式体现了一个重要理念：AI 不应该是一个”立刻执行”的工具，而应该是一个”先思考再执行”的协作伙伴。

传统的 AI 编程助手像一个急性子的初级程序员，你说什么它立刻就做，经常做错。Plan 模式让 AI 更像一个有经验的工程师，会先理解需求、设计方案、和你讨论，确认无误后再动手。

这种工作方式不仅能产出更好的代码，还能让你保持对项目的控制权。你不是在”监督”AI 的输出，而是在”指导”它的思路。

如果你在用 Claude Code，强烈建议试试 Opus Plan 模式。特别是在处理复杂任务时，多花几分钟审核计划，能省下几小时的返工时间。

你在用 AI 编程工具时，是直接让它写代码，还是会先让它做计划？欢迎在评论区分享你的经验。