AI 生成后台管理系统原型，决定成品质量的不是生成速度，而是这份初稿能不能继续编辑、能不能被评审。提示词写得越接近一份需求说明，生成结果越接近可以讨论的初稿；只写一句“生成一个后台”，拿到的通常只是一块通用看板。
提示词要先写清业务角色、页面、字段与权限，再将生成页逐步连成可交互原型。拿到初稿后，可对照AI 生成后必须人工复核的四项检查业务规则与页面状态。
提示词要写清六类信息
把提示词当成一份缩小版需求说明来写。下面六类信息分别对应评审时必须回答的问题，缺哪一类，评审就会在哪一类上停下来补课。
| 信息类别 | 要写什么 | 缺了会怎样 |
|---|---|---|
| 系统与使用角色 | 业务类型、角色分工、谁在什么场景下操作 | 生成通用看板，对不上真实岗位 |
| 业务对象与字段 | 对象清单、关键字段、字段来源、必填与校验 | 字段缺项，开发阶段回来追问数据口径 |
| 页面清单与入口 | 页面类型、入口位置、操作完成后回到哪里 | 页面各自成岛，链路串不起来 |
| 状态与异常 | 空、加载、失败、无权限、冲突与重复提交 | 只画出“有数据”的正常状态 |
| 权限与数据范围 | 角色可见的菜单、按钮、字段与数据行 | 评审时只能靠口头补充说明 |
| 输出与可编辑要求 | 组件化输出、命名规范、保留可继续编辑的结构 | 拿到一张截图，改一处还要重画 |
六类信息不是写作提纲，而是生成结果能否继续编辑的前提条件。
先写任务流程，再写页面清单
顺序会影响返工量。先定义核心任务从哪里开始、经过哪些角色、在哪里结束，再按这条链路列出页面。首页看板依赖指标口径，过早生成容易出现只有图表、没有业务闭环的结果。
页面清单至少要标出三件事：每个页面从哪里进入、操作完成后回到哪里、第一版先做哪些。首版范围怎么切、哪些模块可以先留入口，可以参考后台管理系统的功能范围与首版切片。
一段可以直接改写的提示词骨架
把六类信息填进下面的骨架，就是一段可以直接使用的中文提示词。方括号里的内容按自己的业务替换即可。
- 系统与角色：这是一个【行业】的后台管理系统，使用者是【角色】，他们每天要完成【核心任务】。
- 业务对象与字段：需要管理【对象】，每个对象包含【字段】，其中【字段】由系统自动带入，【字段】由人工填写。
- 页面范围：先输出页面清单，包含列表、详情、编辑、审批与结果页，并标注每个页面的入口和返回位置。
- 状态与异常：列表页与详情页都要覆盖空、加载、失败、无权限和重复提交，并说明每种状态的恢复方式。
- 权限与数据范围：【角色】能看到【菜单、按钮、字段、数据行】，无权访问时是隐藏还是置灰。
- 输出要求：按组件化方式生成，命名使用【术语表】里的说法，保留可以继续编辑的组件与图层结构。
提示词不是一次写完的。第一轮生成后，把偏差写回对应的那一段，下一轮只改这一段，页面结构才不会整体漂移。
生成结果怎么变成可编辑原型
生成出来的界面只是一份草稿。落到可编辑画布之后，还要完成四件事，它才算一份可以继续迭代的原型：
- 把生成结果导入或同步到可编辑画布，确认文字、表格和容器都是可选中、可修改的元素，而不是一张图片。
- 把重复出现的控件归并成组件，列表、表单、详情三类标准页面各留一套，改一处就能全站生效。
- 把菜单名、页面名和字段名统一成同一套术语，命名混乱会直接反映在导航、面包屑和评审讨论里。
- 补齐交互与异常路径，把列表、详情、编辑、审批串成一条能点得通的链路，并写出失败后的返回位置。
组件库里应该保留哪些标准页面、页面之间按什么顺序组织，可以先参考后台管理系统的页面类型与设计顺序，再决定哪些页面进入自己的组件库。
交付前的五项检查
进入开发评审之前，把下面五项逐条对照一遍。任何一项不通过，先回到画布补齐，不要把问题留给开发阶段。
- 核心任务能走通：从入口到结果页全程可点击，不依赖口头补充说明。
- 状态与异常齐全：空、加载、失败、无权限、重复提交都有对应页面或提示。
- 权限与数据范围写明：不同角色看到的菜单、按钮、字段和数据行都有据可查。
- 组件与命名可复用：同类页面共用组件，术语和字段名前后一致。
- 版本与改动可追溯：本轮改了什么、谁确认、哪些还待确认都写在版本说明里。
五项都通过之后再进评审，退回原因通常集中在缺状态、缺权限和不可编辑三点。
什么情况下不要把 AI 初稿当交付物
AI 生成适合把零散材料整理成可以讨论的初稿，不适合直接替代业务判断。出现下面三种情况时，先把前置条件补齐再生成：
- 缺少真实数据：字段来源、指标口径和样例数据都还没有确定，生成结果只能靠猜。
- 权限模型未定：角色、数据范围和审批链路还在讨论，先画界面会固化错误的假设。
- 涉及系统对接：需要和第三方系统、硬件设备或历史数据打通，界面之外还有大量接口约束。
原型最终要交给开发时，尺寸、切图、标注和验收标准同样需要写清楚，这部分可以先看后台原型的交付规范。
用墨刀把 AI 初稿变成可编辑原型
提示词写清之后，工具的选择就落在“生成之后还能不能改”这件事上。墨刀把 AI 生成和工作台放在同一处：按上面的骨架输入提示词，生成的后台页面会直接进入可编辑画布。
同一份工作台里既能看 AI 生成的界面，也能继续改字段、状态和命名。
- 生成结果是可编辑的组件与图层，改字段、改状态、改命名都不用重画。
- 页面、组件和评审评论在同一份文件里，评审时不用来回传截图。
- 交付时分享链接或导出，产品、设计、研发看到的是同一个版本。
想先看生成效果，可以直接打开墨刀 AI 生成原型，用一句话生成一个后台页面，再照上面的五项检查对照一遍；如果团队更习惯从空白画布搭骨架，也可以从墨刀在线原型设计里的一套后台模板开始。
常见问题
AI 生成的后台原型能直接交给开发吗？
不建议直接交付。生成初稿通常只覆盖主路径和正常状态，字段来源、权限范围、失败重试和重复提交往往缺失。补齐这四项并完成交付前检查后，才适合进入开发评审。
提示词里必须写字段和权限吗？
必须写。字段决定列表和表单能展示什么，权限决定同一页面在不同角色下呈现什么。两者都不写，生成结果只能停留在视觉层面，评审时无法验证业务规则。
生成结果是图片还是可编辑组件？
取决于提示词里的输出要求，也取决于生成后是否导入可编辑画布。要求组件化输出并落到画布后，才能继续调整字段、状态和交互；只保存截图，后续修改成本会重新回到手工绘制。
