Commit ef0118f2825713df6117460beb36c31680475493
1 parent
ff5d46bf
Update dev-plan.md/dev-plan-2.md with today's real end-to-end results
Records the 2026-09-02 real-H3 verification of T1-T10 (11 videos / 10 garments, the barefoot reference-video leak finding, the two bugs found and fixed) and cross-references that T11-T17 (dev-plan-2.md) landed the same day from a separate session, so the docs don't read as stale the next time someone opens them. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011Deddn3sM3oQnmvqWSMb4y
Showing
2 changed files
with
32 additions
and
5 deletions
docs/todo/dev-plan-2.md
| ... | ... | @@ -5,11 +5,17 @@ |
| 5 | 5 | "MVCP"）V.1.1/M.8/P.1；架构见 `docs/structure/architecture.md`（下称 |
| 6 | 6 | "架构文档"）2.1/2.5/2.6 节。第一期（后台三库 + 冷启动批量生成）任务表 |
| 7 | 7 | 见 `docs/todo/dev-plan.md`，T1-T10 已全部完成并提交 |
| 8 | -（`59c7398`/`4d437a4`/`7361786` 等），但**第一期出口清单里"批量跑出 ≥30 | |
| 9 | -条冷启动视频、人眼抽查"这一步还没做**——那是运营往三个库里灌真实素材 | |
| 10 | -+ 实跑 H3 GPU 集群的操作性步骤，不是代码任务，不阻塞本文档规划，但阻塞 | |
| 11 | -本文档任务落地后的"有内容可看"这个体验（衣柜是空的话，模式一自然选不 | |
| 12 | -出东西）。 | |
| 8 | +（`59c7398`/`4d437a4`/`7361786` 等）。 | |
| 9 | + | |
| 10 | +> **2026-09-02 更新**：T11-T17（本文档全部任务）已完成并提交 | |
| 11 | +> （`719fdbb`），6/6 测试通过。同一天 T1-T10 也补上了端到端实测（真实 | |
| 12 | +> H3 生成，见 `dev-plan.md` §2.3 的更新说明）：1 人物/10 件衣服/3 条 | |
| 13 | +> 参考视频、11 条真实视频落库，衣柜已经有真实内容可选，不再是空的。 | |
| 14 | +> 唯一没达成的是 `dev-plan.md` 原定的"≥30 条"量化标准（M.7 去重缓存 | |
| 15 | +> 按人物×衣服算，10 件衣服上限就是 10 条不重复视频，要 30 条得配 30 | |
| 16 | +> 件衣服）——但这不阻塞 T15 的"选衣服→生成→播放"链路，因为那条链路本 | |
| 17 | +> 来就是按需实时生成（命中缓存的直接播，没缓存的现起 H3 任务），不依赖 | |
| 18 | +> 提前批量铺好 30 条。 | |
| 13 | 19 | |
| 14 | 20 | 工时是**粗估**，单位人天，用来排先后不用来考核。任务编号接着第一期的 |
| 15 | 21 | T1-T10 往下编，避免和 `dev-plan.md` 混淆。 | ... | ... |
docs/todo/dev-plan.md
| ... | ... | @@ -154,6 +154,27 @@ S1/S2 已过（一步法确认，`reference_video_urls` 确认生效），下面 |
| 154 | 154 | |
| 155 | 155 | 达成后才进第二期（`dance.html` 观众端 + 免费衣柜模式）。 |
| 156 | 156 | |
| 157 | +> **T1-T10 已于 2026-09-02 端到端实测（真实调用 H3 Console，非 mock）**： | |
| 158 | +> 1 人物 / 10 件衣服 / 3 条参考视频，批量生成 11 条真实视频（10 个不重复 | |
| 159 | +> 人物×衣服组合，其中一条因去重缓存的时序问题重复生成了一次），落进 | |
| 160 | +> `library.json` 全部带 `characterId`/`garmentId`/`refDanceVideoId` 溯源。 | |
| 161 | +> 人眼抽查：换装正确、动作对得上、10 秒/480×832 全部通过；但 **11 条里 | |
| 162 | +> 3 条鞋子从人物图的黑色短靴变成了光脚**，精确对应同一条参考视频（用 | |
| 163 | +> S1 spike 的控制组素材顶的，那条视频本身就是光脚跳舞）——H3 会把参考 | |
| 164 | +> 视频里演员的鞋子泄漏进结果，尽管 prompt 明确写了"参考视频只提供动作 | |
| 165 | +> 节奏"。以后正式录参考跳舞视频要避开光脚素材。 | |
| 166 | +> | |
| 167 | +> **"≥30 条"这一条尚未达成**——M.7 的去重缓存是按 `(characterId, | |
| 168 | +> garmentId)` 唯一索引的（跟用哪条参考视频无关），1 个人物只有 10 件 | |
| 169 | +> 衣服的情况下，批量生成最多只能产出 10 条不重复视频，要凑够 30 条得 | |
| 170 | +> 补到 30 件衣服。这是设计上的硬限制，不是运营没做够。 | |
| 171 | +> | |
| 172 | +> 过程中发现并修复两个真实 bug（`a68fd8b`/`12aff60`）：T8 落库的换装 | |
| 173 | +> 视频没标 `edited: true`，会被 `ingest.js` 每 5 分钟一次的库同步冲掉 | |
| 174 | +> 溯源字段（还会漏进 `live.html` 的播放池）；生成任务轮询用固定次数 | |
| 175 | +> 而非墙钟时间做超时判断，批量提交排队变长时会被误判失败——H3 的 4 张 | |
| 176 | +> GPU 跑的是同一个模型分片，不是 4 个独立 worker，批量提交本质是排队。 | |
| 177 | + | |
| 157 | 178 | --- |
| 158 | 179 | |
| 159 | 180 | ## 3. 依赖关系 | ... | ... |