feat(monitor): 抖音 Web 接口客户端 —— 绕开爬虫子进程，直接发 HTTP
移植自 mac-agent-os 的 mediacrawler_adapter：不起子进程、不开页面，用浏览器里那份
登录态直接调抖音 Web 接口。产物键名照抄 store/douyin，所以 ingest 那条链路一个字不用改。
**目前能用的（真环境实测，非推断）**：
profile/other : 200, 7075 字节 —— 博主主页指标（粉丝/获赞/作品数/昵称）
aweme/detail : 200, 45425 字节 —— 单条作品详情（含点赞/评论/收藏/分享）
**目前不能用的：作品列表 `aweme/post`。** 两个互相独立的原因：
1. 这个接口被抖音单独升级成了真校验：不带 x-tt-argus 回 403「Uifid Not Found」，
带上 dummy 值回 200 + **空 body**。也就是说「头在不在」骗得过，「真校验」过不了。
同一套头打 profile/other 和 aweme/detail 都是通的 —— 抖音是挑着接口加保护的，
挑中的恰好是「批量拉作品列表」这个最敏感的动作。
2. 改走页面截获也不行：CDP 浏览器打开博主主页会落到「验证码中间页」（当天大量探测的
代价，过几小时要重测）。
所以现在的边界是：**已知作品的指标刷新能做，自动发现新作品做不了**。
**排查中控住变量后得到的两条事实**（都写进注释了）：
· `Accept` / `Accept-Language` / `Referer` 才是主页接口能返回真数据的原因 —— 只有
UA+client hints+Cookie 时是 200 但仅 121 字节的空壳，补上这三个头变 7074 字节。
（我先前猜的 sec-ch-ua 不是关键。）
· 因此 UA 与 client hints 必须**成套地取自同一个浏览器**，所以 BrowserIdentity 一次
从 CDP 取齐 cookie + UA + hints，而不是各自写死。
「200 + 空 body 必须当场报错」也是刻意写死的：放过去它会在下游变成「这个博主没作品」，
把一次失败伪装成一条正常结果 —— 爬虫那条路正是这么栽的，还被翻译成「账号被封」。
测试 +11：cookie 解析、请求头成套性（含 uifid 缺失/回退）、产物键名与 store 对齐、
以及 _get 的三条失败路径（空 body / 403 带网关原话 / 正常返回）。
This commit is contained in:
@@ -0,0 +1,166 @@
|
||||
# 业界 AI 视频生产流程调研 —— 关键帧先行（Keyframe-First）
|
||||
|
||||
> 调研日期：2026-10-04
|
||||
> 调研人：codewhale（应 ghai 要求「全网搜一遍到底该怎么做」）
|
||||
> 触发问题：我们现在的「剧本 → 分镜 → 直接图生视频」是不是错的？是不是应该先做成连环画？
|
||||
|
||||
---
|
||||
|
||||
## 一、结论（先说答案）
|
||||
|
||||
**是的，业界主流就是「先做连环画，再让连环画动起来」。**
|
||||
|
||||
这个范式叫 **keyframe-first（关键帧先行）**：
|
||||
先把每个镜头该有的**静帧画面**生成好，再用图生视频（I2V）让它动。
|
||||
**不是**直接拿角色定妆照/场景空照去当视频首帧。
|
||||
|
||||
---
|
||||
|
||||
## 二、业界标准流水线
|
||||
|
||||
```
|
||||
① 故事创意 → 剧本（文字）
|
||||
② 剧本 → 分镜脚本（shot list：每镜头一行 —— 景别 / 角度 / 动作 / 台词）
|
||||
③ 分镜 → 【关键帧图】★ 每镜头先出一张静帧（这一环是成败关键）
|
||||
④ 关键帧图 → 图生视频（I2V，让静帧动起来）
|
||||
⑤ 片段 → 配音 + 音效 + 剪辑
|
||||
```
|
||||
|
||||
跨工具流水线（来源：`lanshu-awesome-ai-video-kit` methodology/20 §「为什么需要单独一篇」）：
|
||||
|
||||
```
|
||||
[基础图] [一致性扩展] [驱动] [声音 + 后期]
|
||||
MidJourney v6 ──┐
|
||||
Flux Dev/Kontext ┼─→ Nano Banana Pro ──→ Kling 2.6 / VEO 3 / ──→ ElevenLabs 配音
|
||||
GPT Image 2 │ (Character Sheet) Seedance 2.0 DaVinci Resolve
|
||||
Ideogram ┘ (Image-to-Video) (剪辑)
|
||||
```
|
||||
|
||||
同文档 §8「完整制作流水线」摘录：
|
||||
|
||||
```
|
||||
0. Mood Board 先行（情绪板定调）
|
||||
1. ChatGPT 优化 prompt（粗糙描述 → 精准 prompt）
|
||||
2. MJ / Flux 生成基础图（多次 Vary 选最佳面部）
|
||||
3. Nano Banana Pro 生成 Character Sheet（正脸/侧脸/半身/全身）
|
||||
4. Omni Reference 多图同时参考（Flux Kontext 支持 4 张）→ 扩展生活场景
|
||||
5. 图生视频（Kling / VEO / Seedance）
|
||||
6. 配音 + 剪辑
|
||||
```
|
||||
|
||||
── 注意第 3、4 步：**角色一致性靠「多角度角色卡」+「多图参考」**，
|
||||
关键帧生成阶段把「角色 + 场景 + 风格」一起喂进去。
|
||||
|
||||
---
|
||||
|
||||
## 三、角色一致性的 5 种主流技术
|
||||
|
||||
（来源：methodology/20 §1，整合 20 个 YouTube 教学，累计 5M+ 播放）
|
||||
|
||||
| # | 技术 | 做法 | 我们是否有 |
|
||||
|:--|:--|:--|:--|
|
||||
| 1 | **Character Sheet（角色卡）** | 多角度（正脸/侧脸/半身/全身）参考卡作统一锚点 | ✅ 已有（7 视角套装） |
|
||||
| 2 | **Omni Reference（多图同参）** | 同时输入 1~4 张参考图（角度/服装），生成新场景时综合保持 | ❌ 缺（接口已实现未调用） |
|
||||
| 3 | 3×3 角度网格 | 9 张角度合成 1 张，绕过人脸过滤 + 保一致 | ❌ 无 |
|
||||
| 4 | 平台内置角色锁 | OpenArt character lock 等 | ❌ 无 |
|
||||
| 5 | Face Swap | 跨场景换脸 | ❌ 无 |
|
||||
|
||||
---
|
||||
|
||||
## 四、我们的现状与差距
|
||||
|
||||
### 现状（代码 `composer/pipeline.py:_generate_shot`）
|
||||
|
||||
```python
|
||||
ref_image = self._resolve_reference_image(shot, storyboard) # 挑一张：角色图 或 场地图
|
||||
prompt = build_shot_prompt(shot, sb, has_ref_image=...) # 运动提示词
|
||||
client.generate_video(prompt, dest, image_path=ref_image) # 直接图生视频
|
||||
```
|
||||
|
||||
即：**把「角色定妆照」或「场景参考图」直接当成镜头首帧**。
|
||||
|
||||
### 差距
|
||||
|
||||
| | 我们 | 业界 |
|
||||
|:--|:--|:--|
|
||||
| 喂给视频模型的第一张图 | 角色定妆照（白底半身）**或** 场景空镜 | **这个镜头本该有的画面**（人+环境+构图都对） |
|
||||
| 模型要自己想象的 | 场景长什么样、人站哪、什么构图 | 只需让画面动起来 |
|
||||
| 后果 | 容易崩（拿不匹配的图去猜） | 稳 |
|
||||
|
||||
**这一个缺陷同时解释了三件事**：
|
||||
1. 为什么角色图和场景图**只能二选一**（没做关键帧合成）
|
||||
2. 为什么「全自动选图」感觉不靠谱（它是在错误的层面猜）
|
||||
3. 为什么人物大特写时场景用不上（本来就是二选一的取舍）
|
||||
|
||||
### 关键证据：这一环的代码**早已写好，但从未被调用**
|
||||
|
||||
`capabilities/kling_video.py:396`
|
||||
|
||||
```python
|
||||
def submit_multi_image2image(self, subject_images: list, prompt="",
|
||||
scene_image="", style_image="", ...):
|
||||
"""多图参考生图（POST /v1/images/multi-image2image）
|
||||
· subject_images: 1~4 张主体参考图
|
||||
· scene_image: 场景参考图 ← 官方把主体与场景【分开】传，互不污染
|
||||
· 合计至少 2 张 · ¥0.4/张 · 只支持 model=kling-v2-1
|
||||
"""
|
||||
```
|
||||
|
||||
全仓库搜索：**只有定义，零调用点**。
|
||||
另有 `agent-local/runtime/ave/拼图参考图测试/`（2026-10-04 实测产物 `grid_2x3.mp4` /
|
||||
`single_front.mp4`）说明曾做过相关验证（约 ¥6），但未接进流程。
|
||||
|
||||
---
|
||||
|
||||
## 五、建议的正确流程
|
||||
|
||||
```
|
||||
剧本 → 分镜（shot list）
|
||||
↓
|
||||
【新】关键帧合成（每镜头一张，¥0.4/张）
|
||||
角色参考图（1~4 张，来自 Character Sheet）
|
||||
+ 场景参考图（按机位选：top / side / wide …）
|
||||
+ 构图 / 光线提示词
|
||||
↓ multi-image2image
|
||||
这个镜头该有的画面（人 + 环境 + 构图都对）
|
||||
↓
|
||||
图生视频（kling，单图 + 运动提示词）
|
||||
↓
|
||||
片段 → 拼接 → 配音 → 成片
|
||||
```
|
||||
|
||||
**关键转变**：
|
||||
1. 角色图与场景图**不再二选一** —— 在**关键帧生成**阶段同时使用
|
||||
2. 图生视频仍只吃一张图，但那张图已经是「对的画面」
|
||||
3. **关键帧比视频便宜得多**（¥0.4 vs ¥3+）→ 可以「先出图给用户审，通过再生视频」，
|
||||
既是正确节奏，也能显著省钱
|
||||
|
||||
**成本**：4 镜头短片多花约 **¥1.6**（关键帧）。
|
||||
|
||||
---
|
||||
|
||||
## 六、其他值得接入但尚未使用的能力
|
||||
|
||||
| 能力 | 说明 | 状态 |
|
||||
|:--|:--|:--|
|
||||
| Kling **Elements / Bind** | 把角色注册为身份，跨镜头引用（比传参考图更稳） | 未接入，`capabilities.yaml` 未登记 |
|
||||
| Kling **Multi-Shot** | 一次生成多镜头（社区实测 6 shots / 15s） | 未接入 |
|
||||
| **3×3 网格法** | 角色九宫格，绕过人脸过滤 | 未接入（我们用的是分开生成的 7 视角套装） |
|
||||
|
||||
---
|
||||
|
||||
## 七、来源清单
|
||||
|
||||
- `cclank/lanshu-awesome-ai-video-kit`（MIT，21 篇 SOP / 543 条实测 prompt / 15 模型）
|
||||
- `methodology/20-realistic-character-consistency.md` ← **主要引用**
|
||||
- `methodology/README.md`（全库索引与阅读顺序）
|
||||
- `methodology/03-分镜时序.md`（复杂剧情拆成镜头1/2/3）
|
||||
- `methodology/18-kling-masterclass.md`（Elements / Bind / Multi-Shot / 3×3 网格）
|
||||
- `skills/seedance-storyboard/SKILL.md`（剧情 → 分镜）
|
||||
- `Healer-AI/SceneSequencer`（关键帧规划 agent：环境一致性 + 摄影机语言）
|
||||
- `Eman11shahbaz2/Affective-Audiovisual-Storyboard`（文本 → 分镜 → 关键帧 → 配音 → animatic）
|
||||
- `MarkiiBee/Dream-Weave-Studio`（角色一致性 3 步管线：refinement → style → animation）
|
||||
|
||||
> 检索通道备注：本机 `web_search`（Tavily）不可用；`raw.githubusercontent.com` /
|
||||
> `api.github.com` 可用（**有间歇性失败，重试即可**）；`curl` 直连与系统代理均不通，
|
||||
> 必须走 `fetch_url` 工具。
|
||||
@@ -0,0 +1,143 @@
|
||||
# 「关键帧合成」设计方案（待评审）
|
||||
|
||||
> 日期：2026-10-04 · 状态：**待 ghai 拍板**
|
||||
> 目标：补上业界标准的 keyframe-first 环节，解决「角色/场景二选一」与一致性反复崩的问题。
|
||||
> 前置阅读：`00_业界生产流程_关键帧先行.md`
|
||||
|
||||
---
|
||||
|
||||
## 一、要解决什么
|
||||
|
||||
当前 `pipeline._generate_shot` 把「角色定妆照」**或**「场景参考图」直接当视频首帧，
|
||||
模型必须自己想象场景/构图 → 容易崩，且两者不能兼得。
|
||||
|
||||
**目标**：在分镜与生成视频之间，插入「关键帧合成」——先出一张
|
||||
**「角色 + 场景 + 构图」都对**的静帧，再用它去图生视频。
|
||||
|
||||
---
|
||||
|
||||
## 二、流程改造（插入点）
|
||||
|
||||
```
|
||||
现在：分镜 → [挑一张参考图] → 图生视频 → 去AI化 → 拼接 → 混流
|
||||
|
||||
改后：分镜 → 【关键帧合成】→ 图生视频 → 去AI化 → 拼接 → 混流
|
||||
↑ 新增，每镜头一张
|
||||
```
|
||||
|
||||
插入位置：`composer/pipeline.py::render()`，在 `audio_first` 之后、逐镜头生成之前
|
||||
（约 224 行之后、306 行并发段之前）。
|
||||
|
||||
---
|
||||
|
||||
## 三、代码改动清单
|
||||
|
||||
### 1. 新增 `composer/keyframe.py`（核心）
|
||||
|
||||
```python
|
||||
def build_keyframe(shot, sb, work_dir) -> str:
|
||||
"""为单个镜头合成关键帧（多图参考生图）
|
||||
|
||||
输入组合（按可用性自动裁剪）：
|
||||
· subject_images: 角色参考图 1~4 张（来自 Character Sheet 套装：
|
||||
优先 front_half / side_45 / face_closeup）
|
||||
· scene_image: 场景参考图 1 张（按 shot_contract 机位选 wide/top/side…，
|
||||
复用现有 _resolve_location_ref）
|
||||
· prompt: 构图/光线描述（复用 build_shot_prompt 的**视觉部分**，
|
||||
不含"运动"描述 —— 运动属于视频阶段）
|
||||
输出：work_dir/keyframes/{shot_id}.png
|
||||
成本：¥0.4/张
|
||||
"""
|
||||
```
|
||||
|
||||
约束（实测已知，见 `kling_video.py:410-414`）：
|
||||
- 只支持 `model=kling-v2-1`（v3 报 not supported）
|
||||
- 主体 + 场景 + 风格**合计至少 2 张**
|
||||
- 并发按 `n` 计
|
||||
|
||||
### 2. 改 `pipeline._generate_shot`
|
||||
|
||||
```python
|
||||
# 新增开关 keyframe_first（默认 False，渐进启用）
|
||||
_kf = work_dir / "keyframes" / f"{shot.shot_id}.png"
|
||||
if keyframe_first and _kf.exists():
|
||||
image_path = str(_kf) # ★ 优先用关键帧当首帧
|
||||
elif keyframe_first:
|
||||
_kf = build_keyframe(shot, sb, work_dir) # 合成一张
|
||||
image_path = _kf
|
||||
else:
|
||||
image_path = self._resolve_reference_image(shot, sb) # 原逻辑（回退）
|
||||
```
|
||||
|
||||
**关键**：关键帧存在即复用（续跑友好），失败自动回退到原逻辑 —— 不阻塞出片。
|
||||
|
||||
### 3. `render()` 新增参数
|
||||
|
||||
```python
|
||||
def render(self, sb, output_path, ..., keyframe_first: bool = False,
|
||||
keyframe_only: bool = False): # ← 只出关键帧、不生成视频
|
||||
```
|
||||
|
||||
`keyframe_only=True` → 走完关键帧合成就返回，供前端「先审后生」。
|
||||
|
||||
### 4. 新增接口（`routes/ave.py`）
|
||||
|
||||
| 接口 | 用途 |
|
||||
|:--|:--|
|
||||
| `POST /storyboard/keyframe/{job_id}` | 只生成关键帧（需 `confirm_cost`） |
|
||||
| `GET /storyboard/keyframes/{job_id}` | 列出已生成的关键帧（供预览） |
|
||||
|
||||
沿用现有 `confirm_cost` 硬拦截（费用防护不例外）。
|
||||
|
||||
---
|
||||
|
||||
## 四、UI 设计：把「先审后生」变成默认节奏
|
||||
|
||||
```
|
||||
导演台 → 🎬 生成分镜 → 【新】🖼 生成关键帧（¥0.4/镜头）
|
||||
↓
|
||||
逐张预览关键帧（可单张重做 / 换机位 / 改提示词）
|
||||
↓
|
||||
满意后 → ▶ 生成视频（复用已通过的关键帧）
|
||||
```
|
||||
|
||||
好处（这是省钱的关键）：
|
||||
- 关键帧 **¥0.4**，视频 **¥3+** —— 先花小钱把画面定死，避免整条视频跑完才发现构图错
|
||||
- 关键帧是静帧，人能一眼判断"像不像 / 对不对"，视频不行
|
||||
|
||||
---
|
||||
|
||||
## 五、成本与风险
|
||||
|
||||
**成本**：每镜头 +¥0.4（关键帧）。4 镜头短片 +¥1.6。
|
||||
|
||||
**风险**：
|
||||
1. **只能用 `kling-v2-1`** —— 图像质量可能与 v3 有差异，需实测比对
|
||||
2. **合成图可能有拼接痕迹** —— 多图参考的本质是"融合"，主体与场景交界处需抽检
|
||||
3. **多一道生成 = 多一个失败点** —— 已设计「失败自动回退到原单图逻辑」，不阻塞出片
|
||||
4. **提示词要拆** —— 关键帧需要"视觉描述"，视频需要"运动描述"。
|
||||
现有 `build_shot_prompt` 已按 `has_ref_image` 分支（图生视频只写动作），
|
||||
可以复用为两个出口，但需要确认拆分后两边都不缺信息
|
||||
|
||||
---
|
||||
|
||||
## 六、实施步骤（建议分三步，每步可停）
|
||||
|
||||
| 步 | 内容 | 费用 | 产出 |
|
||||
|:--|:--|:--|:--|
|
||||
| **S1** | 写 `keyframe.py` + `keyframe_only` 通路 + 接口；**不接入默认渲染** | ¥0 | 可单独调用，零风险 |
|
||||
| **S2** | **跑 1 个镜头**端到端验证：关键帧 → 视频，人工比对 | ≈¥3.4 | 决定是否继续 |
|
||||
| **S3** | 接入 `render()` 开关 + 前端「先审后生」UI | ¥0 | 全流程可用 |
|
||||
|
||||
**S2 的验证点**（必须人工看，我看不了图）：
|
||||
1. 关键帧里**人和场景是否都正确**（人物像不像？环境对不对？）
|
||||
2. 关键帧 → 视频后**人物是否保持**（有无换脸/漂移）
|
||||
3. 与"直接用定妆照当首帧"的老做法**对比**，哪个更好
|
||||
|
||||
---
|
||||
|
||||
## 七、待确认
|
||||
|
||||
1. 是否按 S1→S2→S3 推进？（S1/S3 零费用，S2 约 ¥3.4）
|
||||
2. 关键帧提示词用哪一套？（建议：复用现有 `build_shot_prompt` 的视觉部分）
|
||||
3. 前端「先审后生」放在导演台出片区，还是独立一步？（建议：出片区加一个"生成关键帧"按钮）
|
||||
@@ -0,0 +1,161 @@
|
||||
# 百炼（阿里云）可用能力与价格实测
|
||||
|
||||
> 数据来源：`GET https://dashscope.aliyuncs.com/api/v1/models`（实测拉取 **519 个模型**，含 `prices` 字段）
|
||||
> 日期：2026-10-04 · 用法：`Authorization: Bearer <aliyun.api_key>`（我们**已有**该 key）
|
||||
> ⚠️ **本文数据来自模型清单，尚未实际调用验证**（是否需要单独开通、接口字段格式待确认）
|
||||
|
||||
---
|
||||
|
||||
## 一、为什么重要
|
||||
|
||||
我们此前只用**可灵**，得出「图生视频只能吃一张参考图」的结论。
|
||||
百炼平台上存在 **R2V（Reference-to-Video）** 系列：**多图/多视频混合参考直接生视频**，
|
||||
以及 **KF2V（首尾帧）**、**VideoEdit（视频编辑替换元素）**、**Image-Edit（图像编辑）**。
|
||||
|
||||
**这直接覆盖了此前判定为「缺失」的一整层能力。**
|
||||
|
||||
---
|
||||
|
||||
## 二、图像类（关键帧 / 编辑）
|
||||
|
||||
| 模型 | 价格 | 输入模态 | 说明 |
|
||||
|:--|:--|:--|:--|
|
||||
| `wan2.7-image` | **¥0.2/张** | Image, Text | 文生图 / 图像编辑 / **多图参考生成** / 交互式编辑 |
|
||||
| `wan2.7-image-pro` | ¥0.5/张 | Image, Text | 同上旗舰版 |
|
||||
| `wan2.6-image` | **¥0.2/张** | Text, Image | **多图创意融合**、商用级一致性 |
|
||||
| `qwen-image-edit-plus` | **¥0.2/张** | Image | 指令式图像编辑（Plus） |
|
||||
| `qwen-image-edit` | ¥0.3/张 | Text, Image | 指令式图像编辑（基础） |
|
||||
| `wan2.5-i2i-preview` | **¥0.2/张** | Text, Image | 指令控制图像编辑（重绘向） |
|
||||
|
||||
## 三、视频类（生成 / 参考 / 首尾帧）
|
||||
|
||||
| 模型 | 价格 | 输入模态 | 说明 |
|
||||
|:--|:--|:--|:--|
|
||||
| **`wan2.7-r2v`** | ¥0.6/秒(720P) | **Audio, Image, Text, Video** | **最大 5 个图/视频混合参考** + 音频音色参考 |
|
||||
| `wan2.6-r2v` | ¥0.6/秒(720P) | Image, Video, Text | 多角色参考合拍、形象+声音一致 |
|
||||
| **`wan2.6-r2v-flash`** | **¥0.3/秒(720P)** | Image, Video, Text | 参考生视频（快）—— **比可灵便宜一半** |
|
||||
| **`wan2.2-kf2v-flash`** | **¥0.1/秒(480P)** | Image, Text | **首尾帧生视频**（超便宜） |
|
||||
| `wanx2.1-kf2v-plus` | ¥0.7/秒 | Image | 首尾帧-Plus |
|
||||
| `pixverse/pixverse-c1-r2v` | ¥0.24/秒(360P) | Image, Text | 多主体参考（**2-7 张**图像） |
|
||||
| **`wan2.7-videoedit`** | ¥0.6/秒(720P) | Image, Text, Video | **自然语言指令编辑视频；可参考图像替换视频元素** |
|
||||
| `happyhorse-1.0-video-edit` | ¥0.9/秒(720P) | Text, Image, Video | 视频编辑，**可参考最多 5 张图片** |
|
||||
|
||||
> 对比：可灵 `kling-v3` 720P = **¥0.6/秒**。
|
||||
|
||||
---
|
||||
|
||||
## 四、成本对照（4 镜头 × 5 秒短片）
|
||||
|
||||
| 方案 | 计算 | 合计 |
|
||||
|:--|:--|:--|
|
||||
| 现在（可灵直接图生视频） | 4×5×¥0.6 | **¥12** |
|
||||
| 路径 A：关键帧 + 首尾帧生视频 | 4×¥0.2(关键帧) + 4×5×¥0.1(kf2v 480P) | **¥2.8** |
|
||||
| 路径 A'：关键帧 + r2v-flash 720P | 4×¥0.2 + 4×5×¥0.3 | **¥6.8** |
|
||||
| 路径 B：多图参考直接生视频（r2v-flash） | 4×5×¥0.3 | **¥6** |
|
||||
|
||||
---
|
||||
|
||||
## 五、两条可选路径
|
||||
|
||||
### 路径 A：关键帧先行（推荐）
|
||||
```
|
||||
分镜 → wan2.7-image 合成关键帧（角色图 + 场景图 + 构图提示词）→ 用户审图
|
||||
→ wan2.2-kf2v-flash 首尾帧生视频（或 wan2.6-r2v-flash 单图生视频）
|
||||
```
|
||||
优点：**可审、可退、可单格重做**；关键帧便宜（¥0.2）而视频贵，先审后生最省钱。
|
||||
|
||||
### 路径 B：多图参考直接生视频
|
||||
```
|
||||
分镜 → wan2.6-r2v-flash（角色图多张 + 场景图，一次喂进去）→ 直接出视频
|
||||
```
|
||||
优点：步骤少；缺点：不能预先审，出问题要整条重跑。
|
||||
|
||||
---
|
||||
|
||||
## 六、实测验证结果（2026-10-04 追加）
|
||||
|
||||
### ✅ 已验证（真实调用接口）
|
||||
|
||||
1. **四个端点全部存在**（用非法 model 名探测，返回 `Model not exist` 而非 404）：
|
||||
- `video-generation/video-synthesis`
|
||||
- `multimodal-generation/generation`
|
||||
- `image2image/image-synthesis`
|
||||
- `text2image/image-synthesis`
|
||||
|
||||
2. **图像端三个模型可用，且无需单独开通**（返回参数错误而非"模型不存在"）：
|
||||
- `qwen-image-edit-plus` / `qwen-image-edit` / `wan2.7-image`
|
||||
|
||||
3. **字段结构（已摸清）**：
|
||||
```
|
||||
input.messages[0].content[] ← 数组，元素为：
|
||||
{"text": "..."} ← 文本指令
|
||||
{"image": "<URL>"} ← 参考图（必须可直接下载）
|
||||
```
|
||||
校验层级（从错误信息逐层探得）：
|
||||
`Field required: input.messages.0.content` → `content list cannot be empty`
|
||||
→ `Failed to download image from [not-a-url]: not-a-url`
|
||||
|
||||
### ⚠️ 操作事故（如实记录）
|
||||
|
||||
探测第 ③ 步发了 `{"model":"wan2.7-image","input":{"messages":[{"role":"user","content":[{"text":"x"}]}]}}`
|
||||
—— **这其实是合法的文生图请求**（不是"参数不完整"），
|
||||
结果 **HTTP 200 返回了真实生成的图片 URL，花费约 ¥0.2**。
|
||||
|
||||
**教训：「参数不完整」必须是真正的不完整**（如 content 为空数组 / 缺必填字段）。
|
||||
写一个 1 个字符的 prompt 仍然会**真的生成**。
|
||||
今后探测一律用**结构性缺失**或**明显非法值**（非法 model 名 / 非法 URL / 空数组）。
|
||||
|
||||
### ⏳ 尚未验证
|
||||
|
||||
- 视频端三个模型（`wan2.6-r2v-flash` / `wan2.2-kf2v-flash` / `wan2.7-videoedit`）的参数与可用性
|
||||
- 原因：视频端点存在「空参数也会创建任务」的历史（需手动 cancel），
|
||||
在没有可靠的非破坏性探测句式前不冒险
|
||||
- 建议路径：查官方文档 → 照文档写代码 → 或批准一次**最短时长的真实测试**（约 ¥0.3~0.6）
|
||||
|
||||
---
|
||||
|
||||
## 七、附录：百炼视频接口调用范式（从现有代码提取，可直接复用）
|
||||
|
||||
> 来源：`material_producer/wan2_2/wan2_2.py`（`wan2.2-s2v` 数字人，已在用）
|
||||
> 这四步范式对 R2V / KF2V / VideoEdit **同样适用**，只需替换 `input` 字段。
|
||||
|
||||
```
|
||||
① 上传文件 → oss:// URL
|
||||
GET /api/v1/uploads?action=getPolicy&model=<model> （拿 OSS 凭证）
|
||||
POST {upload_host} （multipart 直传）
|
||||
→ oss://<upload_dir>/<filename>
|
||||
|
||||
② 提交任务（异步）
|
||||
POST /api/v1/services/aigc/image2video/video-synthesis
|
||||
headers: Authorization: Bearer <key>
|
||||
X-DashScope-Async: enable ← 异步必须
|
||||
X-DashScope-OssResourceResolve: enable ← 用 oss:// 时必须
|
||||
body: {"model": ..., "input": {...}, "parameters": {"resolution": "480P"}}
|
||||
→ output.task_id
|
||||
|
||||
③ 轮询
|
||||
GET /api/v1/tasks/{task_id}
|
||||
→ output.task_status == "SUCCEEDED" → output.results.video_url
|
||||
|
||||
④ 下载 video_url → 本地
|
||||
```
|
||||
|
||||
**各模型待确认的 `input` 字段**（这是唯一还没定的部分）：
|
||||
|
||||
| 模型 | 推测字段 | 状态 |
|
||||
|:--|:--|:--|
|
||||
| `wan2.6-r2v-flash` | `prompt` + `reference_images[]`（或 `subject_images`） | ⏳ 待确认 |
|
||||
| `wan2.2-kf2v-flash` | `first_frame_url` + `last_frame_url` + `prompt` | ⏳ 待确认 |
|
||||
| `wan2.7-videoedit` | `prompt` + `video_url` + `reference_images[]` | ⏳ 待确认 |
|
||||
|
||||
确认方式建议：**批准一次最短时长的真实测试**（1 秒 / 480P，约 ¥0.2~0.3），
|
||||
一次即可拿到确切字段与返回结构，比反复试探安全。
|
||||
|
||||
---
|
||||
|
||||
## 八、结论
|
||||
|
||||
- 用户提出的「多图参考」「从别人的视频替换成我的角色/场景」「图像编辑/风格化」**在百炼上都有对应模型**
|
||||
- 且价格**普遍低于可灵**（r2v-flash ¥0.3/秒 vs 可灵 ¥0.6/秒）
|
||||
- 我们**已有 key**，无需新增账号
|
||||
- 下一步：零费用字段探测 → 单镜头实测验证效果 → 接进流水线
|
||||
@@ -0,0 +1,184 @@
|
||||
# 千问AI平台 · 视频/图像能力 OpenAPI 字段规格（实测抓取）
|
||||
|
||||
> 来源：`https://platform.qianwenai.com/docs/llms.txt` → 各 `openapi-*.json`（官方 OpenAPI 规格）
|
||||
> 日期：2026-10-04 · 抓取方式：脚本读取 JSON，**零费用**
|
||||
> ⚠️ 服务地址为 `https://maas.qianwenaiapi.com/api/v1`（千问AI平台域名），
|
||||
> 与我们现用的 `dashscope.aliyuncs.com` **不同域** —— key 兼容性待一次实测确认。
|
||||
|
||||
---
|
||||
|
||||
## 一、R2V 参考生视频（多图/视频参考）★ 核心
|
||||
|
||||
**模型**：`wan2.7-r2v`（¥0.6/秒 720P）· `wan2.6-r2v-flash`（¥0.3/秒 720P）
|
||||
**端点**：`POST /services/aigc/video-generation/video-synthesis`
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"model": "wan2.7-r2v",
|
||||
"input": {
|
||||
"prompt": "★必填 · 期望视频内容（支持中英文 + 引用标识符）",
|
||||
"negative_prompt": "需排除的内容（≤500 字符）",
|
||||
"media": [ // ★必填 · 参考媒体对象数组
|
||||
{
|
||||
"type": "★必填 · reference_image | reference_video | first_frame",
|
||||
"url": "★必填 · 参考媒体文件 URL",
|
||||
"reference_voice": "可选 · 音频 URL，指定该参考主体的【音色】"
|
||||
}
|
||||
]
|
||||
},
|
||||
"parameters": {
|
||||
"resolution": "720P / 1080P …",
|
||||
"ratio": "输出宽高比（若给了 first_frame 则忽略）",
|
||||
"duration": "秒。参考素材含视频时 2–10s；仅图片时范围另定",
|
||||
"prompt_extend": "bool · 用 LLM 扩写提示词",
|
||||
"seed": "int · 复现种子",
|
||||
"watermark": "bool"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**关键点**：
|
||||
- `media[].type` 的 enum = **`reference_image` / `reference_video` / `first_frame`**
|
||||
→ 意味着**可以在同一次调用里同时给「角色参考图」+「场景参考图」+「首帧」**
|
||||
- `reference_voice` 可直接绑**音色**（音色锁）
|
||||
- 图片要求：JPEG/JPG/PNG(无 alpha)/BMP/WEBP，每边 240–8000 px
|
||||
|
||||
---
|
||||
|
||||
## 二、KF2V 首尾帧生视频
|
||||
|
||||
**模型**：`wan2.2-kf2v-flash`（¥0.1/秒 480P）
|
||||
**端点**：`POST /services/aigc/image2video/video-synthesis`
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"model": "wan2.2-kf2v-flash",
|
||||
"input": {
|
||||
"prompt": "可选 · 若首尾帧主体/场景变化，建议描述过渡方式",
|
||||
"negative_prompt": "可选（≤500 字符）",
|
||||
"first_frame_url": "★必填 · 首帧图 URL（输出宽高比与此图一致）",
|
||||
"last_frame_url": "★必填 · 尾帧图 URL（分辨率可与首帧不同）"
|
||||
},
|
||||
"parameters": {
|
||||
"resolution": "1080P > 720P > 480P（影响计费）",
|
||||
"duration": "固定 5 秒，不可修改",
|
||||
"prompt_extend": "bool（默认 true）",
|
||||
"template": "特效模板名 —— 用了它只需传 first_frame_url",
|
||||
"watermark": "bool（默认 false）",
|
||||
"seed": "int"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
> 这就是「关键帧 → 视频」的主力工具：**两张关键帧图 + 一句过渡描述**。
|
||||
|
||||
---
|
||||
|
||||
## 三、Character Swap 视频换人
|
||||
|
||||
**端点**：`POST /services/aigc/image2video/video-synthesis`
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"input": {
|
||||
"image_url": "★必填 · 人物图片 URL（单个正面人物，面部清晰）",
|
||||
"video_url": "★必填 · 参考视频 URL（单个正面人物）",
|
||||
"watermark": "bool"
|
||||
},
|
||||
"parameters": {
|
||||
"check_image": "bool（默认 true）",
|
||||
"mode": "★必填 · wan-std（快/便宜）| wan-pro（专业）"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
> 用户说的「把别人的视频里的人物换成我的角色」—— **这个模型就是干这个的**。
|
||||
|
||||
---
|
||||
|
||||
## 四、Video Style Transform 视频风格重绘 ★ 回答「像素化」
|
||||
|
||||
**端点**：`POST /services/aigc/video-generation/video-synthesis`
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"input": { "video_url": "★必填 · 输入视频 URL（≤30s）" },
|
||||
"parameters": {
|
||||
"style": "★可选值 0–7：0 日式漫画 / 1 美式漫画 / 2 清新漫画 / 3 3D卡通 /
|
||||
4 国风卡通(古装最佳) / 5 纸艺风格 / 6 简易插画 / 7 …",
|
||||
"video_fps": "15~25",
|
||||
"animate_emotion": "bool · 情绪表情迁移",
|
||||
"min_len": "720 | 540（短边分辨率）",
|
||||
"use_SR": "bool · 超分辨率增强"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
> **8 种艺术风格** —— 这应该就是用户说的「像素化/风格化」的正解。
|
||||
|
||||
---
|
||||
|
||||
## 五、同一文档站还有的能力（待按需展开）
|
||||
|
||||
| 页面 | 能力 |
|
||||
|:--|:--|
|
||||
| `openapi-wan-video-editing.json` | **Wan 统一视频编辑**：多图参考 / 视频重绘 / 局部编辑 / 视频续写 / 画面扩展 |
|
||||
| `openapi-wan27-video-editing.json` | Wan 2.7 视频编辑（多模态指令） |
|
||||
| `openapi-wan30-video.json` | **万相 3.0 All-in-One**：文生视频 / 图生视频(首帧/首尾帧) / 参考生视频，**最长 30s / 30fps / 原生有声** |
|
||||
| `wan-image-editing`（文档页） | 万相图像编辑（**多图输入 + 多图输出**，多图融合、主体特征保持） |
|
||||
| `wan21-image-editing`（文档页） | 万相 2.1 通用图像编辑（扩图/去水印/**风格迁移**/指令编辑/局部重绘） |
|
||||
| `virtual-model`（文档页） | 虚拟模特（保持站姿，**替换背景与模特**） |
|
||||
| `openapi-wan-character-swap.json` | 视频换脸 |
|
||||
| `openapi-wan-image-to-animation.json` | 动作迁移（参考视频动作 → 图片人物） |
|
||||
| `openapi-vidu-*` | Vidu 系列（参考生视频 / 首尾帧 / 文生视频） |
|
||||
| `openapi-pixverse-ref-to-video.json` | PixVerse 参考生视频（`@ref_name` 语法） |
|
||||
|
||||
---
|
||||
|
||||
## 五之二、两个重量级规格（已抓到确切字段）
|
||||
|
||||
### Wan 统一视频编辑 `openapi-wan-video-editing`
|
||||
**端点**：`POST /services/aigc/video-generation/video-synthesis`
|
||||
|
||||
```jsonc
|
||||
"input": {
|
||||
"function": "★必填 · 能力选择器（多图参考 / 视频重绘 / 局部编辑 / 视频续写 / 画面扩展）",
|
||||
"prompt": "★必填",
|
||||
"ref_images_url": "参考图（多图）",
|
||||
"video_url": "输入视频",
|
||||
"mask_image_url" / "mask_video_url" / "mask_frame_id": "局部编辑用的遮罩",
|
||||
"first_clip_url" / "last_clip_url": "视频续写用",
|
||||
"first_frame_url" / "last_frame_url": "首尾帧"
|
||||
},
|
||||
"parameters": {
|
||||
"prompt_extend", "size", "obj_or_bg", "control_condition", "strength",
|
||||
"mask_type", "expand_ratio",
|
||||
"top_scale" / "bottom_scale" / "left_scale" / "right_scale": "画面扩展方向比例"
|
||||
}
|
||||
```
|
||||
|
||||
> **一个接口吃下五大编辑能力**，靠 `function` 切换。
|
||||
|
||||
### 万相 3.0 All-in-One `openapi-wan30-video`
|
||||
**端点**：`POST /services/aigc/video-generation/video-synthesis`
|
||||
|
||||
```jsonc
|
||||
"input": { "prompt": "...", "media": [...] },
|
||||
"parameters": { "resolution", "ratio", "duration",
|
||||
"audio": "★ 原生有声输出开关",
|
||||
"seed", "prompt_extend", "watermark" }
|
||||
```
|
||||
|
||||
> 官方描述：**统一支持文生视频 / 图生视频（首帧・首尾帧）/ 参考生视频**，
|
||||
> **最长 30 秒、30fps、原生有声**。这一个模型可能就覆盖大部分主流程。
|
||||
|
||||
---
|
||||
|
||||
## 六、待确认（各一次调用即可，很便宜）
|
||||
|
||||
1. **域名/key 兼容性** —— 我们的 key 来自 `dashscope.aliyuncs.com`，
|
||||
上述端点在 `maas.qianwenaiapi.com`。是否同一个 key 通用？
|
||||
2. `wan2.7-r2v` 的 `media` 数组**数量上限**（文档说"最大 5 个"）
|
||||
3. `first_frame` 作为 media 类型时的具体行为（与 `first_frame_url` 的区别）
|
||||
|
||||
> 建议：用 `wan2.2-kf2v-flash`（¥0.1/秒 480P，最便宜）做一次**最短实测**确认域名/key 与返回结构。
|
||||
@@ -0,0 +1,94 @@
|
||||
# 看板前端改造方案（草案 · 待讨论）
|
||||
|
||||
> 日期：2026-10-04 · 状态：**草案，未实施**
|
||||
> 目的：把调研结论（见 `00/02/03`）落到「改哪些文件、改什么」
|
||||
|
||||
---
|
||||
|
||||
## A. 导演台出片改成两段式（关键帧 → 视频）★ 最核心
|
||||
|
||||
**要解决的问题**：现在点「生成视频」直接花钱出片，出了才知道对不对；
|
||||
改成先出关键帧（¥0.2/张）给你审，通过了再生视频。
|
||||
|
||||
**改动点**：
|
||||
|
||||
| 文件 | 改动 |
|
||||
|:--|:--|
|
||||
| `09_ave/scripts/composer/pipeline.py` | `render()` 新增 `keyframe_first` / `keyframe_only` 开关 |
|
||||
| `09_ave/scripts/composer/keyframe.py` | **新建** —— `build_keyframe(shot, sb)`，调 R2V/多图参考生图 |
|
||||
| `10_dashboard/routes/ave.py` | 新增 `POST /storyboard/keyframe/{job_id}`（生成关键帧）、`GET /storyboard/keyframes/{job_id}`（列出） |
|
||||
| `frontend/src/views/ave-director.js` | 出片区加两个按钮：**🖼 生成关键帧** / ▶ 生成视频；中间加关键帧预览网格（可单张重做） |
|
||||
|
||||
**交互**：
|
||||
```
|
||||
[🚀 生成分镜] → 分镜表 → [🖼 生成关键帧（¥0.2/镜）]
|
||||
↓
|
||||
关键帧网格（点开看大图 / 🔄 单张重做 / 换机位）
|
||||
↓
|
||||
[▶ 生成视频（复用已通过的关键帧）]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## B. 能力登记（capabilities.yaml + 供应商）
|
||||
|
||||
**改动点**：
|
||||
|
||||
| 文件 | 改动 |
|
||||
|:--|:--|
|
||||
| `09_ave/config/capabilities.yaml` | 新增能力：`ref_to_video`（R2V）、`keyframe_video`（KF2V）、`video_style_transform`、`video_edit`（统一编辑）；更新 `person_swap` 增补 wan 路径 |
|
||||
| `09_ave/config/capabilities.yaml` | 新增 provider：`qianwen`（域名 `maas.qianwenaiapi.com`） |
|
||||
| `frontend/src/views/ave-capabilities.js` | 自动读取（无需改，若结构兼容） |
|
||||
| `frontend/src/views/ave-providers.js` | 加"千问AI平台"供应商条目（key 状态检测） |
|
||||
|
||||
**注**：能力清单是数据驱动的，理论上只改 YAML + 后端调用实现。
|
||||
|
||||
---
|
||||
|
||||
## C. 新功能入口（独立页面或流程页）
|
||||
|
||||
| 入口 | 说明 | 后端 |
|
||||
|:--|:--|:--|
|
||||
| 🎨 **视频风格重绘** | 上传视频 → 选 8 种风格之一 → 出风格化视频 | `style-transform` |
|
||||
| 🔄 **视频换人**（新实现） | 我的角色图 + 别人的视频 → 换人（保留场景光线） | `character-swap` |
|
||||
| 🖼 **参考驱动生视频** | 多张参考图（角色/场景/道具）+ 提示词 → 视频 | `wan2.7-r2v` |
|
||||
| ✂️ **视频编辑** | 局部改 / 续写 / 扩图 / 多图参考 | `wan-video-editing`（`function` 切换） |
|
||||
|
||||
**改动点**：新增 `frontend/src/views/ave-*.js` + `routes/ave_*.py` + 菜单注册三处
|
||||
（`view-registry.js` / `nav-menu.js` / `inline.js`）。
|
||||
|
||||
---
|
||||
|
||||
## D. 关键帧作为资产/产物
|
||||
|
||||
| 项 | 说明 |
|
||||
|:--|:--|
|
||||
| 落盘 | `runtime/ave/renders/{job_id}/keyframes/{shot_id}.png` |
|
||||
| 管理 | 纳入「🎬 全部生成产物」（`/api/ave/artifacts` 已扫 mp4，需扩到 png） |
|
||||
| 复用 | 关键帧可按镜头重做、可跨任务复用（对应 `reuse_existing` 机制） |
|
||||
|
||||
---
|
||||
|
||||
## E. 前置：一次最小实测（¥0.1~0.3）
|
||||
|
||||
**必须先确认**：千问AI平台域名（`maas.qianwenaiapi.com`）能否用我们现有的 key。
|
||||
|
||||
**做法**：用 `wan2.2-kf2v-flash`（¥0.1/秒）跑 **1 秒 480P** 的最短任务。
|
||||
- 成功 → 整条路线打通，可以照文档写代码
|
||||
- 401/403 → key 不通用，需另配平台 key
|
||||
|
||||
> ⚠️ 这一步不做，A/B/C/D 全部建在"假设可用"上。
|
||||
|
||||
---
|
||||
|
||||
## 建议顺序
|
||||
|
||||
```
|
||||
E（实测确认，¥0.1~0.3）
|
||||
→ B（能力登记，零费用）
|
||||
→ A（关键帧两段式，零费用代码）
|
||||
→ C（新入口，零费用代码，但每个都要实测效果）
|
||||
→ D（资产化）
|
||||
```
|
||||
|
||||
先从 E 开始的原因：**它是所有工作的地基**，且只要几毛钱。
|
||||
@@ -0,0 +1,121 @@
|
||||
# 图像生成 / 编辑能力调研（文生图 + 图生图）
|
||||
|
||||
> 来源：`platform.qianwenai.com/docs`（官方文档 + OpenAPI 规格，脚本抓取，**零费用**）
|
||||
> 日期：2026-10-04 · 用途：为「关键帧创作」环节选型
|
||||
|
||||
---
|
||||
|
||||
## 〇、一个重要发现：域名问题的答案
|
||||
|
||||
官方示例第一行就是：
|
||||
|
||||
```python
|
||||
dashscope.base_http_api_url = 'https://maas.qianwenaiapi.com/api/v1'
|
||||
api_key = os.getenv("DASHSCOPE_API_KEY")
|
||||
```
|
||||
|
||||
**结论**：千问AI平台就是 **DashScope 生态**（同一 SDK、同一个 `DASHSCOPE_API_KEY` 环境变量），
|
||||
只是 `base_http_api_url` 不同。我们现有的 key **大概率可直接用**（仍需一次调用确认）。
|
||||
|
||||
---
|
||||
|
||||
## 一、模型总览（官方「推荐模型」表）
|
||||
|
||||
| 模型 | 文生图 | 编辑 | 最大输出数 | 最大分辨率 | 特点 |
|
||||
|:--|:--:|:--:|:--|:--|:--|
|
||||
| `qwen-image-3.0-pro` | ✓ | ✓ | 6 | 2048×2048 | 复杂版面 / 10px 小字 / **负向提示词** / 摄影级细节 |
|
||||
| `qwen-image-3.0` | ✓ | ✓ | 6 | 2048×2048 | 同上、更快 |
|
||||
| `qwen-image-2.1-pro` | ✓ | ✓ | 6 | 2048×2048 | **编辑最多 10 张参考图**、可输出透明通道 |
|
||||
| `wan2.7-image-pro` | ✓ | ✓ | 4（顺序模式 **12**） | **4096×4096**（编辑 2048） | 4K、**最多 9 张输入图**、**边界框交互编辑**、**角色一致性多图生成** |
|
||||
| `wan2.7-image` | ✓ | ✓ | 4（顺序 12） | 2048×2048 | 同能力、更快 |
|
||||
| `z-image-turbo` | ✓ | ✗ | 1 | 2048×2048 | **快 10 倍、价格约 1/5**、写实人像 |
|
||||
| `vidu/vidu-image_reference2image` | ✓ | ✓ | 1 | **4K** | 参考图生图 |
|
||||
|
||||
**选型建议（官方）**：
|
||||
- 默认用 `qwen-image-3.0-pro`（生图+编辑同 ID，支持负向提示词）
|
||||
- 需要 **>2K / 品牌色 / 多图一致性** → `wan2.7-image-pro`
|
||||
- 只要快和省 → `z-image-turbo`
|
||||
|
||||
---
|
||||
|
||||
## 二、关键能力（这些正是「关键帧」需要的）
|
||||
|
||||
| 能力 | 哪个模型 | 对关键帧的意义 |
|
||||
|:--|:--|:--|
|
||||
| **多图输入 + 多图融合** | 全部编辑模型 | 「角色图 + 场景图」融合成一张镜头画面 |
|
||||
| **最多 9 张输入图** | `wan2.7-image-pro` | 可同时给：角色正/侧/背 + 场景 3 机位 + 道具 |
|
||||
| **角色一致性多图生成（顺序模式 12 张）** | `wan2.7-image-pro` | **一次生成整个分镜的关键帧**，且角色一致 |
|
||||
| **主体特征保持** | 万相 2.7/2.6/2.5 系列 | 保证"还是这个人" |
|
||||
| **边界框交互式编辑** | `wan2.7-image-pro` | 精准改某一块（如"把这个位置换成我的道具"） |
|
||||
| **负向提示词** | `qwen-image-3.0-pro` | 排除不要的元素 |
|
||||
| **透明通道输出** | `qwen-image-2.1-pro` | 抠主体（合成用） |
|
||||
|
||||
---
|
||||
|
||||
## 三、调用方式（官方示例，实测格式）
|
||||
|
||||
```python
|
||||
import os, dashscope
|
||||
from dashscope.aigc.image_generation import ImageGeneration
|
||||
from dashscope.api_entities.dashscope_response import Message
|
||||
|
||||
dashscope.base_http_api_url = 'https://maas.qianwenaiapi.com/api/v1'
|
||||
api_key = os.getenv("DASHSCOPE_API_KEY")
|
||||
|
||||
message = Message(
|
||||
role="user",
|
||||
content=[
|
||||
{"text": "把图2的涂鸦喷绘在图1的汽车上"}, # 指令
|
||||
{"image": "https://.../car.webp"}, # 图1
|
||||
{"image": "https://.../paint.webp"}, # 图2（可继续追加）
|
||||
# 支持本地文件：{"image": "file://car.png"}
|
||||
]
|
||||
)
|
||||
rsp = ImageGeneration.call(
|
||||
model='wan2.7-image-pro',
|
||||
api_key=api_key,
|
||||
messages=[message],
|
||||
watermark=False,
|
||||
n=1,
|
||||
size="2K",
|
||||
)
|
||||
```
|
||||
|
||||
**要点**：
|
||||
- `content` 是**数组**：文本 + 多张图片混排
|
||||
- 支持 **本地文件** `file://`
|
||||
- 参数：`n`（输出张数）、`size`（分辨率档）、`watermark`
|
||||
- **同步调用**（直接返回图 URL），无需轮询
|
||||
|
||||
---
|
||||
|
||||
## 四、其他相关能力（同一平台）
|
||||
|
||||
| 文档页 | 能力 | 对项目的用途 |
|
||||
|:--|:--|:--|
|
||||
| `image-editing` | 通用指令编辑 | 关键帧微调 |
|
||||
| `wan21-image-editing` | 扩图 / 去水印 / **风格迁移** / 指令编辑 / 局部重绘 | 风格化关键帧 |
|
||||
| `image-inpainting` | `wanx-x-painting` 局部重绘 | 改局部 |
|
||||
| `image-out-painting` | 画面扩展（按比例/方向/旋转） | 调整构图 |
|
||||
| `sketch-to-image` | 涂鸦作画 | 手绘草图 → 画面 |
|
||||
| `virtual-model` | 虚拟模特（保持站姿，**替换背景与模特**） | 换人换景 |
|
||||
| `background-generation` | 商品图生成背景 | 产品场景 |
|
||||
| `image-erase-completion` | 擦除补全 | 去杂物 |
|
||||
| `person-instance-segmentation` | 人物像素级分割 | 抠人 |
|
||||
|
||||
---
|
||||
|
||||
## 五、对「关键帧创作」环节的结论
|
||||
|
||||
**核心工具**：
|
||||
- 主选 **`wan2.7-image-pro`**（9 图输入 + 顺序模式一次 12 张 + 角色一致性）
|
||||
- 备选 **`qwen-image-3.0-pro`**（负向提示词 + 小字渲染）
|
||||
|
||||
**典型关键帧指令**（多图融合）：
|
||||
```
|
||||
[角色正面图] + [角色侧脸图] + [场景 wide 图] + [场景 top 图]
|
||||
+ 文本："角色站在病房床边的中景，俯视 30°，冷白日光灯，写实摄影"
|
||||
→ 一张「人和环境都对」的关键帧
|
||||
```
|
||||
|
||||
**待实测**（各一次调用）：确认现有 key 在 `maas.qianwenaiapi.com` 可用。
|
||||
@@ -0,0 +1,132 @@
|
||||
# 「关键帧创作」环节 · 流程与操作界面设计
|
||||
|
||||
> 日期：2026-10-04 · 状态：**待 ghai 确认**
|
||||
> 对应流程：① 剧本创作 → **② 关键帧创作（本文）** → ③ 关键帧变视频
|
||||
|
||||
---
|
||||
|
||||
## 一、流程确认
|
||||
|
||||
```
|
||||
① 剧本创作 导演系统产分镜表（每镜头：景别/角度/动作/台词/参考资产）
|
||||
↓
|
||||
② 关键帧创作 ★新增 每镜头先出一张「人和环境都对」的静帧（= 连环画）
|
||||
· 有独立操作界面
|
||||
· 可审、可改、可重做、可换机位
|
||||
↓
|
||||
③ 关键帧变视频 首尾帧 / 参考驱动，让静帧动起来
|
||||
```
|
||||
|
||||
**用户原话**：「第 1 个是导演创作剧本，然后把这个剧本变成关键帧（也是图片），
|
||||
第 2 个是关键帧创作，第 3 个才是关键帧变视频」→ **确认，就是这三步。**
|
||||
|
||||
---
|
||||
|
||||
## 二、关键帧是什么（定义）
|
||||
|
||||
**一个镜头 = 一张关键帧**（可选加一张尾帧用于精准动作）。
|
||||
它是这个镜头「该有的那一瞬间画面」：人物（像不像）× 环境（对不对）× 构图（怎么拍）。
|
||||
|
||||
**生成方式**：多图参考融合
|
||||
```
|
||||
输入：角色参考图（1~3 张，来自角色套装）
|
||||
+ 场景参考图（1 张，按机位选）
|
||||
+ 道具/产品图（可选）
|
||||
+ 提示词（构图 / 光线 / 动作瞬间）
|
||||
输出：一张关键帧 PNG
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 三、操作界面设计
|
||||
|
||||
### 3.1 整体布局（三段式）
|
||||
|
||||
```
|
||||
┌───────────────────────────────────────────────────────────────────┐
|
||||
│ 🖼 关键帧创作 [⚙ 参数] [🖼 批量生成全部] 进度 3/8 │
|
||||
├────────────┬──────────────────────────────────────────────────────┤
|
||||
│ 分镜列表 │ 关键帧网格 │
|
||||
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌─────────┐│
|
||||
│ ① 全景建立 │ │ [缩略图] │ │ [缩略图] │ │ [ 空 ] │ │ [ 空 ] ││
|
||||
│ ② 中景-她 │ │ 全景·平视 │ │ 中景·俯视 │ │ 待生成 │ │ 待生成 ││
|
||||
│ ③ 特写-手 │ │ ✅ 已确认 │ │ 🔄 待审 │ │ 🖼 生成 │ │ 🖼 生成││
|
||||
│ ④ 空镜-窗 │ └──────────┘ └──────────┘ └──────────┘ └─────────┘│
|
||||
│ │ │
|
||||
│ 共 4 镜 │ ── 选中：② 中景-她 ────────────────────────────────│
|
||||
│ ✅2 🔄1 ⬜1 │ 参考图： [角色·正面] [角色·45°] [场景·top] ＋加参考 │
|
||||
│ │ 提示词： 角色站在病床边，俯视 30°，冷白日光灯… │
|
||||
│ │ [🔄 重新生成] [✏️ 改提示词] [📐 换机位] [✅ 确认采用]│
|
||||
└────────────┴──────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 3.2 关键帧卡片（每镜头一张）
|
||||
|
||||
```
|
||||
┌────────────────────┐
|
||||
│ [ 缩略图 ] │ ← 点击看大图（lightbox，已有组件）
|
||||
│ ② 中景 · 俯视 │ ← 机位标签（来自分镜 shot_contract）
|
||||
│ ✅ 已确认 / 🔄 待审 │ ← 状态徽章
|
||||
│ [🔄] [📐] [👁] [✅] │ ← 重做 / 换机位 / 看大图 / 确认
|
||||
└────────────────────┘
|
||||
```
|
||||
|
||||
**状态**：⬜ 待生成 → 🔄 待审 → ✅ 已确认（只有 ✅ 才允许进第③步）
|
||||
|
||||
### 3.3 单张操作（选中后右侧/下方）
|
||||
|
||||
| 操作 | 说明 |
|
||||
|:--|:--|
|
||||
| 🔄 **重新生成** | 同参数再出一张（不满意就换一版） |
|
||||
| ✏️ **改提示词** | 就地编辑，重生成时生效 |
|
||||
| 📐 **换机位** | 切换场景参考图（wide/front/side/top/detail/back） |
|
||||
| ➕ **加/减参考图** | 增减角色图、道具图（最多 9 张） |
|
||||
| 🖼 **多出几张挑一张** | `n=4` 一次出 4 张，选一张采用 |
|
||||
| 👁 **看大图** | lightbox（复用已有 `_assetViewImg`） |
|
||||
| ✅ **确认采用** | 锁定该关键帧，进第③步 |
|
||||
|
||||
### 3.4 批量操作
|
||||
|
||||
- **🖼 批量生成全部**（一次跑完所有镜头）
|
||||
- **♻️ 只跑未生成的**（续跑，已确认的不动）
|
||||
- **📥 一键采纳全部待审**（审得快的场景）
|
||||
- 顺序模式（`wan2.7-image-pro` 可一次出 12 张且角色一致）→ 适合"整条片子一起出"
|
||||
|
||||
---
|
||||
|
||||
## 四、与第③步的衔接
|
||||
|
||||
```
|
||||
关键帧 ✅ 全部确认 → [▶ 生成视频]
|
||||
↓
|
||||
· 有首尾帧 → wan2.2-kf2v-flash（首尾帧生视频，¥0.1/秒）
|
||||
· 单帧驱动 → wan2.6-r2v-flash（参考驱动，¥0.3/秒）
|
||||
↓
|
||||
片段 → 去AI化 → 拼接 → 配音 → 成片
|
||||
```
|
||||
|
||||
**省钱逻辑**：关键帧 ¥0.2/张，视频 ¥0.3~0.6/秒。
|
||||
一个 4 镜头 5 秒短片：关键帧 ¥0.8 + 视频 ¥6~12 ——
|
||||
**先花 ¥0.8 看连环画，通过了才花大头。**
|
||||
|
||||
---
|
||||
|
||||
## 五、技术实现要点
|
||||
|
||||
| 项 | 方案 |
|
||||
|:--|:--|
|
||||
| 生成 | `wan2.7-image-pro`（9 图输入 / 顺序 12 张）或 `qwen-image-3.0-pro` |
|
||||
| 落盘 | `runtime/ave/renders/{job_id}/keyframes/{shot_id}.png` |
|
||||
| 状态 | 存 `keyframes/{shot_id}.json`（提示词 / 参考图 / 状态 / 采用的 seed） |
|
||||
| 接口 | `POST /storyboard/keyframe/{job_id}`（生成）、`GET .../keyframes`（列出）、`POST .../keyframe/{shot_id}/adopt`（确认） |
|
||||
| 前端 | 新增 view `ave-keyframes.js` 或在 `ave-director.js` 内加一个阶段面板 |
|
||||
| 入口 | 导演台：分镜表下方 →「🖼 进入关键帧创作」 |
|
||||
|
||||
---
|
||||
|
||||
## 六、待确认
|
||||
|
||||
1. 界面放哪儿：**独立页**（菜单加「🖼 关键帧工作台」）还是**导演台内的一个阶段**？
|
||||
→ 我倾向**导演台内**（流程连贯，不用跳页）
|
||||
2. 是否要"多出几张挑一张"（n=4，成本 ×4）？
|
||||
3. 先做哪个模型：`wan2.7-image-pro`（能力强、贵些）还是 `qwen-image-3.0-pro`（平衡）？
|
||||
@@ -0,0 +1,160 @@
|
||||
# 「关键帧工作台」设计方案（独立页 · 全面版）
|
||||
|
||||
> 日期：2026-10-04 · 状态：**待 ghai 确认**
|
||||
> 对应流程：① 剧本创作 → **② 关键帧工作台（本文）** → ③ 关键帧变视频
|
||||
> 关联：`capabilities.yaml` 的「🖼️ 图像」12 项能力 · `📚 API 文档中心`
|
||||
|
||||
---
|
||||
|
||||
## 一、定位
|
||||
|
||||
**独立的一级页面**，不是导演台里的一个阶段（按用户要求「单独做一个关键帧工作台」）。
|
||||
|
||||
它是**剧本与视频之间的那一步**：把导演产出的分镜，变成一组**可审、可改、可重做的静帧**。
|
||||
|
||||
```
|
||||
导演台：剧本 → 分镜表
|
||||
↓ 带过去（project_id / storyboard）
|
||||
关键帧工作台：逐镜头生成静帧 → 你审 → 通过
|
||||
↓ 再带过去
|
||||
生成视频：首尾帧 / 参考驱动 → 片段 → 成片
|
||||
```
|
||||
|
||||
**为什么它是独立页**：关键帧的工作量大（每镜头可能要试好几版）、周期长（可跨天），
|
||||
需要一个能"沉浸式审图"的地方，而不是夹在导演台的小面板里。
|
||||
|
||||
---
|
||||
|
||||
## 二、关键帧的 4 种生成方式（用户提到的全覆盖）
|
||||
|
||||
| # | 方式 | 输入 | 用哪个能力 | 典型场景 |
|
||||
|:--|:--|:--|:--|:--|
|
||||
| 1 | **文生图** | 只给文本 | `text_to_image` | 空镜 / 氛围镜（没人物的画面） |
|
||||
| 2 | **图生图（单参考）** | 1 张参考图 + 文本 | `text_to_image`(ref) / `image_edit` | 已有场景图，生成该机位画面 |
|
||||
| 3 | **多图生图（融合）★主力** | 角色图 1~3 + 场景图 1 + 道具 + 文本 | `ref_to_image` | **人和环境都要对**的镜头 |
|
||||
| 4 | **改造（编辑已有图）** | 一张底图 + 编辑指令 | `image_edit` / `image_inpaint` / `image_outpaint` / `image_style_transfer` | 关键帧基本对、只改某处 / 换风格 / 扩构图 |
|
||||
|
||||
**顺序模式（一次性出整条片子）**：`ref_to_image` 的 `mode=sequential`
|
||||
（`wan2.7-image-pro` 支持一次 12 张且角色一致）→ 适合"先把整条分镜的关键帧一起出，再逐张审"。
|
||||
|
||||
---
|
||||
|
||||
## 三、提示词从哪来（关键词生成）
|
||||
|
||||
**不是让你手写** —— 工作台从分镜**自动生成**，你再改。
|
||||
|
||||
```
|
||||
分镜 shot 字段 → 关键帧提示词
|
||||
─────────────────────────────────────────────────────────
|
||||
visual_description（画面描述） → 主体 + 动作瞬间
|
||||
shot_contract.shot_size（景别） → 构图（特写/中景/全景）
|
||||
shot_contract.angle（角度） → 机位（俯视/平视/侧拍/过肩）
|
||||
global_anchors.lighting_state → 光线
|
||||
global_anchors.shooting_style → 画面风格
|
||||
scene_id 对应的场景资产 topology → 空间关系（谁在哪、朝向）
|
||||
```
|
||||
|
||||
复用现有 `pipeline.build_shot_prompt()` 的**视觉部分**（去掉"运动"描述 —— 运动属于第③步视频阶段）。
|
||||
|
||||
**工作台上可改**：生成的提示词直接显示在输入框里，你可编辑、可加负向词、可切换"按机位重选场景参考图"。
|
||||
|
||||
---
|
||||
|
||||
## 四、操作界面（独立页）
|
||||
|
||||
```
|
||||
┌──────────────────────────────────────────────────────────────────────────┐
|
||||
│ 🖼 关键帧工作台 项目:[痔疮术后vlog ▾] ⚙ 参数 🔄更新 [🖼 批量生成] │
|
||||
├─────────────┬────────────────────────────────────────────────────────────┤
|
||||
│ 镜头列表 │ 关键帧网格（每镜头可有多版，挑一版） │
|
||||
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
|
||||
│ ① 全景·建立 │ │ [v1] ✅ │ │ [v2] 🔄 │ │ [ 空 ] │ │ [ 空 ] │ │
|
||||
│ ② 中景·她 │ │ 全员确认 │ │ 待审 │ │ 待生成 │ │ 待生成 │ │
|
||||
│ ③ 特写·手 │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
|
||||
│ ④ 空镜·窗 │ │
|
||||
│ │ ── 选中 ② 中景·她 ─────────────────────────────────────────│
|
||||
│ 共4镜 │ 生成方式： ○文生图 ○单参考 ●多图融合 ○改造已有图 │
|
||||
│ ✅2 🔄1 ⬜1 │ 参考图： [角色·正面][角色·45°][场景·top] ＋加参考（最多9） │
|
||||
│ │ 提示词： 角色站在病床边，俯视30°，冷白日光灯，写实摄影… │
|
||||
│ │ 负向词： people duplicated, extra fingers… │
|
||||
│ │ [🔄 重新生成] 张数[1▾] [👁 看大图] [✅ 采用此版] [🗑 丢弃] │
|
||||
└─────────────┴────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 每镜头卡片
|
||||
|
||||
```
|
||||
┌──────────────┐
|
||||
│ [缩略图] │ ← 点开看大图（lightbox 已具备）
|
||||
│ ② 中景·俯视 │
|
||||
│ v2 · 🔄 待审│ ← 版本号 + 状态
|
||||
│ [🔄][👁][✅][🗑]│
|
||||
└──────────────┘
|
||||
```
|
||||
|
||||
**状态**：⬜ 待生成 → 🔄 待审 → ✅ 已采用（可多版并存，挑一版采用）
|
||||
|
||||
### 批量操作
|
||||
- **🖼 批量生成全部**（未生成的）
|
||||
- **⚡ 顺序模式一次出**（`wan2.7-image-pro`，整条片子一起，角色一致性最好）
|
||||
- **📥 一键采用全部待审**
|
||||
- **♻️ 重置某镜头**（回到待生成）
|
||||
|
||||
---
|
||||
|
||||
## 五、它在数据上怎么走
|
||||
|
||||
```
|
||||
输入：project_id（来自导演台的分镜）
|
||||
↓
|
||||
每镜头生成 → runtime/ave/keyframes/{project_id}/{shot_id}/v{n}.png
|
||||
+ 同名 .json（提示词 / 参考图 / 模型 / seed / 状态 / 是否采用）
|
||||
↓
|
||||
采用的那一版 → 复制为 {shot_id}.png（第③步读这个）
|
||||
↓
|
||||
第③步：有尾帧 → keyframe_video(KF2V)；单帧 → ref_to_video(R2V)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 六、涉及的基础能力（对应 capabilities.yaml）
|
||||
|
||||
| 环节 | 能力 id | 模型（默认） | 价格 |
|
||||
|:--|:--|:--|:--|
|
||||
| 文生图 | `text_to_image` | `wan2.7-image-pro` | ¥0.2/张 |
|
||||
| **多图融合**（主力） | `ref_to_image` | `wan2.7-image-pro` | ¥0.2/张 |
|
||||
| 指令编辑 | `image_edit` | `qwen-image-3.0-pro` | ¥0.2/张 |
|
||||
| 局部重绘 | `image_inpaint` | `wanx-x-painting` | ¥0.2/张 |
|
||||
| 扩图 | `image_outpaint` | `image-out-painting` | ¥0.2/张 |
|
||||
| 风格迁移 | `image_style_transfer` | `wanx2.1-imageedit` | ¥0.2/张 |
|
||||
| 抠图 | `person_segment` | `person-instance-segmentation` | — |
|
||||
| 首尾帧→视频 | `keyframe_video` | `wan2.2-kf2v-flash` | ¥0.1/秒 |
|
||||
| 参考→视频 | `ref_to_video` | `wan2.6-r2v-flash` | ¥0.3/秒 |
|
||||
| 视频风格重绘 | `video_style_transform` | `video-style-transform` | 按秒 |
|
||||
|
||||
**成本对照**（4 镜头 5 秒短片）：
|
||||
- 关键帧 4×¥0.2 = **¥0.8**（多试两版 ≈ ¥2）
|
||||
- 视频 4×5×¥0.1(480P) = **¥2.0**
|
||||
- **合计约 ¥2.8**，对比现在"直接可灵出片"的 ¥12
|
||||
|
||||
---
|
||||
|
||||
## 七、实施路径（分 3 步，每步可停）
|
||||
|
||||
| 步 | 内容 | 费用 |
|
||||
|:--|:--|:--|
|
||||
| **K1** | 后端：`keyframe.py`（4 种生成方式） + 3 个接口（生成/列表/采用） | ¥0 |
|
||||
| **K2** | 前端：独立页 `ave-keyframes.js` + 菜单注册 + 从导演台跳转 | ¥0 |
|
||||
| **K3** | 打通用：采用的关键帧 → 第③步视频（接 `keyframe_video` / `ref_to_video`） | ¥0 |
|
||||
| 验证 | 跑 1 个镜头端到端（关键帧 → 视频） | ≈¥0.2 + ¥0.5 |
|
||||
|
||||
**前置**：确认千问AI平台域名可用（一次 ¥0.2 的 `wan2.7-image-pro` 调用）。
|
||||
|
||||
---
|
||||
|
||||
## 八、待确认
|
||||
|
||||
1. **入口位置**：菜单「🎬 视频工厂 · 流程」下加「🖼 关键帧工作台」？（与其他流程页并列）
|
||||
2. **是否要"多版并存"**（同一镜头存 v1/v2/v3 挑一版）？还是要"重做即覆盖"？
|
||||
3. **批量生成默认策略**：一镜一镜（可控、便宜）还是顺序模式一次出（快、角色一致好）？
|
||||
4. **前置验证**是否现在做（¥0.2，确认 key 在千问平台可用）？
|
||||
@@ -0,0 +1,259 @@
|
||||
# 关键帧 → 视频 工作台设计方案（第③步）
|
||||
|
||||
> 2026-10-04 · 待评审
|
||||
> 用户诉求：关键帧生成后，如何让它「动起来」？导演分镜里已有动作思路，
|
||||
> 应该有一个「关键帧转视频」的操作平台，引用导演分镜的路径与运动描述，
|
||||
> 支持首尾帧衔接，并显示用什么模型。
|
||||
|
||||
---
|
||||
|
||||
## 一、先确认流程（用户问「是不是这么个逻辑」）
|
||||
|
||||
**是的，你的逻辑是对的。** 完整流程应该是五步：
|
||||
|
||||
```
|
||||
① 剧本 / 分镜 —— 导演创作（已有：每镜已含动作/运动描述）
|
||||
② 关键帧（静帧审图） —— ✅ 已做（关键帧工作台 v2）
|
||||
③ 关键帧 → 视频 —— ⬜ 本次要建（图生视频）
|
||||
④ 后处理 —— 已有：去AI化 → 拼接 → 字幕 → 混音
|
||||
⑤ 交付 —— 已有：候选成片 / 复核
|
||||
```
|
||||
|
||||
**但有两个顺序细节要强调**：
|
||||
|
||||
1. **音频先行应在 ③ 之前**：先 TTS 得到台词的真实时长 → 反推每镜时长 →
|
||||
再生成视频。否则视频时长会和台词对不上。（现有 pipeline 已实现这个开关）
|
||||
2. **去AI化属于 ④ 而非 ③**：它是"拍完之后"的画面处理，不该混进生成阶段。
|
||||
|
||||
---
|
||||
|
||||
## 二、🔴 关键发现：现有出片流程**根本没用关键帧**
|
||||
|
||||
`composer/pipeline.py:538`：
|
||||
```python
|
||||
ref_image = self._resolve_reference_image(shot, storyboard)
|
||||
# ↑ 取「角色定妆照 / 场景空照」当视频首帧
|
||||
```
|
||||
|
||||
也就是说：现在出片是**拿定妆照直接当首帧**，你精心审过的关键帧**完全被跳过**。
|
||||
|
||||
这解释了三个一直存在的怪现象：
|
||||
- 关键帧和工作台审了半天，出片却是另一张图
|
||||
- 角色/场景二选一（因为只能喂一张参考图）
|
||||
- 人物特写用不上场景（同上）
|
||||
|
||||
**好消息**：`kling_video.generate_video()` 的参数已经齐了：
|
||||
```python
|
||||
generate_video(prompt, dest, image_path="", # ← 首帧（图生视频）
|
||||
duration="5", model="kling-v3",
|
||||
tail_image_path="", # ← 尾帧（可灵 image_tail）
|
||||
vfx_type="", ...)
|
||||
```
|
||||
**通路是现成的，只差把关键帧接进去。**
|
||||
|
||||
---
|
||||
|
||||
## 三、核心改动（后端，最小且高价值）
|
||||
|
||||
在 `_generate_shot` 取图处，插一层「关键帧优先」：
|
||||
|
||||
```python
|
||||
# 新增：先看这个镜头有没有「采用的关键帧」
|
||||
kf = _adopted_keyframe(shot.shot_id) # 读 runtime/ave/keyframes/{pid}/{sid}/v*.json
|
||||
if kf:
|
||||
ref_image = kf # ★ 关键帧优先于角色定妆照
|
||||
want_image = True
|
||||
log.info(" 🖼️ 用「已采用的关键帧」作首帧：%s", Path(kf).name)
|
||||
else:
|
||||
ref_image = self._resolve_reference_image(shot, storyboard) # 原有逻辑（回退）
|
||||
```
|
||||
|
||||
**这一处改动就让"关键帧真正进片"**，且对没做关键帧的项目**完全向后兼容**（回退到原逻辑）。
|
||||
|
||||
---
|
||||
|
||||
## 四、工作台设计（第③步 · 独立页）
|
||||
|
||||
### 布局（延续第②步的两列风格）
|
||||
|
||||
```
|
||||
┌─────────────────┬──────────────────────────────────────────┐
|
||||
│ 镜头（连环画） │ 这一镜怎么动 │
|
||||
│ ┌─────────────┐ │ ┌─ 首帧 ────────────────┐ │
|
||||
│ │1 shot_01 ✅ │ │ │ [采用的关键帧] │ ← 来自第②步 │
|
||||
│ │ [关键帧缩略] │ │ │ （不可改，要换回第②步改）│ │
|
||||
│ └─────────────┘ │ └───────────────────────┘ │
|
||||
│ ┌─────────────┐ │ ┌─ 尾帧（可选）───────────┐ │
|
||||
│ │2 shot_02 ⬜ │ │ │ ○ 无 │ │
|
||||
│ │ [关键帧缩略] │ │ │ ○ 本镜尾帧 │ │
|
||||
│ └─────────────┘ │ │ ● 上一镜的实际末帧 ★ │ ← 跨镜衔接 │
|
||||
│ ↑↓ 切换 │ │ ○ 手选（下一镜关键帧） │ │
|
||||
│ │ └───────────────────────┘ │
|
||||
│ │ 🎬 运动提示词（从分镜 action 派生，可编辑） │
|
||||
│ │ ┌──────────────────────────────────┐ │
|
||||
│ │ │ 她缓缓转头看向窗外，手轻抚被角… │ │
|
||||
│ │ └──────────────────────────────────┘ │
|
||||
│ │ ⚠️ 只写"怎么动"，不重复描述画面（图已有） │
|
||||
│ │ │
|
||||
│ │ 引擎：[kling-v3 ▾] 💡 ¥0.6/秒 · 质量优先 │
|
||||
│ │ 时长：[5s ▾] 画幅：9:16（跟随关键帧） │
|
||||
│ │ │
|
||||
│ │ [🎬 生成视频] [🎬 批量生成全部] │
|
||||
│ │ │
|
||||
│ │ ┌─ 视频版本 ─────────────┐ │
|
||||
│ │ │ v1 [可播放] ✅采用 │ │
|
||||
│ │ └───────────────────────┘ │
|
||||
└─────────────────┴──────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 与第②步的分工（明确的边界）
|
||||
|
||||
| | 第②步 关键帧 | 第③步 转视频 |
|
||||
|:--|:--|:--|
|
||||
| 产物 | 静帧图 | 视频片段 |
|
||||
| 核心动作 | 选图（多版挑一） | 选运动（写怎么动） |
|
||||
| 数据 | 关键帧自己的 json | 视频文件 + 参数 |
|
||||
| 输入 | 角色图/场地图 + 提示词 | **采用的关键帧** + 运动提示词 |
|
||||
|
||||
---
|
||||
|
||||
## 五、运动提示词：从哪来、怎么写
|
||||
|
||||
**来源**：导演分镜的字段
|
||||
- `shot.action`（动作）—— 主来源
|
||||
- `shot.expression_detail`（表情变化）—— 补充
|
||||
- `shot.sentiment`（情绪）—— 语气参考
|
||||
|
||||
**组装规则**（复用现有 `build_shot_prompt(has_ref_image=True)` 的分支）：
|
||||
```
|
||||
❌ 错误写法（重描述视觉 → 模型重画 → 画面漂移）：
|
||||
"一个黑发女子坐在病床上，白色病号服，冷白灯光，她缓缓转头"
|
||||
|
||||
✅ 正确写法（只写运动）：
|
||||
"她缓缓转头看向窗外，手轻抚被角，胸口随呼吸轻微起伏"
|
||||
```
|
||||
|
||||
这条是**可灵官方守则**（图生视频只描述运动），我们代码里已有实现，直接复用。
|
||||
|
||||
---
|
||||
|
||||
## 六、引擎清单（新建 `config/video_models.yaml`）
|
||||
|
||||
| 模型 | 供应商 | 价格 | 特点 | 速度 |
|
||||
|:--|:--|:--|:--|:--|
|
||||
| `kling-v3` | 可灵 | ¥0.6/秒（720P） | 质量最好，现用 | 8-10 分钟 |
|
||||
| `kling-v2-5-turbo` | 可灵 | ¥0.3/秒 | 便宜一半，质量略降 | 较快 |
|
||||
| `wan2.2-kf2v-flash` | 百炼 | **¥0.1/秒** | **首尾帧专用**，最省 | 快 |
|
||||
| `wan2.6-r2v-flash` | 百炼 | ¥0.3/秒 | 多图参考生视频 | 快 |
|
||||
|
||||
**省钱建议**：
|
||||
- 测试期用 `wan2.2-kf2v-flash`（¥0.1/秒）——4 镜 5 秒短片约 **¥2**
|
||||
- 正式出片用 `kling-v3`（¥0.6/秒）—— 同样 4 镜约 **¥12**
|
||||
|
||||
---
|
||||
|
||||
## 七、首尾帧衔接（三种模式）
|
||||
|
||||
1. **独立**（默认）：每镜独立生成，镜头之间靠剪辑衔接
|
||||
2. **跨镜衔接** ★：把**上一镜实际生成的末帧**抽出来，作本镜的 `image_tail`
|
||||
- 保证动作连贯（上一镜结束时手在哪，这一镜从哪继续）
|
||||
- 依赖：`composer/frames.py`（抽尾帧，本地 ffmpeg，零成本）
|
||||
3. **首尾帧对**：本镜关键帧（首）+ 下一镜关键帧（尾）
|
||||
- 让模型在这两帧之间插值，适合"从 A 状态变到 B 状态"的镜头
|
||||
- ⚠️ 会牺牲中间过程的自由度，适合明确的过渡镜
|
||||
|
||||
---
|
||||
|
||||
## 八、与现有出片流程的关系
|
||||
|
||||
**不是另起炉灶，而是"给现有 pipeline 补上关键帧入口"**：
|
||||
|
||||
```
|
||||
现有：分镜 → [pipeline] → 取定妆照当首帧 → 图生视频 → 去AI化 → 拼接 → 字幕 → 混音
|
||||
新增：分镜 → [pipeline] → ★优先取「采用的关键帧」当首帧 → ……（后续不变）
|
||||
```
|
||||
|
||||
**好处**：
|
||||
- 音频先行 / 对口型 / 去AI化 / 音画同步 / 混流 **全部自动继承**
|
||||
- 不需要维护两套渲染逻辑
|
||||
- 没做关键帧的项目照常工作（回退）
|
||||
|
||||
---
|
||||
|
||||
## 九、实施步骤（建议顺序）
|
||||
|
||||
| 阶段 | 内容 | 费用 | 风险 |
|
||||
|:--|:--|:--|:--|
|
||||
| **V1** | 后端「关键帧优先作首帧」+ 单镜生成接口 | 0 | 低（有回退） |
|
||||
| **V2** | 工作台前端（两列 + 运动提示词 + 引擎选择） | 0 | 低 |
|
||||
| **V3** | 跨镜衔接（抽尾帧 → image_tail） | 0 | 中（需验证衔接效果） |
|
||||
| **V4** | 视频模型注册表 + 百炼通道接入 | 0 | 中（新通道） |
|
||||
| **V5** | 实测一镜（¥0.5~3） | 低 | — |
|
||||
|
||||
---
|
||||
|
||||
## 九·五、🔴 已知缺口：一个镜头「多段视频」（待实施）
|
||||
|
||||
**用户的架构**（2026-10-04 明确）：
|
||||
> 一个分镜可能要生成好几段视频 —— 因为关键帧是 A→B→C→D，
|
||||
> 那么 A→B 一段、B→C 一段、C→D 一段，拼起来才是这一镜的完整内容。
|
||||
|
||||
**现状差距**（实测 `keyframe_videos/{pid}/shot_01/`）：
|
||||
```
|
||||
shot_01/
|
||||
v1.mp4 v1.json v1.mp4.taskid ← 只有「一个版本」，不是「多个片段」
|
||||
```
|
||||
即：现在是**「一个镜头 = 同一片段的多次生成，挑一个」**，
|
||||
而不是**「一个镜头 = 多个片段，全都要，拼起来」**。两者语义完全不同。
|
||||
|
||||
**方案：引入「片段（segment）」概念**
|
||||
|
||||
三层概念要分清：
|
||||
| 概念 | 含义 | 数量关系 |
|
||||
|---|---|---|
|
||||
| **片段 segment** | 一段视频，由「首帧 → 尾帧」定义 | 一镜可有 1~N 段 |
|
||||
| **版本 version** | 同一片段的多次生成（挑一个） | 每段可有 1~N 版 |
|
||||
| **镜头 shot** | 由多个片段**按顺序拼接**而成 | 拼接产物 |
|
||||
|
||||
**存储结构**（向后兼容：无片段的老产物视为 1 段）
|
||||
```
|
||||
keyframe_videos/{pid}/{sid}/
|
||||
s1_v1.mp4 s1_v1.json ← 片段1 版本1（A → B）
|
||||
s1_v2.mp4 s1_v2.json ← 片段1 版本2
|
||||
s2_v1.mp4 s2_v1.json ← 片段2 版本1（B → C）
|
||||
concat.json ← 拼接清单：按顺序记 段号→采用的版本
|
||||
shot.mp4 ← 本地 ffmpeg 拼接产物（零成本）
|
||||
```
|
||||
|
||||
**界面**（视频标签内加「片段」组织层）
|
||||
```
|
||||
镜头 01
|
||||
├ 片段 1 首帧[A] → 尾帧[B] [生成] 版本: v1 ✅ v2
|
||||
├ 片段 2 首帧[B] → 尾帧[C] [生成] 版本: v1
|
||||
└ [🔗 拼接成完整镜头] → shot.mp4（本地 ffmpeg，零成本）
|
||||
```
|
||||
|
||||
**与关键帧设计的天然对应**：
|
||||
```
|
||||
设计层 frames: A(首) B(中) C(中) D(尾)
|
||||
生成层片段: s1=A→B s2=B→C s3=C→D ← 帧数 N → 片段数 N-1
|
||||
```
|
||||
→ **片段数 = 帧数 - 1**，可直接从 `kf_plan.frames` 自动派生片段清单。
|
||||
|
||||
**实施步骤**
|
||||
1. 后端：版本号改为 `s{seg}_v{ver}`；`concat.json` 读写；`POST /video/concat`（本地 ffmpeg 零成本）
|
||||
2. 后端：`/video/context` 返回 `segments[]`（从 kf_plan 派生：帧 A→B、B→C…）
|
||||
3. 前端：视频标签把「版本区」改为「片段区」，每段独立生成/挑版本
|
||||
4. 前端：末尾「🔗 拼接成完整镜头」按钮
|
||||
5. 兼容：无 `s{n}_` 前缀的老文件视作 s1_v{n}
|
||||
|
||||
**成本影响**：一段视频的钱不变（按时长计），但**一个镜头会花 N-1 倍**
|
||||
（换来的是动作连续性 —— 这是 06 Skill §08「动作桥接」的唯一可靠实现方式）。
|
||||
|
||||
## 十、待确认
|
||||
|
||||
1. **首尾帧衔接默认开还是关？**（建议默认关，用户显式选）
|
||||
2. **运动提示词是"只读派生"还是"可自由编辑"？**（建议可编辑，预填派生值）
|
||||
3. **是否本期就接百炼视频通道**（`wan2.2-kf2v-flash` ¥0.1/秒，测试期很省）
|
||||
4. **视频版本是否也做多版并存 + 采用**（与第②步一致）
|
||||
5. **生成后是否自动串联后续**（去AI化/字幕/混音），还是只在第③步停下
|
||||
@@ -0,0 +1,252 @@
|
||||
# 导演工作流整合方案（待评审）
|
||||
|
||||
> 起因：用户指出「导演创作 / 关键帧工作台 / 关键帧转视频 / 创意工坊 / 创意库」应当整合为一个流程，
|
||||
> 信息靠传参容易出错，中间产物应以缓存暂存。
|
||||
> 日期：2026-10-04 · 状态：**待用户拍板**
|
||||
|
||||
---
|
||||
|
||||
## 一、现状诊断（实测）
|
||||
|
||||
### 1.1 页面分散
|
||||
|
||||
| 类别 | 页面 | 体积 | 问题 |
|
||||
|:--|:--|:--|:--|
|
||||
| 创意 | `creative-studio.js` + `creatives.js` | 38KB + 14KB | 两个页面，工坊产出后要去库里找 |
|
||||
| 导演 | `ave-director.js` | **74KB** | 一个页面扛了策划+分镜+演员表+建议 |
|
||||
| 关键帧 | `ave-keyframes.js` | 36KB | 独立页 |
|
||||
| 转视频 | `ave-keyframe-video.js` | 39KB | 独立页 |
|
||||
| 流程页 | 7 个 `ave-flow-*.js` | 各 0.5~0.7KB | 只是入口卡片（点进去加载模板到画布） |
|
||||
| 资源库 | 15 个页面 | — | 角色/场景/道具/产品/服装/音色/BGM/音效/环境音/特效/素材 |
|
||||
|
||||
### 1.2 传参靠 localStorage（核心病灶）
|
||||
|
||||
```
|
||||
ave_creative_handoff 创意工坊 → 导演创作（带去分镜）
|
||||
ave_dir_cast_v1 导演创作的演员表（暂存）
|
||||
ave_dir_suggest_v1 AI 建议（暂存）
|
||||
ave_char_pending 导演创作 → 角色生成器（带去生成）
|
||||
ave_dir_cast_bind 角色生成器 → 导演创作（生成完绑回来）
|
||||
```
|
||||
|
||||
**四个问题**：
|
||||
1. **易丢**：清缓存 / 换浏览器 / 隐身模式 → 上下文全没
|
||||
2. **各写各的**：5 个 key 分散在 4 个文件里，改一处忘一处
|
||||
3. **无版本**：结构变了老数据还在，静默错乱
|
||||
4. **不可追溯**：出了问题查不到"当时传的是什么"
|
||||
|
||||
**实证**：`ave_char_pending` 的有效期曾设 30 分钟→120 分钟，就是因为"超时丢失"被投诉过。
|
||||
|
||||
---
|
||||
|
||||
## 二、目标架构
|
||||
|
||||
### 2.1 一个项目贯穿到底（Project-Centric）
|
||||
|
||||
核心转变：**从「页面之间传参」改为「所有页面围绕同一个项目对象工作」**
|
||||
|
||||
```
|
||||
项目对象（服务端 project.json，单一真相源）
|
||||
{
|
||||
"project_id": "vid_xxx",
|
||||
"stage": "keyframes", ← 当前进行到哪一步
|
||||
"creative": {...}, ← 创意（工坊产出）
|
||||
"script": {...}, ← 脚本/大纲/小说
|
||||
"storyboard": {...}, ← 导演分镜（已有 schema）
|
||||
"keyframes": {...}, ← 关键帧版本与采用状态
|
||||
"videos": {...}, ← 视频片段版本与采用状态
|
||||
"post": {...}, ← 声音/字幕/去AI化配置
|
||||
"cast": [...], ← 演员表
|
||||
"history": [...] ← 每步的变更记录（可回溯）
|
||||
}
|
||||
```
|
||||
|
||||
**好处**：
|
||||
- 传参不再经 localStorage → 切页面/刷新/换设备都不丢
|
||||
- 单一真相源 → 不会出现"演员表在两处不一致"
|
||||
- 有 stage → 界面能告诉用户"你现在在哪一步、下一步做什么"
|
||||
- 有 history → 可回溯、可撤销
|
||||
|
||||
### 2.2 单页标签式（一条流水线）
|
||||
|
||||
```
|
||||
┌─ 导演工作室 ─────────────────────────────────────────────┐
|
||||
│ 💡创意 → 📝剧本 → 🎬分镜 → 🖼关键帧 → 🎞视频 → 🎙后期 → 📤成片 │ ← 标签页
|
||||
├──────────────────────────────────────────────┬──────────┤
|
||||
│ │ │
|
||||
│ （当前标签页的内容） │ 📦 资源 │
|
||||
│ │ 角色 │
|
||||
│ │ 场景 │
|
||||
│ │ 道具 │
|
||||
│ │ 音色 │
|
||||
│ │ …（常驻） │
|
||||
└──────────────────────────────────────────────┴──────────┘
|
||||
```
|
||||
|
||||
**设计要点**：
|
||||
- **标签页 = 流程阶段**，随时可回退（比如在第④步发现关键帧不对，点标签③就回去改）
|
||||
- **右侧常驻资源面板**：任何阶段都能拖角色/场景进来（不用跳页去角色库）
|
||||
- **顶部显示项目名 + 当前阶段 + 进度**（如"4 镜 · 关键帧 4/4 · 视频 1/4"）
|
||||
- **原来的独立页面保留**（资源库管理、能力配置等），只是**创作流程**整合
|
||||
|
||||
### 2.3 各标签页的职责
|
||||
|
||||
| 标签 | 内容 | 数据来源 | 产出 |
|
||||
|:--|:--|:--|:--|
|
||||
| 💡 创意 | 参数库选型 → 候选创意 → 选中/淘汰 | `config/creative_matrix.yaml` | `project.creative` |
|
||||
| 📝 剧本 | 灵感/小说/大纲 → 脚本 → 导演剧本 | 创意 + LLM | `project.script` |
|
||||
| 🎬 分镜 | 导演选择 + 演员表 + 生成分镜表 | `project.script` | `project.storyboard` |
|
||||
| 🖼 关键帧 | 逐镜生成/审图/采用 | 分镜 + 资产 | 每镜关键帧版本 |
|
||||
| 🎞 视频 | 逐镜转视频（选路径/声音） | 关键帧 | 每镜视频版本 |
|
||||
| 🎙 后期 | 去AI化/字幕/混音/成片 | 视频片段 | 成片 |
|
||||
| 📤 成片 | 交付确认 + 记录 | 全部 | 归档 |
|
||||
|
||||
**资源库（角色/场景/道具…）保持独立页面**，但从工作室右侧可直达（点"＋新建角色"→ 打开角色生成器，建完自动绑回当前项目的演员表）。
|
||||
|
||||
---
|
||||
|
||||
## 三、实施步骤（分阶段，可独立交付）
|
||||
|
||||
### 阶段 1：统一项目状态（地基，零风险）
|
||||
- 新增 `routes/ave_project.py`：`GET/PATCH /api/ave/project/{pid}`
|
||||
统一读写 `runtime/ave/projects/{pid}/project.json`
|
||||
- 把现有 localStorage 传参**双写**（既写 localStorage 也写服务端）→ 保证不回退
|
||||
- 前端新增 `modules/project-store.js`：统一读写封装（替代散落的 localStorage 调用）
|
||||
|
||||
**验证**：清浏览器缓存后，项目上下文仍完整。
|
||||
|
||||
### 阶段 2：导演工作室骨架（单页 + 标签）
|
||||
- 新增 `views/ave-studio.js`（单页，内含 6 个标签）
|
||||
- 每个标签**复用现有视图**的 `loadView()`（不重写！）→ 风险最低
|
||||
- 顶部进度条 + 阶段指示；右侧资源面板（复用资产组件）
|
||||
- 菜单新增「🎬 导演工作室 ★」，旧的 3 个页面**保留**（过渡期）
|
||||
|
||||
**验证**：能在同一页里走完 创意→分镜→关键帧，切标签不丢数据。
|
||||
|
||||
### 阶段 3：阶段联动
|
||||
- 创意选中的项 → 剧本标签自动带入
|
||||
- 剧本定稿 → 分镜标签可一键生成
|
||||
- 分镜完成 → 关键帧标签自动列出镜头
|
||||
- 关键帧采用 → 视频标签自动就绪
|
||||
- 视频采用 → 后期标签自动可用
|
||||
|
||||
**验证**：从创意到成片全程不打开其他页面。
|
||||
|
||||
### 阶段 4：清理
|
||||
- 移除 localStorage 传参（改纯服务端）
|
||||
- 旧页面转「独立使用」入口（保留但不再是主路径）
|
||||
|
||||
---
|
||||
|
||||
## 四、与业界做法对照（实读 README，非猜测）
|
||||
|
||||
### 4.1 `Liang80mrer/AI-Animation-Studio` —— 11 步标准流程
|
||||
|
||||
```
|
||||
00 Project Control ← 项目控制（总控）
|
||||
↓
|
||||
01 Story Ideation 故事创意
|
||||
↓
|
||||
02 Worldbuilding 世界观 ← 我们缺
|
||||
↓
|
||||
03 Character Design 角色设计 ✓ 有
|
||||
↓
|
||||
04 Screenplay 剧本
|
||||
↓
|
||||
05 Storyboard 分镜 ✓ 有
|
||||
↓
|
||||
06 Keyframe Expansion 关键帧扩展 ✓ 有
|
||||
↓
|
||||
07 Prompt Compiler 提示词编译 ✓ 有（六模块）
|
||||
↓
|
||||
08 Video Quality Control 视频质检 ← 部分有（交付状态标注）
|
||||
↓
|
||||
09 Cover Design 封面 ← 我们缺
|
||||
↓
|
||||
10 Publishing 发布 ← 我们缺
|
||||
```
|
||||
|
||||
**它的三个核心机制**（正是用户要的"传递不出错"）：
|
||||
1. **Modular Skill Architecture** —— 每阶段是独立 Skill，**通过标准化接口**传结构化输出
|
||||
（对照我们：现在是页面之间传 localStorage → 一定要改）
|
||||
2. **Cross-Skill Inheritance System** —— **跨阶段继承**：下游自动继承上游约束
|
||||
（对照我们：`global_anchors` 有点这个意思，但没成体系）
|
||||
3. **Asset Library Strategy** —— 产出即资产
|
||||
（对照我们：资产库存的是"素材"，但创意/剧本/分镜还散在文件里）
|
||||
|
||||
### 4.2 `yfge/ai-video-studio` —— 专业短剧团队的工程化做法
|
||||
|
||||
> The core idea is to help creative teams collaborate around a **playable Timeline**,
|
||||
> not around one-off model outputs.
|
||||
> Main chain: **`audio → timeline → clip → render → export`**
|
||||
> **Timeline is the single source of truth (SSOT)** for playable episode output,
|
||||
> while Storyboard remains a visual support view.
|
||||
|
||||
**它给我们的三个关键启示**：
|
||||
1. ★ **Timeline 才是 SSOT，不是分镜** —— 分镜只是"视觉支撑视图"。
|
||||
我们一直是「分镜 → 出片」，没有"成片时间线"这个可编辑的最终对象。
|
||||
→ **建议吸收**：第⑥步（后期）的产出应该是一条**可编辑时间线**，
|
||||
而不是一次性渲染出的 mp4
|
||||
2. ★ **audio 先行**（`audio → timeline`）—— 我们已实现（`audio_first`），方向一致 ✓
|
||||
3. ★ **"把 AI 产出变成可追溯的生产资产，而不是临时提示词和文件"**
|
||||
→ 我们的 `runtime/ave/keyframes/{pid}/{sid}/v{n}.png` 已经是这个思路 ✓ 但只有关键帧/视频做了，创意/剧本没做
|
||||
|
||||
**它的工程做法**（我们**不照抄**，但可借鉴思路）：
|
||||
- FastAPI + SQLAlchemy + Celery + MySQL/Redis + Next.js
|
||||
- 代价：需要数据库与任务队列，部署复杂（Lite 模式也要 Docker）
|
||||
- **我们的现状**：JSON 文件 + 内存任务，够用且部署简单
|
||||
- **结论**：保留文件存储（当前规模够用），但**借鉴它的"对象化管理"**（项目对象 + 阶段状态）
|
||||
|
||||
### 4.3 横向对照
|
||||
|
||||
| 工具 | 组织方式 | 对我们的意义 |
|
||||
|:--|:--|:--|
|
||||
| ComfyUI | 节点图 | 灵活但门槛高，不适合内容创作者 |
|
||||
| Runway / Pika | 单页生成器 | 只做单点，无多镜成片流程 |
|
||||
| 剪映 / 即梦 | 时间线 + 素材箱 | **与我们目标同构** |
|
||||
| AI-Animation-Studio | 11 步 Skill 流水线 | **流程划分可直接参考** |
|
||||
| ai-video-studio | Timeline SSOT + 资产化 | **数据模型可参考** |
|
||||
|
||||
**结论**：业界共识 = 「**素材箱常驻 + 线性流程 + 单一真相源**」，
|
||||
用户的直觉（标签式整合 + 资源库常驻 + 缓存不丢）与业界完全一致。
|
||||
|
||||
**我们的差异化**：AI 生成需要"审图 / 多版 / 采用"环节
|
||||
（传统剪辑不需要 —— 素材是拍好的），所以关键帧与视频阶段要有**版本管理**（已实现）。
|
||||
|
||||
---
|
||||
|
||||
## 四·补、吸收后的方案调整
|
||||
|
||||
基于上述学习，对第二、三章做三处升级：
|
||||
|
||||
| 调整 | 内容 | 理由 |
|
||||
|:--|:--|:--|
|
||||
| **A. 加「世界观」层** | 分镜之前补一个轻量「设定」标签（人物关系/世界规则/基调），内容注入给剧本与分镜 | AI-Animation-Studio 有 Worldbuilding 且位置在角色设计之前 |
|
||||
| **B. 第⑥步产出「时间线」而非 mp4** | 后期阶段维护一条**可编辑时间线**（片段顺序/时长/音轨/字幕轨），渲染只是"导出"动作 | ai-video-studio：Timeline = SSOT；避免"渲染完发现要改就得重跑" |
|
||||
| **C. 全流程资产化** | 创意/剧本/分镜也纳入项目对象（现在只有关键帧/视频是版本化的） | 同上的"可追溯生产资产"原则 |
|
||||
|
||||
**不做**（明确记录，避免过度设计）：
|
||||
- 不引入数据库（JSON 文件在数个项目规模下够用）
|
||||
- 不引入任务队列（现有线程 + job.json 够用）
|
||||
- 不做发布/封面（当前不涉及，留待需要时）
|
||||
|
||||
---
|
||||
|
||||
## 五、风险与对策
|
||||
|
||||
| 风险 | 对策 |
|
||||
|:--|:--|
|
||||
| 74KB 的 ave-director 复用困难 | 阶段 2 **只包不拆**：先把它整个塞进标签，后续再拆 |
|
||||
| 单页体积过大 | 标签内容**懒加载**（点开才加载该视图模块） |
|
||||
| 改动面大、易回归 | 分 4 阶段，每阶段独立可验证、可回滚（git revert） |
|
||||
| 用户已习惯旧路径 | 旧页面全部保留，只新增工作室入口 |
|
||||
|
||||
---
|
||||
|
||||
## 六、待用户拍板
|
||||
|
||||
1. **是否按此方案推进**（阶段 1 先做地基）
|
||||
2. **标签页顺序**：创意 → 剧本 → 分镜 → 关键帧 → 视频 → 后期，对吗？
|
||||
3. **资源库**：保持独立页面 + 右侧快捷面板（我的建议），还是也要塞进标签？
|
||||
4. **旧页面**：保留（建议）还是最终移除？
|
||||
5. **单页 vs 多路由**：单页标签（我建议，切换不丢状态）还是多路由 + 共享 store？
|
||||
@@ -0,0 +1,177 @@
|
||||
# 按段落交接 · 全面改造方案（落地版）
|
||||
|
||||
> 依据：`docs/业界参考/剧本与分镜的分层标准.md`（实读 AI-Animation-Studio 04/05/06）
|
||||
> 用户要求：按段落交接，所有东西都要显示出来，全部补全
|
||||
> 日期：2026-10-04
|
||||
|
||||
---
|
||||
|
||||
## 一、回答「故事板要不要再生成一次」
|
||||
|
||||
**结论：默认用「文字故事板」，需要视觉预演时可选 AI 草图，不必手画。**
|
||||
|
||||
| 方式 | 成本 | 适用 |
|
||||
|:--|:--|:--|
|
||||
| **A. 文字故事板** ★默认 | ¥0 | 我们的主路径 —— 最终喂给可灵的是**提示词**，不是故事板图。故事板的职责是**镜头规划**（动作如何接、空间是否连续），文字清单就能完成 |
|
||||
| B. AI 生成草图 | ¥0.2/张 | 需要"看着顺不顺"的视觉预演时点一下。提示词用 `rough pencil storyboard sketch, simplified characters, no rendering`（**低完成度** —— 业界明确禁止精修插画） |
|
||||
| C. 手画 | 时间成本 | 真人拍摄项目才需要；对纯 AI 流程无增益 |
|
||||
|
||||
**为什么不做成"必须生成图"**：
|
||||
1. AI 生视频吃的是提示词，故事板图不参与生成
|
||||
2. 故事板图的价值是给人看"节奏对不对"，一张便宜的草图足够
|
||||
3. 强制生成 = 多花一批钱（4 镜 × ¥0.2 = ¥0.8/次），而收益只是"看一眼"
|
||||
|
||||
**什么时候值得生草图**：
|
||||
- 动作复杂的镜头（动作升级是否成立）
|
||||
- 空间连续性存疑（机位跳变会不会穿帮）
|
||||
- 给别人评审时
|
||||
|
||||
---
|
||||
|
||||
## 二、改造总览
|
||||
|
||||
### 2.1 剧本：从「一坨文字」变成「段落结构」
|
||||
|
||||
```
|
||||
project.script = {
|
||||
meta: {
|
||||
一句话故事 / 核心冲突 / 主角 / 对手 / 平台 / 视频时长 / 视觉风格 / 禁忌项
|
||||
},
|
||||
脚本模式: "情绪表演型", ← ★ 新增（决定分镜怎么拆）
|
||||
脚本驱动力: "眼神、偷听、信息差",
|
||||
价值判断: { 结论, 理由, 最大风险, 修改方向 },
|
||||
情绪路线: { 起点, 中段, 高潮, 结尾 },
|
||||
paragraphs: [ ← ★ 核心：按段落
|
||||
{
|
||||
no: 1,
|
||||
剧情: "...", ← 每段必须五项
|
||||
动作: "...",
|
||||
表情: "...",
|
||||
情绪: "...",
|
||||
画面重点: "..."
|
||||
},
|
||||
...
|
||||
],
|
||||
给下一阶段的输入: { ... } ← ★ 显式交接
|
||||
}
|
||||
```
|
||||
|
||||
**原样照搬业界的「每段五项」**（04 §11）：
|
||||
> 每段必须：剧情 / 动作 / 表情 / 情绪 / 画面重点
|
||||
|
||||
### 2.2 分镜：补齐「镜头功能」三要素
|
||||
|
||||
现有 `Shot` 有 `shot_contract`（景别/机位/运镜），缺业界要求的：
|
||||
```
|
||||
镜头功能 （这个镜头为什么存在：建立空间？推进情绪？给反应？）
|
||||
转场接口 （和下一镜怎么接：泡泡向镜头漂来形成遮挡 / 直接切 / 视线引导）
|
||||
重点 （观众此刻应看到什么）
|
||||
```
|
||||
→ 加进 `Shot`，并在关键帧/视频标签的「分镜原貌」里显示。
|
||||
|
||||
### 2.3 故事板：新增一层（文字版）
|
||||
|
||||
```
|
||||
project.storyboard_script（= 故事板，与既有分镜表分开）
|
||||
{
|
||||
模式: "情绪表演型",
|
||||
选择理由: "...",
|
||||
核心驱动力: "...",
|
||||
不适合的模式: "...",
|
||||
空间: { 空间类型, 功能, 主要元素, 视觉限制 }, ← 业界的「空间连续性」
|
||||
角色表演规则: { 动作语言, 情绪轨迹, 行为边界 },
|
||||
整体镜头语言: { 气质, 偏好, 构图倾向, 避免 },
|
||||
镜头: [ ← 逐格
|
||||
{ no, 镜头名, 功能, 相机, 画面内容, 行动, 转场接口, 重点 }
|
||||
],
|
||||
是否需要关键帧扩展: { 结论, 需要扩展的镜头, 扩展原因 },
|
||||
给下一阶段的输入: { ... }
|
||||
}
|
||||
```
|
||||
|
||||
### 2.4 显式交接（所有阶段都要显示）
|
||||
|
||||
每个标签页**底部固定显示一块「📤 给下一阶段的输入」**，内容就是从项目对象里
|
||||
读出来的结构化清单 —— **看得见、可校对、可直接复制**。
|
||||
|
||||
业界的硬规矩一并落地：
|
||||
> 「如果某类素材不存在，必须写"无，不使用"，不要编造素材。」
|
||||
|
||||
---
|
||||
|
||||
## 三、界面改造
|
||||
|
||||
### 3.1 剧本标签（重做）
|
||||
|
||||
```
|
||||
📝 剧本
|
||||
┌─ 上游（自动带入，只读） ─────────────────────────┐
|
||||
│ 💡 创意：<选中方向> 🌍 设定：<世界观/基调/禁忌> │
|
||||
└──────────────────────────────────────────────┘
|
||||
┌─ 脚本模式（决定分镜怎么拆）★ ─────────────────────┐
|
||||
│ ○ 动作预演型 ○ 情绪表演型 ○ 对话口播型 ○ 产品广告型 │
|
||||
│ ○ 科普解释型 ○ 世界观展示型 ○ 角色出场型 ○ 封面转视频型│
|
||||
│ 选中后显示：核心驱动力 / 镜头重点 / 不适合的模式 │
|
||||
└──────────────────────────────────────────────┘
|
||||
┌─ 剧情结构 & 情绪路线 ────────────────────────────┐
|
||||
│ 开场→冲突→行动→升级→结果→记忆点 │
|
||||
│ 情绪：起点→中段→高潮→结尾 │
|
||||
└──────────────────────────────────────────────┘
|
||||
┌─ 段落（可增删排序）★ ────────────────────────────┐
|
||||
│ 段落 01 [剧情][动作][表情][情绪][画面重点] │
|
||||
│ 段落 02 ... │
|
||||
│ + 添加段落 │
|
||||
└──────────────────────────────────────────────┘
|
||||
┌─ 📤 给下一阶段的输入 ────────────────────────────┐
|
||||
│ 故事标题 / 推荐脚本模式 / 建议故事板模式 / 核心驱动力 │
|
||||
│ / 角色 / 世界观 / 剧情段落 / 情绪路线 / 重点镜头 ... │
|
||||
└──────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 3.2 故事板标签（新增，第 4 个标签）
|
||||
|
||||
排在 剧本 与 分镜 之间：
|
||||
```
|
||||
💡创意 → 🌍设定 → 📝剧本 → 🎬故事板 → 🎬分镜 → 🖼关键帧 → 🎞视频 → 🎙后期
|
||||
```
|
||||
|
||||
内容 = 上面 2.3 的结构 + 「生成草图」按钮（可选，¥0.2/张）。
|
||||
|
||||
### 3.3 阶段条加进度
|
||||
|
||||
顶部显示每个阶段的完成状态（✅/⬜），一眼看出走到哪、还缺什么。
|
||||
|
||||
---
|
||||
|
||||
## 四、落地顺序
|
||||
|
||||
| 步 | 内容 | 交付 |
|
||||
|:--|:--|:--|
|
||||
| **1** | 项目对象加 `script` / `storyboard` 的完整结构（后端 schema + 默认值） | 数据层 |
|
||||
| **2** | 剧本标签重做（段落编辑 + 脚本模式 + 交接清单） | 界面 |
|
||||
| **3** | 故事板标签新建（文字版 + 可选草图） | 界面 |
|
||||
| **4** | 分镜加「镜头功能/转场接口/重点」+ 各标签显示交接清单 | 增强 |
|
||||
| **5** | 阶段进度条 + 平台适配建议 | 收尾 |
|
||||
|
||||
---
|
||||
|
||||
## 五、脚本模式速查（写进提示词用）
|
||||
|
||||
```
|
||||
A 动作预演型 核心=动作系统 每格答：角色在做什么/动作系统变成什么/空间如何被改变
|
||||
B 情绪表演型 核心=情绪变化 公式：平静→微小破绽→被触发→表情管理失败→情绪落点
|
||||
C 对话口播型 核心=信息节奏 公式：抛信息→反应→信息升级→情绪变化→结论/梗/钩子
|
||||
D 产品广告型 核心=痛点机制 公式：痛点→问题升级→方案出现→机制展示→结果→记忆点
|
||||
E 科普解释型 核心=概念可视化 公式：提出问题→原因可视化→过程→冲突变化→结论
|
||||
F 世界观展示型 核心=世界规则 公式：建立世界→进入空间→角色日常→规则→潜在冲突→钩子
|
||||
G 角色出场型 核心=第一印象 公式：环境暗示→局部出现→完整登场→招牌动作→反差→定格
|
||||
H 封面转视频型 核心=静变动态 公式：静态封面→局部微动→主体动作→空间展开→回到记忆点
|
||||
```
|
||||
|
||||
**平台适配**：
|
||||
```
|
||||
抖音 → 动作预演型 / 产品广告型 / 角色出场型
|
||||
小红书 → 情绪表演型 / 封面转视频型 / 世界观展示型
|
||||
视频号 → 对话型 / 情绪型 / 科普型
|
||||
B站 → 世界观型 / 动作预演型 / 科普型
|
||||
```
|
||||
@@ -0,0 +1,111 @@
|
||||
# 首尾帧工作流 —— 现状诊断与建议
|
||||
|
||||
> 起因：用户发现「关键帧工作台生成的图」与「首尾帧衔接」语义混淆，并提出：
|
||||
> 「每个视频是不是应该有首尾帧？生成关键帧时是不是应该有首尾帧的区别？
|
||||
> 需要的话就生成尾帧，不需要就复用上一镜的尾帧 —— 相当于省掉一个」
|
||||
> 日期：2026-10-04 · 状态：**待用户拍板**
|
||||
|
||||
---
|
||||
|
||||
## 一、结论：用户的判断是对的
|
||||
|
||||
**关键帧工作台现在生成的图 = 视频的「首帧」**（不是尾帧，也没区分）。
|
||||
|
||||
**首尾帧衔接现在的做法**：从上一镜的**视频**里抽末帧 → 当本镜首帧。
|
||||
（`pipeline.py:604-620`，2026-10-03 修正过语义，方向是对的）
|
||||
|
||||
**但缺了关键的一环**：**本镜自己的「尾帧」从来没被生成过** →
|
||||
模型只能自由发挥结尾 → **衔接不可控**。
|
||||
|
||||
---
|
||||
|
||||
## 二、现状梳理（逐条实证）
|
||||
|
||||
| 环节 | 现在 | 问题 |
|
||||
|:--|:--|:--|
|
||||
| 关键帧工作台 | 生成「关键帧」，当**首帧**用 | ❌ 没有尾帧概念 |
|
||||
| 关键帧转视频 | 单帧 → 图生视频（模型自由发挥尾帧） | ❌ 结尾不可控 |
|
||||
| 首尾帧衔接 | 抽**上一镜视频**的末帧 → 当本镜首帧 | ⚠️ 视频末帧可能有运动模糊/压缩噪点，不如"生成的尾帧"干净 |
|
||||
| 可灵 `image_tail` | `_tail_image` 变量**从未赋值**，永远是 `""` | ❌ **死代码**：参数传了但一直空 |
|
||||
| 与角色参考图冲突 | 有参考图时**放弃衔接**（代码注释：两者冲突，二选一） | ⚠️ 体验割裂 |
|
||||
|
||||
**接口本身是支持的**（实测我们文档里的规格）：
|
||||
|
||||
```
|
||||
可灵官方：image（首帧）+ image_tail（尾帧）
|
||||
千问代理：media[{type:"first_frame"}, {type:"last_frame"}]
|
||||
|
||||
KF2V 模型 wan2.2-kf2v-flash（¥0.1/秒 480P）：
|
||||
first_frame_url ★必填 + last_frame_url ★必填
|
||||
→ 专为首尾帧设计，最便宜
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 三、建议方案
|
||||
|
||||
### 3.1 关键帧工作台：加「帧类型」
|
||||
|
||||
```
|
||||
镜头 01 的关键帧
|
||||
┌─────────┐ ┌─────────┐
|
||||
│ 首帧 │ │ 尾帧 │ ← 新增一栏（可选）
|
||||
│ [v2.png]│ │ 生成/选用 │
|
||||
└─────────┘ └─────────┘
|
||||
```
|
||||
|
||||
- **首帧**：这一镜从哪里开始（= 现在生成的）
|
||||
- **尾帧**：这一镜在哪里结束（**新增，可选**）
|
||||
|
||||
### 3.2 衔接逻辑改为「接力」
|
||||
|
||||
```
|
||||
镜头 1：首帧 F1 + 尾帧 T1 → 生成视频（F1 → T1）
|
||||
镜头 2：首帧 = T1（复用上一镜尾帧）+ 尾帧 T2 → 生成视频（T1 → T2）
|
||||
镜头 3：首帧 = T2（复用）+ 尾帧 T3 → 生成视频（T2 → T3）
|
||||
...
|
||||
```
|
||||
|
||||
**「复用」是零成本**（只是把上一镜的尾帧文件当本镜首帧）。
|
||||
|
||||
### 3.3 成本对比（4 镜短片）
|
||||
|
||||
| 方案 | 关键帧张数 | 成本 | 衔接质量 |
|
||||
|:--|:--|:--|:--|
|
||||
| 现在 | 4 张（都是首帧） | ¥0.8 | 差（从视频抽末帧，可能糊） |
|
||||
| **建议** | F1 + T1 + T2 + T3 = **4 张** | **¥0.8（相同！）** | **好**（尾帧是生成的，干净、可控） |
|
||||
|
||||
**同样的钱，质量提升明显** —— 因为第 2 镜起"首帧"不用再生成（复用上一镜尾帧）。
|
||||
|
||||
### 3.4 三个衔接模式（界面上选）
|
||||
|
||||
```
|
||||
○ 不衔接（独立） —— 每镜各自首帧，模型自由发挥结尾
|
||||
○ 接力衔接（推荐） —— 上一镜尾帧 = 本镜首帧，无缝
|
||||
○ 首尾帧对（最可控） —— 本镜同时指定首帧 + 尾帧，过渡完全可控
|
||||
（用 KF2V wan2.2-kf2v-flash ¥0.1/秒，最便宜）
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 四、实施步骤（建议顺序）
|
||||
|
||||
| 步 | 内容 | 成本影响 |
|
||||
|:--|:--|:--|
|
||||
| 1 | 关键帧工作台加「帧类型」标记（首帧/尾帧），数据层加字段 | 无 |
|
||||
| 2 | 「关键帧转视频」加首尾帧模式（选首帧 + 选尾帧） | 无 |
|
||||
| 3 | 接线 KF2V（`wan2.2-kf2v-flash`）—— 比可灵 ¥0.6/秒 便宜 6 倍 | **省钱** |
|
||||
| 4 | 衔接模式改为「接力」：自动把上一镜尾帧填为本镜首帧 | 无 |
|
||||
| 5 | 清理 `_tail_image` 死代码（要么用起来，要么删） | 无 |
|
||||
|
||||
---
|
||||
|
||||
## 五、待用户拍板
|
||||
|
||||
1. **是否按此方案做**（建议从第 1、2 步开始，零成本零风险）
|
||||
2. **默认衔接模式**：不衔接 / 接力 / 首尾帧对？
|
||||
3. **尾帧生成时机**：在关键帧工作台**一次性生成**（首帧+尾帧），还是**到转视频时再生成**？
|
||||
4. **与角色参考图冲突怎么办**：
|
||||
- 现在是有参考图就不衔接
|
||||
- 备选：用 KF2V 时**首帧可以就是「角色+场景融合图」**，天然带角色 → 不冲突
|
||||
（因为关键帧本身就是合成图，不需要额外参考图）
|
||||
@@ -0,0 +1,90 @@
|
||||
# 千问AI平台（千问代理）的可灵通道 —— 规格对照
|
||||
|
||||
> 来源：本地官方文档库 `docs/api/raw/qwen/api-reference-video-generation-kling-video-generation-create-task.md`（498 行，OpenAPI spec）
|
||||
> 发现时间：2026-10-05（排查 R2V 端点时顺带发现）
|
||||
|
||||
---
|
||||
|
||||
## 一、核心事实
|
||||
|
||||
**千问AI平台也提供可灵视频生成** —— 与「可灵官方 API」是**两条不同的通道**，
|
||||
字段名完全不同。我们目前用的是**可灵官方**（`local.yaml` 的 `base_url: api-beijing.klingai.com`）。
|
||||
|
||||
| | 可灵官方（我们在用） | 千问代理（千问AI平台） |
|
||||
|---|---|---|
|
||||
| 端点 | `api-beijing.klingai.com` | `maas.qianwenaiapi.com` |
|
||||
| 鉴权 | `Authorization: Bearer api-key-kling-…` | `Authorization: Bearer sk-…`（同一个百炼 key） |
|
||||
| 原生有声字段 | **`sound: "on"/"off"`** | **`parameters.audio: true/false`** |
|
||||
| 首尾帧 | `image` + `image_tail`（顶层） | `input.media[] = [{type:first_frame},{type:last_frame}]` |
|
||||
| 时长 | 5 / 10 秒 | **3–15 秒** |
|
||||
| 分辨率 | 720P / 1080P | std(720P) / pro(1080P) / **4k** |
|
||||
| 多镜头 | 无 | **`multi_shot` + `shot_type` + `multi_prompt`（≤6 镜头）** |
|
||||
| 参考生视频 | 无（需 Elements） | **`omni` 模型的 `refer` 类型** |
|
||||
| 视频编辑 | 无 | **`omni` 的 `base`/`feature` 类型** |
|
||||
|
||||
---
|
||||
|
||||
## 二、千问代理可灵的模型与能力
|
||||
|
||||
| 模型 | 能力 |
|
||||
|---|---|
|
||||
| `kling/kling-v3-turbo-video-generation` | 文生视频、图生视频（**仅首帧**）。不支持 `negative_prompt`（写进 prompt） |
|
||||
| `kling/kling-v3-video-generation` | 文生、图生（**首帧/首尾帧**）、**多镜头叙事** |
|
||||
| `kling/kling-v3-omni-video-generation` | 全部 + **参考生视频**（`refer`）+ **视频编辑**（`base`/`feature`） |
|
||||
|
||||
---
|
||||
|
||||
## 三、关键字段（官方 spec 原文）
|
||||
|
||||
```yaml
|
||||
input.media[]:
|
||||
type: first_frame | last_frame | refer | base | feature
|
||||
first_frame 图生视频首帧
|
||||
last_frame 图生视频尾帧
|
||||
refer 参考图像（omni）
|
||||
base 参考视频（omni）
|
||||
feature 特征参考视频（omni）
|
||||
url: 媒体文件的公网 URL
|
||||
keep_original_sound: yes | no（默认 no，仅 omni 的 base/feature 有效）
|
||||
|
||||
input.prompt: 文本提示词
|
||||
input.negative_prompt: ≤2500 字符（turbo 不支持）
|
||||
input.multi_shot: bool（默认 false）—— 启用须指定 shot_type
|
||||
input.shot_type: intelligence（模型自动分镜）| customize（按 multi_prompt）
|
||||
input.multi_prompt[]: 自定义分镜提示词，最多 6 个镜头，index 从 1 开始
|
||||
|
||||
parameters.duration: 3–15 秒（默认 5）
|
||||
parameters.audio: bool（默认 false）—— **是否自动生成配音** ← 原生有声
|
||||
parameters.watermark: bool（默认 false）
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 四、对我们的意义（待决策）
|
||||
|
||||
**潜在收益**：
|
||||
1. **一个 key 打通可灵 + 万相**（都在千问平台）→ 配置更简单
|
||||
2. **多镜头叙事** —— 一个任务直接出多镜头（我们现在是自己拆镜 + 拼接）
|
||||
3. **3–15 秒** —— 比可灵官方的 5/10 灵活（我们的 `align.py` 为解决音画时长做了变速/裁尾，若能自由定时长可省掉这一步）
|
||||
4. **4K** 输出
|
||||
5. **omni 的 refer** —— 可灵版的「多图参考生视频」
|
||||
|
||||
**风险 / 成本**：
|
||||
- 可灵官方通道**已验证可用**（`sound=on` 实测有音轨、出片正常）
|
||||
- 切通道需重写 `kling_video.py` 的 payload 层（约 1 个模块）
|
||||
- **千问代理的可灵价格未知**（我们只查过万相的价格）
|
||||
- 两条通道并存会增加维护面
|
||||
|
||||
**建议**：
|
||||
- **暂不切换** —— 现有通道稳定，优先完成「关键帧设计 → 关键帧 → 视频 → 成片」主链路
|
||||
- **需要时再切**：如果要用「多镜头叙事」或「3–15 秒自由时长」，再走千问代理
|
||||
- 记入 `docs/参数速查.md`，避免下次又混用两条通道的字段
|
||||
|
||||
---
|
||||
|
||||
## 五、踩坑记录（本次）
|
||||
|
||||
1. **KF2V 端点写错**：`wan2.2-kf2v-flash` 走 `/services/aigc/**image2video**/video-synthesis`，
|
||||
不是 `video-generation/video-synthesis`（后者是 R2V 用的）→ 已修
|
||||
2. **KF2V 的 `duration` 不可传**：官方「固定 5 秒」→ 已移除该参数
|
||||
3. **R2V 的 `prompt` 是必填**：我原来做成可选 → 已改为必填并报错提示
|
||||
@@ -0,0 +1,227 @@
|
||||
# 千问AI平台可用能力总览（从本地 57 篇官方文档里筛出「对我们有用的」）
|
||||
|
||||
> 来源：`docs/api/raw/qwen/`（205 篇官方文档，其中 57 篇是「创建任务」类）
|
||||
> 整理时间：2026-10-05 · 只列**与视频工厂流程相关**的，不是全部
|
||||
|
||||
---
|
||||
|
||||
## 一、我们正在用的（3 个）
|
||||
|
||||
| 能力 | 模型 | 用途 | 状态 |
|
||||
|---|---|---|---|
|
||||
| 首尾帧生视频 | `wan2.2-kf2v-flash` | 关键帧 → 视频（¥0.1/秒） | ✅ 已接 |
|
||||
| 多图参考生视频 | `wan2.6-r2v-flash` | 角色+场景参考（¥0.3/秒） | ⚠️ 通道已写，缺 UI 入口 |
|
||||
| 对口型 | `videoretalk` | 配音后驱动嘴型（¥0.08/秒） | ✅ 已接 |
|
||||
|
||||
---
|
||||
|
||||
## 二、🔴 值得关注的新发现（对我们流程直接有用）
|
||||
|
||||
### ① 首尾帧 —— 有第二个选择
|
||||
```
|
||||
vidu/viduq3-turbo_start-end2video ← Vidu 的 turbo 版首尾帧
|
||||
```
|
||||
**价值**：与 `wan2.2-kf2v-flash` 形成对比。若质量更好或价格更低，值得切换。
|
||||
**待查**：价格、时长限制、是否必须首尾帧。
|
||||
|
||||
### ② 动作控制 —— 可灵 camera_control 的替代
|
||||
```
|
||||
pixverse/pixverse-motioncontrol ← 爱诗 PixVerse
|
||||
```
|
||||
**价值**：我们的可灵 `camera_control` **踩过坑**（`code=1201: 仅 std 模式 + 5s + kling-v1 支持`），
|
||||
实际上限制极多。motioncontrol 可能更通用。
|
||||
**待查**：能否指定镜头运动轨迹、价格。
|
||||
|
||||
### ③ 草图 → 正式图 —— 完美衔接「故事板草图」
|
||||
```
|
||||
wanx-sketch-to-image-lite ← 万相涂鸦作画
|
||||
字段：prompt + style
|
||||
```
|
||||
**价值**：我们已有「故事板草图」（低完成度铅笔稿）功能。
|
||||
这条路能**把草图直接变成正式关键帧** —— 故事板的视觉预演就有了实用出口，不再是死图。
|
||||
**待查**：输入是否必须是线稿、风格选项。
|
||||
|
||||
### ④ 图生动作 —— 人物置换的近亲
|
||||
```
|
||||
wan2.2-animate-move ← 图生动作（不换场景）
|
||||
（我们 `person_swap` 用的是 `wan2.2-animate-mix`，会换场景）
|
||||
```
|
||||
**价值**：当只想「让人物按某段视频动起来」但**保留原场景**时用它。
|
||||
|
||||
### ⑤ 视频放大 —— 4K 输出
|
||||
```
|
||||
pixverse/pixverse-upscale
|
||||
```
|
||||
**价值**：关键帧/成片放大。低成本提升画质的后处理手段。
|
||||
|
||||
---
|
||||
|
||||
## 三、完整能力清单（按用途分类）
|
||||
|
||||
### A. 生视频
|
||||
```
|
||||
wan27-text-to-video · wan27-image-to-video · wan27-reference-to-video
|
||||
wan-text-to-video · wan-reference-to-video · wan30-video（All-in-One）
|
||||
wan2.2-kf2v-flash（首尾帧）· vidu-start-end-to-video（首尾帧·Vidu）
|
||||
vidu-text-to-video · vidu-image-to-video · vidu-reference-to-video
|
||||
happyhorse-text-to-video · happyhorse-image-to-video · happyhorse-reference-to-video
|
||||
pixverse-text-to-video · pixverse-image-to-video · pixverse-reference-to-video
|
||||
kling-video-generation（★可灵三条线，见 docs 12）
|
||||
minimax-h3-video
|
||||
```
|
||||
|
||||
### B. 视频后处理
|
||||
```
|
||||
videoretalk（对口型·我们在用）· pixverse-lipsync（对口型·备选）
|
||||
wan-video-character-swap（视频换人）· wan2.2-animate-move（图生动作）
|
||||
wan-general-video-editing · wan27-video-editing · happyhorse-video-editing
|
||||
video-style-transform（风格重绘）· pixverse-upscale（放大）
|
||||
emo-video（情绪视频）· animate-anyone（让任何人做动作）
|
||||
liveportrait-video（静态人像动起来）
|
||||
```
|
||||
|
||||
### C. 生图 / 图像编辑
|
||||
```
|
||||
wan27-image-gen-edit · wan26-image-gen-edit（我们在用 wan2.7-image-pro）
|
||||
wan21-general-image-editing · wan25-general-image-editing
|
||||
wanx-sketch-to-image（涂鸦作画★）· wanx-style-repaint（风格重绘）
|
||||
wanx-x-painting（扩图）· image-out-painting
|
||||
background-generation · creative-poster（海报）
|
||||
ai-tryon（试穿）· virtual-model（虚拟模特）· shoe-model
|
||||
facechain-generation（★人脸链）· facechain-finetune（人脸微调）
|
||||
kling-image-generation · vidu-image-generation
|
||||
wordart-semantic · wordart-texture · image-erase-completion
|
||||
```
|
||||
|
||||
### D. 数字人 / 音频
|
||||
```
|
||||
wan-s2v（语音驱动数字人，我们在 digital_human 流程用过）
|
||||
wan-image-to-animation（图生动画）
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 四、建议的探索顺序（**都不产生费用，先看文档**）
|
||||
|
||||
1. **`wanx-sketch-to-image`** —— 与我们已有的「故事板草图」形成闭环，投入最小
|
||||
2. **`vidu-start-end-to-video`** —— 首尾帧的第二个选择，可能更优
|
||||
3. **`pixverse-motioncontrol`** —— 替代限制极多的可灵 camera_control
|
||||
4. **`facechain-generation`** —— 角色一致性的另一条路（我们目前靠「套装 + 参考图」）
|
||||
|
||||
---
|
||||
|
||||
## 四·五、💰 价格实测（2026-10-05，`GET /api/v1/models`，零成本）
|
||||
|
||||
| 能力 | 模型 | 价格 | 评价 |
|
||||
|---|---|---|---|
|
||||
| **静态人像动起来** | `liveportrait` | **¥0.02/秒** | 🔥 **全场最便宜**（kf2v 的 1/5） |
|
||||
| 草图 → 正式图 | `wanx-sketch-to-image-lite` | ¥0.06/张 | 很便宜，与我们的故事板草图天然配对 |
|
||||
| 对口型（在用） | `videoretalk` | ¥0.08/秒 | 比 pixverse 版便宜 |
|
||||
| **首尾帧（在用）** | `wan2.2-kf2v-flash` | **¥0.1/秒（480P）· ¥0.2/秒（720P）** | 最便宜的首尾帧 |
|
||||
| 对口型（备选） | `pixverse/pixverse-lipsync` | ¥0.12/秒 | 比 videoretalk 贵 50% |
|
||||
| 视频放大 | `pixverse/pixverse-upscale` | ¥0.15/秒 | 后处理提画质 |
|
||||
| 首尾帧（备选） | `vidu/viduq3-turbo_start-end2video` | ¥0.25/秒（540P）· ¥0.375/秒（720P） | **比 kf2v 贵 2~2.5 倍**，不划算 |
|
||||
| 动作控制 | `pixverse/pixverse-motioncontrol` | ¥0.27/秒（360P）· ¥0.3/秒（540P） | 可灵 camera_control 的替代 |
|
||||
| 多图参考（已写通道） | `wan2.6-r2v-flash` | ¥0.3/秒（720P）· ¥0.5/秒（1080P） | — |
|
||||
| 图生动作 | `wan2.2-animate-move` | ¥0.4/秒（std）· ¥0.6/秒（pro） | 保留原场景的换人 |
|
||||
| 视频换人（在用） | `wan2.2-animate-mix` | ¥0.6/秒（std）· ¥0.9/秒（pro） | — |
|
||||
| 对照：可灵 3.0 | `kling/kling-v3-video-generation` | ¥0.6/秒（720P） | 现行出片默认 |
|
||||
|
||||
### 🔬 kf2v 实测结果（2026-10-05，真实调用）
|
||||
|
||||
```
|
||||
素材：shot_01/v1.png（首帧）+ shot_01/v2.png（尾帧）· 均 720x1280
|
||||
参数：wan2.2-kf2v-flash · 480P · prompt「镜头保持固定，人物自然呼吸，轻微头部动作」
|
||||
结果：✅ 成功 · 耗时 81 秒生成 + 5 秒下载
|
||||
产物：kf2v_test1.mp4 · 1317 KB · **5.00s**（固定）· **720x1280**（跟随首帧宽高比）
|
||||
h264 High / yuv420p / **30fps** · **无音轨**（KF2V 本身无声，符合预期）
|
||||
费用：5 秒 × ¥0.1 = **¥0.5**
|
||||
```
|
||||
|
||||
**实测确认**：
|
||||
1. **时长固定 5 秒**（传 duration 会被拒，文档说的是对的）
|
||||
2. **输出宽高比跟随首帧**（首帧 720x1280 → 输出 720x1280 竖屏）
|
||||
3. **无声** —— 需要声音要另配（TTS+口型，或改用可灵原生有声）
|
||||
|
||||
**结论**：
|
||||
- **`liveportrait` ¥0.02/秒 值得重点关注** —— 如果它能满足「让角色说话/做表情」的需求，
|
||||
那比 kf2v 又便宜 5 倍。**适合口播类镜头**（人像基本不动，只需要表情与嘴型）
|
||||
- **kf2v ¥0.1/秒仍是「动作镜头」的最优解**
|
||||
- vidu 的首尾帧比万相贵 2 倍多，**不值得接**
|
||||
- 对口型用 videoretalk（¥0.08）而非 pixverse（¥0.12）
|
||||
|
||||
---
|
||||
|
||||
## 四·六、🔥 `liveportrait` 完整规格（已查清，2026-10-05）
|
||||
|
||||
**它不是「让任意视频动起来」，而是「数字人播报」**：
|
||||
|
||||
```
|
||||
模型：liveportrait（灵动人像）
|
||||
用途：人物肖像图 + 语音音频 → 口型与音频同步的播报视频
|
||||
官方定位：数字人播报、虚拟主播
|
||||
|
||||
必填：
|
||||
input.image_url 人物肖像图（jpeg/jpg/png/bmp/webp，<10MB，宽高比≤2，最长边≤4096）
|
||||
input.audio_url 驱动音频（wav/mp3，<15MB，时长 1 秒 ~ 3 分钟，须含清晰人声）
|
||||
|
||||
参数：
|
||||
parameters.template_id normal | calm | active
|
||||
calm 推荐播报场景（小幅度头部运动）
|
||||
parameters.eye_move_freq 眨眼频率（≥0）
|
||||
|
||||
端点：/services/aigc/image2video/video-synthesis
|
||||
前置：建议先调 liveportrait-detect 检测图片是否合规
|
||||
价格：**¥0.02/秒**
|
||||
```
|
||||
|
||||
### ★ 为什么它对我们特别合适
|
||||
|
||||
**输入要求正好是我们的现有资产**：
|
||||
- `image_url` = 人物肖像图 → **我们的「角色定妆照」正是这个** ✓
|
||||
- `audio_url` = 清晰人声 → **我们的 TTS 配音正是这个** ✓
|
||||
|
||||
### 成本对比（5 秒口播镜头）
|
||||
|
||||
| 方案 | 成本 | 说明 |
|
||||
|---|---|---|
|
||||
| 现在：kf2v(¥0.1/秒) + videoretalk(¥0.08/秒) | **¥0.9** | 首尾帧+对口型两段式 |
|
||||
| **liveportrait** | **¥0.1** | 一步到位（图 + 音频 → 口播视频） |
|
||||
| 可灵原生有声（sound=on） | ¥3.0 | 质量最好但最贵 |
|
||||
|
||||
→ **¥0.1 vs ¥0.9 —— 便宜 9 倍**（对比可灵原生有声便宜 30 倍）
|
||||
|
||||
### 🔬 实测结果（2026-10-05，真实调用）
|
||||
|
||||
```
|
||||
素材：害羞美女患者/ref_face_closeup.png（1248x832 横屏肖像）
|
||||
+ seg_01.wav（4.00 秒 TTS 配音）
|
||||
参数：template_id=calm
|
||||
结果：✅ 成功 · 耗时 71 秒生成 + 2 秒下载
|
||||
产物：lp_test1.mp4 · 797 KB · 4.05s · 1024x682 · h264 High / yuv420p / aac 44.1kHz
|
||||
音量 mean -37.7dB / max -12.0dB（源音频 -37.2 / -11.6 → **音频完整保留**）
|
||||
费用：4 秒 × ¥0.02 = **¥0.08**
|
||||
```
|
||||
|
||||
**两个实测确认的要点**：
|
||||
1. **时长由音频决定** —— 源 4.00s → 出 4.05s（≈ 音频时长，不是固定值）
|
||||
2. **⚠️ 输出分辨率跟随输入图片** —— 输入 1248x832 横屏 → 输出 1024x682 横屏。
|
||||
**竖屏短剧必须用竖屏肖像图**，否则出片是横的。
|
||||
|
||||
（产物在 `agent-local/runtime/ave/test_liveportrait/lp_test1.mp4`）
|
||||
|
||||
### 适用边界（重要）
|
||||
|
||||
- ✅ **口播 / 播报类镜头**（人物对着镜头说话，不需要大幅动作）→ 就是我们的 `talking_head`
|
||||
- ❌ **有动作的镜头**（走位、打斗、转身）→ **不适用**，仍走 kf2v / 可灵
|
||||
|
||||
**建议的接入方式**：在「🎞 视频」标签，按分镜的 `type` 自动推荐：
|
||||
`talking_head` → 默认建议 liveportrait；其他 → kf2v / 可灵。
|
||||
|
||||
---
|
||||
|
||||
## 五、注意
|
||||
|
||||
- 以上**都没有实测**，只是从官方文档 presence 判断「能力存在」
|
||||
- **价格全部待查**（可用 `GET /api/v1/models` 查，见 `02_百炼可用能力与价格.md` 的方法）
|
||||
- 接任何一个之前，**先按 `docs/参数速查.md` 的纪律**：查文档 → 零成本探测 → 才真实调用
|
||||
Reference in New Issue
Block a user