root/ai

Fork 0

Files

T

www d9c81a3ac0 feat: expand novel IP and production workflows

2026-09-18 08:14:51 +02:00

12 KiB

Raw Blame History

目标肯定是把api优化到接入网页版，我最总要的是自动化流水下，人工，效率太低；网页版应该也是掉api的把，按官网的api文档参数传递参数，？

对，你的判断基本正确：

网页版本质上也是调用模型服务，但它不等于“公开 API 文档里那几个参数直接调用”。

更准确地说：

网页版 = 模型 API + 官方产品层优化 + 内部路由 + 隐藏参数/策略 + 后处理
你自己接 API = 公开 API + 你自己实现产品层优化

所以你的目标应该是：

把自己的 API 流水线做成“接近网页版体验”的产品层，而不是只照文档传 prompt。

一、网页版是不是也调 API？

大概率是。

但它调的可能是：

官方内部 API；
与公开 API 类似但参数更多的接口；
包含系统 prompt、路由、自动优化、重试、候选筛选的服务；
可能还带有前处理、后处理和质量筛选。

所以不能简单理解成：

网页版输入框内容 = API prompt
网页版生成按钮 = 公开 API 调用

真实情况更像：

用户输入
  ↓
官方前端
  ↓
提示词增强
  ↓
安全审核
  ↓
模型路由
  ↓
参数补全
  ↓
生成多个候选 / 重试
  ↓
质量过滤
  ↓
后处理
  ↓
展示结果

你自己接 API，就需要把中间这些层做出来。

二、按官网 API 文档传参数够不够？

能跑通，但不一定能跑出网页版效果。

官网 API 文档告诉你的是：

接口怎么调用
参数怎么传
返回值怎么解析
错误怎么处理

但通常不会完整告诉你：

网页版内部怎么改写 prompt
网页版怎么选模型
网页版怎么设置隐藏参数
网页版怎么做多候选
网页版怎么判断哪条结果最好
网页版怎么做图像预处理
网页版怎么做后期增强

就像你调用视频模型 API：

{
  "prompt": "一个女人在雨夜奔跑",
  "duration": 5,
  "ratio": "9:16"
}

可以生成视频。

但网页版可能内部实际会变成：

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...

还可能自动加：

参考图处理
镜头稳定约束
人物一致性约束
负面词
运动强度
光影风格
候选筛选
失败重试

所以文档参数是基础，产品层优化才决定最终效果。

三、你要做的不是“人工网页版”，而是“API 自动网页版”

你的目标很清楚：自动化流水线，人工太低效。

那你应该把网页版背后的逻辑拆成系统模块：

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 增强层

不要让用户原始输入直接进模型。

用户提示词 / 小说章节 / 分镜
  ↓
Prompt Builder
  ↓
模型专用 Prompt

你现在真人视频已有 live-action-prompt-engine-v2，能输出 scene type、camera、lighting、VFX、negative prompt、actor consistency rules 等，这个方向是对的。

但还要继续加强：

豆包专用模板
可灵专用模板
海螺专用模板
Sora 专用模板
图生视频模板
文生视频模板
真人短剧模板
玄幻大场面模板
对话镜头模板

2. Provider 能力矩阵

不同模型能力不一样，不能统一传同一组参数。

要记录：

支持时长
支持比例
支持分辨率
是否支持首帧
是否支持尾帧
是否支持角色参考图
是否支持多参考图
是否允许真人照片
是否支持同步声音
是否支持种子 seed
是否支持运动强度
失败率
平均耗时
平均成本
适合场景

你上传的架构文档里也明确把 Provider 能力矩阵列为待优化点，包括时长、分辨率、首帧、尾帧、角色参考图、真人照片、多参考图、同步声音等。

这层必须做。

3. 参数适配层

你不能写死：

duration=5
resolution=720p
ratio=9:16

应该由 Router 根据 Provider 能力自动转。

比如：

豆包支持 5s / 10s
可灵支持 5s / 10s，图生更稳
海螺 Fast 适合低成本对话
Sora 适合高价值镜头

同一个分镜，传给不同 Provider 的参数应该不一样。

4. 角色一致性层

短剧最重要的是角色不换脸。

你现在已经有：

GlobalCharacter
GlobalCharacterAsset
Character
CharacterImage
CharacterDesignVersion
CharacterState
ActorProfile

而且设计上区分了“真人脸包”和“项目内定妆锚点图”，这很正确。

下一步要强化：

角色视觉档案
角色锚点图优先级
服装状态变体
受伤状态变体
同一集角色锁定配置
每个镜头引用哪个角色版本

不要每个镜头重新描述一个角色。

5. 参考图预处理层

网页版通常会自动处理图。

你自己 API 要做：

裁剪主体
统一比例
增强清晰度
去水印/去杂乱边缘
人脸区域检测
生成角色锚点图
生成场景首帧
保存参考图版本

尤其是图生视频，首帧图质量决定一半结果。

6. 多候选生成层

不要一个分镜只生成一次。

建议：

普通镜头：1-2 个候选
重要镜头：3-4 个候选
关键爆点镜头：多 Provider 生成

你的现有架构已经支持“同一分镜可以用多个视频模型生成多个候选，合成前选择最终片段”，这个要保留并加强。

7. 自动质量评分层

每个候选视频要打分。

评分维度：

角色是否一致
是否崩脸
动作是否完成
镜头是否稳定
是否符合分镜
画面是否真实
是否多手多脚
是否有明显伪影
是否适合接入下一镜头
是否可用于成片

低分自动重试，高分进入候选池。

8. 失败重试 / Fallback 层

你现在 Router 已经有 fallback：

普通路线、高价值路线、成本检查、预算检查、Provider 跳过原因。

继续加强：

Provider 超时但外部 running → 继续轮询
Provider 失败 → 换备用模型
同模型失败 2 次 → 降级 prompt
动作太复杂失败 → 自动拆成两个镜头
时长不支持 → 自动拆段

9. 后处理层

API 原始视频不是成片。

你要做：

统一分辨率
统一帧率
统一色调
裁剪补齐
镜头拼接
字幕
配音
BGM
SFX
响度标准化
封面截图
转码

你当前 FFmpeg 已经做了标准化片段、竖屏 720x1280、fps、concat、音频混合、字幕、BGM、SFX、编码 fallback 等，这是非常正确的方向。

10. Prompt 调试面板

这是你后面提质最关键的后台工具。

每个分镜要能看到：

原始分镜
最终 Prompt
负面词
Provider
Provider 参数
参考图
Router 决策
跳过原因
成本估算
生成结果
评分
失败原因

你文档里也提到需要增加“Prompt 调试面板”，展示最终提交给 Provider 的完整参数、参考图、负面词、成本估算，方便测试。

这个必须做，越早做越好。

五、网页版效果怎么反推到 API？

你可以用一个“反推流程”。

第一步：网页版测试

同一个镜头在网页版测：

简单 prompt
详细 prompt
图生视频
不同参考图
不同时长
不同动作复杂度

记录：

输入词
生成效果
失败点
角色一致性
动作完成度
画面风格

第二步：总结模板

把好结果拆成模板：

角色描述模板
场景模板
动作模板
镜头模板
光影模板
负面词模板

第三步：写进 Prompt Builder

例如：

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 批量验证

同一分镜跑：

豆包
可灵
海螺
Sora

记录真实成本、耗时、成功率、质量评分。

第五步：更新 Router

最后把经验变成规则：

对话镜头 → 海螺 Fast
情绪特写 → 豆包 Seedance 2.0
动作镜头 → 可灵 / 豆包
玄幻大场面 → 豆包 / Sora
关键爆点 → 高价值路线
普通过渡 → 低成本路线

这样你的 API 系统会越来越接近甚至超过手工网页版效率。

六、官网 API 文档参数要怎么用？

你要分三层用。

第一层：硬参数

这些必须严格按文档：

model
prompt
image_url / reference_image
duration
aspect_ratio
resolution
callback_url
seed
watermark

第二层：业务参数

这是你系统自己的参数，不一定传给 Provider，但用于路由和控制：

scene_type
route_tier
importance_score
motion_intensity
emotion_intensity
character_consistency_required
cost_level
retry_policy
candidate_count

第三层：Prompt 组件参数

这些最终会被 Prompt Builder 合成 prompt：

character_identity
costume
location
main_action
camera_shot
camera_move
lighting
mood
visual_style
continuity_rules
negative_prompt

也就是说，后台不要只保存一个 prompt_text。

最好保存：

{
  "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 等，这个方向继续做。

七、你的最终方向是对的

你的目标不是：

人工去网页版一个个生成

而是：

用 API 复刻网页版背后的自动化产品层

最终应该是：

小说章节
  ↓
自动转剧本
  ↓
自动分镜
  ↓
自动角色锁定
  ↓
自动选 Provider
  ↓
自动构建 Prompt
  ↓
自动生成多候选
  ↓
自动质检
  ↓
自动选择 / 人工少量审核
  ↓
自动合成

人工只做：

选题
角色锚点确认
关键分镜审核
最终成片确认

不是每个镜头都人工调。

八、你现在最该补的三个功能

按优先级：

1. Provider 能力矩阵

这是 API 稳定性的地基。

不做这个，就会大量 Provider 报错、参数不匹配、生成失败。

2. Prompt 调试面板

没有这个，你不知道为什么某个镜头生成差。

3. 视频质量评分 / 多候选自动选择

没有这个，你只能人工看大量视频，效率会很低。

九、最终答案

是的，网页版大概率也是基于模型服务，但它不是简单调用公开 API 参数。

你的目标应该是：

用公开 API + 自己的 Prompt Builder + Router + 角色资产 + 多候选 + 质检 + 后处理，做出接近网页版甚至更适合批量生产的自动化系统。

按官网 API 文档传参数只是第一步。真正决定效果的是你自己的产品层。

一句话：

网页版强在“官方替你做了优化”； API 强在“你可以把优化变成自动化流水线”。你要做的，就是把网页版里的人工和隐藏优化，沉淀成自己的后台规则、Prompt 模板、Router 策略和质检系统。

12 KiB Raw Blame History Unescape Escape