文章目录一、背景二、PRD三、原型一、背景事情是这样的。前两天有个想法一直绕在脑子里做一个能帮开发者自动分析日志的 Agent。就是把报错日志往里一丢它不光告诉你哪里错了还能顺带分析出根因、给出修复建议甚至能跨时间段关联历史故障。想法转完这一圈兴奋了大概三十秒。。。然后就想到了接下来要面对的事情。二、PRD做技术出身的人产品感多少有一点但要凭空把一个完整的交互流程描述出来还要让设计师能看懂、能执行这个转换成本真的很高。按以前的流程光这一步就要折腾一两周。那时候真的愣在那里想有没有更快的方式。然后就想起来了Codex 那边不是有两个插件吗一个叫superpowers一个叫Product Design一个负责想清楚一个负责搭交互。要不试试用它们来跑一遍全流程在 Codex 里直接 了 superpowers。superpowers 作为资深架构师和经验丰富的产品经理请通过向我提问的方式帮助我澄清需求、挖掘边缘场景最终共创一份高质量的PRD。 当前任务是设计并实现一个完善的日志分析Agent应用。。 请逐一提出具体且有引导性的问题帮助我逐步完善需求。它真的就开始问问题了。而且问的方式跟大多数人想的完全不一样。不是第一次写 PRD 的人以前都是自己列功能清单觉得把「用户能上传日志」「Agent 能自动分析」这种话写上去就算完事了。但 superpowers 是这样问的。这个 Agent用户第一次用的时候他对「日志分析」的核心目标是什么他会不会以为上传完就能直接出结果如果他等了三分钟还没响应他会去做什么这些问题一出来突然就愣住了。之前想的那个「功能清单」根本不是需求。那只是想要的功能不是用户真正会用到的东西。然后它就一个问题一个问题地问一个一个回答答着答着PRD 自己就长出来了。它不是让先写 PRD 再审核而是让 PRD 在问答的过程中自然形成。答完一轮它就更新一轮文档能实时看到 PRD 在变厚、在变具体。这个感觉很奇妙就像有一个资深的产品合伙人坐在对面他不替你做决定但他问的每一个问题都逼你把模糊的东西想清楚。最后出来的 PRD扫了一眼核心功能、边缘场景、交互逻辑、甚至数据流向都写进去了。如果自己写可能要花两天还不一定想得到那些边缘场景。PRD 有了下一步是原型。三、原型这一步以前是最痛苦的。你要跟设计师说「这个地方要有一个上传按钮」设计师说「好的」然后过两天给你一版你说「不对我的意思是拖拽上传」设计师说「你当时没说啊」然后推翻重来。这种拉锯经历过太多次了。在 Codex 里 了 Product Design直接把刚才的 PRD 丢给它。Product Design 设计并完善日志分析Agent应用的交互式原型。作为资深产品经理与UI/UE设计师基于需求文档创建高质量HTML交互式原型在关键功能节点上标注需求说明确保交互逻辑清晰、视觉层次合理最终输出可直接演示的完整原型文件。然后它问要几种视觉方向。说先给三种吧选一个。它就真的给了三种。偏科技感的深色系、偏简洁的浅色系、还有一个偏数据可视化的信息密度高的方向。当时选了第二个。因为这个工具的目标用户是开发者太花哨反而干扰。选完之后它就开始生成了。以前对「AI 生成原型」这件事是存疑的。总觉得它出来的东西要么长得很模板要么交互是死的点不了、转不动只能看个静态图那跟画在纸上有什么区别。但这次出来的结果说真的有点被震到了。怎么说呢。。。它不只是画了几个页面它是把交互逻辑也做进去了。能点击按钮能切换页面能在关键节点上看到需求说明的标注。就像真的可以拿去给老板演示、拿去跟开发对接的程度。当时就愣住了说实话也没想到能到这个程度。整个流程跑完算了一下时间。从在 Codex 里打出第一句「帮我澄清需求」到最后拿到可以演示的完整原型花了大概不到一个小时。这里面还包括跟 superpowers 来回问答的时间、选视觉方向的时间、以及最后盯着原型看来看去觉得「这个地方好像还能再调一下」的时间。如果用传统方式做这件事这一天就别想干别的了。值得写下来不是因为快。快当然重要但更重要的是它改变了「想法到原型」这件事的门槛。以前要做一个产品原型要么自己学 Figma要么找设计师合作要么就用一些很模板化的原型工具出来的东西要么不够专业要么不够灵活。但通过 superpowers 先把需求想清楚再用 Product Design 将其转化为可交互的原型这个组合实际上将一件需要多角色协作的事情压缩到了一个人、一台电脑、一个下午就能完成的规模。这个变化是真实的。不是说设计师要失业了而是说当有一个想法的时候不再需要等任何人自己就能把它变成一个「别人能看到、能理解、能给你反馈」的东西。这个「能给别人看」很重要。因为想法在脑子里的时候它永远是完美的。只有把它变成原型、拿给别人看的时候才会发现「哦原来这里逻辑是断的」「哦原来用户根本不会这样操作」。原型的核心价值不是「好看」是「能测试」。回头看superpowers 在整个流程里扮演的角色其实比「帮我写 PRD」要深得多。它做的是需求澄清。这件事听起来简单实际上非常难。难在哪里呢难在大多数人在描述一个产品想法的时候说的都是解决方案不是需求。会说「我要做一个日志上传功能」但 superpowers 会问「用户为什么需要上传日志他在什么场景下会产生这个需求如果他的日志文件有 10 个 G他还会用上传的方式吗」被问到第三个问题的时候才会意识到原来「上传日志」这个解决方案只适用于特定场景。如果用户是运维工程师他面对的日志可能是分布式的、实时的、几十个 G 的那「上传」这个方案本身就是有问题的。superpowers 的价值就在于它用提问的方式逼你把解决方案背后的真实需求给挖出来。挖出来之后PRD 就不是「功能清单」了而是「用户在什么场景下遇到什么问题、我们提供什么价值去解决它」的完整叙事。Product Design 这边也有一个细节让人印象很深。它生成原型的时候会在关键功能节点上标注需求说明。这个细节很重要因为原型不是只给自己看的。要拿给开发看、拿给老板看、拿给投资人看如果只看页面他们不知道这个按钮为什么要放在这里、这个交互逻辑背后的需求是什么。有了标注原型就变成了一个「可沟通」的东西。另外就是它默认给三种视觉方向这个设计很人性化。因为大多数人在做原型的时候其实不知道自己想要什么风格直到看到具体的选项才知道「哦我要这个」。给选项而不是让从空白开始描述这个设计思路本身就很产品化。现在回头看这件事觉得最有意思的不是「AI 能帮我做原型」这件事本身。而是「人和 AI 的协作方式」在悄悄发生变化。以前用 AI 工具都是描述清楚需求它帮执行。但 superpowers Product Design 这套流程里AI 不是在执行指令它是在跟人一起把一件本来很模糊的事情一步一步变清楚、变具体、变可执行。superpowers 帮「想清楚」Product Design 帮「做出来」。这两个动作连在一起就是一个产品从 0 到 1 最核心的东西。。。 这套协作方式值得让更多人知道。
使用Codex 的 Superpowers + Product Design 快速生成交互式原型
发布时间：2026/6/17 2:25:22
文章目录一、背景二、PRD三、原型一、背景事情是这样的。前两天有个想法一直绕在脑子里做一个能帮开发者自动分析日志的 Agent。就是把报错日志往里一丢它不光告诉你哪里错了还能顺带分析出根因、给出修复建议甚至能跨时间段关联历史故障。想法转完这一圈兴奋了大概三十秒。。。然后就想到了接下来要面对的事情。二、PRD做技术出身的人产品感多少有一点但要凭空把一个完整的交互流程描述出来还要让设计师能看懂、能执行这个转换成本真的很高。按以前的流程光这一步就要折腾一两周。那时候真的愣在那里想有没有更快的方式。然后就想起来了Codex 那边不是有两个插件吗一个叫superpowers一个叫Product Design一个负责想清楚一个负责搭交互。要不试试用它们来跑一遍全流程在 Codex 里直接 了 superpowers。superpowers 作为资深架构师和经验丰富的产品经理请通过向我提问的方式帮助我澄清需求、挖掘边缘场景最终共创一份高质量的PRD。 当前任务是设计并实现一个完善的日志分析Agent应用。。 请逐一提出具体且有引导性的问题帮助我逐步完善需求。它真的就开始问问题了。而且问的方式跟大多数人想的完全不一样。不是第一次写 PRD 的人以前都是自己列功能清单觉得把「用户能上传日志」「Agent 能自动分析」这种话写上去就算完事了。但 superpowers 是这样问的。这个 Agent用户第一次用的时候他对「日志分析」的核心目标是什么他会不会以为上传完就能直接出结果如果他等了三分钟还没响应他会去做什么这些问题一出来突然就愣住了。之前想的那个「功能清单」根本不是需求。那只是想要的功能不是用户真正会用到的东西。然后它就一个问题一个问题地问一个一个回答答着答着PRD 自己就长出来了。它不是让先写 PRD 再审核而是让 PRD 在问答的过程中自然形成。答完一轮它就更新一轮文档能实时看到 PRD 在变厚、在变具体。这个感觉很奇妙就像有一个资深的产品合伙人坐在对面他不替你做决定但他问的每一个问题都逼你把模糊的东西想清楚。最后出来的 PRD扫了一眼核心功能、边缘场景、交互逻辑、甚至数据流向都写进去了。如果自己写可能要花两天还不一定想得到那些边缘场景。PRD 有了下一步是原型。三、原型这一步以前是最痛苦的。你要跟设计师说「这个地方要有一个上传按钮」设计师说「好的」然后过两天给你一版你说「不对我的意思是拖拽上传」设计师说「你当时没说啊」然后推翻重来。这种拉锯经历过太多次了。在 Codex 里 了 Product Design直接把刚才的 PRD 丢给它。Product Design 设计并完善日志分析Agent应用的交互式原型。作为资深产品经理与UI/UE设计师基于需求文档创建高质量HTML交互式原型在关键功能节点上标注需求说明确保交互逻辑清晰、视觉层次合理最终输出可直接演示的完整原型文件。然后它问要几种视觉方向。说先给三种吧选一个。它就真的给了三种。偏科技感的深色系、偏简洁的浅色系、还有一个偏数据可视化的信息密度高的方向。当时选了第二个。因为这个工具的目标用户是开发者太花哨反而干扰。选完之后它就开始生成了。以前对「AI 生成原型」这件事是存疑的。总觉得它出来的东西要么长得很模板要么交互是死的点不了、转不动只能看个静态图那跟画在纸上有什么区别。但这次出来的结果说真的有点被震到了。怎么说呢。。。它不只是画了几个页面它是把交互逻辑也做进去了。能点击按钮能切换页面能在关键节点上看到需求说明的标注。就像真的可以拿去给老板演示、拿去跟开发对接的程度。当时就愣住了说实话也没想到能到这个程度。整个流程跑完算了一下时间。从在 Codex 里打出第一句「帮我澄清需求」到最后拿到可以演示的完整原型花了大概不到一个小时。这里面还包括跟 superpowers 来回问答的时间、选视觉方向的时间、以及最后盯着原型看来看去觉得「这个地方好像还能再调一下」的时间。如果用传统方式做这件事这一天就别想干别的了。值得写下来不是因为快。快当然重要但更重要的是它改变了「想法到原型」这件事的门槛。以前要做一个产品原型要么自己学 Figma要么找设计师合作要么就用一些很模板化的原型工具出来的东西要么不够专业要么不够灵活。但通过 superpowers 先把需求想清楚再用 Product Design 将其转化为可交互的原型这个组合实际上将一件需要多角色协作的事情压缩到了一个人、一台电脑、一个下午就能完成的规模。这个变化是真实的。不是说设计师要失业了而是说当有一个想法的时候不再需要等任何人自己就能把它变成一个「别人能看到、能理解、能给你反馈」的东西。这个「能给别人看」很重要。因为想法在脑子里的时候它永远是完美的。只有把它变成原型、拿给别人看的时候才会发现「哦原来这里逻辑是断的」「哦原来用户根本不会这样操作」。原型的核心价值不是「好看」是「能测试」。回头看superpowers 在整个流程里扮演的角色其实比「帮我写 PRD」要深得多。它做的是需求澄清。这件事听起来简单实际上非常难。难在哪里呢难在大多数人在描述一个产品想法的时候说的都是解决方案不是需求。会说「我要做一个日志上传功能」但 superpowers 会问「用户为什么需要上传日志他在什么场景下会产生这个需求如果他的日志文件有 10 个 G他还会用上传的方式吗」被问到第三个问题的时候才会意识到原来「上传日志」这个解决方案只适用于特定场景。如果用户是运维工程师他面对的日志可能是分布式的、实时的、几十个 G 的那「上传」这个方案本身就是有问题的。superpowers 的价值就在于它用提问的方式逼你把解决方案背后的真实需求给挖出来。挖出来之后PRD 就不是「功能清单」了而是「用户在什么场景下遇到什么问题、我们提供什么价值去解决它」的完整叙事。Product Design 这边也有一个细节让人印象很深。它生成原型的时候会在关键功能节点上标注需求说明。这个细节很重要因为原型不是只给自己看的。要拿给开发看、拿给老板看、拿给投资人看如果只看页面他们不知道这个按钮为什么要放在这里、这个交互逻辑背后的需求是什么。有了标注原型就变成了一个「可沟通」的东西。另外就是它默认给三种视觉方向这个设计很人性化。因为大多数人在做原型的时候其实不知道自己想要什么风格直到看到具体的选项才知道「哦我要这个」。给选项而不是让从空白开始描述这个设计思路本身就很产品化。现在回头看这件事觉得最有意思的不是「AI 能帮我做原型」这件事本身。而是「人和 AI 的协作方式」在悄悄发生变化。以前用 AI 工具都是描述清楚需求它帮执行。但 superpowers Product Design 这套流程里AI 不是在执行指令它是在跟人一起把一件本来很模糊的事情一步一步变清楚、变具体、变可执行。superpowers 帮「想清楚」Product Design 帮「做出来」。这两个动作连在一起就是一个产品从 0 到 1 最核心的东西。。。 这套协作方式值得让更多人知道。
