智慧衣橱虚拟试穿实践：从占位 UI到 Sophnet 双图图生图的落地思考
一、写在前面：
做智慧衣橱时，产品页面上最早写的是AI 试穿 / 图生图 · 接入中。很长一段时间里，我把试穿和小衣对话助手混在一起想——以为在聊天框里发一张衣服图，大模型说几句搭配建议，就算AI 试衣了。
后来明白：虚拟试穿本质上是图像问题，不是文本问题。
- 对话大模型：输入文字 → 输出文字（或附带描述）
- 虚拟试穿：输入 人物图 + 服装图 → 输出 一张新的合成图
这在技术分类上属于 图生图（Image-to-Image） 或 条件图像编辑：以人物照为底，用服装图和 Prompt 作为条件，让扩散模型生成穿上这件衣服的效果图。
专用 VTON（Virtual Try-On）扩散模型（如 IDM-VTON）效果最好，但需要 GPU 或海外 API。我们团队当时 只有 Sophnet 平台的 API Key，没有阿里云 DashScope 原厂 Key，也没有 Replicate 账号。
于是做了一个务实选择：用 Sophnet 上的 `Qwen-Image-Edit-2509` 做双图 + Prompt的近似试穿——不是严格意义上的 VTON，但在工程上能跑通、能演示、能写进论文，而且和现有 Key 兼容。
二、近似试穿
2.1 三种路线，我们选了中间那条
| 路线 | 做法 | 难度 | 效果 |
|---|---|---|---|
A. 专用 VTON | IDM-VTON 等双图模型 | 高（GPU/海外 API） | 最好 |
B. 图像编辑 / 图生图 | 双图 +「穿上这件衣服」Prompt | 中 | 够用，不稳定 |
C. 纯文生图 | 只描述衣服，不喂服装图 | 低 | 衣服对不上 |
我们走的是 B：在 Sophnet 文档里，`Qwen-Image-Edit-2509` 支持 1～3 张参考图 + 编辑指令，任务类型标注为 I2I（图生图），这和让人物穿上某件衣服的需求是对齐的。
2.2 和专用 VTON差在哪里（心里要有数）
图生图近似试穿 不保证：
- 服装纹理 1:1 还原（Logo、条纹可能糊）
- 人脸 100% 不变（偶发换脸感）
- 复杂姿态下的遮挡关系
但它 能保证：
- 端到端链路：App 选图 → 后端 → 云 API → 结果 URL → 展示
- 和衣橱数据打通：服装图可直接来自已录入单品
-基于图生图条件编辑的近似虚拟试穿，后续可升级为专用 VTON
三、整体架构：Key 绝不进 App
个人理解里，移动端 AI 接入的第一原则是：API Key 只放服务端。
```
Android VirtualTryOnScreen
│ Multipart: person_image + garment_image
│ Header: Authorization: Bearer <登录 JWT>
▼
FastAPI /api/v1/ai/tryon
│ 鉴权 → 存图 → tryon_service.run_tryon()
▼
Sophnet Qwen-Image-Edit-2509
│ 异步任务：创建 → 轮询 → 取 results[0].url
▼
backend/uploads/tryon/ → App 用 Coil 加载 result_url
```
令试穿单独一个页面：
1. 图生图慢（常 30～120 秒），不适合在聊天气泡里干等
2. 两张图 + 轮询，交互更像工具而不是对话
3. 以后换 VTON 模型，只改 `tryon_service.py`，App 协议不变
四、后端实现
4.1 接口设计：简单、可演示、可扩展
FastAPI 路由（节选）：
```python
@app.post("/api/v1/ai/tryon", response_model=TryOnResponse)
async def ai_tryon(
user_id: Annotated[int, Depends(current_user_id)],
person_image: UploadFile = File(...),
garment_image: UploadFile = File(...),
) -> TryOnResponse:
# 校验 image/ → 落临时文件 → run_tryon()
...
return TryOnResponse(payload)
```
响应里我刻意加了 `mode` 字段：
- `provider`：Sophnet 图生图成功
- `demo`：未配置 Key，或调用失败时回显人物图
这是个人很看重的一点：没有 Key 的日子也要能答辩演示 UI。Demo 不是造假，而是工程上的 降级策略（Graceful Degradation）。
4.2 核心：双图顺序 + Prompt 设计
Sophnet 文档写得很清楚：`input.images` 支持 1～3 张图，多图时按数组顺序，且 输出宽高比以最后一张为准。
因此我们的顺序是：
```python
"images": [garment_data_uri, person_data_uri]
# 图1 = 服装，图2 = 人物 → 输出比例跟人物走
```
Prompt 是反复试出来的（可放 `.env` 覆盖）：
```python
DEFAULT_TRYON_PROMPT = (
"参考图1中的服装单品，让图2中的人物自然穿上该服装。"
"保持图2的人脸、发型、体态、背景不变，服装贴合身体，写实摄影风格，高清。"
)
DEFAULT_NEGATIVE_PROMPT = (
"模糊，低质量，变形的脸，多余的手指，文字水印，卡通，插画风格，"
"服装错位，头部替换，背景突变"
)
```
思考： Prompt 写图1 / 图2是和数组顺序绑定的；若以后改成人物在前、服装在后，Prompt 必须一起改，否则模型会懵。
4.3 异步任务：创建 + 轮询
Sophnet 图片接口是 异步 的：POST 返回 `taskId`，再 GET 查状态直到 `SUCCEEDED`。
创建任务（节选）：
```python
payload = {
"model": "Qwen-Image-Edit-2509",
"input": {
"prompt": prompt,
"negative_prompt": negative,
"images": [garment_data_uri, person_data_uri],
},
"parameters": {
"size": "12801280",
"watermark": False,
"prompt_extend": True,
"save_to_jpeg": True,
},
}
r = client.post(SOPHNET_IMAGE_TASK_URL, headers={...}, json=payload)
task_id = output["taskId"]
```
轮询逻辑（个人实现要点）：
```python
while time.time() < deadline:
r = client.get(f".../task/{task_id}", headers={...})
status = output.get("taskStatus", "").upper()
if status == "SUCCEEDED":
return output["results"][0]["url"]
if status in ("FAILED", "CANCELED"):
raise RuntimeError(...)
time.sleep(2) # 默认 2 秒一轮，最多 180 秒
```
响应体有时包在 `output` 里，有时在 `result` 里，我写了 `_unwrap_output()` 做兼容，避免联调时明明成功却解析失败。
图生图失败时不向 App 抛 500，而是 `print` 日志 + 降级 demo。用户至少能看到人物回显和错误提示，而不是整页崩溃。
4.4 环境变量（`.env`）
```env
TRYON_PROVIDER=sophnet
SOPHNET_API_KEY=你的Key
TRYON_MODEL=Qwen-Image-Edit-2509
TRYON_API_BASE_URL=https://www.sophnet.com/api/open-apis/projects/easyllms/imagegenerator/task
TRYON_POLL_MAX_SEC=180
```
Sophnet 文档：[视觉模型](https://www.sophnet.com/docs/component/vision_model.html)
五、Android 端实现与思考
5.1 页面：VirtualTryOnScreen
交互我设计成三步，尽量像工具不像聊天：
1. 选人物照（相册）
2. 选服装图（相册 或 衣橱横滑选单品）
3. 点生成试穿效果→ 展示 `result_url`
实现的衣橱联动：服装图不必重新拍，直接用 DataStore 里已有 `imageUri`，形成我的衣橱 → 试穿预览闭环。
5.2 上传：Retrofit Multipart
```kotlin
@Multipart
@POST("api/v1/ai/tryon")
suspend fun tryOn(
@Part personImage: MultipartBody.Part,
@Part garmentImage: MultipartBody.Part,
): TryOnResponseDto
```
`AiRepository` 里从 `content://` 读字节，和上传头像同一套路：
```kotlin
suspend fun virtualTryOn(personUri: Uri, garmentUri: Uri): TryOnResponseDto {
val personPart = uriToPart(personUri, "person_image", "person.jpg")
val garmentPart = uriToPart(garmentUri, "garment_image", "garment.jpg")
return api.tryOn(personPart, garmentPart)
}
```
5.3 超时：图生图 ≠ 登录接口
普通接口 readTimeout 20s；图生图单独 `aiApi()` 拉到 120s。这是实际联调时得到的经验——异步轮询在后端做，但整次 HTTP 仍可能接近一分钟。
5.4 登录与游客
试穿接口复用 JWT。游客点击生成会引导登录——既是安全（防刷 API），也是产品逻辑（试穿算深度功能）。
六、联调步骤
1. `cd backend && pip install httpx && uvicorn main:app --host 0.0.0.0 --port 8080`
2. `.env` 填 `SOPHNET_API_KEY`
3. Android `local.properties`：`WARDROBE_API_BASE_URL=http://10.0.2.2:8080/`（模拟器）
4. App 登录 → 搭配 → AI 实验室 → AI 试穿 / 虚拟上身
5. 人物照 + 服装图 → 生成
6. 成功：`mode=provider`；未配 Key：`mode=demo` 回显人物图
七、效果与局限：
效果：
- 认清试穿 = 图生图，没有硬塞进 LLM 聊天
- 服务端代理 Key，JWT 鉴权
- 演示降级 + 真实模式用 `mode` 区分
- Sophnet 双图 I2I 与现有 Key 兼容，零 GPU
局限：
- 效果随 Prompt、照片质量波动大
- 专用 VTON 在衣服还原度上仍明显更好
- 大图 Base64 上传，尚未做压缩/去背景预处理
- 轮询在后端同步阻塞，高并发时要改 task 队列
若继续迭代，我会按这个顺序：
1. 上传前缩放到短边 768、服装图去背景
2. 后端改异步：POST 返回 task_id，App 轮询
3. 有余力再换 Replicate IDM-VTON 或万相试衣专用接口
八、总结
本项目的虚拟试穿模块，是在智慧衣橱场景下对图生图（Image-to-Image）技术的一次工程实践：客户端采集人物照与服装单品图，经 FastAPI 服务端调用 Sophnet 平台的 Qwen-Image-Edit-2509 图像编辑模型，通过双图输入与自然语言编辑指令生成近似上身效果。该方案属于 条件图像编辑式近似试穿，与专用 VTON 扩散模型相比实现成本更低，便于在课程项目中完成端到端验证；API 密钥部署于服务端，移动端仅传输业务图片与 JWT，兼顾安全与可扩展性。
