我一开始只是想给一个虚拟试穿页面补几件真实衣服。原来的页面已经能把衣服图放到人的照片上，切换款式也没有报错，看起来像是“功能完成”了。可是逐张看效果，感觉始终不对：短袖还能勉强跟着身体，长袖、卫衣和带帽子的衣服一上身，就像一张贴纸被压在人体轮廓上。
这次真正要解决的，后来并不是“再找几张更好的衣服图”，而是先回答一个容易被混淆的问题：我们要的是镜头里的实时预览，还是一张真实的试穿照片，还是一段能持续跟着人动作变化的视频？这3种体验都可以叫虚拟试穿，但背后的技术路线完全不同。
先从体验目标倒推路线
最初的目标其实很具体：用户选一件衣服，打开摄像头，站在镜头前，在单次约60秒的体验里看到试穿效果，最后保存截图。这个目标里同时藏着2个要求。第1个是“马上有反馈”，第2个是“保存下来要像真的穿过”。如果只盯着其中一个要求，很容易选错方案。
我后来把目标拆成3层。第1层是实时跟随，画面必须持续更新，用户转身、抬手时衣服也要跟着动。第2层是准实时出图，用户站稳后抓取1帧，等几秒看到一张更真实的试穿照。第3层是单张高清照，不追求连续动作，只追求褶皱、遮挡、衣服上的字和光影尽量可信。
技术路线不能从“哪个模型宣传得快”开始，而要从用户究竟要等待什么、保存什么开始。
如果不先拆开这3层，后面就会出现一种很典型的错觉：拿一张生成效果很好的照片，证明它能做实时；或者看到模型标了几十帧每秒，就默认它能接摄像头、指定衣服并稳定运行。等真正接到产品里，才发现模型速度、完整应用速度和用户感知的等待时间根本不是一回事。
贴纸感不是素材问题
第1轮我从约260张候选衣服图里筛选，只留下正面、完整、背景干净的素材。这样做确实有必要，斜拍、裁掉一截或者背景复杂的图片，本来就会影响抠图和定位。但素材变干净以后，问题仍然存在，这说明症结不在衣服数量。
原来的方案先识别人身上的关键点，再把衣服图片按网格进行变形。它能把肩膀、腰部和下摆大致对齐，却不会凭空生成衣料的褶皱，也不知道手臂应该挡住衣服的哪一部分，更不会根据光照重新计算阴影。长袖被压进躯干区域后，袖子自然就消失了；衣服边缘和身体之间没有真实的遮挡关系，视觉上当然像贴上去的图。
这里最容易走的错误捷径，是继续调锚点、改网格、换几组裁剪参数，希望把“不会生成”的内容调出来。我没有继续沿着这条路耗时间，是因为问题已经越过参数能解决的边界。调点可以改善对齐，不能补上布料、人体和光线之间的生成关系。
当一个方案缺少生成褶皱、遮挡和光影的能力时，继续调定位参数，只是在优化贴纸的边缘。
这并不代表贴图方案没有用。它的价值是快，而且可以作为摄像头画面的即时反馈。真正的问题是，不能把它的即时反馈包装成真实试穿，更不能把它的上限写进最终验收标准。
宣传里的实时，究竟实时了什么
为了判断开源项目是否值得投入，我没有只看论文中的帧率，而是逐项核对它能不能指定衣服、有没有完整摄像头程序、许可是否允许使用、项目是否还在维护，以及真实输入会不会失效。
核对之后，很多“实时换装”被拆出了不同含义。有的项目只报告模型本身的推理速度，仓库里没有摄像头应用；有的本质上是增强现实叠加，衣服会跟着人体动，但长袖仍然保留原来的形状；还有的实时模型确实能连续生成，却只能根据文字描述衣服，不能让用户从衣橱里指定某一件。论文里有数字，不等于产品里有完整闭环。
这次核验还暴露出另一个风险：项目看起来开源，不代表可以直接商用。有些虚拟试穿模型能下载、能运行，但许可只允许非商业研究；有的项目只有论文，代码和权重并没有公开。若不处理这个问题，后面即使把效果接进应用，也可能在发布前被许可卡住，前面的开发时间无法直接复用。
所以我把核验表收缩成4个必须回答的问题：输入是不是用户指定的衣服图，速度是单模型还是端到端体验，许可和权重是否真实可用，最后是在目标硬件上测出来还是只按宣传数字推算。任何1项答不上来，我都不会把它写成“已经可用”。
一张真实试穿照，能跑到什么程度
在现有显卡上，我实际跑了一套可以商用的开源单张生成模型。模型加载后，30步生成约27秒，15步约14秒；把步数降到8步后，单张约7.5秒，而且和15步的效果接近。这个数字不是论文里的理想值，而是同一台现有设备、同一批衣服跑出来的结果。
效果上的差异也很直观。卫衣的长袖能盖住手臂，帽子、手插口袋的姿势可以保留，衣服上的字和标识没有像贴图那样被拉平，同时能看到褶皱和光影。这说明生成式单张模型确实能解决“像不像穿上”的核心问题。
但我不会把7.5秒说成实时。它更准确的名字是“准实时单张试穿”：人站到镜头前，系统判断姿态稳定后抓一帧，等待约7.5秒，再把真实试穿照显示出来。等待期间可以保留贴图预览，让用户知道系统没有卡住；照片出来以后，用户再决定保存或换下一件衣服。
这个判断很重要。如果不把“拍照出图”和“视频跟随”分开，产品验收就会变成一句含糊的“要快一点”。最后可能一边承诺实时，一边交付每张要等几秒的照片，用户感受到的不是技术取舍，而是系统没有兑现承诺。
真正实时，瓶颈不只是显卡
视频实时生成的约束可以用时间预算看得更清楚。每秒20到30帧，意味着每帧只有约0.03到0.05秒。单张生成实测约7.5秒，和这个目标相差超过100倍。换更强的显卡当然能缩短时间，但它不会自动把单张模型变成专门为连续视频训练的模型。
我看到过把更高端显卡直接等同于实时能力的说法，这里需要谨慎。更快的设备可以让单张照片更快，也可能让某些低质量视频方案提高帧率；但真正的视频试穿还要处理帧间一致性、动作变化、衣服遮挡和长时间运行稳定性。若模型本身没有这些能力，增加显存只是让同一个限制运行得更快一点。
因此，现阶段我会把设备和目标这样对应：现有显卡适合约7.5秒出一张真实试穿照；更强的消费级显卡可以尝试把等待压到几秒，但需要实测，不能把算力比例当成承诺；真正的连续视频还需要专门的实时生成模型和更高的算力，而不是只换一张卡。
真实试穿和实时试穿是2条不同的验收线，前者已经可以在本地落地，后者目前缺的首先是可用模型，其次才是显卡。
我选择的折中，不是假装已经实现
基于这次实测，我选择“实时预览加延迟真实照片”的组合。摄像头画面继续用现有的快速叠加方案，负责让用户选衣服、调整站姿时始终有反馈；姿态稳定后自动抓取原始摄像头画面，交给生成模型处理；约7.5秒后显示真实试穿照。这里必须使用原始画面，而不是把已经叠过衣服的截图再次送入生成模型，否则前一层的错误会被带进去。
如果用户要试多件衣服，可以在第1张生成期间先看预览，生成完成后再把其余款式放到后台依次处理。这样做不会把系统说成连续实时，但能让体验从“每次都重新等待”变成“第1件需要等待，后面逐渐可切换”。保存当前摄像头画面和生成高清试穿照也应该是2个不同动作，避免用户误以为当前预览就是最终结果。
这套组合的价值不在于掩盖限制，而在于把限制变成界面上能理解的等待。真正难的不是把演示跑通，而是让用户知道哪一张是即时反馈，哪一张是生成结果。一个诚实的产品边界，往往比一个听起来更快但无法复现的数字更有用。
下次我会怎么做
下次再遇到“想做实时”的视觉项目，我会先让需求写出3个数字：允许用户等待多久、画面需要连续到什么程度、最终结果要不要保存。如果目标是选衣服后立刻跟着动作走，就把实时跟随列为单独路线；如果目标是得到一张可信照片，就先做单张生成实测，不拿视频宣传数字替代它。
然后我会按输入、许可、端到端延迟、效果和失败场景逐项核验。输入要确认能不能指定真实衣服图；许可要确认能不能进入产品；延迟要在目标硬件上测；效果要看长袖、褶皱、遮挡、衣服文字和不同姿态；失败场景则要提前规定网络不稳、姿态不完整或生成失败时显示什么。只看一张漂亮样片，永远不够。
最后，我会把“已实测”“可推算”和“尚未实现”分开写进验收标准。像7.5秒这样的数字，可以作为当前单张体验的事实；2到3秒如果没有真实测试，只能标成推算；真正实时的视频，如果缺少可用开源模型，就明确写成未实现，而不是用更大的显卡把问题藏起来。
这件事让我重新意识到，技术路线的成熟，不是找到一个最响亮的模型名称，而是知道它在什么体验里成立、在什么体验里不成立。把实时、准实时和真实效果分开，用户得到的也许不是一次完美的试穿，但至少每一次等待都有解释，每一个承诺都有证据。