你有没有遇到过这种情况。
打开 OpenCode，丢给它一个需求——“帮我把这个模块的鉴权逻辑重构一下”。几秒钟后，终端里开始刷刷刷地生成代码。你心里暗爽：AI 真快。
但读到一半你发现问题了。它理解错了。它以为你要改的是 A 模块，实际上你要改的是 B 模块。它以为你要用 JWT，实际上你用 Session。
代码已经写了一大半。改回去？还是将就着用？
这个场景太常见了。
很多人在用 OpenCode 的时候，根本搞不清楚 Plan 和 Build 到底有什么区别。反正都是让 AI 干活，有什么区别？区别大了。
目录
一、大多数人都在用错模式
二、Build 不是 Plan 的“升级版”——它们是两个东西
三、Plan 模式到底在做什么
四、Build 模式到底在做什么
五、一个真实案例：先 Plan 后 Build 的完整流程
六、对你意味着什么
七、一个问题
一、大多数人都在用错模式
先看一个数据。
根据社区测试，采用“先 Plan 后 Build”策略的复杂重构任务，代码一次性通过率提升了约 40%。
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% 的一次性通过率提升，你一分都没吃到。
