很多项目延期，并不是因为代码写得慢，而是因为一开始就写错了方向。

需求只看了一半就开工，做到后面才发现权限边界没考虑；接口已经接完，才发现状态流转和产品预期不一致；页面开发完成，测试一跑才发现异常场景完全没覆盖；代码写了很多，最后却因为架构不合适不得不推倒重来。

这类问题在开发中很常见。

它们表面上是代码问题，本质上却是方案问题。

所以我越来越认同一个观点：真正成熟的开发流程，不应该从写代码开始，而应该从审方案开始。

DevEco Code 的 Plan + Build 模式，正好体现了这种思路。

Plan Agent 负责需求拆解、方案设计、任务规划和风险识别；Build Agent 负责代码实现、构建验证和问题修复。两者分工协作，不是为了把流程变复杂，而是为了避免在错误方向上高效前进。

一、为什么直接 Build 容易返工

很多开发者拿到需求后的第一反应是：先写起来。

这种方式在小功能里问题不大，比如改一个按钮文案、补一个字段、修一个明确的空指针错误。但一旦需求涉及多个页面、多个状态、多个模块，直接进入 Build 阶段就很容易出问题。

原因很简单：代码是结果，不是起点。

如果需求边界不清楚，代码写得越快，偏离得也越快。

例如一个看似简单的“用户资料编辑”功能，真正落地时可能涉及：

用户是否登录。
资料字段是否必填。
手机号是否允许修改。
邮箱修改后是否需要重新验证。
头像上传失败如何处理。
保存过程中离开页面是否要提示。
旧数据和新数据如何合并。
接口失败时是否回滚页面状态。
管理员和普通用户权限是否一致。

如果这些问题没想清楚，直接写页面，很可能第一版只能覆盖理想路径。

等测试、产品或用户反馈问题时，再回头补异常、补状态、补权限，代码就会越来越乱。

这就是很多项目“越改越难维护”的根源。

不是开发者不会写代码，而是写代码之前缺少一次真正有效的方案审查。

二、Plan 的价值不是写文档，而是降低不确定性

很多人一听到 Plan，就会联想到写文档、开会、画流程图，觉得它会拖慢开发。

但真正有价值的 Plan，不是为了形式化地写一堆说明，而是为了回答几个关键问题：

这个需求到底解决什么问题？
用户在什么场景下使用？
成功路径是什么？
异常路径有哪些？
哪些模块会被影响？
哪些逻辑可以复用？
哪些地方存在风险？
最小可交付范围是什么？

如果这些问题没有答案，后面的 Build 只是碰运气。

Plan 阶段最重要的产出，不是漂亮的文档，而是清晰的判断。

例如：

这个需求不应该新增一个独立状态，而应该复用现有订单状态。
这个页面不需要单独做一套权限，只需要接入已有权限中间件。
这个接口不能直接在前端拼参数，因为涉及敏感字段。
这个功能必须先做数据迁移，否则旧用户会出问题。
这个改动影响导出流程，需要补回归测试。

这些判断越早出现，返工成本越低。

好的 Plan 能让开发者在动手之前知道：哪些事情必须做，哪些事情不能做，哪些事情现在不该做。

三、Build 的价值不只是写代码，还包括验证

Build 阶段很多人理解成“生成代码”或“执行开发”，但我认为 Build 的完整含义应该包括三部分：

实现。
构建。
验证。

实现只是把方案变成代码。

构建是确认项目能正常运行、依赖能正确安装、类型检查和打包过程没有问题。

验证则是确认功能真的符合预期，而不是“代码看起来没问题”。

一个成熟的 Build 阶段，至少应该回答：

代码是否符合项目现有结构？
有没有破坏已有逻辑？
异常状态是否处理？
接口失败是否有提示？
是否需要 loading、empty、error 状态？
是否影响其他页面？
是否有必要补测试？
构建是否通过？
是否有 lint 或类型错误？

如果 Build 只负责写代码，不负责验证，那么开发流程仍然是不完整的。

真正可靠的开发，不是“代码写完了”，而是“代码能跑、能测、能交付”。

四、Plan + Build 的核心是分离思考和执行

Plan + Build 最有价值的地方，是把“思考”和“执行”分开。

人在写代码时，很容易被局部实现细节吸引。

写着写着就开始纠结变量名、组件拆分、样式结构、接口封装，却忘了最初的问题是什么。

Plan 阶段把注意力拉回到更高层：

目标是什么？
边界在哪里？
路径是否合理？
风险是否可控？

Build 阶段再把注意力放到具体实现：

文件怎么改？
组件怎么写？
接口怎么接？
状态怎么维护？
错误怎么处理？

这两个阶段的思维方式不同。

Plan 更像架构设计和需求评审。

Build 更像工程实现和质量验证。

如果混在一起，开发者很容易一边写一边改方向，最后代码中留下大量临时判断和补丁逻辑。

而分开之后，流程会更清楚：

先确认方向正确。
再追求执行效率。

这比一开始就快速编码更稳。

五、什么场景最适合 Plan + Build

并不是所有任务都需要完整的 Plan + Build。

如果只是修一个简单 typo，或者改一个样式间距，直接 Build 就可以。

但下面这些场景，我认为非常适合先 Plan 后 Build。

第一，跨模块需求。

比如一个功能同时涉及前端页面、接口字段、权限控制、缓存策略和埋点统计。如果不先拆清楚，很容易漏掉某个环节。

第二，状态复杂的需求。

例如订单、审批、登录、支付、导入导出、离线缓存。这类功能的难点不是页面，而是状态流转。

第三，涉及历史兼容的需求。

如果系统已有老用户、旧数据、旧接口，不能只考虑新逻辑，还要考虑迁移和兼容。

第四，影响核心链路的需求。

登录、支付、发布、提交审核、数据保存，这些链路一旦出错，影响面很大，必须先评估风险。

第五，需要多人协作的需求。

如果一个需求要前端、后端、测试、产品一起参与，Plan 阶段可以提前统一语言，避免各做各的。

简单说：任务越复杂，Plan 的价值越大。

六、一个高质量 Plan 应该包含什么

如果只是写一句“实现某某功能”，那不叫 Plan。

一个真正能指导 Build 的 Plan，至少应该包含以下内容：

需求目标。
用户流程。
页面或模块影响范围。
数据结构变化。
接口变化。
状态流转。
异常场景。
复用方案。
不做什么。
风险点。
验证方式。

其中“ 不做什么 ”非常重要。

很多需求失控，不是因为该做的没做，而是因为顺手做了太多不该做的。

比如本来只是增加导出限制提示，结果顺手重构了导出模块；本来只是修复支付状态显示，结果改了整个用户权限逻辑；本来只是补一个表单校验，结果重新封装了一套表单系统。

这些改动看似积极，实际会增加风险。

Plan 阶段明确“不做什么”，可以有效控制范围。

一个好的 Plan，应该让 Build 阶段的人知道：

应该改哪里。
不应该改哪里。
完成标准是什么。
失败时如何判断问题。

七、方案评审比代码评审更靠前

很多团队重视 Code Review，但忽略 Plan Review。

代码评审当然重要，但代码评审发生在代码写完之后。这个时候如果发现方向错了，代价已经很高。

相比之下，方案评审更靠前。

在 Plan 阶段就提出问题，成本最低。

例如：

这个方案会不会引入重复状态？
这个接口是否会泄露敏感信息？
这个页面是否需要考虑无数据状态？
这个逻辑是否和已有权限系统冲突？
这个功能是否需要灰度？
这个改动是否会影响旧版本用户？

这些问题如果在写代码之前被发现，只需要改方案。

如果在代码写完后才发现，就要改代码、改测试、改文档，甚至重新联调。

所以 Plan + Build 模式的一个核心价值，是把一部分风险从 Code Review 前移到 Plan Review。

这会让整个交付链路更稳。

八、Build 阶段要避免“过度发挥”

当 Plan 明确之后，Build 阶段最重要的是尊重方案边界。

很多实现问题并不是不会写，而是写着写着开始“顺手优化”。

例如：

顺手改了不相关的样式。
顺手替换了工具函数。
顺手调整了目录结构。
顺手重构了旧组件。
顺手改了接口返回处理。

这些改动如果没有经过 Plan，很容易引入额外风险。

所以 Build 阶段应该遵守一个原则：

只做 Plan 中确认过的事情。

如果实现过程中发现 Plan 有问题，应该回到 Plan 阶段修正，而不是在 Build 中偷偷扩展范围。

这不是保守，而是工程纪律。

因为可维护的软件不是靠一次性写得多，而是靠每次改动都可解释、可验证、可回滚。

九、Plan + Build 对个人开发者也有价值

很多人以为这种模式只适合大团队。

其实个人开发者更需要。

因为个人开发者往往一个人承担所有角色：

产品经理。
前端开发。
后端开发。
测试。
运维。
客服。
文档。
上线审核。

一个人做所有事情，最容易出现的问题就是：想到哪里做到哪里。

今天改页面，明天改支付，后天补隐私政策，再过一天发现价格描述和后台配置不一致。

如果没有 Plan，项目很快就会变成一堆临时补丁。

个人开发者使用 Plan + Build，可以让自己在每次动手前先问：

这次到底要解决什么问题？
会影响哪些文件？
需要同步修改哪些文档？
是否影响上线审核？
如何验证完成？

这几个问题能明显减少混乱。

尤其是做插件、小程序、鸿蒙应用、PWA、SaaS 工具这类产品时，开发不只是写代码，还包括发布、审核、支付、隐私、合规和用户支持。

Plan + Build 能帮助个人开发者把这些事情串起来。

十、Plan Agent 和 Build Agent 的协作边界

如果把 Plan Agent 和 Build Agent 看作两个角色，它们的职责应该很清楚。

Plan Agent 负责：

理解需求。
拆解任务。
识别风险。
设计方案。
定义边界。
给出验收标准。

Build Agent 负责：

根据方案修改代码。
补充必要实现。
运行构建检查。
修复明确错误。
输出变更说明。
配合验证交付。

Plan Agent 不应该过早陷入代码细节。

Build Agent 不应该随意改变需求方向。

一个负责“想清楚”，一个负责“做扎实”。

这就是双 Agent 协作的关键。

如果 Plan 不清楚，Build 会乱。

如果 Build 不受控，Plan 会失效。

两者不是谁替代谁，而是让开发流程从“边想边写”变成“先想明白，再稳定执行”。

十一、真正提升效率的不是更快写代码，而是更少返工

很多工具宣传效率时，喜欢强调“写代码更快”。

但在真实项目里，影响效率的最大因素往往不是打字速度，而是返工次数。

一次需求理解错误，可能浪费一天。
一次接口设计错误，可能拖慢一周。
一次权限边界遗漏，可能导致线上事故。
一次缓存策略错误，可能让用户数据丢失。
一次审核材料不一致，可能导致产品被驳回。

这些问题不是靠更快写代码解决的。

它们需要更早的方案判断和更稳定的执行流程。

Plan + Build 模式真正提升效率的地方，正在于减少无效实现。

少写错代码，比快写代码更重要。

十二、总结

DevEco Code 的 Plan + Build 模式，本质上不是简单的工具分工，而是一种更成熟的工程节奏。

先 Plan，是为了把问题想清楚。

再 Build，是为了把方案做扎实。

它提醒我们：开发不是从敲第一行代码开始，而是从理解问题、拆解边界、识别风险开始。

一个高质量的软件交付流程，应该同时具备三种能力：

方向判断能力。
工程实现能力。
结果验证能力。

Plan 解决方向和边界。

Build 解决实现和验证。

当这两个阶段被清晰分离，开发过程就不再只是“把功能写出来”，而是更接近“把正确的功能稳定交付出去”。

这也是我认为 Plan + Build 模式最值得借鉴的地方。

它不是让开发变慢，而是让开发少走弯路。

它不是削弱开发者判断，而是把判断放到更重要的位置。

真正高效的开发，从来不是想到哪里写到哪里，而是在动手之前，先确认自己要去哪里。