目标肯定是把api优化到接入网页版，我最总要的是自动化流水下，人工，效率太低；网页版应该也是掉api的把，按官网的api文档参数传递参数，？ 对，你的判断基本正确： > **网页版本质上也是调用模型服务，但它不等于“公开 API 文档里那几个参数直接调用”。** 更准确地说： ```text 网页版 = 模型 API + 官方产品层优化 + 内部路由 + 隐藏参数/策略 + 后处理 你自己接 API = 公开 API + 你自己实现产品层优化 ``` 所以你的目标应该是： > **把自己的 API 流水线做成“接近网页版体验”的产品层，而不是只照文档传 prompt。** --- # 一、网页版是不是也调 API？ 大概率是。 但它调的可能是： 1. 官方内部 API； 2. 与公开 API 类似但参数更多的接口； 3. 包含系统 prompt、路由、自动优化、重试、候选筛选的服务； 4. 可能还带有前处理、后处理和质量筛选。 所以不能简单理解成： ```text 网页版输入框内容 = API prompt 网页版生成按钮 = 公开 API 调用 ``` 真实情况更像： ```text 用户输入 ↓ 官方前端 ↓ 提示词增强 ↓ 安全审核 ↓ 模型路由 ↓ 参数补全 ↓ 生成多个候选 / 重试 ↓ 质量过滤 ↓ 后处理 ↓ 展示结果 ``` 你自己接 API，就需要把中间这些层做出来。 --- # 二、按官网 API 文档传参数够不够？ **能跑通，但不一定能跑出网页版效果。** 官网 API 文档告诉你的是： ```text 接口怎么调用 参数怎么传 返回值怎么解析 错误怎么处理 ``` 但通常不会完整告诉你： ```text 网页版内部怎么改写 prompt 网页版怎么选模型 网页版怎么设置隐藏参数 网页版怎么做多候选 网页版怎么判断哪条结果最好 网页版怎么做图像预处理 网页版怎么做后期增强 ``` 就像你调用视频模型 API： ```json { "prompt": "一个女人在雨夜奔跑", "duration": 5, "ratio": "9:16" } ``` 可以生成视频。 但网页版可能内部实际会变成： ```text realistic cinematic vertical short drama, Chinese woman, rainy night street, wet asphalt reflections, handheld tracking shot, medium close-up, anxious but restrained expression, natural motion, dramatic lighting, no face distortion, no extra fingers, stable camera... ``` 还可能自动加： ```text 参考图处理 镜头稳定约束 人物一致性约束 负面词 运动强度 光影风格 候选筛选 失败重试 ``` 所以文档参数是基础，**产品层优化才决定最终效果**。 --- # 三、你要做的不是“人工网页版”，而是“API 自动网页版” 你的目标很清楚：自动化流水线，人工太低效。 那你应该把网页版背后的逻辑拆成系统模块： ```text Prompt Builder Provider Router Capability Matrix Context Builder Asset Preprocessor Candidate Generator Quality Evaluator Retry / Repair Post-processing Cost Controller ``` 你当前系统已经有不少基础：架构里已经有 `AiRouterService`、`PromptBuilderService`、`ProviderConfig`、`LiveActionModule`、`MediaModule`、`FFmpeg`、`RenderTask`、`BullMQ Worker`，而且视频侧已经支持 Provider fallback、成本估算、候选片段、人工选择和合成流程。 所以你现在不是从 0 做，而是要继续补齐“官方网页版隐藏的优化层”。 --- # 四、API 要接近网页版，需要做 10 层 ## 1. Prompt 增强层 不要让用户原始输入直接进模型。 ```text 用户提示词 / 小说章节 / 分镜 ↓ Prompt Builder ↓ 模型专用 Prompt ``` 你现在真人视频已有 `live-action-prompt-engine-v2`，能输出 scene type、camera、lighting、VFX、negative prompt、actor consistency rules 等，这个方向是对的。 但还要继续加强： ```text 豆包专用模板 可灵专用模板 海螺专用模板 Sora 专用模板 图生视频模板 文生视频模板 真人短剧模板 玄幻大场面模板 对话镜头模板 ``` --- ## 2. Provider 能力矩阵 不同模型能力不一样，不能统一传同一组参数。 要记录： ```text 支持时长 支持比例 支持分辨率 是否支持首帧 是否支持尾帧 是否支持角色参考图 是否支持多参考图 是否允许真人照片 是否支持同步声音 是否支持种子 seed 是否支持运动强度 失败率 平均耗时 平均成本 适合场景 ``` 你上传的架构文档里也明确把 Provider 能力矩阵列为待优化点，包括时长、分辨率、首帧、尾帧、角色参考图、真人照片、多参考图、同步声音等。 这层必须做。 --- ## 3. 参数适配层 你不能写死： ```text duration=5 resolution=720p ratio=9:16 ``` 应该由 Router 根据 Provider 能力自动转。 比如： ```text 豆包支持 5s / 10s 可灵支持 5s / 10s，图生更稳 海螺 Fast 适合低成本对话 Sora 适合高价值镜头 ``` 同一个分镜，传给不同 Provider 的参数应该不一样。 --- ## 4. 角色一致性层 短剧最重要的是角色不换脸。 你现在已经有： ```text GlobalCharacter GlobalCharacterAsset Character CharacterImage CharacterDesignVersion CharacterState ActorProfile ``` 而且设计上区分了“真人脸包”和“项目内定妆锚点图”，这很正确。 下一步要强化： ```text 角色视觉档案 角色锚点图优先级 服装状态变体 受伤状态变体 同一集角色锁定配置 每个镜头引用哪个角色版本 ``` 不要每个镜头重新描述一个角色。 --- ## 5. 参考图预处理层 网页版通常会自动处理图。 你自己 API 要做： ```text 裁剪主体 统一比例 增强清晰度 去水印/去杂乱边缘 人脸区域检测 生成角色锚点图 生成场景首帧 保存参考图版本 ``` 尤其是图生视频，首帧图质量决定一半结果。 --- ## 6. 多候选生成层 不要一个分镜只生成一次。 建议： ```text 普通镜头：1-2 个候选 重要镜头：3-4 个候选 关键爆点镜头：多 Provider 生成 ``` 你的现有架构已经支持“同一分镜可以用多个视频模型生成多个候选，合成前选择最终片段”，这个要保留并加强。 --- ## 7. 自动质量评分层 每个候选视频要打分。 评分维度： ```text 角色是否一致 是否崩脸 动作是否完成 镜头是否稳定 是否符合分镜 画面是否真实 是否多手多脚 是否有明显伪影 是否适合接入下一镜头 是否可用于成片 ``` 低分自动重试，高分进入候选池。 --- ## 8. 失败重试 / Fallback 层 你现在 Router 已经有 fallback： 普通路线、高价值路线、成本检查、预算检查、Provider 跳过原因。 继续加强： ```text Provider 超时但外部 running → 继续轮询 Provider 失败 → 换备用模型 同模型失败 2 次 → 降级 prompt 动作太复杂失败 → 自动拆成两个镜头 时长不支持 → 自动拆段 ``` --- ## 9. 后处理层 API 原始视频不是成片。 你要做： ```text 统一分辨率 统一帧率 统一色调 裁剪补齐 镜头拼接 字幕 配音 BGM SFX 响度标准化 封面截图 转码 ``` 你当前 FFmpeg 已经做了标准化片段、竖屏 720x1280、fps、concat、音频混合、字幕、BGM、SFX、编码 fallback 等，这是非常正确的方向。 --- ## 10. Prompt 调试面板 这是你后面提质最关键的后台工具。 每个分镜要能看到： ```text 原始分镜 最终 Prompt 负面词 Provider Provider 参数 参考图 Router 决策 跳过原因 成本估算 生成结果 评分 失败原因 ``` 你文档里也提到需要增加“Prompt 调试面板”，展示最终提交给 Provider 的完整参数、参考图、负面词、成本估算，方便测试。 这个必须做，越早做越好。 --- # 五、网页版效果怎么反推到 API？ 你可以用一个“反推流程”。 ## 第一步：网页版测试 同一个镜头在网页版测： ```text 简单 prompt 详细 prompt 图生视频 不同参考图 不同时长 不同动作复杂度 ``` 记录： ```text 输入词 生成效果 失败点 角色一致性 动作完成度 画面风格 ``` --- ## 第二步：总结模板 把好结果拆成模板： ```text 角色描述模板 场景模板 动作模板 镜头模板 光影模板 负面词模板 ``` --- ## 第三步：写进 Prompt Builder 例如： ```text xianxia_transformation_template realistic_dialog_template identity_reveal_template emotional_closeup_template action_chase_template ``` 你现有 Prompt Builder 已经有 `dialog`、`conflict`、`reveal`、`identity_reveal`、`xianxia_transformation`、`action` 等场景模板，可以继续扩展。 --- ## 第四步：API 批量验证 同一分镜跑： ```text 豆包 可灵 海螺 Sora ``` 记录真实成本、耗时、成功率、质量评分。 --- ## 第五步：更新 Router 最后把经验变成规则： ```text 对话镜头 → 海螺 Fast 情绪特写 → 豆包 Seedance 2.0 动作镜头 → 可灵 / 豆包 玄幻大场面 → 豆包 / Sora 关键爆点 → 高价值路线 普通过渡 → 低成本路线 ``` 这样你的 API 系统会越来越接近甚至超过手工网页版效率。 --- # 六、官网 API 文档参数要怎么用？ 你要分三层用。 ## 第一层：硬参数 这些必须严格按文档： ```text model prompt image_url / reference_image duration aspect_ratio resolution callback_url seed watermark ``` --- ## 第二层：业务参数 这是你系统自己的参数，不一定传给 Provider，但用于路由和控制： ```text scene_type route_tier importance_score motion_intensity emotion_intensity character_consistency_required cost_level retry_policy candidate_count ``` --- ## 第三层：Prompt 组件参数 这些最终会被 Prompt Builder 合成 prompt： ```text character_identity costume location main_action camera_shot camera_move lighting mood visual_style continuity_rules negative_prompt ``` 也就是说，后台不要只保存一个 `prompt_text`。 最好保存： ```json { "raw_prompt": "", "prompt_components": {}, "final_prompt": "", "negative_prompt": "", "provider_params": {}, "router_decision": {} } ``` 你文档里 Prompt Builder 已经输出 prompt components、negative prompt、director plan、motion director、lip sync policy 等，这个方向继续做。 --- # 七、你的最终方向是对的 你的目标不是： ```text 人工去网页版一个个生成 ``` 而是： ```text 用 API 复刻网页版背后的自动化产品层 ``` 最终应该是： ```text 小说章节 ↓ 自动转剧本 ↓ 自动分镜 ↓ 自动角色锁定 ↓ 自动选 Provider ↓ 自动构建 Prompt ↓ 自动生成多候选 ↓ 自动质检 ↓ 自动选择 / 人工少量审核 ↓ 自动合成 ``` 人工只做： ```text 选题 角色锚点确认 关键分镜审核 最终成片确认 ``` 不是每个镜头都人工调。 --- # 八、你现在最该补的三个功能 按优先级： ## 1. Provider 能力矩阵 这是 API 稳定性的地基。 不做这个，就会大量 Provider 报错、参数不匹配、生成失败。 --- ## 2. Prompt 调试面板 没有这个，你不知道为什么某个镜头生成差。 --- ## 3. 视频质量评分 / 多候选自动选择 没有这个，你只能人工看大量视频，效率会很低。 --- # 九、最终答案 是的，网页版大概率也是基于模型服务，但它不是简单调用公开 API 参数。 你的目标应该是： > **用公开 API + 自己的 Prompt Builder + Router + 角色资产 + 多候选 + 质检 + 后处理，做出接近网页版甚至更适合批量生产的自动化系统。** 按官网 API 文档传参数只是第一步。 真正决定效果的是你自己的产品层。 一句话： > **网页版强在“官方替你做了优化”； > API 强在“你可以把优化变成自动化流水线”。 > 你要做的，就是把网页版里的人工和隐藏优化，沉淀成自己的后台规则、Prompt 模板、Router 策略和质检系统。**