EC EasyCode 前台功能重组

第一版梳理结论

乱感不是功能缺,而是所有阶段都挤在同一个工作台里

当前链路已经很强:需求、系统模块、数据库、业务动作、页面设计、预览运行都有了。 主要问题是导航层级和页面职责没有跟上功能增长,用户进入后不知道“现在在哪一步、下一步做什么、哪些是高级编辑”。

选择一个重组方向

三种方案,从小改到重构信息架构

点击卡片会高亮,回到聊天回复 A/B/C
A 小改动

保留现有页面,工作台改成步骤式

把 `/generate` 清成一条纵向流程,顶部固定进度条,当前阶段只展示一个主操作区。

项目生成工作台 保存草稿 / 预览
需求 -> 系统模块 -> 数据库 -> 业务流程 -> 页面设计 -> 预览
  • 开发成本最低,能快速降低“堆在一起”的感觉。
  • 适合先救急,但项目越来越大后仍可能再次拥挤。
B 推荐

新增项目详情枢纽,功能按阶段分区

把 `/generate` 变成“创建/继续项目”的入口,把每个项目放进 `/project/:id/workspace` 统一管理。

客户管理系统 运行预览 / 下载
  • 最适合当前功能规模,后续业务块、模板市场、运行日志都能自然加进去。
  • 改动中等,需要调整路由和若干页面职责,但不是推倒重写。
C 设计器优先

把页面设计器作为主舞台

项目打开后直接进入设计器,数据库、业务动作、业务块作为左侧资源和右侧配置。

页面设计器 保存 / 预览
  • 页面搭建体验会最强,适合把产品定位成低代码设计工具。
  • 会弱化“从需求生成项目”的主线,改动和认知成本最大。
当前建议选择 B:项目详情枢纽。它能保住生成主线,也能容纳越来越多的设计能力。

项目概览作为“下一步”中控台

用户不用记住入口,只看当前完成度和下一步动作。

保存草稿 继续下一步

需求完整度

项目名称、关键词、补充说明、模块选择。

生成状态

系统蓝图、数据库、业务动作、页面设计的任务状态。

交付出口

项目结构预览、运行预览、源码下载。
推荐落地方式

第一阶段先不大改后端:保留现有 API 和组件,把页面职责重排。 `GenerateView` 缩成创建/载入入口;新增 `ProjectWorkspaceView` 承接当前工作台的主流程; `PageDesignerView` 和 `PreviewView` 继续独立全屏,但由项目工作区统一进入。

路由层级草案

把“平台入口”和“项目内工作”分开