从B端AI产品经理转型打造C端AI虚拟试衣工具，经历了怎样的心路历程？一款名为'智搭衣橱'的产品如何在零预算下从概念走到原型？本文深度还原了一个AI产品经理利用周末时间，独自验证虚拟试衣市场空白的全过程——从甲方的随口一句需求，到精准砍掉VTON模型的MVP策略，再到用H5链接绕过应用商店审核的实战智慧。

这篇文章不讲方法论框架，不列”AI产品经理必备的十大能力”。我想聊的是一个更具体的问题——如果你是一个在职的AI产品经理，工作日做着B端项目，周末想自己从零做一款C端产品，这条路到底长什么样？踩过的坑是什么？每一步真实的决策逻辑是什么？

我花了几个周末做了一款叫”智搭衣橱”的产品，一个AI虚拟试衣+衣橱管理的工具。从竞品调研到可运行原型到交付开发，全程一个人推进。以下是完整的过程复盘。

先说清楚起点：一个很朴素的念头

事情的起因其实和工作有关。

我日常在做服饰类外呼项目，负责和甲方对接需求。有一次对接会上，甲方随口提了一句”你说现在有没有那种能帮客户做穿搭推荐的工具，买了我们的衣服不知道怎么搭”。当时会上没人接话，话题很快过去了。

但这句话在我脑子里留了下来。因为我自己就有这个困扰——每天早上站在衣柜前，上衣几十件，裤子十来条，加上鞋帽配饰，排列组合的可能性太多了，反而做不了决策。甲方说的是他们客户的痛点，但那也是我自己的痛点。

一个来自B端客户的随口一提，加上自己作为C端用户的切身体感，两条线交汇在一起，让我开始认真想这件事。

回去之后我下了几款衣橱管理App试了试。搭搭、极简衣橱、Smart Closet，基本都是一个思路：把衣服拍照存进去，然后平铺拼在一起看搭配。

说实话，用了两天就卸了。因为”把衣服平铺在一起看”这件事，和我在衣柜前把衣服拿出来摆在床上看没有本质区别——我想看的是穿在身上的效果，而不是摊在桌上的色块拼图。

然后我又去看了虚拟试衣类的App，比如好搭盒子。它确实能看到衣服穿在虚拟人物身上的效果，但有一个致命的限制：你只能试穿平台提供的电商商品，没办法把自己衣柜里的那件牛仔裤传上去。

到这里我意识到一件事：市面上有两类产品在做这件事，一类管理你的衣橱但不能试穿，一类能试穿但只能试电商的衣服。中间有一个明显的空白——”用自己的衣服+穿在自己身上看效果”，没人做。

这就是智搭衣橱的起点。一个甲方的随口一句话，加上自己作为用户的真实痛感。

第一步：不急着画原型，先搞清楚这事能不能做

很多产品经理拿到一个想法之后，第一反应是打开Figma开始画原型。我以前也这样，但这次我克制住了。因为做B端项目的经验告诉我，验证可行性永远比画界面重要。

对于这个产品，可行性分两个维度：

市场维度——需求到底是真的还是我个人偏好？竞品为什么没做这个空白？是做不了还是不值得做？

技术维度——”把一件衣服的照片穿到一个人的照片上”，现在的AI技术到底能做到什么程度？效果行不行？成本多少？

于是我花了一个完整的周末做竞品调研和技术调研。

竞品分析的结论前面说了，两个赛道是割裂的。但更有意思的发现是用户评价里的共性抱怨——搭搭的用户说”搭配结果看不到穿身上的效果”，好搭盒子的用户说”只能试平台的衣服不能传自己的”。这两条高频差评恰好指向同一个方向。

技术调研的结论让我比较兴奋。2025年以来，虚拟试衣（VTON）的开源模型已经进化到了一个临界点——FASHN VTON v1.5只有972M参数，消费级GPU就能跑，Apache 2.0协议可以商用，而且不需要提前做衣服区域的分割标注，直接丢两张图进去就能出结果。

但我也注意到了几个限制：

第一，上衣和裤子的试穿效果已经不错，但帽子、耳饰、丝巾、手链这些配饰类的虚拟试戴技术远未成熟。

第二，VTON模型对输入图片质量很敏感。电商白底商品图效果很好，但用户自己拍的衣服——背景杂乱、光线不均、有褶皱——效果会大打折扣。

第三，模型推理需要GPU服务器，一张4090大概7秒一张图，云端月租2000起。

这三个限制直接影响了我后面的MVP策略，后面会展开讲。

我把调研结论画成了一张图：

第二步：MVP怎么切，砍掉什么比加上什么更重要

经过调研之后，我面对的核心问题是：第一版到底做什么、不做什么？

这个问题看起来简单，但大多数C端产品失败的原因恰恰在这里——要么MVP切得太大，花了三个月做出来用户不买账；要么切得太小，做出来的东西传达不了产品的核心价值。

我的思考框架是这样的：MVP不是”功能最少的版本”，而是”能验证核心假设的最小版本”。

那我的核心假设是什么？

用户愿意把自己的衣服拍照上传，并且认为在虚拟形象上看搭配效果是有价值的。

围绕这个假设，我要验证三件事：

1. 录入意愿——用户会不会嫌拍照录入太麻烦？（如果拍三件就放弃了，产品就不成立）
2. 搭配价值感——把衣服放到人物上看效果，用户觉得有用吗？（如果觉得”还不如自己穿上照镜子”，产品也不成立）
3. 回访意愿——用户第二天还会回来用吗？（如果只是新鲜感，用一次就忘了，产品没有留存价值）

然后我做了一个关键决策——第一版不接入VTON模型。

这个决策违反了很多人的直觉。你做的是”AI虚拟试衣”，结果第一版没有AI试穿？那不是砍掉了最大的卖点吗？

我的理由是这样的：

VTON模型需要GPU服务器，每月至少2000-5000元，用户量未知的情况下投这笔钱是赌博。而且我的核心假设要验证的不是”AI合成效果好不好”，而是”用户愿不愿意进入这个流程”。

替代方案是图片叠加式试穿——用户上传全身照做背景，衣服照片叠加上去，可以自由拖拽、缩放位置。效果当然不如AI合成逼真，但足以让用户感受到”我的衣服穿在我身上的搭配效果”这个核心价值主张。

如果图片叠加版的录入率和搭配完成率数据都不好，那换成AI合成也救不了——因为问题出在流程而不是效果。如果数据好，那接入VTON就是一个确定性的体验升级，值得投入。

另一个重要的砍刀落在了配饰上。

我最初设想的品类包括上衣、裤子、裙子、鞋子、帽子、耳饰、手链、项链、丝巾。但调研发现配饰的VTON效果很差，硬上只会让用户对整个产品的技术能力产生怀疑。最终的策略是：配饰可以录入到衣橱、可以在搭配画布上平铺展示，但暂时不做虚拟试戴。 等配饰VTON技术成熟了再开放。

MVP的功能边界最终长这样：

第三步：原型怎么做，迭代比完美更重要

确定了MVP范围，下一步是做原型。

这里我做了第二个反直觉的决策——不做App，不做小程序，直接做一个可以在浏览器里打开的体验链接。

原因很现实：一个人、利用周末时间、零预算。App需要3-6个月开发周期加上应用商店审核，小程序需要在微信公众平台注册。而做成一个http链接的形式，朋友只需要点一个链接就能在手机浏览器里直接体验，不用下载任何东西。

关键是，验证核心假设不需要App。用户不是因为你是App才愿意用你的产品，而是因为你的产品能解决他的问题。一个体验链接发到微信群里，朋友点开就能操作——这个获取路径比”去应用商店搜索→下载→安装→注册”短了四步，每少一步都减少了流失。

原型的迭代过程也比较有意思。我一共迭代了5个版本，每个版本只解决一个核心问题：

每个版本的改动都是从自己体验中发现的具体问题驱动的，不是提前规划好的。这一点我觉得很重要——做C端产品，你自己要先当用户，体验中觉得别扭的地方，就是需要改的地方。

第四步：评测指标不是越多越好，要分层看

产品做出来了，怎么判断它好不好？很多人的第一反应是列一堆指标——DAU、MAU、留存率、转化率、NPS……

我的经验是：指标太多等于没有指标。因为你根本不知道该看哪个。

我的做法是把指标分三层，每一层回答一个明确的问题：

第一层（方向层）：这个产品方向对不对？ 只看三个数字——衣物录入率（≥40%）、搭配完成率（≥60%）、次日留存率（≥25%）。这三个数字任何一个不达标，说明产品方向有问题，不是优化细节能解决的。

第二层（体验层）：哪个环节体验差？ 看单品录入耗时（≤60秒）、录入中途放弃率（≤30%）、搭配操作时长（2-5分钟）、页面加载时间（≤2秒）。这些数据帮你定位具体问题——比如录入放弃率高，可能是拍照步骤太麻烦，那就加AI自动识别。

第三层（商业层）：能不能赚钱？ 看心愿单添加率（≥15%）、电商跳转率（≥10%）、付费转化率（≥3%）。这一层在MVP阶段不看，等用户量跑起来再说。

为什么要分层？因为在不同阶段应该关注不同层的指标。

如果你在MVP阶段就去纠结NPS得分或者CPS转化率，那是在还没学会走路的时候研究跑鞋——不是说跑鞋不重要，而是你现在用不上。

第五步：心愿单——一个藏着商业模式的小功能

在搭配功能里我加了一个看起来不起眼的小功能——心愿单。

用户在搭配衣服的时候，如果觉得”缺一件白色衬衫搭这条裤子就完美了”，可以点”加入心愿单”，填写想要的品类、颜色、预算。

这个功能在MVP阶段不产生任何收入，但它是整个商业模式的关键验证点。

为什么？

因为未来的变现逻辑是这样的：用户搭配 → 发现缺少某件单品 → 心愿单记录需求 → 系统推荐电商匹配商品 → 用户通过链接购买 → 我们赚CPS佣金。

但这个链条成不成立，取决于一个前提——用户在搭配过程中会不会产生购买冲动？

心愿单就是用来验证这个前提的。

如果心愿单添加率超过15%，说明”搭配触发购买意图”的假设成立，后续接入CPS电商导购就有底气。如果没人用心愿单，说明这条变现路径走不通，需要换思路。

一个好的MVP应该在验证核心体验的同时，用最低成本验证商业假设。 心愿单就是那个最低成本的商业验证工具。

第六步：反馈系统不是摆设，是早期产品的命脉

做B端产品的时候，收集用户反馈有很多成熟的渠道——客户成功团队、售后工单、定期回访。但做C端产品，尤其是早期产品，用户用完就走了，你根本不知道他觉得哪里不好。

所以我在产品里内置了两个模块：

产品日志——用时间轴的形式展示每次更新了什么、处理了哪些用户反馈、下一步打算做什么。这个东西看起来像开发周报，但对早期用户来说，它传递的信号是”这个产品背后有人在认真做，我的反馈是被看见的”。

意见反馈——分了四种类型（问题报告、功能建议、表扬、其他），每种有针对性的引导文案。可以留联系方式。用户提交后能在页面上看到自己的反馈历史和处理状态。

这两个模块的核心目的不是”显得专业”，而是在没有运营团队、没有客服预算的情况下，用产品内嵌的方式建立和用户的沟通通道。

实际操作中最有价值的是反馈里的联系方式。如果一个用户愿意留微信号，说明他对产品是有期待的。后续直接私信他说”你上次提的XX建议，我在新版本里改了”——这种一对一的互动比任何增长黑客手段都有效。

第七步：交付给开发不是”把需求文档甩过去”

原型做完、指标定完、反馈系统建好之后，我把原型打包成了一个独立的HTML文件，部署到线上生成了一个体验链接。然后在微信里把链接发给身边的朋友，让他们在手机上直接体验——不用下载、不用注册，点开就能用。

这种验证方式的好处是零摩擦。朋友不需要给你任何承诺，点开链接试两分钟，好用就继续用，不好用关掉就完事。他们的行为本身就是最真实的数据。

等第一轮反馈收集完，确认方向没问题之后，下一步才是找开发做成正式的产品。

我踩过一个坑：最初以为写一份需求文档就够了。后来发现开发拿到文档第一个问题就是”界面长什么样？”——他不可能凭文字描述去猜按钮放哪里。

最终我整理的交付物是三件套：

• 需求文档（功能逻辑、交互细节、数据结构、技术选型建议）
• 可运行原型（H5网页，开发可以直接操作看交互）
• UI参考图（每个核心页面的视觉设计稿）

这三样东西缺一不可。需求文档说清楚”做什么”，原型展示”怎么交互”，UI设计稿标注”长什么样”。开发对着三件套，不需要反复确认就能动手。

写在最后：AIPM做C端产品，和B端最大的区别是什么

做了B端AI产品，再自己做C端产品，最深的感受是：B端产品的核心是解决客户明确的业务问题，C端产品的核心是创造用户没意识到的需求。

这意味着C端产品经理要多做一个B端不太需要做的事——用最小成本验证需求是否真实存在。

这也是为什么我会在原型阶段就花那么多精力在MVP策略、评测指标、心愿单埋点上。不是因为我喜欢做这些，而是因为在C端，你猜错方向的成本远高于B端。B端猜错了，最多一个项目做不好；C端猜错了，可能半年时间全部白费。

能跑通的丑原型，永远比想象中完美的PPT有价值。

作者注：智搭衣橱目前仍在MVP验证阶段，正在收集第一批用户反馈。文中提到的评测指标达标线基于行业基准和个人判断设定，仅供参考。