霍格沃兹测试开发学社
四、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 处特殊日志需要人工确认（包含敏感信息）
发布于 北京
分享
评论
赞
未登录
友善发言
评论
加载中
