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