外观
AI 视频生产工作流项目
分册导航： 本文负责端到端架构、数据模型、状态机和媒体底座；只有语音恢复时间线、口播一致性、首轮镜头可用率、无穿帮拼接、平台规格、模型横评和投放增长，见实战问题与增长篇。
目录
- 1. 项目摘要
- 2. 背景、目标与边界
- 3. 端到端工作流
- 4. 系统架构与技术栈
- 5. 核心数据模型与状态机
- 6. 必须掌握的知识点
- 7. 关键技术方案与权衡
- 8. 常见问题、根因与解决方案
- 9. 评测、监控与验收
- 10. 分阶段实施计划
- 11. 面试表达与递进追问
- 12. 参考资料
- 13. 简明总结
1. 项目摘要
- 项目类型：学习型生产项目；
- 项目目标：将主题、文案或已有素材自动加工为可预览、可局部返工、可验收的视频；
- 典型输入：主题、目标受众、平台、时长、画幅、风格、语言、已有图片或视频、品牌规范；
- 典型输出：MP4 成片、封面、字幕文件、分镜清单、素材清单、质检报告和生成审计记录；
- 核心链路：需求 → 脚本 → 分镜 → 素材 → 配音字幕 → 时间线 → 合成 → 质检 → 局部返工 → 发布；
- 核心难点：长任务可靠执行、镜头一致性、音画同步、编码兼容、局部重试、成本控制和内容合规；
- 项目定位：不是调用一次视频生成 API，而是构建一套可恢复、可追踪、可评测的 AI 视频生产系统。
1.1 面试结论
AI 视频项目的技术含量主要不在“调用哪个模型”，而在如何把不稳定、昂贵、长耗时的生成能力组织成可控工作流：以镜头为最小生产和重试单元，用持久化状态机保证任务可恢复，用统一时间线解决音画字幕同步，用技术质检和语义质检共同守住交付质量。
1.2 面试官为什么问
这个项目可以同时考察：
- 是否真正理解多模态模型，而不只是会写 Prompt；
- 是否具备异步任务、状态机、幂等和失败恢复能力；
- 是否理解视频编码、时间戳、帧率、音频和字幕；
- 是否会设计评测、监控、成本和安全门禁；
- 是否能从业务目标反推架构，而不是堆砌模型和框架。
2. 背景、目标与边界
2.1 示例业务场景
为知识科普、产品介绍、儿童故事或内部培训自动生产短视频。用户提交主题和要求后，系统完成脚本、分镜、素材生成、配音、字幕、合成和质检；用户可以只重做失败镜头，而不必整条视频重新生成。
本文描述的是建议方案，不代表已经上线的真实业务。项目数据量、准确率、耗时、成本和收益必须通过实际实现与测试获得，不得把规划值当作实测结果。
2.2 功能目标
- 支持文本主题、结构化脚本和已有素材三种入口；
- 自动生成脚本、角色设定、视觉规范和分镜；
- 支持图片、视频、配音、音乐、音效和字幕资产；
- 能查看总进度、阶段进度、失败原因和成本；
- 支持镜头级预览、编辑、重新生成和版本回退；
- 自动完成编码、画幅、时长、响度和字幕等技术质检；
- 使用视觉模型或人工门禁完成内容一致性和安全审核；
- 导出平台要求的成片和配套文件。
2.3 非功能目标
- 可恢复：服务重启或供应商超时后能从检查点继续；
- 可控重复：内部请求、回调和状态迁移必须幂等；外部生成优先使用供应商原生幂等 Token，提交结果不确定时先对账。供应商不支持去重或查询时只能承认至少一次语义，不能承诺绝不重复生成或扣费；
- 可观测：每个镜头、模型调用和渲染步骤均可追踪；
- 可替换：模型供应商通过适配层接入，不把业务状态绑定到供应商状态；
- 可控成本：生成前可估算，执行中有预算和重试上限；
- 可审计：保留素材来源、授权、Prompt 版本、模型版本和审核记录；
- 可局部返工：一个镜头失败不触发整条流水线重跑。
2.4 明确边界
- 第一版优先做模板化短视频，不直接挑战长电影级自由编辑；
- 第一版只支持有限画幅、帧率、编码和字幕模板；
- AI 负责生成建议和素材，不绕过版权、肖像、声音授权和人工发布门禁；
- 业务授权通过不等于供应商能力可用；提交前必须按供应商、模型、区域和版本执行能力策略门禁；
- 发布到外部平台属于独立适配器，生成完成不等于发布成功；
- 模型效果会随供应商和版本变化，项目必须用评测集而不是演示案例判断质量。
截至 2026-07-10，OpenAI 视频 API 的当前限制包括：不支持生成真人；带真人脸的输入图片会被拒绝；人类肖像角色上传默认受限；受版权保护的角色和音乐会被拒绝。限制会变化，接入时必须重新核对目标供应商官方策略。即使用户拥有某项授权，也不能绕过供应商硬限制；系统应在付费调用前给出可解释拒绝或路由到合规且支持的方案。
3. 端到端工作流
3.1 总体流程
图 1：镜头级 AI 视频生产与局部返工闭环
图表加载中…
替代文本： 任务先生成结构化脚本和分镜，图片/视频与音频资产按镜头并行生产，统一时间线合成低清预览；质检失败只回到对应镜头，成功后才高清渲染和发布。
读图结论： 镜头是生成、质检和重试的最小单元，低清预览与局部返工用于控制高成本生成的不确定性。
3.2 步骤一：需求规范化
输入必须先转为结构化约束：
- 目标平台：横屏、竖屏或方形；
- 总时长和单镜头时长范围；
- 目标受众、语言和表达语气；
- 视觉风格、角色、品牌色和禁用元素；
- 是否允许真人、声音克隆、外部素材或敏感主题；
- 业务授权是否完备，以及目标供应商当前是否支持该人物、参考图、角色、音乐和区域；
- 输出分辨率、帧率、字幕样式和音频要求；
- 预算、最高重试次数和交付时间。
需求不完整时先进入 WAITING_FOR_INPUT，不能让模型擅自补齐版权、人物身份或发布范围等高风险信息。
3.3 步骤二：生成结构化脚本
LLM 输出必须经过 Schema 校验，而不是直接保存自然语言。建议脚本至少包含：
- 标题、核心观点和目标情绪；
- 旁白文本及预估时长；
- 镜头列表和镜头顺序；
- 每镜头的主体、动作、场景、景别、运镜、风格和禁止项；
- 所需图片、视频、配音、音乐和音效；
- 字幕文本和重点词；
- 事实来源与需要人工确认的内容。
校验失败时只修复无效字段；事实、版权或人物信息不确定时转人工确认。
3.4 步骤三：分镜与时间预算
系统根据最终配音或预估语速，为每个镜头分配时间范围：
text
时间线总时长 = max(所有已裁剪片段的结束时间)
顺序镜头使用重叠转场时：
总时长 = 片头 + Σ镜头时长 - Σ重叠转场时长 + 片尾
镜头时长 >= 旁白时长 + 必要停顿只有把转场做成独立插入片段时，才把它的时长正向加入；常见 Crossfade 会让相邻镜头重叠，因此要扣除重叠区间。最终以逻辑时间线上所有视频、音频、字幕和图层片段的最大结束时间为准，不能仅靠镜头时长相加。以 FFmpeg xfade 为例，输入需先规范到相同分辨率、Pixel Format、帧率与 Time Base，再按 duration 和 offset 计算重叠区间。
分镜阶段同时生成角色设定卡和视觉规范（Style Bible），锁定角色外观、服装、色彩、光线、镜头语言和负面约束，避免每个镜头独立发挥。
教学插图：共享角色约束与跨镜头身份漂移
替代文本： 左侧角色设定卡固定原创机器人角色的橙色围巾、白色星形徽章、左侧短天线和蓝白配色；上排不同景别、机位和光线仍保留这些身份锚点，下排独立生成则分别出现围巾变色、徽章丢失、天线换边和身体轮廓变化，并标出逐镜质检结果。
读图结论： 共享 Style Bible、参考资产和结构化镜头约束可以降低跨镜头漂移概率，但不能保证一致；系统仍需把身份锚点转成可检查规则，逐镜质检并局部返工。
景别、角度和光线的正常变化不等于身份漂移；角色一致性也只是质量维度之一，动作连续性、时序、语义、字幕、声音和技术规格仍需单独验收。
3.5 步骤四：镜头资产生成
以 shot_id 为最小任务单位并行生成。每次模型调用记录：
- 内部业务意图 ID、供应商原生幂等 Token（若支持）、供应商任务 ID 和提交状态；
- Prompt 模板版本、最终 Prompt 和参考资产；
- 模型、参数、Seed、分辨率和目标时长；
- 提交、开始、结束、失败和下载时间；
- Token、时长、次数或供应商账单项；
- 原始响应、错误码和重试次数。
视频生成通常是异步任务，应使用 Webhook 接收完成事件，并用轮询或定时核对作为兜底。Worker 在“供应商已受理、内部任务 ID 尚未落库”之间崩溃时，状态必须进入 SUBMISSION_UNKNOWN / RECONCILING，禁止盲目重新提交；优先按原生幂等 Token、Client Request Key 或供应商任务列表对账。若供应商既不能去重也不能查询，只能人工对账或补偿，并明确保留重复计费风险。供应商返回的临时地址必须及时转存到项目对象存储，不能把临时 URL 当作永久资产。
3.6 步骤五：配音、音乐与字幕
推荐先确定最终旁白音频，再进行字幕和镜头精确对齐：
- TTS 生成配音并记录文本版本；
- 使用 STT 或强制对齐获得句级、词级时间戳；
- 根据停顿和语义切分字幕；
- 音乐按旁白区间做 Ducking；
- 音效绑定镜头或具体时间点；
- 字幕在最终时间线下重新导出，避免转码后漂移。
3.7 步骤六：时间线与合成
先生成与渲染器无关的 timeline.json，再由 FFmpeg 或 Remotion 消费。时间线至少包含：
- 输出画幅、帧率、时长和音频参数；
- 每个镜头的入点、出点、裁剪、缩放、速度和转场；
- 配音、音乐和音效轨道；
- 字幕片段、字体、位置和安全区；
- 封面、片头、片尾和品牌图层；
- 所有资产的内容哈希和版本。
先渲染低清预览，质检通过后再做高清成片，可以显著减少高成本返工。
3.8 步骤七：双层质检
技术质检检查文件是否可交付：
- 容器、Codec、Pixel Format、分辨率和帧率；
- 音视频流、总时长、黑帧、静音和损坏帧；
- 字幕越界、乱码、重叠和字体缺失；
- 响度、峰值、采样率和声道；
- 音画时间戳、首帧速度和文件大小。
语义质检检查内容是否正确：
- 画面是否符合分镜；
- 同一角色、场景和品牌元素是否一致；
- 旁白、字幕和画面表达是否对应；
- 是否存在事实错误、敏感内容或授权风险；
- 是否需要人工导演复核。
3.9 步骤八：局部返工与交付
质检结果必须绑定到具体 shot_id、资产或时间区间。返工时仅失效受影响节点及其下游缓存，例如：
- 改旁白文本：重做配音、字幕、时间线和最终渲染；
- 改某个镜头 Prompt：只重做该镜头、预览和最终渲染；
- 改字幕样式：复用所有生成素材，只重做渲染；
- 改画幅：重新计算裁剪、安全区和模板，不默认重做全部模型素材。
教学插图：镜头级生产与局部返工
替代文本： 脚本先被拆成多个分镜；各镜头分别生成画面、配音和字幕并汇入时间线。质检发现镜头 4 不合格后，只将镜头 4 返回生成环节，其他合格镜头继续复用，最终重新合成并输出成片。
读图结论： 把 shot_id 作为生成、质检和重试的最小单元，才能把一次局部质量问题限制在局部资产及其必要下游，而不是让整条高成本链路全部重跑。
插图表达的是逻辑依赖，不代表所有返工都只影响一个文件；实际失效范围仍由资产哈希、时间线引用和下游缓存依赖共同决定。
4. 系统架构与技术栈
4.1 逻辑架构
图：架构｜AI 视频生产系统组件边界与可靠启动链路
图表加载中…
替代文本： API 将业务任务与 Outbox 原子写入 PostgreSQL，Dispatcher 以固定 Workflow ID 启动 Temporal；规划、生成、渲染和质检 Worker 通过模型适配层、对象存储和媒体工具协作，整条链写入可观测系统。
读图结论： 可靠性边界在“数据库任务 + Outbox + 固定 Workflow ID”，模型生成、媒体渲染和质检则按资源类型拆成可恢复 Worker。
创建任务时不能在一个请求里无保护地“双写 PostgreSQL + 启动 Temporal”。API 短事务先写 VideoJob 与 Outbox 事件并提交；Dispatcher 以 workflow_id = job_id 启动工作流，遇到同 ID 时按“复用已存在 Workflow、拒绝不同业务意图”的策略处理。Outbox 至少一次投递，启动动作和首个 Activity 都必须幂等；扫描器负责补发未发布事件，从而修复“有任务无工作流”。另一种可选边界是以 Workflow 为事实源，并让数据库写入成为幂等 Activity，但两种事实源不能混用。
4.2 技术调用流程
图：技术调用流程｜视频任务启动、供应商提交与结果对账
替代文本： 用户创建视频任务后，API 在 PostgreSQL 同一事务写入任务与 Outbox；Dispatcher 领取事件，以固定 Workflow ID 请求 Temporal 启动，收到 started/already-exists 确认后才标记 Outbox 已发布，启动不可用时保留事件等待补偿。生成 Worker 再通过供应商适配层提交镜头任务；供应商成功时转存资产，响应丢失时冻结重提并按幂等 Token 或任务 ID 对账。
图表加载中…
读图结论： API、Outbox、Workflow 和供应商调用各自有不同一致性边界；最危险的不是收到明确失败，而是付费提交结果未知后盲目重提。
该时序把“可靠启动”和“外部副作用对账”连起来：内部用固定业务意图与 Workflow ID 防重，外部只在供应商契约支持的范围内依赖幂等 Token；无法确认时必须保留人工处理边界。
4.3 技术栈、框架、库与组件清单
| 技术点 ID | 技术点/环节 | 类型 | 采用方案 | 链路职责 | 版本/证据边界 |
|---|---|---|---|---|---|
| TP-01 | 长任务编排与恢复 | 工作流组件 | PostgreSQL Outbox + Temporal + 分资源 Worker | 可靠启动分钟到小时任务，管理超时、重试、信号、检查点和恢复 | 参考生产方案；是否采用由任务时长、失败恢复演练和团队运维能力决定 |
| TP-02 | 媒体探测、合成与转码 | 命令行工具 + 可选渲染框架 | FFmpeg、ffprobe、libass；按模板需求选 Remotion | 以时间线为输入完成探测、裁剪、字幕、响度、编码和最终验收 | 生产构建、编码器和平台兼容性必须由固定制品、ffprobe 与真实播放器验证 |
| TP-03 | 外部生成模型接入 | 服务适配组件 | 版本化供应商适配层 + 业务意图/任务对账 | 归一化提交、查询、Webhook、下载、错误、成本和能力限制 | 供应商能力和政策动态变化；必须以当前官方文档、契约测试和真实调用证据为准 |
4.4 横向选型对比
| 技术点 ID | 候选方案 | 优点 | 缺点/代价 | 适用场景 | 不适用场景 | 选择结论与依据 |
|---|---|---|---|---|---|---|
| TP-01 | Celery + Redis 等任务队列 | 上手快、生态成熟、适合简单异步任务 | 复杂状态、补偿、长时恢复和可视化需自行建设 | MVP、阶段少、任务可安全重跑 | 多小时工作流、人工信号、跨阶段补偿 | 早期可用；当恢复代码和人工排障成本持续上升时切换 |
| TP-01 | Temporal 等持久化工作流 | 状态、定时、重试、信号和恢复语义完整 | 平台运维、确定性与版本兼容成本更高 | 多阶段长任务、局部返工、进程重启后恢复 | 单步短任务或团队无法维护平台 | 只有故障注入证明恢复收益覆盖平台成本时采用 |
| TP-02 | 纯 FFmpeg 管线 | 编解码控制精细、部署路径直接、适合最终成片 | 复杂动态图形和可视化模板开发成本高 | 稳定媒体处理、编码兼容和批量渲染 | 大量 React 动效模板与可视化设计迭代 | 最终兼容链优先保留 FFmpeg，并固定构建验证 |
| TP-02 | Remotion 模板 + FFmpeg 验收 | 前端团队易复用组件，动态图形和字幕模板迭代快 | 浏览器渲染资源、字体和跨环境一致性更复杂 | 品牌模板、动态图形和低清预览 | 只需简单拼接转码或资源受限环境 | 模板复杂度值得引入时使用，最终仍由媒体探测和播放器验收 |
| TP-03 | 业务代码直接调用单一供应商 SDK | 链路短、首版快、可直接使用供应商特性 | 业务状态与供应商字段、错误和策略耦合 | 单供应商验证、低切换需求 | 多供应商、统一对账、成本和合规治理 | 原型期可用；出现第二供应商或统一治理需求时迁移适配层 |
| TP-03 | 统一供应商适配层 | 业务状态稳定，便于合约测试、路由、对账和审计 | 不能抹平模型质量与能力差异，维护矩阵有成本 | 生产多供应商、容灾、区域和政策路由 | 只有一个短期调用且无治理需求 | 用适配器合约测试、能力矩阵新鲜度和切换演练证明价值 |
4.5 详细推荐技术栈
| 层次 | 推荐选择 | 主要职责 | 选型原因与边界 |
|---|---|---|---|
| Web 前端 | Next.js、React | 任务创建、分镜编辑、预览、进度和返工 | 适合复杂表单和时间线交互；不在浏览器执行重型最终渲染 |
| API 层 | Python、FastAPI、Pydantic | 鉴权、参数校验、任务接口和签名 URL | AI SDK 生态成熟；重型生成不能放进请求进程 |
| 长任务编排 | Temporal | 持久化工作流、超时、重试、取消、信号和恢复 | 适合分钟到小时的多阶段任务；MVP 可用 Celery + Redis，但补偿和可视化要自行建设 |
| 元数据 | PostgreSQL | 项目、任务、镜头、资产、版本、成本和审核记录 | 保持强一致的业务状态；大文件不直接存数据库 |
| 对象存储 | S3 兼容存储或 MinIO | 原始素材、中间产物、成片、封面和质检截图 | 使用内容哈希、生命周期和签名 URL 管理资产 |
| AI 规划 | 支持结构化输出的 LLM | 需求澄清、脚本、分镜、Prompt 和返工建议 | 输出必须 Schema 校验；事实与版权信息需要独立验证 |
| 视频生成 | 供应商适配层，如 OpenAI 视频 API | 文生视频、图生视频、参考图驱动 | 生成是异步和概率性的；适配层维护版本化能力/限制矩阵、原生幂等与对账能力，不能让供应商状态直接成为内部状态 |
| 音频模型 | TTS、STT、可选声音转换 | 配音、时间戳、字幕和音色处理 | 最终音频是时间线基准；真人声音必须有授权 |
| 视觉模型 | VLM 或专用检测模型 | 分镜符合度、一致性和安全检查 | 模型评分只能辅助，关键发布保留人工门禁 |
| 媒体处理 | FFmpeg、ffprobe、libass | 探测、裁剪、缩放、合成、转码、响度和字幕 | 生产环境固定构建版本和编解码能力 |
| 模板渲染 | Remotion，可选 | React 模板、动态图形、字幕和低清预览 | 适合参数化模板；最终兼容性仍用 ffprobe/播放器验证 |
| 实时进度 | SSE 或 WebSocket | 推送阶段进度、镜头状态和错误 | 服务端状态来自数据库或工作流，不以浏览器连接为事实源 |
| 可观测性 | OpenTelemetry、Prometheus、Grafana | Trace、Metric、Log、成本和告警 | 使用统一 job_id、shot_id 和 provider_call_id 关联链路 |
| 部署 | Docker；规模扩大后 Kubernetes | 环境固定、Worker 隔离和弹性扩容 | 渲染、CPU 和 GPU Worker 应使用不同资源池 |
4.6 MVP 与生产版的区别
| 能力 | MVP | 生产版 |
|---|---|---|
| 工作流 | Celery + Redis 或单机任务队列 | Temporal 等持久化工作流 |
| 存储 | 本地磁盘 + SQLite/PostgreSQL | PostgreSQL + S3 兼容对象存储 |
| 模型 | 单一供应商 | 统一适配层、路由、限流和降级 |
| 合成 | 固定 FFmpeg 模板 | 时间线模型 + FFmpeg/Remotion 多模板 |
| 质检 | 技术检查 + 人工预览 | 技术、语义、规则和人工分级门禁 |
| 返工 | 整任务重跑 | 镜头级依赖失效和断点续跑 |
| 观测 | 普通日志 | Trace、Metric、Log、成本和审核关联 |
5. 核心数据模型与状态机
5.1 核心实体
| 实体 | 关键字段 | 作用 |
|---|---|---|
VideoProject | 标题、用户、品牌规范、目标平台 | 聚合多个版本和生成任务 |
VideoJob | 状态、目标规格、预算、当前阶段、版本 | 一次端到端生产执行 |
ScriptVersion | 结构化脚本、来源、版本、审核人 | 保证脚本变更可追溯 |
Shot | 顺序、时间范围、Prompt、状态、依赖 | 最小生成、质检和返工单元 |
Asset | 类型、URI、哈希、规格、来源、授权 | 管理原始和生成素材 |
ProviderCall | 业务意图、原生幂等 Token、供应商任务、提交/对账状态、参数、成本、错误 | 追踪每次外部模型调用及不确定提交窗口 |
TimelineVersion | 轨道、片段、时间戳、模板版本 | 将创作数据与渲染实现解耦 |
Render | 输入版本、输出规格、日志、成片 URI | 保存预览和正式渲染结果 |
QCReport | 检查项、结果、证据、失败区间 | 驱动发布门禁和局部返工 |
AuditEvent | 操作者、动作、前后值、时间 | 记录授权、审核、发布和删除 |
5.2 状态机
建议内部状态使用业务语义，而不是复制供应商的 queued、processing：
图 3：AI 视频业务任务状态机与失败恢复路径
替代文本： 业务任务从创建、需求补齐、规划、审批进入素材生成、音画对齐、预览渲染和质检；质检失败进入 REWORK_REQUIRED，并按问题类型回到镜头生成、对齐或预览渲染。执行阶段出现可重试错误时进入 FAILED_RETRYABLE，经 RECOVERING 读取检查点后定向恢复；不可重试或超过次数、预算上限时进入 FAILED_FINAL，用户也可以在未完成阶段取消任务。
图表加载中…
读图结论： REWORK_REQUIRED 是“质量不达标但已有资产可复用”的局部返工门，FAILED_RETRYABLE 是“执行故障且允许恢复”的技术失败门；二者不能混为一次整任务重跑，取消和最终失败也必须形成明确终态。
REWORK_REQUIRED 必须携带失败的 shot_id、资产或时间区间及依赖失效范围，再按问题类型回到最小必要节点。FAILED_RETRYABLE 则保存失败阶段、检查点、错误分类、已用重试次数和预算，RECOVERING 读取这些证据后恢复原失败节点，而不是默认从头执行。图中只画出代表性故障和取消入口；规则上任一未完成的执行状态都可能进入 FAILED_RETRYABLE、FAILED_FINAL 或 CANCELLED，取消还要向已启动的 Worker 和供应商任务传播，无法撤销的外部副作用必须转补偿或人工处置。
所有状态迁移都必须带版本号或条件更新，并以状态事件记录前态、后态、触发源和业务意图，防止 Webhook、轮询、恢复器和人工操作并发覆盖。PUBLISHED、FAILED_FINAL 与 CANCELLED 是终态；若业务允许“从失败任务创建新尝试”，应产生新的执行版本或业务意图，而不是偷偷把终态改回执行态。
外部付费调用还要有独立提交子状态：
图 4：付费供应商提交、对账与防重复付费状态机
替代文本： 外部调用从 NEW 以唯一业务意图和供应商幂等 Token 进入 SUBMITTING；明确受理并持久化任务 ID 后进入 SUBMITTED 和 RUNNING。若响应丢失或供应商受理后本地落库前崩溃，则进入 SUBMISSION_UNKNOWN，自动冻结再次付费提交并转入 RECONCILING；查到原任务时继续跟踪，权威证据确认未创建时才允许使用同一业务意图安全重提，无法确认时进入 MANUAL_REVIEW。
图表加载中…
读图结论： SUBMISSION_UNKNOWN -> RECONCILING 是付费副作用的安全闸门：不知道供应商是否已受理时先冻结重提并对账，只有取得“未创建”的权威证据才进入 SAFE_RESUBMIT，否则宁可人工处理也不能用自动重试赌一次重复扣费。
内部防重边界是 business_intent_id 唯一约束，供应商防重边界是其明确承诺的原生幂等 Token 或稳定 Client Request Key；两者要随 ProviderCall 一起持久化。幂等 Token 只能覆盖供应商契约声明的范围和保留期，不能把外部系统包装成通用的 exactly-once。
SUBMISSION_UNKNOWN 不允许自动回到 SUBMITTING。RECONCILING 应依次用原生幂等 Token、Client Request Key、供应商任务列表和账单记录核对：查到任务就复用原任务 ID；确认未创建才通过 SAFE_RESUBMIT 复用同一业务意图重提；供应商既不能去重也不能查询、证据冲突或账单延迟时进入 MANUAL_REVIEW。这条边界只能降低重复生成和重复扣费概率，无法消除不提供幂等与查询能力的供应商所带来的残余风险。
5.3 幂等与缓存键
缓存键不能直接拼接字符串，应先构造版本化对象，按字段排序做 Canonical JSON 序列化，再计算 SHA-256。例如：
json
{
"tenant_id": "...",
"authorization_scope_hash": "...",
"stage": "render_preview",
"normalized_input_hash": "...",
"provider": "...",
"model": "...",
"model_version": "...",
"generation_engine_version": "...",
"parameters": {},
"prompt_template_version": "...",
"reference_asset_hashes": [],
"timeline_version": "...",
"renderer_version": "...",
"ffmpeg_build": "...",
"font_pack_version": "...",
"codec_profile": "..."
}字段边界和类型由 Canonical JSON 保证，不能用 a + b + c 产生歧义。不同阶段只保留真正影响该产物的字段，但必须覆盖租户/授权范围和全部输出版本。缓存命中前仍要重新验证资产存在、当前授权有效、供应商许可和输出规格兼容；撤权、删除、字体/编码配置变化要主动失效。随机生成任务只有在业务明确允许复用时才使用缓存；用户主动要求“重新创作”时必须产生新版本和新业务意图。
6. 必须掌握的知识点
6.1 视频与音频基础
- 容器与编码：MP4 是容器，H.264/H.265/AV1 是视频编码，AAC/Opus 是音频编码；
- 帧率：CFR 与 VFR 的区别，以及混用时的音画漂移风险；
- 时间戳：Time Base、PTS、DTS、入点和出点；
- 画面：分辨率、宽高比、SAR、DAR、裁剪、填充和安全区；
- 像素与颜色：Pixel Format、
yuv420p、色彩空间、色域和动态范围； - 压缩：码率、CRF、GOP、关键帧和首帧播放；
- 音频：采样率、位深、声道、响度、True Peak 和 Ducking；
- 字幕：SRT、VTT、ASS、软字幕、硬字幕、字体和换行规则。
6.2 生成式 AI
- 结构化输出和 Schema 校验；
- 文生图、图生图、文生视频和图生视频的差异；
- Prompt 模板、负面约束、Seed 和参考资产；
- 时序一致性、角色一致性、首尾帧和短镜头策略；
- TTS、STT、Forced Alignment 和 Lip Sync；
- VLM 质检、模型评分偏差和人工审核；
- 模型版本、参数和输入资产的可复现性边界。
6.3 分布式工作流
- 工作流、活动任务、队列和 Worker 的职责；
- 至少一次投递下的幂等处理；
- 超时、指数退避、最大重试、不可重试错误和死信处理；
- Webhook 验签、乱序、重复和丢失后的轮询对账；
- 断点续跑、检查点、补偿动作和取消传播；
- 供应商限流、全局并发、每用户配额和背压；
- 中间产物版本化、缓存失效和局部重算。
6.4 评测与可观测性
- 技术质量与语义质量必须分开评测；
- Trace 用于单任务调用链，Metric 用于整体趋势，Log 用于具体事件证据；
- 高基数字段如原始
job_id不应无限制放入聚合指标标签； - 模型、Prompt、脚本、素材、时间线和渲染版本必须一起记录；
- 成本要细分到项目、视频、镜头、供应商和阶段；
- 失败样本要沉淀为回归集，避免同类问题重复出现。
6.5 安全与合规
- 素材版权、音乐授权、角色形象、真人肖像和声音授权，以及目标供应商的版本化能力限制；
- 深度伪造、未成年人、敏感内容和平台政策；
- 上传文件隔离、病毒检查、Prompt 注入和工具最小权限；
- Webhook 验签、临时 URL、访问控制和数据保留周期；
- 水印、内容来源、审核记录和删除能力。
7. 关键技术方案与权衡
| 决策 | 推荐选择 | 备选方案 | 为什么 | 代价与风险 |
|---|---|---|---|---|
| 生产粒度 | 镜头级生成与返工 | 整条视频一次生成 | 可并行、可重试、成本可控 | 需要处理风格和转场一致性 |
| 时间基准 | 最终配音驱动时间线 | 先定画面再硬塞配音 | 字幕和旁白更容易同步 | 镜头可能需要裁剪或重生成 |
| 工作流 | 持久化状态机 | HTTP 请求内串行执行 | 长任务可恢复、可取消、可观测 | 引入工作流系统和确定性约束 |
| 视频模型 | 供应商适配层 | 业务直接调用单一 SDK | 可切换、降级、统一错误和成本 | 不能完全抹平供应商能力差异 |
| 合成 | 时间线 JSON + FFmpeg | 在业务代码中拼命令字符串 | 数据和渲染解耦，易版本化 | 需要维护时间线 Schema |
| 模板动画 | Remotion 可选 | 纯 FFmpeg Filter | React 适合复杂图形和预览 | 增加 Node 渲染栈和许可证评估 |
| 质检 | 规则 + VLM + 人工分级 | 只用人工或只用模型 | 兼顾效率、覆盖率和高风险门禁 | 需要维护阈值与误报策略 |
| 渲染策略 | 低清预览后高清成片 | 每次直接高清 | 减少高成本返工 | 预览与高清必须保持布局一致 |
| 缓存 | 内容哈希 + 版本依赖 | 仅按文件名或任务 ID | 可复用且能精确失效 | 随机创作是否复用需业务确认 |
7.1 为什么不能放在同步 HTTP 请求里
视频生成和渲染可能持续数分钟甚至更久，还会遇到排队、限流和供应商故障。同步请求容易超时、丢失进度、重复提交，也不能可靠支持取消和恢复。HTTP 接口只负责创建任务并返回 job_id；执行由工作流和 Worker 完成，前端通过查询与事件订阅展示进度。
7.2 为什么按镜头拆分
镜头是创作、成本、质检和返工的共同最小单元。拆得比镜头更细会增加调度和一致性成本；按整片处理又会导致一个局部失败引发全片重跑。镜头级还能明确记录哪个 Prompt、模型和参考图产生了哪个素材。
7.3 为什么先定义中间数据协议
如果脚本、分镜、时间线和供应商响应都只是自由文本，系统无法稳定校验、重试和渲染。先定义版本化 Schema，再让 LLM 和适配器围绕 Schema 工作，可以把概率性模型限制在确定性工作流之内。
7.4 技术难点清单
| 技术难点 | 为什么难 | 核心矛盾 | 可落地抓手 |
|---|---|---|---|
| 外部生成的幂等与费用一致性 | 供应商可能已经受理并计费，但内部在任务 ID 落库前崩溃；重试既可能恢复任务，也可能再次付费 | 业务希望“只执行一次”，外部接口通常只能提供至少一次或能力不一的去重保证 | 业务意图唯一键、供应商幂等 Token、SUBMISSION_UNKNOWN 对账态、账单与任务关联、人工补偿入口 |
| 跨镜头一致性与并行效率 | 镜头并行能缩短等待时间，却会让角色、道具、光线和空间关系各自漂移 | 生产吞吐与叙事连续性相互牵制 | Style Bible、角色身份锚点、参考资产版本、首尾帧衔接、跨镜头质检 |
| 多媒体时间基统一 | 视频帧、音频采样和字幕时间戳使用不同 Time Base，舍入或 VFR/CFR 混用会把微小误差累积成可见漂移 | 各资产独立生成，但交付必须共享一条确定性时间线 | 以最终音频驱动逻辑时间线、统一起始时间戳、分别换算 PTS、合成前媒体规范化、首中尾抽检 |
| 局部返工与缓存失效 | 重做一个镜头可能改变时长、转场、字幕和下游合成结果；仅按文件名缓存会复用错误资产 | 希望只重做局部，又必须保证所有受影响下游同步更新 | 不可变资产版本、内容哈希、显式依赖图、时间线引用版本、按依赖传播失效 |
| 概率质量与确定性交付 | 模型输出可能“技术上可播放但语义不合格”，VLM 质检也会误报或漏报 | 自动化效率与发布风险之间需要分级决策 | 技术规则、VLM 语义检查和人工门禁分层；高风险项硬阻断；失败样本进入回归集 |
| 合规授权与供应商能力漂移 | 业务侧有授权，不代表目标模型在当前区域、版本和输入类型下允许生成 | 合法可用与供应商可调用不是同一判断 | 授权链、能力矩阵和发布政策分开版本化；付费调用前契约校验；策略变化回归 |
这些难点的共同点是：模型调用只是局部能力，真正困难的是在不确定外部系统、确定性媒体标准和发布责任之间建立可恢复、可解释的边界。
7.5 方案亮点的证据化表达
以下是设计级亮点及其验证方法，不代表已取得线上效果；面试中只有完成对应测试或拿到真实 Trace、媒体报告和成本记录后，才能改写为“已实现”。
| 问题 | 关键决策 | 证据或验证方式 | 适用边界 |
|---|---|---|---|
| 单个坏镜头导致整片重跑 | 以 shot_id 作为生成、质检、成本和返工的共同最小单元，并用依赖图传播必要失效 | 注入单镜失败，比较重试前后的供应商调用、资产版本和渲染节点，确认未受影响镜头没有重生成 | 镜头时长或全局风格变更可能影响后续时间线，不能机械地只替换一个文件 |
| 长任务在超时或重启后丢失进度 | HTTP 只创建任务；执行交给持久化状态机，阶段产物和检查点外置保存 | 在提交、回调、下载、渲染等阶段分别杀死 Worker，核对状态迁移、检查点和最终产物 | 依赖工作流与活动代码满足确定性、幂等和版本兼容；外部副作用仍需单独对账 |
| 音画字幕由多个工具生成后难以同步 | 使用版本化 timeline.json 作为单一时间源，以最终配音重新计算镜头和字幕边界 | 保存 ffprobe JSON，检查各流 Time Base、PTS、duration；在首、中、尾及切镜点做自动与人工核验 | 口型、复杂音乐节拍和创意剪辑仍需要专用模型或人工导演判断 |
| 供应商切换会污染业务状态 | 在适配层归一化提交、查询、回调、下载、错误和成本，内部状态不复制供应商枚举 | 对每个适配器执行同一组合约测试，并用录制响应验证错误映射与回调乱序 | 适配层只能统一协议，不能抹平模型质量、合规、区域和参考图能力差异 |
| 自动质检难以覆盖发布责任 | 将技术质检、语义质检和人工审核拆成分级门禁，高风险问题不允许模型自行放行 | 用损坏媒体、错字幕、角色漂移、受限素材和误报样本执行回归，核对门禁与审计记录 | 低风险模板化内容更适合自动放行；品牌、真人、版权和事实敏感内容应保留人工责任人 |
8. 常见问题、根因与解决方案
8.1 生成质量与一致性
| 问题 | 现象 | 主要根因 | 解决方案 | 验证方式 |
|---|---|---|---|---|
| 人物一致性差 | 同一角色跨镜头脸型、服装或年龄变化 | 只靠文本描述；参考资产、模型和参数不固定 | 建立角色设定卡；锁定参考图和核心参数；关键镜头使用首帧或角色参考；短镜头生成 | 对人脸、服装和颜色做相似度检查，并逐镜人工审核 |
| 画风和镜头连续性差 | 色调跳变、物体瞬移、运镜突变或闪烁 | 镜头独立生成；没有统一视觉规范和衔接信息 | 建立 Style Bible；使用上一镜尾帧作为参考；限制主体位移和运镜；先做低清串片 | 检查镜头边界、主体位置和色彩变化，记录不通过镜头 |
| 结果偏离分镜 | 缺少关键人物、动作、道具或构图 | Prompt 冲突；单镜承载过多动作；分镜不可执行 | 按主体、动作、环境、镜头、风格和约束拆 Prompt；复杂动作拆镜；生成前静态校验 | 使用视觉模型比对关键要素，再按导演清单人工验收 |
| 时序伪影 | 手指、物体或背景在连续帧中变形 | 模型时序稳定性不足；镜头过长或动作过复杂 | 缩短镜头；降低动作复杂度；使用参考帧；失败区间单独重做 | 抽取关键帧和短 GIF，检查主体结构和运动连续性 |
| 已获授权但供应商仍拒绝 | 真人脸、肖像角色、版权角色或音乐在提交时被策略拒绝 | 把业务授权误当成供应商能力；能力矩阵过期 | 在付费调用前按供应商/模型/区域/版本执行能力门禁；给出可解释拒绝或路由到支持且合规的方案 | 对当前官方限制建立契约测试；策略版本变更后重新跑门禁用例 |
8.2 时间线、音频与字幕
| 问题 | 现象 | 主要根因 | 解决方案 | 验证方式 |
|---|---|---|---|---|
| 音画不同步 | 声音逐渐领先或落后，切镜点与配音错位 | 逻辑时间线换算错误；VFR/CFR 混用；音视频各自 PTS 未按所属 Time Base 正确缩放 | 统一逻辑时间轴和起始时间戳；视频规范化帧率、音频规范化采样率；分别重建/缩放各流 PTS，必要时转 CFR 和重采样 | 用 ffprobe 分别检查音视频 time_base、start_time、duration、帧率和采样率；首、中、尾三点人工核对 |
| 口型不匹配 | 嘴型滞后、停顿仍张嘴或多人串音 | 口型使用旧音频；说话人区间错误；缺少词级时间戳 | 以最终音频驱动 Lip Sync；按说话人分段；失败镜头单独重生成 | 重点检查句首、爆破音、停顿和说话人切换 |
| 字幕错位 | 字幕提前、滞后、重叠或跨句 | 按字数估时；最终音频变更后未重新对齐 | 使用 STT 或强制对齐生成时间戳；字幕绑定最终音频版本 | 校验时间段顺序和重叠，并逐句抽检 |
| 字幕乱码或越界 | 中文缺字、字体替换、竖屏被裁切 | FFmpeg 缺少 libass 或字体；未按画幅计算安全区 | 固定字体包和 FFmpeg 构建；使用 ASS；按画幅设置安全区和换行 | 对所有目标分辨率渲染截图，检查边界和缺字 |
| 配音被音乐淹没 | 人声不清、片段间响度突变 | 未做响度归一化和音乐 Ducking | 使用响度分析和 loudnorm；旁白区间压低音乐；限制 True Peak | 检查响度报告并在耳机、手机和扬声器试听 |
8.3 编码、合成与资源
| 问题 | 现象 | 主要根因 | 解决方案 | 验证方式 |
|---|---|---|---|---|
| 拼接失败或转场错位 | 分辨率不一致、接缝黑帧、音频短缺 | 片段参数和起始时间戳不同；直接拼接异构素材 | 合成前统一分辨率、帧率、Pixel Format、采样率并将片段时间戳归零 | 用 ffprobe 比较所有输入流；在每个接缝前后抽帧与试听 |
| 播放器不兼容 | 黑屏、有声无画、移动端失败或首帧慢 | Codec、Profile、Pixel Format 或容器不兼容 | 默认交付 MP4 + H.264 + yuv420p + AAC；启用 Fast Start；必要时转 CFR | ffprobe 检查流信息，并在目标浏览器和真机验证 |
| 黑帧或损坏帧 | 成片局部黑屏、花屏或无法解码 | 下载不完整；供应商文件损坏；渲染进程异常退出 | 下载后校验长度和哈希；完整解码检测；损坏资产禁止进入合成 | 对全部帧执行解码测试，并保留失败时间区间 |
| 渲染 OOM 或磁盘爆满 | Worker 被杀、临时文件堆积、任务反复失败 | 整片一次解码；并发过高；临时资产没有生命周期 | 分段渲染再合并；限制 Worker 并发；流式处理；为临时目录设置配额和清理策略 | 监控内存、磁盘和渲染峰值；故障注入后确认可恢复 |
8.4 异步任务、成本与安全
| 问题 | 现象 | 主要根因 | 解决方案 | 验证方式 |
|---|---|---|---|---|
| 任务长期卡住 | 一直处理中，回调未到或状态不再变化 | Webhook 丢失；无超时和看门狗；供应商状态未对账 | Webhook + 轮询兜底；阶段超时；看门狗扫描；可重试与终态分离 | 注入丢回调、服务重启和供应商超时，检查最终状态 |
| 重复生成或重复扣费 | 同一镜头产生多个任务，或账单有无法关联的重复项 | 重复提交/回调；供应商已受理但内部任务 ID 落库前崩溃 | 服务端业务意图唯一键；优先传供应商原生幂等 Token；SUBMISSION_UNKNOWN 禁止盲目重提；按 Client Key/任务列表对账；不支持查询时人工补偿 | 重放请求/回调并注入“受理后崩溃”；确认进入对账态；明确记录供应商不支持 exactly-once 时的残余风险 |
| 局部失败导致全片重跑 | 一个镜头失败后成本和时间成倍增加 | 任务粒度过大；中间产物不可复用；无依赖图 | 按镜头和阶段保存版本化产物；只失效失败节点和必要下游 | 人为使单镜失败，确认其他成功节点未再次调用模型 |
| 供应商下载地址失效 | 任务显示成功但成片资产丢失 | 把短期签名 URL 直接存为资产地址 | 完成事件后立即下载并转存对象存储；校验哈希后再标记资产就绪 | 缩短 URL 有效期测试，确认内部资产仍可访问 |
| 生成成本失控 | 高清反复重做、费用不可预测 | 没有预估、预算、缓存、重试上限和分级模型 | 生成前估算；低清确认后高清；镜头级成本；预算硬门禁；超限人工确认 | 汇总每阶段、镜头和供应商成本，验证超限会暂停 |
| 版权、肖像或供应商策略风险 | 素材、角色、音乐或声音无授权，或有授权但目标供应商不支持 | 授权链缺失；能力策略未版本化；发布前无硬门禁 | 分开校验业务授权、供应商能力与发布政策；保存来源、范围、有效期和策略版本；任一门禁失败都不提交/不发布 | 抽查授权链与策略版本；用受限人物、参考图、角色和音乐做调用前门禁测试 |
| 提示注入或越权 | 上传素材诱导 Agent 泄密或调用危险工具 | 外部内容被当成系统指令；工具权限过宽 | 内容与指令分离；工具白名单；最小权限；敏感信息脱敏；Webhook 验签 | 使用恶意 Prompt、伪造回调和越权工具做安全测试 |
8.5 推荐排查顺序
遇到“视频生成失败”时不要直接重跑整个任务，按以下顺序定位：
- 查内部
VideoJob、Shot和状态迁移，确认卡在哪个阶段； - 查
ProviderCall，区分未提交、排队、限流、供应商失败和下载失败； - 确认对象存储中的输入和输出资产真实存在、可读且哈希匹配；
- 用 ffprobe 检查容器、流、时长、帧率、时间基、分辨率和音频；
- 查
timeline.json的镜头入点、出点、依赖版本和字幕时间； - 查看渲染命令、标准错误、资源峰值和失败时间区间；
- 最后才判断是模型语义质量问题，并决定重写 Prompt、换参考图还是人工处理。
8.6 生产易发问题闭环
本文尚无真实线上事故记录，所以下表是面向实施和演练的故障闭环模板。表中的“证据”指故障发生时必须采集的材料，“验证”指修复后的验收动作，不能当作已经完成的实测结果。
| 现象 | 影响 | 证据 | 根因 | 止损 | 修复 | 验证 | 预防 |
|---|---|---|---|---|---|---|---|
| 任务长时间停在“生成中” | 用户无法交付，队列槽位和预算被持续占用 | VideoJob 状态年龄、最近状态事件、供应商任务状态、Webhook 验签日志、队列租约 | 回调丢失、Worker 租约过期后无人接管，或内部状态未与供应商对账 | 暂停该任务的新调用；轮询供应商现态；超过预算转人工处理，不直接重跑整片 | 增加阶段超时、看门狗、Webhook 与轮询兜底，并区分可重试、待对账和最终失败 | 注入丢回调、Worker 重启和乱序通知，确认任务进入唯一终态且进度可恢复 | 对状态年龄、无心跳任务和回调失败率告警；定期执行恢复演练 |
| 同一镜头出现多个供应商任务或重复账单 | 增加成本，多个结果竞争覆盖正确资产 | 业务意图键、供应商 Request/Task ID、调用时间线、账单明细、Outbox 与回调记录 | 提交结果不确定时盲目重试，或请求、回调未去重 | 冻结该镜头自动重试与发布；按稳定 Client Key 对账并选定唯一有效结果 | 落实唯一约束、幂等 Token、SUBMISSION_UNKNOWN 状态和补偿流程；提交与意图记录使用事务 Outbox | 重放相同请求、重复回调，并注入“供应商受理后进程崩溃”，核对调用次数与费用关联 | 监控一业务意图对应多个外部任务；将不支持查询/幂等的供应商标为高风险能力 |
| 低清预览正常，高清成片黑屏、越界或布局变化 | 审核结论失效，最终交付失败且高清渲染成本浪费 | 预览/高清时间线版本、字体与 FFmpeg 构建、渲染 stderr、失败帧、ffprobe 报告 | 两套渲染参数或资源不一致，高清阶段字体、显存、滤镜或安全区不同 | 阻断发布并保留已通过素材；只回退高清渲染节点，不重新生成合格镜头 | 让预览与高清共享时间线、字体包、布局算法和容器镜像，仅允许编码质量参数不同 | 对同一时间点做预览/高清截图差异检查，并在目标设备完成解码与安全区验收 | 将渲染镜像和模板版本写入产物元数据；升级前跑多画幅黄金样本 |
| 视频越到后面音画或字幕偏移越明显 | 旁白、切镜与字幕失配，成片不可用 | 音视频 time_base、PTS、start_time、duration、VFR/CFR、采样率及首中尾对点结果 | 各流按错误 Time Base 换算、反复浮点舍入，或最终音频变化后仍复用旧字幕 | 停止继续拼接；定位首次偏移时间点并隔离受影响时间线版本 | 使用整数时间单位和统一逻辑时间轴，分别重建各流 PTS；最终音频变更后强制重对齐字幕 | 用合成短片和长片覆盖帧率/采样率组合，校验累计误差并首中尾人工试听 | 对时间线计算做属性测试；合成前设置媒体规格门禁和版本依赖校验 |
| 供应商显示成功，但下载或后续渲染找不到素材 | 已付费结果丢失，任务无法恢复或被迫再次生成 | 外部 URL 过期时间、下载响应、对象存储事件、文件长度、哈希、资产状态迁移 | 把短期签名 URL 当成永久资产，或转存未完成就标记资产就绪 | 立即尝试在有效期内转存；禁止删除上游任务和盲目重新生成 | 成功回调后先下载、校验、转存，再以内部对象键原子标记 ASSET_READY | 缩短签名 URL 有效期并中断下载，确认可续传、可对账且半成品不会进入合成 | 监控“外部成功但内部未就绪”状态年龄；对象存储启用完整性与生命周期审计 |
| 技术检查通过但违规或错误内容被送入发布队列 | 产生事实、品牌、版权、肖像或平台治理风险 | 分镜与成片对照、VLM 判定、人工审核记录、授权链、策略版本、发布事件 | 把可播放等同于可发布，或能力/授权策略过期 | 立即冻结发布和分享链接，保全审计证据并通知审核责任人 | 将技术、语义、授权和平台策略拆成独立硬门禁；高风险项要求人工签署 | 用受限素材、事实错误、角色漂移和越权发布样本验证门禁无法被跳过 | 策略版本变更触发回归；发布服务只接受完整门禁凭证而非前端布尔值 |
8.7 可复用经验积累
| 可复用经验 | 适用信号 | 推荐做法 | 使用边界 |
|---|---|---|---|
| 把“不知道外部是否成功”建模为业务状态 | 超时或断线后无法判断供应商是否已受理 | 引入待对账状态，先查任务与账单，再决定继续、补偿或人工处理 | 不能因此宣称外部 exactly-once；供应商无查询能力时仍有残余风险 |
| 先画副作用边界，再设计重试 | 调用会计费、发布、发通知或覆盖资产 | 为每类副作用定义唯一键、重试主体、最大次数、补偿和责任人 | 纯计算任务可更积极重试，但也要防止资源雪崩 |
| 局部返工依赖“不可变产物 + 显式依赖” | 修改一点却不知道哪些下游必须重跑 | 资产按内容和版本寻址，时间线保存引用，失效沿依赖图传播 | 全局模板、时长或风格变化可能天然扩大失效范围 |
| 预览和正式交付是两个验收层级 | 低清审核通过但高清或真机失败 | 共享布局和时间线，分别验证语义质量与最终编码兼容 | 预览不能替代目标平台、目标设备和最终文件验收 |
| 排障从确定性层向概率性层推进 | 团队遇到失败就先改 Prompt 或换模型 | 先查状态、资产、协议、媒体参数和时间线，再分析模型语义质量 | 已有证据明确指向模型退化时，可直接进入模型回归与路由分析 |
| 合规策略也是版本化依赖 | 同一素材在供应商、区域或模型升级后表现不同 | 分开维护授权、供应商能力和发布政策，并把版本写入决策与审计 | 业务授权不能覆盖供应商硬限制，技术门禁也不能替代法务判断 |
9. 评测、监控与验收
9.1 质量指标
技术指标：
- 成片可解码率、目标平台播放通过率；
- 分辨率、画幅、帧率、总时长和文件大小合规率；
- 音画偏移、字幕重叠、黑帧、静音和响度检查结果；
- 预览和高清渲染成功率。
语义指标：
- 分镜关键要素覆盖率；
- 角色、品牌和场景一致性；
- 旁白、字幕和画面的一致性；
- 事实、安全和授权审核通过率；
- 人工返工镜头占比。
工程指标：
- 端到端时长及各阶段 P50/P95；
- 模型排队时间、生成时间、下载时间和渲染时间；
- 工作流成功率、可恢复失败率和最终失败率；
- 单视频、单分钟、单镜头和单供应商成本；
- 缓存命中率、平均重试次数和局部返工比例。
以上指标需要在真实项目中建立基线和目标值，本文不虚构阈值。
9.2 Trace、Metric 和 Log
- Trace：一次
job_id从 API、工作流、模型调用、下载、渲染到质检的全链路； - Metric：阶段耗时、成功率、并发、队列深度、错误类型和成本趋势；
- Log：状态迁移、外部请求摘要、ffprobe 结果、渲染错误和审核事件；
- Artifact：失败帧、波形、字幕截图、质检 JSON 和模型原始响应。
日志中不记录密钥、完整用户隐私数据或无脱敏的 Prompt；高基数 ID 用于 Trace 和日志检索，不直接作为无限制指标标签。
9.3 测试策略
- 单元测试：Schema、时间线计算、状态迁移、缓存键和成本计算；
- 合约测试：各模型适配器的提交、查询、回调、下载和错误归一化；
- 媒体测试：不同画幅、帧率、音频、字幕和损坏文件；
- 工作流测试：超时、重试、取消、服务重启、重复回调和乱序回调；
- 回归测试：固定脚本和参考素材，比较技术指标和语义评分；
- 安全测试：未授权素材、伪造 Webhook、Prompt 注入和越权工具调用；
- 人工验收：关键镜头、事实、品牌、版权和最终观看体验。
9.4 最小验收清单
- [ ] 可以创建任务并看到阶段和镜头级进度；
- [ ] 注入“业务事务已提交但 Workflow 未启动”，Outbox 扫描能以同一
workflow_id补偿启动且不产生重复工作流； - [ ] 服务重启后任务能够恢复或进入明确失败状态；
- [ ] 一个镜头失败时只重做该镜头及必要下游；
- [ ] 重复内部提交和回调只对应一个业务意图；注入“供应商受理后响应丢失”时进入
SUBMISSION_UNKNOWN/RECONCILING，不会盲目再次付费调用； - [ ] 成片通过 ffprobe、完整解码和目标播放器验证；
- [ ] 字幕、旁白、画面和总时长基本同步；
- [ ] 可以查看每个镜头的 Prompt、模型、成本、错误和版本；
- [ ] 未授权或审核未通过的内容不能发布；
- [ ] 质检失败能够定位到具体镜头、资产或时间范围；
- [ ] 最终交付包含成片、字幕、封面、清单和质检报告。
10. 分阶段实施计划
10.1 第一阶段：确定性视频合成
先不接视频生成模型，完成可验证的媒体底座：
- 固定脚本和人工准备素材；
- 设计
timeline.json； - 完成配音、字幕、背景音乐和 FFmpeg 合成；
- 使用 ffprobe 输出机器可读质检报告；
- 支持低清预览和高清成片。
验收重点：同一输入可以稳定得到可播放、时间线正确的输出。
10.2 第二阶段：AI 脚本与分镜
- LLM 输出结构化脚本和镜头清单；
- 加入 Schema 校验、事实标记和人工确认；
- 建立角色设定卡和视觉规范；
- 记录 Prompt 模板和脚本版本。
验收重点：错误输出会被校验或拦截，不会直接流入渲染。
10.3 第三阶段：异步素材生成
- 接入一个视频或图像供应商适配器；
- 实现提交、查询、Webhook、下载、超时和错误归一化；
- 以镜头为粒度并行生成；
- 转存临时结果并建立内容哈希；
- 展示阶段进度和镜头失败原因。
验收重点：服务重启、回调丢失和重复回调下状态仍然正确。
10.4 第四阶段：局部返工与质检
- 建立镜头依赖图和版本化中间产物；
- 加入技术质检、VLM 质检和人工门禁；
- 支持镜头级重生成和下游精确失效；
- 建立固定回归样本、成本统计和可观测链路。
验收重点：一次局部修改不会触发无关模型调用，且新版本可追溯。
10.5 第五阶段：生产化
- 供应商路由、限流、预算和降级；
- 多租户权限、审核、授权和数据保留；
- CPU、GPU、渲染 Worker 的资源隔离；
- 目标平台发布适配与发布后对账；
- SLO、容量评估、告警和故障演练。
验收重点：系统在并发、供应商故障和发布失败场景下可恢复、可解释。
11. 面试表达与递进追问
11.1 30 秒项目介绍
我设计的是一套 AI 视频生产工作流，不是单次模型调用。系统先用 LLM 生成结构化脚本和分镜，再以镜头为单位并行生成视频、配音和字幕，通过持久化工作流管理长任务、幂等和局部重试，最终用统一时间线、FFmpeg 和双层质检完成交付。核心设计目标是生成失败可恢复、局部问题不用全片重跑、成本和质量都有证据可追踪。
11.2 2～3 分钟回答结构
- 背景：AI 视频生成耗时长、结果不稳定、成本高，直接串 API 无法生产化；
- 粒度：把视频拆成镜头，以镜头作为生成、质检、缓存和返工单元；
- 流程：需求、脚本、分镜、资产、配音字幕、时间线、预览、质检、高清交付；
- 架构：API + 持久化工作流 + 模型适配器 + 对象存储 + FFmpeg Worker；
- 难点：幂等与回调对账、角色一致性、音画同步、编码兼容、局部失效；
- 验证：状态故障注入、ffprobe 技术检查、语义评测集、成本和人工返工指标；
- 演进：多供应商路由、自动质检、发布适配和容量治理。
11.3 高频递进追问
问题一：为什么不用 FastAPI BackgroundTasks？
回答要点：它适合进程内小任务，视频生成和渲染是重型、跨进程、长耗时工作；需要持久化、取消、超时、重试、恢复和分布式 Worker，因此应使用任务队列或持久化工作流。
问题二：为什么工作流重试仍会重复扣费？
回答要点：多数外部调用是至少一次语义，Worker 在供应商已受理但内部任务 ID 落库前崩溃时，单靠内部唯一键无法判断是否已扣费。优先把服务端业务意图作为供应商原生幂等 Token；结果不明确就进入 SUBMISSION_UNKNOWN/RECONCILING，按 Client Key 或供应商任务列表对账，禁止盲目重提。供应商既不支持幂等也不支持查询时只能人工对账/补偿，不能宣称 exactly-once。
问题三：如何做到只重做一个镜头？
回答要点：中间产物要版本化，时间线保存依赖图；修改镜头后只失效该镜头资产、预览和最终渲染，不失效其他镜头。若修改旁白导致全局时长变化，则需要重新对齐受影响的后续时间线。
问题四：音画不同步如何定位？
回答要点：先用 ffprobe 分别检查音频、视频流的 time_base、start_time、PTS、帧率/采样率和时长，再验证它们是否正确映射到同一逻辑时间轴；音频和视频的 Time Base 数值不必相同。随后检查 timeline 入点和出点，区分全局固定偏移、随时间累积漂移和单镜局部错位，三者根因不同。
问题五：如何评价生成视频质量？
回答要点：技术质量、语义质量和业务效果分开。技术质量可自动检测；语义质量使用固定分镜评测集、VLM 和人工评分；业务效果使用返工率、交付时间或实际业务指标。不能用几个精选 Demo 代表整体质量。
问题六：如何控制成本？
回答要点：生成前估算，低清预览后高清，镜头级缓存和局部返工，按任务设置预算和重试上限，根据镜头难度做模型路由，并把成本拆到镜头和供应商进行复盘。
问题七：如果并发扩大十倍，哪里先成为瓶颈？
回答要点：先观察供应商配额和排队，再看下载带宽、对象存储、CPU/GPU 渲染和临时磁盘；使用分阶段队列、背压、资源池隔离和容量指标，不能只扩 API 实例。
问题八：版权和安全如何设计成系统能力？
回答要点：授权不是备注字段，而是发布门禁；素材记录来源、用途、有效期和主体授权，模型输入输出走审核，所有发布与删除都有审计记录。同时把“业务已授权”和“供应商当前支持”分成两个门禁；例如目标供应商禁止真人脸输入时，即使取得同意也不能提交，应解释拒绝或选择其他合规方案。
12. 参考资料
以下资料在 2026-07-10 核对：
- OpenAI 视频生成指南：异步生成、轮询与 Webhook、结果下载、参考图和角色一致性能力；其中 Guardrails and restrictions 用于核对真人、肖像、版权角色和音乐限制；
- FFmpeg Filters Documentation：拼接、字幕、响度和其他音视频 Filter；其中
xfade用于核对 Crossfade 的重叠时长与输入规格约束； - ffprobe Documentation：媒体流探测和 JSON 输出；
- Temporal Documentation：可恢复的长任务和持久化执行；
- FastAPI Background Tasks：进程内后台任务及重型计算边界；
- Remotion Documentation：React 参数化视频、预览和渲染；
- OpenTelemetry Documentation：Trace、Metric、Log 与上下文关联。
13. 简明总结
一句话记忆： AI 视频生产系统的核心，是用镜头级、可恢复的工作流驯服不稳定的生成模型，再用统一时间线和双层质检保证交付。
- 工作流：需求 → 脚本 → 分镜 → 素材 → 配音字幕 → 合成 → 质检 → 局部返工 → 发布；
- 技术栈：FastAPI、Temporal、PostgreSQL、S3、模型适配层、FFmpeg/ffprobe、OpenTelemetry；
- 核心知识：生成式 AI、视频编码与时间戳、分布式任务、评测、成本和内容安全；
- 排障原则：先查状态与资产，再查媒体参数和时间线，最后才重做模型生成；
- 面试重点：镜头级拆分、幂等恢复、音画同步、局部重试和可验证质量。