资讯动态

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

发布时间:2026/9/10 13:16:40 来源:尧图企业网站定制
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中计划环节位于描述之后、实现之前描述一个清晰的目标并附上有用的截图、文件或约束条件当任务跨越多个页面、系统或文件时先审查计划让 Agent 实现变更并跟进进度在Preview中测试结果发送聚焦的后续指令为关键工作流补充或运行测试部署、分享、下载或在本地继续开发。这正是 what_is_reflex_build.md 中 Review Every Change 一节反复强调的实践对于较大的变更先在实现前审查计划。如果结果走偏应检查改动过的文件或恢复更早的检查点Checkpoint而不是让 Agent 从头重建整个应用。何时需要计划Plan first 三档选择创建应用create screen和聊天控制中都提供Plan first选项用来控制 Agent 是否在实现前先产出计划取值行为适用场景Auto由 Agent 自行判断该请求是否需要计划大多数日常请求也是推荐默认值Always无论请求大小实现前必定先生成计划复杂的、跨页面/跨系统的任务Never跳过独立计划直接开始实现小范围、边界清晰的修改选择依据很直接影响多个页面、多个集成或多个系统的工作应当使用计划而孤立的小修改例如调整一个组件的间距、改写一段文案通常不需要独立计划。best_practices.md 给出了同样的建议除非你想为一个复杂任务强制要求计划、或为一个小改动跳过计划否则把Plan first保持在Auto即可。此外它还强调一份精确的提示词比任何设置都更重要——计划选项是辅助清晰的输入才是根本。生成前先自己“打草稿”即使是让 Agent 做计划best_practices.md 也建议你在生成前自己先写下五件事应用的主要用户与目标必须可用的第一个页面或工作流该页面需要的数据三到五项核心功能任何视觉参考或设计规则。对于大型规格说明可以要求 Agent 把它拆解为有序、可构建的任务清单然后逐项构建并验证而不是在一次生成中请求整个产品。这也正是 Plan 视图存在的意义把「拆解」这一步从你的脑子里搬到一个可审查的界面上。审查与调整计划在应用工作区打开Plan即可审查当前的计划分区sections与任务tasks。你可以添加或重组计划分区——按模块、页面或工作流重新组织实施顺序在生成开始前编辑计划——修改措辞、增删任务让计划与你的真实意图一致对计划项发表评论或要求 Agent 修订——把疑问和约束直接写在计划上而不是事后才发现实现方向错了在生成过程中调整计划——Agent 会在后续步骤中拾取最新改动。大型请求的审查要点对于多页面或强集成的请求务必等到 Agent 产出计划后再放行实现并逐项确认每个分区都描述了具体的产出结果concrete outcome而不是含糊的“优化一下”依赖关系的顺序正确——例如先建数据模型再写页面再接集成验证环节被包含在内——计划里应当有测试、预览检查等收尾动作而不是实现完就结束。让计划保持“进度记录”价值文档特别提醒手动编辑要保持聚焦。计划不仅是开工前的蓝图也是实现过程中的进度记录progress record。如果随意堆砌修改计划就会失去可对照性后续的审查和回滚都会变得困难。在计划与实现之间切换Plan 与实现不是互斥的两个阶段而是可以并行存在的两个视图生成运行时可以一直开着 Plan 视图随时切回Preview查看实时结果计划不会被丢弃生成过程中修改计划时同步在聊天里把改动说清楚——这样 Agent 才能把最新指令与已在进行的实现工作对账reconcile避免“改了口径但代码还按旧口径走”实现完成后回到 Preview 对比计划逐项核对已完成的任务对仍不满意的任务或视觉细节发送聚焦反馈。这套“计划 ⇄ 实现”双视图协作与 generation_controls.md 描述的协作机制一脉相承Agent 的工作区会实时显示当前活动包括 planning、web 搜索、工作区操作、测试与生成的截图你可以一边浏览Preview和Plan一边跟进如果要改变方向等当前步骤完成、审查结果后再发送一条合并后的完整指令而不是中途堆积多条相互冲突的消息。落地示例员工仪表盘what_is_reflex_build.md 的入门教程tutorial.md演示了计划思维的典型用法。教程把一个“员工仪表盘”拆成了多个可审查的步骤创建应用响应式仪表盘 员工表格 薪资柱状图检查首版结果Preview 中验证表格与图表渲染、不同宽度下的表现添加筛选姓名搜索 部门筛选联动表格与图表并提供清除筛选添加员工管理新增、编辑、删除行字段校验表格与图表同步添加第二个页面Chat 页并接入导航用 Review mode 圈选图表区域并发送标注反馈为关键工作流创建浏览器测试复制/下载或部署。每一步都是一个独立的、可验证的小任务——这正是「先规划再分步实现」的实践范本。若一次性让 Agent 生成整个产品计划的可审查性、出错后的可回退性都会大打折扣。与其它工作流的衔接Review mode / Codeeditor_modes.md实现完成后用 Review mode 在预览上圈选区域、添加注释并发送给 Agent需要看实现细节或做源码级小修改时切换到 Code 视图。Generation Controlsgeneration_controls.mdAgent 工作时可排队后续指令、跟进生成进度多人协作时注意编辑锁edit lock避免重叠修改。Automated Testingautomated_testing.md计划中的“验证环节”落地为单元测试与浏览器测试实现完成后运行测试确认行为符合预期。小结Plan 视图是 Reflex Build 里连接「描述」与「实现」的桥梁用Auto / Always / Never三档控制何时计划用可增删、可评论、可实时修订的计划面板做实现前的对齐再用「计划视图 ⇄ Preview」双视图在实现过程中持续校正方向。对于多页面、多集成的大型请求养成「先看计划、逐项确认产出与依赖、实现后再回 Preview 对照」的习惯能显著减少返工让 Agent 的产出始终可控、可预期。【免费下载链接】reflex️ Web apps in pure Python 项目地址: https://gitcode.com/GitHub_Trending/re/reflex创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价