Codex超实用一键出PPT Skill
Product Design 的核心工作流
可以把它理解成 6 个阶段。
第一步：确认设计 Brief
这是整个流程的入口。
你可以这样说：
代码块
Plain Text
@Product Design 我想做一个 AI 播客剪辑工具，请帮我设计一个产品首页和主工作台原型。
插件不会马上开工，而是会追问：
代码块
Plain Text
是的视觉方向主要是哪种感觉？
有没有参考产品、截图或视觉风格？
交互要做到什么程度？
你可以回答得很简单：
代码块
Plain Text
产品是 AI 播客剪辑工具，面向播客创作者和内容团队。
核心功能是上传音频、自动识别高光片段、生成短视频和字幕。
视觉风格偏专业苹果风简洁工具，不要太花。
首页可以偏展示，工作台需要能点击切换状态。
这就够了。
好的 brief 不需要长篇大论，但要有几个关键信息：
•产品是什么•用户是谁•要设计哪个页面或流程•参考什么风格•需要什么样的交互
描述完了之后，它会和你进行最终确认并且按照你的要求执行。
第二步：生成视觉方向
它会先进入视觉探索阶段，生成 3 个不同方向的设计方案。
这一步很像设计师给你出初稿。
最终它输出了如下的设计稿，是不是很惊艳，而且很有苹果风的感觉，简洁大气。
这一步的价值不是"哪张图最好看"，而是帮你快速看见不同产品气质。
很多时候，我们以为自己要的是一个界面，其实真正要的是一个方向。
方向定错了，后面代码写得再漂亮也没用。
第三步：选择一个方案
Product Design 插件有一个很明确的规则：
没有选定视觉目标，就不进入实现阶段。
我按照它的要求这样继续：
代码块
Plain Text
那就选第2个方向+可点击工作台原型
这一步最好不要含糊。
不要只说"都不错，继续"。
你要告诉它：具体选哪一个，保留什么，删掉什么，往哪个方向靠等
这样的反馈更容易让插件做出稳定结果。
第四步：把视觉方案做成原型
选定方案后，插件才会进入实现阶段，以下是实施的过程
它会把视觉目标转成一个本地可运行的前端原型，包括：
•页面结构•字体、颜色、间距•图片和图标资源•导航、按钮、表单•hover、弹窗、切换、筛选等交互•桌面端和移动端适配
如果是工作台类产品，它不会只做一张静态图。
可点击的地方要能点，状态要能切，弹窗要能打开，列表和筛选也应该有基本行为。
最后你会得到一个本地地址，比如：
代码块
Plain Text
打开后就能直接体验。
这是最终构建的可以访问的页面（整体完成度还算不错）
第五步：设计 QA
这是 Product Design 插件比较特别的地方。
很多 AI 原型工具做到"能跑"就停了。
Product Design 会继续做一轮设计 QA，也就是把实现后的页面和原始视觉目标对比。
它会检查：
•页面结构有没有跑偏•字号、间距、颜色是否接近•图片资源有没有缺失•移动端是否变形•按钮、菜单、弹窗是否能用•有没有明显的视觉错位
如果问题比较严重，它会继续修。
直到 QA 结果通过，才算完成一次比较可靠的交付。
这一步对团队协作很有用。
因为原型不是只给自己看，通常还要给老板、产品、设计、开发一起评审。页面一打开就错位，很影响信任感。
第六步：分享和继续迭代
原型跑起来后，你可以继续让它改。
比如：
代码块
Plain Text
把工作台顶部的数据卡片减少到 3 个。
代码块
Plain Text
把上传音频流程改成三步：上传、识别、导出。
代码块
Plain Text
也可以让它准备分享版本：
代码块
Plain Text
请帮我把这个原型整理成可以给团队评审的版本。
如果你配置了部署工具，还可以进一步生成可分享链接。
以上就是巴巴哥给大家分享的具体流程，好不好用适不适合自己大家使用了就能判断的出来。
总结延展下完整案例：做一个 AI 播客剪辑工具原型
下面用一个完整例子串起来。
输入需求
代码块
Plain Text
补充 brief
代码块
Plain Text
目标用户是播客创作者和内容团队。
视觉风格偏现代 SaaS，但不要太企业后台。
首页用于介绍产品价值，工作台用于实际剪辑。
首页可以偏静态展示，工作台需要基本交互。
让它出 3 个方向
代码块
Plain Text
它可能会给出：
•方向 A：团队协作型 SaaS•方向 B：创作者内容工具•方向 C：AI 自动化工作台
选择方向
代码块
Plain Text
我选方向 B。保留创作者工具的轻量感，但工作台要更专业一点。
生成原型
代码块
Plain Text
请基于这个方向实现本地可运行原型。
检查和迭代
代码块
Plain Text
主工作台的信息层级还不够清楚，请突出当前音频、识别片段和导出按钮。
这就是一条完整链路：
想法 -> brief -> 视觉方向 -> 选择方案 -> 原型 -> 迭代。
其他常见用法
从截图改版
如果你已经有一个旧页面，可以直接丢截图：
代码块
Plain Text
@Product Design 这是我现在的设置页截图，请帮我重新设计得更清晰，适合 SaaS 后台使用。
适合做：
•登录页改版•设置页改版•仪表盘改版•会员页改版•表单流程优化
从 URL 做本地原型
你也可以给一个网页地址：
代码块
Plain Text
@Product Design 请参考这个 URL，做一个本地可运行的前端原型。
这里要注意授权。
这个能力适合用在你自己的页面、公司内部页面，或者你有权限复刻的产品上。不要拿它去复制别人的商业网站直接上线。
更健康的用法是：学习结构，验证风格，做内部参考。
从 Figma 到前端
如果你已经有设计稿，可以这样说：
代码块
Plain Text
适合设计师和前端协作。
设计师不需要手写代码，开发也不用从一张图里猜尺寸和交互。
做产品流程审查
Product Design 也可以做 UX 审查。
比如：
代码块
Plain Text
@Product Design 请审查这个注册流程，找出用户可能卡住的地方。
它会按步骤截图，然后指出：
•哪一步信息不清楚•哪个按钮不明显•哪些字段增加了用户负担•有没有可访问性风险•哪些问题只能通过真实用户测试确认
这比一句"帮我看看页面怎么样"要有效得多。
给已有项目加功能
如果你在本地有一个前端项目，也可以让它在现有界面上加功能：
代码块
Plain Text
@Product Design 请在当前项目的仪表盘里增加一个筛选面板，可以按时间、状态和团队成员筛选。
这种场景里，最好说清楚：
•要改哪个页面•新功能放在哪里•是否要沿用现有设计系统•需要做到什么交互程度
提示词模板
下面这些可以直接复制用。
新产品原型
代码块
Plain Text
@Product Design 我想做一个 [产品类型]，面向 [目标用户]。
核心功能是 [功能 1]、[功能 2]。
请先帮我确认设计 brief，然后生成 3 个视觉方向。
截图改版
代码块
Plain Text
URL 参考
代码块
Plain Text
@Product Design 请参考这个 URL 的页面结构和视觉风格，做一个本地可运行原型。
这个页面是我自己的项目，可以用于复刻。
产品流审查
代码块
Plain Text
已有项目加功能
代码块
Plain Text
@Product Design 请在当前项目的 [页面名称] 里增加 [功能名称]。
保持现有设计风格，交互做到可以点击演示。
使用时要注意什么？
第一，不要只给一句模糊需求。
"帮我做个好看的页面"这种输入，结果通常不稳定。
第二，尽量提供视觉参考。
截图、URL、Figma、品牌色、竞品页面都可以。AI 不是读心术，参考越明确，结果越像你想要的东西。
第三，先选方向，再写代码。
Product Design 的优势就在于它会先出视觉方向。如果你跳过这一步，很容易做出一个"能跑但不对味"的原型。
第四，不要把原型当最终产品。
它适合验证想法、评审体验、推进沟通。真正上线前，还需要接后端、处理权限、数据、安全、性能和测试。
第五，URL 克隆要注意边界。
可以复刻自己的项目，可以做学习和内部参考，不要直接复制别人的商业页面上线。
适合谁用？
我觉得 Product Design 最适合三类人。
第一类是产品经理。
你可以不懂前端，但能把想法变成一个可点击的东西。拿去开会，比写十页 PRD() 更直观。
第二类是独立开发者。
很多独立开发者卡在"产品长什么样"这一步。这个插件能帮你快速试几个方向，不必一开始就纠结视觉细节。
第三类是设计师。
它不能替代设计判断，但可以帮你快速做变体、把方案变成原型、检查实现偏差。用得好，会省掉不少重复劳动。
总结
Product Design 插件不是魔法按钮。
它更像一个有流程感的产品设计助手。
你给它一个模糊想法，它会先追问。
你给它一个清晰 brief，它会帮你出方向。
你选定一个方向，它再帮你做成可以点击的原型。
做完以后，它还会检查实现和设计是否一致。
这套流程听起来比"一句话生成页面"麻烦一点，但更接近真实产品工作。
产品设计本来就不是从灵感直接跳到成品。
中间要确认目标，要试方向，要取舍，要评审，也要改。
Product Design 插件真正有用的地方就在这里：它没有假装产品设计很简单，而是把那些原本散落在设计师、产品经理和前端之间的步骤，串成了一条可以实际推进的工作流。
巴巴设计
AI 时代的设计师指南，聊工具、聊趋势、聊设计师的未来，AI 正在重塑设计行业，记录每一个值得关注的变化！
27篇原创内容
公众号
阅读 3115
Product Design插件