上个月帮一个朋友收拾烂摊子，他们组用AI生成了一套后台管理界面，看着确实挺唬人——登录页、侧边栏、数据卡片、图表一应俱全。结果一接真实业务，全崩了：订单列表没有筛选条件，表单没有校验规则，点击编辑弹出来的居然还是静态假数据。问题出在哪？他们的提示词写的是“生成一个订单管理页面，包含表格、搜索框、分页”。这种写法，AI只能给出“页面的皮”，给不了“业务的神”。
这篇文章就是来讲透这件事的：AI生成B端后台，提示词到底该怎么写。我会给你一套可复用的模板，从业务任务拆解一直写到页面状态的Prompt设计，覆盖空态、加载态、错误态、数据态这些B端页面最容易翻车的部分。适合正在用AI辅助开发管理后台的开发者、前端工程师，以及想提升内部工具搭建效率的产品同学。看完你可以直接照着改自己的提示词。
1. AI生成B端后台的普遍翻车现场
先花点时间把“翻车现场”拆细一点，因为大多数人不是不会写Prompt，而是根本不知道自己写的Prompt缺了什么。
1.1 表面光鲜、实际不可用的典型症状
我见过太多这类AI生成的后台了，高度相似的症状基本可以归纳成四类。
第一，布局满装备但功能残废。侧边栏菜单、顶部面包屑、卡片式数据统计全都有，看起来很有管理后台的样子。但菜单点了没有路由，卡片数据是写死的静态数组，切个用户还是一样。
第二，字段堆了一堆但业务对不上。比如“客户”字段直接用英文原名没做格式化；订单金额没有单位；时间戳用了一串纯数字。这些细节在真实业务里全部要返工，而且返工的痛苦程度远大于当初手工写页面。
第三，交互状态基本缺失。没有一个AI默认会帮你把“加载中”“无数据”“接口报错”“列表为空”这四种状态做全。大多数情况下它只做了数据状态，也就是“有数据时的表格长什么样”，其他三种状态全靠运气。
第四，权限和角色只是装饰。B端后台区别于C端页面最大的地方就是角色回路——管理员能删除，操作员只能查看，这种逻辑AI几乎不会主动写。它默认生成出来的按钮人人可点，这在真实企业系统里根本交不了差。
这些问题的根源，不是AI能力不行，也不是模型太笨，而是提示词只给了“页面的皮”，没有给“业务的骨”。
1.2 问题的本质：提示词停留在“页面层”而非“任务层”
先说一个判断标准：你写的提示词里，如果出现最多的词是“表格、搜索框、侧边栏、卡片”这类组件名，那你就在“页面层”写提示词；如果你写的是“运营要筛选出超时未发货的订单，并批量通知仓库”，那你就在“任务层”写提示词。
页面层提示词的问题在于，LLM是靠统计概率生成内容的。给它“生成一个订单管理页面”，它脑海里的“典型订单页”是海量网页样本拼起来的平均值——可能来自电商后台、仓储系统、SaaS CRM等各种场景的混血。结果就是：什么都有点像，什么都不精确。
任务层提示词则相反。当你告诉它“这个页面的核心任务是让客服在30秒内找到问题订单并处理”，它就能反推出来：需要按订单状态筛选、需要查看操作日志、需要异常标记、需要快捷处理按钮。页面组件反而自然地长出来了。
所以，写B端后台提示词的第一原则：先写业务任务，再写页面结构。任务拆对了，页面是AI自己会长出来的东西。
2. 从业务任务出发的提示词设计框架：先拆任务，再谈页面
那“先拆任务”具体怎么拆？我总结了一个五步框架，每一步对应提示词里的一段话。
2.1 五步任务拆解法
第一步，写清楚“这个页面给谁用”。是给运营还是给财务，是给客服还是给采购？角色不同，页面的默认字段和敏感度完全不同。给财务看的页面默认要精确到分、要留审计日志；给客服看的页面则突出快捷操作，字段的展示密度反而不是第一优先级。
第二步，写清楚“用户在这个页面上的核心任务”。只说一个主任务，不要贪多。一个B端页面如果同时承载“查询订单”“做财务报表”“管理供应商”，那它大概率是个失败页面，AI也处理不好这种多重目标。一旦任务多了，AI的输出就会变成一堆组件的无脑堆叠，每个任务都沾一点，每个任务都没做透。
第三步，列出完成这个任务的关键动作。比如客服处理异常订单的页面，关键动作可能是：筛选异常 → 查看客户历史 → 修改配送地址 → 发起补发 → 记录处理备注。每个动作对应一组组件，动作清单就是页面功能的骨架。
第四步，写明数据从哪来、每条数据的关键字段是什么。这个尤其重要。B端页面没有一个字段是“装饰”，每个字段都要被某个业务流程消费。你可以在提示词里直接贴出后端数据模型或接口返回示例。AI一看到真实的字段，就会自动收敛生成范围，不会再去发明一些后端根本不存在的幻影字段。
第五步，把异常情况写出来。“如果接口超时怎么办”“如果列表查询结果为空怎么办”“如果用户没有权限删除怎么办”。AI非常吃这一套，你越写异常，它越能生成健壮的代码。理想状态下，你甚至可以把异常提示的文案直接写进提示词里，比如“查询无结果时显示：抱歉，没有找到符合条件的记录，请尝试调整筛选条件”。
2.2 一个完整的任务拆解示例：订单管理模块
我拿订单管理做一个实际的拆解示例，你可以直接参考这个套路去拆你自己的页面。
角色：电商后台运营人员，日常处理发货和售后。
核心任务：在最短时间内定位异常订单并处理。
关键动作：
- 按订单状态、支付时间、收货城市筛选订单
- 查看单个订单的完整详情（商品明细、物流信息、操作日志）
- 对未支付订单做催付操作
- 对已付款订单做发货操作
- 对售后订单做退款/退货审核
- 批量导出订单数据
数据字段：订单号、下单用户ID、订单状态、支付金额、支付时间、收货地址、商品快照列表、操作日志。
异常情况：查询无结果时给“暂无相关订单”空态；接口慢时给加载骨架屏；退款审核需要角色权限校验。
把这个拆解塞进提示词，AI生成出来的东西，跟“给我一个订单管理页面”完全是两个物种。前者知道自己在做一张给运营用的工具页，后者只知道自己在凑一张“看起来像后台”的拼贴画。
2.3 为什么“任务拆解”能直接提升AI输出的质量
这里有个底层原理值得说一下。LLM生成页面时，本质是在做一个“意图→结构”的映射。任务拆解给了它清晰的意图边界，它就不用靠猜，而是可以按业务逻辑去推导页面应有的组件和行为。任务拆得越细，AI的推导路径越短，输出的噪点越少。
我实测下来，同样的模型，同样的基础提示词，在做了任务拆解之后，生成的表格列字段、筛选条件、操作按钮的准确率明显高出一个级别。这是提示词工程里性价比最高的一个改动，比堆砌任何“高级Prompt技巧”都管用。
3. 核心提示词模板：角色、上下文、数据模型三段式
任务拆解是思想，落到提示词里还需要一套稳定的结构。我长期使用的模板可以分成三段：角色设定段、业务上下文段、数据模型段。
3.1 角色设定段：让AI知道自己是“资深B端产品工程师”而不是“通用助手”
第一段先锁身份。不要只写“你是一个AI”，而要写：
你是拥有十年B端后台产品设计与开发经验的工程师，擅长将业务任务转化为高效、可维护的管理后台页面。你的输出需要遵循企业级SaaS产品的交互规范和信息架构原则。
这一段是“思维定势触发器”，它引导模型调用它训练数据里所有关于B端后台的知识，而不是泛泛地调用“网页开发”的知识。加这段之后，AI会自觉考虑权限、状态、角色这些B端专属问题。
3.2 业务上下文段：把任务拆解的产物翻译成人话
第二段就是把第2节的任务拆解结果放进去。注意用短句、分条写，不要写成一大段散文。模型对结构化的输入更敏感。我常用下面这种格式，把业务背景、用户目标、操作流程、交互要求分列清楚，每一条都独立成行。
业务背景：这是一个电商后台的订单管理模块，使用者是运营人员。
用户目标：快速定位异常订单并完成处理。
页面要支持以下几个操作流程：筛选订单、查看详情、发货、催付、售后审核、批量导出。
交互要求：所有操作必须有明确的成功/失败反馈。
状态要求：页面必须覆盖空态、加载态、错误态和数据态。
3.3 数据模型段：直接贴字段表或JSON示例
第三段是最容易被人忽略、但其实价值最大的一段：数据模型。你不需要写完整的后端接口文档，但至少要把前端会用到的关键字段和类型写清楚。我自己习惯直接贴一段带注释的JSON，如下面的订单数据示例，AI能直观看懂每个字段的类型和用途。
{ "orderId": "string，订单唯一编码", "status": "enum: pending_pay | paid | shipped | completed | refunding | refunded", "payAmount": "number，单位元，保留两位小数", "payTime": "string，ISO8601格式", "receiverCity": "string，收货城市", "items": "array，商品快照列表，含name、skuId、quantity", "opsLog": "array，操作日志，含operator、action、timestamp" }字段表的作用是让AI生成的表格列、详情卡片、筛选条件都严格落在真实接口能提供的字段上，避免它瞎编字段。很多AI生成页面接不上接口，就是提示词里没有数据模型，AI只能靠想象兜底，结果自然是一场空。
3.4 完整模板打包：可以直接抄的通用版
把三段拼起来，就是一个可复用的基础模板。我建议你把它存成自己的Snippet，每次新建后台页面时替换字段和任务就行。模板里我留了业务系统、模块名、角色描述这些占位符，你直接替换掉括号内的内容，其他骨架可以不动。
你是拥有十年B端后台产品设计与开发经验的工程师，擅长将业务任务转化为高效、可维护的管理后台页面，输出遵循企业级SaaS产品的交互规范和信息架构原则。 【业务背景】 这是一个{业务系统}的{模块名}页面，使用者是{角色描述}。 【用户核心任务】 {一句话说清主任务} 【关键操作流程】 1. {操作1} 2. {操作2} 3. {操作3} 【数据模型/接口字段】 {JSON字段说明或字段列表} 【交互与状态要求】 - 列表查询必须有加载态，加载中显示骨架屏 - 查询结果为空时显示空态提示 - 接口异常时显示错误态并提供重试按钮 - 所有提交操作需要二次确认和结果toast反馈 - 删除、退款、导出等敏感操作需要权限校验这个模板覆盖了B端页面的任务、数据、交互三个核心维度。把业务背景和用户任务换成你自己的，AI输出的质量就比“生成一个XX页面”强太多了。我每次接手新模块都从这个模板起手，省掉了大量重复调校的时间。
4. 页面状态Prompt：空态、加载态、错误态、数据态一次说清
接下来聊标题里的重头戏：页面状态。B端后台跟C端落地页最大的区别，就在于状态管理是页面的“半条命”。一个没有状态设计的后台页面，接上真实接口之后一定灾难。
4.1 为什么状态是B端后台的隐藏雷区
你看AI默认生成的页面，几乎永远只有一种状态：数据完美加载、列表一堆数据、图表饱满漂亮。这不是AI不努力，而是因为它接受的训练样本里，展现给用户的永远是“最好看的那一屏”。真实情况下，用户打开后台页面的场景大概率是：接口在转圈、数据为空、某个字段挂掉了、权限不够弹了个403提示。这些“不好看”的状态，恰恰是B端用户每天要面对的。
如果你不在提示词里显式声明状态要求，AI就默认不做。这不是玄学，是LLM的“最小努力原则”——你不提，它就觉得你不需要。就像你问朋友“帮我把家收拾一下”，他大概率只会把客厅的桌子抹一遍，不会去整理衣柜。只有你把每个柜门打开，告诉他里面该怎么叠，他才会照做。
4.2 四种核心状态的提示词写法
我习惯在提示词里用一小节专门写状态，并且明确写出每种状态下的UI表现。下面这段可以原样贴进提示词：
页面必须实现以下四种状态，并给出各状态下的UI表现：
数据态：表格正常渲染，分页控件可用，操作按钮可点击。
空态：列表没有数据时，显示“暂无数据”插画与说明文字，并提供“清除筛选条件”的快捷按钮。
加载态：请求发起后显示骨架屏或转圈，代替整页白屏。表格区域优先使用骨架屏。
错误态：接口返回异常时，页面显示错误提示、错误原因（如有）和“重试”按钮，不能只是控制台报错。
这里特别说一下空态的设计。很多AI生成的空态就是一行居中的灰色小字“暂无数据”，连个回到正常数据的出口都不给。真实业务里，空态往往是因为筛选条件设得太死，用户最需要的是一个“清空筛选条件”的按钮。你把这个细节写进提示词，AI生成的空态就直接具备了业务价值，而不是一句干巴巴的占位文字。
4.3 状态之间的联动与边界条件
更进阶的写法是描述状态之间的联动规则。状态不是孤立的，它一直在随着用户操作和接口返回而流转。我给自己的提示词里固定加了这样一段：
筛选条件变化后，列表应回到第一页并重新请求数据。
错误态内点击重试时，先回到加载态，再重新发起请求。
空态与错误态要区分对待：空态是正常查询但没有数据，错误态是接口请求失败，二者不能共用同一套UI。
表格翻页、排序、筛选等操作进行中，要防止用户重复提交。
这些联动规则写清楚了，AI生成的页面就不容易出现“筛选后数据没刷新”“报错后点重试还是白屏”这种低级bug。这类问题是真实后台开发中最高频的返工项，提示词阶段花30秒写清楚，能省下后期一晚上的联调时间。
5. 交互逻辑与状态流转的提示词：让AI生成的页面真正可操作
页面状态解决了“某一时刻页面长什么样”的问题，但B端页面是活的——用户会点按钮、填表单、走流程。交互逻辑与状态流转的提示词，才是让页面“可操作”的关键。
5.1 列表页到表单页的交互路径
B端最常见的交互是“列表 → 新建/编辑 → 提交 → 回到列表”。这个流程看似简单，但如果没有在提示词里约束，AI经常把它做残。我通常会写这样一段：
交互路径要求：
- 点击“新建”按钮后，以弹窗或抽屉形式打开表单，而不是跳转新页面，避免丢失列表的筛选状态。
- 表单提交成功后，关闭弹窗，刷新列表，并弹出“保存成功”toast。
- 表单校验失败时，在对应字段下方显示错误信息，页面不允许提交。
- 编辑操作需要回填该行的现有数据；回填失败时提示错误并保持弹窗打开。
这些细节是真实业务中天天踩的坑。AI默认做法可能只是“点击按钮弹个窗，提交后什么都不发生”，那接上真实接口基本没法用。特别是“跳转页面还是弹窗”这个选择，很多AI会默认选择跳转新页面，因为它觉得这样“页面结构更清晰”。但后台场景里，跳转会丢失列表页的筛选条件和滚动位置，用户体验非常糟糕。你把这个偏好写进提示词，就提前排掉了一个大雷。
5.2 流程类页面的状态机描述
如果你的页面涉及审批流、订单状态流转这种多步骤流程，建议在提示词里做状态机描述。状态机描述不需要画图，用箭头文本就够了。以订单为例，我会这样写：
订单状态流转：pending_pay → paid → shipped → completed；在paid和shipped状态下均可发起refunding → refunded。页面中的操作按钮要依据当前订单状态动态显隐；已处于终态completed和refunded的订单，不允许任何修改操作。
这段描述的价值在于：AI生成的代码里，按钮的禁用、隐藏、操作后的状态刷新全都基于真实状态枚举，而不是写死的“编辑、删除”按钮。做过后台开发的人都知道，按钮依据状态动态显隐是B端最常见的需求之一，也是AI最容易乱写的部分。你给它一张状态机文字图，它就能把分支逻辑处理得明明白白。
5.3 权限与角色对交互状态的影响
B端后台绕不开权限。我的经验是，不要在提示词里只写“需要有权限管理”，那样太抽象，AI会给你生成一个权限管理的页面骨架，但不会把权限落到具体交互上。要这么写：
角色分为admin和operator两类：
- admin：可查看全部订单，可删除订单，可导出数据，可审核退款。
- operator：仅可查看自己名下订单，可发起发货，不可删除，不可导出。
- 所有无权限的操作，按钮直接禁用或隐藏；即使通过接口调用，后端也会拦截，前端要处理403响应并提示“无权限执行该操作”。
这样AI就会在按钮级做权限判断，而不仅仅是在路由层面给个遮罩。你后续接真实权限系统时，只需要把角色判断替换成真实的权限判断函数，改动成本非常小。另外我还会加一句“注意：权限判断在前端只是体验优化，最终以接口返回为准”，防止AI把前端权限当成安全边界，生成一些“删掉按钮就以为安全了”的幼稚逻辑。
6. 提示词调优的实测经验：从AI输出反推问题
前面几节讲的是怎么写好第一版提示词。但实际工作中，AI第一次生成的结果通常还有偏差。这一节聊聊我实测下来的调优经验，属于那种文档里不写、踩坑才懂的东西。
6.1 输出偏视觉化：用约束词把“皮”拉回“骨”
如果AI生成出来的页面漂亮但业务逻辑弱，说明它被“美学”带跑了。这时候不要推翻重写，只需要加一段约束：
禁止使用花哨的装饰性组件和渐变色彩；所有UI组件以Ant Design或Element Plus默认样式为准；页面布局使用标准后台布局，不追求视觉创新；组件的可访问性、键盘操作、focus状态需要保留。
这段的意图是告诉AI：我要的是可用的后台，不是作品集。加了之后，生成结果的业务关注度会明显回来。我见过很多团队卡在这里——AI生成的页面截图发给业务方看，业务方说“挺好看的”，真机一用全是坑。约束词就是把“好看”这个干扰项干掉，让AI老老实实做功能。
6.2 输出偏笼统：用反例锁定边界
还有一种情况，AI生成的代码逻辑都对，但没有覆盖边界。比如筛选条件只有一个“关键词搜索”，没有按状态、按时间段的筛选。这时候用反例法：
请检查以下反例场景是否都已处理：
- 用户只想查“已退款”订单，是否能直接按状态筛选？
- 用户需要查“2024年3月1日至3月31日”的订单，时间范围筛选是否存在？
- 订单列表超过50条时，分页是否正常工作？
反例法是提示词工程里特别有效的手段。因为LLM在“正着告诉你该做什么”时容易走过场，但在“你检查这个能不能做”的质问下，会真的去审视自己的输出，补上缺失逻辑。我甚至试过把反例写成“如果用户这么操作，你的页面会崩吗”，效果比正面要求“请考虑所有边界场景”好得多。
6.3 一套可以复制的工作流：三轮生成法
最后分享一个我一直在用的三轮生成工作流，不一定适合所有人，但对B端后台这种复杂度适中的场景很稳。
第一轮：只给业务上下文和数据模型，让AI生成页面结构，包括组件布局、表格列定义、筛选条件、按钮集合。这个阶段不聊天，拿结果当草稿。
第二轮：把第一轮结果贴回去，追加状态要求和交互路径要求，让它补状态实现和交互逻辑。这一轮会暴露很多“视图层没问题、逻辑层缺失”的问题。
第三轮：把前两轮结果整合，追加权限、边界、异常处理要求，然后让人工review关键代码。这轮的产出就基本具备接到真实接口上的质量了。
这套流程的本质是“逐步收紧约束”。一次性把所有要求全塞进提示词，AI的输出质量反而不稳定；分批给，每次只加一个维度，AI的输出更容易落在预期内。你可以理解成带新人：第一天只让他熟悉代码结构，第二天才让他写具体功能，第三天再让他考虑异常和边界。步子迈太大，新人要崩，AI也一样。
我现在的习惯是，拿到一个新后台需求，先花十五分钟写任务拆解，再花十分钟把状态和交互钉死，最后五分钟才是让AI生成代码。你把这个顺序反过来，AI大概率会用更多轮的返工来惩罚你。写提示词的时候，尽量用“页面必须……”而不是“请帮我……”——“请”是商量语气，AI会倾向于给出“建议型”的温柔回应；“必须”是约束语气，AI会倾向于执行命令。这个差异在B端这种对逻辑完备性要求高的场景里非常明显，加上这一个小改动，准确率提升比想象中大。
B端后台的AI生成，本质上是“把业务任务翻译成信息架构”的过程，提示词只是翻译说明书写得够不够清楚。先把任务拆明白，再把状态和交互钉死，AI生成的页面就不会再是花架子了。
