你有没有遇到过这种情况。打开 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 模式适合什么场景明确的小需求改一个函数、加一个参数、修一个 bugPlan 已经确认过的复杂任务方案定好了只需要执行纯执行类操作跑测试、安装依赖、格式化代码不适合什么场景需求模糊、涉及多个模块的重构你也不确定怎么改才对的场景第一次接触的代码库五、一个真实案例先 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% 的一次性通过率提升你一分都没吃到。