Chang Portfolio 视频、图文、产品设计、软件开发作品与求职档案

Overview

项目说明

这是 woven-tote-bag-creative 这条 run 的第一版默认草稿(04_video_draft.mp4)。它和后来的《Smooth Summer Orbit》交付版来自同一个 run-id、同一份 00_inputs 快照、同一张 Hero shot,差别只在三处:

  • 创意选择:Candidate 1「The Bag That Doesn’t Move (Summer Does)」——包不动,夏天动,以 stop-motion / freeze / jump / 悬停成轨道作为视觉语言。
  • tag:无显式 --tag,所以走默认 part1/part2,storyboard prompt 当时还允许 panel 内 framing notes 与 motion arrows。
  • 拼接参数:tools/ffmpeg_variants.py::stitch_videos() 当时还没有 fps 参数,内部写死 30fps,Seedance 24fps 源片被强转,引入重复帧。

成片本身可以播放(854×480 / 30fps / 29.87s),但 Phase 5 的 Claude Vision 抽帧审查明确指出”有 stop-motion / hold / jump 造成的卡顿感”。深入复盘把卡顿来源拆成两层:

  1. 创意层:Candidate 1 brief 里反复出现 stop-motion、3 帧、冻结、悬停成轨道——Seedance 被这些词导向出有顿挫的运动。
  2. 工程层:fps=30 强转 24fps 的 Seedance 源片,补帧机制引入重复帧,放大了顿挫感。

两层都被证据化:analysis_stutter_contact.jpg(多帧接触表)、analysis_stutter_frames/(逐帧样本)被作为”为什么必须修”的输入沉淀下来。随后三项系统级修复被设计出来:

  • prompts/03_storyboard_prompt_template.md 显式禁止箭头 / panel 编号 / 手写注释 / diagram lines。
  • prompts/04_seedance_timeline_template.md 锁定单一主角 + 单一产品,禁止背景替身。
  • tools/ffmpeg_variants.py::stitch_videos() 加 fps 参数,默认 24fps。

这些修复之后跑出的就是 v2 的《Smooth Summer Orbit》。

把这一版作为作品集条目保留下来,不是把”上一稿”塞进交付物清单,而是因为这条 pipeline 的默认行为就是「序列化 · 不覆盖 · 以 tag 区别」——v1 和 v2 必须并存,才能对照;能对照,才有判断。敢留下失败版本才是这条流水线最反传统的地方。

也因此,这一版的存在价值不在于成片本身的质量,而在于它把”为什么这条流水线长成现在这样”的因果链摊在了桌面上:可见、可对照、可复盘、可继续修。

Process

制作流程

每个详情页都把真正重要的步骤拆开，不只展示结果，也展示判断是如何形成的。

01

Run 初始化:同一份 inputs 快照、同一个 run-id

`pipeline.py init --product-id woven-tote-bag-creative --run-id 20260520_144707_woven-tote-bag-creative` 与后续 smooth_clean 版完全一致。输入三视图、brand_context、action_constraints、ad_mode=playful_effects、video_duration=30 都在 `00_inputs/` 下被序列化为快照。这个选择是「变量控制」的前提:两版唯一的差别只能出现在创意选择 + tag 上,不能出现在输入上。

02

Phase 1 · Claude brief 选 Candidate 1「The Bag That Doesn't Move (Summer Does)」

同一轮 Claude 推理距周 6 个月趋势 + 15–20 个概念 + 锦标赛后,本版选中 Candidate 1「包是画面里唯一不动的东西 / 夏天在转动」:看百叶窗 / 阳伞 / 咖啡壶 / 亚麻餐巾以 stop-motion 在包周围自我编排,海边石阶作 climax。后续同一份 brief 中才补入了 Candidate 4 并改选,但当时保存下来的 prompt 快照用的就是 Candidate 1。

03

Phase 2 · GPT-Image-2 Hero(seed 54457,跨版本复用)

Hero 生成在 06:56:21。后续 smooth_clean 版没重跑这一步,直接复用同一张图作为 reference。这让「v1 vs v2 对照」只发生在创意 + storyboard + 拼接参数三层,而在产品外观这个「身份证」层是完全一致的——实验对照组只需要一个变量。

04

Phase 3 · 默认 tag(无 --tag)双 storyboard

`phase3 --duration 30` 被拆成 part1 / part2 两份 15 秒分镜,GPT-Image-2 各出 1536×1024(seed 93926 / 86947),都把 Hero 写进 input_refs。这两张 storyboard 的 prompt 里明确允许「cinematic framing notes / motion arrows in panels」——这是本版后续被诊断为「被 Seedance 误抄进视频」风险的根源。

05

Phase 4 · Seedance 两段 15 秒(seed 56357 / 60495)

fal.ai `bytedance/seedance-2.0/reference-to-video` 端点。每段 reference 是 Hero + 对应 storyboard,16:9 / 480p / 15s / generate_audio=false。输出落到 `04_video_draft_part1.mp4` 与 `_part2.mp4`。这一步后续 smooth_clean 版参数一样,唯一不同是 reference 里的 storyboard 画的是不同创意 + prompt 本身是带 stop-motion / 3 帧 / 冻结上下文的。

06

ffmpeg 拼接被写死为 30fps(`stitch_videos` 还没加 fps 参数)

当时 `tools/ffmpeg_variants.py::stitch_videos()` 还没加 fps 参数,内部写死 `fps=30`。等效 filter「[0:v]fps=30,scale=854:480:force_original_aspect_ratio=increase,crop=854:480,setsar=1[v0];[1:v]同上[v1];[v0][v1]concat=n=2:v=1:a=0[v]」。编码 libx264 / CRF18 / preset=slow / yuv420p / movflags=+faststart。产出 29.866s、896 帧、实际以 30fps 表达 Seedance 24fps 源片——会引入重复帧。

07

Phase 5 · Claude Vision 审查 → 双重卡顿诊断

ffmpeg `fps=1, scale=960:-1` 抽帧 → Claude review prompt → Claude Code CLI。人工复盘明确诊断两重原因:(1)创意语言本身含 stop-motion / 3 帧 / 冻结 / 悬停成轨道;(2)拼接强转 30fps 放大了轻微顿挫。诊断产物 `analysis_stutter_contact.jpg` + `analysis_stutter_frames/` 被作为证据保留,以此定义了后续三项修复。

Thinking

设计思路

这里说明为什么这样做，而不是只列出做了哪些动作。

v1 不是「失败」,是基线

在 AIGC 生产里,「什么叫卡顿」本身是个后验问题——必须跑出一版「看起来不对」的成片,才能定义什么叫对。这一版不是丢不起的交付品,而是「使判断变得可能的实验组」。作品集里保留它,是让看的人看到「这是怎么被迭代出来的」——不是天生就是 smooth 版。

卡顿不是单一原因:创意语言 + 工程默认双重贡献

初看会以为是代码 bug。实际上是两件事迭加:(a)Candidate 1 创意本身要求 stop-motion / 3 帧 / 冻结 / 悬停,是 Seedance 被导向出有顿挫感的主因;(b)`stitch_videos()` 默认 30fps 拼接把 Seedance 24fps 源片变成了含重复帧的 30fps,放大了顿挫感。判断这两者是「加法关系」而不是「二选一」,才能同时修两面。

同 run 同 hero 不同 tag:tag 就是为「变量控制实验」设计的

Tag 的初衷是变体命名,但这里袖手变成了「同一 hero 上起两个并行创意」的实验平台:v1 走默认 part1/part2、v2 走 creative_smooth_clean_part1/part2。两组产物同时存在于 `runs/` 下,创意人、产品方、复盘者随时可以拉出来并排。

失败不掩盖反而沉淀:`analysis_stutter_*` 是「证据链」

`analysis_stutter_contact.jpg` 把多帧拼成接触表,`analysis_stutter_frames/` 保留抽出的个帧。这些不是调试中间产物那种临时文件,而是明确作为「为什么要修下一步」的证据存下来。以后什么时候「为什么要加 fps 参数」被质疑,只需反回这几张帧。

拆开复盘:创意决策与工程决策各自都可被修复

Candidate 1 是创意决策——修复动作是「换 Candidate 4 / 改 brief」。stitch 写死 30fps 是工程决策——修复动作是「加 fps 参数默认 24」。storyboard 允许箭头是提示词决策——修复动作是「明示禁止、锁单主角」。三个修复动作互不依赖,才使得「不是梦中重构而是逐点升级」。

流水线的真正价值:「敢留下失败版本」

传统剪辑流程里,「上一版」几乎总是被另存为“tmp1” 最后被删掉。这条 pipeline 的默认行为是「序列化 · 不覆盖 · 以 tag 区别」,所以 v1 和 v2 并存不是侥幸,是默认。只有能并存才能对照,只有能对照才有判断——这是这条 v1 草稿能进作品集的原因。

Result

交付与结果

交付内容
  • 30 秒 480p 草稿成片 `04_video_draft.mp4`(854×480 / 30fps / H.264 / 29.87s / 5.99MB / 无音频)
  • 两段 15 秒 Seedance reference-to-video 原始片段 `_part1.mp4` / `_part2.mp4` 及各自 meta.json
  • Hero shot + 默认 tag 的双 storyboard(part1 / part2)+ 全部 prompt 快照(01/03/04 三层)
  • 卡顿诊断产物 `analysis_stutter_contact.jpg` + `analysis_stutter_frames/` 帧样本目录
  • `pipeline.log` 完整调用记录,可与 smooth_clean 版逐行对照看完整迭代路径
项目结果
  • 用真实成片暴露了「创意 prompt 含 stop-motion/freeze 词 + 拼接强转 30fps」双重卡顿来源
  • 为后续 creative_smooth_clean 版本的 3 项系统级修复(storyboard prompt 禁止箭头 / timeline prompt 锁单主角 / stitch_videos 加 fps 参数)提供了证据
  • 把 Candidate 1 留作「反例样本」,让流水线同时拥有 v1 基线与 v2 交付版,反者可对照
  • 同一条 run 上产出两份“同输入不同创意”的草稿——以事实证明 tag 机制可承担变量控制实验