What Building WeShop Taught Me About Generative-AI Products 谈谈做 WeShop 过程中对 AIGC 产品的一些思考

When we opened the WeShop beta on May 10, both growth and user feedback exceeded what our small team expected. It felt a little like the early mobile-internet years: if the product solved a real problem, users and media would carry part of the distribution for you.

The formal release also made one thing clear: WeShop would be a paid product built around AI compute. That sounds simple, but for an AIGC product it changes almost every product decision, from onboarding to infrastructure.

A lot of AI discussion at the time was philosophical. We were more interested in the practical question: what breaks when you try to turn image-generation technology into a real commercial workflow?

The first problem is product definition before the technology is fully ready

Every AI application faces the same tension. If the technology is already mature, the opportunity may be gone. If the technology is not mature, the product can easily be worse than the old workflow. That is why product judgment becomes even more important in the AI era.

For WeShop, the obvious research direction had always been virtual try-on: give the system a product photo and have it place the product naturally on many different models. Mogujie had explored this since it first had a computer-vision team. My view then was that the technology still did not meet the minimum bar for a B2B workflow, though it could work earlier in some consumer-facing experiments.

A better route is often to combine technical taste with business sense: choose a promising technical direction, then apply it to a business problem you have understood for years.

Once the technical route and interaction are good enough, users become more imaginative than the team. One customer gave us a very concrete lesson.

In the mannequin workflow, merchants often uploaded hollow mannequin photos without heads or limbs. These images are common in the industry, but they are difficult for a model-generation system.

If used directly, the result usually failed in obvious ways.

We spent a lot of time trying to make these inputs produce natural model photos. Then one customer found a workaround: add a few rough strokes before running the generation.

With that hint, the output improved dramatically.

Other customers quickly extended the trick. A product weakness became partly solvable through a workflow pattern we had not designed ourselves.

Compute cost becomes a product constraint

WeShop was the first product in my career where compute cost became a serious concern at such an early user scale. GPUs were expensive, hard to procure, and often needed urgently because growth was difficult to forecast.

1. Different customer requests needed different combinations of base models, LoRAs, ControlNets, and traditional CV models. These models are large, GPU utilization is high during each job, and cold-starting them online is too slow for users. We had to pre-configure resource pools, which created waste and occasional queues.
2. The output quality required constant parameter tuning and offline training. Because of cost constraints, online and offline workloads had to share infrastructure, and our switching logic was not yet intelligent enough.
3. Different GPU types across different data centers made resource management even harder.

For an AIGC business, compute is not a back-office detail. It is part of the life line of the product.

Evaluation is still unsolved

Controlling a diffusion model to commercial quality is hard. In one iteration, the left sleeve edge clearly improved after we trained a more targeted base model.

But we soon found that the model had overfit. In other scenes, the generated image acquired a hazy layer that damaged the texture and commercial quality of the photo.

The same pattern appeared across base models, LoRAs, templates, and parameter choices. Even with strong community developers on the team, there was no obvious best practice for deciding whether a model change was truly better.

That is why real customer demand matters so much. AIGC teams have to improve together with customers inside an uncertain experience space.

Small teams, hard choices

WeShop was an AI product under Mogujie, run by a small, self-driven team distributed across several regions. We were hiring for frontend, backend, and algorithm roles, but we also wanted to stay small.

The frontend challenge was designing interactions around AI. The backend stack was mainly Go and Python, with heavy work around compute management. The algorithm work required familiarity with Stable Diffusion, LLMs, and strong coding ability; traditional CV and NLP backgrounds were useful but not enough by themselves.

Many people reached out about APIs, private deployments, ecosystem integrations, and partnerships. With limited resources, we had to queue many requests and make tradeoffs. The practical lesson was simple: in early AI productization, focus is not a slogan. It is the only way a small team survives.

自从我们WeShop的Beta版本5月10号开放注册来，增长和用户反馈都远超我们团队的预期，有一种回到10年移动互联网刚开始的阶段，只要做好产品功能，自然就会有口碑传播，有自来水的媒体为你宣传。

今天我们发布了正式版，其中最重要的是确定了WeShop是提供AI算力服务的收费模式。不熟悉WeShop背景的朋友可以参考下面两篇文章，也可以去我们官网体验下产品：www.weshop.com

大家现在讨论AI，偏哲学层面的多，偏落地的少。正好我们有一些切身的实践经验，在这里分享一些我们遇到的问题，和大家探讨探讨。

整个行业都处于非常早期的阶段，我们的经验也只是一种探索。过一段时间回顾，可能讲的全是错的，大家包涵。

首当其冲是如何在技术不够好的时候定义产品方案

我们做产品时，永远面对一个问题，如果一个技术成熟了，就没你啥机会了，比如现在的移动互联网。如果一个技术不成熟，做出来的产品有可能还不如传统方案好，成先烈了。

因此，我依旧认为在AI时代做应用，最灵魂的角色还是产品经理，只是这个产品经理的要求更高了。比如WeShop切入的赛道，在过去无论是学术界还是工业界，被投入资源最多的都是virtual try on，大家都希望能够给一个产品图，自由任意的穿到各式各样的模特身上。蘑菇街自从有图像算法团队开始，就一直在这件事情上做尝试，到今天我的看法依旧是技术还不够到2B产品化的最低标准，而在2C端的尝试可能更容易落地。

选一个有潜力的技术路线【技术品味，需要长期积累】，去解决一个长期困扰你的业务问题【业务sense，需要长期积累】，可能是最佳的实践路线。

一个有潜力的技术路线加上不错的产品交互，你的用户会比你更有想象力，给大家看一个我们客户的真实案例：

我们产品上线后，客户在使用我们人台图场景时，经常上传没有脑袋没有四肢的人台图片，比如：

这种人台在行业里面非常常见，也是我们已知问题，如果直接用WeShop，大概率是这样的：

我们花了很多时间去研究如何在这种人台上生产比较自然的模特图。我们有个客户自己找了个办法，增加了点涂鸦

再用Weshop生成，效果就好很多很多。

其他客户看到后很快有进一步发展了这个玩法，相当于变相解决了这个问题。

算力成本问题

WeShop是我职业生涯中第一次在这个用户规模下就要考虑算力和成本的项目。GPU资源除了贵之外，还不好买到，由于对增长的预估不足，我们经常要机器要的很急，感谢腾讯云的团队在背后大力的支持，到处帮我们调资源。

我们目前遇到几个明确的问题：

1. WeShop的业务模式需要很多不同特点的底模、lora、controlnet以及一些传统的CV模型做整合，而且是在用户发起任务请求的时候才知道合理的配置方案，但这些模型一般都很大，且每次任务的GPU使用率都是100%，没有办法在用户可接受的延时内从离线到线上，只能按经验来事先配好不同的资源方案，对我们的算力造成了不少浪费，而且不可避免的会发生不可预估的客户请求排队，但集群有余量。
2. 我们生成的效果，需要不停的按客户需求去调参，离线训练的需求很大，但又受限于成本约束，目前线上和线下是混合部署，线上资源和离线资源的之间的切换管理还不够智能，又造成了一部分的资源浪费。
3. 算力资源中有不同型号的卡，且在不同的机房，进一步加剧了我们整个算力管理的难度。

对比其他创业公司，可能我们的财力已经算好的了，但在AIGC时代，成本项依旧很突出，算力的成本基本就是业务生命线了，相信未来这方面会有更多成熟的方案出现。

模型评估问题

控制Diffusion模型到商用级别是个很难的问题，比如下面那张图，左1原图，左2是原底模，左3是针对性迭代的底模，可以看出来左手袖子边缘好了很多。

但是我们很快就发现，这个模型过拟合了，在一些场景上有很致命的问题，如下图所示，左1原图，左2生成图，会有一层雾蒙蒙的感觉贴在图片上，极大的影响了图片的质感。

类似的的情况，在各个场景都有发生，如底模和lora的训练，不同模板参数的选择。我们团队中已经有在海外社区中相对有影响力的开发者，但针对这个问题，如果有效的评估我们这次改进是不是更好，应该说目前还没有特别明确的最佳实践。

如何在不确定的体验中与客户一起进步，将是为了所有做AIGC团队要面临的问题，而这也正是尽快获取到真实的客户需求的重要性。

招人

WeShop是蘑菇街旗下的AI产品，WeShop。我们是一个小而充满自驱精神的团队，人员分布全球多地，资金自有且充足，目前正在积极招聘ing~~~

目前开放前端、后端、算法的开发岗位，我们未来依旧希望能保持一个小团队的状态。前端的挑战在于如何和实现AI base的交互问题，后端目前的技术栈是Golang和python，目前需求集中在算力管理的问题。算法需要对SD、LLM的各项工作比较熟悉，特别是能有较强的代码能力，有传统CV和NLP背景的同学加分。

希望有志于投入到AIGC浪潮的同学可以看下我们的作品，感兴趣的请联系我们：wujia@weshop.com 或 rongrong@mogu.com

最后

特别感谢大家的支持和认可，这个月好多朋友过来谈合作，比如需要API、需要私有定制、需要接入生态等，实在是资源有限，我们现阶段只能先把需求放在队列里面。我们现在是一个非常小的团队，在未来也会努力追求一个小团队，所以很多事情只能有取舍。其中特别感谢阿里的朋友，愿意迁就我们目前的产品现状，找了各种办法让我们能灵活的接入淘宝的应用生态。

WeShop会努力做好产品，服务好我们的客户，感谢大家。