企业官网建设流程全解析

Reflex AI Builder 的 Planning 功能：把大需求拆成可审查、可调整的实施计划

【免费下载链接】reflex🕸️ Web apps in pure Python 🐍项目地址: https://gitcode.com/GitHub_Trending/re/reflex

在 Reflex Build（本仓库docs/ai_builder目录所描述的 AI 应用构建器）中，Plan 视图负责把一段大型提示词（prompt）转化为结构化的实施计划，让你在 Agent 动手实现之前、甚至实现过程中都能审查与调整。本文基于 docs/ai_builder/features/planning.md 完整展开，结合 what_is_reflex_build.md、best_practices.md、generation_controls.md 等关联文档，讲清楚「何时该计划、如何审查调整、如何在计划与实现之间来回切换」，让你在构建多页面、多集成的大型应用时把不确定性降到最低。

什么是 Plan 视图

Plan 视图的核心定位是：将一个大而模糊的需求，提前转写为一份可以逐条审阅、逐节调整的实施计划，而不是让 Agent 拿到提示词就直接埋头写代码。

在 Reflex Build 的典型工作流（Describe → Build → Test → Ship）中，计划环节位于描述之后、实现之前：

1. 描述一个清晰的目标，并附上有用的截图、文件或约束条件；
2. 当任务跨越多个页面、系统或文件时，先审查计划；
3. 让 Agent 实现变更并跟进进度；
4. 在Preview中测试结果，发送聚焦的后续指令；
5. 为关键工作流补充或运行测试；
6. 部署、分享、下载或在本地继续开发。

这正是 what_is_reflex_build.md 中 "Review Every Change" 一节反复强调的实践：对于较大的变更，先在实现前审查计划。如果结果走偏，应检查改动过的文件或恢复更早的检查点（Checkpoint），而不是让 Agent 从头重建整个应用。

何时需要计划：Plan first 三档选择

创建应用（create screen）和聊天控制中都提供Plan first选项，用来控制 Agent 是否在实现前先产出计划：

选择依据很直接：影响多个页面、多个集成或多个系统的工作，应当使用计划；而孤立的小修改（例如调整一个组件的间距、改写一段文案）通常不需要独立计划。

best_practices.md 给出了同样的建议：除非你想为一个复杂任务强制要求计划、或为一个小改动跳过计划，否则把Plan first保持在Auto即可。此外它还强调，一份精确的提示词比任何设置都更重要——计划选项是辅助，清晰的输入才是根本。

生成前先自己“打草稿”

即使是让 Agent 做计划，best_practices.md 也建议你在生成前自己先写下五件事：

• 应用的主要用户与目标；
• 必须可用的第一个页面或工作流；
• 该页面需要的数据；
• 三到五项核心功能；
• 任何视觉参考或设计规则。

对于大型规格说明，可以要求 Agent 把它拆解为有序、可构建的任务清单，然后逐项构建并验证，而不是在一次生成中请求整个产品。这也正是 Plan 视图存在的意义：把「拆解」这一步从你的脑子里搬到一个可审查的界面上。

审查与调整计划

在应用工作区打开Plan，即可审查当前的计划分区（sections）与任务（tasks）。你可以：

• 添加或重组计划分区——按模块、页面或工作流重新组织实施顺序；
• 在生成开始前编辑计划——修改措辞、增删任务，让计划与你的真实意图一致；
• 对计划项发表评论，或要求 Agent 修订——把疑问和约束直接写在计划上，而不是事后才发现实现方向错了；
• 在生成过程中调整计划——Agent 会在后续步骤中拾取最新改动。

大型请求的审查要点

对于多页面或强集成的请求，务必等到 Agent 产出计划后再放行实现，并逐项确认：

1. 每个分区都描述了具体的产出结果（concrete outcome），而不是含糊的“优化一下”；
2. 依赖关系的顺序正确——例如先建数据模型，再写页面，再接集成；
3. 验证环节被包含在内——计划里应当有测试、预览检查等收尾动作，而不是实现完就结束。

让计划保持“进度记录”价值

文档特别提醒：手动编辑要保持聚焦。计划不仅是开工前的蓝图，也是实现过程中的进度记录（progress record）。如果随意堆砌修改，计划就会失去可对照性，后续的审查和回滚都会变得困难。

在计划与实现之间切换

Plan 与实现不是互斥的两个阶段，而是可以并行存在的两个视图：

• 生成运行时可以一直开着 Plan 视图，随时切回Preview查看实时结果，计划不会被丢弃；
• 生成过程中修改计划时，同步在聊天里把改动说清楚——这样 Agent 才能把最新指令与已在进行的实现工作对账（reconcile），避免“改了口径但代码还按旧口径走”；
• 实现完成后，回到 Preview 对比计划，逐项核对已完成的任务，对仍不满意的任务或视觉细节发送聚焦反馈。

这套“计划 ⇄ 实现”双视图协作，与 generation_controls.md 描述的协作机制一脉相承：Agent 的工作区会实时显示当前活动（包括 planning、web 搜索、工作区操作、测试与生成的截图），你可以一边浏览Preview和Plan一边跟进；如果要改变方向，等当前步骤完成、审查结果后，再发送一条合并后的完整指令，而不是中途堆积多条相互冲突的消息。

落地示例：员工仪表盘

what_is_reflex_build.md 的入门教程（tutorial.md）演示了计划思维的典型用法。教程把一个“员工仪表盘”拆成了多个可审查的步骤：

1. 创建应用：响应式仪表盘 + 员工表格 + 薪资柱状图；
2. 检查首版结果（Preview 中验证表格与图表渲染、不同宽度下的表现）；
3. 添加筛选：姓名搜索 + 部门筛选，联动表格与图表，并提供清除筛选；
4. 添加员工管理：新增、编辑、删除行，字段校验，表格与图表同步；
5. 添加第二个页面（Chat 页）并接入导航；
6. 用 Review mode 圈选图表区域并发送标注反馈；
7. 为关键工作流创建浏览器测试；
8. 复制/下载或部署。

每一步都是一个独立的、可验证的小任务——这正是「先规划再分步实现」的实践范本。若一次性让 Agent 生成整个产品，计划的可审查性、出错后的可回退性都会大打折扣。

与其它工作流的衔接

• Review mode / Code（editor_modes.md）：实现完成后，用 Review mode 在预览上圈选区域、添加注释并发送给 Agent；需要看实现细节或做源码级小修改时切换到 Code 视图。
• Generation Controls（generation_controls.md）：Agent 工作时可排队后续指令、跟进生成进度；多人协作时注意编辑锁（edit lock），避免重叠修改。
• Automated Testing（automated_testing.md）：计划中的“验证环节”落地为单元测试与浏览器测试，实现完成后运行测试确认行为符合预期。

小结

Plan 视图是 Reflex Build 里连接「描述」与「实现」的桥梁：用Auto / Always / Never三档控制何时计划，用可增删、可评论、可实时修订的计划面板做实现前的对齐，再用「计划视图 ⇄ Preview」双视图在实现过程中持续校正方向。对于多页面、多集成的大型请求，养成「先看计划、逐项确认产出与依赖、实现后再回 Preview 对照」的习惯，能显著减少返工，让 Agent 的产出始终可控、可预期。

【免费下载链接】reflex🕸️ Web apps in pure Python 🐍项目地址: https://gitcode.com/GitHub_Trending/re/reflex