那视频生成模型也是一样的道理，自己调用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 接近网页版，就要把官方隐藏的产品层，在自己的系统里重建出来。**