【AI智能体】Codex 制作数字人商品展示和口播视频实战详解

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

我是AI时代的无业游民，我游荡在现实与意念之间

【AI智能体】Codex 制作数字人商品展示和口播视频实战详解

什么时候用这份手册：你手里有一个商品链接或几张产品图，想快速产出一条带数字人口播的展示视频；或者你在作品集里需要一个"AI 视频流水线"的小项目。下面按使用频率排序，每条给出用途、最小示例、一个坑。30 秒内找到你要的那段。

前置知识：会 Python 基础语法、知道什么是 HTTP 请求与 JSON、能看懂 YAML 配置。不需要你有生产环境经验——所有示例都能在一台普通笔记本上跑通。

① 重构前的症状：脚本能跑，但一改就崩

很多人第一版是"一个大函数串到底"，典型长这样：

# before.py —— 能出片，但没法维护
def make_video(product_url):
imgs = crawl(product_url) # 抓图
txt = ask_llm(f"给{product_url}写口播稿") # 写稿
audio = tts(txt) # 配音
avatar = gen_avatar(audio) # 数字人
return merge(imgs, avatar) # 合成

痛在哪，能复现：

• 改一句文案要重跑全流程：tts 和 gen_avatar 各花几十秒到几分钟，改标点也得从头来。
• 失败不可续：第 4 步超时，前 3 步的产物全丢。
• 模型换代即全改：想把口播模型从一家换到另一家，得动主函数。
• 无法并行：多个商品只能串行排队。

面试/作业里常被追问的点：“你的流水线中间产物存在哪？失败了怎么恢复？” 答不上来，说明你写的是脚本不是系统。

② 问题诊断：根因是"阶段耦合 + 无契约"

表面看是代码乱，根因有三条：

关键认知：数字人视频生成的本质是"多模态产物的接力"——文本→音频→视频→合成。每一棒都应该是一个可缓存、可替换、有 schema 的产物。把这条想通，重构方向就定了。

③ 重构后的写法：阶段化 + 契约 + 落盘

核心改动：把一条大函数拆成四个带输入输出契约的 Stage，中间产物落盘为文件，用配置声明用哪个模型。

# after/pipeline.py
from dataclasses import dataclass
from pathlib import Path

@dataclass
class Script: # 契约1：文案
text: str
duration_hint: float

@dataclass
class VoiceTrack: # 契约2：音频
wav_path: Path
sample_rate: int

@dataclass
class AvatarClip: # 契约3：数字人片段
mp4_path: Path
fps: int

# 每个 Stage 只做一件事，输入输出都是上面的 dataclass
def stage_script(product: dict, llm) –> Script:
raw = llm.chat(
model="当前主流大模型", # 型号走配置，不写死
messages=[{"role": "user",
"content": f"为商品写30秒口播稿：{product['title']}"}],
)
return Script(text=raw, duration_hint=30.0)

def stage_voice(script: Script, tts) –> VoiceTrack:
out = Path("work/voice.wav")
tts.synthesize(script.text, out) # 厂商无关的薄封装
return VoiceTrack(wav_path=out, sample_rate=24000)

def stage_avatar(voice: VoiceTrack, avatar_engine) –> AvatarClip:
out = Path("work/avatar.mp4")
avatar_engine.render(voice.wav_path, out)
return AvatarClip(mp4_path=out, fps=25)

def stage_compose(imgs: list[Path], clip: AvatarClip) –> Path:
out = Path("work/final.mp4")
compose(imgs, clip.mp4_path, out) # 画面+画中画口播
return out

关键改动对照：

调度层只负责编排与缓存判断：

def run(product, cfg):
if not Path("work/voice.wav").exists():
script = stage_script(product, cfg.llm)
stage_voice(script, cfg.tts)
clip = stage_avatar(VoiceTrack(Path("work/voice.wav"), 24000), cfg.avatar)
return stage_compose(product["images"], clip)

注意点：契约 dataclass 里的字段名一旦定下就当 API 对待，改名等于破坏下游——这正是"能写进作品集"的那一小段能力：定义模块边界。

④ 收益与代价

• 可读性：主函数从 ~40 行降到 ~8 行，新人 5 分钟看懂流程。
• 性能：文案与配音阶段可并行到多商品，N 个商品总耗时从 N×T 降到接近 max(T)；单商品改文案只重跑后两段，省掉最贵的数字人渲染。
• 复杂度：多了 3 个 dataclass、1 个调度函数、1 份配置。代价是前期多写约 30 行样板。
• 可测性：每个 Stage 可单独 mock 测试，这是面试里能讲清楚的加分项。

⑤ 适用边界与检查清单

不该这么改的时候：一次性脚本、只跑一遍的演示、Stage 之间没有复用价值——过度抽象反而拖慢你。判断标准：你会不会第二次改它。

上线前检查清单：

• 每个 Stage 的输入输出都是显式类型，没有裸 dict
• 中间产物落在固定目录，重跑能命中缓存
• 模型/引擎名走配置，主流程不出现厂商 SDK 调用
• 单 Stage 有超时与重试，失败不污染已完成产物
• 有一条"只重跑某一段"的命令或参数

面试常被追问：为什么用 dataclass 而不是 dict？——因为字段即契约，类型检查能在改下游前拦住你。为什么产物落盘而不是传对象？——因为渲染是分钟级操作，内存态一旦崩就全丢。

把这条流水线做成一个小 demo 放进作品集，比"我调过某个视频 API"有说服力得多：它证明你会拆边界、定契约、管状态——这三件事，才是真实项目里最缺的。