两个职位一个聚焦逻辑一个习惯看界面，经常会出现一种很微妙的情况：产品经理写了一大段需求说明，但设计师看完只问一句“那这个按钮是放在这里，还是放在底部？”而设计师画完一版界面，产品经理又会冒出来补一句：“这个状态变化是不是没考虑 loading？”
这种无休止的开会、改稿、互相折磨，太常见了
。界面、规则、文档，其实根本就是同一件事的不同表现形式。把它们强行割裂开，最后堵住的，还是咱们自己交付给开发那条路。
最近我自己在项目里跑通了一套流程，还挺顺的，顺便整理出来。教你怎么用AI把
“画界面”、“写说明”和“产出PRD”
这三件事串起来。
很多产品经理写PRD时，其实需要结合界面结构。比如一个简单的问题：首页是信息流还是卡片布局？操作按钮放在底部还是右上角？这些问题如果只在脑子里想，很容易越想越乱。
不管是PM想给设计师画个示意图，还是UI在前期找排版灵感，都可以
先让AI生成一个界面草稿
。比如在原型工具的AI里输入一段简单描述（这里以墨刀AI为示例，其他同类AI也可以实现）：
风格为现代简约、多边形元素、活力橙色点缀、卡片式层次、引导性强
功能页面包括：首页、课程搜索、学习进度、AI 互动页课程详情、题库/测评、错题本、直播间、排行榜、
个人中心、订单/商城、支付页、消息中心、家庭中心、设置页，页面顺序按照用户习惯的使用顺序设置。
AI通常十几秒钟就会给出结构化页面，这里经过几次调整后，AI生成了整套AI学习APP原型图。有了可视化的页面，PM和设计师对齐需求的时候，很多讨论会变得更具体。
AI在生成界面的时候，有个细节其实挺容易被忽略。AI在生成界面的同时，还会附带生成一段关于这个页面的“设计说明”。
很多团队的问题是缺少规则。例如一个按钮，可能有默认状态、点击状态、loading状态等等，如果这些没有明确写出来，开发实现时会自由发挥。于是上线之后就会出现各种细节差异，这时候如果再回头补说明，其实已经晚了。
而AI在生成界面的阶段，就已经把这些信息沉淀出来了，是后边写需求文档最宝贵的底料啊！
这种说明看起来简单，但其实非常关键。咱们只要稍微理一理，把它固化在界面的旁边，后边再输出给开发的时候，就不用凭空去捏造规则了。
有了界面和设计规则，其实需求文档的主体已经有了。传统的做法是打开Word疯狂码字，结果开发根本不爱看。真正能提效的，其实是让PRD视觉化一些。
你现在身处的是产品设计工具里，AI是知道你的业务上下文的。你可以甩给它一个稍微严谨点的提示词，读取刚才生成的UI页面和说明，让AI基于这些内容，生成完整的PRD需求文档。注意要重点补充可能出现的异常状态及提示语。需要有图文对照感，排版清晰，方便前端开发直接阅读。
前面的原型图其实已经提供了很多上下文，这时候AI写出来的PRD文档，就不再是那种假大空的通用框架了。它生成的PRD会带有很多可视化的元素，比如把用户分层模型用饼图画出来，把功能架构以地图形式贴在画板里，图文并茂、高度挂钩。
但是AI写出来的PRD，大多数时候还只是个初稿。最后肯定还是得人工过一遍，把细节补齐。
以前产品经理和设计师的分工其实挺清晰，产品经理负责逻辑，设计师负责界面。但现在AI工具让这两件事的界限正在慢慢变得打破。产品经理可以快速生成原型界面，设计师也可以直接看到需求逻辑。界面、说明和需求文档，其实是同一件事的不同表达。
这些能力被整合到同一个工作流里，就会让产品设计这件事，变得更顺一些。
