先说一下核心判断：大部分人在使用OpenCode时，其实都在用错误的方式。

你有没有遇到过这种情况——打开OpenCode，丢给它一个需求：“帮我把这个模块的鉴权逻辑重构一下”。几秒钟后，终端里开始刷刷刷地生成代码。心里暗爽：AI真快。

但读到一半你发现问题了。它理解错了。它以为你要改的是A模块，实际上你要改的是B模块。它以为你要用JWT，实际上你用Session。

代码已经写了一大半。改回去？还是将就着用？

这个场景太常见了。

很多人在用OpenCode的时候，根本搞不清楚Plan和Build到底有什么区别。反正都是让AI干活，有什么区别？区别大了。

一、大多数人都在用错模式

先看一个数据。

根据社区测试，采用“先Plan后Build”策略的复杂重构任务，代码一次性通过率提升了约40%。这个数字意味着什么？如果正在做一个中等规模的重构，用对模式，一次搞定的概率从五五开变成了接近八成。

但现实是，大部分人打开OpenCode就直接开干。输入需求，AI直接进入Build模式开始改文件。快是快，但快不一定对。

问题出在哪？

绝大多数AI编程工具（包括Cursor和Copilot）的工作逻辑是：你给一个需求，它直接生成代码。用户习惯了这种“即时响应”的模式。OpenCode把“规划”和“执行”拆成了两个独立的阶段，但用户的大脑还停留在“一个需求=一个输出”的旧模式里。

于是出现了两种典型错误：

第一种，啥需求都用Build。改一个按钮颜色用Build，重构整个模块也用Build。小需求没问题，大需求翻车率极高。

第二种，啥需求都用Plan。改一行配置也要先让AI出个三页的方案。杀鸡用牛刀，效率直接归零。

不是Plan好还是Build好。是在对的场景用对的模式。

二、Build不是Plan的“升级版”——它们是两个东西

先厘清一个最普遍的误解。

很多人以为Plan和Build是“简略版”和“完整版”的关系——Plan是轻量级方案，Build是重拳出击。不对。

Plan模式和Build模式的核心差异在于：Plan不修改任何文件，Build会修改文件。

就这么简单。

Plan模式禁用了所有写操作。你不能用Plan模式改代码，它根本不会调用edit、write这些工具。它只做一件事：读代码、分析、输出方案。

Build模式拥有完整的工具权限。可以读文件、写文件、改文件、跑命令、删文件——所有操作都能做。

所以Plan和Build不是程度差异，是权限差异。

Plan = 只读+输出方案。Build=读写+执行操作。

搞清楚这个，你就明白了一半。

三、Plan模式到底在做什么

Plan模式的定位是“只动脑不动手”。

你给它一个需求，它会：

第一步，读取相关代码。它通过read工具读取你指定的文件，或者通过grep搜索相关代码片段。

第二步，分析依赖关系。它要搞清楚这个需求涉及哪些模块、哪些函数、哪些数据流。

第三步，输出实施方案。用自然语言描述它打算怎么做，分几步，每一步改什么。

整个过程中，它不会调用任何修改类工具。edit不调，write不调，bash也不调（有文件写入风险的命令也被限制）。

Plan模式的核心价值是什么？

把“理解偏差”消灭在执行之前。

AI编程最常翻车的地方，不是它写代码的能力不行，是它理解需求的能力有偏差。你描述一个需求，它按自己的理解开始写，写到一半你发现问题——但已经晚了。要么回滚，要么将就。

Plan模式让你在它动手之前，先看到它打算怎么做。方案不对？继续对话修正。方向偏了？调整描述重新规划。直到方案完全符合你的预期，再切到Build模式执行。

怎么切到Plan模式？

按Tab键。状态栏会显示当前模式。你也可以直接输入/plan命令切换到规划模式。

GitLab的官方指南里有一句话：任何非trivial的任务，永远先跑Plan。

四、Build模式到底在做什么

Build模式的定位是“全能施工包工头”。

它拥有OpenCode全部内置工具的访问权限：glob、grep、read、edit、write、bash、patch……所有工具都能调。

你给一个需求，它直接开始干活。建文件、改代码、删文件、跑测试、查日志——全自动。

Build模式默认就是OpenCode的启动模式。你输入一个需求，如果不做任何切换，它就在Build模式下执行。

但这里有个关键点：Build模式不负责“想清楚”，它只负责“干完活”。

这就是为什么Plan和Build要搭配使用。Plan负责想，Build负责干。分开，各自做到极致。合在一起，形成完整的“规划-执行”闭环。

Build模式适合什么场景？

• 明确的小需求：改一个函数、加一个参数、修一个bug
• Plan已经确认过的复杂任务：方案定好了，只需要执行
• 纯执行类操作：跑测试、安装依赖、格式化代码

不适合什么场景？

• 需求模糊、涉及多个模块的重构
• 你也不确定怎么改才对的场景
• 第一次接触的代码库

五、一个真实案例：先Plan后Build的完整流程

假设你在维护一个电商项目。接到一个需求：把订单模块的日志从console.log全部替换成结构化日志（JSON格式，包含timestamp、level、module、message四个字段）。

涉及15个文件，横跨3个子模块。

如果你直接用Build模式：

AI收到需求，开始扫描文件、定位console.log、逐个替换。但它不知道你要的结构化格式具体什么样，不知道哪些日志需要保留哪些可以删，不知道替换后会不会破坏业务逻辑。改到第8个文件的时候，你可能发现方向偏了——但已经改了一半。

如果你先Plan后Build：

第一步，按Tab切到Plan模式。

第二步，输入需求。AI开始读取订单模块的所有文件，分析console.log的使用情况，输出一份方案：

• 发现47处console.log分布在15个文件中
• 建议统一替换为logger.info()、logger.error()等结构化方法
• 列出需要新建的logger.ts工具文件
• 标注3处特殊日志需要人工确认（包含敏感信息）

第三步，你审阅方案。发现它漏掉了错误堆栈的记录。补充说明后，AI更新方案。

第四步，方案确认无误。按Tab切到Build模式，输入“按方案执行”。

第五步，AI开始批量修改。15个文件全部改完，自动运行测试，通过。

整个流程，从规划到执行，耗时不到20分钟。如果没有Plan模式兜底，你大概率要在第10分钟的时候喊停，然后花更多时间收拾残局。

这就是Plan模式的价值：它不是在拖慢你，是在帮你避免走错路之后花更多时间绕回来。

六、对你意味着什么

如果你还在把所有需求都直接丢给Build模式，你正在错过OpenCode最核心的设计。

Plan和Build的分离，本质上是把“决策”和“执行”解耦。

人在做复杂决策的时候容易出错，AI也是。但人审阅方案的能力远强于在代码执行到一半的时候发现问题。Plan模式把AI的“决策过程”暴露出来，让人在关键节点介入，把错误拦截在早期。

这个设计思路不只适用于OpenCode。

它适用于任何你使用AI编程工具的场景：让AI先输出方案，你再审阅，确认后执行。

对三类人来说，这意味着不同的东西：

• 在校生：你需要理解的不只是“Plan怎么用、Build怎么用”，而是“为什么需要把规划和执行分开”。这个思维模式，比具体操作重要得多。
• 初级工程师：如果你正在用OpenCode但经常翻车，先检查一下自己是不是直接用了Build模式。养成“先Plan后Build”的习惯，一次性通过率能翻倍。
• 中级工程师：你需要思考的是——你们团队有没有建立“AI编程的质量门禁”？Plan模式就是一个天然的“方案评审”环节。谁在审Plan？审什么？怎么把Plan的输出沉淀成团队的文档资产？这些是下一步要解决的问题。

七、一个问题

最后，不总结了。

问你一个实际的问题：

你最近一次用AI编程工具做复杂重构的时候，是先让AI出方案再执行，还是直接让它动手的？

如果答案是后者，那40%的一次性通过率提升，你一分都没吃到。