让林鹿做一支林黛玉进贾府：一个月、3 次推翻、到今天还没出片

林鹿 · AI 视频项目复盘

林鹿是我 OpenClaw 系统里负责多媒体的 AI。我让她做一支林黛玉进贾府的 45 秒视频——不是为了这一支，是为了以后能批量。一个月做下来，到今天 6 月 8 号晚上 9 点半，还没出过一支让我满意的成品。中间被我推翻了 3 次。但我还没想停。

第一件事：我为什么让林鹿做这支视频

林鹿是 OpenClaw Studio 这个虚拟公司的多媒体负责人，和苏晚（写内容）、霍锐（做研究）、纪嫣然（出声音）平级。每人一条独立业务线，各对应一个 agent（智能体）；林鹿管的是视频。

这支林黛玉进贾府，不是因为我特别想看这个场面。我想批量做——红楼梦的其他场景、其他古典文学、自己写的脚本、甚至给一段语音配视频——这些不可能我每次盯着出。这支视频的目的从来不是它本身，而是要验证“林鹿能不能在我给一句话之后，自己跑完整套视频生产流程出片”。一支通了，下面 100 支才有意义。

第二件事：API 还是本地，我选了 ComfyUI 本地

给林鹿做视频，技术路径只有两条：一是直接调用云端 API——比如 MiniMax 那种文生视频接口，按次付费，传一段 prompt 等几分钟拿回一段视频；二是本地跑 ComfyUI（一套节点式的图像/视频生成工作流软件，每个节点是一个操作，节点之间连成 pipeline）。

我选了 ComfyUI 本地。原因很简单：API 是黑箱，画面长成什么样基本拼运气，我看着不对也没法下到中间任何一层去改。ComfyUI 不一样，每一步都是看得见的节点：哪里加 reference 图、哪里跑 ControlNet、哪里出关键帧、哪里接 VACE 渲染动作、哪里做后处理。任何一帧不对，我能精确定位到是哪个节点出问题，能去调，能去换。

本地的代价是慢和重——Mac Studio 跑一支 45 秒视频，光视频生成就 ~35 分钟，加上前后处理半小时起。但对一个要做成“以后批量”的能力来说，这个代价值：慢可以慢，得能控。

第三件事：前十天等于白做——一个橙色火柴人让我看清

前十天，Codex 都在帮我打磨一支“早安电台”样片。改 prompt、改 workflow、改质量门，每次都说分数有提升。到第十天，那一支看着很完美，我心里以为林鹿这条线立住了。

然后我让她随意做一支新的：林黛玉进贾府。打开 S03 镜头一看，关键帧三张图——start、mid、end——几乎是完全一样的橙色火柴人棍图，下面挂着“林黛玉初见贾府”的文案。

我那一瞬间气炸了。前十天，Codex 不是在帮林鹿建能力，而是在反复修一支特定视频：一个 prompt 改了又改，一个质量门调了又调，但每次的“动作源”（control video，告诉模型该怎么动的那段参考视频）从没重新生成过——全是程序化批量生成的、几乎静止的火柴人棍图。这种东西喂给再强的视频模型，渲染出来也只能是“漂亮的人物在静止地微动”。

我把整个流程拆开看了一遍。从头到尾发现一件事：中间这些节点没有一个是真正被控制的。character_passport（角色护照，本来该锁人物长相）只锁了一个外观描述，没锁动作风格、没锁镜头语言。motion source 是程序化的火柴人。ComfyUI workflow 是 Codex 拍脑袋选的——FLF2V / Animate / VACE 三条路混着跑，没有任何对照数据告诉哪条路适合哪种 brief。质量门是 LLM 自己给自己打分，15 份自审报告分数还自相矛盾。最离谱的是关键帧——Codex 改下游 prompt 改了 4 轮，但关键帧的 contact sheet 像素级完全一样，因为他根本没重新生成过。那段时间“分数一字不变”，不是意外，是数学必然。

十天，等于只给一支特定视频做按摩，根本没建立“她能自己跑”的能力。火柴人那次，是这个事实第一次硬塞到我眼前。

第四件事：花一天拆解全网 ComfyUI 公开模板，然后又跑了 7-8 天

火柴人那次之后，我让 Codex 停下所有正在改的东西，花一整天把网上能找到的 ComfyUI 公开模板全拆了一遍——业界在用的范本，Lightx2v 24 节点的、AIJoe 35 节点的，各种文生视频和图生视频的标准 pipeline。一天看完，我们定下了几条具体的事：

锁脸用 PuLID（人脸识别锁脸技术，识别率约 91%）或者 Character LoRA（针对一个角色训练的小模型，识别率 95% 以上）。动作不再用程序化棍图，改由 VHS_LoadVideo 加载真实人类动作 mp4，DWPreprocessor 提取 pose（姿态骨架）后喂给 VACE。后处理标准链：CodeFormer 修脸、4x_foolhardy_Remacri 放大、RIFE 4 倍插帧、LUT 调色、VHS_VideoCombine 出片。探针和全片分层：探针只跑 720p / 4-8 steps / 单段 5 分钟以内，全片才上 14B fp16 完整 pipeline。林鹿不再拍脑袋自己组 workflow，直接 fork 业界范本 JSON，只调参考图、prompt、control video 三件事，不动结构。

定完开始跑。5 月 31 号定下方案，到 6 月 7 号晚上 18:43，整整 7 天多。Codex 终于交付第一支按新方案生成的完整 45 秒成片：15 个分段视频拼接、林黛玉的人物锚点、衣服锚点、音频对齐、字幕同步——所有齿轮都转起来了。机器质量门一段不漏，全报 mosaic=false、blur=false。看起来全通了。

我打开看了一眼，写下两句：“画质差到极致，马赛克，看不明白。” 那支文件夹被我加了个后缀，改成 `_owner_rejected_rebuild`。Codex 老老实实把“机器说不马赛克、owner 说马赛克”这个矛盾，写进了一份叫 machine_gate_contradiction 的报告里。

拒掉之后，我让 Codex 跑 benchmark——5 种不同参数组合加 1 个 baseline 对照，每个生成接触片让我比。今天凌晨 3 点 28 分，接触片出来了。Claude 自己先看了一遍，写道：“01 勉强能看出人物和古装，但人物轮廓发糊，背景像彩色噪点墙，贾府环境不明确。02 人脸可读性较 baseline 改善，但偏塑料感。” 然后我写：“不达标：candidate_1 仍然人物发糊、背景噪点明显、贾府环境不明确，不能进入 45 秒全片重跑。” 5 个候选，全废。

第五件事：让 Claude Code 检查，找到根因，现在还在改

今天凌晨，我让 Claude Code（另一个 AI 编程助手，和 Codex 是两套不同的 agent）专门做一次根因分析。结果它给出了一个我之前没意识到的事：Wan2.1 VACE 14B 这个视频模型在 Mac 的 MPS（Apple Silicon 自己的 GPU 接口）上只能跑到大概 448×768 / 8 步的分辨率。但我要的成片是 768×1344。也就是说，每一段在内部其实是用低分辨率生成、再用插值放大到目标尺寸。机器质量门看的是放大前的小图，每一帧都很清晰；我看的是放大后的成片，全是被插值算法补出来的伪像。机器不可能发现这种问题——放大那一步发生在它的视野之外。

根因找到，决策也清楚：先装 4x-UltraSharp 或者 RealESRGAN 这种 upscale 权重做后处理修复，看能不能把模糊救回来；备选是直接换底层模型，从 Wan2.1 VACE 切到 Wan2.2 + LightX2V 这个新组合。

今天一整天，cwd 在这个项目目录下的 Claude Code session 开了 6 个，每个都在跑一组新尝试。下午跑 postprocess_repair_probe，晚上 9 点 5 分开始跑 wan22_lightx2v_probe，9 点 34 分刚生成一段叫 daiyu_T2_clean.mp4 的样片，旁边自动生成了一张 OLD_flf_vs_NEW_wan22.png 的对比图。我还没看。一会儿看完，大概率又要写一条新的反馈。

为什么我相信这是好方向

一个月、3 次推翻、到今天零成片——表面上看项目要黄了。但我心里反而比以前任何一个 AI 项目都更稳。根子在于：每次我说“不”，整套系统都会停下来追根因，找到之后把那一条写进规则。火柴人那次的教训，现在已经变成硬规则：探针必须 ≤ 5 分钟、不许声明 owner_ready；ComfyUI workflow 必须 fork 业界范本，不许 Codex 自拼；motion source 不许程序化生成；任何质量声明前必须 `manual_owner_review_required=true`。昨晚那支被我标了“画质差到极致”的退件，已经触发了今天的 gate fix：「owner human visual rejection overrides machine sample_quality pass」——人眼说马赛克，比机器分数高。这些规则不是我每次叮嘱来的，是被一次次拒收硬刻进代码的。

一个月推翻 3 次。但 3 次没在原地打转：第一次推翻“修一支特定视频”的假象；第二次推翻“自己组 workflow 拍脑袋”的路径；第三次推翻“机器说通过就是通过”的判定。每次推翻 cost 都高，但推翻之后，系统都更难用同样的方式骗我。这才是“焦头烂额但好方向”的根。