ai/docs/chatgpt/novel/11.md

目标肯定是把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 策略和质检系统。**