从一个穿搭痛点到一款AI产品：AI PM的C端从0到1实录
AI产品经理利用周末时间，从B端甲方的一个随口需求出发，独自完成竞品调研→MVP定义→原型迭代→指标体系→商业验证的全流程，做了一款AI虚拟试衣+衣橱管理工具”智搭衣橱”
基本信息
- 来源：人人都是产品经理（woshipm.com）
- 作者：洋洋（两年 AI 产品搬砖人）
- 发布日期：2026-04-28
- 标签：AI产品、C端产品、MVP策略、个人项目、产品验证、虚拟试衣
核心观点
-
市场空白来自两类产品的割裂：市面上的衣橱管理App（搭搭、极简衣橱、Smart Closet）只能平铺看搭配色块，虚拟试衣App（好搭盒子）只能试电商商品——“用自己的衣服+穿在自己身上看效果”这个空白没人做。两类产品的用户差评恰好指向同一个方向。调研方法上，用户评价中的共性抱怨比功能对比表更有洞察力。
-
MVP不是”功能最少的版本”，而是”能验证核心假设的最小版本”：核心假设是”用户愿意把衣服拍照上传，且认为在虚拟形象上看搭配效果有价值”，围绕此验证三件事——录入意愿、搭配价值感、回访意愿。基于此，第一版不接入VTON模型（月成本2000-5000元的GPU服务器是赌博），改用图片叠加式试穿验证流程而非效果，数据好再接入VTON做确定性体验升级。
-
砍掉什么比加上什么更重要：配饰VTON效果差，硬上只会让用户怀疑产品技术能力。策略是配饰可录入+平铺展示但不做虚拟试戴，等配饰VTON技术成熟再开放。MVP的功能边界要严格围绕核心假设切割。
-
评测指标分三层，不同阶段看不同层：方向层（录入率≥40%、搭配完成率≥60%、次日留存≥25%）判断产品方向对不对；体验层（单品录入≤60秒、放弃率≤30%、搭配操作2-5分钟、加载≤2秒）定位具体体验问题；商业层（心愿单≥15%、电商跳转≥10%、付费≥3%）在MVP阶段不看。指标太多等于没有指标。
-
心愿单是最低成本的商业验证工具：搭配→发现缺单品→心愿单记录需求→推荐电商→CPS佣金的变现逻辑，前提是”搭配过程中会不会产生购买冲动”。心愿单添加率超15%说明假设成立，<15%说明这条路走不通。好的MVP应同时验证核心体验和商业假设。
-
零预算C端产品的分发策略：H5链接而非App/小程序：一个人利用周末零预算，App需3-6个月+审核，小程序需注册。做成http链接朋友点开就能用，获取路径比”搜索→下载→安装→注册”短四步，每少一步减少流失。验证核心假设不需要App，用户要的是解决问题不是你的形式。
-
反馈系统是早期C端产品的命脉：内置产品日志（时间轴展示更新和反馈处理，传递”有人在认真做”信号）和结构化意见反馈（四种类型+可留联系方式）。用户留微信号说明对产品有期待，一对一通知”你的建议我在新版本改了”比任何增长黑客手段都有效。
-
B端PM做C端最大的区别是验证成本的差异：B端核心是解决客户明确的业务问题，C端核心是创造用户没意识到的需求——C端PM必须额外做”用最小成本验证需求是否真实存在”。B端猜错最多一个项目做不好，C端猜错可能半年全部白费。
-
开发交付三件套缺一不可：需求文档（功能逻辑+交互细节+数据结构+技术选型）、可运行原型（H5网页开发可直接操作）、UI参考图（每个核心页面视觉稿）——开发对着三件套不需要反复确认就能动手。只给文档是踩过的坑。
-
原型迭代5版本，每个版本只解决一个核心问题：改动都从自己体验中发现的具体问题驱动，不是提前规划——做C端产品自己要先当用户，体验中觉得别扭的地方就是需要改的地方。
实操内容保留
操作步骤
竞品调研+技术调研一周末完成：
- 下载搭搭、极简衣橱、Smart Closet试用，记录核心体验差异
- 下载好搭盒子，记录”只能试电商衣服”的限制
- 提取用户评价中的共性抱怨（这是最有洞察力的信号）
- 技术调研：FASHN VTON v1.5（972M参数，Apache 2.0，消费级GPU可跑，无需分割标注）
- 记录三个技术限制：配饰VTON未成熟、用户拍摄图片质量差效果打折、GPU推理成本月2000+
MVP核心假设验证设计：
- 验证1：录入意愿——拍三件就放弃则产品不成立
- 验证2：搭配价值感——觉得”不如照镜子”则产品不成立
- 验证3：回访意愿——只用一次则无留存价值
评测指标三层架构：
- 方向层：衣物录入率≥40%、搭配完成率≥60%、次日留存≥25%
- 体验层：单品录入耗时≤60秒、放弃率≤30%、搭配操作2-5分钟、加载≤2秒
- 商业层：心愿单添加率≥15%、电商跳转≥10%、付费转化≥3%
心愿单商业验证逻辑： 搭配→发现缺单品→心愿单记录需求→系统推荐电商→用户购买→CPS佣金
开发交付三件套：
- 需求文档（功能逻辑、交互细节、数据结构、技术选型建议）
- 可运行原型（H5网页，开发可直接操作看交互）
- UI参考图（每个核心页面的视觉设计稿）
（本文无实操代码/Prompt模板，但有完整的分步决策方法论）
关键概念
- VTON 虚拟试衣 — 核心技术支撑，本文给出详细的技术限制分析
- MVP — 产品验证方法论，本文给出反直觉的”第一版不接AI”策略
- 独立开发者 — 本文作者以独立方式（周末+零预算）推进C端产品
- GTM — 心愿单作为商业验证工具，体现了GTM从产品设计阶段内嵌的思路
与其他素材的关联
- 2026-05-09-pm-ai-playbook：本文是PM AI playbook中”人机协作边界”理念的真实实践——作者用AI做技术调研和信息整合，但MVP切割、指标分层、商业验证等判断全部自己做
- 2026-05-09-product-to-startup-blues：Blues说”判断力是AI时代护城河”，本文作者在每个决策点（砍VTON、砍配饰、做H5不做App、心愿单验证）都体现了独立判断力；Blues说GTM要内嵌产品，心愿单就是GTM内嵌产品的实例
- 2026-04-29-ai-game-development-3h-28w：Pieter Levels 3小时做游戏vs本文作者几个周末做试衣工具——都是独立开发者快速验证，但本文更完整展示了验证方法论而非仅展示速度
原文精彩摘录
很多产品经理拿到一个想法之后，第一反应是打开Figma开始画原型。我以前也这样，但这次我克制住了。因为做B端项目的经验告诉我，验证可行性永远比画界面重要。
MVP不是”功能最少的版本”，而是”能验证核心假设的最小版本”。……VTON模型需要GPU服务器，每月至少2000-5000元，用户量未知的情况下投这笔钱是赌博。而且我的核心假设要验证的不是”AI合成效果好不好”，而是”用户愿不愿意进入这个流程”。如果图片叠加版的录入率和搭配完成率数据都不好，那换成AI合成也救不了——因为问题出在流程而不是效果。
做了B端AI产品，再自己做C端产品，最深的感受是：B端产品的核心是解决客户明确的业务问题，C端产品的核心是创造用户没意识到的需求。……在C端，你猜错方向的成本远高于B端。B端猜错了，最多一个项目做不好；C端猜错了，可能半年时间全部白费。能跑通的丑原型，永远比想象中完美的PPT有价值。