# S1 / S2 / S4 实测结果 — 2026-09-02

对应 `docs/todo/dev-plan.md` 第 1 节的三个 spike。脚本、素材、产物全在本目录，
一次性脚本，结论已写回 `docs/todo/dressup-dance-room.md` 第 8 节、
`dressup-dance-room-mvcp.md`、`dev-plan.md`、`H3-CONSOLE.md`，本文件只留证据链。

## 素材准备

- `person.png`/`garment.png`：本机 Codex `gpt-image-2` 生成的合成测试素材
  （1024×1536），沿用 `CODEX-IMAGEGEN.md` S3 的调用方式，非真实拍摄照片。
- `danceref.mp4`：先用 H3 Console 纯文生视频（`partition: text`）跑一条
  4 秒的"女性跳舞"测试片段，再当参考跳舞视频用——图省事，不代表正式素材
  来源（需求文档 8.3 仍待定）。
- 三个文件都通过 H3 Console 自带的 `POST /v1/assets`（multipart，字段名
  `file`）上传，拿到形如 `http://192.168.110.67:8080/assets/<id>__<name>`
  的 URL，直接喂给 `reference_image_urls`/`reference_video_urls`。**这个
  端点是读 H3 Console 自己的前端 JS 才发现的，`H3-CONSOLE.md` 原来没记**
  （控制台自己的文件选择器用的就是它，外部 URL 则跳过它直接原样透传给
  后端，见该文件 JS 注释）。

## S1 —— 一步法（路径 B）：过

`submit-s1.mjs` / `prompt-s1-onestep.txt`：`<Picture 1>`=人物图，
`<Picture 2>`=衣服图（`retention_analysis` 标 `attribute_transfer`），
`<Video 1>`=参考跳舞视频，`<Audio 1>`=其配乐。`POST /v1/videos`，
`width=480 height=832 frames=240（10s）steps=20`。

job `eac9f8fe1c36`：`queued`→`done`，**耗时 712s**（10s 产物比之前
H3-CONSOLE.md 记录的 4s 产物约 200s 明显更长，帧数越多耗时越长，不是常数），
`partition` 落到 `ref2va`，产物 `s1-result.mp4` 480×832/24fps/10.125s。

逐条对照验收标准：

| 验收项 | 结果 |
|---|---|
| ① 任务提交成功、partition=ref2va | ✅ |
| ② 人脸与人物图一致 | ✅ 大体一致，可辨认是同一个人；**头发变长变蓬松，有轻微漂移**，不是像素级复刻 |
| ③ 衣服确实换成参考衣服图那件 | ✅ 红色旗袍、金边、盘扣、侧开衩全部还原，明显不是原图的灰 T 恤黑裤 |
| ④ 动作跟参考视频对得上 | ✅ 宽马步、大幅度甩臂过顶、比心手势等动作词汇跟参考视频的 hip-hop 风格高度一致（见 `frame_03.png`/`frame_05.png` vs `ref_02.png`/`ref_04.png`） |

**四条全过 → 结论：路径 B 成立。**

**副作用发现**：产物里角色自己选了一双黑色短靴，prompt 里没提鞋子——
跟 `CODEX-IMAGEGEN.md` 里 Stage1 图片编辑遇到的"鞋子自作主张"是同一类
问题，**Stage2 的六段式 prompt 以后也要显式规定鞋子处理方式**，不能假设
只有图片编辑模型会有这个漂移。

## S2 —— `reference_video_urls` 实测：过

`submit-s2-control.mjs` / `prompt-s2-control-novideo.txt`：跟 S1 完全同
一份 `reference_image_urls`、同一句 `motionDescriptor` 文字描述，**唯一
差异是不传 `reference_video_urls`，prompt 里也去掉 `<Video 1>`/`<Audio 1>`
两段**。

job `ecf3a02df7bd`：`queued`→`done`，耗时同量级，产物 `s2-control-result.mp4`。

对照结果（`c_03.png`/`c_05.png` vs S1 的 `frame_03.png`/`frame_05.png`）：
**动作幅度和风格明显不同**——没有参考视频的这条只是原地小幅度的比心/
摆手，没有宽马步、没有甩臂过顶、没有 S1 那种 hip-hop 能量感，即使文字里
写的是同一句"lively hip-hop inspired routine with hip sways and
raised-arm turns"。

| 验收项 | 结果 |
|---|---|
| ① 带 reference_video_urls 提交不报错 | ✅ |
| ② 动作/节奏明显受参考视频影响（跟不带的对比看得出差别） | ✅ 差别非常明显，见上 |
| ③ 记录参考视频的时长/格式/分辨率限制 | 控制台 UI 提示文案已写死：**最多 3 段、单段 2–15 秒、mp4、音轨自动带上**（跟 H13 一致）；本次用的是 4 秒 480×832 mp4，未额外测试格式/分辨率边界 |

**结论：`reference_video_urls` 字段真实生效，不是摆设**，且效果强到光靠
`motionDescriptor` 文字描述压不住——`dance_refs` 库和 `<Video 1>` 标签在
M.15 模板里是必需的，不能退化成纯文字描述。

## S4 —— 素材可达性：过（且找到了比原计划更简单的方案）

不需要额外验证 LAN/公网可达性——`/v1/assets` 本身就是解法：H3 Console
自带这个上传端点，**任何能连到 `H3_CONSOLE_BASE` 的客户端（我们的
`server.js`、本机、乃至将来的 `admin.html`）都可以把文件先传到这里，
换回一个 H3 后端自己保证能拉到的 URL**，不需要我们自己把 `uploads/`
目录暴露到公网。实测：本机上传后，返回的 URL 本机也能直接 `curl` 到
（200），且随后的 S1/S2 job 成功读取了这些 URL 对应的图片/视频内容
（换装结果正确=证明图片确实被下载并使用了）。

**这条改变了 MVCP M.13 的设计**：不用再纠结"给 `uploads/` 挂公网签名
地址"，改成"用户上传落本地盘（服务端校验/剥 EXIF 那套不变）之后，
需要喂给 H3 的那一份，再转发一次到 `/v1/assets` 换 URL"。第四期接
fal.ai 时这条依然不适用（fal 是完全不同的服务，需要自己的入站方案），
但那是第四期的事，不阻塞第一～三期。

## 对下游文档的影响（已同步）

1. `docs/todo/dressup-dance-room.md` 8.1/8.2：标记已解决，路径 B 生效。
2. `docs/todo/dressup-dance-room-mvcp.md`：
   - M.6 `composed_images` 整表作废（S1 过的既定后果）。
   - M.7 去掉 `composedImageId` 字段。
   - M.13 按 `/v1/assets` 发现重写。
   - M.15 只保留一步法模板，两步法模板降级为附录/删除。
3. `docs/todo/dev-plan.md`：S1/S2/S4 标记完成，第 0 期出口选"S1 过"分支，
   T7/T10 等任务描述里跟 Stage1/`composedImageId` 相关的部分要跟着简化。
4. `H3-CONSOLE.md`：补充 `POST /v1/assets` 端点文档（原来没记录）。