命令二：/plan —— 先想清楚再动手@explore 帮你搞清楚了“项目现在是什么样”。下一步是“如果要改，应该怎么改”。这时候用 /plan。/plan 是 OpenCode 的主代理（primary agent） 之一，和默认的 Build 平级。你按 Tab 可以在 Build 和 Plan 之间切换。Plan 模式和 Build 模式的核心差异只有一条：Plan 不修改任何文件，Build 会修改文件。Plan 模式禁用了所有写操作——edit 不调，write 不调，有文件写入风险的 bash 命令也被限制。它只做三件事：读相关代码、分析依赖关系、输出实施方案。用法：/plan 我想给这个模块加一个缓存层，你先出一个方案/plan 重构这个函数的逻辑，告诉我改哪些文件、怎么改/plan 把这个项目的日志从 console.log 换成 winston，列一下改动范围Plan 模式会给你一份自然语言的实施计划：涉及哪些文件、每一步改什么、有没有风险点。你看了方案觉得不对，可以调整；觉得没问题，再切到 Build 模式执行。为什么推荐先 /plan 再动手？根据社区数据，复杂重构任务采用“先 Plan 后 Build”的策略，**代码一次性通过率能提升大约 40%**。说白了就是：让 AI 先把方案拿出来给你看，你确认了再让它干，比让它直接干然后你返工要快得多。什么时候用 /plan：需求涉及多个文件、多个模块你不确定改动会波及哪些地方你想先看看 AI 的理解对不对，再让它动手任何“改动范围超过 3 个文件”的事情小改动（改个配置、修个错别字）直接 Build 就行。大改动先 Plan。命令三：/build —— 动手干活这个你可能已经用过了。/build 是 OpenCode 的默认主代理，拥有所有工具的完整权限——读、写、编辑、删文件、跑命令，全都能做。但这里要说的不是怎么用 /build，而是什么时候用。很多人打开 OpenCode 就直接输入需求，默认走的就是 Build 模式。这在两种情况下没问题：改动范围很小，改一行配置、修一个错别字你已经完全理解了这个项目，知道 AI 要改什么、改哪里但在陌生代码库上，直接 /build 的风险在于：AI 可能理解错你的意图，改了你不想改的地方，或者漏掉了关键依赖。
发布于 北京
分享
评论
赞
未登录
友善发言
评论
加载中
