AI 视频工作流搭建笔记：从批量照片到分段视频与本地归档
这套项目最初用于生成“专家年轻时与现在跨越时空相遇”的系列短片，随后扩展成支持人物、商品多视图和参考生视频的网页工作台。核心流程是：
整理素材 → 设计分镜与提示词 → 按需生成多视图 → 上传参考图片 → 提交云端生成任务 → 跟踪状态 → 下载本地成片 → 提取尾帧衔接下一段 → 后期剪辑。
一、先把素材变成可追踪的资产
批量生产的第一步是建立稳定的编号和配对关系。
原会话中，Excel 最终整理为 27 组记录、54 张新老照片，采用：
01-姓名-young.jpeg
01-姓名-old.jpeg
表格中有重复姓名，因此应按“记录编号＋姓名”识别素材，不能仅按姓名合并。
当时的素材处理要求是单张小于 10MB、短边大于 400 像素。小图曾等比放大到短边 512 像素，大图进行压缩。
需要保留的经验是：图片处理完成后，要分别验证文件大小、像素尺寸和配对关系。放大图片可以满足上传尺寸要求，但不会恢复原图缺失的真实细节。
二、提示词要明确身份、空间、动作和结束状态
系列视频既要统一风格，也要保留每个人的差异。可以固定以下内容：
- 年轻人物与现在人物分别对应哪张参考图。
- 两人在画面中的左右位置、朝向和视线。
- 镜头景别、整体光线、画幅和情绪。
- 背景如何过渡，以及视频结束时人物处于什么状态。
场景和互动则根据照片调整。例如，背景从各自时代逐渐融合到年轻时的环境；互动可以选择拥抱、握手拍肩、共同读书等，每次只安排一组完整动作。
对于证件照和大头照，要明确它们主要提供身份特征，身体和场景需要合理补全。还要约束头身比、人物相对大小，避免直接照搬两张照片不同的拍摄尺度。
提示词表达的是生成目标，人物一致性、手部结构和动作自然度仍需观看成片验收。
三、分镜设计和视频动作描述分两步完成
项目已经沉淀了一份《提示词规范》，其中值得长期使用的方法是：
先设计分镜，确定每个镜头的目的、时长、景别、人物位置、首尾状态和转场；再补充镜头内的动作、表演和摄影机运动。
关键帧必须是一张能够静止截取的画面。例如“人物右手扶住书页，低头看书”是状态；“人物拿起书、翻页、转身”是一段过程，应放在动作描述中。
参考图也要明确职责：
- 人物图锁定面部、发型、肤色等身份特征。
- 商品图锁定颜色、花色、材质、结构和外观。
- 场景图控制环境与空间关系。
- 上一段尾帧提供下一段开场的连续性参考。
不要默认让人物参考图同时控制服装、背景、姿势和构图。准确文字、品牌口号和字幕优先在后期叠加。
四、长视频需要拆成可以独立执行的短段
原项目曾按每段最多 15 秒设计长视频方案。这个数值属于当时的生成规则，实际拆段应服从所选模型的时长限制。
每一段都要具备完整的素材说明、独立时间轴、动作过程和结束状态，不能只写“同上一段”。
正确的衔接流程是：
上一段生成完成 → 导出最后一个可用画面 → 将其作为下一段新增参考图 → 下一段从 0 秒开始描述动作。
例如，原来已有图1、图2，下一段可以新增：
图3为上一段尾帧，仅用于参考本段开场的人物姿态、构图、服装、道具和光线。
不要写“播放上一段第15秒”或“冻结上一段尾帧0.3秒”，因为下一次生成是独立请求，模型并没有自动获得上一段视频。
还要区分两种能力：把尾帧加入普通参考图，属于连续性引导；把图片传入模型专门的首帧字段，才属于首帧控制。两者不能等同，也都不能保证跨段完全一致。
五、多视图生成用于补充主体外观参考
当前多视图功能使用图文输入生成图片：
1—3 张人物或商品参考图＋文字描述 → 图像模型 → 一张包含多个视角的合成图。
当前代码支持选择 2、3、4 个视角，以及 qwen-image-3.0、qwen-image-3.0-pro、画幅和输出尺寸。
生成的多视图可以帮助后续视频理解主体外观，但背面、侧面等未被原始素材展示的内容仍可能由模型推测，不能当作真实结构证据。
多视图成图是否加入视频参考，应由使用者选择。还要说明合成图只是外观参考，避免视频直接生成分栏或多个重复主体。
六、本地图片需要先转成云端可访问的地址
当前项目的视频提交接口使用 HTTPS 素材地址。电脑上的文件路径和浏览器的 blob: 地址都不能直接供云端模型读取。
实际上传链路是：
浏览器选图 → 尺寸与体积处理 → /api/uploads → 临时媒体服务 → 返回 HTTPS 地址 → 提交模型。
这里有两个值得记录的排障经验。
第一个是上传超时。历史上，本地 Worker 的流式上传与媒体服务不兼容，后来改成带明确 Content-Length 的 multipart 请求。
第二个是 413 Payload Too Large。模型允许的图片大小，并不代表浏览器到模型之间的每一层代理都允许同样大小。当前网页把图片压缩目标设为约 800KiB，为上传请求留出空间。
排查时应分别检查浏览器、本地代理、上传接口、媒体服务和模型的限制，不能一遇到上传失败就归因于模型。
七、视频生成采用异步任务机制
网页提交后，模型通常先返回任务 ID，随后才完成生成。
项目将任务状态统一为：
PENDING → RUNNING → SUCCEEDED / FAILED
当前代码中，图片任务约每 5 秒查询一次，视频任务约每 8 秒查询一次；进入终态后停止正常轮询。
最重要的保存时机是拿到任务 ID 的时候。此时就应记录服务商、模型、提示词、参数、素材顺序和任务状态，不能等成片后才保存，否则刷新页面可能丢失任务入口。
项目还遇到过“云端任务已经成功，但流程阶段仍显示排队”的问题。这说明任务状态和流程阶段状态需要同步恢复，不能各自保留一套互相矛盾的结果。
八、任务索引与本地媒体文件共同构成历史记录
项目早期只保存任务信息和远程链接，后来改为将图片、视频自动保存到用户选定的本地文件夹。
主要结构包括：
happyhorse-studio-history.json：整个工作区的历史索引。HappyHorse任务/任务ID/任务记录.json：单个任务记录。- 任务下的图片、视频目录：实际生成文件。
本地目录访问使用浏览器文件系统能力，目录句柄通过 IndexedDB 保存；浏览器仍可能要求重新授权。
历史恢复时不能只相信总索引。旧版本曾出现文件已经存在、索引却缺少路径的情况，因此需要扫描任务目录并补回记录。
去重应优先使用任务 ID 等稳定标识。临时云端链接和本地 blob: 链接会变化，按 URL 去重曾导致同一张图片重复显示。
云端生成成功、本地下载成功、页面预览成功，也应视为三个独立结果分别判断。
九、临时链接用于交付，本地文件用于长期保留
云端返回的签名链接有有效期。历史记录里有链接，不代表之后始终能够播放或下载。
项目后来采用的体验是：成片可先在线播放，同时后台保存；本地保存成功后，再切换到本地文件播放。
刷新后重新读取文件、创建新的 blob: 地址，不应把旧 blob: 地址当作永久路径。
“复制尾帧”也优先读取本地视频，再截取接近结尾的可用画面，减少重复下载。这个方法适合衔接参考，但不等同于经过严格逐帧解码得到的最后编码帧。
十、多服务商接入要隔离协议、密钥和权益
项目使用 React、TypeScript 和 Vinext，后端接口与前端放在同一个工程中，实际图像与视频生成由云端模型完成。
百炼与 MiniMax 需要分别处理：
- API 地址与鉴权密钥。
- 模型和输入模式。
- 时长、清晰度、图片数量。
- 任务状态查询和结果下载。
- 账户额度与计费规则。
例如，当前 MiniMax 查询链路需要先取得 file_id，再换取下载地址；不能直接套用百炼的任务解析方式。任务历史也必须保存 provider，刷新后按原服务商查询。
当前源码中的 MiniMax 接入仍限制为：
MiniMax-Hailuo-2.3＋文生/单张首帧图生＋6秒＋768P
这是项目当前实现的限制。后来要求增加其他 MiniMax 模型、首尾帧和主体参考能力的会话，只提出了扩展方案，没有完成落地，不能记为已支持。
账户方面也要分清：Key 鉴权成功、模型可见、账户有额度、任务被受理、最终生成成功，是不同层次的证据。历史查询到的额度只代表当时状态，不能反推出套餐名称、购买价格或今天剩余的次数。
十一、密钥保护与验证方式也是工作流的一部分
当前项目已从早期前端密码门禁，升级为服务端登录验证：服务端保存密码哈希，登录后签发会话 Cookie，生成、上传、查询和下载接口检查登录状态。
服务商 Key 保存在服务端配置或密钥文件中；手动填写的 Key 仅用于当前页面会话，不写入任务历史。排障时只输出变量是否存在、HTTP 状态和脱敏错误，不直接打印密钥。
验证可以分层进行：
- 检查页面和参数校验。
- 检查鉴权、模型目录或额度查询。
- 模拟任务状态变化，验证刷新恢复、停止轮询和保存失败处理。
- 获得生成授权后，再提交真实视频并观看验收。
历史会话里曾在验证过程中真实提交测试视频，带来消耗额度的问题。这条经验应保留：测试网页交互和状态恢复时，优先使用模拟响应；真实生成需要明确计入测试成本。
当前工作流的准确描述
目前网页中的“全流程 AI 视频生成”保留两步：多视图生成和参考生视频。早期内置的在线分镜生成界面及接口已经移除。
因此，现阶段可以这样描述整套流程：
在工作台外完成分镜与提示词设计，在工作台内按需生成多视图、上传参考素材、分段生成视频、自动保存成片并复制尾帧，最后使用剪辑工具完成拼接、字幕、音乐和片头片尾。