DevEco Code 的 Plan + Build 模式：为什么“先审方案，再执行”会成为新的开发习惯

很多项目延期并不是因为代码写得慢而是因为一开始就写错了方向。需求只看了一半就开工做到后面才发现权限边界没考虑接口已经接完才发现状态流转和产品预期不一致页面开发完成测试一跑才发现异常场景完全没覆盖代码写了很多最后却因为架构不合适不得不推倒重来。这类问题在开发中很常见。它们表面上是代码问题本质上却是方案问题。所以我越来越认同一个观点真正成熟的开发流程不应该从写代码开始而应该从审方案开始。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 模式最值得借鉴的地方。它不是让开发变慢而是让开发少走弯路。它不是削弱开发者判断而是把判断放到更重要的位置。真正高效的开发从来不是想到哪里写到哪里而是在动手之前先确认自己要去哪里。