1. 先说一个普遍现象AI画B端后台为什么总是“中看不中用”做B端后台的朋友最近应该都有类似感受AI生成营销落地页、个人网站效果确实惊艳配色、排版、动效样样在线。但一到后台管理系统生成出来的东西总差点意思——表格能看按钮能点可一到真实环境就露馅没有空态没有加载态接口报错直接白屏点个删除按钮连确认框都没有更别提筛选、分页、权限这些刚需功能了。我前后用AI生成过三四十个后台页面从订单管理到权限配置都试过。一开始也踩了同样的坑后来摸索下来发现问题的根源不在AI能力而在提示词的打开方式不对。绝大多数人写AI提示词时习惯把注意力放在“界面长什么样”上——表格几列、按钮什么颜色、左侧菜单怎么排。这些当然重要但B端后台的核心从来不是视觉而是业务任务是否跑得通、页面状态是否覆盖全。举一个很典型的例子。很多人会这样写“帮我生成一个订单管理页面要有表格、筛选器、分页风格要简洁大气。”这个Prompt不能说错但它本质上是在描述一个“静态的界面草图”。AI收到这种指令只能凭训练数据里的通用印象去猜你的业务规则订单状态有哪些筛选条件是联动还是独立导出按钮要不要做权限校验删除是大程度删除还是软删除这些它全都要靠猜。猜得对页面能用猜不对就成了那个“中看不中用”的demo。所以后来我把提示词的思路彻底换了一遍不再描述界面而是描述业务任务。页面上的每一个元素都对应某个业务任务的一个环节每一次交互都是任务状态的一次流转。想清楚这件事之后AI生成B端后台的可用性提升了一个量级。2. 核心方法论五要素Prompt模板2.1 为什么“业务任务”比“界面元素”更适合当提示词的主线后台系统本质上是给特定角色完成特定工作的工具。运营要处理订单财务要核对账单管理员要配置权限。每个页面存在的唯一理由是“某个角色在这里完成某些任务”。所以当你把提示词的主线从“长什么样”换成“要完成什么任务”AI的理解就会从“视觉排版”切换到“业务逻辑”这两个维度产出的质量差异非常大。以“订单管理页”为例。如果主线是界面描述AI会给你一个标准的CRUD表格列名、筛选、分页应对一下。但如果主线是业务任务你会自然带出以下信息运营人员进入页面后第一步要做什么最常见的工作路径是什么哪些操作需要二次确认哪些操作会影响其他模块。这些信息一旦写进提示词AI生成的页面就不再是“看起来像订单管理”而是“真的能处理订单管理的工作”。这背后的原理也简单大语言模型在训练时见过海量的后台系统代码和产品文档它对“界面描述”的反应是模式匹配对“任务描述”的反应是逻辑推理。前者容易产出千篇一律的套壳页面后者能调动它对业务流转、异常处理、权限控制的综合理解。所以写Prompt的第一步是强迫自己用“任务清单”而不是“组件清单”来描述页面。2.2 五要素模板的完整结构我自己现在写的B端后台Prompt固定包含五个要素缺一不可角色与场景告诉AI它是什么角色、在什么行业背景下做设计。核心业务任务列出用户在这个页面上要完成的所有任务按优先级排序。数据模型定义页面上涉及的字段、类型、枚举值、字段之间的约束关系。页面状态覆盖加载中、空数据、筛选无结果、接口异常、操作成功/失败、权限不足等全部状态。交互行为与约束明确每个操作触发什么流程、需要什么确认、有什么权限限制、风格和组件有什么约定。这五个要素对应到一份Prompt里的典型段落是这样组织的你现在是一名资深B端后台产品经理兼前端架构师服务于一家电商公司的运营中台团队。请设计一个“订单管理页面”的完整方案。 【核心业务任务】 1. 运营人员进入页面后默认展示最近7天的订单列表。 2. 支持按订单状态、下单时间范围、订单金额区间进行组合筛选。 3. 列表中展示订单号、客户名称、商品摘要、订单金额、订单状态、下单时间、操作列。 4. 点击“发货”按钮弹出确认框确认后订单状态从“已支付”变为“已发货”。 5. 点击“取消订单”需要二次确认并填写取消原因取消后状态变为“已取消”。 6. 支持将当前筛选结果导出为Excel文件。 7. 点击订单号跳转到订单详情页。 【数据模型】 - orderNo: string订单号格式如“DD202506010001” - customerName: string客户名称 - goodsSummary: string商品摘要格式如“iPhone 15 Pro Max 256G x 1” - amount: number订单金额单位分 - status: enum可选值为 PENDING(待支付)、PAID(已支付)、SHIPPED(已发货)、COMPLETED(已完成)、CANCELLED(已取消) - createdAt: datetime下单时间 - cancelReason: string取消原因仅CANCELLED状态时有值 【页面状态要求】 1. 加载状态列表数据请求中展示骨架屏禁止白屏。 2. 空状态系统内没有任何订单时展示空数据插画和“去创建第一笔订单”的引导入口。 3. 筛选无结果展示“未找到匹配的订单”提示并提供“清除筛选条件”按钮。 4. 接口异常展示错误提示文案并提供“重试”按钮重试时显示加载状态。 5. 操作反馈发货、取消操作成功后Toast提示成功信息并自动刷新列表数据。 6. 权限控制当前角色无“取消订单”权限时该按钮隐藏而不是置灰。 【交互与约束】 - 订单金额和下单时间列支持排序。 - 订单状态使用Tag组件颜色区分待支付橙色、已支付蓝色、已发货紫色、已完成绿色、已取消灰色。 - 取消订单的确认框必须包含原因填写区原因必填。 - 所有按钮点击必须有防重复提交处理。 - 表格采用左右布局的筛选区筛选区最多两行超出部分收纳到“更多筛选”中。这份Prompt如果喂给当前主流的AI编程工具或大模型产出的页面已经能达到“可以直接联调接口”的程度。后面我会逐步拆解每个要素为什么要这么写以及哪些细节最容易踩坑。2.3 要素拆解之一角色与场景决定AI的“专业姿势”角色设定不是可有可无的前缀。同样是“设计订单管理页面”“前端工程师”角色和“产品经理”角色产出的重点完全不同。前端角色会关注布局、组件、交互实现产品角色会关注需求逻辑、状态流转、异常分支。B端后台实际需要的是两者的结合所以我会把角色定位成“资深B端后台产品经理兼前端架构师”让AI同时调用产品思维和工程思维。场景信息也很关键。给“电商运营中台”设计订单页面和给“企业采购系统”设计订单页面业务任务的侧重点完全不一样。电商更关注发货、退款、售后流转采购更关注审批、对账、供应商协同。写Prompt时花两行字交代行业背景AI输出的业务规则会更符合真实场景。2.4 要素拆解之二核心业务任务按优先级写清楚业务任务是整个Prompt的心脏。写的时候有几个技巧任务要按“用户的使用频率”排序。运营每天看订单列表的频率远高于导出Excel所以列表加载、筛选是最高优先级任务导出是次要任务。AI在理解优先级后会把重要功能放在视觉重心位置次要功能收进二级入口。任务要描述动作而不是描述组件。不说“页面要有筛选器”而是说“运营人员需要按订单状态、下单时间范围、订单金额区间进行组合筛选”。一个“筛选器”组件AI只能给个外壳但一个“组合筛选”的任务描述AI会自动考虑筛选项之间的并列关系、重置逻辑、筛选后列表刷新等问题。任务要写清前后端的状态流转。“发货后状态从已支付变为已发货”这一句话比一百句“按钮要好看”都值钱。因为B端页面的95%的交互都是状态流转AI一旦理解状态流转规则生成的代码里会自然包含状态判断和更新逻辑。2.5 要素拆解之三数据模型杜绝AI瞎编字段的唯一的办法AI生成后台页面最让人头疼的问题就是瞎编字段。你不定义字段它就会自己发挥这个页面没有“订单类型”字段AI给加上了你的后端接口返回的是“custName”AI写的是“customerName”。字段名对不上联调的时候全是泪。所以数据模型必须在Prompt里显式定义而且定义得越细越好。字段名、类型、必填还是可选、枚举值的具体字符串、字段的业务含义全都要写清楚。特别是枚举值很多后台页面的Bug都出在状态枚举对不上。前端显示“已支付”后端存的只有数字“2”这种不一致在AI生成代码时非常常见提前定义枚举值是成本最低的规避方式。单位问题也容易被忽略。订单金额到底是元还是分、时间戳是秒还是毫秒这些细节不写清楚AI生成的代码会带着自己的猜测。我在Prompt里几乎每次都会加“金额单位分”之类的说明看着啰嗦实际能省掉大量返工。2.6 要素拆解之四页面状态B端后台的灵魂如果说业务任务是B端后台的骨架页面状态就是血肉。我用“状态覆盖度”来衡量AI生成后台页面的成熟度成熟度高的Prompt生成的页面一定包含了完整的六种状态加载态、空态、筛选无结果态、接口异常态、操作反馈态、权限控制态。为什么状态这么重要因为B端后台的使用者不是普通消费者而是每天面对这套系统工作八小时的员工。他们遇到空数据、接口报错是家常便饭如果系统在这些时刻白屏或者没有反馈工作效率会断崖式下降。而且这些状态恰恰是AI训练数据里很少出现的——网上的后台模板为了展示效果全是塞满数据的“美好状态”AI默认生成的就是这种没有异常处理的页面。所以写Prompt时我会把每个状态细化成“什么场景出现 展示什么内容 提供什么操作”而不是笼统地写“要有加载状态”。比如空状态不只要说展示插画还要说“提供去创建第一笔订单的引导入口”接口异常不只要说提示错误还要说“提供重试按钮重试时显示加载状态”。状态描述得越具体AI生成的处理逻辑就越完整。2.7 要素拆解之五交互行为与约束把边界划清楚最后一个要素是交互约束。这里主要写两类内容一类是业务规则约束比如取消订单必须填原因、按钮要防重复提交另一类是设计规范约束比如状态用Tag组件且不同状态不同颜色、表格布局采用左右筛选区。设计规范约束对于后台系统来说尤其重要。B端后台通常都有现成的组件库和设计规范AI不了解这些规范时会输出一堆自定义组件风格和既有系统格格不入。在Prompt里给出组件约定等于提前给AI划了一条边界保证输出和现有系统风格统一。如果你用的是具体组件库可以直接把组件名写进去比如“使用Ant Design的Table组件”“用ProForm的Search表单”AI会按照这些组件的API来进行生成代码可用性直接上一个台阶。3. 实战验证用订单管理页把模板跑一遍3.1 一份可以直接复制的完整Prompt前面给出了订单管理页的Prompt示例这里我把它补全成一个可以直接复制使用的版本。这个版本我实际测试过多次配合当前主流的AI编程工具使用基本一次生成就能达到“可评审”的完成度。你是资深B端后台产品经理兼前端架构师熟悉电商运营中台场景。请设计订单管理页面输出包含页面结构说明和关键交互逻辑的产品方案。 【业务背景】 这是一套面向电商运营人员的管理后台。运营人员每天需要处理大量订单核心诉求是快速找到需要处理的订单、查看关键信息、完成发货或取消操作。系统用户角色分为运营专员和运营主管运营主管额外拥有“取消订单”的权限。 【核心业务任务】 1. 默认展示最近7天订单列表按下单时间倒序排列。 2. 支持按订单状态、下单时间范围、金额区间组合筛选筛选后列表自动刷新。 3. 列表字段订单号、客户名称、商品摘要、订单金额、订单状态、下单时间、操作列。 4. 点击操作列“发货”弹出确认框显示订单号和客户名确认后状态由PAID变为SHIPPED并记录操作时间。 5. 点击操作列“取消订单”弹出对话框必须填写取消原因原因不能少于5个字符。确认后状态变为CANCELLED。 6. 支持导出Excel导出的数据必须是当前筛选条件下的全量数据不依赖当前分页。 7. 点击订单号文本跳转订单详情页新标签页打开。 【数据模型】 orderNo: string唯一 customerName: string goodsSummary: string如“商品名 x数量” amount: number单位分 status: string枚举PENDING/PAID/SHIPPED/COMPLETED/CANCELLED createdAt: stringISO格式 shippedAt: string可空 cancelReason: string可空 【页面状态】 1. 首次加载骨架屏。 2. 列表无数据空态插画文案“暂无订单”操作按钮“去创建订单”跳创建页。 3. 筛选结果为空文案“未找到匹配的订单”操作按钮“清除筛选”。 4. 请求失败文案“订单数据加载失败”操作按钮“重试”。 5. 发货成功Toast提示“发货成功”列表刷新并保留当前筛选条件和页码。 6. 取消成功Toast提示“订单已取消”列表刷新。 7. 无权限时“取消订单”按钮不展示不影响其他功能。 【交互与设计约束】 1. 订单状态用Tag展示颜色PENDING橙色、PAID蓝色、SHIPPED紫色、COMPLETED绿色、CANCELLED灰色。 2. 金额列右对齐保留两位小数。 3. 筛选区最多两行第三行起的筛选项收进“更多筛选”折叠区。 4. 发货和取消按钮的点击事件要做防重复提交。 5. 表格分页固定在底部支持每页10/20/50条切换。3.2 这份Prompt到底比普通写法强在哪如果用“帮我生成订单管理页面要有表格筛选分页”这样的PromptAI大概率会生成一组组件拼出来的静态界面核心逻辑全是empty函数。但用上面这份五要素PromptAI生成的结果会有几个明显变化。第一个变化是代码结构里会多出一层“状态管理”。AI能识别出这个页面存在PENDING、PAID、SHIPPED、COMPLETED、CANCELLED几种状态会自动设计状态对应的枚举常量和展示映射而不是把所有状态都放在一个字符串里做随机渲染。第二个变化是交互闭环完整了。发货、取消不再是弹个框就完事而是有确认、有校验、有防重复、有操作后的列表刷新。第三个变化是异常分支齐全加载、空态、错误、重试这些在普通Prompt里完全不会出现的内容会被自动纳入生成范围。实测下来用这份Prompt生成的代码联调后端接口时基本只需要改接口地址和字段映射业务逻辑层面的返工极少。对比之前的方式一个订单管理页的联调时间从一两天缩短到半天以内。3.3 页面状态降级的处理细节骨架屏、空态、错误态页面状态作为Prompt里最容易被忽略也最有价值的部分我在实际使用中积累了几个处理细节。骨架屏和白屏的区别。很多AI生成的加载态只是给表格加一个loading属性这就够用了但如果能更进一步指定骨架屏的行数和列布局页面加载时的视觉体验会好很多。我通常会在Prompt里写“列表加载中展示骨架屏结构为左侧筛选区固定右侧表格区按8行占位”。这样AI能明确生成与最终布局一致的加载占位。空态要区分“有没有数据”和“筛不到数据”。这两个场景的文案和操作应该完全不同。没有数据时是“从0到1”的引导提供创建入口筛选没结果时是“从多到少”的提示提供清除筛选的出口。混为一谈用户会被卡在一个没有出口的空页面上。错误态必须有重试动作。接口异常时展示“重试”按钮是最小可用的处理方案更好的方案是提示“请检查网络后重试”的同时保留上次的筛选条件让用户恢复现场的成本降到最低。这些细节普通Prompt不会要求但写进Prompt后AI会老老实实生成。4. 从单页到系统多页面共用的Prompt工程套路4.1 用“全局约定 单页Prompt”控制一致性单个页面的Prompt写好了真正的工程化挑战在于多页面之间的一致性。一个后台系统少则十几个页面多则几十个如果每个页面都从零写Prompt生成的代码会东一块西一块这个页面用的状态标签组件是Tag那个页面又用了自定义的徽标风格规范全乱套。我的做法是建立一套“全局约定文档”把所有页面共用的规则固定下来然后每个页面的Prompt都引用这套约定。全局约定文档包含以下内容项目使用的技术栈和版本例如Vue3 TypeScript Ant Design Vue通用状态组件的规范比如状态Tag使用统一的color映射表表格通用规则分页组件、默认页大小、操作列的按钮布局通用反馈规则所有删除操作必须二次确认、所有成功操作必须Toast提示权限控制的统一实现方式写单个页面Prompt时把全局约定摘录到Prompt的开头或“约束条件”部分。这样AI生成的每一页都会带上同一套规范代码风格和交互模式自然统一。维护成本也不高全局约定改动后需要重新生成的页面重新喂一遍新约定即可。4.2 跨页面的数据模型复用多页面系统里最常见的问题是同一个实体在不同页面里的字段定义不一致。订单列表页里那个字段叫“customerName”订单详情页里AI又生成一个“clientName”后端其实是同一个字段。这种问题在人工开发时尚且难免AI生成时更容易各写各的。解法是把数据模型做成全局共享的“实体定义”每次Prompt都粘贴同一份。订单实体、用户实体、商品实体只要页面涉及就复制同一段定义不做任何改动。随着生成页面增多实体定义的版本也会越来越完善这些完善会自然沉淀下来成为团队的领域模型资产。4.3 权限与角色怎么进Prompt后台系统的权限逻辑无法回避但也不用写得过于复杂。在单页Prompt里只需要做到“基于角色描述可见性和可操作性”即可。比如“运营主管额外拥有取消订单权限运营专员没有”这个信息对AI的含义就是页面上有一批操作只需要对特定角色开放渲染时需要读取角色信息来判断是否展示。全局层面则建议在Prompt里明确“当前用户角色从全局状态中读取禁止在页面内写死角色”。这样AI生成的所有页面都会遵守“角色来自全局Store”的约定权限控制的实现方式保持一致管理员配权后页面联动生效不至于出现改一处权限要翻遍十几个页面的窘境。5. 实操中踩过的坑和排查实录5.1 AI瞎编字段名唯一解法是显式定义数据模型有一次我生成一个对账单页面Prompt里没有写数据模型AI给生成了“billAmount”“totalAmount”“amountDue”三个看起来相似的金额字段后端接口其实只有一个“totalAmount”。查了一会儿才反应过来AI把金额在不同业务场景下的展示方式误解成了不同的字段。从那以后我所有的Prompt都把数据模型放在最醒目的位置并且在“约束条件”里加一条硬性规定“页面代码中所有字段名必须严格按照数据模型定义不得自行创造新字段名后端字段名以本Prompt为准。”实测下来这条约束能显著减少瞎编字段的情况。即使AI偶尔还是在后续分批生成时走偏你也有依据让它改正——把模型定义重新贴给它和它说“字段名再对一遍”。5.2 交互写到位了但状态没写到位早期我写过一份“能完成发货操作”的订单页面Prompt交互动作写得很细致发货确认框、发货成功提示都有唯独漏了“发货成功后列表要刷新”。生成出来的页面操作完Toast提示“发货成功”但列表里那个订单的状态纹丝不动用户以为操作失败了实际后端已经改了状态刷新页面才发现已经发货。这类问题在B端页面里极其常见操作行为写全但状态刷新和页面恢复写漏了。现在我写Prompt都会刻意检查三类状态闭合操作成功后的列表刷新、操作失败后的错误提示与恢复、筛选条件变更后的列表重载和页码重置。这三个闭合点任意一个缺失交互就给用户留下了“系统不好用”的印象。5.3 筛选项一多AI容易把页面堆成“表单墙”后台页面的筛选区是个容易失控的地方。筛选项多的时候AI倾向于把所有条件都在页面上平铺出来结果筛选区占了半个屏幕列表区域被挤压得可怜用户翻看数据非常吃力。这个坑可以靠约束条件解决。我一般会在Prompt里加“筛选区最多显示两行第三行起收到‘更多筛选’折叠区”“筛选区使用折叠面板组织基础条件常驻高级条件折叠”。用这两个约束配合“筛选区宽度不超过页面宽度的40%”之类的量化描述AI生成的筛选区就正常多了。归根结底AI不知道你对信息密度的容忍度你需要把边界划给它。5.4 状态设计自查清单为了尽量减少遗漏我把常用的状态检查项整理成了一份清单每次写Prompt后按清单过一遍基本不会漏状态首次进入页面时数据请求中展示什么接口返回异常时用户看到什么能不能重试系统没有任何数据时用户看到什么有没有引导入口筛选后没有结果时用户看到什么怎么恢复操作成功后页面是否刷新筛选条件和页码是否保留操作失败时如何提示用户能否重新操作无权限角色看到什么敏感操作是隐藏还是禁用数据量大时表格的分页/虚拟滚动如何处理这份清单覆盖了我遇到过的90%的页面状态问题建议你在写Prompt时直接对照着补全“页面状态要求”段落。6. 最后再分享一点个人体会用了这么久AI生成B端后台我现在最大的感受是这份活儿本质上不是在考AI的能力而是在考我把业务讲清楚的能力。之前总觉得AI生成的东西不够专业后来发现是我给的输入不够专业。一个页面背后涉及的场景、角色、数据规则、状态流转我在脑子里过了几遍写成PromptAI就能还原出八成我偷懒少写一段状态描述AI就用它训练数据里那个“没有异常处理”的通用后台模板来回复我。如果你刚开始尝试不要追求一步到位。先按五要素结构写一份看生成结果漏了什么再迭代补充。你会明显感觉到随着Prompt越来越贴近真实的业务任务AI的产出也在一点点从“好看的前台页面”变成“能用的后台系统”。这个过程本身就是一次对业务流程的梳理受益的不只是AI生成的代码还有你对系统本身的理解。