AI 虚拟试衣从开发角度来看，本质上是一个由人物图像、服装参考图和试穿参数共同构成的图像处理任务。
在 AI Clothes API 中，开发者需要先准备目标人物图片，再指定需要试穿的服装。服装来源既可以是上传的参考图片，也可以直接使用图片 URL 或预定义的 Outfit Template。
完成输入准备后，通过 AI Task API 创建虚拟试衣任务，并根据返回的 task_id 查询处理状态，最终取得生成图片。
相比单纯讨论“AI 换装”，这套 API 更值得关注的是它如何组织人物、服装与生成任务之间的数据关系。
1. File API：先将人物图片转换成可调用的文件资源
AI Clothes API 使用独立的 File API 处理文件上传：
/s2s/v2.0/file这里并不是直接把完整图片放进创建试衣任务的请求中。
首先向 File API 提交图片的 content_type、file_name 和 file_size。API 返回的数据中包含两个关键内容：
file_id
用于后续创建 AI Task。
requests.url
用于实际上传图片文件。
因此，文件注册与图片二进制上传是分开的。
取得 requests.url 后，再通过 PUT 请求将真实图片上传到对应地址。完成后，这张人物照片就可以通过 file_id 被后续的虚拟试衣任务引用。
这种设计也意味着 AI Task 本身不需要反复传输原始图片数据，而是可以直接引用已经准备好的文件资源。
2. Reference Outfit：服装输入并不只有一种方式
人物图像准备完成之后，第二个核心输入是 Reference Outfit。
文档提供了三种服装来源：
- ref_file_id
- ref_file_url
- template_id
ref_file_id 适合已经通过 File API 上传的服装图片；ref_file_url 可以直接使用有效的服装图片 URL；template_id 则可以引用系统已经提供的 Outfit Template。
这种设计让服装资源和人物资源可以分别管理。
例如，用户照片可能每次都不同，但电商平台中的服装 SKU 相对固定。开发者可以根据自己的商品数据结构选择 URL、上传文件或者 Template，而不需要把人物与服装预先合成为一张图片。
3. Template API：将预定义服装作为独立资源调用
除了自己提供 Reference Outfit，AI Clothes API 还提供 Template API：
/s2s/v2.0/task/template/cloth
开发者可以通过该接口取得预定义的 Outfit Templates。
文档示例中还出现了：
page_size
以及：
starting_token
这说明 Template List 本身支持分页获取。
从 API 结构上看，Template 和用户自己上传的服装图片最终都可以作为 AI Task 的服装输入，只是资源来源不同。
因此，在具体应用中，可以根据服装数据的管理方式决定使用 template_id，还是使用自己的 ref_file_id / ref_file_url。
4. AI Task API：人物和服装在这里组成一次试穿任务
真正创建虚拟试衣任务使用：
/s2s/v2.0/task/cloth
人物输入可以使用：
src_file_id 或 src_file_url
服装输入可以使用：
ref_file_id、ref_file_url 或 template_id
文档给出的任务创建示例是：
这个请求已经能够体现 AI Clothes API 最核心的数据结构。
src_file_url 指向目标人物，ref_file_url 指向需要参考的服装，而 garment_category 则进一步指定本次虚拟试穿对应的服装区域。
因此，创建任务并不是只向模型提供“两张图片”，还需要让 API 明确知道这次试穿任务所对应的 garment category。
5. garment_category 为什么是重要参数？
在示例请求中：
"garment_category": "full_body" |
这个字段值得单独关注。
虚拟试衣面对的服装并不一定具有相同的身体覆盖范围。完整穿搭、上装和下装所对应的人体区域不同，因此 Reference Image 本身也必须与目标试穿区域匹配。
这一点在官方 File Specs 中体现得很明显。
例如进行 full-body try-on 时，不能使用只包含半身服装的 Reference Image；对于 lower-body，如果使用真人服装照片作为参考，也需要完整呈现对应的服装区域。
因此，garment_category 不只是一个普通商品分类字段，它与本次 AI Task 所处理的试穿范围直接相关。
6. AI Clothes API采用异步 Task 处理
创建任务成功后，API 不会直接在同一个响应中返回最终图片，而是返回：
json { "status": 200, "data": { "task_id": "SaGaqpDgKwFrVBgMpQMA3HY0LeqdT9_13W5TOD8_u_GPi6NqQ3dhlmN-6ntFwhzT" } } |
也就是说，虚拟试衣采用的是异步 Task 模式。
应用取得 task_id 后，再通过：
GET /s2s/v2.0/task/cloth/<YOUR_TASK_ID>
查询任务处理结果。
这种结构把 API 请求与 AI 图像生成过程分离开来。对于需要一定推理时间的图像任务而言，客户端不需要维持一次长时间的同步 HTTP 请求，而是通过 task_id 管理当前生成任务。
7. Result API返回的是生成图片资源
当 Task 成功后，查询结果中会出现：
这里可以关注三个字段。
task_status 表示当前 AI Task 的状态；error 用于表示任务错误信息；results.url 则提供最终生成图片的下载地址。
因此，从应用层来看，AI Clothes API 最终交付的并不是复杂的服装结构化数据，而是一项图像生成结果资源。
业务系统可以取得这个 URL，再决定如何进行前端展示或后续资源处理。
8. 图片规格实际上是API输入协议的一部分
对于视觉 AI API，输入图片不能被简单理解成“只要是 JPG 或 PNG 就可以”。
官方文档对 Target User Image 和 Reference Clothing Image 都规定了比较明确的条件。
推荐分辨率为 1024×768，最低为 512×384，图片最长边不超过 4096 px，文件大小需要低于 10MB，支持 JPG 和 PNG。
对于人物照片，文档还要求单人、正面站立、面部无遮挡，并对人物在画面中的占比以及身体可见区域提出要求。
这些限制说明，人物构图本身就是模型输入条件的一部分。
Reference Clothing Image 的要求则更加依赖服装来源。
真人服装参考图
如果使用真人穿着照片作为 Reference，需要保证只有一个人物，并且服装区域完整覆盖需要试穿的范围。
服装还不能被长发、手臂等严重遮挡。
例如需要进行 full-body try-on，就不能使用只有 half-body 服装信息的参考图片。
商品服装图
如果直接使用 Product Image，则要求提供单件服装的正面商品图。
文档明确不建议把上装和下装组合在同一张 Composite Image 中。
另外，对于 lower-body，目前要求使用实际穿着效果作为参考，而不是独立的下装商品图。
这些要求非常关键，因为它们说明 Reference Image 并不是普通商品图片接口。
图片中的可见服装区域、遮挡情况、人物姿态以及商品呈现方式，都会直接决定它是否符合 AI Task 的输入条件。
9. 从API结构理解AI虚拟试衣
把这些接口放在一起看，AI Clothes 的技术结构其实比较清楚。
File API 负责管理人物和服装图片资源；Template API 提供可直接引用的预定义 Outfit；AI Task API 将人物输入、服装输入和 garment_category 组合成一次生成任务；task_id 用于跟踪异步处理过程，最终再通过任务查询接口取得结果图片。
因此，对于开发者来说，AI 虚拟试衣 API 真正需要理解的并不只是模型本身，而是三个技术对象：
Target User、Reference Outfit 和 AI Task。
Target User 定义需要被处理的人物，Reference Outfit 定义服装输入，AI Task 则负责把两类视觉资源和试穿参数组织成一次可查询的生成任务。
从这个角度看，AI Virtual Try-On 更接近一套围绕视觉资源管理与异步图像生成设计的 AI API，而不是一个简单的前端“换衣滤镜”。
