前端页面组件怎么拆提示词（组件树设计、状态放在哪一层、Props 接口、可复用组件识别）
开始做一个复杂页面（后台详情页、多步骤表单、带筛选的列表），不知道怎么拆组件、状态该放在哪里时用：给出页面描述或原型，AI 先画组件树，再决定每份状态的归属和数据流向，定义每个组件的 Props，并指出哪些组件值得抽成通用组件。
通用大模型 对话模型通用
你是一名擅长组件设计的前端架构师。请在写代码之前，先帮我设计页面的组件结构。 - 框架：[框架]（例：React、Vue 3） - 页面描述（区块、交互、数据来源；有原型可描述原型）： [页面描述] - 已有的通用组件库：[已有组件库]（例：Ant Design + 团队内部组件） - 状态管理方案：[状态管理]（例：服务端数据用 TanStack Query，全局状态用 Zustand） 请输出： 1. 组件树：用缩进列表表示，每个组件写一句职责说明。拆分依据：单一职责、重复出现的结构、独立变化的区域、需要单独测试的逻辑。避免拆得过细（只被用一次且不足十行的部分不必单独成为组件）。 2. 状态清单：列出页面上所有的状态，逐条决定它属于哪一类、放在哪里： - 服务端数据（列表、详情）：交给数据请求层缓存，不要复制一份到本地状态； - 地址栏状态（筛选条件、页码、当前标签页）：放在查询参数里，刷新与分享时保持； - 表单状态：放在表单组件内部或表单库中； - 界面状态（弹窗开关、展开收起）：放在离使用它最近的组件； - 真正的全局状态（当前用户、主题）：才放进全局状态管理。 对每份状态说明：哪些组件读取、哪些组件修改、为什么放在这一层。 3. 数据流：画出关键交互（例如修改筛选条件 → 列表刷新）中数据和事件的流向，检查是否存在层层传递过深的属性，给出解决方式（组合、上下文、调整状态位置）。 4. Props 接口：为主要组件写出 Props 类型定义（名称、类型、是否必填、说明），以及组件对外触发的事件。 5. 可复用识别：哪些组件可以抽成通用组件放进组件库，哪些属于业务组件；不要为了「可能复用」过早抽象。 6. 目录结构建议（components、features、hooks 或 composables 的划分）。
高亮处换成你自己的内容：[框架]、[页面描述]、[已有组件库]、[状态管理]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[页面描述] 按区块写清楚：每块显示什么、有哪些操作、操作后会影响哪些区块。例如「顶部筛选栏修改后，列表刷新并回到第一页；点击某行在右侧抽屉显示详情，抽屉中修改后列表对应行更新」。
常见坑：
- 把接口返回的数据复制到全局状态里再手动同步，数据不一致的问题层出不穷。服务端数据交给数据请求库管理。
- 筛选条件和页码放在组件内部状态，刷新页面就丢失，也没法把链接分享给同事。
- 为了「以后可能复用」，把业务组件抽象成一堆配置项，最后谁都不敢改。先在业务里用起来，出现第二、第三次重复时再抽象。
追问技巧：设计确认后追问「按这个设计生成组件骨架代码，每个组件只写 Props 类型和结构，不写样式」，再逐个填充。
示例输出
示例，仅供参考（订单列表页，节选）
OrderListPage 页面容器：读取地址栏查询参数，组合各区块
├─ OrderFilters 筛选栏：修改后更新查询参数并重置页码
├─ BatchActionBar 批量操作：仅在有选中项时显示
├─ OrderTable 表格：展示数据、行选择
│ └─ OrderStatusTag 状态标签（通用，可放入组件库）
├─ Pagination 分页：读写查询参数中的页码
└─ OrderDetailDrawer 详情抽屉：根据查询参数中的订单编号加载详情| 状态 | 类型 | 位置 | 读取者 | 修改者 |
|---|---|---|---|---|
| 筛选条件、页码 | 地址栏状态 | 查询参数 | 页面容器、列表请求 | 筛选栏、分页 |
| 订单列表数据 | 服务端数据 | 数据请求缓存 | 表格 | 批量操作成功后使缓存失效 |
| 选中的行 | 界面状态 | 页面容器 | 表格、批量操作栏 | 表格 |
| 当前查看的订单编号 | 地址栏状态 | 查询参数 | 详情抽屉 | 表格行点击 |
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～