【OpenCode系统性指南】第3篇：Plan与Build：OpenCode的核心工作流
【OpenCode系统性指南】第3篇：Plan与Build：OpenCode的核心工作流
引言
你是否经历过这样的场景：让AI帮你改代码，结果它一口气改了十几个文件，最后发现改错了方向，只能手动一行行恢复。这不是AI的问题，而是你用错了工作模式。OpenCode（以及Claude Code）提供了Plan和Build两种核心模式，正确使用它们，可以让你的AI编程效率提升数倍，同时大幅降低"改崩代码"的风险。
一、90%的人用错的模式切换
很多开发者打开OpenCode就直接开始提需求："帮我实现一个用户登录功能"。AI立刻开始写代码、改文件、跑命令——看起来很高效，但问题也随之而来：改了哪些文件？为什么要这样改？有没有更简单的方案？这些问题在代码已经写完之后才想起来问，为时已晚。
最常见的错误用法：
- 一上来就Build：不做分析直接执行，结果方向跑偏
- Plan模式当摆设：知道有这个功能但从来不用
- 频繁切换无规律：一会Plan一会Build，AI也跟着混乱
- 不审查直接确认：Plan模式下生成的计划看都不看就切换执行
专业开发者的做法完全不同。根据社区调研，高效用户遵循"80/20法则"——80%的时间用于规划，只有20%的时间用于实际执行。这不是浪费时间，而是把精力放在"想清楚"上，真正动手写代码反而是最快的一步。
二、Plan模式：先想清楚再动手
Plan模式是OpenCode的"只读分析"模式。在这个模式下，AI可以读取你的代码库、搜索文件、分析依赖，但绝对不能修改任何文件或执行任何命令。
什么时候用Plan模式
根据官方文档和实践经验，以下场景强烈推荐使用Plan模式：
| 场景 | 为什么需要Plan |
|---|---|
| 多文件改动 | 功能涉及3个以上文件时，先理清依赖关系 |
| 陌生代码库 | 接手别人的项目，先让AI帮你"看懂" |
| 复杂需求 | 需求描述超过3句话，说明逻辑复杂需要拆解 |
| 安全审计 | 分析代码漏洞但不想改动任何东西 |
| 技术方案评估 | 比较多种实现方案的优劣 |
激活Plan模式的方法
# 方法1：启动时指定
opencode --permission-mode plan
# 方法2：会话中切换（推荐）
按 Tab 键切换模式
# 方法3：Claude Code 用户
按 Shift+Tab 两次：Normal → Auto-Accept → Plan Mode
如何审查AI给出的方案
Plan模式下，AI会生成一份详细的实现计划。不要急着切换到Build模式，先做这几件事：
- 检查完整性：计划是否覆盖了所有需求点？
- 评估复杂度：有没有过度设计的嫌疑？能不能更简单？
- 识别风险点：哪些改动可能影响现有功能？
- 追问细节：对任何不确定的地方要求AI补充说明
一个真实的案例：开发者让AI规划"添加用户头像上传功能"，AI的计划涉及7个文件包括数据库迁移。开发者在Plan模式下追问"能不能只用现有的存储服务"，最终方案精简到只改3个文件，省去了一整天的数据库迁移工作。
迭代优化计划
Plan模式的一大优势是可以反复迭代而不产生任何代码变更。你可以：
- 让AI提供多个方案供选择
- 质疑某个设计决策，要求重新考虑
- 补充新的需求约束，看计划如何调整
- 请AI评估方案的性能影响
记住：Plan模式下的每一次讨论都是免费的，不会留下任何代码债务。而在Build模式下改错一行代码，可能需要半小时来修复。
三、Build模式：放手让AI干活
当你对Plan模式下的方案满意后，就可以切换到Build模式执行了。Build模式是OpenCode的默认模式，AI拥有完整的读写权限，可以修改文件、运行命令、创建新文件。
执行与权限确认
Build模式并不意味着AI可以"为所欲为"。OpenCode内置了权限确认机制：
- 高敏感操作（删除文件、执行bash命令）：默认需要用户确认
- 中等敏感操作（修改现有代码）：根据配置决定
- 低敏感操作（创建新文件、读取文件）：自动执行
这种分层权限设计让你既享受AI的效率，又保持对关键操作的控制权。
/undo与/redo：你的安全网
即使做好了规划，执行过程中也可能出问题。OpenCode提供了强大的撤销机制：
/undo # 撤销上一步操作
/redo # 重做被撤销的操作
/rewind # 回到历史检查点（Claude Code）
检查点（Checkpoint）机制：每次你发送提示给AI，系统都会自动创建一个检查点。这意味着你可以随时"时光倒流"回到任意一个历史状态。
/rewind的四种恢复模式
当你触发/rewind（按Esc两次或输入命令）时，可以选择：
- Restore code and conversation — 完全恢复，代码和对话都回到那个时间点
- Restore conversation only — 只恢复对话历史，保留当前代码状态
- Restore code only — 只恢复文件变更，保留当前对话上下文
- Summarize from here — 压缩之前的对话，释放上下文空间
重要提醒：/rewind追踪的是OpenCode会话内的变更，不会追踪你在会话外手动做的修改，也不会追踪bash命令造成的文件系统变化（如rm、mv）。对于这些情况，Git仍然是你的最终安全保障。
四、一个完整的功能开发演示
让我们通过一个真实案例来演示Plan和Build的完整工作流。假设你要为项目添加"深色模式"功能。
第一步：Plan模式探索
[Plan Mode]
用户：我想给这个React项目添加深色模式，请先分析现有代码结构，
然后给出实现方案。
AI开始读取文件：检查CSS框架、组件结构、状态管理方案。它发现项目使用了Tailwind CSS和Zustand，因此推荐利用Tailwind的dark类和Zustand的持久化存储。
生成的计划：
- 在tailwind.config.js中启用darkMode: 'class'
- 创建useThemeStore管理主题状态
- 添加ThemeToggle组件
- 在根布局监听系统主题偏好
- 更新现有组件的暗色样式
第二步：审查与迭代
用户：第5步需要更新所有组件吗？有没有更简洁的方式？
AI重新分析后建议：使用Tailwind的dark:前缀配合CSS变量，只需要在全局样式中定义颜色变量，组件使用变量即可自动适配，无需逐个修改组件。
第三步：切换Build执行
确认方案后，切换到Build模式：
[Build Mode]
用户：按优化后的方案执行
AI开始执行：修改配置文件、创建store、添加组件。每一步你都可以看到具体的文件变更。
第四步：验证与调整
用户：运行开发服务器，截图看看效果
如果效果不理想，可以使用/undo撤销最近的变更，或者在Plan模式下讨论调整方案。
完整工作流总结
Plan Mode（分析）
↓ 理解需求、探索代码库、制定计划
↓ 用户审查并迭代优化计划
↓ 审查通过
Build Mode（实施）
↓ 执行计划、编写代码
↓ /undo 调整 /redo 恢复
↓ 验证结果
Plan Mode（复盘）—— 如有需要
这个流程看似繁琐，实际上避免了"改了又改"的低效循环。正如一位资深开发者所说："在Plan模式下多花10分钟讨论，往往能省下Build模式下1小时的返工。"
小结
- Plan模式是只读分析：适合探索代码、制定方案、迭代讨论，绝不产生代码变更
- Build模式是执行阶段：确认方案后再执行，配合/undo和/redo实现安全开发
- 遵循80/20法则：80%规划、20%执行，"想清楚"比"动手快"更重要
- 检查点是你的安全网：/rewind可以回到任意历史状态，但Git仍是最终保障