AI辅助原型设计工具层出不穷，但真正能融入产品经理工作流的却凤毛麟角。从Figma的昂贵订阅到Pixso的体验崩溃，再到Pencil的复杂配置，本文深度评测四大主流工具的实战表现，并揭秘如何通过Claude Code实现从需求到原型的一站式AI解决方案。关键不在工具本身，而在于重构整个产品设计工作流程。

讲过了需求，下一步就是画原型，用AI画原型这个工作，我们也是经历了好几个版本。可以讲讲几个历史的版本，正好对各类工具做个对比。

方案一：Figma

Figma是我们最早使用的方案，200块钱左右一个月的professional版本。支持make和design。

实际上现在想想我们当时还是比较传统的产品经理工作思路，设计是设计，需求是需求。把设计单独拿出来作为一个个体去AI辅助。所以走了一些弯路。

优势非常明显：

• 专业，Figma Make基本可以做到所见即所得
• 支持局部修改，相当于vibe design和传统设计可以混用
• solo这种IDE原生支持Figma，可以把Figma的设计稿直接转成HTML

缺点也很突出：

• bug比较多，比如有个刷新bug，经常是改完的内容，一刷新又变回去了
• 硬伤就是贵。一个月的用量一开始一天就用完了，而且这东西还不支持按量付费，只能用月包，没办法只能换号重新干
• 当时我们还是比较理想化的，希望Figma design产出的设计稿可以让前端直接拿去用，但是前端反馈是和生产代码差距太大，没有办法直接用，基本要重写，我也不知道是真这样还是摸鱼的说辞。

方案二：Pixso

同期我们就用了号称Figma平替的Pixso，也是字节生态下的一款vibe design产品。

Pixso虽然号称平替，但是使用的门槛要明显高于Figma，典型的抄没有完全抄彻底的产品。这个我们只是体验了一下，没有合到完整的工作流程中，因为问题太多，更像是个玩具。

基本上就是花了点钱体验体验，然后就脱坑了。

原因如下：

• BUG太多
• 不支持局部修改
• 为了把设计稿导出给IDE，得用MCP，配置超级复杂，我这个资深程序员都花了很长时间才搞定。而且通过MCP生成的前端代码，和原设计稿差的太多，基本还得重做一遍

放弃。

方案三：Pencil

Pencil之前还想试试Stitch，但是科学上网怎么都上不了Stitch，直接放弃了。

所以又试用了Pencil，感觉就是个加强版的Pixso，而且巨难用。前面各种复杂的配置就不多说了，也是考虑vibe design + 传统design混用，但是体验很差。我觉得对于产品经理来说，如果是模型能力和模型辅助策略做得不好，这种层面的换工具，就是从一个坑跳到另一个坑。有研究它的时间，Axure就摆平所有了。

做了这轮体验后，我们发现实际上在AI辅助原型设计上，我们面临几个上生产阶段重要的问题。

• 因为AI工具本身是没有版本管理和迭代这个概念的，所以基本上都是一版提示词，整个工程都会重新构建，但是产品生产过程是一个迭代一个迭代推动的；
• figma、pencil虽然支持局部修改，但是这种点对点的修改，靠AI反而更麻烦，而传统产品经理的习惯恰恰就是先出一版大概，然后自己慢慢磨；
• 这种类似Vibe Design的操作，实际上对产品经理就是一次工作方式的改造，工具学习如果释放给下面的产品经理，实际上学习门槛并不低，基本上就是初级产品经理能AI辅助就是初级水平，也指望不了用好AI。

再后来，我认真地研究了Anthropic的Cat Wu关于内部产研流程改造的访谈，深感AI的改造如果局限在某个环节或者某个人身上，那其实只能在一个基础的层面去解决基础问题。

而画原型这种问题，本身它是一个工作步骤，无法独立存在。而且新技能、新方法带来的实际上是高昂的学习成本，如果没有很强的驱动力，是没有人愿意承担这个学习成本的。

所以我就尝试自己改造当前产品经理工作流程：

把AI辅助标准化，让所有产品经理参照标准来工作。

换句话说：

你别自己学AI了，你这个水平学也学不明白，我都给你做好了，你照着抄作业，作业我来检查。

这就把AI辅助这个“创造力工作”，变成了一个常规工作安排。

方案四：Claude Code

所以推广AI辅助设计，变成了产品经理工作流程标准化。之前的文章我讲了用skill改造了需求分析和排期的流程，而Vibe Design的最佳实践，实际上就是缩短需求到原型的路径，让需求能够快速的在系统上体现。

所以可以理解我们做的不是原型，而是一个通过AI快速迭代的前端系统。

最大问题： 需要产品经理懂一点代码。这个是没办法的，现在都指望产品经理包办所有了，所以学点代码一技傍身还是有必要的。

具体做法：

• Claude可以整合到Trae Solo里，Trae作为一个传统IDE使用，实际上这里选其他IDE也没什么毛病，主要是我之前让产品经理用trae体验过AI辅助coding，所以就直接拿来用了。
• 上来就可以让Claude Code读需要实现的story

为了保真：

• 我们做了自己的DESIGN.md作为设计规范，保证生成的页面能够无限接近高保真

Skill方面：

• 集成了Superpowers的插件，没有用自己的skill，因为完全没必要，Superpowers本身已经足够强大
• 读取story后，Superpowers会自己调用brainstorming来做story分析。因为我们前面的需求澄清足够详细，所以brainstorm会主要围绕设计思路来和我们进行讨论

工作流程：

• 讨论确认后，brainstorming可以形成一套基础的设计方案
• 然后Superpowers会大概率自己去找writing-plan帮你写实现计划
• 如果你想把这个设计思路形成文档，那就让它写；如果是想直接生成页面，那就跳过写方案环节

这个过程同样支持增量。其实需要coding基础的环节是一开始前端系统的搭建，这个环节有很多配置啥的，不需要你懂，但是Claude说啥得听得懂。这个环节过了之后，小白也可以干活了。由于有老系统的限制 + DESIGN.md，生成的内容出现偏差的可能性不大。即使有点小问题，让它自己修正一下就好了。

体验效果：

其实如果你的办公电脑恰好有两个显示器的话，基本上是可以达到所见即所得的效果的——左边让它自己coding着，右边可以直接看效果。

写PRD

原型通过反复的聊天，保证准确之后，自然就是写PRD。这里我们自己也做了一个skill，就直接根据原型系统的代码生成PRD，或者干脆就叫系统说明就成。

同样支持增量，全流程通过STORY串联起来。可以看看我们生成的说明文档的效果：

它可以对应的story、流程图、场景、处理逻辑、异常等全都生成出来，非常详细。而且最重要的是，这个文档它就不是给人看的，是让研发拿来直接生成系统完整代码的。

所以，产品经理的工作产出，最终也上了GIT，我们甚至可以挑战让产品经理独立完成简单的系统。因为本身工作流程都是完整的。

小结

选来选去，我们还是选了一个有一定技术门槛的方案，作为最终的落地方案。其他的好处不只在于画原型，而是在于完整的工作流程的支持。

AI辅助coding和AI辅助需求，实际上是模糊了产品经理和程序员的界限。能用好AI的人，更像是一个产品架构师，他能够独立去操控整个产品的生命周期。而产品经理和技术的核心竞争力，应该就是对于市场、商业、产品管理的Know How能力了。