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端后台的页面状态至少包括以下几种状态类型触发条件页面表现初始加载页面首次打开骨架屏或加载动画空数据接口返回空列表空状态插图引导文案加载失败接口报错或超时错误提示重试按钮无权限当前角色无访问权限403提示返回首页部分成功批量操作部分失败成功/失败分项提示操作确认点击危险操作二次确认弹窗操作结果提交后返回成功/失败Toast提示这些状态如果在提示词里不写AI默认只会生成“有数据”这一种情况。但实际项目中空数据和异常状态才是用户最常遇到的。我的做法是在提示词里专门用一段来描述状态页面需要处理以下状态加载中显示骨架屏数据为空时显示“暂无合同数据点击右上角新建合同”的引导加载失败时显示“数据加载失败请检查网络后重试”并提供重试按钮当前用户无审批权限时操作按钮置灰并显示tooltip提示“您没有该合同的审批权限”。这段描述直接决定了生成页面的完整度。实测下来加了状态描述的提示词生成结果的可直接用比例能从30%提升到70%以上。2. 从业务任务到Prompt一套可复用的模板结构2.1 模板的整体框架经过多次迭代我目前用的B端后台Prompt模板大致分为五个部分业务背景这个系统是做什么的给谁用解决什么问题角色与权限有哪些角色每个角色能做什么页面结构页面由哪些区域组成每个区域放什么状态与交互页面有哪些状态用户操作后发生什么视觉与组件规范用什么组件库风格偏好响应式要求这五个部分不是随便排的顺序有讲究。业务背景放最前面是为了让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端后台页面的生成需求。当然每个项目都有自己的特殊性模板只是起点具体内容还需要根据实际业务调整。最后分享一个我自己的习惯每次生成完页面后把提示词和生成结果一起存档。下次遇到类似页面时先翻存档找到最接近的提示词修改业务背景和角色权限部分直接复用。这样效率最高质量也最稳定。