企业官网建设流程全解析

B端后台和C端产品最大的区别在于：C端页面可以靠直觉和审美去堆，B端页面必须靠业务逻辑去撑。一个后台页面背后往往挂着权限体系、数据流转、状态机、审批链路，任何一个环节没对齐，生成出来的东西就是一堆看着像那么回事、实际没法用的组件堆砌。

这也是为什么很多人用AI写B端页面时，第一版出来感觉还行，第二版就开始崩——因为提示词里只说了“帮我做一个用户管理页面”，但没告诉AI这个页面里有哪些角色、每种角色看到什么、数据从哪来、空状态怎么显示、加载失败怎么办。AI只能靠猜，猜出来的东西自然经不起推敲。

我过去大半年时间一直在用AI辅助生成B端后台页面，从最开始的一句话描述，到后来整理出一套相对稳定的Prompt模板体系，中间踩的坑不少。这篇文章就把这套方法完整拆开，从业务任务怎么拆解、页面状态怎么描述、Prompt怎么写，到实际生成后怎么校验，一步步说清楚。

1. 为什么B端后台的提示词不能照搬C端写法

1.1 C端提示词和B端提示词的本质差异

C端页面的提示词可以很感性。你说“做一个电商首页，风格清新，突出促销氛围”，AI能给你生成一个像模像样的东西，因为C端页面的核心是视觉冲击和用户情绪，业务逻辑相对简单——用户看到商品、点击、下单，链路短且线性。

B端后台完全不是这个逻辑。一个典型的B端页面，比如“工单管理”，它至少涉及：谁能看到这个页面（角色权限）、看到哪些工单（数据范围）、工单有哪些状态（状态机）、每个状态下能做什么操作（动作权限）、操作后触发什么流程（审批链路）、数据为空时显示什么（空状态）、加载失败时怎么处理（异常状态）。

这些信息如果不在提示词里说清楚，AI生成出来的就是一个“看起来像工单管理”的静态页面，但没有任何业务灵魂。你点“审批通过”按钮，它不知道要跳转到哪；你切换角色，它不知道要隐藏哪些字段。

所以B端提示词的第一原则是：先描述业务任务，再描述页面结构，最后描述视觉风格。顺序反了，生成结果就会本末倒置。

1.2 业务任务拆解：从“做什么”到“谁在什么条件下做什么”

写B端提示词之前，我习惯先做一件事：把业务任务拆成“角色-场景-动作-状态”四要素。

举个例子，假设你要做一个“合同审批后台”。不要直接写“帮我做一个合同审批页面”，而是先拆：

• 角色：法务专员、法务主管、财务审核人、业务发起人
• 场景：发起审批、初审、复审、财务审核、归档
• 动作：提交、通过、驳回、转交、撤回、下载附件
• 状态：草稿、待初审、初审通过、待复审、复审通过、待财务审核、审核通过、已归档、已驳回

拆完这四要素，你再去写提示词，AI就能理解这个页面不是一个静态表格，而是一个有状态流转的业务系统。

我自己的做法是，在提示词开头先用一段话把业务背景说清楚，类似这样：

这是一个合同审批系统的后台页面，主要使用者是法务团队和财务团队。合同从业务方发起后，需要经过法务初审、法务复审、财务审核三个环节，每个环节有不同的审批人。审批人可以看到合同的基本信息、附件、审批历史，并根据当前状态决定是通过还是驳回。

这段话不长，但它给AI建立了一个业务上下文。有了这个上下文，后面描述页面结构时，AI就知道“审批历史”应该是一个时间线组件，“当前状态”应该是一个带颜色的标签，“操作按钮”应该根据状态动态显示。

1.3 页面状态描述：B端提示词里最容易被忽略的部分

我见过很多B端提示词，把页面结构描述得很详细，表格有哪些列、筛选条件有哪些、按钮放在哪，但完全没提页面状态。结果生成出来的页面，数据一为空就是一片白，加载失败就是浏览器默认报错，用户根本不知道发生了什么。

B端后台的页面状态至少包括以下几种：

这些状态如果在提示词里不写，AI默认只会生成“有数据”这一种情况。但实际项目中，空数据和异常状态才是用户最常遇到的。

我的做法是在提示词里专门用一段来描述状态：

页面需要处理以下状态：加载中显示骨架屏；数据为空时显示“暂无合同数据，点击右上角新建合同”的引导；加载失败时显示“数据加载失败，请检查网络后重试”并提供重试按钮；当前用户无审批权限时，操作按钮置灰并显示tooltip提示“您没有该合同的审批权限”。

这段描述直接决定了生成页面的完整度。实测下来，加了状态描述的提示词，生成结果的可直接用比例能从30%提升到70%以上。

2. 从业务任务到Prompt：一套可复用的模板结构

2.1 模板的整体框架

经过多次迭代，我目前用的B端后台Prompt模板大致分为五个部分：

1. 业务背景：这个系统是做什么的，给谁用，解决什么问题
2. 角色与权限：有哪些角色，每个角色能做什么
3. 页面结构：页面由哪些区域组成，每个区域放什么
4. 状态与交互：页面有哪些状态，用户操作后发生什么
5. 视觉与组件规范：用什么组件库，风格偏好，响应式要求

这五个部分不是随便排的，顺序有讲究。业务背景放最前面，是为了让AI建立上下文；角色与权限放第二，是因为B端页面的所有逻辑都围绕权限展开；页面结构放第三，是在前两部分约束下自然推导出来的；状态与交互放第四，是补全页面的动态行为；视觉规范放最后，是因为视觉是锦上添花，前面四部分没写好，视觉再好也没用。

2.2 业务背景怎么写才有效

业务背景不是写公司简介，而是写“这个页面在业务链路中的位置”。

差的写法：“这是一个CRM系统。”——太泛，AI不知道你要做什么页面。

好的写法：“这是一个CRM系统中的客户跟进记录页面。销售人员在跟进客户后，需要在这里记录跟进内容、下次跟进时间、客户意向等级。销售主管可以查看团队所有成员的跟进记录，并按意向等级筛选。”

好的写法给了AI三个关键信息：页面在系统中的位置（客户跟进记录）、使用者（销售和销售主管）、核心数据（跟进内容、时间、意向等级）。有了这些，AI生成的页面就不会跑偏。

我通常会把业务背景控制在100到150字，太短信息不够，太长AI会抓不住重点。

2.3 角色与权限的描述粒度

角色描述要具体到“每个角色能看到什么、能操作什么”。不要只写“有管理员和普通用户”，要写清楚差异。

比如：

系统有两种角色：销售专员和销售主管。销售专员只能看到自己名下的客户跟进记录，可以新增、编辑自己的记录，不能删除。销售主管可以看到团队所有成员的记录，可以按成员筛选，可以导出数据，可以删除任何记录。

这种描述方式直接告诉AI：表格的数据范围因角色而异，操作按钮的显示逻辑因角色而异。生成出来的页面就会自带权限判断逻辑，而不是一个所有人都能看所有数据的裸页面。

如果角色更多，可以用表格来组织：

表格的好处是信息密度高，AI容易解析。实测下来，用表格描述角色权限，生成结果的权限逻辑准确率明显高于纯文字描述。

2.4 页面结构的模块化描述

页面结构不要按“从上到下”描述，而是按“模块”描述。一个典型的B端页面通常包含：筛选区、操作区、数据展示区、分页区。

每个模块要写清楚：包含哪些元素、元素的类型、元素之间的关系。

比如筛选区：

筛选区包含：客户名称输入框（支持模糊搜索）、跟进时间范围选择器（日期区间）、意向等级下拉选择（A/B/C三档）、查询按钮、重置按钮。筛选条件变化后点击查询，表格数据刷新。

这种描述方式让AI知道每个元素的类型和交互行为。如果不写“支持模糊搜索”，AI可能生成一个精确匹配的输入框；如果不写“点击查询后刷新”，AI可能生成一个实时筛选的表格。

数据展示区要特别说明列的定义：

表格列包括：客户名称、跟进人、跟进时间、跟进方式（电话/微信/拜访）、意向等级（用不同颜色标签区分）、操作列（编辑、删除）。操作列的删除按钮需要二次确认。

这里有个细节：意向等级用颜色标签区分，这个描述会直接影响生成结果的视觉呈现。如果不写，AI可能只生成纯文本。

2.5 状态与交互的完整清单

状态与交互部分，我习惯用一个清单来写，确保不遗漏：

• 页面加载时：显示骨架屏，骨架屏行数与表格默认行数一致
• 数据为空时：显示空状态插图，文案为“暂无跟进记录，点击右上角新增”
• 加载失败时：显示错误提示和重试按钮
• 点击删除时：弹出二次确认框，确认后执行删除并刷新列表
• 删除成功后：显示Toast提示“删除成功”
• 删除失败时：显示Toast提示“删除失败，请重试”
• 无权限时：操作按钮置灰，hover显示“无权限”提示

这个清单看起来琐碎，但每一条都对应一个真实的用户场景。写全了，生成出来的页面就是一个完整的产品；写不全，就是一个半成品。

3. 页面状态描述的进阶技巧：让AI理解状态机

3.1 什么是B端页面的状态机

B端页面和C端页面最大的区别之一，就是B端页面通常有明确的状态流转。一个工单从“待处理”到“处理中”到“已完成”，一个合同从“草稿”到“审批中”到“已归档”，这些都是状态机。

如果提示词里不描述状态机，AI生成的页面就是一个静态表格，所有数据平铺展示，没有状态区分，没有状态对应的操作差异。

描述状态机的关键是：列出所有状态、每个状态下的可用操作、操作后的状态变化。

比如：

工单有四种状态：待处理、处理中、已完成、已关闭。待处理状态下可以“开始处理”和“关闭”；处理中状态下可以“完成”和“转交”；已完成状态下只能“查看”；已关闭状态下只能“查看”。状态用不同颜色的标签展示：待处理为橙色，处理中为蓝色，已完成为绿色，已关闭为灰色。

这段描述直接决定了生成页面的操作列逻辑。AI会根据状态动态显示按钮，而不是所有按钮都堆在那里。

3.2 状态与操作的对应关系表

当状态和操作比较多时，用表格描述更清晰：

这个表格放在提示词里，AI就能准确生成操作按钮的显示逻辑。实测下来，有状态机描述的提示词，生成结果的业务逻辑正确率能提升一倍以上。

3.3 状态变化的视觉反馈

状态变化后，页面要有视觉反馈。这一点也要在提示词里写清楚：

状态变更后，表格对应行的状态标签实时更新，同时页面顶部显示Toast提示“状态已更新”。如果状态变更涉及数据刷新，表格显示加载动画。

如果不写这些，AI可能只更新数据但不给用户任何反馈，用户会以为操作没生效。

3.4 异常状态的兜底处理

B端页面最怕的不是正常流程，而是异常流程。网络断了、接口超时、数据格式错误、并发操作冲突，这些在C端可能很少见，在B端却是家常便饭。

提示词里要专门写异常处理：

如果提交操作时网络异常，显示“网络异常，请检查网络后重试”，并保留用户已填写的数据。如果接口返回数据格式错误，显示“数据解析失败，请联系管理员”，并记录错误日志。如果并发操作导致数据版本冲突，显示“数据已被他人修改，请刷新后重试”。

这些兜底逻辑写进去，生成出来的页面才有生产环境的可用性。

4. 实操：一个完整的B端后台Prompt示例

4.1 场景设定：合同审批后台

假设我们要生成一个合同审批后台的列表页。按照前面的模板，提示词可以这样写：

业务背景：这是一个合同审批系统的后台页面，主要使用者是法务专员和法务主管。业务方发起合同后，合同进入审批流程，需要经过法务初审、法务复审两个环节。法务专员负责初审，法务主管负责复审。审批人可以看到合同的基本信息、附件、审批历史，并根据当前状态决定是通过还是驳回。

角色与权限：法务专员只能看到待初审和初审中的合同，可以执行初审通过和驳回操作。法务主管可以看到所有合同，可以执行复审通过和驳回操作，可以导出合同列表。系统管理员可以看到所有合同，可以执行所有操作，包括删除和归档。

页面结构：页面顶部是筛选区，包含合同名称输入框、合同编号输入框、审批状态下拉选择（待初审/初审中/待复审/复审中/已通过/已驳回）、提交时间范围选择器、查询按钮、重置按钮。筛选区下方是操作区，包含新建合同按钮（仅业务方可见）、导出按钮（仅法务主管和管理员可见）。操作区下方是表格区，列包括：合同名称、合同编号、提交人、提交时间、当前状态（彩色标签）、当前审批人、操作列（查看、审批、导出）。表格下方是分页组件。

状态与交互：页面加载时显示骨架屏。数据为空时显示“暂无合同数据”的空状态。加载失败时显示错误提示和重试按钮。点击审批按钮弹出审批弹窗，弹窗内显示合同详情、审批历史、审批意见输入框、通过按钮、驳回按钮。点击通过或驳回后，弹窗关闭，列表刷新，顶部显示Toast提示“审批完成”。点击导出按钮，显示导出进度提示，导出完成后自动下载文件。

视觉与组件规范：使用Ant Design组件库，表格支持斑马纹和固定表头，状态标签使用不同颜色区分，整体风格简洁专业，适配1366px及以上屏幕宽度。

这个提示词大概500字左右，但它包含了业务背景、角色权限、页面结构、状态交互、视觉规范五个部分。用这个提示词生成出来的页面，基本可以直接进入开发环节，只需要微调样式和对接真实接口。

4.2 生成结果的校验清单

生成完成后，不要急着用，先按以下清单校验：

• 角色权限是否正确：切换不同角色，检查数据范围和操作按钮是否变化
• 状态流转是否正确：模拟不同状态，检查可用操作是否符合预期
• 空状态是否显示：清空数据，检查空状态文案和插图
• 异常状态是否处理：模拟接口报错，检查错误提示和重试按钮
• 操作反馈是否完整：执行操作后，检查Toast提示和列表刷新
• 响应式是否正常：调整浏览器宽度，检查布局是否错乱

这个清单是我踩过多次坑之后总结出来的。最开始用AI生成页面时，我只检查“页面能不能打开”，结果上线后才发现空状态没处理、权限没判断、异常没兜底。后来每次生成完都按这个清单过一遍，问题就少了很多。

4.3 常见生成问题与修正方法

即使提示词写得很详细，AI生成的结果也可能有问题。以下是我遇到最多的几种情况：

问题一：操作按钮没有根据状态动态显示。所有按钮都堆在操作列里，不管当前状态是什么。修正方法是在提示词里明确写“操作列根据当前状态动态显示按钮，不可用的操作不显示或置灰”。

问题二：空状态没有引导文案。只显示一个空表格，没有提示用户下一步做什么。修正方法是在提示词里写“空状态显示引导文案，文案内容为‘暂无数据，点击右上角新建’”。

问题三：筛选区没有重置按钮。用户填了筛选条件后不知道怎么清空。修正方法是在提示词里明确列出筛选区的所有元素，包括重置按钮。

问题四：表格列宽不合理。某些列太宽，某些列太窄。修正方法是在提示词里指定关键列的宽度，比如“合同名称列宽200px，状态列宽100px”。

问题五：分页组件缺失。数据多了之后没有分页。修正方法是在提示词里明确写“表格下方包含分页组件，支持每页10/20/50条切换”。

这些问题看起来小，但每一个都影响用户体验。我的经验是，提示词写得越具体，生成结果的可用性越高。不要怕提示词长，B端页面的复杂度决定了提示词不可能短。

5. 提示词迭代：从能用到好用

5.1 第一版提示词的目标：跑通主流程

第一版提示词不要追求完美，先跑通主流程。什么是主流程？就是用户打开页面、看到数据、执行操作、得到反馈这条链路。

第一版提示词可以只包含业务背景、角色权限、页面结构三部分，状态与交互和视觉规范可以简化。生成出来后，先看主流程能不能走通，表格有没有数据、按钮能不能点、弹窗能不能弹。

如果第一版就跑不通，说明业务背景或角色权限描述有问题，需要回去补充。

5.2 第二版提示词的目标：补全状态和异常

主流程跑通后，第二版提示词重点补状态和异常。把前面说的状态清单、异常处理、操作反馈都加进去。

这一版生成出来后，重点检查空状态、加载失败、无权限、操作确认这些场景。这些场景在正常演示时不会出现，但实际使用中一定会遇到。

5.3 第三版提示词的目标：优化视觉和交互细节

前两版都跑通后，第三版提示词开始优化视觉和交互细节。比如表格的斑马纹、状态标签的颜色、按钮的圆角、弹窗的宽度、Toast的显示时长。

这些细节不影响功能，但影响用户体验。B端用户每天要在后台页面上花几个小时，视觉和交互的舒适度直接影响工作效率。

5.4 迭代过程中的经验教训

迭代过程中我最大的教训是：不要一次性把所有要求都写进提示词。第一版提示词写得太复杂，AI反而抓不住重点，生成结果四不像。

正确的做法是分阶段迭代。第一版只写核心业务逻辑，第二版补状态和异常，第三版优化视觉。每一版都在上一版的基础上修改，而不是推倒重来。

另外，每次迭代后要把生成结果和提示词一起保存下来。这样下次做类似页面时，可以直接复用提示词模板，只需要修改业务背景和角色权限部分。

6. 不同B端场景的提示词调整策略

6.1 列表页 vs 详情页 vs 表单页

B端后台最常见的三种页面类型是列表页、详情页、表单页。它们的提示词侧重点不同。

列表页的重点是筛选、排序、分页、批量操作。提示词里要重点描述筛选条件、表格列、操作列、分页规则。

详情页的重点是信息展示的层次和完整性。提示词里要重点描述信息分组、字段类型、关联数据的展示方式。

表单页的重点是字段校验、联动、提交反馈。提示词里要重点描述字段类型、校验规则、字段之间的联动关系、提交后的跳转逻辑。

6.2 数据看板类页面的提示词要点

数据看板类页面的重点是图表选型和数据刷新。提示词里要明确每种数据用什么图表展示，比如趋势用折线图、占比用饼图、对比用柱状图。还要说明数据刷新频率和刷新方式。

另外，看板类页面通常有筛选条件，筛选条件变化后所有图表要联动刷新。这一点要在提示词里写清楚。

6.3 审批流类页面的提示词要点

审批流类页面的重点是状态机和操作权限。提示词里要详细描述审批链路、每个节点的审批人、每个节点的可用操作、操作后的状态变化。

审批流页面通常还有审批历史，提示词里要描述审批历史的展示方式，比如时间线组件、每条记录包含审批人、审批时间、审批意见、审批结果。

6.4 配置类页面的提示词要点

配置类页面的重点是表单分组和保存反馈。提示词里要描述配置项的分组、每个配置项的类型（输入框、开关、下拉选择）、默认值、保存后的反馈。

配置类页面通常还有重置功能，提示词里要说明重置是恢复到默认值还是恢复到上次保存的值。

7. 提示词工程在B端后台的边界与局限

7.1 AI能生成什么，不能生成什么

AI能生成的是页面结构、组件布局、状态逻辑、交互反馈。这些是“形”层面的东西。

AI不能生成的是业务规则背后的领域知识。比如“合同金额超过100万需要法务总监审批”这条规则，AI不知道，你必须告诉它。再比如“客户意向等级A/B/C的定义标准”，AI也不知道，你必须写进提示词。

所以提示词工程的核心不是“让AI猜”，而是“把你知道的告诉AI”。你知道的越多，提示词写得越详细，生成结果越好。

7.2 提示词无法替代的部分

提示词无法替代需求分析和业务梳理。如果你自己都没想清楚这个页面的业务逻辑，提示词也写不清楚。

我见过很多人，业务逻辑一团浆糊，就指望AI生成一个能用的页面。结果生成出来一堆问题，回头又怪AI不行。其实问题不在AI，在于需求本身没理清。

正确的做法是：先用提示词把业务逻辑写一遍，写的过程中如果发现逻辑不通，说明需求还没想清楚，回去继续梳理。提示词写清楚了，需求也就理清楚了。

7.3 人机协作的最佳实践

我的经验是：AI负责生成初版，人负责校验和修正。AI生成速度很快，但生成结果需要人工校验。校验的重点是业务逻辑是否正确、状态流转是否完整、异常处理是否到位。

校验完成后，人工修正提示词，再让AI生成第二版。如此迭代两到三轮，基本就能得到一个可用的页面。

这个过程里，人的价值在于业务理解和逻辑校验，AI的价值在于快速生成和批量处理。两者结合，效率比纯人工高很多，质量比纯AI好很多。

8. 我踩过的几个典型坑

8.1 提示词太笼统导致生成结果跑偏

最开始我写提示词，喜欢写“做一个用户管理页面，包含增删改查”。结果AI生成的是一个通用表格，列是“姓名、年龄、性别”，完全不是我想要的。

后来我改成“做一个B端后台的用户管理页面，用户是企业的员工，包含工号、姓名、部门、职位、入职时间、状态（在职/离职）。支持按部门和状态筛选，支持批量导入和导出”。生成结果就准确多了。

教训：提示词里的每个名词都要有业务含义，不要用通用词汇。

8.2 忽略状态描述导致页面不完整

有一次我生成一个订单管理页面，提示词里只写了表格列和操作按钮，没写状态。结果生成出来的页面，所有订单都显示“查看”按钮，没有“发货”“取消”等操作。

后来我在提示词里加了订单状态和对应的操作，生成结果就完整了。

教训：B端页面的状态描述和页面结构描述同等重要，缺一不可。

8.3 权限描述不清导致逻辑错误

有一次我生成一个审批页面，提示词里只写了“有审批人和普通用户两种角色”，没写具体权限差异。结果生成出来的页面，普通用户也能看到审批按钮。

后来我改成“审批人可以看到所有待审批的申请，可以执行通过和驳回操作。普通用户只能看到自己提交的申请，只能执行撤回操作”。生成结果就正确了。

教训：权限描述要具体到“每个角色能看到什么、能操作什么”，不能只写角色名称。

8.4 视觉规范缺失导致风格不统一

有一次我生成多个页面，提示词里都没写视觉规范。结果每个页面的按钮颜色、表格样式、弹窗风格都不一样，拼在一起像几个不同系统。

后来我在每个提示词里都加上“使用Ant Design组件库，主色调用蓝色，表格支持斑马纹，弹窗宽度600px”。生成结果的风格就统一了。

教训：如果项目有多个页面，视觉规范要写进每个提示词里，确保风格一致。

8.5 迭代次数过多导致提示词臃肿

有一次我迭代了七八版提示词，每次都在上一版基础上加内容，最后提示词写了2000多字。结果AI反而抓不住重点，生成结果还不如第三版。

后来我学乖了，每次迭代前先精简上一版提示词，去掉已经不需要的约束，只保留核心要求。提示词控制在800到1200字之间，生成效果最好。

教训：提示词不是越长越好，而是要精准。迭代过程中要定期精简，去掉冗余信息。

9. 一套可以直接抄的Prompt模板

9.1 通用模板结构

以下是我目前用的通用模板，可以直接复制修改：

业务背景：[描述这个页面在业务链路中的位置，使用者是谁，解决什么问题]

角色与权限：[列出所有角色，每个角色的数据范围和可操作]

页面结构：[描述页面的区域划分，每个区域包含的元素]

状态与交互：[描述页面的各种状态，用户操作后的反馈]

视觉与组件规范：[描述组件库、风格偏好、响应式要求]

9.2 列表页模板示例

业务背景：这是一个[系统名称]的[页面名称]页面，主要使用者是[角色]。页面用于[核心功能]。

角色与权限：[角色A]可以看到[数据范围]，可以执行[操作列表]。[角色B]可以看到[数据范围]，可以执行[操作列表]。

页面结构：筛选区包含[筛选条件列表]。操作区包含[操作按钮列表]。表格列包括[列名列表]。表格下方是分页组件。

状态与交互：加载中显示骨架屏。空数据显示空状态引导。加载失败显示错误提示和重试按钮。点击[操作按钮]弹出[弹窗类型]，确认后[操作结果]。

视觉与组件规范：使用[组件库名称]，[风格描述]，适配[屏幕宽度]。

9.3 详情页模板示例

业务背景：这是一个[系统名称]的[页面名称]详情页，主要使用者是[角色]。页面用于查看[核心数据]的详细信息。

角色与权限：[角色A]可以看到[信息范围]。[角色B]可以看到[信息范围]。

页面结构：页面分为[区域数量]个区域。第一个区域展示[基本信息字段]。第二个区域展示[关联数据]。第三个区域展示[操作历史]。

状态与交互：加载中显示骨架屏。数据不存在显示“数据不存在或已被删除”。加载失败显示错误提示和重试按钮。

视觉与组件规范：使用[组件库名称]，[风格描述]，适配[屏幕宽度]。

9.4 表单页模板示例

业务背景：这是一个[系统名称]的[页面名称]表单页，主要使用者是[角色]。页面用于[表单用途]。

角色与权限：[角色A]可以填写和提交表单。[角色B]只能查看表单。

页面结构：表单分为[分组数量]个分组。第一个分组包含[字段列表]。第二个分组包含[字段列表]。表单底部是提交和取消按钮。

状态与交互：字段校验规则为[校验规则列表]。提交成功后跳转到[页面路径]并显示Toast提示。提交失败显示错误提示并保留已填写数据。

视觉与组件规范：使用[组件库名称]，[风格描述]，适配[屏幕宽度]。

这套模板我用了大半年，覆盖了大部分B端后台页面的生成需求。当然，每个项目都有自己的特殊性，模板只是起点，具体内容还需要根据实际业务调整。

最后分享一个我自己的习惯：每次生成完页面后，把提示词和生成结果一起存档。下次遇到类似页面时，先翻存档，找到最接近的提示词，修改业务背景和角色权限部分，直接复用。这样效率最高，质量也最稳定。