1. 先把“提示词”这事儿想明白B端后台不是聊天是“任务交接”我做了快十年的B端产品从早期的传统管理软件到现在各种中台、低代码平台最常被问的一个问题是“AI生成后台页面提示词到底怎么写”很多人一上来就写“帮我生成一个用户管理页面”然后AI确实生成了——一张漂亮的表格、几个按钮、一堆写死的假数据。看起来挺像那么回事但真正落到业务里压根没法用。为什么因为B端后台的本质不是“画界面”而是“跑任务”。你让AI生成的不是一张图而是一套能支撑业务流转的界面逻辑状态体系。先说个最直观的对比。C端产品你让AI生成一个“个人中心”核心就三件事展示信息、修改资料、退出登录。状态无非是加载中、有数据、报错。但B端后台的“用户管理”页面背后至少牵扯用户列表查询、筛选条件组合、新增用户弹窗、编辑用户表单、删除二次确认、批量操作、权限分配、角色联动、分页加载、空数据提示、操作失败反馈……这还只是一个最普通的模块。所以你会发现提示词的关键不在于“描述界面长什么样”而在于“描述任务怎么流转”。AI只有理解了业务任务才能把页面状态、交互逻辑、异常处理这些东西一次性生成到位。我用这个思路写提示词前后对比一下低质量提示词“生成一个用户管理页面包含表格、搜索框、新增按钮”高质量提示词“生成一个B端用户管理页面角色为超级管理员。页面需要支持按用户名、手机号、状态筛选用户表格展示用户ID、姓名、手机号、角色、状态、创建时间支持新增用户弹窗表单表单必填项为姓名、手机号、角色提交成功后刷新列表并弹出成功提示删除用户需要二次确认状态切换需要即时更新并给出反馈。所有请求需包含loading状态、错误状态、空数据状态。”后者看起来只是多了几行字但生成出来的东西完全是两个量级。前者只能产出静态稿后者能给出一套接近可用的业务模块。这篇文章我就把我这些年总结的“从业务任务到页面状态”的Prompt模板体系完整拆一遍每个模块都配上可以直接抄的模板和注意事项。2. 为什么“业务任务”必须前置三个核心逻辑2.1 AI没有“行业常识”它只有“文本联想”这是一个特别容易被忽略的点。我们人类做B端后台天然知道“用户管理”应该有筛选、有分页、有禁用、有角色。但AI没有这套行业常识它只是根据训练数据里的海量文本去“猜”一个管理页面大概长什么样。这就导致一个问题如果你只给出“用户管理”四个字AI会把它训练数据里最常见的“用户管理”页面元素全部拼凑出来。常见吗常见。但适用吗不一定。比如你的业务可能是“B2B2C平台里的商家子账号管理”那你的用户管理就涉及“所属商家”“对接渠道”“结算权限”这些特殊字段。AI拼出来的通用模板里根本没有这些。我自己的做法是在提示词里把“业务任务”当成第一优先级的约束条件。先告诉AI这个页面要完成什么业务目标再让它生成界面。比如业务目标运营人员需要审核新注册的商家并给通过审核的商家分配一个专属客户经理。界面任务需要提供待审核列表、审核通过/驳回操作、分配客户经理的下拉选择器。AI一旦理解了业务目标生成的页面就会自动围绕“审核”“分配”这两个动作展开而不是泛泛地输出一个“商家列表”。2.2 页面状态是“任务流转”的结果不是设计师的装饰很多人写提示词时只提界面元素完全不提状态。结果AI生成出来的页面永远是静态的、完美的、无异常的。但B端后台的真实使用场景里用户会遇到接口加载中页面需要展示loading而不是白屏接口返回空数组页面需要展示空状态引导而不是一张空表格接口报错页面需要展示错误提示和重试按钮而不是直接崩溃用户误操作删除重要数据时需要二次确认弹窗这些状态不是UI设计师“加个装饰”而是业务任务在流转过程中必然会遇到的分支。如果你不给AI描述这些分支它就不会生成这些分支。我举一个真实案例。之前给一个物流调度平台做“运单管理”模块最初提示词只写了表格、筛选、详情。生成出来的页面在正常情况下没什么大问题但一旦模拟“网络请求失败”页面直接白屏没有任何提示。后来我在提示词里补了一句所有列表请求需包含loading状态、错误状态、空数据状态。错误状态需显示“加载失败请重试”按钮。再生成时AI自动就在列表区域加了错误占位图和重试逻辑。这就是“状态描述”的价值——它让AI生成的页面具备真实业务场景下最基本的健壮性。2.3 提示词写的越“像需求文档”AI输出的越“像可用代码”我还有一个特别深的体会AI生成B端后台的效果取决于你给它的“需求颗粒度”。颗粒度越细输出的质量越高。什么叫需求颗粒度就是你把一个页面拆到什么程度。比如“用户管理”可以拆成列表页筛选区、表格区、分页区、批量操作区新增/编辑弹窗表单字段、校验规则、提交逻辑操作反馈成功提示、失败提示、二次确认权限控制哪些按钮对哪些角色可见如果你只给一句话AI只能给出一个粗糙的壳。但如果你给出一段结构化的需求描述AI就能生成一个包含逻辑的完整模块。所以我现在写提示词默认要求自己做到两个“凡是”凡是涉及数据展示的地方必须描述“数据来源”和“异常状态”凡是涉及用户操作的地方必须描述“操作结果”和“反馈方式”这样做的本质其实就是把“页面设计”升级为“任务设计”。AI生成的代码也就从“视觉还原”升级为“业务可用”。3. B端后台Prompt模板全拆解从“一句话”到“一套体系”3.1 模板一标准CRUD页面列表新增编辑删除这是B端后台最常用的一类页面适合用户管理、商品管理、订单管理等绝大多数模块。我常用的标准模板结构如下请生成一个【模块名称】管理页面面向【角色】。 页面包含 1. 筛选区支持【字段1】、【字段2】、【字段3】的筛选筛选条件变化时自动触发列表刷新。 2. 表格区展示【字段列表】支持分页每页【N】条。 3. 操作区支持新增、编辑、删除。删除操作需弹出二次确认框确认后才提交请求。 4. 表单弹窗新增和编辑共用同一个弹窗表单字段为【字段列表】。其中【必填字段】为必填项【字段】需要校验格式。 5. 状态要求所有数据请求需包含loading状态、错误状态、空数据状态。错误状态展示“加载失败请重试”按钮。操作成功后弹出成功提示并刷新当前列表。 附加要求 - 保持现有项目的技术栈【Vue3 Element Plus / React Ant Design】。 - 所有交互需有用户反馈不得出现静默失败。这个模板我用了很久基本覆盖了CRUD页面的全部场景。但有几个细节要特别说明第一筛选区要强调“条件变化时自动触发刷新”。如果不写AI可能生成一个“点击查询按钮才刷新”的交互。两种交互都不能算错但B端用户习惯的是选了状态就立刻刷新输入关键字要点击查询或防抖查询。你需要明确告诉AI到底用哪种。第二新增和编辑一定要写“共用同一个弹窗”。如果分开AI会生成两个独立弹窗代码量翻倍且容易出不一致的bug。共用弹窗只需要在打开时根据“是否有当前行数据”来决定标题和提交接口逻辑更简单也更规范。第三操作成功后的反馈方式必须写清楚。是刷新列表还是跳转详情是弹出Message提示还是用Notification我通常建议列表场景用轻量的Message提示详情提交场景用Notification。你不写AI就会随机选一个有时会出现“提交成功但列表没刷新”这种尴尬情况。我再给一个具体的“抄作业”示例基于Vue3 Element Plus请生成一个商品管理页面面向运营人员。 页面包含 1. 筛选区支持商品名称模糊搜索、商品状态上架/下架筛选、商品分类下拉筛选。筛选条件变化时自动触发列表刷新。 2. 表格区展示商品ID、商品名称、分类、价格、库存、状态、创建时间。支持分页每页10条。 3. 操作区支持新增、编辑、上架/下架、删除。删除操作需弹出二次确认框确认后才提交请求。 4. 表单弹窗新增和编辑共用同一个弹窗。表单字段为商品名称必填、分类必填、价格必填大于等于0、库存必填整数、商品描述选填。 5. 状态要求所有数据请求需包含loading状态、错误状态、空数据状态。错误状态展示“加载失败请重试”按钮。操作成功后弹出成功提示并刷新当前列表。 附加要求 - 技术栈Vue3 Element Plus。 - 所有交互需有用户反馈不得出现静默失败。 - 代码使用Composition API编写。这段提示词生成出来的效果已经接近一个可以直接二次开发的真实页面了。3.2 模板二复杂表单页面分步流程动态字段联动校验B端后台除了列表页还有大量复杂表单场景。比如创建订单、配置权限、发布活动、搭建流程。这类页面的核心难点不是“字段齐全”而是“流程顺畅”。我写过最有代表性的一个案例是“创建推广活动”页面。这个页面的业务流程是第一步选择活动类型不同类型会展示不同的后续字段。第二步填写基础信息包括活动名称、时间、预算。第三步配置推广渠道可以动态添加多条渠道。最后提交前需要二次确认确认后调用创建接口。如果只写“生成创建活动表单”AI大概率会输出一个静态的、所有字段平铺的表单。这会让用户面对一堆无关字段体验非常差。所以我给复杂表单页面单独总结了一套模板请生成一个【流程名称】表单页面面向【角色】。 整体流程 1. 第一步【步骤说明】需要选择【选择项】选择不同选项后动态展示对应的【字段】。 2. 第二步【步骤说明】填写【字段列表】。 3. 第三步【步骤说明】支持动态添加多条【子表单】。 4. 第四步提交前弹窗展示本次提交的数据摘要用户确认后调用提交接口。 表单校验要求 - 【字段1】必填且需要满足【校验规则】。 - 【字段2】与【字段3】存在联动关系当【字段2】为【某值】时【字段3】必填。 状态要求 - 切换步骤时保留已填写的数据。 - 提交中展示loading状态成功后跳转【目标页面】失败后展示错误原因不清空表单。这里我想强调几个实操经验动态表单是AI最容易出bug的地方。特别是“动态添加多条子表单”这种需求AI经常会生成固定的两三条数据或者把添加按钮的逻辑写死。我建议在提示词里明确写“支持动态添加和删除”并且补充“每条子表单有独立的校验逻辑”。步骤条里的数据保留非常重要。我见过很多AI生成的代码用户从第二步切回第一步第一步填的东西全没了。原因就是提示词里没提。所以一定要写“切换步骤时保留已填写的数据”这句话能帮你避免一大类很尴尬的bug。提交失败的场景必须做特殊处理。很多AI生成的表单提交失败后会清空表单这是B端产品的大忌。用户填了半天的内容就因为接口超时全没了换谁也不愿意再填一遍。所以我在模板里明确要求“失败后展示错误原因不清空表单”这几乎是B端所有表单的底线要求。3.3 模板三数据看板页面指标卡趋势图多维筛选数据看板是B端后台里比较特殊的一类页面。它不像CRUD那样有明确的操作任务但它的信息架构和状态管理依然有很强的规律。我常用的看板模板如下请生成一个【业务方向】数据看板页面面向【角色】。 页面包含 1. 顶部指标卡展示【指标1】、【指标2】、【指标3】指标卡需展示数值和环比变化率。 2. 趋势图展示【时间段】内的【指标】变化趋势支持按【维度】切换。 3. 排行榜展示TOP N列表包含【排名、名称、数值】。 4. 筛选区支持按【时间范围】、【业务线】等维度筛选筛选条件变化时所有图表联动更新。 5. 状态要求所有图表数据请求需包含loading状态、错误状态、空数据状态。图表加载失败时展示占位图并支持重试。 附加要求 - 图表组件使用【ECharts / AntV】。 - 页面布局需要适配不同屏幕尺寸。有一个细节我觉得值得单独说一下看板页面的空数据状态往往被忽视。很多AI生成的图表在一开始没有数据时直接渲染一个空图用户根本不知道是“没有数据”还是“请求失败了”。我的处理方式是在提示词里写清楚空数据状态下指标卡显示“--”图表区域显示“暂无数据”的占位图。这个看似很小的要求能让看板页面的专业度提升一个档次。另外看板页面的“筛选联动”也是个高频翻车点。如果不强调“所有图表联动更新”AI可能只更新其中一个图表。所以这句话一定要写。3.4 模板四审批流页面状态流转操作按钮动态变化B端后台里最考验状态管理的页面非“审批流”莫属。因为同一个页面在不同环节、不同角色眼里呈现出来的操作按钮是完全不一样的。举个例子一个“报销审批单”页面在发起人眼里看到的是“撤回”在部门主管眼里看到的是“通过/驳回”在财务眼里看到的可能是“生成付款单”。这些按钮必须根据当前审批状态和当前登录角色动态渲染。我给审批流页面设计的模板是请生成一个【单据名称】审批详情页面面向【角色】。 页面包含 1. 单据信息区展示【字段列表】包括单据编号、申请人、申请时间、金额、状态等。 2. 审批记录区展示时间线包含每一步的审批人、审批意见、审批结果、审批时间。 3. 操作区根据当前角色和当前审批状态动态展示可用操作按钮。例如 - 当前角色为【角色A】且状态为【待审批】时展示【通过】【驳回】按钮。 - 当前角色为【角色B】且状态为【审批中】时展示【撤回】按钮。 - 当前角色为【角色C】且状态为【已通过】时展示【打印】【导出】按钮。 4. 弹窗交互 - 点击“通过”时弹出填写审批意见的弹窗。 - 点击“驳回”时弹出填写驳回原因的必填弹窗。 - 点击“撤回”时需二次确认。 5. 状态要求页面初始化时加载单据详情和审批记录需包含loading状态、错误状态。操作完成后刷新当前页面数据。 附加要求 - 按钮的展示逻辑需要用【权限判断函数】统一控制不得在模板中写死。这类页面我踩过最大的坑就是“按钮写死”。AI如果不理解审批流的状态流转很容易把所有按钮都渲染出来导致发起人也能看到“审批通过”按钮。后来我总结出一个经验在提示词里给AI一个“角色状态”的二维矩阵示例。比如明确写出“当前角色为A且状态为B时显示什么按钮”AI就能比较容易地理解动态控制的逻辑。3.5 模板五系统设置页面权限分级敏感操作保护系统设置页面看起来简单实际上对权限和安全的要求极高。B端后台的“配置管理”“角色管理”“日志查询”都属于这类页面。我常用的模板如下请生成一个【配置模块】设置页面面向【角色】。 页面包含 1. 配置项分组展示将【配置项列表】按【分组名称】分组展示。 2. 敏感操作保护修改核心配置时需弹出二次确认弹窗并输入当前账号密码进行二次验证。 3. 权限控制页面中的某些按钮仅对【角色A】可见其他角色不可见。 4. 操作反馈保存成功后弹出成功提示失败后展示错误原因。 5. 日志记录所有修改操作需生成操作日志记录操作人、操作时间、修改前后值。这里特别值得说的是“密码二次验证”这个设计。很多AI生成的代码只会做二次确认弹窗但不会做密码验证。在真实B端系统里修改支付配置、删除数据源这些高风险操作基本都需要二次验证。如果提示词里不写AI绝对不会主动生成。另外“操作日志”也是容易被忽略的点。B端系统出问题时要追溯“谁在什么时候改了什么”没有操作日志排查起来极其痛苦。我在模板里写“修改前后值”就是为了让日志不仅记录“改了什么”还能记录“从什么改成什么”。3.6 模板六批量操作与导入导出大任务反馈结果汇总B端后台还有一个常见场景批量操作和导入导出。比如批量审核、批量删除、Excel导入用户、导出订单报表。这类场景最大的痛点是“长时间任务没有反馈”。如果AI只生成一个“导出”按钮点击后没有任何loading或进度反馈用户会以为系统坏了。我给这类页面设计的提示词模板如下请生成一个【数据模块】批量操作功能面向【角色】。 功能要求 1. 列表页支持多选选中后展示批量操作按钮按钮包括【批量操作1】【批量操作2】。 2. 点击批量操作后弹出二次确认框展示本次操作影响的数据条数。 3. 批量操作提交后需展示操作进度可以以进度条或百分比形式展示。 4. 操作完成后展示执行结果汇总包括成功条数、失败条数、失败原因。 5. 导出功能支持按当前筛选条件导出数据导出过程中需展示loading状态导出完成后提供文件下载链接。 6. 导入功能支持Excel导入导入前需校验文件格式和大小导入后展示导入失败的行数和错误原因。这个模板的核心思路是“让AI把任务反馈做完整”。B端用户面对批量操作时最怕的就是“点了没反应”或者“只报成功不报失败”。把成功条数、失败条数、失败原因都展示出来用户才能真正信任这个功能。4. Prompt提示词常用的“状态描述”关键词表我平时写提示词有一个反复使用的“状态描述关键词表”。如果你不知道该怎么给AI描述页面状态可以直接从下面这个表里挑。场景状态关键词使用目的数据加载loading状态、骨架屏、加载中避免页面白屏数据为空空数据状态、暂无数据、空状态引导避免空表格、空图表请求失败错误状态、加载失败、请重试、错误占位图提供异常反馈操作成功成功提示、Message、Notification确认操作生效操作失败失败原因、不清空表单减少用户重复劳动删除操作二次确认、取消/确认防止误操作批量操作操作进度、进度条、成功条数、失败条数大任务可视化反馈导入导出文件格式校验、文件大小限制、下载链接规范文件操作权限控制按钮权限、角色判断、权限函数动态控制可见性日志审计操作人、操作时间、修改前后值安全追溯这张表我建议你直接收藏。每次写完提示词对照这张表检查一遍看有没有漏掉哪些状态描述。漏掉一个AI就少生成一个分支。5. 在真实项目里用Prompt生成B端后台有哪些防翻车技巧5.1 让AI先出“任务清单”再出“页面代码”很多AI工具有一个特点你让它直接生成完整页面它容易把功能糅在一起代码不可控。我的习惯是先让AI生成一个“任务拆分清单”确认无误后再让它写代码。比如请先不要写代码。先帮我拆解“用户管理页面”需要完成哪些业务任务每个任务涉及哪些页面状态用列表形式输出。这一步能有效避免AI生成的代码“东一榔头西一棒槌”。等它输出任务清单后你还能在清单层面提出修改不用等代码写完了再去否定。5.2 给AI一个“参照物”比让AI“闭门造车”更高效如果你手头有一个已经做好的相似页面可以直接告诉AI“参考当前项目的XX页面风格生成新的YY页面。”AI在文本理解上会更容易对齐你的预期。如果没有任何参照物也可以描述你希望参考的设计规范比如“按钮风格使用圆角、表格密度中等、筛选区固定在页面顶部”。5.3 分模块生成不要“一个大Prompt生成整个系统”我建议每次只让AI生成一个模块用户管理就是一个用户管理不要同时让它生成用户管理、角色管理、权限管理、操作日志。模块划分得越细AI的注意力越集中生成质量越高。如果是整个后台系统我会先让AI生成“页面框架”和“菜单配置”然后逐个模块生成最后再统一联调。5.4 代码生成后至少要检查这四个点我每次拿到AI生成的页面代码会固定检查四个地方检查loading状态是否覆盖了所有异步请求检查提交成功后是否正确刷新列表或跳转检查权限控制是否真的生效而不是只做了视觉隐藏检查二次确认弹窗是否能被正常触发这四个点是B端后台最常见的翻车位置。每检查出一个问题我就回填一条提示词把问题描述补充进去重新生成。多来几次AI就能生成出接近生产可用的代码。6. 常见问题速查表为什么AI生成的B端后台总是不对劲问题现象原因解决方案生成出来的页面没有loading状态提示词里没有描述异步状态补充“所有请求需包含loading状态”操作成功后列表不刷新提示词里没有描述操作反馈补充“操作成功后刷新当前列表”删除没有二次确认提示词里没有描述敏感操作保护补充“删除需弹出二次确认框”空数据时显示空白表格提示词里没有描述空数据状态补充“展示暂无数据占位图”所有按钮对所有人可见提示词里没有描述权限控制补充“根据当前角色动态显示按钮”表单提交失败后内容清空提示词里没有描述异常保留补充“提交失败时不清空表单”审批操作按钮写死提示词里没有描述状态流转补充“根据角色和状态动态展示操作按钮”导出功能点击后无反馈提示词里没有描述任务进度补充“导出中展示loading完成后提供下载链接”动态表单只有固定行数提示词里没有描述动态添加逻辑补充“支持动态添加和删除子表单”筛选条件变化后图表不联动提示词里没有描述联动关系补充“筛选变化时所有图表联动更新”这张表我基本是结合自己踩过的坑整理出来的。你在写提示词之前可以先把这张表过一遍把涉及到的场景直接用自然语言写进提示词里。7. 把“页面设计”升级为“任务设计”才是B端后台Prompt的正确打开方式我个人在实际生成B端后台的过程中最核心的体会就是不要用“设计页面”的思维写提示词要用“设计任务”的思维写提示词。每写一个提示词我都会问自己三个问题用户在这个页面上要完成什么业务任务这个任务从开始到结束要经历哪些状态每个状态出现时用户应该看到什么、能操作什么这三个问题想清楚了提示词就很容易写出来。AI生成出来的页面也不会只是一个好看的壳而是一套能跑通业务的真实模块。最后再分享一个小技巧写提示词时尽量用“短句明确动词”。比如“展示”“支持”“弹出”“刷新”“提交”“校验”这些动词能精确约束AI的行为。少用“漂亮”“清晰”“合理”这类模糊形容词因为AI无法量化这些词生成出来的效果往往不符合你的心理预期。我见过很多新手写提示词花大量篇幅描述“界面要好看”但对“任务怎么流转”只字不提。结果生成出来的东西光鲜亮丽却一碰就碎。反过来把业务任务和页面状态描述清楚哪怕你对视觉风格只字未提AI也会基于训练数据里的最佳实践生成出一个专业且耐用的B端后台页面。这个思路不仅仅适用于用户管理、商品管理这些标准模块也适用于审批流、数据看板、系统设置这些复杂的B端场景。把“任务”和“状态”当成提示词的骨架把“视觉风格”当成可有可无的皮肉你的AI生成效率和质量都会有质的提升。
B端后台AI生成提示词模板：从任务设计到页面状态
1. 先把“提示词”这事儿想明白B端后台不是聊天是“任务交接”我做了快十年的B端产品从早期的传统管理软件到现在各种中台、低代码平台最常被问的一个问题是“AI生成后台页面提示词到底怎么写”很多人一上来就写“帮我生成一个用户管理页面”然后AI确实生成了——一张漂亮的表格、几个按钮、一堆写死的假数据。看起来挺像那么回事但真正落到业务里压根没法用。为什么因为B端后台的本质不是“画界面”而是“跑任务”。你让AI生成的不是一张图而是一套能支撑业务流转的界面逻辑状态体系。先说个最直观的对比。C端产品你让AI生成一个“个人中心”核心就三件事展示信息、修改资料、退出登录。状态无非是加载中、有数据、报错。但B端后台的“用户管理”页面背后至少牵扯用户列表查询、筛选条件组合、新增用户弹窗、编辑用户表单、删除二次确认、批量操作、权限分配、角色联动、分页加载、空数据提示、操作失败反馈……这还只是一个最普通的模块。所以你会发现提示词的关键不在于“描述界面长什么样”而在于“描述任务怎么流转”。AI只有理解了业务任务才能把页面状态、交互逻辑、异常处理这些东西一次性生成到位。我用这个思路写提示词前后对比一下低质量提示词“生成一个用户管理页面包含表格、搜索框、新增按钮”高质量提示词“生成一个B端用户管理页面角色为超级管理员。页面需要支持按用户名、手机号、状态筛选用户表格展示用户ID、姓名、手机号、角色、状态、创建时间支持新增用户弹窗表单表单必填项为姓名、手机号、角色提交成功后刷新列表并弹出成功提示删除用户需要二次确认状态切换需要即时更新并给出反馈。所有请求需包含loading状态、错误状态、空数据状态。”后者看起来只是多了几行字但生成出来的东西完全是两个量级。前者只能产出静态稿后者能给出一套接近可用的业务模块。这篇文章我就把我这些年总结的“从业务任务到页面状态”的Prompt模板体系完整拆一遍每个模块都配上可以直接抄的模板和注意事项。2. 为什么“业务任务”必须前置三个核心逻辑2.1 AI没有“行业常识”它只有“文本联想”这是一个特别容易被忽略的点。我们人类做B端后台天然知道“用户管理”应该有筛选、有分页、有禁用、有角色。但AI没有这套行业常识它只是根据训练数据里的海量文本去“猜”一个管理页面大概长什么样。这就导致一个问题如果你只给出“用户管理”四个字AI会把它训练数据里最常见的“用户管理”页面元素全部拼凑出来。常见吗常见。但适用吗不一定。比如你的业务可能是“B2B2C平台里的商家子账号管理”那你的用户管理就涉及“所属商家”“对接渠道”“结算权限”这些特殊字段。AI拼出来的通用模板里根本没有这些。我自己的做法是在提示词里把“业务任务”当成第一优先级的约束条件。先告诉AI这个页面要完成什么业务目标再让它生成界面。比如业务目标运营人员需要审核新注册的商家并给通过审核的商家分配一个专属客户经理。界面任务需要提供待审核列表、审核通过/驳回操作、分配客户经理的下拉选择器。AI一旦理解了业务目标生成的页面就会自动围绕“审核”“分配”这两个动作展开而不是泛泛地输出一个“商家列表”。2.2 页面状态是“任务流转”的结果不是设计师的装饰很多人写提示词时只提界面元素完全不提状态。结果AI生成出来的页面永远是静态的、完美的、无异常的。但B端后台的真实使用场景里用户会遇到接口加载中页面需要展示loading而不是白屏接口返回空数组页面需要展示空状态引导而不是一张空表格接口报错页面需要展示错误提示和重试按钮而不是直接崩溃用户误操作删除重要数据时需要二次确认弹窗这些状态不是UI设计师“加个装饰”而是业务任务在流转过程中必然会遇到的分支。如果你不给AI描述这些分支它就不会生成这些分支。我举一个真实案例。之前给一个物流调度平台做“运单管理”模块最初提示词只写了表格、筛选、详情。生成出来的页面在正常情况下没什么大问题但一旦模拟“网络请求失败”页面直接白屏没有任何提示。后来我在提示词里补了一句所有列表请求需包含loading状态、错误状态、空数据状态。错误状态需显示“加载失败请重试”按钮。再生成时AI自动就在列表区域加了错误占位图和重试逻辑。这就是“状态描述”的价值——它让AI生成的页面具备真实业务场景下最基本的健壮性。2.3 提示词写的越“像需求文档”AI输出的越“像可用代码”我还有一个特别深的体会AI生成B端后台的效果取决于你给它的“需求颗粒度”。颗粒度越细输出的质量越高。什么叫需求颗粒度就是你把一个页面拆到什么程度。比如“用户管理”可以拆成列表页筛选区、表格区、分页区、批量操作区新增/编辑弹窗表单字段、校验规则、提交逻辑操作反馈成功提示、失败提示、二次确认权限控制哪些按钮对哪些角色可见如果你只给一句话AI只能给出一个粗糙的壳。但如果你给出一段结构化的需求描述AI就能生成一个包含逻辑的完整模块。所以我现在写提示词默认要求自己做到两个“凡是”凡是涉及数据展示的地方必须描述“数据来源”和“异常状态”凡是涉及用户操作的地方必须描述“操作结果”和“反馈方式”这样做的本质其实就是把“页面设计”升级为“任务设计”。AI生成的代码也就从“视觉还原”升级为“业务可用”。3. B端后台Prompt模板全拆解从“一句话”到“一套体系”3.1 模板一标准CRUD页面列表新增编辑删除这是B端后台最常用的一类页面适合用户管理、商品管理、订单管理等绝大多数模块。我常用的标准模板结构如下请生成一个【模块名称】管理页面面向【角色】。 页面包含 1. 筛选区支持【字段1】、【字段2】、【字段3】的筛选筛选条件变化时自动触发列表刷新。 2. 表格区展示【字段列表】支持分页每页【N】条。 3. 操作区支持新增、编辑、删除。删除操作需弹出二次确认框确认后才提交请求。 4. 表单弹窗新增和编辑共用同一个弹窗表单字段为【字段列表】。其中【必填字段】为必填项【字段】需要校验格式。 5. 状态要求所有数据请求需包含loading状态、错误状态、空数据状态。错误状态展示“加载失败请重试”按钮。操作成功后弹出成功提示并刷新当前列表。 附加要求 - 保持现有项目的技术栈【Vue3 Element Plus / React Ant Design】。 - 所有交互需有用户反馈不得出现静默失败。这个模板我用了很久基本覆盖了CRUD页面的全部场景。但有几个细节要特别说明第一筛选区要强调“条件变化时自动触发刷新”。如果不写AI可能生成一个“点击查询按钮才刷新”的交互。两种交互都不能算错但B端用户习惯的是选了状态就立刻刷新输入关键字要点击查询或防抖查询。你需要明确告诉AI到底用哪种。第二新增和编辑一定要写“共用同一个弹窗”。如果分开AI会生成两个独立弹窗代码量翻倍且容易出不一致的bug。共用弹窗只需要在打开时根据“是否有当前行数据”来决定标题和提交接口逻辑更简单也更规范。第三操作成功后的反馈方式必须写清楚。是刷新列表还是跳转详情是弹出Message提示还是用Notification我通常建议列表场景用轻量的Message提示详情提交场景用Notification。你不写AI就会随机选一个有时会出现“提交成功但列表没刷新”这种尴尬情况。我再给一个具体的“抄作业”示例基于Vue3 Element Plus请生成一个商品管理页面面向运营人员。 页面包含 1. 筛选区支持商品名称模糊搜索、商品状态上架/下架筛选、商品分类下拉筛选。筛选条件变化时自动触发列表刷新。 2. 表格区展示商品ID、商品名称、分类、价格、库存、状态、创建时间。支持分页每页10条。 3. 操作区支持新增、编辑、上架/下架、删除。删除操作需弹出二次确认框确认后才提交请求。 4. 表单弹窗新增和编辑共用同一个弹窗。表单字段为商品名称必填、分类必填、价格必填大于等于0、库存必填整数、商品描述选填。 5. 状态要求所有数据请求需包含loading状态、错误状态、空数据状态。错误状态展示“加载失败请重试”按钮。操作成功后弹出成功提示并刷新当前列表。 附加要求 - 技术栈Vue3 Element Plus。 - 所有交互需有用户反馈不得出现静默失败。 - 代码使用Composition API编写。这段提示词生成出来的效果已经接近一个可以直接二次开发的真实页面了。3.2 模板二复杂表单页面分步流程动态字段联动校验B端后台除了列表页还有大量复杂表单场景。比如创建订单、配置权限、发布活动、搭建流程。这类页面的核心难点不是“字段齐全”而是“流程顺畅”。我写过最有代表性的一个案例是“创建推广活动”页面。这个页面的业务流程是第一步选择活动类型不同类型会展示不同的后续字段。第二步填写基础信息包括活动名称、时间、预算。第三步配置推广渠道可以动态添加多条渠道。最后提交前需要二次确认确认后调用创建接口。如果只写“生成创建活动表单”AI大概率会输出一个静态的、所有字段平铺的表单。这会让用户面对一堆无关字段体验非常差。所以我给复杂表单页面单独总结了一套模板请生成一个【流程名称】表单页面面向【角色】。 整体流程 1. 第一步【步骤说明】需要选择【选择项】选择不同选项后动态展示对应的【字段】。 2. 第二步【步骤说明】填写【字段列表】。 3. 第三步【步骤说明】支持动态添加多条【子表单】。 4. 第四步提交前弹窗展示本次提交的数据摘要用户确认后调用提交接口。 表单校验要求 - 【字段1】必填且需要满足【校验规则】。 - 【字段2】与【字段3】存在联动关系当【字段2】为【某值】时【字段3】必填。 状态要求 - 切换步骤时保留已填写的数据。 - 提交中展示loading状态成功后跳转【目标页面】失败后展示错误原因不清空表单。这里我想强调几个实操经验动态表单是AI最容易出bug的地方。特别是“动态添加多条子表单”这种需求AI经常会生成固定的两三条数据或者把添加按钮的逻辑写死。我建议在提示词里明确写“支持动态添加和删除”并且补充“每条子表单有独立的校验逻辑”。步骤条里的数据保留非常重要。我见过很多AI生成的代码用户从第二步切回第一步第一步填的东西全没了。原因就是提示词里没提。所以一定要写“切换步骤时保留已填写的数据”这句话能帮你避免一大类很尴尬的bug。提交失败的场景必须做特殊处理。很多AI生成的表单提交失败后会清空表单这是B端产品的大忌。用户填了半天的内容就因为接口超时全没了换谁也不愿意再填一遍。所以我在模板里明确要求“失败后展示错误原因不清空表单”这几乎是B端所有表单的底线要求。3.3 模板三数据看板页面指标卡趋势图多维筛选数据看板是B端后台里比较特殊的一类页面。它不像CRUD那样有明确的操作任务但它的信息架构和状态管理依然有很强的规律。我常用的看板模板如下请生成一个【业务方向】数据看板页面面向【角色】。 页面包含 1. 顶部指标卡展示【指标1】、【指标2】、【指标3】指标卡需展示数值和环比变化率。 2. 趋势图展示【时间段】内的【指标】变化趋势支持按【维度】切换。 3. 排行榜展示TOP N列表包含【排名、名称、数值】。 4. 筛选区支持按【时间范围】、【业务线】等维度筛选筛选条件变化时所有图表联动更新。 5. 状态要求所有图表数据请求需包含loading状态、错误状态、空数据状态。图表加载失败时展示占位图并支持重试。 附加要求 - 图表组件使用【ECharts / AntV】。 - 页面布局需要适配不同屏幕尺寸。有一个细节我觉得值得单独说一下看板页面的空数据状态往往被忽视。很多AI生成的图表在一开始没有数据时直接渲染一个空图用户根本不知道是“没有数据”还是“请求失败了”。我的处理方式是在提示词里写清楚空数据状态下指标卡显示“--”图表区域显示“暂无数据”的占位图。这个看似很小的要求能让看板页面的专业度提升一个档次。另外看板页面的“筛选联动”也是个高频翻车点。如果不强调“所有图表联动更新”AI可能只更新其中一个图表。所以这句话一定要写。3.4 模板四审批流页面状态流转操作按钮动态变化B端后台里最考验状态管理的页面非“审批流”莫属。因为同一个页面在不同环节、不同角色眼里呈现出来的操作按钮是完全不一样的。举个例子一个“报销审批单”页面在发起人眼里看到的是“撤回”在部门主管眼里看到的是“通过/驳回”在财务眼里看到的可能是“生成付款单”。这些按钮必须根据当前审批状态和当前登录角色动态渲染。我给审批流页面设计的模板是请生成一个【单据名称】审批详情页面面向【角色】。 页面包含 1. 单据信息区展示【字段列表】包括单据编号、申请人、申请时间、金额、状态等。 2. 审批记录区展示时间线包含每一步的审批人、审批意见、审批结果、审批时间。 3. 操作区根据当前角色和当前审批状态动态展示可用操作按钮。例如 - 当前角色为【角色A】且状态为【待审批】时展示【通过】【驳回】按钮。 - 当前角色为【角色B】且状态为【审批中】时展示【撤回】按钮。 - 当前角色为【角色C】且状态为【已通过】时展示【打印】【导出】按钮。 4. 弹窗交互 - 点击“通过”时弹出填写审批意见的弹窗。 - 点击“驳回”时弹出填写驳回原因的必填弹窗。 - 点击“撤回”时需二次确认。 5. 状态要求页面初始化时加载单据详情和审批记录需包含loading状态、错误状态。操作完成后刷新当前页面数据。 附加要求 - 按钮的展示逻辑需要用【权限判断函数】统一控制不得在模板中写死。这类页面我踩过最大的坑就是“按钮写死”。AI如果不理解审批流的状态流转很容易把所有按钮都渲染出来导致发起人也能看到“审批通过”按钮。后来我总结出一个经验在提示词里给AI一个“角色状态”的二维矩阵示例。比如明确写出“当前角色为A且状态为B时显示什么按钮”AI就能比较容易地理解动态控制的逻辑。3.5 模板五系统设置页面权限分级敏感操作保护系统设置页面看起来简单实际上对权限和安全的要求极高。B端后台的“配置管理”“角色管理”“日志查询”都属于这类页面。我常用的模板如下请生成一个【配置模块】设置页面面向【角色】。 页面包含 1. 配置项分组展示将【配置项列表】按【分组名称】分组展示。 2. 敏感操作保护修改核心配置时需弹出二次确认弹窗并输入当前账号密码进行二次验证。 3. 权限控制页面中的某些按钮仅对【角色A】可见其他角色不可见。 4. 操作反馈保存成功后弹出成功提示失败后展示错误原因。 5. 日志记录所有修改操作需生成操作日志记录操作人、操作时间、修改前后值。这里特别值得说的是“密码二次验证”这个设计。很多AI生成的代码只会做二次确认弹窗但不会做密码验证。在真实B端系统里修改支付配置、删除数据源这些高风险操作基本都需要二次验证。如果提示词里不写AI绝对不会主动生成。另外“操作日志”也是容易被忽略的点。B端系统出问题时要追溯“谁在什么时候改了什么”没有操作日志排查起来极其痛苦。我在模板里写“修改前后值”就是为了让日志不仅记录“改了什么”还能记录“从什么改成什么”。3.6 模板六批量操作与导入导出大任务反馈结果汇总B端后台还有一个常见场景批量操作和导入导出。比如批量审核、批量删除、Excel导入用户、导出订单报表。这类场景最大的痛点是“长时间任务没有反馈”。如果AI只生成一个“导出”按钮点击后没有任何loading或进度反馈用户会以为系统坏了。我给这类页面设计的提示词模板如下请生成一个【数据模块】批量操作功能面向【角色】。 功能要求 1. 列表页支持多选选中后展示批量操作按钮按钮包括【批量操作1】【批量操作2】。 2. 点击批量操作后弹出二次确认框展示本次操作影响的数据条数。 3. 批量操作提交后需展示操作进度可以以进度条或百分比形式展示。 4. 操作完成后展示执行结果汇总包括成功条数、失败条数、失败原因。 5. 导出功能支持按当前筛选条件导出数据导出过程中需展示loading状态导出完成后提供文件下载链接。 6. 导入功能支持Excel导入导入前需校验文件格式和大小导入后展示导入失败的行数和错误原因。这个模板的核心思路是“让AI把任务反馈做完整”。B端用户面对批量操作时最怕的就是“点了没反应”或者“只报成功不报失败”。把成功条数、失败条数、失败原因都展示出来用户才能真正信任这个功能。4. Prompt提示词常用的“状态描述”关键词表我平时写提示词有一个反复使用的“状态描述关键词表”。如果你不知道该怎么给AI描述页面状态可以直接从下面这个表里挑。场景状态关键词使用目的数据加载loading状态、骨架屏、加载中避免页面白屏数据为空空数据状态、暂无数据、空状态引导避免空表格、空图表请求失败错误状态、加载失败、请重试、错误占位图提供异常反馈操作成功成功提示、Message、Notification确认操作生效操作失败失败原因、不清空表单减少用户重复劳动删除操作二次确认、取消/确认防止误操作批量操作操作进度、进度条、成功条数、失败条数大任务可视化反馈导入导出文件格式校验、文件大小限制、下载链接规范文件操作权限控制按钮权限、角色判断、权限函数动态控制可见性日志审计操作人、操作时间、修改前后值安全追溯这张表我建议你直接收藏。每次写完提示词对照这张表检查一遍看有没有漏掉哪些状态描述。漏掉一个AI就少生成一个分支。5. 在真实项目里用Prompt生成B端后台有哪些防翻车技巧5.1 让AI先出“任务清单”再出“页面代码”很多AI工具有一个特点你让它直接生成完整页面它容易把功能糅在一起代码不可控。我的习惯是先让AI生成一个“任务拆分清单”确认无误后再让它写代码。比如请先不要写代码。先帮我拆解“用户管理页面”需要完成哪些业务任务每个任务涉及哪些页面状态用列表形式输出。这一步能有效避免AI生成的代码“东一榔头西一棒槌”。等它输出任务清单后你还能在清单层面提出修改不用等代码写完了再去否定。5.2 给AI一个“参照物”比让AI“闭门造车”更高效如果你手头有一个已经做好的相似页面可以直接告诉AI“参考当前项目的XX页面风格生成新的YY页面。”AI在文本理解上会更容易对齐你的预期。如果没有任何参照物也可以描述你希望参考的设计规范比如“按钮风格使用圆角、表格密度中等、筛选区固定在页面顶部”。5.3 分模块生成不要“一个大Prompt生成整个系统”我建议每次只让AI生成一个模块用户管理就是一个用户管理不要同时让它生成用户管理、角色管理、权限管理、操作日志。模块划分得越细AI的注意力越集中生成质量越高。如果是整个后台系统我会先让AI生成“页面框架”和“菜单配置”然后逐个模块生成最后再统一联调。5.4 代码生成后至少要检查这四个点我每次拿到AI生成的页面代码会固定检查四个地方检查loading状态是否覆盖了所有异步请求检查提交成功后是否正确刷新列表或跳转检查权限控制是否真的生效而不是只做了视觉隐藏检查二次确认弹窗是否能被正常触发这四个点是B端后台最常见的翻车位置。每检查出一个问题我就回填一条提示词把问题描述补充进去重新生成。多来几次AI就能生成出接近生产可用的代码。6. 常见问题速查表为什么AI生成的B端后台总是不对劲问题现象原因解决方案生成出来的页面没有loading状态提示词里没有描述异步状态补充“所有请求需包含loading状态”操作成功后列表不刷新提示词里没有描述操作反馈补充“操作成功后刷新当前列表”删除没有二次确认提示词里没有描述敏感操作保护补充“删除需弹出二次确认框”空数据时显示空白表格提示词里没有描述空数据状态补充“展示暂无数据占位图”所有按钮对所有人可见提示词里没有描述权限控制补充“根据当前角色动态显示按钮”表单提交失败后内容清空提示词里没有描述异常保留补充“提交失败时不清空表单”审批操作按钮写死提示词里没有描述状态流转补充“根据角色和状态动态展示操作按钮”导出功能点击后无反馈提示词里没有描述任务进度补充“导出中展示loading完成后提供下载链接”动态表单只有固定行数提示词里没有描述动态添加逻辑补充“支持动态添加和删除子表单”筛选条件变化后图表不联动提示词里没有描述联动关系补充“筛选变化时所有图表联动更新”这张表我基本是结合自己踩过的坑整理出来的。你在写提示词之前可以先把这张表过一遍把涉及到的场景直接用自然语言写进提示词里。7. 把“页面设计”升级为“任务设计”才是B端后台Prompt的正确打开方式我个人在实际生成B端后台的过程中最核心的体会就是不要用“设计页面”的思维写提示词要用“设计任务”的思维写提示词。每写一个提示词我都会问自己三个问题用户在这个页面上要完成什么业务任务这个任务从开始到结束要经历哪些状态每个状态出现时用户应该看到什么、能操作什么这三个问题想清楚了提示词就很容易写出来。AI生成出来的页面也不会只是一个好看的壳而是一套能跑通业务的真实模块。最后再分享一个小技巧写提示词时尽量用“短句明确动词”。比如“展示”“支持”“弹出”“刷新”“提交”“校验”这些动词能精确约束AI的行为。少用“漂亮”“清晰”“合理”这类模糊形容词因为AI无法量化这些词生成出来的效果往往不符合你的心理预期。我见过很多新手写提示词花大量篇幅描述“界面要好看”但对“任务怎么流转”只字不提。结果生成出来的东西光鲜亮丽却一碰就碎。反过来把业务任务和页面状态描述清楚哪怕你对视觉风格只字未提AI也会基于训练数据里的最佳实践生成出一个专业且耐用的B端后台页面。这个思路不仅仅适用于用户管理、商品管理这些标准模块也适用于审批流、数据看板、系统设置这些复杂的B端场景。把“任务”和“状态”当成提示词的骨架把“视觉风格”当成可有可无的皮肉你的AI生成效率和质量都会有质的提升。
