www
8.2 KiB
那视频生成模型也是一样的道理，自己调用api 和网页版是由差距的？
是的，视频生成模型也是一样的道理：自己调用 API 和网页版/官方工作台，效果可能有明显差距。
原因不是“API 模型更差”，而是：
网页版/官方工作台通常不是只把你的提示词直接丢给模型。 它背后还有一整套产品层优化：提示词增强、参数补全、参考图处理、镜头约束、安全过滤、重试、候选筛选、后处理。
你自己调用 API，如果只是：
prompt → video API → result
效果通常会比网页版差一截。
一、网页版为什么看起来更好？
视频生成网页版一般会帮用户做很多隐藏工作。
1. 自动优化提示词
你输入：
白裙女仙释放法相天地
网页版可能内部扩写成：
cinematic fantasy scene, vertical 9:16, realistic CG, ancient Chinese xianxia goddess, white torn dress, consistent face, dramatic lighting, purple energy, slow camera push-in, debris flying, epic scale...
也就是说，它会帮你补：
角色描述； 镜头语言； 光影； 画风； 动作； 时长； 比例； 负面约束； 一致性要求。
API 如果你不自己做 Prompt Builder，就没有这层增强。
2. 自动选择参数
网页版可能会自动根据场景选择：
分辨率； 时长； 比例； 运动强度； 参考图权重； 镜头稳定性； 真实感增强； 风格模式； 人物一致性模式。
API 需要你自己传参数。 传错一个参数，效果就可能变差。
3. 自动处理参考图
图生视频时，网页版可能会对参考图做：
裁剪； 人脸检测； 主体识别； 背景分离； 清晰度增强； 安全检测； 角色区域锁定； 首帧优化。
自己 API 调用时，如果你只是把图片 URL 直接传过去，可能效果不稳定。
4. 自动做失败重试
网页版有时会偷偷做多次候选，选一个最好的展示给你。
API 如果你只生成一次，看到的就是一次抽卡结果。
所以你系统里要做：
同一分镜生成 2-4 个候选
↓
自动评分
↓
人工/系统选择最佳
↓
再进入合成
你当前架构已经支持“同一分镜用多个视频模型生成多个候选，并在合成前选择每个分镜最终候选片段”，这是正确方向。
5. 自动后处理
网页版可能还会做：
稳像； 补帧； 锐化； 去闪烁； 人脸修复； 音画对齐； 字幕排版； 转码压缩； 封面截取。
API 原始输出不一定包含这些。
你现在已有 FFmpeg 合成、标准化片段、裁剪/补齐、竖屏 720x1280、fps、字幕、BGM、SFX、音频混合等流程，这部分已经接近“自建网页版产品层”。
二、视频 API 要想接近网页版，必须自己补 7 层
你要把视频生成系统做成这样：
小说/剧本/分镜
↓
Prompt Builder
↓
Provider Router
↓
参数适配器
↓
参考图/角色资产处理
↓
多候选生成
↓
质量评分/人工选择
↓
FFmpeg 后处理
↓
成片
不是简单：
提示词 → API → 视频
三、你当前系统已经做对了哪些？
根据你上传的架构，你已经做了很多正确的东西：
- 有
AiRouterService，能按分镜自动选择普通/高价值路线、fallback、成本估算、预算限制； - 有
PromptBuilderService，已经能输出角色一致性、场景类型、镜头、灯光、VFX、负面词、唇形策略等； - 有角色库，区分“真人脸包”和“项目角色锚点图”；
- 有多个视频 Provider：豆包 Seedance、可灵、海螺、Sora、Mock；
- 有候选片段生成和选择；
- 有 FFmpeg 合成流程；
- 有 Provider 长任务轮询和恢复机制。
所以你的系统不是从零开始。 你现在要补的是“让 API 调用尽量接近网页版效果”的产品层细节。
四、自己调用 API 最容易差在哪里？
1. Prompt 太直接
比如你直接传：
女主在废墟中释放紫色法术
模型可能会乱。
应该传：
角色固定描述 + 场景 + 动作 + 镜头 + 情绪 + 光影 + 风格 + 时长 + 负面词
你现有 PromptBuilderService 已经开始做这个，但你文档里也写了，小说、故事圣经、角色抽取、分集、脚本、普通分镜等文本步骤还需要统一更严格的 schema、重试、验证和 Prompt 版本管理。这个要继续补。
2. 没有角色资产锁定
短剧最怕：
第一镜一个脸； 第二镜换脸； 第三镜衣服变了； 第四镜年龄变了。
所以必须有：
角色视觉档案
角色锚点图
角色状态变体
服装版本
参考图使用规则
负面提示词
你当前 Character Library 已经有 CharacterDesignVersion、CharacterState、ActorProfile，而且真人脸包和项目定妆已经拆开，这是对的。
3. 不同 Provider 参数不统一
豆包、可灵、海螺、Sora 的能力不一样。
有的支持 5 秒； 有的支持 10 秒； 有的支持首帧； 有的支持角色参考图； 有的对真人照片更敏感； 有的适合动作； 有的适合情绪对话。
所以你需要 Provider 能力矩阵。
你文档里也明确写了待优化点：需要显式配置 Provider 的时长、分辨率、首帧、尾帧、角色参考图、真人照片、多参考图、同步声音等能力。
这个必须做。
4. 没有多候选和评分
视频生成本质上有随机性。
同一提示词生成 1 次，可能一般； 生成 4 次，可能有 1 个很不错。
所以你的系统要支持：
每个分镜生成 N 个候选
↓
自动评分
↓
人工选择 / 自动选择
↓
进入合成
评分维度：
人物是否一致； 动作是否完成； 镜头是否稳定； 是否崩脸； 是否多手多脚； 是否符合分镜； 是否可用于成片。
五、你要不要用网页版？
我的建议：
测试模型上限时，用网页版
比如你想知道豆包、可灵、海螺某个模型“最高能做到什么效果”，可以用网页版测试。
因为网页版通常有更完整的产品优化。
批量生产时，用 API
你的目标是小说/听书/短剧自动化流水线，最终一定要 API。
因为网页版无法稳定做：
任务队列； 成本统计； 多模型 fallback； 批量分镜生成； 素材入库； 版本管理； 自动合成； 失败重试； 用户项目隔离。
六、正确策略：先用网页版反推 API 参数
你可以这样做：
1. 在网页版手动测试高质量效果
2. 记录输入提示词、参数、参考图、时长、比例
3. 分析它适合什么场景
4. 反推成你系统里的 Prompt Template
5. 写进 PromptBuilder
6. 用 API 批量验证
7. 不断调整 Provider Profile
比如你测试发现：
豆包 Seedance 2.0 适合电影感动作； 可灵适合图生视频和角色动作保持； 海螺 Fast 适合低成本对话镜头； Sora 适合高价值关键镜头。
那你的 Router 就可以这样分：
普通对白镜头 → 海螺 Fast / 豆包 Fast
情绪揭露镜头 → 豆包 Seedance 2.0
高价值动作镜头 → 可灵 / Sora
玄幻神通镜头 → 豆包 Seedance / 可灵
你当前 Router 已经有普通路线和高价值路线，这是正确框架。
七、最终答案
是的：
视频生成 API 和网页版也会有差距。
但差距不是因为 API 一定弱，而是网页版多了产品层优化。
你要做 API 系统，就要自己补：
Prompt Builder
Provider 能力矩阵
角色锚点图
参考图预处理
多候选生成
质量评分
失败重试
FFmpeg 后处理
成本路由
你的系统目前已经有一半以上基础，尤其是 Router、Prompt Builder、Character Library、LiveAction、FFmpeg、Provider Layer 都已经存在。下一步重点不是换模型，而是继续把 Provider 能力矩阵 + Prompt 调试面板 + 视频质量评分 + 多候选自动选择 做完整。
一句话：
网页版是“模型 + 官方产品优化”； API 是“裸模型能力 + 你自己的工程优化”。 你要想 API 接近网页版，就要把官方隐藏的产品层，在自己的系统里重建出来。