RESULTS.md 5.99 KB

Edit Raw Blame History


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 是完全不同的服务，需要自己的入站方案），
但那是第四期的事，不阻塞第一～三期。
对下游文档的影响（已同步）

docs/todo/dressup-dance-room.md 8.1/8.2：标记已解决，路径 B 生效。
docs/todo/dressup-dance-room-mvcp.md：


M.6 composed_images 整表作废（S1 过的既定后果）。
M.7 去掉 composedImageId 字段。
M.13 按 /v1/assets 发现重写。
M.15 只保留一步法模板，两步法模板降级为附录/删除。

docs/todo/dev-plan.md：S1/S2/S4 标记完成，第 0 期出口选"S1 过"分支，
T7/T10 等任务描述里跟 Stage1/composedImageId 相关的部分要跟着简化。
H3-CONSOLE.md：补充 POST /v1/assets 端点文档（原来没记录）。