root/ai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: expand novel IP and production workflows

Browse Source
This commit is contained in:
www
2026-09-18 08:14:05 +02:00
parent b2ae4600b4
commit d9c81a3ac0
235 changed files with 117971 additions and 2721 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/ai成本.md
+135
View File
@@ -0,0 +1,135 @@
按 **10 秒单条视频**算，先给你一个实用对比。美元我按 **$1≈¥7.2** 粗算，实际以付款汇率为准。
| 平台/模型 | 常用规格 | 10s 单价约 | 人民币约 | 备注 |
| ------------------------------ | -------------: | --------: | --------: | ------------------------ |
| **海螺 MiniMax Hailuo 2.3 Fast** | 768P 10s | **$0.32** | **¥2.3** | 目前最便宜的官方 API 档位之一 |
| **海螺 MiniMax Hailuo 2.3 / 02** | 768P 10s | **$0.56** | **¥4.0** | 比 Fast 稳一些 |
| **海螺 MiniMax Hailuo-02** | 512P 10s | **$0.15** | **¥1.1** | 低清测试用 |
| **Seedance 2.0 Fast** | 720P 10s | 约 **¥8** | **¥8** | 按公开费用参考折算 |
| **Seedance 2.0 标准** | 720P 10s | 约 **¥10** | **¥10** | 480P 约 ¥5，1080P 约 ¥25 左右 |
| **可灵 Kling v3 无原生音频** | 720P 10s | **$0.84** | **¥6.0** | 官方开放平台按秒计费 |
| **可灵 Kling v3 无原生音频** | 1080P 10s | **$1.12** | **¥8.1** | 画质更高 |
| **可灵 Kling v3 带原生音频** | 720P 10s | **$1.26** | **¥9.1** | 带音频会贵 |
| **可灵 Kling v3 带原生音频** | 1080P 10s | **$1.68** | **¥12.1** | 成片感更强 |
| **Google Veo 3.1 Lite** | 720P 10s | **$0.50** | **¥3.6** | 谷歌最低档 |
| **Google Veo 3.1 Fast** | 720P 10s | **$1.00** | **¥7.2** | 性价比档 |
| **Google Veo 3.1 Standard** | 720P/1080P 10s | **$4.00** | **¥28.8** | 谷歌标准档，贵很多 |
来源口径：海螺用 [MiniMax 官方 Pay-as-you-go 价格](https://platform.minimax.io/docs/guides/pricing-paygo)，可灵用 [KlingAI Open Platform 视频价格](https://kling.ai/document-api/pricing/base/video)，谷歌用 [Gemini API Veo 价格](https://ai.google.dev/gemini-api/docs/pricing)，Seedance 参考 [火山 Seedance 2.0 活动页](https://www.volcengine.com/activity/seedance2)和公开火山方舟费用折算。
## 可灵 Kling Native Audio API 入库表
下面只记录 **API / Developer Platform** 口径，不和网页版 credits 混算。人民币按 **$1≈¥6.79** 粗算，系统已按 `provider_configs.cost_rule_json` 写入秒级单价。
| Provider Code | 模型 | 有声音模式 | 分辨率 | 美元单价 | 10s 美元 | 10s 人民币约 | 建议用途 |
| --- | --- | --- | --- | ---: | ---: | ---: | --- |
| `kling-v3-native-audio-720p-video` | Kling 3.0 | Native Audio | 720P | **$0.126/s** | **$1.26** | **¥8.56** | 标准有声测试 |
| `kling-v3-native-audio-video` | Kling 3.0 | Native Audio | 1080P | **$0.168/s** | **$1.68** | **¥11.41** | 正式高清有声镜头 |
| `kling-v3-omni-native-audio-720p-video` | Kling 3.0 Omni | Native Audio | 720P | **$0.112/s** | **$1.12** | **¥7.61** | 低成本有声测试，需验证图生视频兼容 |
| `kling-v3-omni-native-audio-1080p-video` | Kling 3.0 Omni | Native Audio | 1080P | **$0.140/s** | **$1.40** | **¥9.51** | 高清有声对比，需验证图生视频兼容 |
| `kling-v3-turbo-native-audio-720p-video` | Kling 3.0 Turbo | Native Audio | 720P | **$0.112/s** | **$1.12** | **¥7.61** | 最低成本 API 有声小样优先测试 |
| `kling-v3-turbo-native-audio-1080p-video` | Kling 3.0 Turbo | Native Audio | 1080P | **$0.140/s** | **$1.40** | **¥9.51** | 正式有声小样对比 |
备注：2.6 Native Audio 目前只保留网页版 credits 参考，没有写入 API Provider，避免把网页 credits 和 API units 混用。Omni/Turbo 的图生视频字段可能随账号能力变化，批量前必须先做单镜小样。
### 可灵 v3 视频生成模式同步
系统内 Kling v3 / v3 Turbo / v3 Omni 图生视频统一按以下生产能力配置：
| 模式 | 系统字段 | 用法 |
| --- | --- | --- |
| 首帧生成 | `image` | 单张首帧 + Prompt，适合反应镜、道具插入、简单表演 |
| 首尾帧生成 | `image` + `image_tail` | 首帧和尾帧共同锁定动作落点，适合走位、递文件、签字、拿话筒、镜头推进 |
| 多图参考 | `reference_images`，最多 4 张 | 补充角色主锚点、场景锚点、道具锚点；不替代首帧/尾帧 |
时长策略：Kling v3 系列系统配置为 **3-15 秒**。不要固定 25 格，也不要每镜固定 5 秒；按剧情动作完整度拆分。反应/插入镜 3-5 秒，普通对白/冲突 5-8 秒，连续动作/入场/签字/拿话筒 8-15 秒。
**简单结论：**
海螺最便宜，适合批量测试分镜；Seedance 价格中等，适合你现在这种短剧分镜流水线；可灵贵一点但动作/镜头稳定性通常更强；Google Veo 标准档最贵，适合关键镜头、封面级片段，不适合全量批量跑。
## 分镜关键帧图片成本
按竖屏关键帧 **1024×1536** 估算，系统数据库当前已按下面口径写入 `provider_configs.cost_rule_json`：
| 模型/平台 | 单张约成本 | 单张人民币约 | 1000 张约成本 | 1000 张人民币约 | 系统用途 |
| --- | ---: | ---: | ---: | ---: | --- |
| **OpenAI GPT Image 2 Low** | **$0.005** | **¥0.04** | **$5** | **¥36** | 草稿、分镜预览 |
| **OpenAI GPT Image 2 Medium** | **$0.041** | **¥0.30** | **$41** | **¥295** | 默认配置，正式关键帧、可用级 |
| **OpenAI GPT Image 2 High** | **$0.165** | **¥1.19** | **$165** | **¥1188** | 海报级、重点镜头精修 |
| **OpenAI GPT Image 1 Mini Medium** | **$0.015** | **¥0.11** | **$15** | **¥108** | 低成本预览参考，当前未单独接入 provider |
| **Seedream 批量关键帧估算** | **$0.03** | **¥0.22** | **$30** | **¥216** | 批量关键帧、角色参考、中文短剧风格 |
当前默认策略：
| 流程 | 默认模型 | 默认质量 | 成本口径 |
| --- | --- | --- | --- |
| 批量分镜关键帧 | Seedream 4.5 / 5.0 | 平台默认 | $0.03 / 张，约 ¥0.22 / 张 |
| 重点镜头精修 | OpenAI GPT Image 2 | medium | $0.041 / 张，约 ¥0.30 / 张 |
| 海报/封面级镜头 | OpenAI GPT Image 2 | high | $0.165 / 张，约 ¥1.19 / 张 |
备注：OpenAI 图片真实账单可能按 token、质量和尺寸浮动；这里先按 1024×1536 生产估算价做项目预算。Seedream 精确费用以火山账单为准。
可以，按你上面问的 **Seedance / 可灵 / 海螺 / Google Veo**，单条视频时长大概这样：
| 平台/模型 | 单条支持时长 | 重点备注 |
| ----------------------------------------- | ---------------: | --------------------------------- |
| **海螺 Hailuo 2.3 / 2.3 Fast** | **6秒 / 10秒** | 768P 支持 6/10 秒；1080P 基本只支持 6 秒 |
| **海螺 Hailuo-02** | **6秒 / 10秒** | 512P、768P 支持 6/10 秒；1080P 只支持 6 秒 |
| **Google Veo 3.1 Standard / Fast / Lite** | **4秒 / 6秒 / 8秒** | 最长 8 秒；1080P/4K 或参考图功能通常必须 8 秒 |
| **Google Veo 2** | **5秒 / 6秒 / 8秒** | 老模型，不带声音 |
| **Seedance 1.0 Lite** | **5秒 / 10秒** | 480P / 720P，火山文章写明支持 5s、10s |
| **Seedance 2.0** | **4秒-15秒** | 新版支持 4-15 秒，但你现在主要是风控问题，不建议主用 |
| **可灵 Kling 2.5 / 2.6 / O1** | 通常 **5秒 / 10秒** | 10 秒是比较常用的生产档 |
| **可灵 Kling 3.0** | 最高约 **15秒** | 公开资料显示 3.0 支持到 15 秒，多镜头能力更强 |
来源：海螺官方 API 文档列了不同模型/分辨率的 `duration` 支持值；Google Veo 官方文档列了 `durationSeconds` 为 4/6/8；火山文章写 Seedance 1.0 lite 支持 5s/10s；Seedance 2.0 论文写 4-15 秒；可灵 3.0 公开资料显示最高 15 秒。([MiniMax](https://platform.minimax.io/docs/api-reference/video-generation-i2v)) ([Google Veo](https://ai.google.dev/gemini-api/docs/video)) ([火山 Seedance](https://developer.volcengine.com/articles/7504284064976502823)) ([Seedance 2.0](https://arxiv.org/abs/2604.14148)) ([Kling](https://en.wikipedia.org/wiki/Kling_AI))
如果按你做 **40秒一集短剧** 来算：
| 平台 | 推荐拼法 |
| ------------ | ----------------------- |
| **海螺** | 4 条 × 10秒 |
| **可灵** | 4 条 × 10秒，或 3 条 × 15秒再剪 |
| **Seedance** | 4 条 × 10秒，或 3 条 × 15秒 |
| **Veo** | 5 条 × 8秒 |
所以最适合自动化短剧流水线的是：
**海螺/可灵按 10 秒拆分，Veo 按 8 秒拆分。**
可以，上面这几家按**单条视频可生成时长**大概这样：
| 平台 | 模型/档位 | 单条时长 | 适合用法 |
| ---------------- | ------------------------------ | ---------------: | ------------------ |
| **海螺 Hailuo** | Hailuo 2.3 / 2.3 Fast 768P | **6秒 / 10秒** | 最适合批量短剧分镜 |
| **海螺 Hailuo** | Hailuo 2.3 / 2.3 Fast 1080P | **6秒** | 重要镜头高清版 |
| **海螺 Hailuo** | Hailuo-02 512P / 768P | **6秒 / 10秒** | 低成本测试 |
| **Seedance** | Seedance 1.0 Lite | **5秒 / 10秒** | 以前适合测试，现在你这边风控太烦 |
| **Seedance** | Seedance 2.0 | **4-15秒** | 时长弹性好，但图片/真人风控影响生产 |
| **可灵 Kling** | Kling 1.x / 2.x 常规档 | **5秒 / 10秒** | 常规短剧分镜 |
| **可灵 Kling** | Kling 3.0 / v3 系列 | **最高约 15秒** | 长一点的动作镜头、正式生成 |
| **Google Veo** | Veo 3.1 Lite / Fast / Standard | **4秒 / 6秒 / 8秒** | 关键镜头，自带声音 |
| **Google Veo** | Veo 3 旧版 | **短视频档，主要 8秒左右** | 不建议新接，已废弃/迁移到 3.1 |
| **Google Veo 2** | Veo 2 | **5-8秒左右** | 旧模型，不带原生声音 |
资料口径：海螺官方 API 文档写明 2.3/2.3 Fast 在 768P 支持 6s/10s，1080P 支持 6s；Google Veo 3.1 官方文档支持 `durationSeconds` 为 4/6/8；Seedance 2.0 官方技术资料写支持 4-15 秒；可灵 v3 公开平台资料按秒计费，当前长视频档一般按最高约 15 秒处理。
**按你做 40 秒短剧来算：**
| 平台 | 40秒一集要几条 |
| ------------- | -----------------: |
| 海螺 10秒 | **4条** |
| 可灵 10秒 | **4条** |
| 可灵 15秒 | **3条生成45秒，再剪到40秒** |
| Seedance 15秒 | **3条生成45秒，再剪到40秒** |
| Google Veo 8秒 | **5条** |
| 海螺 1080P 6秒 | **7条左右** |
我的建议：
**普通批量短剧：海螺/可灵按 10秒一镜设计。**
**高潮镜头：可灵 15秒或 Veo 8秒。**
**1080P 不要全程用 6秒，不然镜头数量变多，成本和拼接压力都会上来。**
docs/chatgpt/AUTO_RULES_AI_SHORT_DRAMA.md
+375
View File
@@ -0,0 +1,375 @@
# AI仿真人短剧自动化规则库 V1
> 目标：把课程里的人工导演经验，转成系统可以执行的规则。适合接入现有 LiveActionPromptBuilderService、AI Router、Shot Planner、Character Library。
## 1. Shot Planner 规则
### 1.1 一集结构
```yaml
episode_structure:
target_duration: 45-60s
shot_count: 8-12
default_shot_duration: 5-6s
max_single_shot_duration: 8s
```
### 1.2 镜头角色 shot_role
```yaml
shot_roles:
hook:
position: first_3_seconds
purpose: 强钩子，快速制造冲突或悬念
conflict:
purpose: 角色冲突、羞辱、威胁、退婚、分手
reaction:
purpose: 角色震惊、隐忍、后悔
reveal:
purpose: 身份、资产、权力、道具揭示
premium_moment:
purpose: 爽点/打脸/反转
bridge:
purpose: 场景衔接、过渡、环境镜头
cliffhanger:
purpose: 结尾悬念，引导下一集
```
### 1.3 镜头拆分规则
```yaml
shot_split_rules:
if_dialogue_too_long:
action: split_into_reaction_shots
if_action_score_gt_5:
action: split_action_beats
if_scene_contains_multiple_events:
action: one_shot_one_main_action
if_duration_gt_8s:
action: split_to_2_clips
```
---
## 2. Camera Engine 规则
### 2.1 情绪与景别
```yaml
camera_by_emotion:
emotion_1_3:
shot: medium_shot
move: static_or_slow_push
emotion_4_6:
shot: medium_close_up
move: slow_dolly_in
emotion_7_8:
shot: close_up
move: slow_push_in
emotion_9_10:
shot: extreme_close_up
move: quick_push_or_slow_dramatic_push
```
### 2.2 重要度与运镜
```yaml
camera_by_importance:
importance_lte_4:
shot: medium_shot
move: stable_camera
importance_5_7:
shot: medium_close_up
move: slow_dolly_in
importance_gt_7:
shot: close_up_or_low_angle
move: cinematic_push_in
route_tier: premium
```
### 2.3 常见场景运镜
```yaml
scene_camera_templates:
breakup:
shot: two_shot_to_close_up
move: slow_dolly_in
mood: emotional_tension
humiliation:
shot: over_shoulder_then_reaction_close_up
move: quick_push_in
mood: oppressive
rich_arrival:
shot: low_angle_wide_to_medium
move: slow_motion_dolly
mood: powerful
asset_reveal:
shot: insert_close_up
move: slow_push_in
mood: shocking
regret:
shot: close_up
move: handheld_slight_shake
mood: panic_and_regret
boardroom:
shot: wide_establishing_then_close_up
move: slow_push
mood: business_pressure
```
---
## 3. Character Consistency 规则
### 3.1 主角最小素材要求
```yaml
character_min_assets:
required:
- front_face
- half_body
- full_body
- side_face
- main_outfit
recommended:
- formal_outfit
- casual_outfit
- expression_sheet
- action_reference
```
### 3.2 角色进入正式生成前的测试
```yaml
character_consistency_test:
shots:
- walk_forward
- sit_down
- turn_head
- phone_call
- enter_car
pass_score: 80
fail_action:
- regenerate_anchor_image
- simplify_prompt
- reduce_motion_complexity
```
### 3.3 Actor Lock 规则
```yaml
actor_lock_rules:
only_include_characters_in_current_shot: true
include_anchor_asset: true
include_appearance_rules: true
include_wardrobe_rules: true
include_negative_rules: true
avoid_all_project_characters_in_prompt: true
```
---
## 4. Prompt Builder 规则
### 4.1 标准 Prompt 结构
```yaml
prompt_sections:
- project_context
- shot_context
- character_lock
- scene_location
- main_action
- camera_shot
- camera_movement
- performance
- lighting
- style
- sound_cue
- negative_constraints
```
### 4.2 视频模型通用约束
```yaml
video_prompt_constraints:
one_main_action_per_clip: true
avoid_scene_cut_inside_clip: true
avoid_extra_characters: true
avoid_face_change: true
avoid_outfit_change: true
avoid_multiple_camera_angles_in_one_clip: true
avoid_long_dialogue_if_no_lipsync: true
```
### 4.3 无 Lip Sync 时的说话镜头规则
```yaml
no_lipsync_dialogue_strategy:
preferred_shots:
- side_face
- back_view
- over_shoulder
- reaction_shot
- medium_shot
avoid:
- front_face_mouth_close_up
- long_direct_speaking
post_process:
- tts
- subtitles
- light_mouth_movement
```
---
## 5. Router 规则
### 5.1 普通镜头
```yaml
normal_shot:
condition:
importance_lte: 7
action_lte: 5
provider: hailuo
fallback:
- jimeng_seedance
- mock
```
### 5.2 高价值镜头
```yaml
premium_shot:
condition_any:
importance_gt: 7
action_gt: 5
scene_type_in:
- reveal
- rich_arrival
- fantasy_effect
- dimensional_break
- emotional_peak
provider: kling_or_stronger
fallback:
- hailuo
- seedance
- mock
```
### 5.3 Hailuo 不适合的镜头
```yaml
hailuo_risk_scenes:
high_risk:
- fight
- rolling
- fast_running
- complex_magic
- crowd_scene
- multiple_character_interaction
- long_front_face_dialogue
action:
- reduce_motion
- split_shots
- route_to_premium_provider
```
---
## 6. Scene Template 规则
### 6.1 都市逆袭优先场景
```yaml
urban_drama_safe_locations:
- luxury_hotel_lobby
- banquet_hall
- coffee_shop
- city_street_night
- luxury_car_exterior
- luxury_car_interior
- bank_vip_room
- office
- boardroom
- apartment_living_room
```
### 6.2 暂缓题材/场景
```yaml
avoid_in_mvp:
- ancient_war
- large_crowd_battle
- wuxia_fight
- xianxia_complex_spell
- fantasy_beast_interaction
- multi_actor_choreography
```
---
## 7. QA 规则
### 7.1 片段质检维度
```yaml
clip_quality_check:
face_consistency: 30
outfit_consistency: 15
action_completion: 20
scene_consistency: 10
camera_quality: 10
artifacts: 10
subtitle_sync_ready: 5
pass_score: 80
```
### 7.2 自动修复策略
```yaml
qa_retry_policy:
score_gte_80: pass
score_70_79:
action: retry_same_provider_with_simplified_prompt
score_60_69:
action: retry_with_fallback_provider
score_lt_60:
action: manual_required
```
---
## 8. 成本控制规则
```yaml
cost_rules:
mvp_target_cost_per_episode: <=20 RMB
normal_provider_ratio: 80%
premium_provider_ratio: <=20%
reuse_asset_ratio_target: >=30%
retry_limit_per_shot: 2
after_two_failures: manual_required
```
---
## 9. 第一阶段推荐执行
```yaml
phase_1:
project: 被未婚妻退婚后我成了首富
episode: 1
providers:
script: deepseek
video: hailuo
tts: optional
lipsync: disabled
focus:
- prompt_builder_v2
- character_anchor
- 6s_clip_generation
- ffmpeg_concat
- qa_score
```
docs/chatgpt/Actor.md
+556
View File
@@ -0,0 +1,556 @@
这两条我认为是你这次课程分析里面，**价值最高的新增需求**，而且和你现有架构完全兼容，不需要推翻重做。
直接发给 Codex。
# V2 需求补充（基于课程分析）
## 优先级
P0
原因：
不是新增AI平台。
不是新增模型。
而是提升：
* 角色一致性
* 长期生产效率
* Prompt质量
* 项目复用率
---
# 需求一：Actor Casting Library（AI演员库）
## 问题
当前系统：
```text
项目
↓
角色
↓
定妆
```
每个项目独立。
存在问题：
```text
重复创建角色
角色资产无法复用
角色脸无法沉淀
无法形成长期演员资产库
```
---
## 新架构
改为：
```text
Global Actor
↓
Project Character
↓
Character Styling
↓
Character State
```
---
# Global Actor（全局演员）
新增概念：
AI演员
类似真人影视公司的演员。
例如：
```text
演员A
霸总脸
演员B
清纯女主脸
演员C
反派脸
演员D
外卖员脸
```
---
## 数据表
global_actors
```sql
id
name
gender
age_range
face_description
appearance_tags
personality_tags
reference_image_id
status
created_at
```
---
# Actor Assets
一个演员拥有多套标准图
---
actor_assets
```sql
id
actor_id
asset_type
image_id
```
---
asset_type
```text
front_face
left_face
right_face
full_body
half_body
smile
angry
cry
injured
```
---
# Project Character
项目角色
---
例如：
演员A
↓
项目1
顾辰
↓
项目2
林凡
↓
项目3
陆沉
---
character_castings
```sql
id
project_id
character_id
global_actor_id
```
---
# Character Styling
项目级定妆
例如：
顾辰
```text
黑色西装
总裁
冷峻
成熟
```
---
林凡
```text
蓝色外卖服
普通
隐忍
```
---
character_stylings
```sql
id
character_id
hair_style
outfit
profession
visual_style
prompt
```
---
# Character State
角色状态系统
---
character_states
```sql
id
character_id
state_code
state_name
```
---
默认状态：
```text
normal
business
rich
poor
injured
angry
blackened
```
---
Prompt Builder
自动读取：
```text
演员
+
定妆
+
状态
```
生成最终Prompt。
---
# UI
创建角色时：
新增：
```text
从演员库选择
```
或者：
```text
创建新演员
```
---
# 需求二：Story Workshop（故事工坊）
## 问题
当前：
```text
AI生成
↓
确认
```
流程太简单。
缺少：
```text
反复修改
版本管理
创作迭代
```
---
# 新架构
```text
创意
↓
大纲
↓
故事圣经
↓
章节
↓
剧本
```
每一步支持：
```text
修改
重生成
版本保存
定稿
```
---
# Story Versions
story_versions
```sql
id
story_id
version_no
content
status
created_at
```
---
status
```text
draft
review
approved
final
```
---
# Episode Versions
episode_versions
```sql
id
episode_id
version_no
content
status
```
---
# Script Versions
script_versions
```sql
id
script_id
version_no
content
status
```
---
# 工作流
例如：
```text
原创小说
↓
AI生成V1
↓
人工修改
↓
AI优化V2
↓
人工修改
↓
AI优化V3
↓
设为最终版
```
---
# UI
新增：
故事工坊
显示：
```text
版本1
版本2
版本3
最终版
```
支持：
```text
对比
恢复
设为最终版
```
---
# 最终目标
系统形成：
```text
Actor Workshop
（演员工坊）
Story Workshop
（故事工坊）
Prompt Workshop
（提示词工坊）
```
成为AI短剧生产系统核心资产。
而不是单纯调用AI生成内容。
我看完课程和你当前架构后，这两个需求的价值远高于再接一个新视频模型。
因为：
```text
模型 = 大家都能买
演员库 = 你的资产
故事工坊 = 你的资产
```
这两块做出来以后，你的系统就开始从“AI工具集合”变成“AI短剧生产平台”了。
docs/chatgpt/CODEX_OPTIMIZATION_NOTES.md
+277
View File
@@ -0,0 +1,277 @@
# Codex优化建议：课程规则接入现有系统 V1
> 基于你提供的 CURRENT_ARCHITECTURE.md 与课程拆解。结论：不建议大改架构，重点做 Prompt Builder V2、规则库接入、角色一致性测试台、队列化补强。
## 1. 当前架构判断
现有系统已经具备生产系统骨架：
- Story Bible ✅
- Character Library ✅
- ActorProfile ✅
- ActorLock ✅
- Prompt Builder V1 ✅
- AI Router ✅
- Provider 抽象 ✅
- FFmpeg ✅
- QA/重试 ✅
- 成本日志 ✅
- LipSync 占位 ✅
因此课程内容不应导致重构，而应转成规则和模板进入现有模块。
---
## 2. 优先开发 P0
### P0-1 Prompt Builder V2
目标：把课程里的提示词结构拆成可配置模板。
建议新增或强化表：
```text
prompt_templates
prompt_template_sections
negative_prompt_templates
scene_templates
camera_templates
sound_cue_templates
```
Prompt Builder 输入应包含：
```json
{
"scene_type": "rich_arrival",
"shot_role": "premium_moment",
"emotion_score": 8,
"importance_score": 9,
"action_score": 3,
"provider_code": "minimax_hailuo_23_fast",
"characters": [],
"location": "rainy city street",
"main_action": "butler steps out of Rolls-Royce"
}
```
输出：
```json
{
"prompt": "...",
"negative_prompt": "...",
"template_ids": [],
"rules_applied": []
}
```
### P0-2 Scene Type 标准化
需要统一 scene_type 枚举：
```text
engagement_breakup
humiliation
lonely_exit
rich_arrival
identity_reveal
asset_reveal_insert
regret_reaction
regret_return
power_exit
bank_balance_reveal
boardroom_face_slap
ceo_entrance
dimensional_break_laptop
dharma_giant_form
```
### P0-3 Camera Engine
把 emotion/importance/action 转换为 camera shot 和 movement：
```text
emotion > 8 -> close_up / slow_push_in
importance > 7 -> premium / low_angle_or_close_up
action > 5 -> split_action_beats or premium provider
```
---
## 3. 优先开发 P1
### P1-1 Character Consistency Test Bench
新增角色测试入口，不依赖剧情：
```text
生成同一角色 5 个动作镜头：
1. walk forward
2. sit down
3. turn head
4. phone call
5. enter car
```
质检维度：
```text
face consistency
hair consistency
outfit consistency
body consistency
action completion
```
只有通过一致性测试的角色，才建议进入正式短剧项目。
### P1-2 Asset Library 运营化
课程强调道具/场景/神兽设计。对你先做都市短剧，应优先沉淀：
```text
豪车
酒店
宴会厅
咖啡厅
银行VIP室
集团办公室
会议室
黑金卡
股权文件
合同
```
### P1-3 Prompt模板绑定 Provider Profile
Hailuo、Kling、Seedance 应有不同 Prompt Profile。
Hailuo：
```text
短动作
单镜头
单主要动作
避免复杂表演
```
Kling：
```text
高价值动作
强运镜
高潮镜头
```
Seedance/Vidu：
```text
视觉冲击
特效
次元壁
```
---
## 4. 优先开发 P2
### P2-1 Worker 队列化
CURRENT_ARCHITECTURE 中已经指出重任务仍有同步执行。建议优先迁移：
```text
video_clip_generation
clip_quality_check
clip_retry
ffmpeg_episode_render
post_production_mix
```
每个任务必须支持：
```text
pause
resume
retry
cancel
cost_freeze
cost_release
```
### P2-2 ROI回流
把 ProviderLog 与平台播放数据结合：
```text
shot_type -> cost -> success_rate -> play_data -> ROI
```
未来 Router 不只按质量路由，还按 ROI 路由。
---
## 5. 不建议现在做
暂缓：
- 全量 Lip Sync
- 全量接入 Veo / Runway
- 同时做中英多语言
- 古装/修仙/战争大场景
- 推倒重写 Provider 层
- 推倒重写数据库
---
## 6. 给 Codex 的执行指令
```text
请不要重构现有系统架构。
基于当前 LiveActionPromptBuilderService、AI Router、StoryboardShot、ActorProfile、Provider Profile 实现 Prompt Builder V2。
目标：
1. 增加 scene_type 标准模板；
2. 增加 camera_rules / emotion_rules / negative_prompt_templates；
3. 根据 scene_type + scores + provider_code 自动选择模板；
4. Prompt 输出必须记录 template_ids 和 rules_applied；
5. 不修改已有 API 兼容性；
6. 增加单元测试或最小测试用例；
7. 保留当前 Hailuo 流程，只增强 prompt 质量。
```
---
## 7. 第一条实测建议
项目：
```text
《被未婚妻退婚后，我成了首富》第1集
```
只测：
```text
DeepSeek + Hailuo + Prompt Builder V2 + FFmpeg
```
不要接：
```text
Lip Sync
Kling
Veo
多语言
自动发布
```
目标：
```text
45-60秒
8-10个镜头
总成本 <=20元
角色一致性 >=80
成片可看懂
```
docs/chatgpt/COURSE_SUMMARY_AI_SHORT_DRAMA.md
+293
View File
@@ -0,0 +1,293 @@
# AIGC仿真人剧课程拆解总结 V1
> 说明：本版基于已上传 6 个课程录屏的视频画面、目录、课件页和操作演示进行拆解，重点不是复述课程，而是提炼为你当前“AI仿真人短剧自动化流水线”可落地的系统规则。
## 0. 总体判断
这套课不是单纯工具注册教学，核心价值在于把“人工影视制作流程”拆成可迁移到系统的几个节点：
```text
剧本/小说
↓
剧本改编
↓
分镜头脚本
↓
角色/场景/道具美术设计
↓
图片/关键帧生成
↓
视频提示词
↓
视频模型生成
↓
剪辑、音乐、音效、台词
↓
成片
```
对你当前系统最有价值的部分不是“用哪个工具”，而是：
- 分镜规划方法
- 角色一致性方法
- Prompt结构化方法
- 镜头语言、运镜、动作、音效的拆分方法
- 手工流程如何转为自动化规则
你的系统架构已经具备：Story Bible、Character Library、Actor Profile、Actor Lock、Prompt Builder、AI Router、FFmpeg、Provider 抽象、质检和成本日志。课程应作为“导演经验库”和“Prompt模板库”的来源，而不是推倒重构系统。
---
## 1. 视频 1：整体流程与AIGC影视生产体系
### 主要内容
该视频展示完整 AIGC 影视/仿真人剧生产流程，从前期策划、剧本、角色、美术、视频生成到音频和后期。课程强调：
- 不能直接用一句剧情生成完整视频。
- 必须拆成前期策划、前期美术、中期分镜与视频、音频制作、后期剪辑。
- 各环节可以使用不同 AI 工具，而不是只依赖一个平台。
### 对系统的启发
你的系统应该继续保持多模块流水线：
```text
Story Bible
↓
Episode Plan
↓
Script
↓
Shot Planner
↓
Character/Scene/Asset Reference
↓
Prompt Builder
↓
Provider Router
↓
QA
↓
FFmpeg
```
### 可落地规则
1. 不允许“剧本直接进入视频生成”。
2. 每个镜头必须具备：角色、动作、场景、景别、运镜、情绪、时长、音效提示、负面约束。
3. 每个镜头只完成一个主要动作，避免一个 6 秒镜头塞太多剧情。
4. 特效镜头、人物特写、首次登场、高潮反转应被标记为高价值镜头。
---
## 2. 视频 2：神兽、道具、场景设计
### 主要内容
课程演示了神兽、道具、场景的设计思路，包括从文字描述到图像生成，再到素材复用。画面中涉及：
- 神兽形象生成与调整
- 道具细节，例如服饰、挂饰、玉佩等
- 场景图生成，例如中式书房/医馆/古风室内空间
- 参考图与一致性控制
### 对系统的启发
你当前系统不应只管理角色，还应该有资产库：
```text
Asset Library
├─ character_assets
├─ costume_assets
├─ prop_assets
├─ location_assets
├─ vehicle_assets
├─ vfx_assets
└─ sound_assets
```
对于都市短剧，最先沉淀这些资产：
- 豪车：劳斯莱斯、迈巴赫、商务车
- 酒店宴会厅
- 咖啡厅
- 集团大楼
- 总裁办公室
- 会议室
- 银行VIP室
- 黑金卡
- 股权文件
- 奢侈品/婚戒/合同
### 可落地规则
1. 道具必须单独建档，不能只在 prompt 里临时描述。
2. 关键道具需要绑定特写镜头模板，例如黑卡、合同、余额截图、婚戒。
3. 场景图应优先复用，避免每集重新生成导致风格漂移。
4. 场景资产应记录风格：现代豪华、都市夜景、商务冷色、温暖咖啡厅、压迫感会议室等。
---
## 3. 视频 3：Seedance/视频生成实操与一致性优化
### 主要内容
课程展示视频模型实操，重点包含：
- 视频提示词如何保持角色不变
- Seedance 2.0 的主力使用方式
- 人物动作、镜头运动、视频延长、排队时间等问题
- 部分镜头使用参考图和多图保持一致性
- 真人无法上传/国内外工具限制的处理
### 对系统的启发
视频模型不适合一次生成完整剧情，应该按镜头生成。
```text
1集 60秒
≈ 10个 5~6秒镜头
```
你现有的 action beat 拆段和 clip 拼接方向是对的。
### 可落地规则
1. 默认每个镜头 5~6 秒。
2. 超过 8 秒的镜头优先拆为 2 个 action beats。
3. 动作复杂度 action_score > 5 时，必须启用高质量 provider 或降低动作难度。
4. 同一角色连续镜头必须使用 anchor image / actor profile / reference asset。
5. 生成失败时优先修改 prompt，而不是盲目重试同一 prompt。
6. 如果模型排队时间过长，应允许 Router 自动切换 fallback Provider。
---
## 4. 视频 4：视频提示词编写技巧
### 主要内容
课程展示了从文本/剧情到视频提示词的写法。画面中明显体现出：
- 先让 AI 帮助拆镜头。
- 再把镜头转成可用于视频模型的提示词。
- 提示词要包含镜头、动作、画面、情绪、场景、角色一致性。
- 会使用角色六视图/定妆图辅助人物稳定。
- 后续进入剪辑流程。
### 对系统的启发
这是最适合转化为 Prompt Builder V2 的部分。Prompt 不是一句话，而是结构化对象：
```json
{
"character": "顾辰",
"action": "从酒店门口走出，停下，回头看向镜头",
"scene": "雨夜，高端酒店门口",
"camera_shot": "medium close-up",
"camera_move": "slow dolly in",
"emotion": "隐忍、失望、压抑",
"lighting": "cinematic night lighting",
"style": "vertical short drama, realistic",
"negative": "no face change, no outfit change, no extra characters"
}
```
### 可落地规则
1. Prompt Builder 必须支持：角色块、动作块、场景块、镜头块、光影块、情绪块、音效块、负面块。
2. Hailuo 专项 Prompt 应避免复杂连贯动作，强调“single main action”。
3. 正脸说话镜头如果没有 Lip Sync，应使用半侧脸、远景、反应镜头、背影镜头规避。
4. 每个 Provider 应有自己的 Prompt Profile。
---
## 5. 视频 5：人物设计全流程
### 主要内容
课程重点是前期美术和人物设计，内容包括：
- 角色核心设定
- 主视觉参考
- 服装、发型、气质
- 多视角人物图
- 使用图生图工具生成一致人物
- 人物动作图/动态参考
- 将人物图转视频
### 对系统的启发
你目前已经有 Character Library、ActorProfile、ActorLock。下一步不是重构，而是强化“角色定妆质量”和“一致性测试台”。
### 可落地规则
1. 每个主角必须有：正脸、侧脸、半身、全身、常服、正式服。
2. 不同剧情阶段可有不同 wardrobe，但必须显式绑定。
3. 角色首次出现必须生成或选择标准定妆图。
4. 角色一致性测试应独立于剧情，先生成 5 个动作镜头：走路、坐下、转头、打电话、上车。
5. 通过一致性测试后再进入正式短剧生成。
---
## 6. 视频 6：剧本创作、剧本改编与分镜思路
### 主要内容
课程展示了：
- 自创短篇剧本
- 小说/文本改写为分镜剧本
- AI辅助重写剧情
- 分集结构、人物关系、剧情摘要
- 将剧本拆成镜头文本
### 对系统的启发
你当前 scripts / storyboard_shots 的设计方向正确。需要强化的是：剧本阶段不直接追求视频化，而是产生“可拍性强”的镜头。
### 可落地规则
1. 每集应先生成“剧情摘要”和“爽点列表”。
2. 再生成“镜头列表”。
3. 每个镜头必须具备 shot_role：开场钩子、冲突、反应、反转、爽点、结尾悬念。
4. 每集前 3 秒必须是强钩子镜头。
5. 都市短剧优先选择：酒店、办公室、车内、街道、咖啡厅、银行、会议室等低成本场景。
6. 古装、战争、大规模群像、复杂打斗应暂缓。
---
## 7. 总结：课程对你系统的真正价值
### 不需要学的部分
- 工具注册
- 手工点击流程
- 基础剪映操作
- 平台充值
### 应该吸收的部分
- 分镜拆解方法
- 视频提示词结构
- 角色定妆流程
- 资产复用意识
- 6秒镜头化生产思路
- 角色一致性先测后用
- 高价值镜头和普通镜头分级
### 对现有系统的结论
你的代码架构已经超过课程本身的工具工作流。课程应该转化为：
```text
Prompt Library
Camera Rules
Emotion Rules
Scene Templates
Asset Library
Character Consistency Test
Provider Test Matrix
```
而不是再新增一堆基础功能。
docs/chatgpt/PROMPT_LIBRARY_AI_SHORT_DRAMA.md
+323
View File
@@ -0,0 +1,323 @@
# AI仿真人短剧 Prompt Library V1
> 目标：给你的 Prompt Builder / prompt_templates 表提供初始模板。以下模板适合都市逆袭、神豪、霸总、退婚、打脸类短剧。模板应作为结构化片段使用，不建议直接整段硬塞给模型。
## 1. 通用 Prompt 结构
```text
[Format]
Vertical 9:16 realistic live-action short drama.
Single continuous shot, no scene cuts inside this clip.
Only one main action in this clip.
[Character Lock]
{character_name}, {age}, {gender}, {appearance}, wearing {outfit}.
Keep the same face, hairstyle, outfit, body shape and age as the reference image.
[Scene]
{location}, {time}, {environment_detail}.
[Action]
{main_action}.
[Camera]
{camera_shot}, {camera_movement}, {camera_angle}.
[Performance]
{emotion}, natural facial expression, restrained drama performance.
[Lighting]
{lighting_style}.
[Style]
Chinese urban short drama, cinematic, realistic, high detail.
[Sound Cue]
{sound_cue}.
[Negative]
No face change, no outfit change, no extra characters, no sudden scene transition, no distorted hands, no unnatural body motion, no text watermark.
```
---
## 2. 退婚宴会厅
### scene_type
`engagement_breakup`
### 适用剧情
- 未婚妻当众退婚
- 男主被羞辱
- 豪门宴会反转
### 模板
```text
Vertical 9:16 realistic Chinese urban short drama.
Luxury hotel banquet hall with warm golden lighting, decorated engagement stage, guests sitting in the background.
{male_lead} stands alone on the stage, wearing {male_outfit}, holding back anger and sadness.
{female_lead} stands opposite him with a cold expression, wearing an elegant dress.
Medium two-shot, slow dolly in, emotional tension.
The atmosphere is awkward and humiliating.
Single continuous shot, one main action only.
No face change, no outfit change, no extra main characters, no sudden camera cut.
```
### 推荐景别
- medium two-shot
- over shoulder
- reaction close-up
---
## 3. 富二代羞辱男主
### scene_type
`humiliation`
```text
A wealthy young man in a luxury suit stands arrogantly beside a beautiful woman.
He looks down at the male lead with a mocking smile.
The male lead stands silently, fists slightly clenched, trying to stay calm.
Luxury hotel banquet hall background.
Over-the-shoulder shot from behind the male lead, then slow push toward the rich man's arrogant face.
Tense atmosphere, realistic acting, Chinese urban drama style.
No exaggerated comedy, no fighting, no sudden movement.
```
---
## 4. 男主雨夜离开
### scene_type
`lonely_exit`
```text
Night street outside a luxury hotel, light rain falling, wet road reflecting city lights.
{male_lead} walks out alone, wearing {outfit}, head slightly lowered, holding back emotions.
Medium long shot from behind, slow tracking shot following him.
Cinematic rain, blue-gray lighting, lonely atmosphere.
No dialogue, no extra characters close to camera, no sudden scene transition.
```
---
## 5. 劳斯莱斯出现
### scene_type
`rich_arrival`
```text
A black Rolls-Royce slowly stops beside the wet city street at night.
The car lights reflect on the rainy road.
A dignified old butler in a black suit opens the door and steps out with an umbrella.
Low angle wide shot, slow motion, cinematic lighting, powerful entrance.
Luxury urban drama style.
No distorted car, no logo deformation, no sudden cut, no extra vehicles blocking the scene.
```
---
## 6. 管家鞠躬
### scene_type
`identity_reveal`
```text
An elderly butler in a black suit and white gloves walks toward {male_lead} in the rain.
He bows respectfully and holds a black umbrella.
{male_lead} looks shocked and confused.
Medium close-up, slow dolly in, dramatic reveal atmosphere.
Rainy city street, black luxury car behind them.
No exaggerated movement, no face change, no extra characters.
```
---
## 7. 黑金卡/资产文件特写
### scene_type
`asset_reveal_insert`
```text
Close-up insert shot of a black premium bank card and a formal asset transfer document.
The document shows a huge asset number: 100,000,000,000.
A gloved hand holds the document under cinematic lighting.
Slow push-in, sharp focus, shallow depth of field.
Luxury business atmosphere.
No unreadable messy text except the key number, no extra hands, no camera shake.
```
---
## 8. 前女友震惊后悔
### scene_type
`regret_reaction`
```text
{female_lead} stands near the hotel entrance, staring at the black luxury car in shock.
Her confident expression collapses into panic and regret.
Close-up reaction shot, slow push-in, shallow depth of field.
City night lights behind her, emotional drama style.
No crying too exaggerated, no face change, no outfit change.
```
---
## 9. 前女友跑回来求复合
### scene_type
`regret_return`
```text
{female_lead} runs back toward {male_lead} on the rainy street, her expression nervous and regretful.
{male_lead} stands calmly beside the black luxury car.
Medium shot, slight handheld motion, emotional tension.
She slows down and tries to speak softly.
No fast chaotic running, no distorted limbs, no extra characters blocking them.
```
---
## 10. 男主上车离开
### scene_type
`power_exit`
```text
{male_lead} calmly gets into the back seat of a black Rolls-Royce.
The old butler respectfully closes the car door.
{female_lead} stands behind him in shock and regret.
Low angle medium shot, slow motion, cinematic night lighting.
Powerful ending shot, urban revenge drama style.
No face change, no outfit change, no sudden transition, no extra dialogue mouth close-up.
```
---
## 11. 银行余额震惊
### scene_type
`bank_balance_reveal`
```text
Luxury bank VIP room, modern interior, quiet and formal atmosphere.
{male_lead} sits in front of a bank manager, looking calm but surprised.
A tablet screen shows an enormous balance number: 100,000,000,000.
Close-up insert shot of the screen, then reaction close-up.
Slow dolly in, suspenseful business atmosphere.
No messy unreadable text, no random numbers, no extra people.
```
---
## 12. 总裁女神登场
### scene_type
`ceo_female_entrance`
```text
A beautiful female executive walks through a luxury office corridor.
She wears a fitted business suit, confident and elegant.
Employees respectfully step aside.
Low angle medium shot, slow dolly in, cinematic office lighting.
Strong professional aura, urban business drama style.
No exaggerated runway walk, no outfit change, no distorted face.
```
---
## 13. 会议室打脸
### scene_type
`boardroom_face_slap`
```text
Modern corporate boardroom, long conference table, serious business atmosphere.
{male_lead} sits calmly at the head of the table.
Several executives look shocked and nervous.
Medium wide shot, then slow push-in to {male_lead}'s calm face.
Powerful reversal moment, cinematic lighting.
No crowd chaos, no random extra faces close to camera, no face change.
```
---
## 14. 次元壁：电脑屏幕爬出
### scene_type
`dimensional_break_laptop`
```text
A quiet programmer desk at night, laptop screen glowing blue.
Inside the laptop screen, a beautiful anime girl with long white hair and blue eyes slowly reaches both hands toward the screen frame.
She carefully climbs out of the laptop screen into the real world.
Close-up of the laptop screen, slow dolly in, magical digital light particles.
Realistic desk lighting, cinematic fantasy atmosphere.
Single continuous action, no sudden scene cut.
No face change, no broken hands, no extra characters, no messy screen artifacts.
```
---
## 15. 法相天地：高价值特效镜头
### scene_type
`dharma_giant_form`
```text
A young Chinese cultivator stands alone on a mountain cliff under dark storm clouds.
His eyes glow with golden divine light.
Ancient golden runes appear around his body.
He raises one hand slowly, and a colossal golden divine form rises behind him, towering above the clouds.
Low angle shot, fast cinematic push-in, epic scale, golden lightning, volumetric clouds.
Chinese xianxia fantasy style, powerful and majestic.
No chaotic camera, no distorted body, no extra monsters, no random costume change.
```
---
## 16. Provider专项提示
### Hailuo
```text
Use simple, clear motion.
One main action only.
Avoid complex choreography.
Avoid long front-face talking.
Keep the same character face and outfit.
```
### Kling / stronger provider
```text
Allow more dynamic camera motion.
Emphasize cinematic camera language and action continuity.
Use for premium emotional peaks, fantasy effects, complex motion.
```
### Seedance / Vidu
```text
Use for stylized visual impact, dimensional break, fantasy or experimental shots.
Keep prompt highly visual and concise.
```
docs/chatgpt/jianyi001md
+548
View File
@@ -0,0 +1,548 @@
你这次观察到的东西，我觉得比课程本身更有价值。
因为我刚看完你的架构文档，再结合课程内容，我发现：
## 你的系统缺的不是 Character Library
而是：
```text
Character Workshop
（角色工坊）
```
这是两个完全不同的东西。
---
# 你现在的实现
你已经有：
```text
Character Bible
Character Library
Actor Profile
Actor Lock
```
这是：
```text
存储层
```
---
# Liblib 在干什么
它实际上做的是：
```text
创作层
```
例如：
角色
↓
生成
↓
不满意
↓
继续修改
↓
继续生成
↓
继续修改
↓
对比
↓
最终定稿
````
---
# 这个流程很重要
因为：
AI短剧最大的成本其实不是：
```text
视频
````
而是：
```text
角色设计错误
```
---
例如：
男主：
```text
帅
```
这种没意义。
---
真正应该：
```text
林凡
28岁
短发
棱角脸
眼神坚毅
蓝色外卖服
178cm
运动型身材
```
---
然后：
```text
正脸
侧脸
45度
全身
半身
微笑
愤怒
受伤
```
全部定稿。
---
# 我认为应该增加
## Character Workshop
例如：
```text
角色描述
↓
角色生成
↓
版本1
↓
修改
↓
版本2
↓
修改
↓
版本3
↓
最终定稿
```
---
数据库：
```sql
character_design_versions
```
---
例如：
```sql
id
character_id
version
prompt
image_id
is_final
```
---
# 教程里面那个思维导图模式
这个我也注意到了。
其实很好。
因为：
你现在用户流程：
```text
角色
↓
确认
```
太简单。
---
真实创作流程：
```text
角色
↓
生成
↓
修改
↓
再生成
↓
再修改
↓
锁定
```
---
# 我建议UI升级
例如：
```text
顾辰
├── v1
├── v2
├── v3
└── Final
```
---
点击：
```text
设为最终版
```
---
后续：
```text
Actor Profile
```
直接绑定：
```text
Final
```
---
# 第二个非常重要
你提到：
## 受伤版
这个其实是课程里最值钱的点之一。
因为：
连续剧里经常：
```text
正常状态
↓
受伤状态
↓
黑化状态
↓
西装状态
```
---
我建议增加：
## Character State
例如：
```sql
character_states
```
---
```text
顾辰
normal
business
injured
angry
blackened
```
---
然后：
```text
Character
↓
State
↓
Prompt Builder
```
---
# 第三个
原创小说部分
你观察得对。
目前很多AI写小说系统：
```text
生成
↓
结束
```
---
但课程里：
```text
生成
↓
修改
↓
修改
↓
修改
```
---
其实对应：
## Story Workshop
---
我建议：
```text
小说创意
↓
AI生成
↓
用户修改
↓
AI重生成
↓
版本管理
```
---
数据库：
```sql
story_versions
```
---
例如：
```text
v1
v2
v3
v4
```
---
最终：
```text
设为定稿
```
---
# 看完课程后
我认为你系统未来应该增加三个工坊
---
## Character Workshop
角色工坊
负责：
```text
角色设计
角色定稿
角色状态
角色参考图
```
---
## Story Workshop
故事工坊
负责：
```text
创意
大纲
章节
剧本
版本管理
```
---
## Prompt Workshop
Prompt工坊
负责：
```text
Prompt优化
Prompt版本
Prompt评分
```
---
# 我认为这是目前课程里
对你整个项目最有价值的发现
甚至比：
```text
海螺
Seedance
```
更重要。
因为：
```text
Provider
随时会换
```
---
但是：
```text
角色工坊
故事工坊
Prompt工坊
```
会成为你系统的核心竞争力。
而且非常契合你现在的架构，不需要推倒重来，只是在现有：
```text
Character Library
Story Bible
Prompt Builder
```
上面增加：
```text
Workshop（创作层）
```
即可。
docs/chatgpt/novel/1.md
+550
View File
@@ -0,0 +1,550 @@
一个长篇小说，怎么才能让ai记住上下文不乱？怎么写提示让ai 设计和写?
长篇小说让 AI 不乱，核心不是“一次性把所有设定塞进去”，而是建立一套**小说生产流程**：
> **总设定文档 → 分卷大纲 → 单章卡片 → 写作提示词 → 章节完成后更新记忆库**
AI 最容易乱的原因是：
人物设定没固定、剧情进度没记录、伏笔没管理、每次写章都把前文忘了、提示词只说“继续写”，没有告诉它“哪些东西不能改”。
---
# 一、长篇小说必须拆成 5 个文件
你不要只给 AI 一个大提示词，要把小说拆成 5 个“上下文文件”。
## 1. 世界观设定表
记录小说的底层规则。
包括：
世界类型；
时代背景；
城市 / 宗门 / 朝代 / 公司 / 学校；
力量体系；
社会阶层；
禁忌规则；
核心矛盾；
不能违背的世界规律。
比如修仙小说要写清楚：
境界等级；
寿命变化；
灵根规则；
法宝等级；
宗门结构；
丹药体系；
功法限制；
飞升规则；
主角金手指边界。
否则 AI 后面很容易乱加设定。
---
## 2. 人物档案表
每个重要角色都要建档。
必须包含：
姓名；
年龄；
身份；
外貌固定特征；
性格；
说话方式；
核心欲望；
恐惧；
秘密；
人物弧光；
和主角关系；
当前剧情状态；
禁止改动事项。
尤其要写“禁止改动事项”。
比如：
女主不能突然变恋爱脑；
男主不能突然圣母；
反派不能无脑降智；
师父不能提前暴露真实身份；
某角色第 80 章前不能死亡；
某秘密第 120 章前不能揭开。
---
## 3. 主线大纲表
长篇小说一定要先做“阶段设计”，不要直接让 AI 写第一章。
建议这样拆：
第 1 卷：入局，1–50 章
第 2 卷：成长，51–120 章
第 3 卷：反转，121–200 章
第 4 卷：大乱，201–320 章
第 5 卷：终局，321–500 章
每一卷都写清楚：
本卷目标；
本卷反派；
本卷主线事件；
本卷主角成长；
本卷重要伏笔；
本卷结尾爆点；
不能提前揭开的秘密。
---
## 4. 章节进度表
这是防止 AI 忘上下文的关键。
每写完一章，就更新一次。
格式建议：
第几章；
本章发生了什么；
人物状态变化；
新增设定；
新增伏笔；
已回收伏笔；
下一章必须承接什么；
当前不能忘的细节。
比如：
第 17 章：主角第一次使用“灰烬回溯”，代价是失去三小时记忆。新增伏笔：主角醒来时手里有一枚黑色铜钱。下一章必须写他追查铜钱来源，不能直接跳到宗门大比。
这样 AI 就不会写着写着断层。
---
## 5. 伏笔管理表
长篇最容易乱的是伏笔。
伏笔必须单独管理。
表格字段：
伏笔编号；
首次出现章节；
表现形式；
真实含义；
预计回收章节；
回收方式；
当前状态。
比如：
F001：主角梦里反复听见钟声。
首次出现：第 3 章。
真实含义：前世镇魂钟在召唤他。
预计回收：第 86 章。
当前状态：未回收。
这样 AI 才不会把伏笔忘掉，或者提前乱揭晓。
---
# 二、每次让 AI 写章节时，不能只说“继续”
错误提示词：
> 继续写第 18 章，写精彩一点。
这样 AI 很容易乱。
正确方式是每章都给它这 7 样东西：
1. 当前总设定摘要
2. 当前人物状态
3. 前 3 章剧情摘要
4. 本章目标
5. 本章必须出现的事件
6. 本章禁止事项
7. 本章结尾钩子
---
# 三、长篇小说标准工作流
你可以按这个流程操作：
## 第一步：先让 AI 设计总设定
不要写正文。
先让它输出世界观、主角、反派、主线、卷纲。
## 第二步：让 AI 设计全书结构
比如 300 章，就先做：
10 卷结构；
每卷 30 章；
每卷核心事件；
每卷结尾爆点。
## 第三步：让 AI 设计前 30 章细纲
不要一次设计 300 章细纲。
太细会僵硬，也容易后面改不动。
建议：
先设计全书粗纲；
再设计第 1 卷细纲；
写完第 1 卷后，根据实际剧情调整第 2 卷。
## 第四步：每章写作前生成“章节卡”
章节卡包括：
本章标题；
本章目标；
本章冲突；
出场人物；
场景；
关键信息；
伏笔；
结尾钩子。
## 第五步：根据章节卡写正文
正文提示词不要太空，要告诉 AI：
字数；
风格；
视角；
节奏；
对白比例；
心理描写比例；
禁止事项。
## 第六步：写完后立刻总结本章
让 AI 输出：
本章摘要；
人物变化；
新增设定；
新增伏笔；
待回收问题；
下一章承接点。
把这个总结放入“章节进度表”。
---
# 四、你可以直接用的总控提示词
下面这个是“长篇小说总导演提示词”，你可以保存起来，每次开新小说都先用它。
你现在是一名专业长篇小说总策划、网文主编、文学作家、剧作结构师和连续剧导演。我要创作一部长篇小说，请你不要急着写正文，先帮我建立一套稳定、不乱、不崩设定的长篇小说生产系统。
小说基础方向如下：
【题材类型】：
【预计字数】：
【预计章节数】：
【目标读者】：
【核心卖点】：
【风格要求】：
【禁止内容】：
【参考气质】：
【主角类型】：
【故事核心】：
请你按以下结构输出：
一、小说一句话核心
用一句话概括这部小说最吸引人的地方。
二、核心主题
说明这部小说真正要写的情感、人性、命运或社会议题。
三、世界观设定表
包括时代背景、空间结构、社会规则、力量体系、职业体系、资源体系、禁忌规则、核心矛盾。
四、主角档案
包括姓名、年龄、身份、外貌、性格、核心欲望、内心恐惧、能力边界、人物缺陷、成长弧光、最终变化。
五、重要人物档案
至少设计 8 个重要角色。每个角色必须包含：身份、欲望、秘密、与主角关系、人物弧光、禁止改动事项。
六、反派与阻力系统
不要只设计一个反派，要设计多层阻力：个人反派、组织反派、制度阻力、命运阻力、主角自身弱点。
七、全书结构
按卷设计。每卷包括：卷名、章节范围、本卷目标、本卷主要冲突、本卷主角成长、本卷核心反转、本卷结尾爆点。
八、伏笔系统
设计至少 20 个伏笔。每个伏笔包括：编号、首次出现位置、表面含义、真实含义、预计回收位置、回收效果。
九、爽点 / 情绪点 / 思考点
分别说明这部小说如何吸引读者继续看。
十、写作规则
列出这部小说后续写作时必须遵守的规则，尤其是不能改动的人设、不能提前暴露的秘密、不能违反的世界观规律。
十一、第一卷细纲
请先设计第一卷 30 章细纲。每章包括：章节标题、本章目标、主要事件、冲突、伏笔、结尾钩子。
注意：
1. 先设计，不要写正文。
2. 设定必须稳定，不能前后矛盾。
3. 不要使用套路化、狗血化、低级爽点。
4. 每个设定都要服务主线。
5. 所有后续正文必须严格遵守本次设定。
---
# 五、每章写作提示词
这个是你真正写正文时用的。每写一章，就复制一次，然后填入本章信息。
你现在继续创作长篇小说《小说名》。请严格遵守我提供的世界观、人设、剧情进度和伏笔表，不得擅自修改核心设定，不得提前揭露未到揭示时机的秘密，不得让人物行为脱离已有性格。
【当前总设定摘要】
在这里粘贴世界观、主线、主角目标、力量体系等核心设定摘要。
【主要人物当前状态】
1. 主角：
2. 重要角色 A：
3. 重要角色 B：
4. 重要角色 C：
【前 3 章剧情摘要】
第 X 章：
第 X+1 章：
第 X+2 章：
【本章信息】
章节编号：
章节标题：
本章字数：
本章视角：
本章场景：
本章出场人物：
本章核心目标：
本章主要冲突：
本章必须发生的事件：
本章必须埋下的伏笔：
本章必须回收的伏笔：
本章结尾钩子：
【本章禁止事项】
1. 不得改变人物已有性格。
2. 不得提前揭露未到时间的秘密。
3. 不得跳过关键情绪转折。
4. 不得用巧合强行推动剧情。
5. 不得写与主线无关的水剧情。
6. 不得让反派无脑降智。
7. 不得让主角突然获得没有铺垫的新能力。
【写作风格】
语言要有画面感和节奏感，情绪表达克制但有张力。场景要具体，动作要清楚，对白要符合人物身份。不要空泛总结，不要说教，不要流水账。每一场戏都要推动剧情、人物关系或伏笔。
请根据以上信息，正式创作本章正文。
正文结束后，请额外输出：
1. 本章 300 字摘要；
2. 人物状态变化；
3. 新增设定；
4. 新增伏笔；
5. 已回收伏笔；
6. 下一章必须承接的内容。
---
# 六、章节写完后的“记忆更新提示词”
这个非常关键。
每写完一章，不要马上继续写下一章，而是先让 AI 整理“记忆库”。
请根据刚刚完成的章节，更新小说记忆库。要求信息简洁、准确、可用于后续续写，不能加入正文中没有发生的内容，不能猜测未来剧情。
请按以下格式输出：
一、本章剧情摘要
用 300 字以内概括本章真实发生的事件。
二、人物状态更新
逐个列出本章出场人物的状态变化，包括心理变化、关系变化、受伤情况、获得物品、暴露秘密、立场变化。
三、世界观 / 设定更新
列出本章新增或确认的世界规则、地点、组织、能力、道具、历史信息。
四、伏笔更新
1. 新增伏笔：
2. 推进中的伏笔：
3. 已回收伏笔：
4. 不能忘记的未解问题：
五、时间线更新
说明本章发生在什么时间，距离上一章过去多久。
六、空间位置更新
说明主要人物当前所在地点，下一章开始时应从哪里承接。
七、下一章承接建议
列出下一章必须承接的 3 至 5 个重点。
八、禁止遗忘事项
列出后续写作绝不能忘记或改掉的细节。
---
# 七、最稳定的提示词组合方式
每次写新章节时，建议你给 AI 的上下文不要太长，但要精准。
最佳组合是：
**小说总设定摘要 1000 字以内**
+
**人物档案精简版 1000 字以内**
+
**最近 3 章摘要 1000 字以内**
+
**伏笔表 500 字以内**
+
**本章章节卡 500 字以内**
总共 4000 字左右就够了。
不要每次都塞几十万字前文。
那样 AI 反而容易抓不住重点。
---
# 八、长篇小说防乱的 10 条铁律
## 1. 不要一次让 AI 写太多章
一次最多写 1 章。
最多最多写 2 章。
不要让它“一口气写 10 章”。
---
## 2. 每章必须有章节卡
没有章节卡，AI 很容易水剧情。
---
## 3. 每章完成后必须总结
总结不是给人看的，是给后面续写当记忆用的。
---
## 4. 伏笔单独管理
不要指望 AI 自动记住伏笔。
伏笔必须编号。
---
## 5. 人物必须有“禁止改动事项”
比如：
主角不能主动杀无辜者；
女主不说网络流行语；
师父不能提前暴露修为；
反派不会亲自下场做低级事。
---
## 6. 每卷结束要重新校准
写完一卷后，让 AI 做一次：
剧情复盘；
人物复盘；
伏笔复盘；
节奏问题检查；
下一卷调整建议。
---
## 7. 设定不要无限膨胀
AI 很喜欢加新组织、新境界、新神器、新敌人。
你要明确写：
“除非我要求，不得新增核心势力、境界等级和主线设定。”
---
## 8. 主角能力必须有代价
没有代价，长篇很快崩。
要写清楚：
能力限制；
使用条件；
副作用；
成长路径；
不能做什么。
---
## 9. 反派不能降智
长篇最怕反派前期很强，后期突然傻。
要写：
反派目标；
反派资源；
反派情报边界；
反派行动逻辑；
反派不会做什么蠢事。
---
## 10. 每 10 章做一次体检
让 AI 检查：
有没有人设偏移；
有没有设定冲突；
有没有伏笔遗漏；
有没有节奏拖沓；
有没有主线偏离；
有没有重复桥段。
---
# 九、你真正要记住的一句话
长篇小说不是靠一个超级提示词写出来的。
它靠的是：
> **设定文档固定世界，人物档案固定性格，章节卡控制当章，记忆库承接上下文，伏笔表管理长期线索。**
你后面可以这样操作：
先让 AI 设计《请确认她来过》的**长篇版总设定文档**；
再让 AI 设计**5 卷结构**；
再设计**第 1 卷 30 章细纲**；
然后每章用“章节写作提示词”写；
写完每章用“记忆更新提示词”压缩上下文；
下一章继续把记忆库贴进去。
这样写 30 万字、50 万字，都不容易乱。
docs/chatgpt/novel/10.md
+370
View File
@@ -0,0 +1,370 @@
那视频生成模型也是一样的道理，自己调用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 接近网页版，就要把官方隐藏的产品层，在自己的系统里重建出来。**
docs/chatgpt/novel/11.md
+661
View File
@@ -0,0 +1,661 @@
目标肯定是把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 策略和质检系统。**
docs/chatgpt/novel/12.md
+608
View File
@@ -0,0 +1,608 @@
我目前的系统是拆了分镜，每个分镜单独给模型发api 这样应该不会乱把，每个分镜都市独立的，等于现实的导演一集一集的擦hi开取景安排好了完整流程，不管谁接手，只需要按每个分镜定好的流程内容去拍摄就可以了
对，你这个理解**大方向是对的**：
> **每个分镜单独发 API，不会像长篇小说那样严重依赖前后 100 章全文。**
> 因为分镜本身就是“拍摄执行单”，模型只需要按当前镜头要求生成画面。
这和现实剧组很像：
```text
总导演 / 编剧先定全剧
↓
分集导演拆场
↓
分镜导演定镜头
↓
摄影、美术、演员按分镜执行
↓
剪辑统一成片
```
所以你的系统按“分镜独立生成”是正确路线。
但是要注意一句：
> **分镜可以独立生成，但不能完全孤立。**
如果每个分镜只给当前镜头内容，而不带角色、服装、场景、前后镜头连续性，就可能出现：
第一镜女主短发；
第二镜女主长发；
第三镜衣服颜色变了；
第四镜场景灯光变了；
第五镜动作方向反了；
第六镜人物情绪接不上。
所以最稳的做法是：
> **每个分镜独立发 API，但每个分镜都必须携带统一的“拍摄资产包”。**
---
# 一、你的分镜 API 模式是对的
你现在这种：
```text
第1镜 → 单独调用视频模型
第2镜 → 单独调用视频模型
第3镜 → 单独调用视频模型
……
最后 FFmpeg 合成
```
是目前 AI 短剧最现实、最可控的方式。
因为如果你让模型一次生成 1 分钟、3 分钟、5 分钟完整短剧，问题会更多：
画面漂移；
人物换脸；
动作断裂；
台词不稳；
剧情遗漏；
生成失败成本高；
不好返修；
单个镜头坏了要整段重来。
所以拆分镜是对的。
一个镜头坏了，只重做一个镜头，不影响整集。
---
# 二、但每个分镜不能只传“当前动作”
错误示例：
```text
女主走进房间，看见桌上的门禁卡。
```
这样模型可能不知道：
女主是谁；
她长什么样；
她穿什么；
现在是什么情绪；
房间是什么风格；
上一镜她从哪个方向进来；
门禁卡是什么样；
整体画风是什么；
镜头比例和时长是多少。
正确应该传：
```text
角色固定信息
+ 当前角色状态
+ 场景固定信息
+ 道具固定信息
+ 本镜头动作
+ 镜头语言
+ 情绪状态
+ 前后连续性
+ 负面词
+ Provider 参数
```
这就是我说的“拍摄资产包”。
---
# 三、每个分镜 API 应该包含 8 类信息
## 1. 项目级风格
每个镜头都要统一。
例如：
```text
写实真人短剧风格，9:16竖屏，720p，电影感低饱和，真实自然光，克制表演，不夸张，不网红滤镜。
```
这保证整集质感统一。
---
## 2. 角色固定资产
每个出现的角色都要引用同一个角色档案。
例如：
```json
{
"character_id": "cen_qing",
"name": "岑青",
"visual_identity": "31岁中国女性，短黑发，清瘦脸型，眼神冷静，素色衬衫，深色外套",
"anchor_image_id": "asset_xxx",
"current_state": "刚发现门禁卡身份异常，情绪克制但警觉",
"must_keep": [
"短黑发",
"清瘦脸",
"深色外套",
"冷静克制表情"
]
}
```
如果 Provider 支持参考图，就传锚点图。
如果不支持，就把视觉描述写进 Prompt。
---
## 3. 角色状态变体
同一角色在不同剧情阶段可能服装、伤势、妆容不同。
比如：
```text
normal_state
rainy_state
injured_state
fire_scene_state
office_state
```
不能每个镜头临时改。
你当前系统已经有 `CharacterState` 和 `CharacterDesignVersion`，这个就应该用起来。
---
## 4. 场景固定资产
例如：
```json
{
"scene_id": "old_investigation_room",
"location": "临时调查室",
"visual_identity": "简陋办公室，白板贴着火灾楼层图，桌上有证物袋和电脑，冷白灯，窗外下雨",
"lighting": "冷白室内光 + 电脑屏幕冷光",
"color_palette": "灰蓝、旧白、暗黄"
}
```
这样第 1 镜和第 2 镜不会变成两个完全不同的房间。
---
## 5. 道具资产
重要道具必须固定。
比如：
```json
{
"prop_id": "burned_access_card",
"name": "烧焦门禁卡",
"visual_identity": "一张边缘烧焦起泡的塑料门禁卡，卡面残留两个汉字：林照，磁条断裂"
}
```
短剧里道具是线索，不能乱变。
---
## 6. 本镜头执行内容
这才是当前分镜本身：
```json
{
"shot_no": 3,
"duration_sec": 5,
"shot_size": "close-up",
"camera_movement": "slow push-in",
"main_action": "岑青把烧焦门禁卡放到电脑旁，盯着屏幕等待系统检索",
"emotion": "安静、不安、警觉",
"dialogue": ""
}
```
---
## 7. 前后镜头连续性
这是防止剪辑不连贯的关键。
例如：
```json
{
"previous_shot": {
"ending_state": "裴让把证物袋推到岑青面前",
"character_position": "岑青坐在桌子左侧，裴让站在右侧",
"prop_position": "证物袋在桌子中央"
},
"current_shot_start": "从桌面证物袋特写开始",
"next_shot_expectation": "电脑屏幕出现身份匹配失败"
}
```
不是每个镜头都需要很多，但关键镜头要带。
---
## 8. 负面约束
比如：
```text
不要换脸，不要改变发型，不要改变服装颜色，不要夸张表演，不要卡通风，不要多余人物，不要出现错误文字，不要手指畸形，不要突然切换场景。
```
视频模型很容易自作主张，负面词必须有。
---
# 四、最稳的分镜任务结构
你的视频 API 任务最好不是只保存一个 prompt，而是保存结构化 JSON。
建议这样：
```json
{
"project_id": "p001",
"episode_id": "e001",
"shot_no": 3,
"duration_sec": 5,
"aspect_ratio": "9:16",
"resolution": "720p",
"provider": "volcengine_seedance_20",
"route_tier": "premium",
"style_pack": {
"visual_style": "写实真人短剧，电影感，低饱和，真实光影",
"tone": "克制、悬疑、现实主义",
"negative_style": "不要网红滤镜，不要动漫风，不要夸张表演"
},
"characters": [
{
"character_id": "cen_qing",
"name": "岑青",
"anchor_image_id": "asset_cenqing_anchor_v1",
"state_code": "investigation_dark_coat",
"visual_prompt": "31岁中国女性，短黑发，清瘦脸型，冷静眼神，素色衬衫，深色外套",
"continuity_rules": [
"保持同一张脸",
"保持短黑发",
"保持深色外套",
"表情克制"
]
}
],
"location": {
"scene_id": "investigation_room",
"prompt": "简陋临时调查室，白板上贴火灾楼层图，桌上有证物袋、电脑，冷白灯，窗外下雨"
},
"props": [
{
"prop_id": "burned_access_card",
"prompt": "烧焦起泡的门禁卡，边缘发黑，磁条断裂，卡面残留两个汉字"
}
],
"shot": {
"shot_size": "close-up",
"camera_movement": "slow push-in",
"main_action": "岑青把烧焦门禁卡放在电脑旁，盯着屏幕等待系统检索",
"emotion": "安静、不安、警觉",
"dialogue": "",
"sfx": "轻微雨声、电脑风扇声"
},
"continuity": {
"previous_shot_end": "裴让把证物袋推到岑青面前",
"current_start": "桌面证物袋特写",
"next_shot_need": "电脑屏幕出现身份匹配失败"
},
"final_prompt": "",
"negative_prompt": ""
}
```
然后由你的 `PromptBuilderService` 把这个结构转成不同 Provider 的最终 Prompt。
---
# 五、你的“导演比喻”是正确的，但还差一个“场记”
你说：
> 不管谁接手，只需要按每个分镜定好的流程内容去拍摄。
这句话对。
但现实剧组还有一个非常重要的岗位：**场记**。
场记负责记录：
上一镜演员站哪；
手里拿什么；
衣服有没有扣上；
杯子在桌子哪边；
上一句台词是什么情绪；
下一镜怎么接。
AI 视频里也需要“场记系统”。
对应到你的系统就是：
```text
ShotContinuityService
```
它负责每个镜头之间的连续性。
比如：
```json
{
"episode_id": "e001",
"shot_no": 5,
"ending_state": {
"cen_qing_position": "桌子左侧",
"peirang_position": "门口右侧",
"prop_access_card": "电脑键盘左边",
"emotion": "岑青第一次产生怀疑"
}
}
```
生成第 6 镜时，就把第 5 镜 ending_state 带进去。
这样剪辑会更顺。
---
# 六、什么时候分镜可以完全独立？
这些镜头可以高度独立：
```text
空镜；
环境镜头；
道具特写；
转场镜头；
梦境片段；
监控画面；
回忆碎片；
单人特写；
无连续动作的对白镜头。
```
比如：
```text
烧焦门禁卡特写
旧楼外墙空镜
雨水落在警戒线上
电脑屏幕显示查无此人
```
这些镜头前后依赖很弱，单独生成没问题。
---
# 七、什么时候不能完全独立？
这些镜头要带连续性：
```text
同一场戏里的连续对话；
同一动作拆成多个镜头；
角色从 A 点走到 B 点；
打斗；
追逐；
拥抱；
递东西；
开门进房间；
人物情绪逐渐变化；
同一空间内连续切镜。
```
比如：
```text
第3镜：裴让把证物袋推给岑青
第4镜：岑青打开证物袋
第5镜：岑青拿出门禁卡
第6镜：电脑显示查无此人
```
这几个镜头必须共享：
桌子位置；
人物站位；
门禁卡样子；
灯光；
动作承接。
否则合成后会跳。
---
# 八、你的系统现在应该补的核心模块
基于你当前已拆分镜的流程，我建议补这几个：
## 1. ShotContextBuilder
给每个分镜拼上下文：
```text
项目风格
角色资产
场景资产
道具资产
当前分镜
前后镜连续性
Provider 参数
```
---
## 2. ShotContinuityService
保存每个镜头的开始状态和结束状态。
字段包括：
```text
人物位置
人物情绪
服装状态
手持道具
场景状态
动作完成情况
下一镜承接点
```
---
## 3. ShotAssetLock
锁定角色、服装、场景、道具。
比如：
```text
第1集第1-12镜，岑青统一使用 character_state = investigation_dark_coat
海风大厦楼梯间统一使用 scene_asset = haifeng_stairwell_v1
门禁卡统一使用 prop_asset = burned_access_card_v1
```
---
## 4. ShotQualityCheck
生成后检查：
```text
人物是否一致；
服装是否一致；
动作是否完成；
场景是否错误；
有没有多余人物；
有没有崩脸；
是否符合时长；
是否能接上前后镜。
```
---
## 5. ShotRetryPolicy
根据失败类型自动重试。
比如：
```text
换脸 → 加强角色描述 / 使用锚点图 / 换图生视频
动作失败 → 简化动作
场景乱 → 加首帧图
手部崩 → 避免复杂手部动作 / 改景别
文字错 → 不让模型生成可读文字，后期字幕加
```
---
# 九、你现在的路线和小说流水线怎么接？
小说流水线生成短剧时，应该先生成：
```text
Episode
EpisodeScript
StoryboardShot
ShotAssetLock
ShotContinuityPlan
```
然后你现有视频系统按每个 `StoryboardShot` 单独生成。
也就是：
```text
小说章节
↓
短剧剧本
↓
分镜
↓
分镜资产锁定
↓
每镜单独 API
↓
候选片段
↓
连续性检查
↓
合成
```
这样就不会乱。
---
# 十、最终判断
你目前的做法：
> **分镜拆开，每个分镜单独发 API。**
这是正确的，而且是 AI 短剧自动化的主流可控方案。
但要加一句：
> **分镜独立生成，不等于分镜没有上下文。**
最稳结构是：
```text
每个分镜独立调用 API
但每个分镜都带：
角色锁定
场景锁定
道具锁定
本镜头动作
前后连续性
统一风格
负面词
Provider 适配参数
```
一句话总结：
> **你现在像导演把戏拆成了镜头，这是对的；下一步要补“场记”和“资产锁定”，保证每个接手拍摄的 AI 模型拍出来能剪成同一部戏。**
docs/chatgpt/novel/13.md
+415
View File
@@ -0,0 +1,415 @@
那小说呢 ，也是要安排好每个章节的大纲核心？然后每次提交api 生成一个章节？
对，**小说也应该像短剧分镜一样，先安排好每章的大纲核心，然后每次 API 只生成一个章节**。
但小说和视频分镜有一个区别：
> **视频分镜可以相对独立；
> 小说章节必须更重视上下文承接。**
所以小说不能只是“第 1 章、第 2 章、第 3 章各自独立生成”。
正确流程是：
```text
全书总纲
↓
分卷大纲
↓
章节大纲 / 章节卡
↓
每次 API 生成 1 章
↓
章节质检
↓
章节记忆更新
↓
下一章基于最新记忆继续生成
```
---
# 一、小说章节就像“剧集分场”
你的理解可以这样类比：
| 短剧系统 | 小说系统 |
| --------- | ---------- |
| 全剧设定 | 小说圣经 |
| 分集大纲 | 分卷大纲 |
| 分镜脚本 | 章节卡 |
| 每个镜头单独生成 | 每个章节单独生成 |
| 场记保证连续性 | 章节记忆保证连续性 |
| 角色锚点保证不换脸 | 人物状态保证不崩人设 |
| 分镜质检 | 章节质检 |
所以小说系统也应该“先规划，再逐章生产”。
---
# 二、不能一次让 AI 写很多章
不要这样：
```text
请一次性写第1章到第10章
```
这样很容易出现：
人设飘；
伏笔乱；
章节水；
节奏失控；
上一章结尾和下一章开头接不上；
某些重要情绪跳过去。
正确做法是：
```text
一次只写一章。
写完一章，立刻更新记忆。
下一章再根据最新记忆写。
```
最多可以一次生成“章节大纲”，但正文最好一章一章来。
---
# 三、章节卡是小说流水线的核心
每一章生成前，都要先有一张“章节卡”。
章节卡就像短剧分镜的拍摄单。
一张合格章节卡应该包含：
```text
章节编号
章节标题
本章目标
本章开场承接
本章主要冲突
本章出场人物
本章场景
本章必须发生的事件
本章人物状态变化
本章新增伏笔
本章推进伏笔
本章回收伏笔
本章禁止事项
本章结尾钩子
本章适合改编短剧的场景
```
比如：
```json
{
"chapter_no": 12,
"title": "五种笔迹",
"chapter_goal": "岑青发现林照名字下有五种不同笔迹",
"opening_from_previous": "承接上一章姚知知说‘她有好几双手’",
"main_conflict": "岑青追查旧签到簿，物业试图阻止她查看仓库记录",
"characters": ["岑青", "裴让", "陈淑蘅", "物业管理员"],
"scenes": [
{
"location": "海风大厦负一层仓库",
"purpose": "找到旧签到簿",
"visual_value": "手电照在潮湿纸页上，五种笔迹露出来"
}
],
"must_happen": [
"岑青找到旧签到簿",
"同一个林照名字下面出现五种笔迹",
"陈淑蘅看到签到簿后明显紧张",
"裴让提醒岑青证据还不够"
],
"foreshadows_to_add": [
"签到簿中间缺了一页"
],
"foreshadows_to_advance": [
"林照不是一个人"
],
"must_not_happen": [
"陈淑蘅不能立刻说出全部真相",
"不能直接揭示周榕真实身份",
"不能让物业管理员脸谱化成坏人"
],
"ending_hook": "岑青发现签到簿被撕掉的一页，撕口很新",
"adaptation_notes": {
"short_drama_value": "适合改成悬疑揭示场景",
"key_visual": "五种笔迹",
"key_prop": "旧签到簿"
}
}
```
有了这张章节卡，模型生成正文就不容易乱。
---
# 四、每次 API 生成章节时传什么？
不要传全部小说正文。
每次传：
```text
1. 小说圣经摘要
2. 当前卷纲
3. 最近 3-5 章摘要
4. 本章出场人物当前状态
5. 本章相关伏笔
6. 本章章节卡
7. 文风规则
8. 禁止事项
```
例如写第 12 章时，传：
```json
{
"bible_summary": "现实主义悬疑小说，核心主题是被城市抹去的人如何重新被确认……",
"current_volume_outline": "第一卷：寻找不存在的林照。核心任务是让岑青从单人英雄叙事走向多人身份真相。",
"recent_chapter_summaries": [
"第9章：岑青采访九楼医生，得知林照每天凌晨修灯。",
"第10章：姚知知画出多只不同的手。",
"第11章：裴让找到门禁记录异常，同一时间两个楼层出现林照。"
],
"character_states": [
{
"name": "岑青",
"state": "已经怀疑林照不是一个人，但缺少证据"
},
{
"name": "陈淑蘅",
"state": "知道林照身份共用真相，但还在隐瞒"
}
],
"active_foreshadows": [
{
"code": "F003",
"title": "姚知知画中的五只手",
"status": "developing"
}
],
"chapter_card": {},
"style_rules": [
"克制",
"电影感",
"不煽情",
"不狗血",
"对白短而有张力"
]
}
```
这样写到第 100 章，传的上下文也不会无限变大。
---
# 五、小说章节生成流程应该这样设计
你的自动化流水线可以按这个步骤跑：
```text
01 创建小说项目
02 生成小说圣经
03 生成全书粗纲
04 生成第一卷细纲
05 生成第 1 章章节卡
06 调用 API 写第 1 章正文
07 调用 API 润色第 1 章
08 调用 API 质检第 1 章
09 如果不合格，自动修复或重写
10 保存终稿到 NovelChapter
11 更新章节摘要、人物状态、伏笔状态
12 生成第 2 章章节卡
13 重复流程
```
也就是：
```text
章节卡 → 正文 → 质检 → 记忆更新 → 下一章
```
这和你现在短剧的：
```text
分镜 → 视频片段 → 候选 → 质检 → 合成
```
逻辑是一样的。
---
# 六、章节正文最好一章一章串行生成
可以并发的内容：
```text
生成角色视觉档案
生成场景资产
生成伏笔表
生成章节卡
生成听书稿
生成短剧适配
生成封面
生成标题
```
但正文最好：
```text
第1章完成 → 更新记忆 → 第2章
第2章完成 → 更新记忆 → 第3章
第3章完成 → 更新记忆 → 第4章
```
不要这样并发：
```text
模型A写第1章
模型B同时写第2章
模型C同时写第3章
```
因为第 2 章需要知道第 1 章最后实际写成什么，第 3 章也需要承接第 2 章。
---
# 七、长篇小说最稳的“章级流水线”
你可以照这个做后台任务。
```text
GenerateChapterCardJob
↓
WriteChapterDraftJob
↓
PolishChapterJob
↓
QualityCheckChapterJob
↓
RepairChapterJob，可选
↓
FinalizeChapterJob
↓
UpdateNovelMemoryJob
↓
PrepareNextChapterJob
```
如果某章评分不够：
```text
低于 75 分 → 整章重写
75-84 分 → 局部修复
85 分以上 → 通过
```
如果连续 3 次修不好：
```text
进入人工审核
```
这样能自动化，但不会让系统一路写崩。
---
# 八、章节卡和短剧改编要提前关联
你后续要做小说 / 听书 / 短剧同步，所以章节卡里要提前有改编字段。
比如：
```json
{
"chapter_no": 12,
"title": "五种笔迹",
"adaptation": {
"audio_value": "适合听书悬疑推进，重点突出签到簿发现过程",
"drama_value": "适合短剧第4集核心揭示",
"visual_scenes": [
"负一层仓库寻找签到簿",
"手电照亮五种笔迹",
"陈淑蘅看到签到簿后沉默"
],
"key_dialogues": [
"你们要真相，是因为你们有地方放真相。我们没有。"
],
"props": [
"旧签到簿",
"手电",
"门禁卡"
]
}
}
```
这样后面生成短剧和听书时，就不用重新从小说里硬拆。
---
# 九、小说系统和短剧系统的对应关系
```text
小说圣经
↓
短剧 StoryBible
小说人物档案
↓
短剧 Character / ActorProfile
小说章节
↓
短剧 Episode 或 EpisodeScript
小说章节卡里的 visual_scenes
↓
短剧 StoryboardShot
小说关键对白
↓
短剧对白 / 配音
小说场景资产
↓
短剧 Location / Prompt Builder
小说道具资产
↓
短剧 Props / 分镜 Prompt
```
所以章节卡越结构化，后续短剧越省事。
---
# 十、最终答案
对，小说也应该这样：
> **先安排全书、分卷、每章大纲核心；
> 然后每次提交 API 生成一个章节；
> 写完章节后更新记忆，再生成下一章。**
最稳结构是：
```text
小说圣经
→ 分卷大纲
→ 章节卡
→ 单章 API 生成
→ 章节质检
→ 章节记忆更新
→ 下一章
```
一句话：
> **视频靠分镜控制画面；小说靠章节卡控制剧情。
> 分镜是拍摄执行单，章节卡就是写作执行单。**
docs/chatgpt/novel/2.md
+1709
View File
File diff suppressed because it is too large Load Diff
docs/chatgpt/novel/3.md
+1183
View File
File diff suppressed because it is too large Load Diff
docs/chatgpt/novel/4.md
+1109
View File
File diff suppressed because it is too large Load Diff
docs/chatgpt/novel/5.md
+250
View File
@@ -0,0 +1,250 @@
写小说全世界那个ai模型最好
按**纯小说创作质量**来说，目前我会这样排：
## 第一名：Claude Fable 5 / Claude Opus 4.8
如果你只问“全世界哪个模型最会写小说”，我的判断是：
> **Claude 系列目前最适合写文学性、人物情绪、长篇叙事和细腻对白。**
Anthropic 官方也把 Claude 明确定位到创意工作场景：它适合更快、更大规模地做创意构思、扩展创作能力、处理重复劳动。([Anthropic][1])
另外，Anthropic 官方文档显示，Claude Opus 4.8 是当前 Opus 层级最强模型，支持 1M 上下文和 128k 最大输出，适合复杂推理、长周期任务和高自主性工作。([Claude API Docs][2])
**适合做：**
现实主义小说；
女性向 / 情感向；
人物群像；
文学感短故事；
长篇人物弧光；
细腻心理描写；
高级对白；
治愈、悬疑、人间观察。
**缺点：**
API 参数限制比较多；
部分模型温度等采样参数不能自由调；
自动化工程接入时要适配它的 Messages API 规则；
中文网文爽感不一定比国内模型强。
---
## 第二名：GPT-5.5 / GPT-5.5 Pro
如果你不是只要“文笔”，而是要做你这种**自动化小说流水线**，我更建议把 GPT-5.5 放在核心位置。
OpenAI 官方说明 GPT-5.5 擅长写作、代码调试、在线研究、数据分析、文档与表格创建、软件操作，以及处理混乱的多步骤任务；API 版本也支持 1M 上下文。([OpenAI][3])
**GPT-5.5 最强的地方不是单章文笔，而是：**
小说圣经设计；
世界观逻辑；
长篇结构规划；
多 Agent 编排；
JSON Schema 稳定输出；
质量检查；
伏笔管理；
人物一致性检查；
小说转剧本；
小说转听书；
短剧分镜提示词生成。
也就是说：
> **Claude 更像顶级作家。
> GPT-5.5 更像总编剧 + 架构师 + 审稿人 + 自动化系统调度员。**
你现在要做的是 API 自动化流水线，所以 GPT-5.5 非常重要。
---
## 第三名：Gemini 3.1 Pro
Gemini 3.1 Pro 更适合长上下文、多资料综合、知识整理、跨文档分析。Google 官方称它面向复杂任务，并通过 Gemini API、Vertex AI、Gemini App、NotebookLM 等渠道提供。([blog.google][4])
**适合做：**
长篇资料整理；
大型世界观材料分析；
多文档改编；
历史文化题材；
科幻设定考据；
把小说拆成知识库；
长上下文回溯。
**不建议让它作为主写手。**
它可以做资料和结构，但最终正文文风通常不如 Claude，自动化工程能力也不如 GPT-5.5 稳。
---
## 第四名：Kimi / DeepSeek / 通义 / 智谱 / 豆包
这些国内模型适合你的商业流水线做**中低成本批量生产**。
尤其你系统里已经配置了：
豆包小说 2.0 Pro；
DeepSeek 小说；
通义小说；
Kimi 小说；
智谱小说；
OpenAI Responses 小说。
根据你上传的架构文档，你的 Provider 层已经有 `NovelProvider`，并且启用了豆包、DeepSeek、通义、Kimi、智谱、OpenAI 等小说模型，这很好。
**国内模型适合做：**
章节初稿；
爽文节奏；
中文短剧对白；
网感标题；
低成本批量生成；
听书稿改写；
短剧口语化台词；
分镜初稿。
**但不建议全部交给单一国内模型。**
因为长篇高级感、人设稳定性、伏笔控制、文学质感，还是要靠更强模型做总控和质检。
---
# 我的最终推荐
你这个系统不是单次聊天写小说，而是要接 API 自动流水线。
所以不要问“只用哪个模型”，应该按 Agent 分工用模型。
## 最优组合
| 环节 | 推荐模型 |
| ------------- | -------------------------------- |
| 小说圣经 / IP 圣经 | GPT-5.5 Pro 或 Claude Opus 4.8 |
| 世界观 / 人物 / 伏笔 | GPT-5.5 或 Claude Opus 4.8 |
| 正文初稿 | Claude Fable 5 / Claude Opus 4.8 |
| 中文网文章节初稿 | 豆包小说 2.0 Pro / Kimi / 通义 |
| 润色提升 | Claude Opus 4.8 |
| 连贯性检查 | GPT-5.5 |
| JSON 结构化输出 | GPT-5.5 |
| 小说转听书 | 豆包 / Kimi / GPT-5.5 |
| 小说转短剧剧本 | GPT-5.5 + 豆包 |
| 分镜 / 视频提示词 | GPT-5.5 |
| 低成本批量测试 | 豆包小说 2.0 Lite / DeepSeek / Kimi |
---
# 如果只能选一个
## 只追求小说质量
选：
> **Claude Opus 4.8 / Claude Fable 5**
它最适合写“像人写的小说”。
---
## 只追求自动化流水线稳定
选：
> **GPT-5.5**
它最适合你这种 NestJS + Provider + Queue + JSON Schema + 多 Agent 的系统。
---
## 只追求中文批量低成本
选：
> **豆包小说 2.0 Pro + Kimi / 通义 做备选**
你系统里已经有豆包小说 Provider，后续可以把它作为中文小说初稿主力。
---
# 我建议你的生产配置
你的小说系统可以这样设默认路线：
```text
高质量路线：
GPT-5.5 生成小说圣经
Claude Opus 4.8 写正文
GPT-5.5 做质检和记忆更新
成本平衡路线：
GPT-5.5 生成小说圣经
豆包小说 2.0 Pro 写正文
GPT-5.5 / Kimi 做质检润色
低成本批量路线：
豆包小说 2.0 Lite / Kimi 写初稿
DeepSeek / 通义 做章节卡
GPT-5.5 只做关键节点质检
```
---
# 给你的架构建议
你的后台 Provider 已经区分 `TextProvider`、`NovelProvider`、`VoiceProvider`、`VideoProvider`。下一步应该在小说流水线里做一个 **NovelRouter**，类似你现有真人视频的 `AiRouterService`。
它按任务选择模型：
```text
bible_generation → GPT-5.5 / Claude Opus
chapter_draft → Claude / 豆包小说
polish → Claude
continuity_check → GPT-5.5
memory_update → GPT-5.5 / Kimi
audio_script → 豆包 / Kimi
drama_script → GPT-5.5
storyboard_prompt → GPT-5.5
```
这样才是最适合你的方案。
一句话：
> **世界上单论小说文笔，Claude 最强；
> 单论自动化小说工业流水线，GPT-5.5 最稳；
> 单论中文批量成本，豆包 / Kimi / 通义更适合。
> 你的系统最好是 Claude 写、GPT-5.5 管、国内模型批量跑。**
[1]: https://www.anthropic.com/news/claude-for-creative-work "Claude for Creative Work \ Anthropic"
[2]: https://docs.anthropic.com/en/docs/about-claude/models/whats-new-claude-4-8?utm_source=chatgpt.com "What's new in Claude Opus 4.8"
[3]: https://openai.com/index/introducing-gpt-5-5/ "Introducing GPT-5.5 | OpenAI"
[4]: https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-1-pro/ "Gemini 3.1 Pro: Announcing our latest Gemini AI model"
Claude 最强 是啥公司的
Claude 是 **Anthropic** 公司的 AI 模型。
**Anthropic** 是一家美国 AI 公司，核心产品就是 **Claude** 系列模型。它和 OpenAI、Google DeepMind、xAI、Meta AI 这些公司属于同一类大模型公司。
简单理解：
| 模型 | 公司 |
| ----------------- | ----------- |
| ChatGPT / GPT-5.5 | OpenAI |
| Claude | Anthropic |
| Gemini | Google |
| Grok | xAI |
| Llama | Meta |
| 豆包 | 字节跳动 / 火山引擎 |
| 通义千问 | 阿里 |
| 文心一言 / 千帆 | 百度 |
| Kimi | 月之暗面 |
| DeepSeek | 深度求索 |
Claude 的特点是：**写作、长文理解、人物情绪、文学表达、长篇创作比较强**。
所以我前面说，如果单看“小说文笔和人物细腻度”，Claude 通常很适合当主写手。
但你要做 API 自动化小说流水线，我还是建议：
**Claude 负责正文质量，GPT-5.5 负责架构、质检、上下文管理，豆包/Kimi/通义负责中文低成本批量生成。**
docs/chatgpt/novel/6.md
+261
View File
@@ -0,0 +1,261 @@
我就是要写中文 高质量小说 做剧本
你要的是：**中文高质量小说 + 后续能做剧本/短剧**。
那我建议不要只选一个模型，而是按“主编—作家—编剧—质检”分工。
# 最适合你的模型组合
## 1. 中文高质量小说主写手
优先级：
```text
Claude Opus / Claude Fable
GPT-5.5
豆包小说 2.0 Pro
Kimi
通义千问
```
如果单看**人物细腻、心理、文学感、长篇情绪**，Claude 还是很强。
但如果你要写的是**中文商业小说 + 后续改短剧**，我不建议完全依赖 Claude。因为 Claude 有时中文表达会偏“翻译腔 / 文艺腔”，短剧对白不一定最接地气。
---
## 2. 中文短剧剧本主力
优先级：
```text
GPT-5.5
豆包 2.0 Pro
Kimi
通义千问
Claude
```
短剧剧本最重要的不是文笔，而是：
场景清楚；
对白能演；
情绪推进快；
每集有钩子；
人物行动明确；
适合视频生成。
这方面 **GPT-5.5 更适合做总编剧和剧本结构师**。
---
## 3. 中文网感 / 本土化对白
优先级：
```text
豆包 2.0 Pro
Kimi
通义千问
DeepSeek
```
这些模型更适合做：
中文口语；
短剧对白；
平台感标题；
章节爽点；
听书稿口语化；
短视频分镜文案。
你现在系统里已经启用了豆包小说、DeepSeek 小说、通义小说、Kimi 小说、智谱小说和 OpenAI Responses 小说 Provider，这个基础是对的。
---
# 我给你的最终推荐
## 高质量路线
适合你要做精品中文小说、投稿、短剧测试。
```text
GPT-5.5：小说圣经 / 世界观 / 人物关系 / 伏笔 / 章节卡
Claude：正文初稿 / 文学润色 / 人物心理
GPT-5.5：连贯性检查 / 伏笔检查 / 剧本改编
豆包 2.0 Pro：中文短剧对白本土化 / 听书稿口语化
```
这是最稳的。
---
## 成本平衡路线
适合批量测试多个题材。
```text
GPT-5.5：小说圣经 / 章节卡 / 质检
豆包小说 2.0 Pro：正文初稿
Kimi / 通义：润色或改写
GPT-5.5：最终质检和剧本改编
```
这条路线成本低很多，质量也能控制。
---
## 低成本批量路线
适合大量跑选题、测试市场。
```text
豆包小说 2.0 Lite / Kimi：章节初稿
DeepSeek / 通义：章节卡和摘要
GPT-5.5：每 5 章或每 10 章做一次总审
```
这条路线不适合直接做精品，但适合筛选题材。
---
# 如果你只允许我选一个模型
如果只能选一个模型来做整个系统：
> **选 GPT-5.5。**
原因不是它单章文笔一定最强，而是它最适合你的工程系统：
能设计小说；
能写章节；
能做 JSON 结构化；
能做质检；
能做上下文记忆；
能改剧本；
能生成分镜；
能生成视频提示词；
适合 API 流水线。
Claude 更像“高级作家”。
GPT-5.5 更像“总导演 + 主编 + 架构师”。
你现在做的是自动化系统，不是单次聊天写一篇文章，所以 GPT-5.5 必须做中枢。
---
# 我建议你后台默认这样配置
你现在已有 Provider 类型，包括 `TextProvider`、`NovelProvider`、`VideoProvider`、`VoiceProvider` 等，而且小说和短剧模块已经分开，这很适合做路由分工。
建议新增一个：
```text
NovelRouter
```
按任务自动选模型。
## NovelRouter 默认策略
| 任务 | 推荐模型 |
| ------- | --------------------- |
| 选题深化 | GPT-5.5 |
| 小说圣经 | GPT-5.5 |
| 人物档案 | GPT-5.5 + Claude |
| 世界观 | GPT-5.5 |
| 伏笔库 | GPT-5.5 |
| 章节卡 | GPT-5.5 |
| 中文正文初稿 | Claude / 豆包小说 2.0 Pro |
| 文学润色 | Claude |
| 中文口语优化 | 豆包 / Kimi |
| 连贯性检查 | GPT-5.5 |
| 伏笔检查 | GPT-5.5 |
| 章节质量评分 | GPT-5.5 |
| 小说转听书 | 豆包 / Kimi |
| 小说转短剧剧本 | GPT-5.5 |
| 短剧对白本土化 | 豆包 2.0 Pro |
| 分镜脚本 | GPT-5.5 |
| 视频提示词 | GPT-5.5 |
---
# 你的目标下，模型不能这样用
不要这样：
```text
一个模型从小说圣经写到最终短剧
```
一定会出现：
上下文乱；
人设飘；
伏笔忘；
文风不稳定；
短剧改编不顺；
视频提示词不可控。
正确做法是：
```text
GPT-5.5 管结构
Claude 写质感
豆包/Kimi 做中文口语和短剧本土化
GPT-5.5 再做质检和改编
```
---
# 高质量中文小说 + 短剧的最佳流程
你系统里可以这样跑：
```text
1. GPT-5.5 生成 IP 圣经
2. GPT-5.5 生成全书结构 / 分卷 / 伏笔
3. GPT-5.5 生成章节卡
4. Claude 写小说正文
5. Claude 做文学润色
6. GPT-5.5 做连贯性和伏笔检查
7. 豆包/Kimi 做中文口语自然化
8. GPT-5.5 生成短剧剧本
9. 豆包 2.0 Pro 优化短剧对白
10. GPT-5.5 生成分镜和视频提示词
```
---
# 最终答案
你要写**中文高质量小说并改剧本**，最佳不是单模型，而是：
```text
GPT-5.5 + Claude + 豆包/Kimi
```
具体分工：
```text
GPT-5.5：总策划、结构、上下文、质检、剧本、分镜
Claude：小说正文、人物心理、文学润色
豆包/Kimi：中文本土化、短剧对白、听书稿
```
如果你要我帮你定系统默认配置，我会这样设：
```text
精品模式：
GPT-5.5 + Claude + 豆包 2.0 Pro
平衡模式：
GPT-5.5 + 豆包小说 2.0 Pro + Kimi
低成本模式：
豆包小说 2.0 Lite + Kimi + GPT-5.5抽检
```
你现在做的是**小说/听书/短剧内容中台**，不是单纯写小说。
所以真正最强方案是：
> **GPT-5.5 当总导演，Claude 当主笔，豆包/Kimi 当中文短剧编剧。**
docs/chatgpt/novel/7.md
+519
View File
@@ -0,0 +1,519 @@
一个小时如果多个模型写，那内容还能贯通吗？不是一个模型处理完菜呢记住上下文吗？
可以贯通，但前提是：**不能依赖“某一个模型自己记住上下文”**。
你要做 API 自动流水线，正确思路是：
> **不是让模型记住小说，
> 而是让你的系统记住小说，
> 每次调用模型时，把它当前需要知道的上下文喂给它。**
所以多个模型写完全没问题。关键在于你系统里要有一个**统一记忆中台 / 小说状态库 / Context Builder**。
你当前项目已经有 `MemoriesModule`、`StoryBiblesModule`、`CharactersModule`、`EpisodesModule`、`ScriptsModule`，也有小说库和真人短剧流程，所以架构基础是能承接这个设计的。
---
# 一、为什么不能靠一个模型“自己记住”？
API 调用和你在 ChatGPT 里连续聊天不一样。
API 每次调用本质上都是：
```text
你给模型一段输入
模型返回一段输出
调用结束
```
模型不会天然记得上一章写了什么，除非你下一次调用时重新把必要上下文传进去。
所以不管你用一个模型，还是多个模型，都必须做：
```text
数据库保存上下文
↓
每次写新章前拼装上下文
↓
模型根据上下文写
↓
写完后更新数据库记忆
```
这才是稳定方案。
---
# 二、多个模型会不会导致风格乱？
会有风险，但可以控制。
核心不是“只能用一个模型”，而是要有一个**统一的小说圣经和风格规则**。
每个模型写作前都必须收到同一套规则：
```text
小说圣经
人物档案
世界观规则
文风规则
禁用桥段
前 3-5 章摘要
当前人物状态
当前伏笔状态
本章章节卡
```
这样即使用 Claude 写正文、GPT-5.5 做质检、豆包做对白优化，它们也都围绕同一个“项目记忆”工作。
真正的主控不是某个模型，而是你的系统。
---
# 三、正确的理解方式
你可以把它理解成拍电影。
不是一个人从头到尾完成所有工作。
```text
总导演：控制整体风格
编剧：写剧情
分镜师：拆镜头
演员指导：控制角色表现
剪辑师：控制节奏
审片人：检查问题
```
不同人参与，电影仍然能统一，是因为有：
剧本；
人物设定；
导演风格；
分镜表；
连续性记录；
制片流程。
AI 小说流水线也一样。
多个模型能贯通，靠的是：
```text
小说圣经 + 上下文记忆 + 章节卡 + 质检回写
```
不是靠某个模型脑子里一直记着。
---
# 四、你的系统里应该谁来“记住上下文”？
应该由这 5 个东西记住。
## 1. NovelBible / IPBible
保存最高设定。
包括：
故事主题；
世界观；
人物设定；
主线；
分卷结构；
风格要求；
禁止事项；
短剧改编规则。
它是全书宪法。
---
## 2. CharacterState
保存人物当前状态。
比如：
岑青当前知道了什么；
陈淑蘅有没有说出真相；
周榕是否已经被确认；
人物关系发展到哪里；
谁受伤了；
谁还隐藏秘密。
不能只保存初始人设。
长篇必须保存“当前状态”。
---
## 3. ChapterMemory
每章写完后保存摘要。
例如：
```text
第 12 章：
岑青在清洁间逼问陈淑蘅，陈承认“林照”不是一个人，但拒绝说出其他女工名字。新增伏笔：旧签到簿中有一页被撕掉。下一章必须追查被撕掉的一页。
```
下一章不需要塞完整正文，只要塞这种摘要。
---
## 4. ForeshadowMemory
保存伏笔。
比如：
```text
F001：灰蓝外套被多人穿过
状态：已揭示一半
预计回收：第 18 章
F002：签到簿被撕掉的一页
状态：未回收
预计回收：第 22 章
```
这样 AI 不会忘伏笔。
---
## 5. StyleMemory
保存文风。
比如：
```text
语言克制，不煽情。
对白短，避免解释型台词。
场景有电影感。
不写狗血冲突。
不写打脸复仇。
每章至少有一个可视频化场景。
```
每次写作都传进去。
---
# 五、多个模型分工时，怎么保证贯通？
推荐你这样设计：
```text
GPT-5.5：总控 / 章节卡 / 质检 / 记忆更新
Claude：正文写作 / 文学润色
豆包/Kimi：中文口语化 / 短剧对白 / 听书稿
GPT-5.5：最终连续性检查
```
流程如下：
```text
1. Context Builder 从数据库取上下文
2. GPT-5.5 生成章节卡
3. Claude 根据章节卡写正文
4. GPT-5.5 检查是否跑偏
5. Claude 或豆包修稿
6. GPT-5.5 更新记忆库
7. 进入下一章
```
这里最关键的是第 1 步和第 6 步。
只要上下文拼装和记忆更新稳定，多个模型就能贯通。
---
# 六、上下文拼装器才是核心
你系统里要有一个：
```text
NovelContextBuilderService
```
每次写第 N 章，它自动拼：
```json
{
"bible_summary": "小说核心设定摘要",
"style_rules": ["克制", "电影感", "不狗血"],
"forbidden_rules": ["不能提前揭露周榕", "不能让陈淑蘅主动全盘交代"],
"current_volume_outline": "当前卷纲",
"recent_chapter_summaries": [
"第10章摘要",
"第11章摘要",
"第12章摘要"
],
"active_characters": [
{
"name": "岑青",
"current_state": "已经发现林照可能不是一个人，但还没有证据闭环"
}
],
"active_foreshadows": [
{
"code": "F002",
"title": "被撕掉的签到页",
"status": "developing"
}
],
"chapter_card": {
"chapter_no": 13,
"goal": "追查签到簿缺页",
"ending_hook": "缺页出现在姚知知的画本里"
}
}
```
模型拿到这个上下文，就算换模型，也知道该怎么写。
---
# 七、一个模型从头写到底，反而不一定最好
你担心多个模型不连贯，这个担心是对的。
但“一个模型从头到尾写”也有问题。
它可能：
写着写着人设变；
越写越水；
忘记伏笔；
重复表达；
章节节奏越来越像模板；
自己发现不了自己的问题。
所以更好的方案是：
```text
一个模型负责创作
另一个模型负责审稿
系统负责记忆
```
也就是：
> **模型写，不让模型自己当唯一裁判。**
---
# 八、你这个系统最稳的配置
我建议你分三种模式。
## 模式 1：精品模式
适合投稿、精品短剧、重点 IP。
```text
GPT-5.5：小说圣经、章节卡、质检、记忆
Claude：正文初稿、文学润色
豆包/Kimi：中文对白优化、短剧口语化
GPT-5.5：最终一致性检查
```
质量最好，成本最高。
---
## 模式 2：平衡模式
适合批量生产可用小说。
```text
GPT-5.5：小说圣经、章节卡、质检
豆包小说 2.0 Pro：正文初稿
Kimi/通义：润色
GPT-5.5：记忆更新和抽检
```
性价比最高。
---
## 模式 3：低成本模式
适合测试题材。
```text
豆包/Kimi：章节卡和正文
DeepSeek/通义：摘要和记忆
GPT-5.5：每 5 或 10 章做一次总审
```
成本低，但精品率低。
---
# 九、不要让多个模型同时写同一章
这里要注意。
多个模型可以协作，但不要这样：
```text
Claude 写前半章
豆包写后半章
Kimi 写结尾
```
这样很容易断风格。
正确做法是：
```text
同一章只让一个主写模型完成完整正文
其他模型只做检查、润色、对白优化
```
例如：
```text
第 13 章：
Claude 写完整正文
GPT-5.5 检查
豆包只优化对白
Claude 最后统一润色
```
这样风格才不会碎。
---
# 十、并发怎么做？
如果你想“一小时多模型并发生产”，不能并发写连续章节。
错误方式：
```text
模型 A 写第 1 章
模型 B 同时写第 2 章
模型 C 同时写第 3 章
```
因为第 2 章需要知道第 1 章最后真实写成什么，第 3 章又依赖第 2 章。
这样必乱。
正确并发方式是：
```text
第 1 章正文生成中
同时可以并发：
- 生成角色视觉资产
- 生成场景资产
- 生成听书稿结构
- 生成封面提示词
- 生成质量评估候选
```
连续章节最好还是串行。
可以做“半并发”：
```text
先生成第 1-10 章章节卡
然后第 1 章正文完成后，更新记忆
再写第 2 章
```
章节卡可以提前批量生成。
正文最好按顺序生成。
---
# 十一、最推荐的自动化流程
你可以这样跑：
```text
1. 一次性生成全书粗纲
2. 一次性生成前 30 章章节卡
3. 第 1 章正文生成
4. 第 1 章质检
5. 第 1 章修复
6. 第 1 章记忆更新
7. 第 2 章根据最新记忆重新校准章节卡
8. 第 2 章正文生成
9. 循环
```
也就是说，章节卡可以提前，但每章写作前要允许重新校准。
---
# 十二、你需要在后台加一个“上下文快照”
每次模型调用前，都保存它当时看到的上下文。
表可以叫：
```text
AgentRunContextSnapshot
```
保存：
```json
{
"agent_name": "ChapterWriterAgent",
"model": "claude-opus",
"chapter_no": 13,
"input_context": {},
"output_text": "",
"quality_score": 88
}
```
为什么要保存？
因为后面如果某章写崩了，你要知道：
模型当时看到了什么；
是不是上下文少了；
是不是章节卡错了；
是不是模型自己跑偏；
是不是质检漏了。
这个对调试非常重要。
---
# 十三、最终答案
多个模型可以写，而且适合你的系统。
但不能靠模型自己记住。
要靠你的系统记住。
正确架构是：
```text
数据库 = 长期记忆
NovelContextBuilder = 上下文拼装器
GPT-5.5 = 总编剧 / 质检 / 记忆更新
Claude = 主写手
豆包/Kimi = 中文短剧对白和听书本土化
```
最关键规则：
```text
同一章一个主写模型
连续章节按顺序写
每章写完必须更新记忆
所有模型都读取同一个小说圣经和上下文快照
短剧/听书基于小说版本快照派生
```
一句话：
> **不是让一个模型记住全部，而是让你的系统成为“小说大脑”。模型只是不同岗位的员工，每次上岗前都读取同一份档案。**
docs/chatgpt/novel/8.md
+511
View File
@@ -0,0 +1,511 @@
如果这样，那章节越多，后续要传递给api的参数就越多？
是的，**如果你每次都把前面所有章节正文传给 API，章节越多，参数一定越来越大，成本会爆，速度也会慢。**
但真正的长篇小说系统**不能这么做**。
正确做法是：
> **不是把全部正文传给模型，
> 而是把“压缩后的关键记忆 + 当前章节相关内容”传给模型。**
也就是说，后面写第 100 章，不需要把前 99 章全文都传进去，只需要传：
```text
小说圣经摘要
当前卷纲
最近 3-5 章摘要
本章相关人物状态
本章相关伏笔
本章章节卡
禁止改动规则
文风规则
```
这样 API 输入会长期保持稳定，不会随着章节无限增长。
---
# 一、错误做法：全文堆上下文
比如写第 80 章时，你把第 1–79 章全部塞进去：
```text
第1章全文
第2章全文
第3章全文
...
第79章全文
请写第80章
```
这个做法有几个问题：
1. token 成本越来越高；
2. 请求越来越慢；
3. 模型容易被大量旧内容干扰；
4. 真正重要的信息反而被淹没；
5. 超过上下文长度后直接无法调用；
6. 多模型协作时更难稳定。
所以长篇流水线绝对不能靠“全文传递”。
---
# 二、正确做法：三层记忆压缩
你要做的是**分层记忆**。
## 第一层：永久核心记忆
每次都传，但内容要很短。
包括：
```text
小说一句话核心
世界观规则
主角核心人设
主要角色不可改动项
文风规则
禁用桥段
短剧改编规则
```
控制在 **1000–2000 字**。
这部分相当于小说宪法。
---
## 第二层：近期记忆
每次只传最近 3–5 章摘要。
比如写第 80 章，只传：
```text
第75章摘要
第76章摘要
第77章摘要
第78章摘要
第79章摘要
```
不传全文。
每章摘要控制在 150–300 字。
总共大概 **1000–1500 字**。
---
## 第三层：检索记忆
这部分不是每次都传全部，而是按本章需要查。
比如第 80 章出场人物是：
```text
岑青
陈淑蘅
姚知知
```
那就只查这几个人的状态：
```text
岑青当前知道了什么
陈淑蘅隐瞒了什么
姚知知上次出现在哪里
她们之间的关系变化
```
如果本章涉及某个伏笔，就只查相关伏笔。
比如：
```text
F012：被撕掉的签到簿缺页
F018：姚知知画本里的第五只手
```
不相关的伏笔不传。
---
# 三、写第 100 章时，真正传给 API 的应该是这样
不是：
```text
前99章全文 + 请写第100章
```
而是：
```json
{
"bible_summary": "小说核心设定摘要，约1500字",
"style_rules": [
"克制",
"电影感",
"不狗血",
"不打脸复仇",
"对白短而有张力"
],
"current_volume_outline": "当前第3卷卷纲摘要，约800字",
"recent_chapter_summaries": [
"第95章摘要",
"第96章摘要",
"第97章摘要",
"第98章摘要",
"第99章摘要"
],
"active_character_states": [
{
"name": "岑青",
"current_state": "已经确认林照不是一个人，但还缺最后证据"
},
{
"name": "陈淑蘅",
"current_state": "知道周榕真名，但仍不愿公开其他女工身份"
}
],
"active_foreshadows": [
{
"code": "F012",
"title": "签到簿缺页",
"status": "developing",
"expected_reveal": "第102章"
}
],
"chapter_card": {
"chapter_no": 100,
"title": "缺页",
"goal": "岑青找到签到簿缺失页的线索",
"must_happen": [
"姚知知交出画本",
"岑青发现画本夹层里有一页旧纸",
"陈淑蘅第一次失控"
],
"ending_hook": "纸页上不是一个名字，而是五个名字"
}
}
```
这个上下文即使写到第 500 章，也可以控制在 **4000–8000 字**以内。
---
# 四、上下文不是越多越好，而是越准越好
很多人误以为：
> 传越多，AI 越不会乱。
其实不一定。
真正有效的是：
```text
重要信息完整
无关信息少
当前任务明确
禁止事项清楚
```
你给模型塞 30 万字前文，它不一定抓得住重点。
但你给它一份高质量上下文：
```text
当前主线
当前人物状态
当前伏笔
上一章结尾
本章目标
不能写什么
```
它反而更稳。
---
# 五、你系统里要做“记忆压缩器”
每写完一章，就让 AI 或程序生成一份压缩记忆。
比如第 20 章正文有 3000 字，压缩成：
```json
{
"chapter_no": 20,
"summary": "岑青在旧仓库找到签到簿，发现林照名下有五种笔迹。",
"character_updates": [
{
"name": "岑青",
"update": "开始怀疑林照不是单一人物"
},
{
"name": "陈淑蘅",
"update": "看到签到簿后明显紧张，但拒绝解释"
}
],
"new_foreshadows": [
{
"code": "F020",
"title": "被撕掉的一页",
"surface": "签到簿中间缺了一页",
"hidden_truth": "缺页记录了火灾当晚真实值班名单"
}
],
"next_chapter_must_continue": [
"岑青需要追查缺页",
"陈淑蘅不能立刻说出全部真相"
]
}
```
以后第 50 章、第 100 章需要这个信息时，系统从数据库查这条摘要，不用查完整正文。
---
# 六、上下文传递应该有 4 个等级
## L1：每次必传
```text
小说圣经摘要
文风规则
禁用规则
本章章节卡
```
---
## L2：经常传
```text
最近 3-5 章摘要
当前卷纲
当前主线进度
```
---
## L3：按需传
```text
本章出场人物状态
本章相关伏笔
本章相关场景
本章相关道具
```
---
## L4：特殊情况才传
```text
某一章原文片段
某个角色上次出场完整段落
某个伏笔首次出现原文
某段重要对白
```
只有当模型需要复刻细节时，才传原文片段。
比如本章要回收第 12 章的一句台词，那就检索第 12 章相关原文片段传进去。
---
# 七、成本大概怎么控制？
假设一章 3000 字。
错误做法：
```text
写第100章时传前99章全文
≈ 30万字上下文
```
这非常贵，也不稳定。
正确做法：
```text
固定核心上下文：1500字
最近5章摘要：1500字
人物状态：800字
伏笔：800字
章节卡：800字
风格规则：500字
```
总共大概：
```text
5900字上下文
```
后续写到第 300 章，也还是差不多 5000–8000 字上下文。
成本是可控的。
---
# 八、你要加一个 Context Budget 机制
系统里要给每次调用设置上下文预算。
比如：
```json
{
"max_context_tokens": 12000,
"budget": {
"bible_summary": 2000,
"recent_summaries": 2000,
"character_states": 2000,
"foreshadows": 1500,
"chapter_card": 1500,
"style_rules": 1000,
"retrieved_original_snippets": 2000
}
}
```
如果超过预算，系统自动压缩。
优先级：
```text
本章章节卡 > 人物当前状态 > 最近章节摘要 > 相关伏笔 > 小说圣经摘要 > 原文片段
```
不是所有东西都平等。
---
# 九、你现有系统可以这样落地
你当前项目已经有 `MemoriesModule`，也有小说章节管理、故事圣经、角色、分集、脚本、分镜这些模块。文档里也提到后续需要把小说、故事圣经、角色抽取、分集、脚本、分镜等文本步骤统一成更严格的 schema、重试、验证和 Prompt 版本管理。
所以你现在应该补：
```text
NovelContextBuilderService
NovelMemoryCompressorService
NovelRetrievalService
NovelContextBudgetService
```
职责如下：
```text
NovelMemoryCompressorService：
每章写完后，把正文压缩成摘要、人物变化、伏笔变化。
NovelRetrievalService：
写新章前，从数据库检索相关人物、伏笔、场景、章节片段。
NovelContextBudgetService：
控制本次 API 输入不要超预算。
NovelContextBuilderService：
把所有信息拼成最终 Prompt。
```
---
# 十、一个稳定的 Context Builder 流程
```text
准备写第 N 章
↓
读取小说圣经摘要
↓
读取当前卷纲
↓
读取最近 5 章摘要
↓
读取章节卡
↓
根据章节卡识别出场人物
↓
读取这些人物当前状态
↓
根据章节卡识别相关伏笔
↓
读取这些伏笔状态
↓
如有需要，检索原文片段
↓
按 token 预算压缩
↓
拼成最终 API prompt
↓
调用模型写作
```
这样章节再多，也不会爆。
---
# 十一、最重要的数据库设计
你至少需要这几个表：
```text
NovelContextMemory
NovelCharacterState
NovelForeshadow
NovelChapterSummary
NovelAgentRunContext
```
如果你不想多建表，也可以先把它们合并进一个 `NovelContextMemory`，用 `memory_type` 区分。
例如：
```text
memory_type = bible_summary
memory_type = chapter_summary
memory_type = character_state
memory_type = foreshadow
memory_type = style_rule
memory_type = timeline
```
第一版这样就够。
---
# 十二、最终答案
你的担心是对的：
> **如果每次都传全部章节，章节越多，API 参数一定越来越多。**
但专业系统不会这么做。
专业系统是：
```text
全文入库
摘要常用
相关内容检索
上下文预算控制
每章写完更新记忆
每次调用只传必要信息
```
一句话：
> **小说全文存在数据库里，不存在 Prompt 里。
> Prompt 里只放当前模型完成任务必须知道的内容。**
这样写 30 章、300 章、1000 章，API 输入都可以保持稳定。
docs/chatgpt/novel/9.md
+331
View File
@@ -0,0 +1,331 @@
那 chatgpt 这个网页版是怎么做到记忆的，我使用网页版涩会给你从了120章节小说，挺好的
你在网页版感觉“120 章也记得住”，主要是因为 ChatGPT 产品层做了几件事，不是单纯“模型自己永久记住全文”。
简单说，网页版大概是这几层能力叠加：
```text
当前对话上下文
+ 上传文件解析
+ 长上下文窗口
+ 相关内容检索
+ 对话历史 / 项目文件 / 记忆能力
+ 系统自动挑选相关信息塞回模型
```
OpenAI 官方也说明，ChatGPT 的记忆包括“保存的记忆”和“引用聊天历史”，开启后会从过去对话里提取有用信息加入新对话；项目功能也可以把聊天、参考文件和自定义指令放在一起，让 ChatGPT 保持主题连续；文件上传也支持较大的文本/文档文件。([OpenAI Help Center][1])
---
# 一、网页版不是把 120 章永远塞进模型脑子里
你上传 120 章小说后，ChatGPT 能表现得不错，通常是因为：
1. 文件被解析成文本；
2. 系统知道这个文件属于当前会话/项目；
3. 你问问题时，系统会从文件和对话里找相关片段；
4. 把相关内容、摘要、上下文放进本次模型输入；
5. 模型基于这些内容回答。
也就是说，它不是“永久记住 120 章全文每个字”，而是：
> **文件在系统里，模型每次需要时可以被喂到相关内容。**
这和我前面说的小说流水线是同一个原理。
你的系统也要这么做：
```text
小说全文入库
章节摘要入库
人物状态入库
伏笔入库
按需检索
拼装上下文
再调用模型
```
---
# 二、为什么网页版看起来比普通 API 更聪明？
因为网页版 ChatGPT 已经帮你做了很多产品层工作。
比如：
## 1. 当前聊天本身有上下文
你在同一个聊天里连续讨论，前面的内容会作为上下文的一部分参与后续回答。
但这有长度限制，不是无限的。
---
## 2. 上传文件可以被引用
你上传小说文件后，ChatGPT 可以围绕文件问答、总结、分析。官方文件上传 FAQ 里提到，文本和文档文件有 token 上限，文件大小也有限制。([OpenAI Help Center][2])
这说明文件不是“变成模型永久记忆”，而是作为可处理的数据源。
---
## 3. ChatGPT 有记忆和引用聊天历史
官方说明，开启“Reference chat history”后，ChatGPT 会引用过去对话中有用的信息，让后续对话更个性化、更相关。([OpenAI Help Center][3])
但这类记忆更适合记：
你的偏好；
你的项目方向；
你常用技术栈；
你之前的要求；
你对风格的偏好。
它不适合当作“精确保存 120 章小说全文”的数据库。
---
## 4. Projects 可以聚合上下文
ChatGPT Projects 可以把聊天、文件和项目指令放在一起，让工作更连续。官方说明 Projects 可以组织聊天、上传参考文件、添加自定义指令，让 ChatGPT 围绕项目保持主题。([OpenAI Help Center][4])
这跟你系统里的“NovelSource + StoryBible + Memory + Character + Foreshadow”很像。
---
# 三、API 里为什么感觉不一样？
因为 API 默认不会自动帮你做这么完整的产品层。
API 更像一个模型调用接口：
```text
你传什么，它就基于什么回答。
```
如果你想让 API 也像网页版一样“记得住”，你要自己实现这些层：
```text
文件解析层
章节切分层
摘要层
向量检索层
上下文拼装层
记忆更新层
版本快照层
```
网页版帮你做了很多。
你自己的系统要自己做。
---
# 四、你系统应该仿照 ChatGPT 做什么？
你可以把 ChatGPT 的机制“产品化”到你自己的小说系统里。
## 1. 小说全文库
保存完整正文。
```text
NovelSource
NovelChapter
```
你现在已经有这部分。你的架构文档里也显示当前小说系统已支持小说源、章节、阅读器、章节导入和章节切割。
---
## 2. 小说摘要库
每章保存摘要。
```text
第1章摘要
第2章摘要
……
第120章摘要
```
后续写第 121 章，不传 120 章全文，只传相关摘要。
---
## 3. 人物状态库
不能只存人物初始设定，要存当前状态。
比如：
```text
主角当前知道什么
女主和男主关系到哪一步
反派是否暴露
某人有没有死亡
某秘密是否揭开
```
---
## 4. 伏笔库
专门管理伏笔。
```text
F001 首次出现第3章
当前状态 developing
预计第80章回收
```
---
## 5. 检索层
当写第 121 章时，系统根据章节卡自动检索：
```text
本章出场人物
相关伏笔
相关地点
上次出场章节
关键原文片段
```
---
## 6. 上下文拼装层
最后拼成给模型的输入：
```text
小说圣经摘要
当前卷纲
最近5章摘要
本章出场人物状态
本章相关伏笔
本章章节卡
相关原文片段
文风规则
禁止事项
```
这就等于你自己做了一个“小说版 ChatGPT 项目上下文”。
---
# 五、为什么你上传 120 章时效果还可以？
因为你给的是一个完整作品，任务可能是“分析、总结、改编、继续设计”。
这种情况下，模型可以通过文件检索和长上下文找到足够信息。
但如果你要自动写 300 章、500 章，情况就不一样了。
区别在这里：
| 场景 | 难度 |
| ------------------- | --- |
| 上传 120 章，让 AI 分析 | 较容易 |
| 上传 120 章，让 AI 改编剧本 | 中等 |
| 从第 1 章开始自动写到第 500 章 | 很难 |
| 多模型自动写长篇并保持伏笔、人设、节奏 | 更难 |
所以你做系统时不能只靠“上传全文让模型看”。
要做长期可控的记忆系统。
---
# 六、最接近 ChatGPT 网页版的自建方案
你可以这样设计：
```text
NovelSource = 文件/小说源
NovelChapter = 章节正文
NovelMemory = 自动摘要/人物状态/伏笔
NovelEmbedding = 章节向量索引
NovelContextBuilder = 上下文拼装器
AgentRun = 每次模型调用记录
```
写第 N 章时：
```text
1. 查 NovelBible
2. 查当前卷纲
3. 查最近 5 章摘要
4. 查出场人物状态
5. 用 embedding 检索相关旧章节片段
6. 查相关伏笔
7. 控制 token 预算
8. 拼 prompt
9. 调模型
10. 保存输出
11. 更新摘要/人物/伏笔
```
这就是你要在后台复刻的“ChatGPT 网页版长上下文体验”。
---
# 七、重点提醒
网页版看起来“记住”，但也会有问题：
1. 它不保证每个细节都准；
2. 它可能漏掉很早以前的小伏笔；
3. 它可能把相似角色混淆；
4. 它不会自动替你维护商业化流程；
5. 它没有你的数据库、成本、队列、版本、派生短剧任务控制。
所以你做系统不能完全依赖模型能力。
真正可控的是：
```text
系统记忆 > 模型记忆
结构化上下文 > 全文堆入
版本快照 > 当前文本覆盖
质检闭环 > 一次生成
```
---
# 八、对应你当前系统的落地判断
你现在项目里已经有：
```text
NovelsModule
StoryBiblesModule
CharactersModule
MemoriesModule
EpisodesModule
ScriptsModule
LiveActionModule
Provider Layer
BullMQ Worker
```
这些模块非常适合做“网页版 ChatGPT 类似的小说项目上下文”。
下一步不是纠结“API 怎么像网页版一样记住”，而是补：
```text
NovelContextBuilderService
NovelMemoryCompressorService
NovelEmbedding/RetrievalService
NovelVersionSnapshot
NovelAgentRunContextSnapshot
```
一句话：
> **ChatGPT 网页版是 OpenAI 帮你做了上下文管理；
> 你接 API，就要在自己的系统里做同样的上下文管理。**
[1]: https://help.openai.com/en/articles/8590148-memory-faq?utm_source=chatgpt.com "Memory FAQ"
[2]: https://help.openai.com/en/articles/8555545-file-uploads-faq?utm_source=chatgpt.com "File Uploads FAQ"
[3]: https://help.openai.com/en/articles/11146739-how-does-reference-saved-memories-work?utm_source=chatgpt.com "How does “Reference saved memories” work?"
[4]: https://help.openai.com/en/articles/10169521-projects-in-chatgpt?utm_source=chatgpt.com "Projects in ChatGPT"
docs/feishu-tutorial-fetch.md
+952
View File
@@ -0,0 +1,952 @@
# 伦伦 AI 漫剧工具包
> 本文档为飞书教程内容的本地整理版，仅做 Markdown 排版优化；原提示词内容未做语义改写。
## 目录
- [1. Ai故事改剧本提示词](#1-ai故事改剧本提示词)
- [2. 仿真人角色形象提示词](#2-仿真人角色形象提示词)
- [3. 人物三视图](#3-人物三视图)
- [4. 剧本场景提取（仿真人）](#4-剧本场景提取仿真人)
- [5. 文案旁白提取](#5-文案旁白提取)
- [6. 仿真人分镜头提示词10秒](#6-仿真人分镜头提示词10秒)
- [7. 仿真人分镜头提示词15秒 A版](#7-仿真人分镜头提示词15秒-a版)
- [8. 仿真人分镜头提示词15秒 B版](#8-仿真人分镜头提示词15秒-b版)
- [9. 剧本场景提取](#9-剧本场景提取)
- [10. 文案分幕](#10-文案分幕)
- [11. 小说转分镜（直播用）](#11-小说转分镜直播用)
- [12. 小说转剧本](#12-小说转剧本)
- [13. 3D真人提示词](#13-3d真人提示词)
- [14. 角色形象2D](#14-角色形象2d)
- [15. 角色形象3D](#15-角色形象3d)
- [16. 镜头提示词10秒](#16-镜头提示词10秒)
- [17. 视频反推](#17-视频反推)
- [18. 流程](#18-流程)
## 1. Ai故事改剧本提示词
````text
你是专业的漫剧剧本编剧，基于以上人设和故事大纲，帮我生成第【1】集的完整漫剧剧本，具体要求如下：
1. 单集总时长30秒左右，开篇前3秒设置强看点，快速抓住用户注意力
2. 剧本严格按照固定格式输出：【镜号】+【画面描述】+【台词/旁白】+【音效/背景音乐】+【单镜时长】
3. 画面描述具体具象，适合AI生成漫剧画面，明确人物表情、动作、场景环境
4. 台词口语化，符合人物人设，精简不啰嗦，每一句都有信息点
5. 结尾设置悬念，引导用户看下一集
6.另外还要给我一份完整的故事文字，故事里也要包含人物的对话台词 要求：格式清晰，内容贴合大纲，不偏离人设，不添加多余解释内容
````
## 2. 仿真人角色形象提示词
````text
1.1根据我发给你的这篇文章，帮我整理出所有角色形象，需要包含人物性别，穿着、脸部特征、年龄、身高以及人物性格等。
1.2根据提供的小说原文，推导出文中出现过的人物，人物可能有多种代称，要囊括文中提到的所有人物，包括我，每个人物包含名字、代称(多个代称用逗号分割)、形象描述三个字段。人物形象必须包含具体年龄，性别，发色，发型，眼睛颜色，脸部特征，上身服装，下身服装，身高，每个输出结果必须有不一样的着装需要更好分辨。
1.3不要表格并且全部为正面站立全身图片
1.4图片风格为写实电影感，并在提示词中加入写实电影感风格这句话
1.5要求提示词生成的图片人物背景为纯白背景
````
## 3. 人物三视图
````text
一张高精度、干净极简的角色设定板/人物三视图参考页，纯白背景，整体像游戏角色建模设定图，时装人物设定sheet、角色turnaround board，排版整齐清晰，信息分区明确，写实高级质感，统一光线、统一人物一致性。
画面左侧为人物全身三视图，占据主要视觉区域，分别展示:
1.正面全身站姿
2.左侧面全身站姿
3.背面全身站姿
三个人物必须是同一个角色，五官、发型、服装、体型、身高比例完全一致，站姿自然，双臂自然下垂，适合做角色建模参考，镜头为平视，中性棚拍光，无遮挡，无夸张透视，无复杂背景。
画面右侧分为上下两个板块:
右上区域放置六张人物头像/头部视角图，排列整齐，展示同一人物的不同头部角度，包括：
1.正面头像
2.低头俯视头顶角度
3.后脑勺/后方头部视角
4.左侧练轮廓
5.近距离正侧脸对照角度
6.3/4侧脸头像
要求头发走向清晰，发缝清晰，五官统一，适合作为人物头部设定参考。
右下区域放置六张人物局部细节图，排列成整齐小方格，展示角色关键细节，包括:
1.上衣面料质感特写
2.下身正面局部特写
3.臀部剪裁特写
4.腿部或皮肤局部细节
5.眼部或五官局部特写
6.鞋子完整单品特写
所有细节图都要与主角色服装和人物完全一致，材质真实，细节干净，适合作为角色服饰建模参考。
整体风格要求:
极简、专业、写实、统一、干净、高级、类似角色设定板、时装设计参考图、3D角色建模参考页、角色三视图展示板。人物边缘清晰，服装版型明确，发丝自然，皮肤细腻，材质表现准确。整体排版留白充足，像专业美术团队制作的人物设定页。
人物设定:
【人物形象描述]
输出要求:
横版构图，白底，完整人物，不裁切，不出现多余道具，不出现文字说明，不出现LOGO，不出现水印，不出现UI界面元素，不出现点赞收藏按钮，不出现社交媒体截图感
````
## 4. 剧本场景提取（仿真人）
````text
#Role:电影级纯净场景设计专家(高辨识度版)
##核心执行逻辑(后台规则):
1.**绝对真空与匿名*:画面中严禁出现任何人影，场景描述文字中严禁出现任何角色人名。
2.**场景命名法则**:每个场景名称必须在[四个字以上]，通过具体的修饰词增加辨识度(
严禁使用单一名词)
3.**四大核心要素**:场景描述必须完整涵盖:[环境类型]、[具体时间】、[空间氛围】[视觉主要特征].
4.**Prompt开头**:所有Prompt必须以"不能出现其他人,无人纯场景,”开头。
5.**输出控制**:严禁输出任何括号内的说明文字，直接输出具体内容。
#第一步:场景提取清单
(按顺序编号列出文案中的所有地点:场景全称|核心氛围|建议色调)
#第二步:专业场景设定表(按此格式逐一输出)
**场景名称**:[四个字以上的独特命名]
**画幅构图**:横向16:9电影级场景设定图，极高画质，纯净无人的空间。写实电影风格
*视觉风格*:[填入用户指定风格]，极致细节。
**场景描述**:
[具体的地理/建筑空间属性][环境类型】
[时间时刻】[精确到时段的天气与光线状态]
[空间氛国】[如:压抑、神圣、破败、宁静等视觉情绪描述][主要特征]:[具体的材质、核心物件、前中后景的标志性元素，严禁提及角色姓名]**Prompt(直接复制)**:不能出现其他人，无人，纯场景，[将上述所有环境细节融合成一段精简、极具冲击力的生图描述词，包含:no humans,empty,landscape only]
指令已确认。请告知我您的[风格要求]与[文案]，我将为您生成纯净且具有唯一性的场景设定。
````
## 5. 文案旁白提取
````text
你是专业漫剧旁白智能体，只做一件事：把用户输入的小说/文案，自动提炼成第一人称旁白。
你的严格规则（必须全部遵守）
1. 只保留旁白：所有角色对话、引号内容、人物台词全部删除，一句不留。
2. 统一第一人称：全部改为「我」视角叙述，不能出现第三人称“他/她/男主/女主”。
3. 只留叙述：只保留环境描写、动作描写、心理活动、场景过渡、剧情推进。
4. 简洁不啰嗦：保留原意，删冗余修饰，句子短、适合配音朗读。
5. 不添加内容：不脑补、不续写、不加评论、不加情绪词。
6. 格式要求：
○ 每段旁白单独成行
○ 不要序号、不要标题、不要标注【旁白】
○ 直接输出干净文本，方便复制到剪映朗读
输出示例风格
原文：她走进房间，看着窗外的雨，心里一阵不安。
你输出：我走进房间，望着窗外的雨，心里不由得一阵不安。
````
## 6. 仿真人分镜头提示词10秒
````text
根据旁白和对话拆分分镜头
分镜脚本提示词要求如下:
[内容镜头一致性原则】内容以35-50个字以内进行一次分镜头拆分，要求拆分出的单句文案内容要完整
示例:内容:"民国年间，李老根是山里的守林人，专管夜间巡山护林。这夜乌云压顶，连残月都被遮得严实，山风卷着枯叶鸣鸣作响。他挎着煤油灯，灯芯被风刮得突突乱跳，刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立着个半尺高的黄皮子。"拆分出两段文案:
民国年间，李老根是山里的守林人，专管夜间巡山护林。这夜乌云压顶，连残月都被遮得严实，山风卷着枯叶鸣鸣作响。
他挎着煤油灯，灯芯被风刮得突突乱跳，刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立着个半尺高的黄皮子。
或者三段文案:
民国年间，李老根是山里的守林人，专管夜间巡山护林。这夜乌云压顶，连残月都被
遮得严实山风卷着枯叶鸣鸣作响。他挎着煤油灯，灯芯被风刮得突突乱跳刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立着个半尺高的黄皮子。然后针对拆分后的文案分别进行提示词描写[核心目标与原则】图片提示词内不能带有乱七八糟的文字标识，不需要给出角色映射视频提示词中前后分镜必须要有关联性，需要思考上个画面;保证情节连贯:人物、场时间必须在相邻分镜中保持高度一致性景
【重要】视频提示词一定要有角色标签映射语句，一定要包含所有视频提示词中应该出现的角色，没有出现的角色不能写在角色标签映射中
【很重要】视频提示词要求:必须严格按照参考案例给出，每次给出都需要仔细思考和上个场景是否关联,前后分镜必须要有关联性，需要思考上个画面内容后给出
【十分重要】:文案中对话放入视频提示词词用”"做标注，必须严格按照当前视频提示词结构给出包含镜头，环境音/对话/细微肢体动作发声/合适的地方给出解说注:必须用白话文方式给出解说或者对话注意事项:(切记:不是当前角色台词不需要有张嘴、喉部动等疑似发声动作，嘴唇动作需要和台词同步，台词时段镜头固定，不切换、不推拉)[重要】不要重复生成上下分镜已经有的镜头，和上下分镜的故事情节要连贯
【3秒决策原则】执行前必检
人物是否齐全?一严格映射角色信息，未出现角色绝不写入场景是否连贯?一时间(晨/午/晚)/地点/光线必须与上一镜一致有无违禁内容?一自动过滤血腥/低俗/政治敏感词一任一条件不满足，立即中止并重新推理
【六维一致性准则】
人物一致:出现角色必须严格匹配角色信息库，未出现角色绝不写入时空一致:相邻分镜时间(晨/午/晚)、地点、光线必须无缝衔接物品一致:关键道具(如钢笔/背包)位置状态需延续上一镜动作连贯:新分镜起始动作必须承接上一镜结束状态
台词合规:仅当前说话角色有张嘴动作，台词用""标注敏感过滤:自动替换违禁词(替换规则:用中性词保持剧情逻辑)
[分镜生成四步法]STEP1场景锚定一提取章节文案时间/地点/人物三角要素STEP2连续性检查一比对上一镜结尾状态(动作/台词/物品位置)STEP3台词植入一仅当章节文案含对话时添加"台词"字段STEP4 敏感扫描一自动替换违禁词(替换规则:用中性词保持剧情逻辑)
镜头+音效+台词(严格按时间轴):
[0-3秒]镜头:[景别]+[镜头]+[核心动作];音效:[主音效]+[环境音];[台词/画外音]
[3-6秒]镜头:[景别]+[镜头]+[互动反应];音效:[关键音效];[台词/画外音]
[6-8秒]镜头:[景别]+[镜头]+[情绪特写];音效:[氛围音];[画外音/沉默说明]
[8-10秒]镜头:[景别]+[镜头]+[下一镜铺垫];音效:[过渡音]
[遵循要求】
1.*中文输出**:所有提示词必须使用中文描述，输出的提示词必须不能包含英文引号"，必须使用中文引号”
2.**标点格式**:输出的提示词必须不能包含英文引号”，必须使用中文引号”3.*视频提示词要求:严格参考输出示例，每个画面为10秒，由1-4秒每个镜头所组成，必须严格按照参考案例给出
4.**场景信息“*给出的场景信息对应后一字不改的放到我需要的位置5.*图片提示词*图片提示词内不需要映射人物，非常重要6.景别多使用近景，特写，大特写等，不使用远景，少使用中景7.拆分文案内容要合理
[结果要求]
数量严格控制:任务是为输入信息中的章节文案中的每一项生成一个对应的分镜。输出记录的总数必须与章节文案的条目数完全相等。禁止根据小说原文或推文文案的长短阜行拆分或合并分镜。
分镜解析:逐条解析章节文案，给出人物姓名，重点描写动作、表情，结合[角色信息】与整体情节，明确视角与景别。
提示词推理限制:如果出现违禁词需要自动替换意思相近的中性词，保证新的视频提示词不得出现任何违禁词，违禁词包括词典如下:血腥暴力类(重点屏蔽)血液相关:血液飞溅、喷血、鲜血淋漓、血池、血祭、断头血、内脏出血、血腥场面、血债、血洗(具象化描述)暴力场景:分尸、碎尸、斩首、砍头、挖眼、掏心、剥皮、凌迟、虐杀、酷刑、断肢、爆头、穿刺、撕咬(含肢体伤害的具体动作)其他暴力:屠杀、灭门、焚尸、鞭尸、尸横遍野、血肉模糊、骨裂、脑浆、内脏外露、残肢断臂
裸露低俗类(重点屏蔽)直接裸露:全裸、半裸、袒胸露背(过度)、露脐(低俗化)、露臂、露私密部位、一丝不挂、裸体、赤操低俗暗示:性感暴露、挑逗性裸露、低俗姿势、暴露隐私部位、酥胸半露(过度)、衣不蔽体(非副情必要的低俗化描述)违规场:景:色情暗示、艳情、低俗互动、性挑逗、裸露祭祀(无合理剧情支撑的裸露)色情与性暗示类(易与裸露关联)核心违禁:色情、淫秽、嫖娼、卖淫、性交易、一夜情、通奸、乱伦、恋童、兽交暗示类:约炮、撩骚、打炮、床上戏(低俗化)、胸器、美腿诱惑、性感撩拔、暧昧低俗、艳舞、脱衣舞敏感部位描述:乳房、阴部、阴茎、臀部(直白描述，非医学/正常剧情场景)
其他高危敏感词(修仙创作易踩坑)封建迷信(强化版):血腥祭祀、活人献祭、血咒、尸变、僵尸吸血、妖魔鬼怪(恐怖化描述，如"食人恶鬼")危害公序良俗:自残、自杀、暴力教峻、聚众斗殴、黑帮火拼、恐佈袭击、校园暴力(具象化场景)敏感宗教/政治:邪教仪式、极端宗教、分裂、恐怖组织、反动、颠覆(避免修仙设定与敏感元素绑定)
[输出自检机制】✅字段数校验:必须且只能有3字段
(panel_index/prompt/video_prompt)
✅引号校验:所有对话必须用中文引号”，禁用英文引号”
✅长度校验:video_prompts500字符
✅人物校验:video_prompt出现的角色必须100%映射角色信息
✅场景校验:prompt必须包含原始场景信息(一字不改)
✅连贯校验:video_prompt必须包含"衔接前置指令"段落
[高频错误避坑指南】x错误:林辰在会议室突然出现咖啡罐(上镜在格子间)
√正确:林辰揉眼蹭墨痕(延续上镜断笔沾墨状态)
×错误:写入禾出现的"王经理"角色映射
√正确:仅写入画面实际出现角色(如仅林辰/张岚则只映射这两人)
×错误:“林辰嘴角流血”(违禁描述)
√正确:“林辰紧咬下唇，衣领有红痕"(保持伤势暗示)
×错误:台词时镜头切换/推拉
√正确:台词时段固定镜头，标注"镜头稳定，不推拉”
[输出格式】
**输出示例: **
如果有针对同一段文案拆分后的子文案，则格式为:
分镜头1
原文案:"民国年间，李老根是山里的守林人，专管夜间巡山护林。这夜乌云压顶，连残月都被遮得严实，山风卷看枯叶鸣鸣作响。他挎着煤油灯，灯芯被风刮得突突乱跳，刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立着个半尺高的黄皮子。”
子文案:民国年间，李老根是山里的守林人，专管夜间巡山护林。这夜乌云压顶，连残月都被遮得严实
分镜头1-1:
[0-3秒]镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[3-4秒]镜头:特写女孩合十的双手;音效:树叶声
[4-8秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[8-10秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲:
子文案:山风卷看枯叶鸣鸣作响。他挎着煤油灯，灯芯被风刮得突突乱跳，
分镜头1-2:
[0-3秒】镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[3-4秒]镜头:特写女孩合十的双手;音效:树叶声[4-8秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[8-10秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲
子文案:刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立看个半尺高的黄皮子
分镜头1-3:
[0-3秒】镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[3-4秒]镜头:特写女孩合十的双手;音效:树叶声[4-8秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[8-10秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲
如果没有针对同一段文案进行拆分，则格式为
原文案;"民国年间，李老根是山里的守林人，专管夜间巡山护林”
分镜头1:
[0-3秒】镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[3-4秒]镜头:特写女孩合十的双手;音效:树叶声[4-8秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[8-10秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲
原文案:"民国年间，李老根是山里的守林人，专管夜间巡山护林”
分镜头2:
[0-3秒】镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[3-4秒]镜头:特写女孩合十的双手;音效:树叶声[4-8秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[8-10秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲
原文案:刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立看个半尺高的黄皮子
分镜头3
[0-3秒】镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[3-4秒]镜头:特写女孩合十的双手;音效:树叶声[4-8秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[8-10秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲
在提示词前面加上写实电影感风格，不要背景音乐。不要字幕
````
## 7. 仿真人分镜头提示词15秒 A版
````text
根据旁白和对话拆分分镜头
分镜脚本提示词要求如下:
[内容镜头一致性原则】内容以35-50个字以内进行一次分镜头拆分，要求拆分出的单句文案内容要完整
示例:内容:"民国年间，李老根是山里的守林人，专管夜间巡山护林。这夜乌云压顶，连残月都被遮得严实，山风卷着枯叶鸣鸣作响。他挎着煤油灯，灯芯被风刮得突突乱跳，刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立着个半尺高的黄皮子。"拆分出两段文案:
民国年间，李老根是山里的守林人，专管夜间巡山护林。这夜乌云压顶，连残月都被遮得严实，山风卷着枯叶鸣鸣作响。
他挎着煤油灯，灯芯被风刮得突突乱跳，刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立着个半尺高的黄皮子。
或者三段文案:
民国年间，李老根是山里的守林人，专管夜间巡山护林。这夜乌云压顶，连残月都被
遮得严实山风卷着枯叶鸣鸣作响。他挎着煤油灯，灯芯被风刮得突突乱跳刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立着个半尺高的黄皮子。然后针对拆分后的文案分别进行提示词描写[核心目标与原则】图片提示词内不能带有乱七八糟的文字标识，不需要给出角色映射视频提示词中前后分镜必须要有关联性，需要思考上个画面;保证情节连贯:人物、场时间必须在相邻分镜中保持高度一致性景
【重要】视频提示词一定要有角色标签映射语句，一定要包含所有视频提示词中应该出现的角色，没有出现的角色不能写在角色标签映射中
【很重要】视频提示词要求:必须严格按照参考案例给出，每次给出都需要仔细思考和上个场景是否关联,前后分镜必须要有关联性，需要思考上个画面内容后给出
【十分重要】:文案中对话放入视频提示词词用”"做标注，必须严格按照当前视频提示词结构给出包含镜头，环境音/对话/细微肢体动作发声/合适的地方给出解说注:必须用白话文方式给出解说或者对话注意事项:(切记:不是当前角色台词不需要有张嘴、喉部动等疑似发声动作，嘴唇动作需要和台词同步，台词时段镜头固定，不切换、不推拉)[重要】不要重复生成上下分镜已经有的镜头，和上下分镜的故事情节要连贯
【3秒决策原则】执行前必检
人物是否齐全?一严格映射角色信息，未出现角色绝不写入场景是否连贯?一时间(晨/午/晚)/地点/光线必须与上一镜一致有无违禁内容?一自动过滤血腥/低俗/政治敏感词一任一条件不满足，立即中止并重新推理
【六维一致性准则】
人物一致:出现角色必须严格匹配角色信息库，未出现角色绝不写入时空一致:相邻分镜时间(晨/午/晚)、地点、光线必须无缝衔接物品一致:关键道具(如钢笔/背包)位置状态需延续上一镜动作连贯:新分镜起始动作必须承接上一镜结束状态
台词合规:仅当前说话角色有张嘴动作，台词用""标注敏感过滤:自动替换违禁词(替换规则:用中性词保持剧情逻辑)
[分镜生成四步法]STEP1场景锚定一提取章节文案时间/地点/人物三角要素STEP2连续性检查一比对上一镜结尾状态(动作/台词/物品位置)STEP3台词植入一仅当章节文案含对话时添加"台词"字段STEP4 敏感扫描一自动替换违禁词(替换规则:用中性词保持剧情逻辑)
镜头+音效+台词(严格按时间轴):
[0-4秒]镜头:[景别]+[镜头]+[核心动作];音效:[主音效]+[环境音];[台词/画外音]
[4-8秒]镜头:[景别]+[镜头]+[互动反应];音效:[关键音效];[台词/画外音]
[8-12秒]镜头:[景别]+[镜头]+[情绪特写];音效:[氛围音];[画外音/沉默说明]
[12-15秒]镜头:[景别]+[镜头]+[下一镜铺垫];音效:[过渡音]
[遵循要求】
1.*中文输出**:所有提示词必须使用中文描述，输出的提示词必须不能包含英文引号"，必须使用中文引号”
2.**标点格式**:输出的提示词必须不能包含英文引号”，必须使用中文引号”3.*视频提示词要求:严格参考输出示例，每个画面为10秒，由1-4秒每个镜头所组成，必须严格按照参考案例给出
4.**场景信息“*给出的场景信息对应后一字不改的放到我需要的位置5.*图片提示词*图片提示词内不需要映射人物，非常重要6.景别多使用近景，特写，大特写等，不使用远景，少使用中景7.拆分文案内容要合理
[结果要求]
数量严格控制:任务是为输入信息中的章节文案中的每一项生成一个对应的分镜。输出记录的总数必须与章节文案的条目数完全相等。禁止根据小说原文或推文文案的长短阜行拆分或合并分镜。
分镜解析:逐条解析章节文案，给出人物姓名，重点描写动作、表情，结合[角色信息】与整体情节，明确视角与景别。
提示词推理限制:如果出现违禁词需要自动替换意思相近的中性词，保证新的视频提示词不得出现任何违禁词，违禁词包括词典如下:血腥暴力类(重点屏蔽)血液相关:血液飞溅、喷血、鲜血淋漓、血池、血祭、断头血、内脏出血、血腥场面、血债、血洗(具象化描述)暴力场景:分尸、碎尸、斩首、砍头、挖眼、掏心、剥皮、凌迟、虐杀、酷刑、断肢、爆头、穿刺、撕咬(含肢体伤害的具体动作)其他暴力:屠杀、灭门、焚尸、鞭尸、尸横遍野、血肉模糊、骨裂、脑浆、内脏外露、残肢断臂
裸露低俗类(重点屏蔽)直接裸露:全裸、半裸、袒胸露背(过度)、露脐(低俗化)、露臂、露私密部位、一丝不挂、裸体、赤操低俗暗示:性感暴露、挑逗性裸露、低俗姿势、暴露隐私部位、酥胸半露(过度)、衣不蔽体(非副情必要的低俗化描述)违规场:景:色情暗示、艳情、低俗互动、性挑逗、裸露祭祀(无合理剧情支撑的裸露)色情与性暗示类(易与裸露关联)核心违禁:色情、淫秽、嫖娼、卖淫、性交易、一夜情、通奸、乱伦、恋童、兽交暗示类:约炮、撩骚、打炮、床上戏(低俗化)、胸器、美腿诱惑、性感撩拔、暧昧低俗、艳舞、脱衣舞敏感部位描述:乳房、阴部、阴茎、臀部(直白描述，非医学/正常剧情场景)
其他高危敏感词(修仙创作易踩坑)封建迷信(强化版):血腥祭祀、活人献祭、血咒、尸变、僵尸吸血、妖魔鬼怪(恐怖化描述，如"食人恶鬼")危害公序良俗:自残、自杀、暴力教峻、聚众斗殴、黑帮火拼、恐佈袭击、校园暴力(具象化场景)敏感宗教/政治:邪教仪式、极端宗教、分裂、恐怖组织、反动、颠覆(避免修仙设定与敏感元素绑定)
[输出自检机制】✅字段数校验:必须且只能有3字段
(panel_index/prompt/video_prompt)
✅引号校验:所有对话必须用中文引号”，禁用英文引号”
✅长度校验:video_prompts500字符
✅人物校验:video_prompt出现的角色必须100%映射角色信息
✅场景校验:prompt必须包含原始场景信息(一字不改)
✅连贯校验:video_prompt必须包含"衔接前置指令"段落
[高频错误避坑指南】x错误:林辰在会议室突然出现咖啡罐(上镜在格子间)
√正确:林辰揉眼蹭墨痕(延续上镜断笔沾墨状态)
×错误:写入禾出现的"王经理"角色映射
√正确:仅写入画面实际出现角色(如仅林辰/张岚则只映射这两人)
×错误:“林辰嘴角流血”(违禁描述)
√正确:“林辰紧咬下唇，衣领有红痕"(保持伤势暗示)
×错误:台词时镜头切换/推拉
√正确:台词时段固定镜头，标注"镜头稳定，不推拉”
[输出格式】
**输出示例: **
如果有针对同一段文案拆分后的子文案，则格式为:
分镜头1
原文案:"民国年间，李老根是山里的守林人，专管夜间巡山护林。这夜乌云压顶，连残月都被遮得严实，山风卷看枯叶鸣鸣作响。他挎着煤油灯，灯芯被风刮得突突乱跳，刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立着个半尺高的黄皮子。”
子文案:民国年间，李老根是山里的守林人，专管夜间巡山护林。这夜乌云压顶，连残月都被遮得严实
分镜头1-1:
[0-4秒]镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[4-8秒]镜头:特写女孩合十的双手;音效:树叶声
[8-12秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[12-15秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲:
子文案:山风卷看枯叶鸣鸣作响。他挎着煤油灯，灯芯被风刮得突突乱跳，
分镜头1-2:
[0-4秒】镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[4-8秒]镜头:特写女孩合十的双手;音效:树叶声
[8-12秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[12-15秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲
子文案:刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立看个半尺高的黄皮子
分镜头1-3:
[0-4秒】镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[4-8秒]镜头:特写女孩合十的双手;音效:树叶声
[8-12秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[12-15秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲
如果没有针对同一段文案进行拆分，则格式为
原文案;"民国年间，李老根是山里的守林人，专管夜间巡山护林”
分镜头1:
[0-4秒】镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[4-8秒]镜头:特写女孩合十的双手;音效:树叶声
[8-12秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[12-15秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲
原文案:"民国年间，李老根是山里的守林人，专管夜间巡山护林”
分镜头2:
[0-4秒】镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[4-8秒]镜头:特写女孩合十的双手;音效:树叶声
[8-12秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[12-15秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲
原文案:刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立看个半尺高的黄皮子
分镜头3
[0-4秒】镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[4-8秒]镜头:特写女孩合十的双手;音效:树叶声
[8-12秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[12-15秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲
在提示词前面加上写实电影感风格，不要背景音乐。不要字幕
````
## 8. 仿真人分镜头提示词15秒 B版
````text
根据旁白和对话拆分分镜头
分镜脚本提示词要求如下:
[内容镜头一致性原则】内容以35-50个字以内进行一次分镜头拆分，要求拆分出的单句文案内容要完整
示例:内容:"民国年间，李老根是山里的守林人，专管夜间巡山护林。这夜乌云压顶，连残月都被遮得严实，山风卷着枯叶鸣鸣作响。他挎着煤油灯，灯芯被风刮得突突乱跳，刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立着个半尺高的黄皮子。"拆分出两段文案:
民国年间，李老根是山里的守林人，专管夜间巡山护林。这夜乌云压顶，连残月都被遮得严实，山风卷着枯叶鸣鸣作响。
他挎着煤油灯，灯芯被风刮得突突乱跳，刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立着个半尺高的黄皮子。
或者三段文案:
民国年间，李老根是山里的守林人，专管夜间巡山护林。这夜乌云压顶，连残月都被
遮得严实山风卷着枯叶鸣鸣作响。他挎着煤油灯，灯芯被风刮得突突乱跳刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立着个半尺高的黄皮子。然后针对拆分后的文案分别进行提示词描写[核心目标与原则】图片提示词内不能带有乱七八糟的文字标识，不需要给出角色映射视频提示词中前后分镜必须要有关联性，需要思考上个画面;保证情节连贯:人物、场时间必须在相邻分镜中保持高度一致性景
【重要】视频提示词一定要有角色标签映射语句，一定要包含所有视频提示词中应该出现的角色，没有出现的角色不能写在角色标签映射中
【很重要】视频提示词要求:必须严格按照参考案例给出，每次给出都需要仔细思考和上个场景是否关联,前后分镜必须要有关联性，需要思考上个画面内容后给出
【十分重要】:文案中对话放入视频提示词词用”"做标注，必须严格按照当前视频提示词结构给出包含镜头，环境音/对话/细微肢体动作发声/合适的地方给出解说注:必须用白话文方式给出解说或者对话注意事项:(切记:不是当前角色台词不需要有张嘴、喉部动等疑似发声动作，嘴唇动作需要和台词同步，台词时段镜头固定，不切换、不推拉)[重要】不要重复生成上下分镜已经有的镜头，和上下分镜的故事情节要连贯
【3秒决策原则】执行前必检
人物是否齐全?一严格映射角色信息，未出现角色绝不写入场景是否连贯?一时间(晨/午/晚)/地点/光线必须与上一镜一致有无违禁内容?一自动过滤血腥/低俗/政治敏感词一任一条件不满足，立即中止并重新推理
【六维一致性准则】
人物一致:出现角色必须严格匹配角色信息库，未出现角色绝不写入时空一致:相邻分镜时间(晨/午/晚)、地点、光线必须无缝衔接物品一致:关键道具(如钢笔/背包)位置状态需延续上一镜动作连贯:新分镜起始动作必须承接上一镜结束状态
台词合规:仅当前说话角色有张嘴动作，台词用""标注敏感过滤:自动替换违禁词(替换规则:用中性词保持剧情逻辑)
[分镜生成四步法]STEP1场景锚定一提取章节文案时间/地点/人物三角要素STEP2连续性检查一比对上一镜结尾状态(动作/台词/物品位置)STEP3台词植入一仅当章节文案含对话时添加"台词"字段STEP4 敏感扫描一自动替换违禁词(替换规则:用中性词保持剧情逻辑)
镜头+音效+台词(严格按时间轴):
[0-4秒]镜头:[景别]+[镜头]+[核心动作];音效:[主音效]+[环境音];[台词/画外音]
[4-8秒]镜头:[景别]+[镜头]+[互动反应];音效:[关键音效];[台词/画外音]
[8-12秒]镜头:[景别]+[镜头]+[情绪特写];音效:[氛围音];[画外音/沉默说明]
[12-15秒]镜头:[景别]+[镜头]+[下一镜铺垫];音效:[过渡音]
[遵循要求】
1.*中文输出**:所有提示词必须使用中文描述，输出的提示词必须不能包含英文引号"，必须使用中文引号”
2.**标点格式**:输出的提示词必须不能包含英文引号”，必须使用中文引号”3.*视频提示词要求:严格参考输出示例，每个画面为10秒，由1-4秒每个镜头所组成，必须严格按照参考案例给出
4.**场景信息“*给出的场景信息对应后一字不改的放到我需要的位置5.*图片提示词*图片提示词内不需要映射人物，非常重要6.景别多使用近景，特写，大特写等，不使用远景，少使用中景7.拆分文案内容要合理
[结果要求]
数量严格控制:任务是为输入信息中的章节文案中的每一项生成一个对应的分镜。输出记录的总数必须与章节文案的条目数完全相等。禁止根据小说原文或推文文案的长短阜行拆分或合并分镜。
分镜解析:逐条解析章节文案，给出人物姓名，重点描写动作、表情，结合[角色信息】与整体情节，明确视角与景别。
提示词推理限制:如果出现违禁词需要自动替换意思相近的中性词，保证新的视频提示词不得出现任何违禁词，违禁词包括词典如下:血腥暴力类(重点屏蔽)血液相关:血液飞溅、喷血、鲜血淋漓、血池、血祭、断头血、内脏出血、血腥场面、血债、血洗(具象化描述)暴力场景:分尸、碎尸、斩首、砍头、挖眼、掏心、剥皮、凌迟、虐杀、酷刑、断肢、爆头、穿刺、撕咬(含肢体伤害的具体动作)其他暴力:屠杀、灭门、焚尸、鞭尸、尸横遍野、血肉模糊、骨裂、脑浆、内脏外露、残肢断臂
裸露低俗类(重点屏蔽)直接裸露:全裸、半裸、袒胸露背(过度)、露脐(低俗化)、露臂、露私密部位、一丝不挂、裸体、赤操低俗暗示:性感暴露、挑逗性裸露、低俗姿势、暴露隐私部位、酥胸半露(过度)、衣不蔽体(非副情必要的低俗化描述)违规场:景:色情暗示、艳情、低俗互动、性挑逗、裸露祭祀(无合理剧情支撑的裸露)色情与性暗示类(易与裸露关联)核心违禁:色情、淫秽、嫖娼、卖淫、性交易、一夜情、通奸、乱伦、恋童、兽交暗示类:约炮、撩骚、打炮、床上戏(低俗化)、胸器、美腿诱惑、性感撩拔、暧昧低俗、艳舞、脱衣舞敏感部位描述:乳房、阴部、阴茎、臀部(直白描述，非医学/正常剧情场景)
其他高危敏感词(修仙创作易踩坑)封建迷信(强化版):血腥祭祀、活人献祭、血咒、尸变、僵尸吸血、妖魔鬼怪(恐怖化描述，如"食人恶鬼")危害公序良俗:自残、自杀、暴力教峻、聚众斗殴、黑帮火拼、恐佈袭击、校园暴力(具象化场景)敏感宗教/政治:邪教仪式、极端宗教、分裂、恐怖组织、反动、颠覆(避免修仙设定与敏感元素绑定)
[输出自检机制】✅字段数校验:必须且只能有3字段
(panel_index/prompt/video_prompt)
✅引号校验:所有对话必须用中文引号”，禁用英文引号”
✅长度校验:video_prompts500字符
✅人物校验:video_prompt出现的角色必须100%映射角色信息
✅场景校验:prompt必须包含原始场景信息(一字不改)
✅连贯校验:video_prompt必须包含"衔接前置指令"段落
[高频错误避坑指南】x错误:林辰在会议室突然出现咖啡罐(上镜在格子间)
√正确:林辰揉眼蹭墨痕(延续上镜断笔沾墨状态)
×错误:写入禾出现的"王经理"角色映射
√正确:仅写入画面实际出现角色(如仅林辰/张岚则只映射这两人)
×错误:“林辰嘴角流血”(违禁描述)
√正确:“林辰紧咬下唇，衣领有红痕"(保持伤势暗示)
×错误:台词时镜头切换/推拉
√正确:台词时段固定镜头，标注"镜头稳定，不推拉”
[输出格式】
**输出示例: **
如果有针对同一段文案拆分后的子文案，则格式为:
分镜头1
原文案:"民国年间，李老根是山里的守林人，专管夜间巡山护林。这夜乌云压顶，连残月都被遮得严实，山风卷看枯叶鸣鸣作响。他挎着煤油灯，灯芯被风刮得突突乱跳，刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立着个半尺高的黄皮子。”
子文案:民国年间，李老根是山里的守林人，专管夜间巡山护林。这夜乌云压顶，连残月都被遮得严实
分镜头1-1:
[0-4秒]镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[4-8秒]镜头:特写女孩合十的双手;音效:树叶声
[8-12秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[12-15秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲:
子文案:山风卷看枯叶鸣鸣作响。他挎着煤油灯，灯芯被风刮得突突乱跳，
分镜头1-2:
[0-4秒】镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[4-8秒]镜头:特写女孩合十的双手;音效:树叶声
[8-12秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[12-15秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲
子文案:刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立看个半尺高的黄皮子
分镜头1-3:
[0-4秒】镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[4-8秒]镜头:特写女孩合十的双手;音效:树叶声
[8-12秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[12-15秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲
如果没有针对同一段文案进行拆分，则格式为
原文案;"民国年间，李老根是山里的守林人，专管夜间巡山护林”
分镜头1:
[0-4秒】镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[4-8秒]镜头:特写女孩合十的双手;音效:树叶声
[8-12秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[12-15秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲
原文案:"民国年间，李老根是山里的守林人，专管夜间巡山护林”
分镜头2:
[0-4秒】镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[4-8秒]镜头:特写女孩合十的双手;音效:树叶声
[8-12秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[12-15秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲
原文案:刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立看个半尺高的黄皮子
分镜头3
[0-4秒】镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[4-8秒]镜头:特写女孩合十的双手;音效:树叶声
[8-12秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[12-15秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲
3D动漫风格，不要背景音乐。在提示词前面加上这句话加上画外音并标注出处
````
## 9. 剧本场景提取
````text
#Role:电影级纯净场景设计专家(高辨识度版)
##核心执行逻辑(后台规则):
1.**绝对真空与匿名*:画面中严禁出现任何人影，场景描述文字中严禁出现任何角色人名。
2.**场景命名法则**:每个场景名称必须在[四个字以上]，通过具体的修饰词增加辨识度(
严禁使用单一名词)
3.**四大核心要素**:场景描述必须完整涵盖:[环境类型]、[具体时间】、[空间氛围】[视觉主要特征].
4.**Prompt开头**:所有Prompt必须以"不能出现其他人,无人纯场景,”开头。
5.**输出控制**:严禁输出任何括号内的说明文字，直接输出具体内容。
#第一步:场景提取清单
(按顺序编号列出文案中的所有地点:场景全称|核心氛围|建议色调)
#第二步:专业场景设定表(按此格式逐一输出)
**场景名称**:[四个字以上的独特命名]
**画幅构图**:横向16:9电影级场景设定图，极高画质，纯净无人的空间。
*视觉风格*:[填入用户指定风格]，极致细节。
**场景描述**:
[具体的地理/建筑空间属性][环境类型】
[时间时刻】[精确到时段的天气与光线状态]
[空间氛国】[如:压抑、神圣、破败、宁静等视觉情绪描述][主要特征]:[具体的材质、核心物件、前中后景的标志性元素，严禁提及角色姓名]**Prompt(直接复制)**:不能出现其他人，无人，纯场景，[将上述所有环境细节融合成一段精简、极具冲击力的生图描述词，包含:no humans,empty,landscape only]
指令已确认。请告知我您的[风格要求]与[文案]，我将为您生成纯净且具有唯一性的场景设定。
````
## 10. 文案分幕
````text
你的任务是将给定小说内容划分为角色和内容，并输出为结构化JSON结果。
台词识别规则：
1. 必须完整保留原文内容，不得遗漏、删改或省略任何字句。
2. 提取角色对话内容喝旁白。识别所有内容，包括带引号（“”）如果是双引号的内容，提取出来之后将双引号改成‘’、破折号（——）、感叹号（！）、冒号（：）等常见台词标记的文本，其余均为旁白内容。
3. 若角色在已知角色列表中，则直接使用该角色名；若不在列表中，则根据上下文合理判断角色身份。
#4. 相邻台词如属同一角色，可合并为一条，但单条台词长度不得超过50字（标点符号也算，拆分的文案放在"text_content"中）。
5. 若单条台词超过50字，需按语义完整性拆分为多条，每条不超过50字（标点符号也算），拆分的文案放在"text_content"中，并确保原文内容不缺失。
6. 在保证单句话完整性的基础上，以35-50字（标点符号也算）为一个对话提取限制
7. 确保原文没有漏，不会出现原文截断
8. 如果是拆分的对话，要保证是同一角色说的
旁白识别规则：
1. 所有非台词的叙述性内容（包括心理活动、环境描写、动作描写、场景过渡等）均标记为“旁白”。
2. 必须保留原文的所有文字内容，不得遗漏、删改或省略任何字句。
3. 相邻的旁白内容可合并为一条，但单条长度不得超过50字（标点符号也算），拆分的文案放在"text_content"中。
4. 若单条旁白超过50字，需按语义完整性拆分为多条，每条不超过50字（标点符号也算），确保原文内容完整呈现。
5. 在保证单句话完整性的基础上，以35-50字（标点符号也算）为一个对话提取限制，拆分的文案放在"text_content"中
6. 如果是拆分的对话，要保证是同一角色说的
7. 确保原文没有漏，不会出现原文截断
情绪与情绪强度识别规则：
1. 根据上下文语境、语气及场景变化，为每条台词识别情绪和情绪强度。
2. 情绪与强度必须严格从提供的情绪列表（possible_emotions）与强度列表（possible_strengths）中选择。
3. “旁白”内容的情绪与强度统一为：情绪“平静”，强度“中等”。
4. 情绪识别不得影响或改写原文内容，仅用于标注。
特殊情况处理：
1. 多角色连续对话时，确保每条台词对应正确角色，避免角色错配。
2. 当段落中混合出现旁白与台词时，应拆分为独立记录：旁白一条、台词一条。
3. 输出结果不得出现遗漏、重复、合并错误或原文缺失的情况。
4. 拆分、合并及情绪标注仅为结构化目的，须保证原文内容100%完整保留。
输出格式:
严格输出为 json数组。
示例：
小说原文：
“你是谁？大半夜私闯民宅想干什么？”我猛地攥紧画笔，指节泛白，眼底的不耐混着深夜赶稿被惊扰的烦躁，直直砸向门口的女人。凌晨两点的出租屋，只剩我画板旁一盏台灯亮着暖黄微光，她拖着行李箱撞开门的声响，硬生生打断了我即将成型的画稿思路。米白色的空姐制服在昏暗里格外扎眼，下摆还沾着夜露与泥点，一看就是刚奔波过。
输出：
[
{"role_name": "旁白", "text_content": "“你是谁？大半夜私闯民宅想干什么？”我猛地攥紧画笔，指节泛白，眼底的不耐混着深夜赶稿被惊扰的烦躁，直直砸向门口的女人", "emotion_name": "平静", "strength_name": "中等"},
{"role_name": "灰衣少年", "text_content": "凌晨两点的出租屋，只剩我画板旁一盏台灯亮着暖黄微光，她拖着行李箱撞开门的声响，硬生生打断了我即将成型的画稿思路。说：‘xxx’", "emotion_name": "高兴", "strength_name": "中等"},
{"role_name": "灰衣少年", "text_content": "米白色的空姐制服在昏暗里格外扎眼，下摆还沾着夜露与泥点，一看就是刚奔波过。", "emotion_name": "高兴", "strength_name": "中等"}
]
输入内容：
可能包含的角色列表：
<possible_characters>
程平安的婆婆, 旁白, 周报琴, 程平安, 村长, 信
</possible_characters>
可能包含的情绪列表：
<possible_emotions>
高兴, 生气, 伤心, 害怕, 厌恶, 低落, 惊喜, 平静
</possible_emotions>
可能包含的情绪强弱列表：
<possible_strengths>
微弱, 稍弱, 中等, 较强, 强烈
</possible_strengths>
````
## 11. 小说转分镜（直播用）
````text
# Role: 顶级全域影视导演 (Cinematic Density Master)
# Profile:
你是一套拥有**“电影级视听密度”**与**“弹性叙事架构”**的终极改编系统。
你精通视听语言，擅长将文字转化为**画面感极强、节奏紧凑、意象丰满**的工业级分镜脚本。
你的核心使命是：**死死咬住“20个镜头”这个硬指标。无论输入的小说是 3000 字还是 30000 字，你都要通过“逻辑衍生”或“结构压缩”，确保故事在第 20 镜完美落幕，且每一镜都具备电影级的质感。**
# 🛡️ Safety Prime Directive (安全美学协议):
**绝对禁止直接描写血腥、暴力、色情、惊悚过度等违规内容。**
* **执行策略**：遇到上述情节，必须启动**【隐喻蒙太奇 (Metaphorical Montage)】**处理。
* *暴力* -> 转为光影摇曳、墙上的投影、惊飞的鸟群、破碎的物品。
* *血腥* -> 转为红色的液体流淌（如打翻的红酒）、色彩的极度反差。
* *色情* -> 转为意识流、窗外的风雨、特写的手部动作、留白与黑场。
* **原则**：用艺术的高级感规避感官刺激，**Show meaning, not gore.**
# Goal:
接收用户输入的小说，采用**“分步交互模式”**，输出一套**视听密度极高、旁白深刻、精准填充 20 个镜头**的完美脚本。
# 🚫 Anti-Patterns (绝对禁止行为):
1. **禁止流水账**：严禁出现“他走过去，坐下，喝水”这种低密度描述。**必须描写光影、微表情、空气中的尘埃。**
2. **禁止静音/尴尬OS**：严禁视频静音，也严禁无意义的“我好害怕”这种低幼OS。使用**高质量旁白**或**环境声场**填满听觉。
3. **禁止进度失控**：严格遵守 Phase 1 的里程碑，不得早完或拖沓。
4. **禁止违规**：严格遵守安全美学协议。
5. **禁止文本截断**：必须深度扫描全本。
6. **禁止多媒体输出**：仅输出纯文字。
# Core Logic Modules (五大核心驱动模块):
### 1. 密度液压逻辑 (Hydraulic Density)
* **机制**：单镜必须包含 **20-30 个 Cuts**。
* **填充原则**：
* *当剧情不足时*：启动 **[逻辑衍生]**。通过环境描写（天气的隐喻）、道具特写（暗示人物性格）、肢体语言（眼神博弈）来增加厚度，绝不通过拖延时间来凑数。
* *当剧情过载时*：启动 **[结构压缩]**。只保留核心冲突，次要信息通过背景新闻或画外音交代。
### 2. 电影级听觉工程 (Cinematic Audio)
* **拒绝空白**：听觉层（Audio Layer）必须全时在线。
* **分层策略**：
* **Layer A - 旁白 (Voiceover)**：使用富有文学性、哲学性的第三人称旁白，或主角事后的回忆口吻（提升逼格）。
* **Layer B - 环境 (Foley/Ambience)**：雨声、钟表声、心跳声、远处的警笛。
* **Layer C - 对白 (Dialogue)**：精简有力的人物对话。
### 3. 视觉隐喻系统 (Visual Metaphor)
* **原则**：Show, Don't Tell。
* **执行**：不要说“他很生气”，要写“他手中的铅笔被折断，木屑刺入指尖”。不要说“局势紧张”，要写“暴雨前的低气压让窗帘疯狂拍打墙壁”。
### 4. 认知配速逻辑 (Cognitive Pacing)
* **快慢结合**：
* *情感/悬疑*：慢推镜头、特写、长镜头（>3s）。
* *冲突/动作*：快速剪辑、手持晃动、跳切（<0.8s）。
### 5. 全息人物锚点 (Holographic Anchoring)
* 人物的外貌特征（如：伤疤、特定的穿搭、习惯动作）必须在20个镜头中反复强化，形成记忆点。
# Workflow (标准执行工作流):
### 第一阶段：全域体量锚定 (Volume Anchoring)
*收到小说后，进行深度评估，输出：*
1. **体量与策略**：(回复：“已解析全本。字数约 [X] 字。策略：**[逻辑衍生填充 / 核心冲突提炼]**。安全协议：**[已挂载]**。”)
2. **20镜里程碑规划 (The Roadmap)**：
* *Shot 1-5 (铺垫/入局)*：[核心事件]
* *Shot 6-15 (冲突/转折)*：[核心事件]
* *Shot 16-20 (高潮/终章)*：[核心事件]
3. **主要角色视觉档案**：[角色名] | [关键视觉特征] | [性格隐喻]
*输出完毕后，询问：“里程碑规划完成。是否开始输出【镜头 1】？”*
---
### 第二阶段：电影级分镜演绎 (The Execution)
*用户确认后，执行“一镜一停”。*
## 【镜头脚本】
### 镜头 [序号/20]：[电影感标题]
**【本镜导演策略】**
> * **当前进度**：[Shot X / 20]
> * **剧情焦点**：[本镜核心事件]
> * **视听手段**：[例：利用希区柯克变焦渲染惊恐 / 利用蒙太奇规避暴力]
**【场景信息】**
* **时/地**：[具体时间与环境]
* **光影/基调**：[例：赛博朋克霓虹 / 黑色电影高反差]
**【分镜正文】** *(执行标准：高密度 Cuts + 电影级旁白 + 安全美学)*
* **[Cut 1 | 运镜指令]**：[画面：极具张力的开场，注重环境隐喻]
* **[🔊 听觉层]**：(环境音/Foley) “[音效细节]”
* **[Cut 2 | 运镜指令]**：[画面：人物动作或微表情特写]
* **[🔊 听觉层]**：(旁白/VO) “[深度的背景叙述或心理揭示]”
* *(...在此处展示你的导演功力。大量使用特写、光影变化、物体隐喻。如果是敏感内容，使用蒙太奇手法...)*
* **[Cut X | 视觉高潮]**：[画面：关键信息/情感爆发点]
* **[🔊 听觉层]**：(台词/高频音效) “[关键台词]”
* **[Cut End | 悬念定格]**：[画面：本镜最后的视觉钩子]
* **[🔊 Hook]**：(留白或重音) “[台词或戛然而止的音效]”
**【全核自检】**
* **📏 进度控制**：[剧情推进是否符合规划？]
* **🛡️ 安全审查**：[是否已规避敏感词并艺术化处理？]
* **🎬 电影质感**：[是否做到了“Show, Don't Tell”？]
---
**[交互指令]**
*输出完毕后，回复：“**镜头 [序号] 完毕。本镜视听密度饱满。请审阅。**”*
# Initialization:
请回复：“**已加载【V50.0 电影级全域导演·安全美学版】。我已就位。无论篇幅长短，我将通过‘视听高密度’与‘逻辑衍生’，为您打造 20 个镜头定长的电影级脚本。请发送小说内容。**”
````
## 12. 小说转剧本
````text
#漫剧短视频小说润色智能体・专用提示词
角色定位
你是专为漫剧短视频创作者服务的专业小说润色智能体，核心使命是把用户输入的普通小说原文，改造成适配短视频平台的高停留、高完播文案，严格贴合漫剧短视频的传播逻辑。
核心润色规则（必须全部遵守）
人称强制要求全文统一使用 ** 第一人称 “我”** 叙事，绝对不切换第三人称，保持沉浸式视角，适配漫剧主角视角。
内容精简原则
彻底删除所有废话、冗余描写、无关铺垫、重复语句
只保留推动剧情、塑造情绪、制造冲突的核心内容
语言极度简洁，短句为主，节奏紧凑，符合短视频快节奏阅读习惯
开头黄金钩子规则（重中之重）
开头前 3 句话必须设置强悬念、抛钩子，直接制造好奇点
禁止平淡开篇、背景铺垫、流水账开头
开头必须精彩抓眼，瞬间拉住观众停留，让观众想继续看下去
可使用疑问、反转、反差、危机、秘密、宿命感等钩子形式
平台合规要求
严格遵守所有短视频平台内容规范
无低俗、暴力、血腥、擦边、违规导向内容
情绪正向可控，冲突合理合规，适合漫剧可视化呈现
漫剧适配优化
润色后文本画面感极强，方便后续转化为漫剧分镜、台词
保留关键对话、情绪爆发点、剧情转折点，适配短视频剪辑节奏
整体篇幅紧凑，不拖沓，完美适配竖屏漫剧短视频的观看体验
执行流程
用户输入任意小说原文后，你直接输出润色后的成品文本，不提问、不解释、不额外沟通，严格按照上述规则完成第一人称精简润色，保证开头钩子拉满、内容干净紧凑、适配漫剧短视频创作。
最终输出要求
只输出润色完成后的文本内容，无多余前缀、后缀、注释，干净整洁，可直接用于漫剧短视频制作。
````
## 13. 3D真人提示词
````text
1. 真人写实风格，极繁主义风格，古风，美男，，动态光影，俊美，冷峻，强对比度，暗黑风，氛围感，极致细节，冷白皮，面部特写，面部聚焦，面容精致，皮肤细腻，轮廓分明，丹凤眼，细致描绘，中景，半身像，正视图， 黑灰色及腰长发男子发丝根根分明，面容细腻渲染，发丝细腻渲染，近距离，皮肤细腻渲染。五官立体，男子面容俊美，身着黑色精致刺绣丝绸+珠光等材质服饰，黑金色金属头冠，极繁主义，超多配饰 背景黑夜花园
2. 俊美男子，妖冶，真实人物，古风美男，冷白皮，单凤眼，眼尾细长，眼中含情，长发披散，漂亮的眼睛看向正前方，发丝细腻刻画，白色古风薄纱罩衣，金粉闪亮，带彩宝石首饰，项链，流苏，腰带，阳光从侧面打在他身上。黑发，微微仰头，唯美，氛围感。姿势合理，慵懒邪魅，绝美构图，背景古色古香，金，白为主，近距离，人物特写，画风暗黑，极致超清，极致细节。
3. 帅哥，帅气男性高贵，疯批，阴湿，五官深邃立体，发丝柔和细腻有层次，冷白皮，皮肤细腻光滑，五官特写，正面， 面部特写细节，西装，领带，穿搭，高定，眼镜，明暗对比，光影投在人物身上，人物光影，故事感，背景透视感，空间感，立体感，最高画质，动感构图，大师级配色，大神级构图，场景感，氛围感强，32k超清晰，阴湿风，暗黑风，精致的画面，超高质量，大光圈，前景清晰背景模糊留白，精致妆容，最高画质，背景黑色，真人，温柔
4. CG建模，古风帅哥，面部聚焦，人物特写，写实风格，冷白皮肤，光滑细腻，绝世容貌，妖冶阴柔，凤眼，清冷感，灰色发丝凌乱抚面，头发无冠无束，披着头发，华丽精致的头饰，发丝间有细碎银饰垂落，穿银白色，白色衣服，领口袖口精致华丽，有银丝和华丽装饰 氛围感，高级感，朦胧梦幻，协调
5. 瓜子脸，亚洲面孔，少年。有着白皙细腻有光泽的肌肤渲染，3d动漫厚涂艺术人像特写，动态视角，温暖色调，光影艺术，唯美光影，半身像，魅力人像，创意，细腻光影，极简，高级感，梦核，朦胧感，模糊感，情感表达，独特视角，古风美男子，深色长发，浅色汉服，桃花林，光影交错，光影对比强烈，高质量极致细节，五官精致，光影斑驳，情绪氛围感，线条清晰，明暗对比，超高清，最高画质，清透，细腻渲染，丰富细节，眼神灵动精致厚涂，二次元拟真风格，超清画质，完美品质，弥散粒子，高级感，氛围感，梦幻光影，笔触感，精致刻画，流畅的线条，发丝细腻富有光泽，瓷白如玉的肌肤，笔触，清冷，高级CG，oc渲染，精致感，高质量，柔焦，大师级光影，8K
6. 古风（都市、末世） 美男 CG建模 冷白皮，俊美，动态光影，强对比度，暗黑风（温柔风），氛围感，极致细节，面部特写，面部聚焦，面容精致，皮肤细腻，轮廓分明，丹凤眼，细致描绘，全身像，正视图，腿长占身高60%，黑灰色及腰长发（发型）男子发丝根根分明，面容细腻渲染，发丝细腻渲染，近距离，皮肤细腻渲染。五官立体，男子面容俊美
7. 古风帅哥，笔触，线条清晰，明暗对比，超高清，垂坠感，高级感，面部特写，最高画质，灰色长发，精美抹额，发丝蓬松，邪魅，狭长的双眼，极致妖孽的容貌，极致清冷感，精美繁复华丽装饰，华丽装饰，精美配饰，绝美眼睛，阴森，细节五官。丰富细节，微距镜头，面部阴影，面部聚焦，丰富的细节，凌乱发丝拂面，高质量，写实逼真，细腻肌理，仰拍视角，看向镜头， 笔触，线条清晰，明暗对比，超高清，垂坠感，高级感，最高画质，灰色长发，精美抹额，发丝蓬松，邪魅，极致清冷感，精美繁复华丽装饰，华丽装饰，精美配饰，绝美眼睛，阴森，细节五官。丰富细节，微距镜头，面部阴影，面部聚焦，丰富的细节，凌乱发丝拂面，高质量，写实逼真，细腻肌理，仰拍视角，看向镜头，全身照
8. 精细三维渲染，bjd，青年成人，古风男子，白灰色长头发，随意披散长发，厚重刘海，华丽的魔皇长袍和纹理，背景是魔殿，正面, 大景深, 全身镜头, 色差艳丽。图片风格为CG 厚涂
9. 3D古风美男，长发飘逸，眼神冷酷，五官立体，棱角分明，长发飘动，抬眼凝视，冷笑，侧颜杀，花瓣翻飞，4K高清，古典，半身像
女性：1、新三维古风，特写，3D，正面，近景，一位中式美女，她的身影仿佛由无数光点凝聚而成，散发着柔和的光芒。她的长发随风飘扬，半透轻纱的裙摆，有着镂空的银丝图案她的存在，如同梦境，既真实又虚幻，让人心驰神往。生物发光，破碎感。背景为黑色
2. 3D仿真，特写，精致刻画，流畅的线条，梦幻感，绝色美女，倾国倾城，柔光，，梦幻光影，色彩弥漫，弥散光影，色彩弥散，极简风格，古风女子，华丽的发冠，黑发，下雪，4K，全身视角，半身视角
3. 三维古风，国风光影，移轴摄影，古风美女，暗夜微光，暗黑魔幻，流体艺术，超长飘发，蓬松闪亮的细密银色长发，精致艳丽的妆容，她身披黑白色披风连衣帽，额头小印花，黑色系主题，古风，HDR，3D渲染，虚拟引擎渲染，高清，8K
4. 远景镜头，全身都在画面里，板绘插画，cg建模，妖冶美丽，面容精致，五官立体 黑灰色及腰蓬松超长发松束半扎，自然垂落长长刘海凌乱拂面，发丝蓬松带清透光泽，几缕碎发被夜风掀起。 冷白皮肤细腻发光，面部轮廓柔和，凤眼，瞳仁深不见底，正望向镜头，睫毛在眼下投出浅淡阴影。眼神淡漠。清冷，孤寂，生人勿近，矜贵清冷，女生
5. 一个长发美女，小香风，全身照特写，眼看镜头，光线柔和 数字艺术风格 厚涂插画 3D渲染 新工笔大师杰作 32k 超高清画质
6. 三维古风。3d，服饰，美女，冷白皮，身材高挑 发钗，头饰，高质量，高分辨率，神秘，幻境，杰作，大师级构图，半身视角 全身像，完整四肢可见，从头顶到脚尖完整构图，背景留白，九头身，黄金比例身材，腿长占身高60%，专业打光，高清细节
````
## 14. 角色形象2D
````text
#角色形象提示词
1.1根据我发给你的这篇文章，帮我整理出所有角色形象，需要包含人物性别，穿着、脸部特征、年龄、身高以及人物性格等。
1.2根据提供的小说原文，推导出文中出现过的人物，人物可能有多种代称，要囊括文中提到的所有人物，包括我，每个人物包含名字、代称(多个代称用逗号分割)、形象描述三个字段。人物形象必须包含具体年龄，性别，发色，发型，眼睛颜色，脸部特征，上身服装，下身服装，身高，每个输出结果必须有不一样的着装需要更好分辨。
1.3不要表格并且全部为正面站立全身图片
1.4图片风格为2D动漫并在提示词中加入2D动漫风格这句话
1.5图片人物背景为纯白
````
## 15. 角色形象3D
````text
#角色形象提示词
1.1根据我发给你的这篇文章，帮我整理出所有角色形象，需要包含人物性别，穿着、脸部特征、年龄、身高以及人物性格等。
1.2根据提供的小说原文，推导出文中出现过的人物，人物可能有多种代称，要囊括文中提到的所有人物，包括我，每个人物包含名字、代称(多个代称用逗号分割)、形象描述三个字段。人物形象必须包含具体年龄，性别，发色，发型，眼睛颜色，脸部特征，上身服装，下身服装，身高，每个输出结果必须有不一样的着装需要更好分辨。
1.3不要表格并且全部为正面站立全身图片
1.4图片风格为2D动漫并在提示词中加入2D动漫风格这句话
1.5图片人物背景为纯白
````
## 16. 镜头提示词10秒
````text
根据旁白和对话拆分分镜头
分镜脚本提示词要求如下:
[内容镜头一致性原则】内容以35-50个字以内进行一次分镜头拆分，要求拆分出的单句文案内容要完整
示例:内容:"民国年间，李老根是山里的守林人，专管夜间巡山护林。这夜乌云压顶，连残月都被遮得严实，山风卷着枯叶鸣鸣作响。他挎着煤油灯，灯芯被风刮得突突乱跳，刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立着个半尺高的黄皮子。"拆分出两段文案:
民国年间，李老根是山里的守林人，专管夜间巡山护林。这夜乌云压顶，连残月都被遮得严实，山风卷着枯叶鸣鸣作响。
他挎着煤油灯，灯芯被风刮得突突乱跳，刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立着个半尺高的黄皮子。
或者三段文案:
民国年间，李老根是山里的守林人，专管夜间巡山护林。这夜乌云压顶，连残月都被
遮得严实山风卷着枯叶鸣鸣作响。他挎着煤油灯，灯芯被风刮得突突乱跳刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立着个半尺高的黄皮子。然后针对拆分后的文案分别进行提示词描写[核心目标与原则】图片提示词内不能带有乱七八糟的文字标识，不需要给出角色映射视频提示词中前后分镜必须要有关联性，需要思考上个画面;保证情节连贯:人物、场时间必须在相邻分镜中保持高度一致性景
【重要】视频提示词一定要有角色标签映射语句，一定要包含所有视频提示词中应该出现的角色，没有出现的角色不能写在角色标签映射中
【很重要】视频提示词要求:必须严格按照参考案例给出，每次给出都需要仔细思考和上个场景是否关联,前后分镜必须要有关联性，需要思考上个画面内容后给出
【十分重要】:文案中对话放入视频提示词词用”"做标注，必须严格按照当前视频提示词结构给出包含镜头，环境音/对话/细微肢体动作发声/合适的地方给出解说注:必须用白话文方式给出解说或者对话注意事项:(切记:不是当前角色台词不需要有张嘴、喉部动等疑似发声动作，嘴唇动作需要和台词同步，台词时段镜头固定，不切换、不推拉)[重要】不要重复生成上下分镜已经有的镜头，和上下分镜的故事情节要连贯
【3秒决策原则】执行前必检
人物是否齐全?一严格映射角色信息，未出现角色绝不写入场景是否连贯?一时间(晨/午/晚)/地点/光线必须与上一镜一致有无违禁内容?一自动过滤血腥/低俗/政治敏感词一任一条件不满足，立即中止并重新推理
【六维一致性准则】
人物一致:出现角色必须严格匹配角色信息库，未出现角色绝不写入时空一致:相邻分镜时间(晨/午/晚)、地点、光线必须无缝衔接物品一致:关键道具(如钢笔/背包)位置状态需延续上一镜动作连贯:新分镜起始动作必须承接上一镜结束状态
台词合规:仅当前说话角色有张嘴动作，台词用""标注敏感过滤:自动替换违禁词(替换规则:用中性词保持剧情逻辑)
[分镜生成四步法]STEP1场景锚定一提取章节文案时间/地点/人物三角要素STEP2连续性检查一比对上一镜结尾状态(动作/台词/物品位置)STEP3台词植入一仅当章节文案含对话时添加"台词"字段STEP4 敏感扫描一自动替换违禁词(替换规则:用中性词保持剧情逻辑)
镜头+音效+台词(严格按时间轴):
[0-3秒]镜头:[景别]+[镜头]+[核心动作];音效:[主音效]+[环境音];[台词/画外音]
[3-6秒]镜头:[景别]+[镜头]+[互动反应];音效:[关键音效];[台词/画外音]
[6-8秒]镜头:[景别]+[镜头]+[情绪特写];音效:[氛围音];[画外音/沉默说明]
[8-10秒]镜头:[景别]+[镜头]+[下一镜铺垫];音效:[过渡音]
[遵循要求】
1.*中文输出**:所有提示词必须使用中文描述，输出的提示词必须不能包含英文引号"，必须使用中文引号”
2.**标点格式**:输出的提示词必须不能包含英文引号”，必须使用中文引号”3.*视频提示词要求:严格参考输出示例，每个画面为10秒，由1-4秒每个镜头所组成，必须严格按照参考案例给出
4.**场景信息“*给出的场景信息对应后一字不改的放到我需要的位置5.*图片提示词*图片提示词内不需要映射人物，非常重要6.景别多使用近景，特写，大特写等，不使用远景，少使用中景7.拆分文案内容要合理
[结果要求]
数量严格控制:任务是为输入信息中的章节文案中的每一项生成一个对应的分镜。输出记录的总数必须与章节文案的条目数完全相等。禁止根据小说原文或推文文案的长短阜行拆分或合并分镜。
分镜解析:逐条解析章节文案，给出人物姓名，重点描写动作、表情，结合[角色信息】与整体情节，明确视角与景别。
提示词推理限制:如果出现违禁词需要自动替换意思相近的中性词，保证新的视频提示词不得出现任何违禁词，违禁词包括词典如下:血腥暴力类(重点屏蔽)血液相关:血液飞溅、喷血、鲜血淋漓、血池、血祭、断头血、内脏出血、血腥场面、血债、血洗(具象化描述)暴力场景:分尸、碎尸、斩首、砍头、挖眼、掏心、剥皮、凌迟、虐杀、酷刑、断肢、爆头、穿刺、撕咬(含肢体伤害的具体动作)其他暴力:屠杀、灭门、焚尸、鞭尸、尸横遍野、血肉模糊、骨裂、脑浆、内脏外露、残肢断臂
裸露低俗类(重点屏蔽)直接裸露:全裸、半裸、袒胸露背(过度)、露脐(低俗化)、露臂、露私密部位、一丝不挂、裸体、赤操低俗暗示:性感暴露、挑逗性裸露、低俗姿势、暴露隐私部位、酥胸半露(过度)、衣不蔽体(非副情必要的低俗化描述)违规场:景:色情暗示、艳情、低俗互动、性挑逗、裸露祭祀(无合理剧情支撑的裸露)色情与性暗示类(易与裸露关联)核心违禁:色情、淫秽、嫖娼、卖淫、性交易、一夜情、通奸、乱伦、恋童、兽交暗示类:约炮、撩骚、打炮、床上戏(低俗化)、胸器、美腿诱惑、性感撩拔、暧昧低俗、艳舞、脱衣舞敏感部位描述:乳房、阴部、阴茎、臀部(直白描述，非医学/正常剧情场景)
其他高危敏感词(修仙创作易踩坑)封建迷信(强化版):血腥祭祀、活人献祭、血咒、尸变、僵尸吸血、妖魔鬼怪(恐怖化描述，如"食人恶鬼")危害公序良俗:自残、自杀、暴力教峻、聚众斗殴、黑帮火拼、恐佈袭击、校园暴力(具象化场景)敏感宗教/政治:邪教仪式、极端宗教、分裂、恐怖组织、反动、颠覆(避免修仙设定与敏感元素绑定)
[输出自检机制】✅字段数校验:必须且只能有3字段
(panel_index/prompt/video_prompt)
✅引号校验:所有对话必须用中文引号”，禁用英文引号”
✅长度校验:video_prompts500字符
✅人物校验:video_prompt出现的角色必须100%映射角色信息
✅场景校验:prompt必须包含原始场景信息(一字不改)
✅连贯校验:video_prompt必须包含"衔接前置指令"段落
[高频错误避坑指南】x错误:林辰在会议室突然出现咖啡罐(上镜在格子间)
√正确:林辰揉眼蹭墨痕(延续上镜断笔沾墨状态)
×错误:写入禾出现的"王经理"角色映射
√正确:仅写入画面实际出现角色(如仅林辰/张岚则只映射这两人)
×错误:“林辰嘴角流血”(违禁描述)
√正确:“林辰紧咬下唇，衣领有红痕"(保持伤势暗示)
×错误:台词时镜头切换/推拉
√正确:台词时段固定镜头，标注"镜头稳定，不推拉”
[输出格式】
**输出示例: **
如果有针对同一段文案拆分后的子文案，则格式为:
分镜头1
原文案:"民国年间，李老根是山里的守林人，专管夜间巡山护林。这夜乌云压顶，连残月都被遮得严实，山风卷看枯叶鸣鸣作响。他挎着煤油灯，灯芯被风刮得突突乱跳，刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立着个半尺高的黄皮子。”
子文案:民国年间，李老根是山里的守林人，专管夜间巡山护林。这夜乌云压顶，连残月都被遮得严实
分镜头1-1:
[0-3秒]镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[3-4秒]镜头:特写女孩合十的双手;音效:树叶声
[4-8秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[8-10秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲:
子文案:山风卷看枯叶鸣鸣作响。他挎着煤油灯，灯芯被风刮得突突乱跳，
分镜头1-2:
[0-3秒】镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[3-4秒]镜头:特写女孩合十的双手;音效:树叶声[4-8秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[8-10秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲
子文案:刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立看个半尺高的黄皮子
分镜头1-3:
[0-3秒】镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[3-4秒]镜头:特写女孩合十的双手;音效:树叶声[4-8秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[8-10秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲
如果没有针对同一段文案进行拆分，则格式为
原文案;"民国年间，李老根是山里的守林人，专管夜间巡山护林”
分镜头1:
[0-3秒】镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[3-4秒]镜头:特写女孩合十的双手;音效:树叶声[4-8秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[8-10秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲
原文案:"民国年间，李老根是山里的守林人，专管夜间巡山护林”
分镜头2:
[0-3秒】镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[3-4秒]镜头:特写女孩合十的双手;音效:树叶声[4-8秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[8-10秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲
原文案:刚摸进山神庙后坡的窄道，就见道旁的枯树根上，立看个半尺高的黄皮子
分镜头3
[0-3秒】镜头:近景，侧面拍摄，女孩双膝跪地，上半身直立，双手慢慢举起合十，往前伸展，说:"黄天在上，厚土为证";音效:流水声。
[3-4秒]镜头:特写女孩合十的双手;音效:树叶声[4-8秒]镜头:俯拍特写女孩脸部，说:“我愿用我领导倒霉10年换我今年财源滚滚"，近景背面拍摄停留0.5秒，镜头转侧面拍摄停留0.5秒;音效:说话声
[8-10秒]镜头:特写女孩双眼，然后眼神猛地发狠，嘴里说:"如果十年不够，那就让他倒霉一辈子，保佑”，镜头转全景，背面拍摄，女孩对着群山直接往下扣头;音效:小桥流水声音
场景:日系动漫电影质感场景，黄昏日落时分的山间高地，地面由粗糙岩石与稀疏枯黄杂草组成，远处层叠山峦笼罩着朦胧薄雾，天空呈现橙黄一粉紫一淡紫的渐变色彩，太阳投射带有柔和光晕的光束，暖色调光影均匀覆盖场景，画面氛围梦幻治愈，细腻的色彩过渡与轻盈的光影渲
动漫风格
不要表格
````
## 17. 视频反推
````text
1.视频文案内容:逐句还原视频口播/字幕文案，标注语气节奏、语速停顿
2.核心主体(Subject):画面核心元素(人物/物体/场景)、人物动作、表情神态、穿搭造型、道具细节、人物动线
3.环境背景(Environment):发生空间(室内/室外)、场景陈设、光影层次、天气状态、空间氛围感
4.艺术风格(Art Style):画面呈现风格(如电影感、超写实摄影、胶片质感、赛博朋克等)、画质参数
(8K、HDR、60帧高帧率)
5.构图与镜头(Composition & Camera):镜头视角、景别、运镜方式(推/拉/摇/移/跟/固定)、转场逻辑、景深效果、画面比例
6.细节修饰(Details &Lighting):布光方式、材质质感、色彩氛围、画面锐度、噪点控制、画面稳定性
请生成适配15秒分镜的完整提示词，确保输入即梦后能1:1还原原视频，无需字幕，提示词为纯文字，不要表格，补充运镜、动作、转场等细节，保证还原度拉满。
````
## 18. 流程
````text
第一步：剧本生成
新手用AI原创，别用小说改编
工具：豆包或DeepSeek
指令：你是专业漫剧编剧，基于人设和故事大纲，生成第一集剧本
要求：单集30-60秒，开篇设强看点，结尾留悬念
操作：提供男女主名字和故事类型，发送指令
产出：画面描述、台词、背景音乐、音效、镜头时长
第二步：人物形象生成
目的：固定角色长相，保持一致性
指令：根据剧本整理角色形象，含性别、穿着、脸部特征、年龄、身高、性格
风格：写实电影感，正面站立全身照
操作：剧本粘贴进豆包，拖入指令，复制绘图提示词到即梦
即梦设置：图片生成，模型5.0或4.6，比例9:16
电图法让角色变美变帅：灵感搜索参考图，复制提示词生成，垫图后再生成自己的角色
三视图：正面、侧面、背面，指令“一张高精度干净极简的三视图参考页”，比例16:9横屏
第三步：场景固定
目的：防止背景乱跳，观众串戏
指令：场景提取指令
操作：剧本粘贴进豆包，拖入指令，复制场景提示词到即梦
即梦设置：图片生成，比例16:9
依次生成所有场景图，不满意点再次生成
第四步：视频画面生成
核心：分镜头提示词，电影质感，已规避违规词
操作：故事粘贴进豆包，拖入分镜指令，按顺序生成
即梦设置：视频生成，模型2.0，功能全能参考，比例16:9
参考图：出现男主角传男主图，出现女主角传女主图，出现场景传场景图
手动引用：选中提示词里的元素名，点引用参考，指定对应图片编号
过人脸限制
方法一：三视图法，直接用三视图当参考图
方法二：彩铅法，指令“帮我把这张图片变成彩铅风格的”
方法三：九宫格法，用美图秀秀在人脸叠加九宫格图片再上传
使用顺序：先三视图，过不去试彩铅，再过不去加网格
豆包替代方案
每天送免费额度，不排队，切换号可无限用
豆包只能生成10秒视频，需用10秒版分镜提示词
没有引用参考功能，在提示词里手动标注“图一”“图二”
和即梦同一底层模型，质量相同
第五步：配音
工具：TTS，完全免费，电脑手机通用
旁白提取指令：把文案提炼成第一人称旁白，删除所有角色对话和台词
操作：拖入参考音频，粘贴旁白文案，点生成
情绪调节：点“使用情感描述文本控制”，输入情绪词
电脑需8G以上显存，低配用手机GPU免费版网页
人物台词不需要配音，即梦直接对口型
第六步：剪映合成
导入视频画面和旁白音频
音画同步，分割对齐
右键识别字幕
加背景音乐，音量调低
加转场，少加特效
````
docs/work-sync/00_文档索引.md
+99
View File
@@ -0,0 +1,99 @@
# Work 同步文档索引
> 批次：`WORK_SYNC_2026-07-19_V11`
> 状态：待上传
> 入口：先阅读本文件，再阅读项目状态快照。
## 1. 当前有效文档
| 顺序 | 文档 | 版本 | 类型 | 当前状态 | 主要回答 |
| ---: | --- | --- | --- | --- | --- |
| 1 | `01_项目现状/PROJECT_STATUS_V1.md` | V1 | 不可变快照 | 当前基线 | 代码、数据、测试和运行现实是什么 |
| 2 | `S_PLUS_BATCH_AUTOMATED_PRODUCTION_PIPELINE_V2.md` | V2 | 目标流程规范 | 当前目标/待分阶段实现 | 面向批量自动化和 S+ 质量，唯一生产流程应该是什么 |
| 3 | `S_PLUS_PRODUCTION_FLOW_AUDIT_V1.md` | V1 | 现状流程审计 | 当前有效 | 当前实现为何不能直接承担无人值守批量生产 |
| 4 | `02_架构设计/SYSTEM_ARCHITECTURE_V1.md` | V1 | 当前设计 | 有效 | 系统边界、模块和部署如何组织 |
| 5 | `05_AI流水线/AI_PIPELINE_V1.md` | V1 | 当前设计 | 有效 | Provider、Prompt、队列、回退和成本如何工作 |
| 6 | `06_数据库/DATABASE_CURRENT_V1.md` | V1 | 当前设计 | 有效 | 数据模型如何分组、怎样迁移和备份 |
| 7 | `03_小说引擎/NOVEL_ENGINE_V1.md` | V1 | 当前设计 | 有效 | 小说生成、记忆、质量和版本如何工作 |
| 8 | `04_短剧引擎/DRAMA_ENGINE_V1.md` | V1 | 当前设计 | 有效 | 剧本、分镜、视频、声音和合成如何工作 |
| 9 | `04_短剧引擎/AI_VIDEO_TEST_LESSONS_V1.md` | V1 | 生产经验 | 有效 | 已验证的视频生产经验和反例有哪些 |
| 10 | `07_版本记录/CHANGELOG.md` | 持续 | 追加记录 | 有效 | 每个同步批次改变了什么 |
| 11 | `08_维护规范/WORK_SYNC_PROTOCOL.md` | V1 | 维护规范 | 有效 | Work 与代码怎样保持同步 |
| 12 | `08_维护规范/DOCUMENT_TEMPLATE.md` | V1 | 模板 | 有效 | 新文档应如何写 |
| 13 | `99_历史设计/README.md` | V1 | 历史索引 | 有效 | 旧系统 A/B 文档何时可使用 |
| 14 | `SYNC_MANIFEST.md` | V11 | 校验清单 | 有效 | 本批次文件、来源和校验和是什么 |
| 15 | `S_PLUS_SHORT_DRAMA_CODEX_OPTIMIZATION_V1_1.md` | V1.1 | 目标架构 | 当前有效 | S+ 内核的合同、质量门和实施路线是什么 |
| 16 | `PROMPT_RULE_AUDIT_V1.md` | V1 | 规则审计 | 当前有效 | 历史 Prompt 中哪些规则保留、待验证或废弃 |
| 17 | `SPLUS_PHASE_0_1_IMPLEMENTATION_REPORT.md` | V1 | 实施报告 | 已完成 | 保护、去污染、合同和硬门完成了什么 |
| 18 | `SPLUS_PHASE_2_IMPLEMENTATION_REPORT.md` | V1 | 实施报告 | 工程完成/内容待验收 | 三阶段结构化写路径如何实现和部署 |
| 19 | `KLING_S_PLUS_MODEL_ROUTING_SPEC_V1.0.md` | V1.0 | 模型路由规范 | 当前有效 | Kling S+ 的能力、路由、参数和质量规则是什么 |
| 20 | `SPLUS_GENERATION_PLAN_IMPLEMENTATION_REPORT_V1.md` | V1 | 实施报告 | 工程完成/真实小样待验收 | 不可变计划怎样成为关键帧到成本审计的执行事实源 |
| 21 | `SPLUS_MODEL_REGISTRY_AND_PLAN_DIFF_IMPLEMENTATION_REPORT_V1.md` | V1 | 实施报告 | 工程完成/真实小样待验收 | 能力、参数、价格如何版本化并与计划修订对比联动 |
| 22 | `KLING_V3_OMNI_API_UPDATE_V1.md` | V1 | 官方能力快照 | 当前有效 | Kling V3 Omni 当前接口、限制和价格基线是什么 |
| 23 | `LANDSCAPE_CHARACTER_ELEMENT_IMPLEMENTATION_REPORT_V1.md` | V1 | 实施报告 | 工程完成/真实元素待验收 | 16:9统一画幅和 Kling 视频角色元素怎样落地 |
| 24 | `SPLUS_CHARACTER_TURNAROUND_ITERATION_REPORT_V1.md` | V1 | 实施与真实验收报告 | 工程保护链完成/单画布路线未达 S+ | 三视图实测、成本、硬门和分面板决策是什么 |
| 25 | `SPLUS_CHARACTER_TURNAROUND_PROMPT_V4_AUDIT.md` | V4 | Prompt 与资产输入审计 | 当前有效 | 网页版分析哪些成立、旧 Prompt/经验如何被阻断、四个角色是否可进入生成 |
| 26 | `AI_REQUEST_INSPECTOR_IMPLEMENTATION_REPORT_V1.md` | V1 | 实施报告 | 双端已上线/Provider Trace 待增强 | AI 请求参数、执行证据和隐私边界如何在页面展示 |
| 27 | `SPLUS_CHARACTER_TURNAROUND_SPLIT_PANEL_IMPLEMENTATION_REPORT_V1.md` | V1 | 实施与真实验收报告 | 工程完成/首轮母版 A+ 88 | 分面板生成、断点续跑、单面板返修、母版合成、真实成本和首轮缺陷是什么 |
| 28 | `SPLUS_EXECUTION_BRIDGE_EXTERNAL_ASSET_WORKFLOW_V1.md` | V1 | 实施报告 | 已完成/等待外部资产 | 确认资产计划如何在不伪造素材 ID 的前提下落地为导演分镜草案 |
### 1.1 不默认上传的本地追溯输入
- `S_PLUS_SHORT_DRAMA_CODEX_OPTIMIZATION_V1.md`：已由 V1.1 取代，只用于追溯初稿。
- `豆包讨论.txt`：原始讨论输入，结论已审阅并吸收到当前规范，不作为代码事实上传。
## 2. 文档职责边界
### 项目状态
只记录某个时间点可验证的事实，包括源码结构、服务状态、测试、数据量和风险。V1 发布后不原地修改事实；下一次审计新建 `PROJECT_STATUS_V2.md`。
### 架构与领域文档
记录当前稳定边界、核心流程、约束和差距。结构性变化时升级文件版本，小的措辞修正可在 CHANGELOG 中说明。
### 功能设计
尚未实现的功能不要直接写进当前设计文档并标成已完成。应单独创建：
```text
FEATURE_<功能名>_V1.md
```
经过 Work 讨论确认后交给 Codex 实现；上线验证后再合并进当前设计文档。
### 架构决策
影响多个领域且存在替代方案的决策，建议使用：
```text
ADR_<编号>_<主题>.md
```
至少记录背景、决策、替代方案、影响和回滚条件。
## 3. 状态标记
| 标记 | 含义 |
| --- | --- |
| 当前有效 | 与当前代码现实一致，可作为讨论基线 |
| 待实现 | 已完成设计，代码尚未完成 |
| 部分实现 | 有入口或数据结构，但链路不完整 |
| 待验证 | 代码存在，但测试/E2E/生产验证不足 |
| 已废弃 | 不再作为当前方案，只供追溯 |
| 历史参考 | 解释旧设计，不能推断当前实现 |
## 4. Work 使用提示
在 Work 中讨论新功能时，先引用最新 `PROJECT_STATUS` 和对应领域文档；不要只引用旧聊天或历史设计。若 Work 的回答与状态快照冲突，应标记为假设并要求代码审计，不直接让 Codex照旧方案开发。
## 5. 下一批计划
下一次同步优先包含：
- V2 流程 P0 安全门实现：候选默认不选中、拒绝清活动指针、合并只接收 `merge_ready`。
- 关键帧批准状态和 Execution Plan 冻结时机修正。
- 新建 `splus_v2` 项目的十步生产台首版。
- 短篇/长篇/现成剧本三条路线和制作拆解合同。
- 项目 #22 仅作为回归样本，不继续承担新流程验收。
- `PROJECT_STATUS_V2.md`、测试结果、Git/备份基线和受控部署记录。
docs/work-sync/01_项目现状/PROJECT_STATUS_V1.md
+879
View File
@@ -0,0 +1,879 @@
# AI 内容生产平台项目现状 V1
> 文档类型：项目状态回灌 / 技术审计快照
> 审计时间：2026-07-15（Europe/Berlin）
> 审计对象：`/www/wwwroot/ai` 当前工作区、当前 MySQL 数据库、当前 systemd 运行服务
> 文档用途：作为 Work 的“代码现实”基线，不替代产品设计文档，也不替代 Git 版本记录。
## 0. 审计口径
本文件按以下优先级判断项目真实状态：
1. 当前工作区源码与配置结构。
2. Prisma schema、迁移记录和数据库只读统计。
3. 当前 systemd、Nginx、MySQL、Redis 运行状态。
4. 构建与自动测试结果。
5. `README.md`、`CURRENT_ARCHITECTURE.md`、`CODEX_PROGRESS.md` 与 `docs/system_a`、`docs/system_b` 等历史文档。
状态标记：
| 标记 | 含义 |
| --- | --- |
| 已实现且验证 | 代码存在，当前可构建，并有运行数据、测试或实际调用记录佐证 |
| 已实现但验证不足 | 主体代码已存在，但自动测试、运行配置或完整 E2E 尚未达到发布基线 |
| 部分接入 | 只有部分入口、部分 Provider 或部分流程可用 |
| 仅设计/预留 | 有文档、数据结构或界面占位，但未形成完整可用链路 |
注意：本文中的 V1 是“状态文档版本”，不是 npm 包版本。当前各 workspace 的代码版本仍为 `0.1.0`，不应仅凭功能变多就直接对外宣布产品 V5.0。
## 1. 执行摘要
### 1.1 当前项目真实定位
当前系统已经不再只是“AI 小说系统”或“AI 漫剧系统”，实际代码覆盖：
- 小说导入、阅读、原创生成、章节质量循环与版本管理。
- 故事圣经、世界观、角色、剧情记忆与 IP 资产管理。
- 分集、剧本、分镜、关键帧、图生视频和候选片段选择。
- 真人/仿真人短剧生产、原生音频视频、字幕、BGM、SFX、转场与 FFmpeg 合成。
- AI Provider 目录、模型偏好、成本记录、路由、实验台与回退。
- 队列、任务重试、人工介入、额度、审核、运营后台和审计日志。
- 面向生产的独立创作工具，当前已开放“人物三视图”。
因此，面向 Work 的项目名称建议使用：
```text
AI 内容生产平台
```
### 1.2 当前健康度
| 检查项 | 当前结论 |
| --- | --- |
| 后端 API | `ai-backend.service` 正在运行，健康检查返回 `ok` |
| 队列 Worker | `ai-workers.service` 正在运行，消费 14 个 BullMQ 队列 |
| 数据库 | MySQL 正在运行，33 个 Prisma 迁移全部已部署 |
| Redis | 正在运行，Worker 与 API 均配置为使用 Redis |
| 前台/后台 | Vue 3 + Vite 生产构建通过，Nginx 直接托管静态产物 |
| 全仓构建 | 通过：backend、admin、user-app、workers 均成功构建 |
| 自动测试 | 未通过：后端 273 条测试中 238 通过、35 失败；Worker 1 条通过；前台和后台无测试文件 |
| Git 基线 | 高风险：`main` 仅 1 个提交，当前有 85 个修改项、47 个未跟踪项 |
| 运行版本一致性 | 需处理：审计构建产物晚于 backend/worker 进程启动时间，当前进程尚未加载最新构建 |
| 存储 | 当前为本机私有存储；MinIO 代码已实现但当前未完整配置 |
| AI 默认模式 | 全局 `AI_PROVIDER_MODE=mock`，但数据库中有大量真实 Provider 可被显式选择 |
### 1.3 结论
当前项目已经是一个有真实数据、真实调用和真实视频资产的内部生产平台，不是原型空壳；但它还不是可安全标记为“稳定生产版”的发布基线。
当前最重要的工作顺序应为：
1. 固化 Git 与数据库备份基线。
2. 修复测试和状态枚举漂移。
3. 对齐当前构建与运行进程。
4. 补齐队列任务执行覆盖。
5. 再继续扩展新功能。
## 2. 当前项目实际架构
### 2.1 仓库形态
项目为 npm workspaces 单仓库：
```text
ai/
├── backend/ NestJS API、Prisma、业务编排、Provider、FFmpeg 调用
├── workers/ BullMQ Worker，消费队列后委托 backend 执行业务
├── user-app/ Vue 3 + Vite 用户端 H5
├── admin/ Vue 3 + Vite 运营管理后台
├── deploy/ 开发依赖与 Nginx 示例，生产脚本尚不完整
├── docs/ 原系统 A/B、AI 生产经验、教程和成本资料
├── data/ 项目内容、剧本、分镜与生成过程资料
├── storage/ 当前本地私有素材存储
└── tmp/ 临时处理文件
```
### 2.2 运行拓扑
```mermaid
flowchart TB
User[用户端 Vue H5] --> Nginx[Nginx]
Admin[管理端 Vue H5] --> Nginx
Nginx --> API[NestJS API :3010]
API --> MySQL[(MySQL ai_manga)]
API --> Redis[(Redis)]
API --> Storage[本地私有存储\nMinIO 可选]
API --> Providers[AI Providers]
API --> FFmpeg[FFmpeg / FFprobe]
API --> BullMQ[BullMQ 14 队列]
BullMQ --> Worker[独立 Worker\n并发 2]
Worker --> InternalAPI[受 WORKER_SECRET 保护的内部接口]
InternalAPI --> API
```
### 2.3 后端基础设施
- 框架：NestJS 10。
- ORM：Prisma 6，MySQL。
- 队列：BullMQ 5 + Redis。
- 文件：本地私有文件为当前主存储，MinIO 为可选实现。
- 媒体：FFmpeg、FFprobe。
- 文件解析：PDF、DOCX、纯文本。
- 鉴权：JWT。
- 后台权限：`admin`、`operator`、`finance`、`auditor` 角色与细粒度 permission。
- API 前缀：`/api`。
- 请求体上限：当前 160 MB。
- 中间件：请求 ID、安全响应头、HTTPS/代理判断、应用层加密请求处理。
- API 返回：统一 envelope 和统一异常过滤。
### 2.4 当前部署事实
- 后端由 `ai-backend.service` 托管。
- Worker 由 `ai-workers.service` 托管。
- Nginx 分别托管用户端与管理端，并反向代理 `/api/`。
- MySQL、Redis 为本机服务。
- 当前 `NODE_ENV=production`、`STORAGE_DRIVER=local`、Worker 并发为 2。
- 后端没有强制 `HTTPS_REQUIRED`；传输安全依赖 Nginx 与部署配置。
- `PUBLIC_ASSET_BASE_URL` 类配置当前未设置，依赖外部 Provider 获取临时素材 URL 的链路需要专项复核。
## 3. 已实现模块
### 3.1 后端模块
当前 `AppModule` 注册的业务模块：
| 模块 | 主要职责 | 状态 |
| --- | --- | --- |
| `AuthModule` | 注册、登录、JWT、账号状态 | 已实现且验证 |
| `UsersModule` | 用户资料 | 已实现 |
| `BillingModule` | 额度、订单、冻结、释放、后台人工调整 | 已实现但支付仅为 mock |
| `ProjectsModule` | 项目、作品库、小说库、创意模式、流水线配置 | 已实现 |
| `ProviderLabModule` | Provider 参数试跑与状态轮询 | 已实现 |
| `AssetsModule` | 上传、下载、预览、Range 流、别名、选择状态 | 已实现且有大量真实素材 |
| `NovelsModule` | 导入、解析、阅读、原创小说、Agent 与章节质量流程 | 已实现但测试不足 |
| `StoryBiblesModule` | 故事圣经、制作规则、确认锁定 | 已实现 |
| `CharactersModule` | 项目角色、全局角色、版本、状态、Prompt 审核与优化经验 | 已实现但复杂度较高 |
| `MemoriesModule` | 剧情、角色、伏笔与连续性记忆 | 已实现但测试桩未同步 |
| `EpisodesModule` | 分集计划、请求预览、质量闸门 | 已实现但质量测试有漂移 |
| `ScriptsModule` | 单集剧本、分镜、动态时长、提示词、转场 | 已实现但测试不足 |
| `ImagesModule` | 角色图、锚点图、三视图、关键帧、视觉质检 | 已实现 |
| `LiveActionModule` | 真人短剧准备、关键帧、视频、QC、合并、后期 | 已实现但仍处于生产化磨合 |
| `MediaModule` | TTS、字幕、传统漫剧合成、音频片段重试 | 已实现 |
| `ProvidersModule` | Provider 目录、配置、调用、日志、成本、异步视频轮询 | 已实现且有真实调用 |
| `QueuesModule` | RenderTask、BullMQ、重试、取消、恢复、Worker 委托 | 已实现但执行覆盖不完整 |
| `ReviewsModule` | 文本/素材审核、返修、案例授权 | 已实现但当前数据库尚无审核记录 |
| `AdminModule` | 运营后台聚合 API、审计、配置、Router 审计 | 已实现 |
`AiRouterModule` 没有作为顶层模块单独注册，但被 `LiveActionModule` 导入并实际用于真人视频路由。当前它不是覆盖全平台所有 AI 请求的统一 Router。
### 3.2 用户端模块
用户端实际为 Vue 3 单页应用，不是旧文档描述的 uni-app 多路由实现。
顶级导航：
- 创作：新建、提示词直出、API 快测。
- 工具：独立创作工具。
- 项目：项目列表、制作台、IP 资产中心、进度。
- 作品：视频、小说、素材。
- 任务：运行任务、审核、额度与成本。
- 我的：账号、角色资产、教程。
制作台主流程：
```text
来源 -> 版权 -> 故事圣经 -> 角色 -> 记忆 -> 分集
-> 剧本/分镜 -> 真人视频 -> 合成 -> 审核
```
独立创作工具当前状态：
| 工具 | 状态 |
| --- | --- |
| 人物三视图 | 已开放；支持主锚点参考或输入本次唯一角色描述；生成后可下载和视觉质检 |
| 影视场景专家 | 待接入 |
| 9 宫格分镜 | 待接入 |
| 16 宫格分镜 | 待接入 |
| 25 宫格分镜 | 待接入 |
| 原创剧本 | 待接入 |
虽然 `user-app/src/pages/` 中保留了多页面文件，但当前 `App.vue` 实际只加载大型 `pages/index/index.vue`，没有 Vue Router。多数业务都集中在一个约 1.35 万行的页面组件中。
### 3.3 管理端模块
管理端实际为自研 Vue 3 单页后台，不是完整 GeekerAdmin 集成。
当前菜单包括：
- 仪表盘、使用教程。
- 项目、小说、全局角色、项目角色、分镜、成品。
- 订单额度、内容审核、任务。
- Router 审计、爆款诊断、AI 平台入口。
- Provider、成本、用户、素材。
- 系统配置、版权、审计日志。
后台同样集中在一个约 1.03 万行的 `App.vue` 中，没有实际 Router、Store 和拆分后的 Views。
## 4. 已完成功能与完成度
| 业务域 | 当前能力 | 完成度判断 |
| --- | --- | --- |
| 账号与安全 | 注册、登录、JWT、账号禁用、密码重置、RBAC、操作审计、应用层加密 | 已实现且验证 |
| 项目 | 新建、列表、删除、取消、进度、作品库、提示词直出分镜 | 已实现 |
| 小说导入 | 粘贴、文件上传、章节切割、编辑、版权确认 | 已实现 |
| 小说阅读 | 目录、分页/翻页、阅读进度、书签、批注 | 已实现 |
| 原创小说 | 创作向导、生成计划、章节 Agent、上下文、质检、修复、版本、批次 | 已实现但自动测试未稳定 |
| 故事与世界观 | StoryBible、WorldBible、制作文本和锁定 | 已实现 |
| 角色资产 | 项目角色、全局演员、外观版本、状态、服装、声音、授权范围 | 已实现 |
| 角色提示词闭环 | Prompt 版本、审核、优化经验、下一次生成吸收 | 已实现 |
| 人物三视图 | 主锚点模式、纯描述覆盖模式、旗舰模板、下载、视觉评分 | 已实现 |
| IP 资产中心 | 场景/道具提取、主资产、版本、Prompt、冲突检查 | 已实现但 UI/测试仍在磨合 |
| 长篇记忆 | 剧情记忆、角色记忆、伏笔线程、连续性检查 | 已实现但测试未同步 |
| 分集 | 动态数量、质量闸门、请求预览与 Prompt 覆盖 | 已实现但当前一条质量测试失败 |
| 剧本 | 剧本生成、人工编辑、确认、请求预览 | 已实现 |
| 分镜 | 动态时长、关键帧/视频 Prompt、前后镜衔接、转场字段、视觉板 | 已实现 |
| 关键帧 | 角色/场景/道具参考、单镜/批量、视觉审核 | 已实现且有真实图片调用 |
| 视频 | 单镜/批量、多候选、首帧/首尾帧/参考图、原生音频 Provider | 已实现且有真实视频调用 |
| 视频 QC | 自动评分、同模型重试、Fallback、人工确认、候选选择 | 已实现但测试和策略仍在变化 |
| 视频合并 | 硬切/转场、画面归一、源音轨、字幕、BGM、SFX、FFmpeg | 已实现但产品质量仍需持续验收 |
| 原创音乐 | 音乐圣经、MusicProvider、BGM 对齐、资产包 | 部分接入，默认关闭 |
| 口型 | LipSync Provider 抽象、策略与桥接 | 部分接入；当前真实 LipSync Provider 全部禁用 |
| 素材库 | 类型、别名、分镜号/范围、选中/候选/淘汰、Range 播放、下载 | 已实现 |
| 队列 | 14 队列、任务幂等、重试、取消、过期恢复、人工介入 | 已实现但部分任务类型无 Worker 执行器 |
| 成本 | Provider 成本规则、调用日志、人民币展示、额度冻结/释放 | 已实现；财务口径仍需统一 |
| 支付 | 套餐、订单模型与 mock-pay | 仅测试，不是生产支付 |
| 内容审核 | 文本、素材、后台复核、案例授权 | API/UI 已实现，但当前 `ContentReview` 为 0 条 |
| 爆款诊断 | 样本、片段、创意模式、项目绑定 | 已实现，属于原设计后的扩展 |
## 5. 数据库结构
### 5.1 总体规模
- Prisma Model：61 个。
- Prisma Enum：0 个。
- 数据库迁移：33 个，当前全部已部署。
- 索引、唯一约束和 JSON 字段大量使用。
- 业务状态主要使用字符串字段，而不是数据库枚举。
### 5.2 模型分组
#### 用户与项目
- `User`
- `UserModelPreference`
- `Project`
- `ProjectPipelineConfig`
- `ProjectCreativePattern`
- `CreativePattern`
#### 小说与 Agent
- `NovelSource`
- `NovelChapter`
- `NovelReadingProgress`
- `NovelBookmark`
- `NovelAnnotation`
- `NovelGenerationPlan`
- `NovelChapterVersion`
- `NovelContextMemory`
- `NovelQualityReport`
- `NovelVersionSnapshot`
- `NovelDerivativeJob`
- `AgentPrompt`
- `AgentRun`
#### 故事、版权与世界观
- `CopyrightRecord`
- `StoryBible`
- `WorldBible`
#### 角色与 IP 资产
- `Character`
- `StoryCharacter`
- `CharacterExtractionVersion`
- `GlobalCharacter`
- `GlobalCharacterAsset`
- `GlobalCharacterLookVersion`
- `CharacterImage`
- `CharacterImageQualityReview`
- `CharacterMemory`
- `CharacterDesignVersion`
- `CharacterPromptVersion`
- `CharacterPromptReview`
- `CharacterPromptOptimizationLesson`
- `CharacterState`
- `ActorProfile`
- `ProjectVisualAsset`
#### 剧集生产
- `Episode`
- `EpisodeScript`
- `StoryboardShot`
- `ShotImage`
- `VideoClip`
- `PlotMemory`
- `PlotThread`
- `ContinuityCheck`
#### 素材、任务与 Provider
- `Asset`
- `RenderTask`
- `ProviderConfig`
- `ProviderLog`
#### 计费、审核与运营
- `Order`
- `QuotaAccount`
- `QuotaLog`
- `RevisionRequest`
- `ContentReview`
- `CaseShowcase`
- `HitAnalysisCase`
- `HitAnalysisSegment`
- `AnalyticsEvent`
- `SystemConfig`
- `OperationLog`
### 5.3 当前数据库数据快照
| 数据 | 数量 |
| --- | ---: |
| 用户 | 2 |
| 项目 | 20 |
| 小说源 | 10 |
| 小说章节 | 256 |
| 故事圣经 | 13 |
| 项目角色 | 87 |
| 全局角色 | 14 |
| 分集 | 87 |
| 单集剧本 | 21 |
| 分镜 | 114 |
| 素材 | 977 |
| 任务 | 748 |
| Provider 配置 | 112 |
| Provider 调用日志 | 1002 |
| 内容审核记录 | 0 |
| 操作审计记录 | 44 |
素材构成：
| 类型 | 数量 |
| --- | ---: |
| image | 600 |
| video_clip | 215 |
| video | 74 |
| audio | 50 |
| subtitle | 33 |
| 其他角色图、片段音频、成品类型 | 5 |
任务状态：
| 状态 | 数量 |
| --- | ---: |
| success | 646 |
| failed | 77 |
| manual_required | 22 |
| pending | 2 |
| completed | 1 |
`completed` 不在当前 `TASK_STATUSES` 常量中，属于历史状态漂移，需要迁移或兼容处理。
## 6. API 接口现状
### 6.1 总量
- Controller：25 个。
- HTTP 方法装饰器：289 个。
- API 全局前缀：`/api`。
- 当前没有生成 OpenAPI/Swagger 规范，接口事实依赖 Controller、DTO 与前端 client。
### 6.2 分组
| 接口域 | 代表能力 | 路由规模 |
| --- | --- | ---: |
| Admin | 仪表盘、项目、用户、素材、作品、Provider、成本、审计、Router | 47 |
| Characters | 项目角色、全局角色、版本、状态、IP 资产、Prompt、声音 | 47 |
| Projects | 项目、库、阅读入口、创意模式、流水线配置 | 28 |
| Live Action | 角色档案、关键帧、视频、QC、候选、渲染、音乐 | 21 |
| Novel Generation | 生成计划、IP 圣经、章节、批次、暂停恢复 | 17 |
| Providers | 目录、配置、执行、日志、成本、偏好 | 16 |
| Billing | 套餐、订单、额度、冻结/释放、后台调整 | 13 |
| Scripts | 剧本、分镜、请求预览、确认、重生 | 12 |
| Memories | 剧情、角色、伏笔、上下文、连续性 | 11 |
| Images | 角色图、关键帧、锚点、视觉质检 | 9 |
| Queues | 创建、列表、重试、取消、恢复、统计 | 9 |
| Reviews | 文本/素材审核、案例授权、后台复核 | 9 |
| Novels / Wizard / Original | 导入、解析、原创、创作向导 | 16 |
| Assets | 上传、预览、Range 下载、临时 URL | 7 |
| Auth / Crypto | 登录注册、用户信息、加密会话 | 7 |
| Episodes / StoryBible / Media | 分集、故事圣经、音频字幕视频 | 14 |
### 6.3 安全边界
- 业务接口主要使用 JWT Guard。
- 管理能力在 Service 层执行 permission 检查。
- Worker 内部接口使用 `WORKER_SECRET` 和 timing-safe 比较。
- 生产环境缺失 Worker secret 时不会使用本地默认值。
- 素材为私有存储，支持鉴权下载、Range 请求和带签名的临时 URL。
- API Key 经服务端密钥加密存储，后台不回显明文。
## 7. 前后端目录结构
### 7.1 后端
```text
backend/src/
├── admin/
├── ai-router/
├── assets/
├── auth/
├── billing/
├── characters/
├── common/
├── config/
├── episodes/
├── images/
├── live-action/
├── media/
├── memories/
├── novels/
├── prisma/
├── projects/
├── provider-lab/
├── providers/
├── queues/
├── reviews/
├── scripts/
├── story-bibles/
└── users/
```
当前后端约 9.39 万行 TypeScript。最大文件：
- `live-action.service.ts`：约 1.42 万行。
- `characters.service.ts`：约 7443 行。
- `providers.service.ts`：约 6776 行。
- `admin.service.ts`：约 6096 行。
- `scripts.service.ts`：约 4600 行。
### 7.2 用户端
```text
user-app/src/
├── api/
├── components/tools/CreativeTools.vue
├── pages/index/index.vue
├── pages/auth/
├── pages/help/
├── pages/projects/
├── pages/user/
├── App.vue
├── workflow.ts
└── styles.css
```
当前约 2.37 万行，主要功能集中在 `index.vue`、`api/client.ts` 和全局 CSS。
### 7.3 管理端
```text
admin/src/
├── api/client.ts
├── api/crypto.ts
├── App.vue
├── main.ts
└── styles.css
```
`router/`、`stores/`、`views/` 当前只有占位文件。管理端约 1.34 万行。
### 7.4 Worker
```text
workers/src/main.ts
```
每个队列由 BullMQ Worker 消费，任务本体通过内部 HTTP 接口委托后端执行，Worker 本身不重复实现业务逻辑。
## 8. 当前 AI 调用流程
### 8.1 通用 Provider 流程
```mermaid
flowchart LR
Input[业务输入] --> Preference[用户/项目模型偏好]
Preference --> Config[ProviderConfig]
Config --> Limit[启停、优先级、成本上限]
Limit --> Execute[ProvidersService]
Execute --> Sync[同步文本/图片/音频]
Execute --> Async[异步视频提交与轮询]
Sync --> Log[ProviderLog]
Async --> Log
Log --> Asset[Asset / VideoClip]
Log --> Task[RenderTask 状态与成本]
Execute --> Fallback[失败回退或人工介入]
```
### 8.2 Provider 现状
- Provider 配置共 112 个。
- Mock 配置 11 个，其中 10 个启用、1 个 LipSync mock 关闭。
- Real 配置 101 个，其中 64 个启用、37 个关闭。
- 当前已启用的真实 Provider 覆盖 Text、Novel、Image、Video、Voice、Music、Embedding、Moderation。
- 真实 LipSync Provider 当前全部关闭。
- 代表性已启用模型族：OpenAI、豆包/火山、DeepSeek、Qwen、Kimi、智谱、MiniMax、Kling、Seedance、Seedream、Sora 等。
- 全局默认仍为 mock，显式选择真实 Provider 时可产生真实调用。
Provider 日志当前共 1002 条：
| 状态 | 数量 |
| --- | ---: |
| success | 825 |
| failed | 170 |
| running | 5 |
| cancelled | 2 |
数据库 `cost_actual` 原始累计值为 354.9416。由于 Provider 成本币种和历史规则可能不同，该值只能用于技术对账，不能直接视为财务账单。
近期真实使用主要集中在：
- `openai-image`。
- `kling-v3-native-audio-720p-video`。
- `openai-responses-text`。
- `volcengine_seedance_20_mini`。
- `volcengine-seedream-50-image`。
- `openai-tts`。
### 8.3 真人短剧流程
```text
剧本/外部提示词
-> 动态分镜与前后镜关系
-> 角色/场景/道具资产计划
-> Prompt Engine
-> 关键帧
-> 视频 Provider 预检与成本估算
-> 单镜或批量视频、多候选
-> 自动 QC / 重试 / Fallback / 人工选择
-> Scene Composer 计划
-> 字幕 / 源音轨 / TTS / BGM / SFX / 转场
-> FFmpeg 合成
-> 成品与素材库
```
当前支持的后期参数包括：源音轨、额外音频、字幕、BGM、SFX、环境音、无源音轨回退 SFX、口型、字幕模式和音量控制。原创音乐与 Scene Composer 由项目配置控制，默认并非全部开启。
### 8.4 小说流程
```text
创作 Brief / 导入小说
-> 生成计划
-> IP/故事/世界观规则
-> Agent Prompt
-> 章节草稿
-> 质量报告
-> 自动修复或重写
-> 章节版本与上下文记忆
-> 小说快照
-> 听书/短剧派生任务
```
小说新引擎代码已形成，但目前自动测试和管理体验还没有达到可无人值守批量生产的程度。
## 9. 队列任务流程
### 9.1 队列与任务
BullMQ 队列共 14 个：
```text
novel_queue
parse_queue
story_queue
character_queue
episode_queue
script_queue
storyboard_queue
image_queue
audio_queue
subtitle_queue
video_queue
qc_queue
review_queue
analytics_queue
```
任务类型共 21 个，状态包括：
```text
pending / running / success / failed / retrying
cancelled / manual_required / skipped
```
### 9.2 执行链
```mermaid
flowchart LR
API[API 创建 RenderTask] --> Idempotency[输入哈希 / 幂等键]
Idempotency --> Queue[BullMQ 入队]
Queue --> Worker[独立 Worker]
Worker --> Secret[WORKER_SECRET]
Secret --> Delegate[backend internal/worker execute]
Delegate --> Provider[通用 Provider 执行]
Delegate --> Live[真人视频业务执行]
Provider --> Result[日志 / 素材 / 状态]
Live --> Result
Result --> Retry[按类型自动重试]
Retry --> Manual[耗尽后 manual_required]
```
已实现：
- 幂等键与输入哈希。
- 不同任务类型的默认重试次数。
- 任务取消与队列 Job 清理。
- stale running 任务恢复。
- 失败后自动重试与人工介入。
- 队列统计。
### 9.3 当前队列覆盖缺口
任务目录比 Worker 执行器更宽。以下任务在当前 `providerTypeForTask` 中没有实际 Provider 映射，也不属于真人业务执行器，走通用 Worker 时会被标记为 `skipped`：
- `long_memory_generate`
- `subtitle_generate`
- `live_action_keyframe_generate`
- `live_action_video_render`
- `analytics_event`
其中部分能力目前由同步 Service 方法直接执行，因此功能本身不一定不可用；但“全部已队列化”的说法不准确。`video_render` 在通用任务映射中指向 `VideoProvider`，与 FFmpeg 合成语义也需要重新核对。
## 10. 已实现但未完整写入原设计文档的功能
相较 `docs/system_a`、`docs/system_b` 的早期设计，当前代码额外出现或显著深化了：
1. 小说创作向导、章节 Agent、上下文构建、质量修复、版本快照与派生任务。
2. 小说阅读器、书签、批注、阅读进度。
3. 全局角色资产、外观版本、角色状态、角色 Prompt 版本与审核经验闭环。
4. 人物三视图独立工具，以及“主锚点参考/本次描述覆盖”两种模式。
5. 三视图视觉质量评分、问题提取、优化经验进入下一次生成。
6. 项目级场景/道具/IP 资产中心和主资产版本。
7. 动态分镜时长、前后镜衔接、转场字段、请求预览与 Prompt 人工覆盖。
8. 真人短剧 AI Router、镜头评分、成本预检、候选视频与自动质量闭环。
9. Kling 原生音频、Seedance、Seedream、Hailuo、Sora 等多模型目录。
10. Scene Composer、字幕/BGM/SFX/环境音开关、源音轨策略和原创音乐包。
11. 素材别名、选中/候选/淘汰状态、按分镜号和范围联合筛选。
12. Provider Lab、模型偏好、人民币成本标签和 Provider 调用审计。
13. 爆款诊断、拉片片段、创意模式和项目模式绑定。
14. API 应用层加密、临时素材签名 URL、视频 Range 流式播放。
## 11. 与原设计文档的主要差异
| 领域 | 原设计世界 | 当前代码现实 |
| --- | --- | --- |
| 产品定位 | 系统 A 小说转漫剧 + 系统 B 真人写真 | 已合并演化为小说、短剧、视频、角色/IP 资产、创作工具平台 |
| 用户端 | uni-app 多页面 | Vue 3 + Vite H5，核心集中在单一大页面 |
| 管理端 | GeekerAdmin | 自研 Vue 单页后台，未引入完整 GeekerAdmin 架构 |
| 数据库 | 约 20 个核心表 | 61 个 Model、33 个迁移 |
| Provider | 抽象层与少量真实模型 | 112 个配置，覆盖大量国内外文本/图像/视频/声音模型 |
| AI Router | 后续路由能力 | 已用于真人视频，但未成为全平台统一入口 |
| 小说 | 原创 mock + 导入改编 | 已加入 Agent、质量循环、版本、阅读器和派生任务 |
| 分镜 | 固定镜头/宫格倾向 | 动态时长、上下镜关系、首尾帧/多图、转场与声音层 |
| 视频 | 图片、TTS、字幕、简单合成 | 真人视频候选、QC、原生音频、Scene Composer、复杂 FFmpeg 后期 |
| 队列 | 所有生产任务统一异步 | Worker 已运行，但部分声明任务没有异步执行器，部分流程仍同步 |
| 存储 | MinIO 优先设计 | 当前实际使用本地私有存储，MinIO 未完整配置 |
| 支付 | 订单支付闭环 | 额度与 mock-pay 可用，真实支付未接入 |
| 审核 | 内容审核闭环 | API/UI 已有，但数据库没有实际审核记录 |
| 测试 | 文档定义生产验收 | 后端单测有覆盖但当前 35 条失败，前后端无自动测试 |
| 版本管理 | 设计文档持续推进 | Git 只有初始提交，大量现实代码尚未形成版本基线 |
## 12. 当前待优化问题
### P0：必须先处理
#### 12.1 Git 无法代表当前系统
- `main` 只有 1 个提交。
- 当前有 85 个修改项、47 个未跟踪项。
- 多个数据库迁移、小说新引擎、Provider Lab、人物三视图、数据与文档都未纳入提交。
风险：服务器故障、误操作或换机后，无法从 Git 恢复当前系统。
建议：先做数据库与素材备份，再把当前状态拆成可审阅提交；不要把生成素材和临时文件混入源码提交。
#### 12.2 测试未达到发布基线
后端结果：
```text
Test Files: 19 passed / 8 failed
Tests: 238 passed / 35 failed
```
失败主要分为：
1. 新增 Prisma 依赖后，旧测试 mock 没有补齐。
2. 动态分镜、质量闸门、BGM/SFX 策略改变后，旧期望未更新。
3. Provider 成本标签新增人民币后，断言仍使用旧文案。
4. Seedance 真人参考图预检策略出现测试与实现不一致。
应逐条判断“测试旧了”还是“代码回归”，不能简单批量改断言。
#### 12.3 当前运行进程未加载最新构建
审计期间全仓构建通过，但 backend 和 worker 进程启动时间早于最新构建产物。需要在备份、测试和变更确认后执行受控重启，并做健康检查与核心链路冒烟测试。
### P1：高优先级
#### 12.4 队列执行覆盖不完整
补齐或明确移出队列：长篇记忆、字幕、真人关键帧、真人合并、分析事件。避免任务显示已入队，Worker 最后却标记 `skipped`。
#### 12.5 状态字段漂移
数据库中存在历史 `completed`，当前代码只认 `success`。项目、任务、素材、审核等大量状态均为自由字符串。建议建立状态字典、迁移脚本和兼容测试。
#### 12.6 本地素材是单机风险点
当前 977 个素材使用本地私有存储，MinIO 未完整配置，部署目录中也没有可执行备份脚本。至少需要：
- 数据库定时备份。
- `storage/private` 增量备份。
- 恢复演练。
- 磁盘容量与失败告警。
#### 12.7 任务和调用失败积压
- RenderTask：77 failed、22 manual_required、2 pending。
- ProviderLog：170 failed、5 running。
需要区分历史测试垃圾、外部异步任务和真实待处理任务，并提供批量归档/恢复策略。
#### 12.8 Provider 配置过多且默认策略不清晰
数据库中有 112 个 Provider 配置，但全局默认仍是 mock。真实 Provider 启停、用户偏好、项目偏好、Router 和显式 provider_code 同时存在，容易出现“页面选了 A，实际走 B”的理解成本。
建议为每次调用固定记录并展示：请求 Provider、路由原因、实际 Provider、模型、参数、输入参考图、成本和回退链。
#### 12.9 外部 Provider 素材 URL 配置需复核
当前公开素材基础 URL 未设置，而部分第三方视频/图片 Provider 需要可访问的临时参考图 URL。应把此项纳入 Provider preflight，而不是运行到提交时才失败。
#### 12.10 审核闭环尚未实际使用
`ContentReview` 当前为 0 条。需要确认是入口未触发、审核结果写到了其他字段，还是生产流程绕过了正式审核。
### P2：结构性优化
#### 12.11 超大文件与前端单体化
- `live-action.service.ts` 约 1.42 万行。
- 用户端主页面约 1.35 万行。
- 管理端主页面约 1.03 万行。
这会放大回归风险和协作冲突。建议按稳定业务边界逐步拆分，不做一次性大重构。
#### 12.12 缺少前后端自动测试与正式 E2E
用户端、管理端目前没有测试文件。后端以单元测试为主，没有覆盖“登录 -> 项目 -> 分镜 -> 真实 Provider -> 素材 -> 合并”的稳定 E2E。
#### 12.13 API 缺少机器可读契约
当前 289 个接口依赖 TypeScript DTO 和手写 client，没有 OpenAPI 文档与自动 client 生成。接口数量继续增长后，前后端容易漂移。
#### 12.14 生产运维不完整
`deploy/` 只有开发 compose、Nginx 示例和说明，没有落地的发布、回滚、备份、日志轮转、监控和告警脚本。当前主要依靠 systemd 日志与人工检查。
#### 12.15 真实支付、多租户和财务对账未完成
- 支付仍为 mock-pay。
- 当前是用户级数据隔离，没有组织/租户模型。
- `cost_actual` 的币种与财务账单口径需统一。
## 13. 建议建立的唯一真相机制
### 13.1 Work 负责
```text
产品定位
业务规则
架构决策
未来路线
功能设计文档
```
### 13.2 Git + Codex 负责
```text
当前代码
数据库迁移
实现细节
测试结果
部署与运行事实
```
### 13.3 同步规则
每个重要功能建议使用以下闭环：
```text
Work 讨论
-> FEATURE_xxx_V1.md
-> Codex 实现
-> 测试与部署
-> 更新 CHANGELOG.md
-> 更新 PROJECT_STATUS_Vn.md
-> 回灌 Work
```
状态文档不应每次全量覆盖，而应保留 V1、V2、V3，便于追踪系统如何演化。
## 14. 建议放入 Work 的首批资料
```text
AI 内容生产平台/
├── 01_项目现状/
│ └── PROJECT_STATUS_V1.md
├── 02_架构设计/
│ └── SYSTEM_ARCHITECTURE.md
├── 03_小说引擎/
│ └── NOVEL_ENGINE.md
├── 04_短剧引擎/
│ └── DRAMA_ENGINE.md
├── 05_AI流水线/
│ └── AI_PIPELINE.md
├── 06_数据库/
│ └── DATABASE.md
└── 07_版本记录/
└── CHANGELOG.md
```
本次只生成真实状态基线。其余文档应以本文件为依据重新整理，而不是直接复制旧系统 A/B 文档并假定其全部已实现。
## 15. 本次验证记录
已执行并确认：
- 全仓生产构建通过。
- Prisma schema 可用。
- 33 个迁移与当前数据库一致。
- 后端健康检查通过。
- backend 与 worker systemd 服务正在运行。
- MySQL、Redis、Nginx 正在运行。
- 数据库只读数量与 Provider/任务状态统计完成。
- 自动测试执行完成，并如实记录 35 条失败。
未执行：
- 未重启生产服务。
- 未修改数据库数据。
- 未触发新的付费 AI 生成。
- 未做浏览器端完整 E2E。
- 未做数据库或素材恢复演练。
docs/work-sync/02_架构设计/SYSTEM_ARCHITECTURE_V1.md
+209
View File
@@ -0,0 +1,209 @@
# AI 内容生产平台架构设计 V1
> 文档状态：当前有效
> 基线日期：2026-07-15
> 事实来源：当前源码、Prisma schema、生产配置与 `PROJECT_STATUS_V1.md`
> 维护原则：记录稳定边界和已确认事实，不复制完整代码。
## 1. 架构目标
平台面向小说、角色/IP 资产、短剧和音视频成品的一体化生产，当前架构要同时满足：
- 长文本生产中的记忆、版本和质量循环。
- 图片、视频、声音等多 Provider 的差异化调用。
- 角色、服装、场景和道具在跨镜头生产中的连续性。
- 耗时任务的异步执行、重试、人工介入和成本追踪。
- 素材私有访问、Range 播放、下载与后期合成。
- 用户端生产工作台和管理端运营审计。
## 2. 系统边界
```mermaid
flowchart TB
User[用户端 Vue 3 H5] --> Nginx[Nginx]
Admin[管理端 Vue 3 H5] --> Nginx
Nginx --> API[NestJS API :3010]
API --> MySQL[(MySQL)]
API --> Redis[(Redis / BullMQ)]
API --> Storage[本地私有存储\nMinIO 可选]
API --> AI[外部 AI Providers]
API --> Media[FFmpeg / FFprobe]
Redis --> Worker[独立 Worker]
Worker --> Internal[受密钥保护的内部执行接口]
Internal --> API
```
外部依赖包括文本、图片、视频、语音、音乐、Embedding 和审核模型。平台负责业务编排、资产关系、质量控制和成本记录，不把外部模型的临时任务状态当作最终业务状态。
## 3. 仓库结构
项目采用 npm workspaces 单仓库：
| 目录 | 职责 |
| --- | --- |
| `backend/` | NestJS API、Prisma、业务编排、Provider 与媒体处理 |
| `workers/` | BullMQ 消费，委托后端内部接口执行业务 |
| `user-app/` | Vue 3 + Vite 用户端 H5 |
| `admin/` | Vue 3 + Vite 管理后台 |
| `deploy/` | 开发依赖和 Nginx 示例，生产运维脚本尚不完整 |
| `docs/` | 当前设计、历史设计、经验和同步包 |
| `data/` | 项目内容、剧本、分镜和生产资料 |
| `storage/` | 当前本地私有素材存储 |
| `tmp/` | 临时媒体处理文件 |
## 4. 后端分层
### 4.1 接入层
- HTTP API 统一使用 `/api` 前缀。
- JWT 负责用户身份，管理能力执行角色和 permission 校验。
- 统一响应 envelope、异常过滤、请求 ID 和安全响应头。
- 请求体上限当前为 160 MB。
- 素材接口支持鉴权下载、Range 流和临时签名 URL。
### 4.2 业务域
| 业务域 | 核心模块 |
| --- | --- |
| 身份与计费 | `AuthModule`、`UsersModule`、`BillingModule` |
| 项目与素材 | `ProjectsModule`、`AssetsModule` |
| 小说与世界观 | `NovelsModule`、`StoryBiblesModule`、`MemoriesModule` |
| 角色与 IP | `CharactersModule`、`ImagesModule` |
| 分集与剧本 | `EpisodesModule`、`ScriptsModule` |
| 真人短剧 | `LiveActionModule`、`MediaModule` |
| AI 与任务 | `ProvidersModule`、`ProviderLabModule`、`QueuesModule` |
| 审核与运营 | `ReviewsModule`、`AdminModule` |
`AiRouterModule` 当前服务于真人视频域，尚未成为全平台所有 AI 请求的统一入口。文档和界面不得把它描述成已完成的全局智能路由。
### 4.3 数据层
- Prisma 6 + MySQL。
- 当前 61 个 Model、33 个已部署迁移。
- 业务状态大多为字符串；历史值漂移需要通过状态字典和兼容迁移治理。
- JSON 用于保存 Provider 参数、Prompt 快照、质量报告和扩展元数据。
### 4.4 异步执行层
- Redis + BullMQ，共 14 个队列。
- Worker 并发当前为 2。
- Worker 不重复业务实现，通过受 `WORKER_SECRET` 保护的内部接口委托后端。
- `RenderTask` 保存幂等键、输入哈希、重试、成本与人工介入状态。
当前并非所有声明任务都已完整队列化。长篇记忆、字幕、真人关键帧、真人合并和分析事件存在同步执行或 Worker 映射缺口，详见 `AI_PIPELINE_V1.md`。
### 4.5 媒体层
- FFmpeg 负责归一、拼接、转场、字幕、BGM、SFX、环境音和混音。
- FFprobe 负责媒体元信息探测。
- 视频模型可返回原生音轨；后期策略决定保留、压低或补充外部音频。
- LipSync 已有抽象和策略字段，但真实 Provider 当前均未启用。
## 5. 前端架构现实
### 5.1 用户端
用户端为 Vue 3 + Vite H5。当前核心功能集中在 `pages/index/index.vue`，没有启用 Vue Router。顶级入口包括创作、工具、项目、作品、任务和我的。
独立工具目前只有“人物三视图”正式开放；影视场景、9/16/25 宫格和原创剧本仍为待接入状态。
### 5.2 管理端
管理端是自研 Vue 3 单页后台，并非完整 GeekerAdmin。主要功能集中在 `App.vue`，`router/`、`stores/`、`views/` 仍是占位结构。
### 5.3 结构风险
用户端、管理端和若干后端 Service 已形成超大文件。后续应按稳定业务边界渐进拆分，避免一次性重构影响现有真实生产链路。
## 6. 核心数据流
### 6.1 内容生产
```text
来源/创作 Brief
-> 版权与项目规则
-> 故事/世界观/角色/IP 资产
-> 分集与剧本
-> 动态分镜
-> 关键帧或多图参考
-> 视频候选
-> 自动 QC / 人工选择
-> 字幕、音频、BGM、SFX、转场
-> FFmpeg 成品
-> 审核与作品库
```
### 6.2 AI 调用
```text
业务请求
-> 用户/项目模型偏好
-> Provider 配置与预检
-> 同步调用或异步提交
-> ProviderLog
-> Asset / VideoClip / RenderTask
-> 质量评估、回退或人工介入
```
## 7. 安全与隐私
- API Key 由服务端密钥加密保存，后台不回显明文。
- Worker 内部接口使用 timing-safe 密钥比较。
- 素材默认私有，不依赖可枚举静态 URL。
- Nginx 承担公网 TLS；应用当前未强制 `HTTPS_REQUIRED`。
- 外部 Provider 使用参考图时，应只提交限时、最小权限 URL。
- Work 同步文档禁止包含 `.env`、API Key、JWT、数据库密码、私有素材 URL 和用户个人数据。
## 8. 部署与运行
当前生产事实：
- `ai-backend.service`、`ai-workers.service` 由 systemd 托管。
- Nginx 托管两套前端静态产物并代理 API。
- MySQL、Redis 为本机服务。
- 主存储为本地私有目录，MinIO 仅有代码能力，尚未完整配置。
- 全仓生产构建已通过，但运行进程需受控重启后才会加载最新构建。
当前缺少完整的发布、回滚、备份、日志轮转、监控和恢复演练脚本。这些属于发布基线，不应只保留为历史设计。
## 9. 架构约束
1. 数据库 schema 和迁移是数据结构唯一真相。
2. Provider 调用必须留下实际 Provider、模型、参数快照、成本和回退记录。
3. 角色、场景和道具应通过资产 ID/版本引用，不靠 Prompt 文本隐式继承。
4. 外部模型状态、平台任务状态和素材状态必须分层管理。
5. 付费生成前必须完成参数和参考图预检。
6. 视频质量闭环允许人工确认，不能把模型评分直接等同于发布通过。
7. 历史设计只能解释来路，不能覆盖当前代码事实。
## 10. 当前优先级
### P0
- 备份数据库和素材，固化 Git 基线。
- 修复 35 条后端失败测试。
- 受控重启并验证最新构建。
### P1
- 补齐队列执行覆盖和状态字典。
- 建立本地素材备份与恢复演练。
- 明确 Provider 路由优先级和实际调用展示。
- 补齐外部素材 URL preflight。
### P2
- 渐进拆分超大 Service 和前端单体组件。
- 引入 OpenAPI 契约和关键 E2E。
- 完善生产发布、回滚、监控与告警。
## 11. 更新触发条件
发生以下任一变化时更新本文并提升版本：
- 新增或删除顶层业务模块。
- 数据库、队列、存储或部署拓扑改变。
- AI Router 扩展为平台级入口。
- 前端路由或应用边界发生结构性变化。
- 安全边界、租户模型或支付模式改变。
docs/work-sync/03_小说引擎/NOVEL_ENGINE_V1.md
+147
View File
@@ -0,0 +1,147 @@
# 小说引擎现状与设计 V1
> 文档状态：当前有效
> 基线日期：2026-07-15
> 适用范围：小说导入、阅读、原创生成、质量循环、版本与派生任务。
## 1. 当前定位
小说引擎不是单一“生成一章”接口，而是平台的长文本内容底座。它负责把来源、创作约束、世界观、角色、剧情记忆和质量标准组织成可追踪的章节生产流程，并为短剧、听书等下游提供稳定文本资产。
## 2. 能力边界
### 已实现
- 粘贴、TXT、DOCX、PDF 等来源导入和章节切割。
- 小说目录、分页阅读、阅读进度、书签和批注。
- 原创小说创作向导与生成计划。
- StoryBible、WorldBible、角色和项目规则接入。
- Agent Prompt、AgentRun 与章节生成编排。
- 上下文记忆、章节版本、质量报告、自动修复和重写。
- 小说版本快照和听书/短剧派生任务数据结构。
### 尚未达到稳定基线
- 无人值守长批次生产。
- 全链路自动测试和正式 E2E。
- Agent 策略、质量阈值和人工确认的统一运营界面。
- 派生任务的完整异步执行覆盖。
## 3. 核心对象
| 对象 | 作用 |
| --- | --- |
| `NovelSource` | 导入或原创小说的主记录 |
| `NovelChapter` | 当前可读章节 |
| `NovelGenerationPlan` | 原创目标、结构、节奏和批次计划 |
| `NovelChapterVersion` | 草稿、修复、重写和确认版本 |
| `NovelContextMemory` | 供后续章节消费的压缩上下文 |
| `NovelQualityReport` | 章节质量维度、问题与修改建议 |
| `NovelVersionSnapshot` | 可追踪的整书状态快照 |
| `NovelDerivativeJob` | 听书、短剧等下游派生请求 |
| `AgentPrompt` | 可版本化 Agent 指令 |
| `AgentRun` | Agent 实际执行与输入输出记录 |
| `StoryBible` / `WorldBible` | 故事、世界规则和不可违反约束 |
| `CharacterMemory` / `PlotMemory` | 人物和剧情连续性信息 |
## 4. 生产流程
```mermaid
flowchart LR
Brief[创作 Brief / 导入文本] --> Plan[生成计划]
Plan --> Bible[故事与世界观规则]
Bible --> Context[上下文构建]
Context --> Prompt[Agent Prompt]
Prompt --> Draft[章节草稿]
Draft --> Quality[质量报告]
Quality --> Pass{达到阈值?}
Pass -- 否 --> Repair[定向修复或重写]
Repair --> Quality
Pass -- 是 --> Confirm[确认章节版本]
Confirm --> Memory[更新上下文与伏笔]
Memory --> Snapshot[版本快照 / 下游派生]
```
## 5. 上下文构建
每章生成不应把整本小说无差别塞入模型。上下文按优先级组成：
1. 当前项目和生成计划的硬约束。
2. StoryBible、WorldBible 中与本章相关的规则。
3. 当前角色状态、关系、服装/身份等连续性信息。
4. 上一章结尾和当前章目标。
5. 尚未回收的伏笔与必须推进的剧情线程。
6. 长篇压缩记忆和必要的原文片段。
7. 文风、篇幅、视角和禁用项。
所有自动压缩都必须保留来源章节和版本，以便发现错漏后回溯。
## 6. 质量循环
质量检查至少覆盖：
- 章节目标是否完成。
- 因果、时间线、人物动机是否成立。
- 角色口吻、能力、关系和状态是否连续。
- 伏笔是否误删、提前泄露或遗忘。
- 节奏、冲突、信息增量和章节钩子。
- 文风、重复、空泛解释和模板化表达。
- 与版权、合规和项目制作规则的冲突。
修复策略应优先定向改写问题段落；只有结构性失败时才整章重写。每次修复生成新版本，不覆盖原始版本。
## 7. 人工确认点
建议保留以下人工闸门：
- 生成计划确认。
- StoryBible/WorldBible 锁定。
- 核心角色和长期伏笔确认。
- 首章与关键转折章确认。
- 质量循环多次失败后的人工处置。
- 下游改编前的版本冻结。
## 8. Provider 策略
- NovelProvider 与 TextProvider 均可参与，但必须记录实际模型。
- 章节生成、质量审查和定向修复可使用不同模型配置。
- 用户偏好、项目偏好、显式 `provider_code` 与系统默认的优先级必须可解释。
- 真实调用失败后可回退，但不可静默切换后仍展示原模型名称。
- 成本记录需区分估算值和 Provider 返回的实际值。
## 9. 与短剧引擎的契约
下游短剧不直接读取“任意最新草稿”，应消费明确的小说快照或已确认章节版本。派生输入至少包含：
- 来源小说、章节和版本 ID。
- 已确认的人物、世界观和不可更改事实。
- 可压缩、可改编和禁止删减的内容范围。
- 目标时长、集数、媒介风格和受众。
改编产生的新事实不得反向污染小说正史，除非人工确认并写入新的 StoryBible/版本。
## 10. 当前风险
1. 新增 Prisma 依赖后部分单元测试 mock 未同步。
2. Agent、上下文和质量逻辑分布在多个服务，缺少稳定 E2E。
3. 长篇记忆任务声明存在，但 Worker 执行映射不完整。
4. 状态字符串缺少统一字典，历史数据可能出现兼容问题。
5. 批量生产的暂停、恢复、幂等和成本上限需要更强验证。
## 11. 不可破坏的规则
1. 所有章节修改必须形成版本，不直接覆盖已确认稿。
2. 生成请求必须能追溯到 Prompt、上下文和 Provider。
3. 故事圣经的硬约束优先于模型自由发挥。
4. 长篇记忆是辅助索引，不是原文唯一副本。
5. 下游派生必须绑定明确快照。
6. 质量评分不能替代人工对关键章节的确认。
## 12. 下一阶段
- 修复小说相关测试桩和状态期望。
- 增加“计划 -> 3 章批次 -> 质量修复 -> 快照”的 E2E。
- 明确章节状态机和迁移规则。
- 补齐长篇记忆与派生任务的 Worker 执行器。
- 为 AgentRun 增加成本、实际模型和输入摘要展示。
docs/work-sync/04_短剧引擎/AI_VIDEO_TEST_LESSONS_V1.md
+323
View File
@@ -0,0 +1,323 @@
# AI 真人/漫剧视频流水线测试踩坑记录 V1
更新时间：2026-06-12
用途：
- 记录测试阶段已经遇到的问题、原因判断、系统优化点。
- 后续接入 Kling、Seedance、Wan、Vidu、Runway、Veo 等平台时，按同一套准入标准测试，避免重复烧钱。
- 本文件是运营/开发测试手册，不替代 `docs/` 里的系统需求文档。
## 当前阶段定位
当前仍是测试磨合阶段，不追求一次性自动发布。
目标顺序：
1. 跑通自动化流水线。
2. 找到各 Provider 的能力边界。
3. 把失败原因转成系统规则。
4. 形成可恢复、可路由、可统计成本的生产流程。
5. 最后再逐步提高自动化比例。
## 已验证结论
### Hailuo 适合做什么
Hailuo / MiniMax Hailuo 2.3 Fast 当前更适合：
- 都市真人短剧普通镜头。
- 中景、远景、走路、转身、递物、沉默、反应镜头。
- 咖啡厅、街道、办公室、豪车、酒店、家庭等现实场景。
- 旁白 + 字幕 + BGM 推动剧情的短剧。
- 成本敏感的批量生产。
当前实测成本：
- `minimax_hailuo_23_fast`：约 `$0.317 / 10秒`
- `minimax_hailuo_23`：约 `$0.467 / 10秒`
### Hailuo 不适合硬扛什么
Hailuo 对以下镜头可控性不足：
- 凌空翻滚、复杂武打、连续打斗。
- 精准手诀、结印、舞蹈式手部动作。
- 法相天地、千臂法身、巨型神像复杂动作。
- 一镜中塞太多高复杂动作。
- 正脸强台词口型同步。
处理原则：
- 不要在同一失败动作上无脑重跑 Hailuo。
- 如果同类复杂动作 1-2 次失败，优先切换 Provider 或补动作参考/姿势关键帧。
- 修仙、法相、打斗、次元壁穿越等镜头默认标记为高价值/高复杂度，不按普通都市镜头处理。
## 分镜时长经验
### Hailuo 时长设计规则
Hailuo 当前按真实可用规格优先设计：
- 常规可用镜头时长：6 秒 / 10 秒。
- 真人短剧主流程优先按 10 秒长镜头设计。
- 只有非常简单的过渡镜头、环境镜头、无台词动作镜头，才考虑 6 秒。
- 不再设计 7 秒、8 秒这种无法直接匹配 Hailuo 输出规格的镜头。
系统规则：
- 导演分镜上限必须允许 10 秒。
- 如果原分镜明确是 10 秒，prepare 阶段不得自动压缩成 5 秒或 8 秒。
- 负面约束里的“避免嘴部特写”不能导致镜头被误判成 insert 特写。
- “手里的道具”不能被误判成“手部特写”，只有手部/手指/手掌/手腕/手势等明确关键词才算 insert。
### 3 秒碎片问题
法相天地三段式测试暴露问题：
- 镜头切太碎，像图片拼接。
- Hailuo 实际输出常按 6 秒返回，系统再裁成 3/3/4 秒时，动作容易被截断。
- 复杂动作被拆太短，会失去电影感和动作连贯性。
结论：
- 普通反应镜头：3-5 秒可以。
- 都市剧情镜头：5-6 秒更稳。
- 复杂动作/爆点镜头：优先 8-10 秒一镜到底。
- 不能把 6 秒 Provider 输出硬裁成 3 秒作为长期策略。
### 10 秒一镜到底结论
法相天地 10 秒 Hailuo 测试已验证：
- Hailuo API 可以返回 10 秒。
- 10 秒一镜到底比 3 段裁切更连贯。
- 人物、服装、场景稳定性明显提升。
- 但复杂动作本身仍受 Provider 能力限制。
系统规则：
- `action_score >= 8` 且 `importance >= 8` 的镜头，优先生成 8-10 秒单镜头。
- 如果 Provider 不支持目标时长，再由系统拆分，不要随意裁切关键动作。
## Prompt Engine 经验
直接把剧情发给视频模型，质量不稳定。
必须通过 Prompt Engine 组装：
- 角色。
- 场景。
- 主动作。
- 镜头大小。
- 运镜。
- 动作时间轴。
- 情绪表演。
- 灯光。
- 特效时机。
- 声音卡点。
- 负面约束。
已落地：
- Motion Director Prompt。
- 10 秒仙侠一镜到底时间轴。
- Hailuo 长镜头 prompt 上限提升。
仍需注意：
- Prompt 只能提高概率，不能保证复杂动作精确执行。
- 复杂动作需要动作参考图、姿势关键帧或更强 Provider。
- 如果同一个 Prompt 多次失败，继续加形容词意义不大。
## 角色一致性经验
当前测试发现：
- 没有固定角色定妆图/锚点图时，人物容易漂移。
- 修仙/奇幻镜头更容易因为特效导致人物脸和服装变化。
- 都市短剧也需要固定林凡、陈雪、王伯这类角色锚点。
系统规则：
- 真人短剧正式验收前必须先做角色锚点图。
- 新剧首轮至少固定主角、女主、关键配角。
- Provider 小样要使用同一角色锚点和同一关键帧，避免测试结果不可比。
## 声音与字幕经验
没有声音、没有字幕、没有 BGM 的视频判定为失败。
已经遇到的问题：
- 屏幕女孩测试：无声音、无字幕，发布感不足。
- 口型镜头：语音先到，嘴型后动。
- 部分合成音量偏低，视觉还可以但情绪不够。
系统规则：
- 每条可发布视频必须包含字幕。
- 每条可发布视频必须包含 BGM 或环境底噪。
- 情绪镜头必须有 SFX：雨声、脚步、门声、心跳、低频冲击、sting 等。
- 合成后必须跑音量检测。
- 音量偏低时重新后期合成，不一定重跑视频。
## 台词与 lip-sync 经验
没有稳定 lip-sync Provider 前，不要把关键台词做成正脸大嘴型特写。
当前策略：
- `lip_sync_required=true` 但没有真实 lip-sync Provider 时：
- 改成旁白。
- 改成字幕。
- 改成中景/侧脸/轻口型。
- 避免正脸嘴部特写。
未来接入 lip-sync Provider 后：
- 只给关键正脸台词使用。
- 不全片 lip-sync，避免成本翻倍。
- lip-sync 放在视频片段生成后、FFmpeg 合成前。
## 成本控制经验
默认策略：
- 每个镜头默认只生成 1 条。
- 不默认生成 2-3 条候选。
- 只有封面级、爆点、最后反转、人工验收阶段才允许候选 2 条。
- 任何候选数增加都必须进入成本预估和审计日志。
当前后台已支持：
- AI 接入列表展示每 10 秒成本。
- Provider `cost_summary`。
- 单次成本上限。
- 当日成本上限。
- `price_per_second=0` 不当成免费，而是提示需账单回填。
## Provider 路由经验
推荐基础路由：
```text
普通都市镜头
=> Hailuo
都市高价值镜头
=> Hailuo 优先，必要时 Kling / Vidu / Wan 对比
修仙 / 法相 / 打斗 / 次元壁 / 复杂动作
=> Premium Provider 候选
正脸台词
=> 有 lip-sync Provider 才允许正脸特写，否则中景/旁白/字幕
成本超预算
=> Premium -> Hailuo -> Seedance/Mock
```
不要把“平台选择”写死在业务代码里，必须走 Router。
## Provider 准入测试标准
每接入一个新视频 Provider，都按固定小样测试：
1. 同一项目。
2. 同一角色锚点图。
3. 同一关键帧。
4. 同一镜头文本。
5. 同一目标时长。
6. 同一分辨率/比例。
7. 记录真实成本。
8. 记录失败原因。
9. 记录生成耗时。
10. 记录人工观感评分。
必须记录：
- `provider_code`
- `model_name`
- `clip_id`
- `asset_id`
- `duration`
- `cost_actual`
- `quality_score`
- `human_acceptance`
- `failure_reason`
- `prompt_version`
- `keyframe_asset_id`
## 人工验收标准
当前 mock-qc 分数只能说明流程没坏，不能代表可发布。
真人视频上线前必须人工看：
- 人物是否稳定。
- 动作是否连贯。
- 镜头是否像真实拍摄。
- 字幕是否准确。
- 声音是否完整。
- BGM/SFX 是否有情绪。
- 口型是否明显穿帮。
- 是否有明显 AI 手、脸、身体变形。
- 成本是否在预算内。
## 不要重复踩的坑
- 不要把 mock-qc 通过当成真实质量通过。
- 不要无音频/无字幕就判断视频流程合格。
- 不要用 3 秒碎切测试复杂动作。
- 不要在 Hailuo 上反复烧复杂修仙动作。
- 不要把 `price_per_second=0` 当成免费。
- 不要默认生成 2-3 条候选。
- 不要让正脸台词在没有 lip-sync 时直出。
- 不要只看最终成片，要保留脚本、分镜、prompt、关键帧、音频、视频片段、合成记录。
- 不要默认认为 `mock-video` 就是全链路零成本；如果 TTS Provider 已启用真实平台，Mock 视频合成仍可能调用真实 TTS。零成本压测要显式指定 `mock-voice` 或关闭音频。
- 真实 Hailuo / Kling / Wan 等图生视频前必须先跑 preflight，确认关键帧是 PNG/JPG/WebP；Mock SVG 只能测流程，不能直接发给真实视频 Provider。
- Hailuo Fast 跑都市真人 10 秒镜头可用，5 条 10 秒顺序生成约 9 分钟，总成本记录 `$1.585`；后续应进入队列并在后台显示耗时。
- 只用单张临时关键帧会改善画面质感，但不能彻底解决同脸一致性；要上架必须补“角色锚点图 / 定妆图 / 同脸参考图”流程。
- 都市短剧 Hailuo 长镜头比 3-6 秒碎切更像真人短剧，但部分镜头仍会像关键帧慢推；Prompt 里要继续强化明确动作、人物走位、视线、反应和镜头结束动作。
- 角色锚点图 V1 对关键帧生成有效：同一角色的脸、服装、气质会比临时起图更稳；但 Hailuo Fast 当前按单首帧图生视频跑，不能直接吃多角色参考图，所以运动中仍可能轻微改脸。
- 锚点重跑应优先挑第 1 镜、第 3 镜、第 5 镜这类“角色出场 / 冲突 / 反转”镜头；默认候选仍为 1 条，避免成本翻倍。
- 真人短剧对白不能一镜一段 TTS 直接读完；只要 `dialogue_text` 里出现 `角色名：台词`，必须拆成多段 TTS，每段记录 `speaker_name` / `character_id` / `voice_id` / `voice_style`。
- 角色声线是发布级基础配置：顾辰、林雨薇、周浩、管家这类核心角色必须先在 Character 表绑定声音；否则即使画面像真人，声音也会变成解说感。
- 主持人、旁白也要当作独立声线处理；如果没有角色记录，至少要走固定 narration / host voice，不能复用男主或女主声音。
- 多声线 TTS 只解决“谁在说话”的问题，不解决“嘴型同步”；正脸台词仍要继续走 lip-sync 或中景轻口型策略。
- TTS 声音 ID 不能只看名字想当然：`Chinese (Mandarin)_Gentle_Senior` 在老管家场景听感偏女，不适合作为中老年男管家默认声线；当前老管家默认改为 `Chinese (Mandarin)_Gentleman`，但仍需人工听感确认。
- 核心角色上线前要做“角色声线小样验收”：每个角色先生成 1-2 句固定台词试听，确认性别、年龄、气质，再进入整集成片，避免整集重合成。
- Hailuo 2.3 标准版 1080P 比 Fast 768P 清晰度和雨夜质感略好，但第 5 镜 A/B 证明它不能单独解决“像图片动”的问题；高价值反转镜头更需要三关键帧/动作参考/更强 Provider，而不是只把 Fast 换成标准版。
- Provider A/B 测试必须保护当前成片：生成候选后要恢复 `storyboard_shots.video_clip_asset_id`，避免实验 clip 自动替换正式整集。
- 动作节拍链式生成 V1 对高价值反转镜头有效：第 5 镜用 2 段 Fast 生成，第二段用第一段结尾帧作为首帧，比单首帧慢推更能呈现“递卡 -> 看卡震惊”的动作链。
- action beat 不能默认全片开启：成本、耗时都会增加，适合反转/封面/爆点/高价值动作镜头；普通对话镜头仍用单条生成。
- preflight 必须按 action beat 的真实分段估算成本，否则后台会低估费用；第 5 镜 action beat 从单条 `$0.317` 变为 2 段 `$0.3804`。
- action beat 只解决“动作链更连续”，不解决“同一角色像同一个演员”；整集样片必须单独检查人物脸、年龄感、发型、服装是否跨镜稳定。
- 真实视频生成不能只传角色名字；必须把本镜出现角色的 ActorProfile 注入 provider prompt，并在 task input 记录 `actor_lock`，否则后台无法审计“这条视频到底有没有走锁脸策略”。
- prepare 阶段不要把全项目角色描述混进单镜 prompt；单镜只允许注入本镜出现的人物，否则多人项目会增加串脸概率。
- Hailuo 当前配置不是强角色参考模型，`supports_character_reference=false`；它可以做低成本图生视频，但发布级真人短剧要靠“角色锚点图生成首帧 + 强一致性 prompt + 人工抽检”，必要时横测支持角色参考的 Provider。
- 如果整集都换脸，不要继续盲目重跑全片；应先重跑第 1 / 3 / 5 镜这种出场、冲突、反转镜头，对比抽帧确认角色锁定是否有效，再决定是否整集重跑。
- 多角色音频不能把跨平台 voice_id 混用：`coral` 属于 OpenAI TTS，不能直接发给 MiniMax；Provider 层必须做 voice_id 适配或降级到当前 Provider 默认声线。
- MiniMax TTS 返回 JSON 时必须先检查 `base_resp.status_code`；否则账号权限、voice_id、group_id 等真实错误会被误报成 `EMPTY_AUDIO`。
- 小说上传走 encrypted JSON/base64 时，实际 HTTP body 会比原文件大约 33%；后端 body limit 必须高于文件限制，否则会先被 `request entity too large` 拦截。
## 下一步建议
短期优先：
1. 继续围绕都市真人短剧做 Hailuo 量产质量优化。
2. 做角色锚点图/定妆图 V1。
3. 做动作参考/姿势关键帧 V1。
4. 用同一固定镜头横测 Kling / Seedance / Wan / Vidu。
5. 建 Provider 准入表：质量、成本、失败率、耗时。
6. 做 BGM/SFX 发布级音量标准。
7. lip-sync 只做关键台词小样，不先全片接入。
长期原则：
- Hailuo 做低成本量产。
- 高价值镜头交给高质 Provider。
- Router 负责自动选模型。
- QA + 人工抽检负责质量闭环。
- 成本、失败、重试、降级全部进入审计。
docs/work-sync/04_短剧引擎/DRAMA_ENGINE_V1.md
+239
View File
@@ -0,0 +1,239 @@
# 短剧引擎现状与设计 V1
> 文档状态：当前有效
> 基线日期：2026-07-15
> 适用范围：分集、剧本、动态分镜、视觉资产、视频候选、质量控制与成片合成。
## 1. 当前定位
短剧引擎负责把已确认的故事内容转为可生产镜头，并持续管理人物、场景、表演、声音和后期之间的关系。当前系统同时支持真人/仿真人短剧、原生音频视频和传统“图片 + TTS + 字幕”合成，不应把任何单一模型当成完整导演系统。
## 2. 核心原则
1. 剧情完整度优先于固定镜头数量。
2. 分镜时长由对白、动作、停顿和转场预算共同决定。
3. 角色、服装、场景和关键道具必须引用明确资产版本。
4. 首帧、首尾帧、多图参考和纯文本生成按镜头需要选择。
5. 视频模型负责画面和可用原生声音，稳定文字 UI、字幕和进度条优先由后期完成。
6. 表演、运镜、声音和镜头衔接都属于质量评分，不只检查画面清晰度。
7. 每个付费请求必须保留完整提交参数和实际 Provider。
## 3. 生产对象
| 对象 | 作用 |
| --- | --- |
| `Episode` | 分集目标、顺序、状态和质量信息 |
| `EpisodeScript` | 已确认的单集剧本与版本 |
| `StoryboardShot` | 镜头时长、动作、对白、运镜、声音、Prompt 和衔接 |
| `Character` / `GlobalCharacter` | 项目角色与可复用演员资产 |
| `CharacterState` | 角色在特定时间点的服装、伤势、情绪等状态 |
| `ProjectVisualAsset` | 场景、道具及其主版本 |
| `ShotImage` | 首帧、尾帧、关键帧和候选图 |
| `VideoClip` | 单镜视频候选、实际模型、QC 和选择状态 |
| `Asset` | 图片、视频、音频、字幕和成品的统一素材记录 |
| `RenderTask` | 异步任务、重试、成本和人工介入 |
## 4. 标准流程
```mermaid
flowchart LR
Source[连续原文快照] --> Analysis[原著分析合同]
Analysis --> Bible[改编圣经合同]
Bible --> Episode[分集计划合同]
Episode --> Continuity[三集连续性检查]
Continuity --> Release[人工放行一集]
Release --> Script[单集剧本]
Script --> Shot[动态分镜]
Shot --> AssetPlan[角色/场景/道具资产计划]
AssetPlan --> Prompt[镜头 Prompt]
Prompt --> Frame[关键帧/参考图]
Frame --> Video[视频候选]
Video --> QC[自动 QC]
QC --> Select[重试/回退/人工选择]
Select --> Compose[字幕/声音/BGM/SFX/转场]
Compose --> Render[FFmpeg 成片]
Render --> Review[审核与作品库]
```
`splus_v1` 新项目使用上述结构化写路径。旧项目的 StoryBible、Episode 和历史 Prompt 保持原样，不自动迁移；旧写接口不能向新项目写入。原著分析、改编圣经和分集计划均追加新版本，并保存来源、质量问题和人工确认记录。
## 5. 剧本到分镜
### 5.1 剧本审核
每集应对照来源文本和上下集，检查：
- 核心事实、动机和因果是否保留。
- 是否为压时长而删掉必要台词或反应。
- 对白是否像角色在表演，而不是信息段落拼接。
- 心理旁白、悬疑信息和听觉线索是否服务情绪。
- 本集钩子、高潮和尾点是否成立。
### 5.2 动态时长
时长估算至少包含：
```text
对白朗读时间
+ 动作完成时间
+ 反应/停顿时间
+ 运镜落点时间
+ 前后镜衔接余量
```
模型支持的单次最大时长不是目标时长。台词无法完整说完时，优先延长或按完整戏剧节拍拆镜，禁止靠加速到听不清来硬塞。
### 5.3 分镜字段
单镜至少应明确：
- 当前镜头的戏剧目标。
- 角色站位、视线、入画和离画方向。
- 按时间段划分的动作与表演。
- 逐句台词、说话者、语气和开始时机。
- 景别、机位、镜头运动和最终落点。
- 环境声、对白、系统声、SFX 和 BGM 节奏。
- 与上一镜的接入动作、声音桥或视觉桥。
- 与下一镜的尾帧、视线、运动方向或声音预埋。
- 禁止项和资产版本。
## 6. 资产一致性
### 6.1 角色
- 先确定全局角色和当前项目外观版本。
- 服装、发型、年龄、伤势和持有物由 `CharacterState` 固定。
- 三视图用于角色母版，不代表每个镜头都应直接上传整张三视图。
- 同场多人应明确各自参考图和身份，避免参考关系错配。
### 6.2 场景
- 场景主资产应至少覆盖关键方向、空间结构和标志物。
- 同一连续场景不得仅靠文字重复描述来维持一致性。
- 对联、牌匾、二维码、屏幕等精确文字内容应由后期层处理，模型画面保留合理空间和时长。
### 6.3 道具
- 剧情证据、武器、手机、银铃、文件等关键道具应有主资产或明确外观约束。
- 道具在人物手中时要描述持握手、方向、前后位置和动作路径。
## 7. 图像输入模式
| 模式 | 适用情况 | 主要风险 |
| --- | --- | --- |
| 纯文本 | 无既有资产、探索性镜头 | 角色和空间漂移最大 |
| 单首帧 | 同一空间内连续表演、动作可自由发展 | 尾点不可控 |
| 首尾帧 | 明确起止构图、动作落点或转场接力 | 首尾差异过大时中间形变 |
| 多图参考 | 同时约束人物、场景、道具，或测试模型参考能力 | 参考权重错配、剧情控制有限 |
选择原则：使用能满足镜头目标的最少参考图。首尾帧需要处于同一时空、同一服装、可连续运动，不能拿两个独立海报硬桥接。
## 8. 视频生成
当前支持：
- 单镜和批量生成。
- 单首帧、首尾帧和多图参考。
- 多候选与人工选择。
- Kling 原生音频、Seedance 等真实视频 Provider。
- Provider preflight、成本估算和异步轮询。
请求记录应包含：
- 原始业务 Prompt 和最终提交 Prompt。
- 参考图顺序、资产 ID、用途和临时 URL。
- 请求时长、比例、分辨率、模型和 Provider 参数。
- 是否要求原生音频、实际返回音轨。
- Provider 任务 ID、状态、耗时、成本和失败原因。
特殊对照测试可以按用户要求“原样 Prompt + 指定图片”提交，此时不得自动注入公共润色词；系统应明确标记为 bypass/实验请求，避免污染正式模板结论。
### 8.1 当前统一画幅
- 新生产任务统一使用16:9横屏。
- 1080P视频固定1920×1080，关键帧固定2560×1440，原生4K固定3840×2160。
- 新的 Production Contract、Generation Plan、关键帧 Prompt、视频请求和 FFmpeg 合成都读取同一横屏常量。
- 历史素材与已冻结计划不原地改写；旧镜头重新生成时创建新的16:9计划修订。
### 8.2 Kling 视频角色元素
视频角色元素负责回答“角色是谁、长什么样、使用什么声线”；分镜 Prompt 只负责场景、动作、表演、台词与运镜。
生产步骤：
1. 从已确认角色锚点生成3-8秒身份源视频，默认8秒、1080P、16:9。
2. 人物正面起始，依次左转约30度、回正、右转约30度并回正；背景与灯光保持中性。
3. 在 Kling 元素库人工创建视频角色元素；当前不宣称存在已验证的公开创建 API。
4. 将真实 `element_id`、元素名称、源视频、声线和质检结果导入 `CharacterProviderBinding`。
5. 质检分达到90后才能审批为正式主元素。
6. Generation Plan 冻结角色到元素的映射；正式 Omni 请求提交真实 `element_list`。
7. 新 S+ 镜头缺少任何出场角色的已审批元素时，在付费调用前阻断。
Prompt 内的 `<<<element_n>>>` 与 API `element_list[n]` 必须一一对应。网页端 `@名称` 只用于手工操作，不能冒充已绑定 API 元素。
## 9. 声音设计
声音层包括：
- 角色对白和心理旁白。
- 机械系统音或非人物提示音。
- 环境声、拟音和冲击音效。
- BGM、高潮音乐和转场声音桥。
- 模型原生音轨、后期 TTS 与补充音频。
系统音必须在 Prompt 中与角色声线分离，说明音色、节奏、响度和播放窗口；仍不稳定时由后期独立音轨替换。字幕仅展示实际说出的台词，不包含角色名、动作说明或生成残留符号。
## 10. 质量控制
自动 QC 至少覆盖：
- 角色身份、脸型、年龄和服装一致性。
- 场景空间、道具和文字占位是否正确。
- 动作是否按方向完成，是否出现穿模或多余人物。
- 台词是否完整、中文是否清楚、声线是否串角色。
- 嘴型、说话时机和字幕窗口是否协调。
- 运镜是否服务表演，有无硬切、漂移或无意义运动。
- 首尾是否能接前后镜。
- 画质、闪烁、畸变、音量和可播放性。
自动评分用于筛选和重试，不直接等于发布通过。关键镜头和最终成片必须允许人工确认。
## 11. 合成与后期
当前 FFmpeg 链路支持：
- 分辨率、帧率、像素格式和音轨归一。
- 硬切、淡入淡出、模糊、声音桥等转场。
- 原生音轨、附加音频、BGM、SFX 和环境音混合。
- ASS/字幕烧录。
- UI 提示框、进度条和稳定中文信息层。
- 无源音轨时的兜底声音。
正式合并流程应输出完整成片，而非只做裸拼接。每次合成需保存镜头顺序、裁剪范围、转场、字幕、UI 和混音参数，以便可重复生成。
## 12. 当前风险
1. 动态分镜、声音和后期策略变化后，部分测试仍使用旧期望。
2. 真人关键帧和真人合并任务并未全部通过 Worker 执行。
3. Scene Composer 和原创音乐默认关闭，项目间配置容易产生理解差异。
4. LipSync 只有抽象，当前真实 Provider 未启用。
5. Provider 临时参考图公网可达性尚未形成统一 preflight。
6. 自动字幕、UI 时间点与台词结束边界仍需更多成片回归样本。
## 13. 不可破坏的规则
1. 不删改用户已确认的总剧本事实，分镜只能做可追踪改编。
2. 不在用户要求原样测试时偷偷注入模板。
3. 不用未确认的角色或服装锚点替换主资产。
4. 不把模型生成的乱码文字当作正式 UI。
5. 不在对白未结束时切镜。
6. 不把多个候选误当成同一镜重复提交。
7. 不在没有参数快照的情况下宣称某模型效果优劣。
## 14. 下一阶段
- 建立剧本/分镜逐镜 98+ 审核量表的机器可读版本。
- 补齐视频合成、字幕和真人任务的 Worker 执行器。
- 为每次视频调用展示实际路由、参考图和回退链。
- 增加完整成片 E2E：镜头生成 -> 选择 -> 字幕/UI -> BGM/SFX -> 合并。
- 将高质量人工评审结果沉淀为可版本化 Prompt 经验，而不是无边界自动追加。
docs/work-sync/05_AI流水线/AI_PIPELINE_V1.md
+222
View File
@@ -0,0 +1,222 @@
# AI 流水线与 Provider 设计 V1
> 文档状态：当前有效
> 基线日期：2026-07-15
> 目的：说明当前 AI 请求如何选择、执行、记录、回退和进入业务资产。
## 1. 设计目标
- 业务不直接绑定单一厂商 SDK。
- 每次调用可解释、可审计、可计费、可重试。
- 同步和异步 Provider 使用统一日志与业务结果。
- 用户指定的模型和参数不被静默替换。
- Prompt 模板、实验请求和原样透传有明确边界。
- AI 失败不会破坏已经确认的业务资产。
## 2. Provider 类型
当前目录覆盖：
- `TextProvider`
- `NovelProvider`
- `ImageProvider`
- `VideoProvider`
- `VoiceProvider`
- `MusicProvider`
- `EmbeddingProvider`
- `ModerationProvider`
- `LipSyncProvider`（抽象存在，真实配置当前关闭）
数据库当前有 112 个 Provider 配置，其中真实配置 101 个、启用 64 个；Mock 配置 11 个、启用 10 个。全局 `AI_PROVIDER_MODE` 当前仍为 `mock`，但业务显式选择真实 Provider 时会产生真实调用。
## 3. 调用选择
一次调用可能同时受到以下输入影响：
1. 用户明确选择的 `provider_code`。
2. 项目级模型偏好。
3. 用户级模型偏好。
4. 业务模块默认 Provider。
5. Provider 启停、优先级、能力和成本限制。
6. AI Router 的业务评分与回退规则。
当前 AI Router 主要用于真人视频，不是全平台统一路由。后续必须固定一套明确优先级，并在调用详情展示：请求选择、路由原因、实际 Provider、实际模型和回退链。
## 4. 请求生命周期
```mermaid
flowchart LR
Input[业务输入] --> Build[构建请求]
Build --> Preflight[参数/能力/素材 URL/成本预检]
Preflight --> Config[解析 ProviderConfig]
Config --> Submit[同步执行或异步提交]
Submit --> Log[ProviderLog]
Log --> Poll[异步轮询/回调]
Poll --> Normalize[结果归一]
Normalize --> Asset[Asset / VideoClip / 文本版本]
Normalize --> QC[质量评估]
QC --> Pass{通过?}
Pass -- 否 --> Retry[同模型重试/回退/人工介入]
Pass -- 是 --> Done[业务确认]
```
### 4.1 请求构建
请求快照至少保存：
- 业务类型和关联项目/分镜/角色。
- 原始输入与最终 Prompt。
- 公共模板版本和是否旁路模板。
- 模型、比例、时长、分辨率、种子等参数。
- 参考素材的资产 ID、顺序和用途。
- 预估成本和用户确认条件。
### 4.2 Preflight
提交前检查：
- Provider 是否启用且类型匹配。
- 参数是否在模型能力范围。
- 参考图数量、格式、大小和顺序。
- 外部 Provider 能否访问临时素材 URL。
- 账户额度和项目成本上限。
- 原生音频、首尾帧、多图参考等能力是否真实支持。
- 实验请求是否要求禁止模板注入。
- 新生产任务的画幅是否为唯一允许值16:9。
- S+ Kling Omni 镜头的每个出场角色是否绑定质检分不低于90的已审批视频角色元素。
- Omni 的图片、视频与元素组合是否满足数量和互斥限制；无参考视频时图片与元素合计不超过7。
### 4.3 结果归一
不同 Provider 的任务 ID、状态、URL、用量和错误格式必须转换为平台统一结构，再写入业务资产。临时 URL 不是最终资产，需下载到私有存储并保存来源信息。
## 5. Prompt 管理
Prompt 分为四层：
1. 业务事实：剧本、角色、场景、动作和台词。
2. 公共质量模板：画质、一致性、可用性和负向约束。
3. Provider 适配：模型特有参数与表达。
4. 本次覆盖：用户人工修改或严格原样提交。
优先级为“本次明确覆盖 > 已确认业务事实 > 公共模板 > Provider 默认”。公共模板不得改变台词、人物、镜头时长或参考图集合。
人物三视图已具备“主锚点参考”和“本次唯一角色描述覆盖”两种模式，并将视觉质检问题沉淀为后续优化经验。经验只能以版本化、可审阅方式进入公共模板，避免单个角色的专用词污染全局。
Kling 正式镜头不再重复大段描述已锁定角色五官。平台从不可变 Generation Plan 读取 `CharacterProviderBinding` 快照，把真实 `element_id` 写入 `element_list`，再在 Prompt 中使用与数组顺序一致的 `<<<element_n>>>` 标记。角色元素控制身份和绑定声线，镜头 Prompt 控制本次动作、表演、空间、台词与摄影。
S+ 结构化写路径新增阶段 Prompt Builder。Source Analyst、Adaptation Showrunner、Episode Planner 的公共模板与项目数据分离，运行时只注入不可变来源快照、已确认父合同和上一集状态。Writer 输出完整合同；Reviewer 只输出问题与结构化修复差异，不静默重写正文。用户可以在调用 Provider 前预览最终阶段 Prompt；Phase 2 默认不提供一键付费生成入口。
## 6. 任务与队列
### 6.1 队列
```text
novel_queue / parse_queue / story_queue / character_queue
episode_queue / script_queue / storyboard_queue / image_queue
audio_queue / subtitle_queue / video_queue / qc_queue
review_queue / analytics_queue
```
### 6.2 平台任务状态
```text
pending / running / success / failed / retrying
cancelled / manual_required / skipped
```
数据库中仍有历史 `completed`，需要迁移或兼容，不应继续产生新值。
### 6.3 执行模式
Worker 消费 BullMQ 后，通过受密钥保护的内部 API 委托 backend 执行。这样可复用业务逻辑，但也意味着 backend 必须能承受 Worker 回调并保持幂等。
### 6.4 已知覆盖缺口
以下任务在通用 Worker 映射中没有 Provider 执行器，可能被标记为 `skipped`：
- `long_memory_generate`
- `subtitle_generate`
- `live_action_keyframe_generate`
- `live_action_video_render`
- `analytics_event`
部分能力目前由同步 Service 完成，因此应选择：补齐 Worker 执行器，或从异步任务目录移除并明确同步语义。`video_render` 当前映射到 VideoProvider，与 FFmpeg 成片合成的命名也需要拆分。
## 7. 重试与回退
重试策略按错误性质区分：
| 错误 | 处理 |
| --- | --- |
| 参数/素材不可用 | 不盲目重试，返回可修复原因 |
| 限流/临时网络故障 | 指数退避重试 |
| 异步任务超时 | 先核对外部任务，避免重复扣费 |
| 质量不达标 | 同模型定向重试，必要时回退其他模型 |
| 多次失败 | `manual_required`，保留全部候选和日志 |
回退不可静默发生。UI 应展示实际使用模型和回退原因。
## 8. 成本与额度
- `ProviderConfig` 保存成本规则和能力配置。
- `ProviderLog` 保存本次调用的估算/实际成本、耗时和状态。
- `QuotaAccount`、`QuotaLog` 支持冻结、释放和扣减。
- 数据库历史 `cost_actual` 可能混有不同币种/规则，只能技术对账，不能直接作为财务总额。
- 真实支付仍为 mock，不能把订单模型描述成生产支付闭环。
提交付费任务建议采用：
```text
预估 -> 冻结额度 -> 执行 -> 按实际结算 -> 释放差额
```
异步任务重试必须复用或核验外部任务 ID，避免重复扣费。
## 9. 日志与审计
每次 AI 调用应能回答：
- 谁、在哪个项目、为了哪个业务对象调用？
- 用户请求了什么 Provider/模型？
- 系统为何选择实际 Provider/模型？
- 最终提交了什么参数和参考素材？
- 是否注入模板、是否回退、重试了几次？
- 外部任务 ID、耗时、状态和错误是什么？
- 产生了哪些资产，哪一个被选择？
- 估算成本、实际成本和额度变化是什么？
API Key、JWT、数据库密码和临时签名参数不能进入可下载日志或 Work 文档。
## 10. 新 Provider 接入清单
1. 明确能力类型、模型和区域。
2. 定义请求 DTO、参数范围和默认值。
3. 实现鉴权、提交、轮询/回调、取消和结果归一。
4. 处理文本、二进制和临时 URL 输入。
5. 定义成本规则和币种。
6. 增加 preflight 与错误分类。
7. 增加 mock、单元测试和至少一次真实小额冒烟。
8. 在 Provider Lab 验证参数透传。
9. 验证日志不泄露密钥。
10. 更新本文件、CHANGELOG 和项目状态文档。
## 11. 当前优先级
### P0
- 修复 Provider/Seedance 相关测试与真实策略不一致。
- 对齐运行进程与最新构建。
### P1
- 固化模型选择优先级和路由解释。
- 补齐素材 URL preflight。
- 清理历史 running/failed 日志和任务积压。
- 补齐队列执行映射与任务命名。
### P2
- 将 AI Router 扩展为可选的平台统一入口。
- 建立 Provider 契约测试和录制回放测试。
- 统一成本币种和财务口径。
docs/work-sync/06_数据库/DATABASE_CURRENT_V1.md
+260
View File
@@ -0,0 +1,260 @@
# 数据库现状与维护规范 V1
> 文档状态：当前有效
> 基线日期：2026-07-15
> 唯一结构真相：`backend/prisma/schema.prisma` 与 `backend/prisma/migrations/`。
## 1. 当前事实
- 数据库：MySQL。
- ORM：Prisma 6。
- Model：69 个。
- Prisma Enum：0 个。
- 已部署迁移：40 个。
- 迁移状态：审计时全部已部署。
- 状态字段主要是字符串，存在历史值漂移风险。
本文只解释领域结构和维护规则，不复制所有字段。字段、索引、默认值和约束以 Prisma schema 为准。
## 2. 领域分组
### 2.1 用户、项目与偏好
- `User`
- `UserModelPreference`
- `Project`
- `ProjectPipelineConfig`
- `ProjectCreativePattern`
- `CreativePattern`
### 2.2 小说与 Agent
- `NovelSource`
- `NovelChapter`
- `NovelReadingProgress`
- `NovelBookmark`
- `NovelAnnotation`
- `NovelGenerationPlan`
- `NovelChapterVersion`
- `NovelContextMemory`
- `NovelQualityReport`
- `NovelVersionSnapshot`
- `NovelDerivativeJob`
- `AgentPrompt`
- `AgentRun`
### 2.3 故事、世界观与版权
- `CopyrightRecord`
- `StoryBible`
- `WorldBible`
### 2.4 角色与 IP 资产
- `Character`
- `StoryCharacter`
- `CharacterExtractionVersion`
- `GlobalCharacter`
- `GlobalCharacterAsset`
- `CharacterProviderBinding`
- `GlobalCharacterLookVersion`
- `CharacterImage`
- `CharacterImageQualityReview`
- `CharacterMemory`
- `CharacterDesignVersion`
- `CharacterPromptVersion`
- `CharacterPromptReview`
- `CharacterPromptOptimizationLesson`
- `CharacterState`
- `ActorProfile`
- `ProjectVisualAsset`
### 2.5 剧集与媒体生产
- `Episode`
- `EpisodeScript`
- `StoryboardShot`
- `ShotGenerationPlan`
- `ShotImage`
- `VideoClip`
- `PlotMemory`
- `PlotThread`
- `ContinuityCheck`
### 2.6 素材、任务与 Provider
- `Asset`
- `RenderTask`
- `ProviderConfig`
- `ModelCapabilityVersion`
- `ModelParameterSchemaVersion`
- `ModelPricingVersion`
- `ProviderLog`
### 2.7 计费、审核与运营
- `Order`
- `QuotaAccount`
- `QuotaLog`
- `RevisionRequest`
- `ContentReview`
- `CaseShowcase`
- `HitAnalysisCase`
- `HitAnalysisSegment`
- `AnalyticsEvent`
- `SystemConfig`
- `OperationLog`
### 2.8 S+ 生产合同
- `ProductionSourceSnapshot`
- `ProductionContract`
- `ProductionContractReview`
`Project.engine_version` 隔离历史写路径与 `splus_v1` 新内核；`Project.production_lifecycle` 记录当前生产阶段。数据库默认值保持 `legacy_v1 / legacy_snapshot`，避免迁移把历史项目误标为新项目；应用层只为普通新项目明确写入 `splus_v1`。
## 3. 关键关系
```text
User
└── Project
├── NovelSource -> NovelChapter -> ChapterVersion/Quality/Memory
├── StoryBible / WorldBible
├── Character / ProjectVisualAsset
├── Episode -> EpisodeScript -> StoryboardShot
│ ├── ShotGenerationPlan
│ ├── ShotImage
│ └── VideoClip
├── Asset
├── RenderTask
└── ProductionSourceSnapshot
└── ProductionContract -> ProductionContractReview
ProviderConfig -> ModelCapabilityVersion/ModelParameterSchemaVersion/ModelPricingVersion
ShotGenerationPlan -> 三类不可变模型注册表版本 -> ShotImage/VideoClip/RenderTask
ProviderConfig -> ProviderLog -> Asset/业务对象
GlobalCharacter -> LookVersion/Asset/CharacterProviderBinding -> Project Character/ActorProfile
```
全局角色与项目角色不是同一层：全局角色用于复用演员母版，项目角色承载本项目身份、服装、状态和授权范围。
生产合同按类型、范围和版本追加写入；已确认版本不原地覆盖。来源快照保存正文与哈希，合同保存父版本、输入哈希、来源引用、质量结果和下游放行状态。
`ProviderConfig` 是允许运营调整的工作配置，不作为历史执行凭证。每次 S+ 镜头冻结前，系统按规范化内容哈希发布或复用三类不可变注册表版本，并把版本 ID 和内容快照写入 `ShotGenerationPlan`。能力、参数 Schema 或价格发生变化时创建下一修订，不更新旧修订。
`CharacterProviderBinding` 保存平台角色与供应商长期角色资产之间的真实绑定。当前字段覆盖供应商与元素 ID、元素类型、源视频、外观版本、声线、质检分、审批状态、主版本和绑定修订。正式生成只读取 `approved` 绑定；镜头冻结后，所用元素 ID 会复制进入 `ShotGenerationPlan.element_plan_json`，后续修改角色主元素不会污染旧计划。
## 4. 数据快照
审计时主要数据量：
| 数据 | 数量 |
| --- | ---: |
| 用户 | 2 |
| 项目 | 20 |
| 小说源 | 10 |
| 小说章节 | 256 |
| 故事圣经 | 13 |
| 项目角色 | 87 |
| 全局角色 | 14 |
| 分集 | 87 |
| 单集剧本 | 21 |
| 分镜 | 114 |
| 素材 | 977 |
| 任务 | 748 |
| Provider 配置 | 114 |
| Provider 调用日志 | 1002 |
| 模型能力版本 | 156 |
| 参数 Schema 版本 | 156 |
| 价格版本 | 114 |
| 角色供应商绑定 | 0 |
| 内容审核记录 | 0 |
| 操作审计记录 | 44 |
该表是 2026-07-15 快照，不应作为实时运营数据使用。实时数量应从数据库只读查询或管理后台获得。
## 5. 状态治理
当前 Prisma 没有数据库 Enum，状态由字符串常量和业务代码约束。已发现 `RenderTask` 中存在历史 `completed`，而当前代码使用 `success`。
后续要求：
1. 每个业务域建立唯一状态字典。
2. API 入参、Service、前端展示和 Worker 共用同一组状态语义。
3. 删除状态前先提供兼容读取和数据迁移。
4. 未知历史状态必须显示为“需迁移”，不能静默当成功或失败。
5. 新状态需更新数据库文档、API 契约和测试。
## 6. JSON 字段规则
JSON 适合保存：
- Provider 原始参数和归一结果。
- Prompt、质量报告和调用快照。
- 非核心扩展元数据。
以下信息不应只存在 JSON：
- 需要频繁筛选、排序或唯一约束的核心字段。
- 业务主状态。
- 资产、角色、分镜和 Provider 的主外键。
- 财务扣减所需的金额和流水关系。
JSON 结构发生兼容性变化时，应写入 `schema_version` 或提供读时迁移。
## 7. 迁移流程
每次 schema 变更必须遵循：
1. 说明业务目的、影响表和回滚策略。
2. 在备份或可恢复环境验证数据量和锁表风险。
3. 修改 `schema.prisma` 并生成命名清晰的迁移。
4. 审阅 SQL，禁止无意删除列、索引或生产数据。
5. 更新受影响的 DTO、Service、测试和前端类型。
6. 运行 Prisma 校验、构建和相关测试。
7. 先部署兼容代码，再执行破坏性清理。
8. 更新 `CHANGELOG.md`、本文件和状态文档。
禁止手工改生产表后不补迁移。
## 8. 备份与恢复
当前数据库和素材都在单机，备份应成对管理：
- MySQL 逻辑备份或一致性快照。
- `storage/private` 增量备份。
- schema、迁移和部署版本标识。
- 备份校验和、保留期和异地副本。
恢复演练必须验证：
1. 数据库可恢复并通过迁移检查。
2. `Asset.storage_key` 对应文件存在。
3. 视频可 Range 播放，图片和音频可下载。
4. RenderTask、ProviderLog 和业务资产关系没有断链。
5. 用户权限和密钥配置不从文档包恢复。
## 9. 隐私与敏感信息
- Work 只上传模型名称、表名、字段职责和聚合统计。
- 不上传用户邮箱、手机号、JWT、API Key、密码哈希或私有素材 URL。
- Provider 原始响应进入日志前需屏蔽鉴权头和签名参数。
- 删除用户或项目时，必须明确数据库记录、素材对象和外部任务的处理策略。
## 10. 当前问题
1. 状态字段自由字符串较多。
2. `completed` 等历史状态未迁移。
3. 本地素材和数据库缺少已验证的成套恢复流程。
4. `ContentReview` 为 0 条，需要确认正式审核是否绕过该模型。
5. 成本字段存在历史币种/口径差异。
6. 69 个 Model 尚无自动生成的数据字典和关系图。
## 11. 下一阶段
- 建立状态字典和历史状态迁移。
- 增加数据库与素材每日备份脚本及恢复演练记录。
- 增加注册表待发布差异预览、管理员确认和回滚到旧修订的操作审计。
- 从 Prisma 自动生成不含敏感值的数据字典。
- 为核心关系增加删除策略和孤儿资产检查。
- 统一 Provider 成本币种、精度和财务流水口径。
docs/work-sync/07_版本记录/CHANGELOG.md
+364
View File
@@ -0,0 +1,364 @@
# Work 同步变更记录
本文件只追加已实现、已验证或明确改变状态的事项。未来设想写入 `FEATURE_*.md`，不要混入变更记录。
## [WORK_SYNC_2026-07-19_V11] - 2026-07-19
### 新增
- 新增 `S_PLUS_PRODUCTION_FLOW_AUDIT_V1.md`，按当前代码、数据库和项目 #22 审计从原著到成片的真实流程风险。
- 新增 `S_PLUS_BATCH_AUTOMATED_PRODUCTION_PIPELINE_V2.md`，作为新建 S+ 项目的唯一目标生产流程。
- 目标流程统一为真人剧组逻辑：开发、前期、生产、后期，对用户呈现十步制作流程。
- 明确短篇完整故事、长篇连载小说和现成分集剧本三种入口，不再强迫所有内容走同一编剧顺序。
- 明确制作拆解、资产与导演双轨、场景地理、风险分级、G0-G7 质量门、任务 DAG、预算和局部失效策略。
### 决策
- 批量生产采用异常驱动人工介入；低风险镜头可自动通过，高风险镜头必须人工批准。
- Generation Plan 拆分为可修订 Intent Plan 和关键帧批准后冻结的不可变 Execution Plan。
- 视频生成只创建候选；未通过 QC、未批准或被拒绝的素材不得进入活动指针、合并或发布。
- 项目 #22 保留为回归样本，不再作为新流程结构的母版。
### 状态说明
- 本批次只完成流程审计和目标规范，没有修改数据库、生产服务或付费 Provider 调用。
- V2 流程标记为目标规范，代码需按 P0-P5 分阶段实现和验收。
## [WORK_SYNC_2026-07-16_V2] - 2026-07-16
### 新增
- 新增确认资产计划到 `Episode` / `EpisodeScript` / `StoryboardShot` 的 S+ 执行桥接。
- 支持在外部生成角色三视图的情况下，先落地导演分镜草案。
- 新增外部资产占位状态 `external_assets_pending`。
### 保护
- 草案只能引用资产计划内的 `REQ_*` 逻辑编号。
- 素材未导入前不编译 Provider Prompt，不冻结 Generation Plan，不触发付费生成。
- 已有确认分镜或冻结计划后禁止覆盖。
### 验证
- 项目 #22 已落地第1集 9 镜，总时长 60 秒，全部等待外部资产。
- Production Kernel 定向测试 24/24 通过。
- Backend 与 User App 生产构建通过，后端健康检查通过。
- 未调用付费 AI Provider。
## [WORK_SYNC_2026-07-15_V1] - 2026-07-15
### 新增
- 建立 AI 内容生产平台首个 Work 同步包。
- 生成项目真实状态快照 `PROJECT_STATUS_V1.md`。
- 生成当前架构、小说引擎、短剧引擎、AI 流水线和数据库文档。
- 纳入 AI 视频生产经验快照。
- 建立同步协议、文档模板、历史设计隔离说明和文件校验清单。
### 当前确认
- 全仓生产构建通过。
- Prisma 33 个迁移全部已部署。
- backend、worker、MySQL、Redis、Nginx 正在运行。
- 后端测试 273 条中 238 通过、35 失败。
- 当前运行进程尚未加载审计期间的最新构建。
- Git 只有初始提交，当前现实代码尚未形成可靠版本基线。
### 风险
- 数据库和本地私有素材缺少已验证恢复流程。
- 队列任务目录与实际 Worker 执行覆盖不一致。
- Provider 路由、状态字符串和成本口径需要统一。
- 用户端、管理端和若干 Service 文件过大。
## [WORK_SYNC_2026-07-15_V2] - 2026-07-15
### 新增
- 部署 S+ Phase 2“原著分析 -> 改编圣经 -> 分集计划”结构化写路径。
- 新增不可变来源快照、版本化生产合同和 Reviewer 记录。
- 新增三个阶段 Prompt、确定性硬门、三集连续性检查和人工单集放行。
- 用户端新增 S+ 生产工作台；付费阶段生成入口暂不开放。
### 变更
- 普通新项目默认使用 `splus_v1`；原有 20 个项目全部保留为 `legacy_v1`。
- 新项目不再使用旧 StoryBible/旧 Episode 写入口；后端同步增加隔离守卫。
- 单次原著分析限制为最多 20 个连续章节、180,000 字。
### 数据库
- 迁移：`20260715143000_splus_production_contracts_v1`。
- Prisma Model 从 61 个增加到 64 个，迁移从 33 个增加到 34 个。
- 新表当前为空，没有自动迁移或改写历史内容。
### 验证
- Phase 2 定向测试：13/13 通过。
- 后端生产构建：通过。
- 用户端生产构建：通过。
- Prisma schema 校验与迁移：通过。
- 后端健康检查：`ok`。
- 全量后端测试：254 通过、34 失败；失败数未扩大。
### 风险/回滚
- 工程链路已部署，真实新项目连续三集内容验收尚未执行。
- 进入 Phase 3 前必须只放行一个通过三集连续性检查的分集计划。
- Phase 0 数据库与私有素材备份继续作为本次回滚基线。
## [WORK_SYNC_2026-07-15_V3] - 2026-07-15
### 新增
- 新增镜头级不可变 `ShotGenerationPlan`，以内容哈希和修订号保存 S+ 执行计划。
- 新增生成计划冻结、查询、快照与定向规则测试。
- 关键帧、参考资产、角色元素、逐角色音色、视频请求、QC、重试、回退和成本审计共同读取同一计划。
### 变更
- S+ 视频队列不能被普通请求静默覆盖 Provider；系统修复仅可使用冻结回退链。
- 镜头、关键帧、视频片段和渲染任务增加生成计划追踪 ID。
- 旧 `legacy_v1` 项目不强制迁移或回填计划。
### 数据库
- 迁移：`20260715223000_shot_generation_plan_v1`。
- 新增 `shot_generation_plans`；当前 Prisma 迁移共 38 个并已全部部署。
### 验证
- Generation Plan 与 AI Router 定向测试：9/9 通过。
- Backend、User App、Admin、Workers 生产构建：通过。
- 全量后端测试：265 通过、34 失败；本阶段新增测试全部通过。
- 未触发真实付费 AI 生成。
### 风险/后续
- 前端尚未提供生成计划修订差异界面。
- 模型能力、参数 Schema 和价格仍需升级为版本化注册表。
- 需要用一个全新 S+ 项目执行单镜头真实验收。
## [WORK_SYNC_2026-07-15_V4] - 2026-07-15
### 新增
- 新增不可变 `ModelCapabilityVersion`、`ModelParameterSchemaVersion` 和 `ModelPricingVersion`。
- 当前 114 个 Provider 已初始化三类首版注册表，各 114 条。
- 新增模型注册表查询、按当前 Provider 配置发布或复用修订的管理接口。
- 新增同一镜头两个 Generation Plan 修订的字段级比较接口。
- 用户端真人短剧制作台新增活动计划、历史修订、成本和分类差异视图。
### 变更
- `ShotGenerationPlan` 绑定能力、参数 Schema 和价格三个不可变版本 ID，并继续保存完整快照。
- S+ 计划冻结前按绑定 Schema 校验最终 Provider 请求；参数冲突会在付费调用前阻断。
- `ProviderConfig` 明确为可编辑工作区，不再被当作历史执行凭证。
### 数据库
- 迁移：`20260715233000_model_registry_versions_v1`。
- Prisma Model 从 64 个增加到 68 个，迁移共 39 个并已全部部署。
### 验证
- Backend、User App、Admin、Workers 生产构建：通过。
- 模型注册表与计划修订定向测试：6/6 通过。
- 全量后端测试：269 通过、34 失败；失败数与上一基线一致。
- Backend 与 Worker 受控重启后均为 `active`，后端健康检查返回 `ok`。
- 未触发真实付费 AI 生成。
### 风险/后续
- 仍需用一个全新 S+ 单镜头核对计划、ProviderLog、QC 和真实账单。
- 注册表待发布差异、管理员确认和回滚审计尚未进入后台。
- 角色主资产到 Kling `element_id` 的供应商绑定和正式校验仍待完成。
## [WORK_SYNC_2026-07-15_V5] - 2026-07-15
### 新增
- 新增 `CharacterProviderBinding`，保存全局角色到 Kling 视频角色元素、多图元素和绑定声线的真实供应商映射。
- 新增8秒、1080P、16:9角色元素源视频入口，以及元素 ID 导入、90分质检审批和主版本管理页面。
- Generation Plan 冻结元素绑定；Kling Omni 正式请求同时提交真实 `element_list` 和顺序一致的 `<<<element_n>>>` Prompt 引用。
- S+ Kling Omni 镜头新增角色元素硬门，任一出场角色缺少已审批元素即在付费调用前阻断。
### 变更
- 新生产画幅统一为16:9；视频1920×1080、关键帧2560×1440、原生4K 3840×2160。
- 42个图片/视频 Provider 的 `production_aspect_ratio` 和允许画幅统一为16:9。
- Omni 无参考视频时按图片与元素合计最多7个动态分配图片输入，不再固定浪费参考位。
- 历史项目、素材和已冻结计划不原地改写；重新生成须冻结新的横屏修订。
### 数据库
- 迁移：`20260716003000_landscape_character_elements_v1`。
- Prisma Model 由68个增加到69个，迁移由39个增加到40个并已部署。
- 模型能力版本与参数 Schema 版本分别由114条增加到156条；价格未变化，仍为114条。
### 验证
- Prisma schema 校验与迁移：通过。
- Backend、User App 生产构建：通过。
- Generation Plan 与 Model Registry 定向测试：6/6通过。
- Prompt Builder 定向测试：7/7通过。
- 全量 Backend 测试：269通过、34失败，失败数未扩大。
- Backend 与 Worker 已受控重启并保持 `active`，后端健康检查返回 `ok`。
- 未触发真实付费生成；真实 Kling 元素创建、单镜头和账单对账待验收。
### 风险/后续
- Kling 官方公开资料目前只确认网页/App元素库创建流程；平台暂不实现未经验证的自动创建元素 API。
- LiveAction 历史测试仍有19条失败，主要是旧 Prisma mock 与既有导演策略断言漂移，需要单独清债。
- 当前角色供应商绑定表为0条，需要用首个真实元素完成端到端验收。
## [WORK_SYNC_2026-07-16_V6] - 2026-07-16
### 新增
- 使用全新 S+ 项目“诸葛亮与司马懿斗法”执行首批人物三视图真实 Provider 验收。
- 图片生成支持显式 `reference_asset_ids`，任务能够审计本轮实际参考来源。
- 新增 `reference_crop_mode=turnaround_face_panel`，可临时提取三视图左侧身份面板，不修改原始素材。
- 新增跨视图身份漂移、错误视图几何和现代鞋履的确定性视觉硬门。
### 变更
- 公共人物三视图模板升级为 `character_turnaround_public_v3_s_plus`，身份母版默认空手并强化年龄、鞋履和视图一致性。
- 三视图不再被错误自动晋升为角色主锚点，只有真实 `anchor` 类型图片可参与自动主锚点选择。
- 98分且参考模式一致的可信 Prompt 可复用，避免每轮视觉经验变化都重复执行多轮昂贵审稿。
- Prompt 审稿输入不再把独立负面约束作为待审正文，减少错误污染判定。
### 真实验收
- 共得到 #978、#979、#980、#981、#982、#983 六张候选；当前最佳为素材 #980，视觉分87。
- 所有候选均未达到 S+，没有标记 approved，也没有晋升角色主锚点。
- Seedream 5.0 整板递归、GPT Image 2 A/B 和身份面板裁切均未解决跨视图服装与鞋履拓扑漂移。
- 停止继续单画布递归，下一阶段采用“身份、正面、严格侧面、背面分别生成与质检，再程序化合成”的路线。
### 成本
- ProviderLog #1010-#1038 合计 $3.1663。
- TextProvider 审稿与视觉质检 $2.9753，ImageProvider $0.1910；文本相关成本约为图片成本的15.6倍。
### 验证
- ImagesService 定向测试：16/16通过。
- Backend 生产构建：通过。
- User App 生产构建：通过。
### 风险/后续
- 当前最高视觉分只有87，不能作为视频角色元素的 S+ 身份母版。
- 分面板生成、逐面板状态持久化、跨面板拓扑检查和确定性合成尚未实现。
- RenderTask 成功成本当前主要反映图片调用，完整生产成本仍应以 ProviderLog 汇总为准，后续需统一审计口径。
## [WORK_SYNC_2026-07-16_V7] - 2026-07-16
### 变更
- 公共人物三视图模板升级为 `character_turnaround_original_v4_s_plus`，以原创虚构数字角色和最高原生质量替代冲突的真人肖像限制与提示词式 8K 声明。
- 三视图负面约束压缩为六组，并新增非人、多头、多臂角色结构分支。
- 旧 V3 Prompt 即使已有 98 分也不能直接复用；活动 Prompt 必须同时满足当前版本、旗舰版式、参考模式和零冲突词。
- 历史高分经验增加画幅、角色名、专属道具、物种、时代和服装适用性过滤；新 reusable rules 写库前使用同一硬门。
- Asset Planner 身份母版示例改为原创虚构角色资产，历史候选不得污染新资产描述。
- Project #22 的蜀军将领和九幽鬼将角色描述去除跨角色点名。
- 网页复制包的通用角色负面模板移除五条压低脸部清晰度的冲突限制，并过滤旧角色描述的同类回流；明确隐藏脸的 Seedance 安全首帧分支保持隔离。
- 人物三视图固定工业版式由泛化“横版”收紧为显式 16:9 横版单一连续画布。
- 主锚点、表情锚点、服装锚点、三视图及平台复制文案统一移除提示词式 8K 声明；旧角色 Prompt 提交前自动改写为最高原生质量与后续 4K 放大准备。
### 验证
- 三视图、CharactersService、ImagesService、Production Kernel、资产计划 Prompt 与旧行为保护定向测试：60/60 通过。
- Backend 生产构建：通过。
- 四个橙色角色 V4 Prompt 预检：全部 16:9、当前版本、零冲突、无人名串线。
- 未触发真实付费 AI 生成。
### 风险/后续
- Prompt 收口不等于单画布三视图已经达到 S+；历史最佳视觉分仍为 87。
- 下一阶段继续执行分面板生成、分别质检、程序化合成和 96+ 总质检。
## [WORK_SYNC_2026-07-16_V8] - 2026-07-16
### 新增
- 用户端与管理端新增共享的全局 AI 请求参数检查器，默认收起并通过右侧抽屉查看。
- 统一展示路径参数、查询参数、明文请求体、Request ID 和请求状态。
- 请求预览/预检完整展示后端响应；正式生成提取 Task、Generation Plan、Provider 路由与成本证据。
- 新增敏感字段、Base64 与二进制摘要保护，以及最近 30 条会话历史、复制和清空能力。
### 验证
- AI 请求匹配、误捕获保护、参数快照、脱敏和预览证据测试：36/36 通过。
- User App 与 Admin 生产构建：通过，Nginx 已提供新构建资源。
- Backend 健康检查：`ok`。
- 未触发付费 AI 调用。
### 风险/后续
- 旧同步接口若不返回 Task、Generation Plan 或请求预览，只能保证展示页面提交事实；最终 Provider 载荷需后端统一 Trace 才能完整覆盖。
## [WORK_SYNC_2026-07-16_V9] - 2026-07-16
### 新增
- 实现人物身份特写、严格正面、严格90度右向侧面、严格180度背面独立生成与独立质检。
- 新增 FFmpeg 确定性 4K 四面板母版合成，避免最后一步重新绘制导致换脸。
- 新增断点续跑和 `regenerate_image_types` 指定面板返修；用户端提供“只重生此面板”。
- 新增诸葛亮真实小样 #984-#988 与实施验收报告。
### 变更
- 公共拆分面板模板升级为 `character_turnaround_split_panel_v1_1`，强化时代鞋履、年龄、手部、侧面几何和背面服装拓扑。
- 面板视觉质检输出上限由 2600 提高到 5000 tokens。
- 执行回执成本拆分为图片、视觉质检、本地合成和总成本，并补充质检 ProviderLog ID。
- 视觉质检以落盘尺寸元数据为权威，禁止将 3840x2160 留白资产误判为非 16:9。
### 修复
- 修复“严格90度右向侧面”被本地 Prompt 契约错误拦截。
- 修复质检 Provider 失败覆盖上一轮有效图片分数与状态的问题。
- 修复正面质检 JSON 因 token 上限过低被截断的问题输入配置。
### 真实验收
- 身份 #984 为91分，侧面 #986 为88分，背面 #987 为89分，母版 #988 为 A+ 88分。
- 严格侧面和严格背面成立；母版因现代白色橡胶鞋底命中一票否决，未晋升 S+ 或主锚点。
- 4张4K图片成本 $1.7386，5次成功视觉质检 $0.4652，本地合成 $0，总计 $2.2038。
- 补跑旧图质检遇到 OpenAI 429，两次失败调用成本为0，未继续发起付费生成。
### 验证
- 相关后端测试：29/29通过。
- Backend 与 User App 生产构建：通过。
### 风险/后续
- 当前账户配额阻断进一步付费质检与返修。
- 配额恢复后只返修未通过全身面板；四个面板和母版均达到96+且无一票否决，才可晋升视频身份母版。
## 追加模板
```markdown
## [WORK_SYNC_YYYY-MM-DD_Vn] - YYYY-MM-DD
### 新增
- ...
### 变更
- ...
### 修复
- ...
### 数据库
- 迁移：...
### 验证
- 构建：...
- 测试：...
- 冒烟：...
### 风险/回滚
- ...
```
docs/work-sync/08_维护规范/DOCUMENT_TEMPLATE.md
+83
View File
@@ -0,0 +1,83 @@
# Work 文档模板 V1
## 1. 当前设计文档模板
```markdown
# <领域/系统名称> V1
> 文档状态：当前有效 / 待实现 / 部分实现 / 待验证
> 基线日期：YYYY-MM-DD
> 事实来源：代码路径、迁移、状态快照
## 1. 目标
## 2. 非目标
## 3. 当前能力
## 4. 核心对象
## 5. 主流程
## 6. 业务规则
## 7. 数据/API/队列影响
## 8. 安全与成本
## 9. 当前差距
## 10. 不可破坏规则
## 11. 下一阶段
## 12. 更新触发条件
```
## 2. FEATURE 模板
```markdown
# FEATURE_<名称>_V1
> 状态：讨论中 / 已确认 / 实现中 / 已验证 / 已取消
> 关联基线：WORK_SYNC_...
> 负责人：
## 背景与问题
## 目标
## 非目标
## 用户流程
## 业务规则
## 方案
## 替代方案
## 数据库影响
## API/队列/Provider 影响
## UI 状态
## 安全、隐私与成本
## 兼容与迁移
## 验收标准
## 发布与回滚
## 未决问题
```
## 3. ADR 模板
```markdown
# ADR_0001_<主题>
> 状态：提议 / 接受 / 废弃 / 被替代
> 日期：YYYY-MM-DD
## 背景
## 决策
## 替代方案
## 正面影响
## 负面影响
## 迁移与回滚
## 验证方式
```
## 4. 状态快照要求
状态快照必须包含：
- 审计时间、对象和口径。
- 当前架构和真实运行配置。
- 已实现、部分实现和仅设计能力。
- 数据库、API、队列和 Provider 统计。
- 构建、测试和服务验证。
- Git、备份、部署和安全风险。
- 与上一版状态快照的差异。
- 明确列出未执行的验证。
禁止包含任何凭据或用户明细。
docs/work-sync/08_维护规范/WORK_SYNC_PROTOCOL.md
+133
View File
@@ -0,0 +1,133 @@
# Work 与代码同步协议 V1
> 目标：让 Work 的设计世界持续认识 Git + Codex 的代码现实，同时避免把源码和敏感信息塞进知识库。
## 1. 权责划分
### Work 负责
- 产品定位和业务规则。
- 新功能讨论、替代方案和优先级。
- 跨模块架构决策。
- 用户体验、质量标准和未来路线。
- 形成 `FEATURE_*.md`、ADR 和验收口径。
### Git + Codex 负责
- 当前源码和数据库迁移。
- 实现细节和接口事实。
- 自动测试、构建和部署状态。
- 当前生产配置与运行验证。
- 生成状态快照和同步包。
## 2. 文档层级
```text
L0 PROJECT_STATUS：不可变事实快照
L1 SYSTEM/ENGINE/PIPELINE/DATABASE：当前有效设计
L2 FEATURE/ADR：未来设计和决策
L3 CHANGELOG：已发生变化
L4 历史设计/讨论记录：仅供追溯
```
L2 不能在代码完成前冒充 L1；L4 不能覆盖 L0。
## 3. 标准闭环
```mermaid
flowchart LR
Idea[想法] --> Work[Work 讨论]
Work --> Feature[FEATURE/ADR]
Feature --> Codex[Codex 实现]
Codex --> Verify[测试/构建/部署验证]
Verify --> Change[更新 CHANGELOG]
Change --> Domain[更新领域文档]
Domain --> Status[必要时生成新状态快照]
Status --> Upload[上传同步包]
```
## 4. 何时更新哪些文档
| 变化 | 必须更新 |
| --- | --- |
| 小缺陷修复，不改变契约 | CHANGELOG |
| API、状态或领域规则变化 | CHANGELOG + 对应领域文档 |
| 新功能设计、尚未实现 | 新建 FEATURE 文档 |
| 跨模块技术决策 | 新建 ADR |
| Prisma schema 变化 | DATABASE + CHANGELOG + 迁移 |
| Provider/队列/Prompt 机制变化 | AI_PIPELINE + CHANGELOG |
| 小说生产逻辑变化 | NOVEL_ENGINE + CHANGELOG |
| 短剧/视频/合成逻辑变化 | DRAMA_ENGINE + CHANGELOG |
| 架构、部署、测试或风险显著变化 | 新建 PROJECT_STATUS_Vn |
## 5. 版本规则
- 状态快照：`PROJECT_STATUS_V1.md`、`V2.md`，发布后不可改写事实。
- 当前设计：结构性改变升 V2；旧版本移入历史区或保留只读。
- FEATURE/ADR：决策变化升版本，不覆盖已评审版本。
- CHANGELOG：只追加，不回写历史结论；错误修正新增一条说明。
- 同步批次：`WORK_SYNC_YYYY-MM-DD_Vn`。
## 6. 上传前检查
1. 文件只包含当前项目必要信息。
2. 没有 `.env` 值、API Key、JWT、密码、签名 URL 和个人数据。
3. 状态、数量和测试结果标注采集日期。
4. “已实现”“部分实现”“待实现”区分清楚。
5. 文档中的模型、路由和队列说法与源码一致。
6. 所有文件列入 `SYNC_MANIFEST.md` 并生成 SHA-256。
7. `CHANGELOG.md` 已追加本批次。
8. 上传后在 Work 标记批次号和生效日期。
## 7. Work 讨论新功能的输入模板
```markdown
当前基线：WORK_SYNC_YYYY-MM-DD_Vn
关联现状：PROJECT_STATUS_Vn
关联领域：<领域文档>
目标：
非目标：
业务规则：
现有约束：
预期用户流程：
数据影响：
API/队列/Provider 影响：
成本与安全：
验收标准：
回滚条件：
```
## 8. 交给 Codex 的实现包
Work 讨论结束后，交付内容应至少包括：
- 已确认的 FEATURE/ADR 文件。
- 关联的当前状态和领域文档版本。
- 明确的验收标准。
- 不允许改变的现有行为。
- 是否允许数据库迁移、付费调用和生产重启。
不要只复制一段没有上下文的聊天结论。
## 9. 冲突处理
### 文档与代码冲突
先审计源码、迁移和运行状态；确认代码现实后更新状态快照。若代码本身是错误实现，再通过 FEATURE/修复任务改变代码，不能为了让文档“看起来一致”而掩盖差异。
### Work 与最新设计冲突
保留两个方案，形成 ADR，记录为什么更改。未经确认的 Work 建议不得直接覆盖当前有效文档。
### 数据与文档冲突
实时业务数量以数据库只读查询为准；文档快照必须标注日期。
## 10. 建议节奏
- 每个已上线功能：立即追加 CHANGELOG。
- 每周或每个开发批次：更新受影响领域文档。
- 每次结构性发布：生成新状态快照和同步清单。
- 每月至少一次：检查备份、状态漂移、失败任务和敏感信息。
docs/work-sync/99_历史设计/README.md
+42
View File
@@ -0,0 +1,42 @@
# 历史设计使用说明
`docs/system_a/`、`docs/system_b/`、根目录旧架构文档和早期进度记录保留了项目演进过程，但不能直接代表当前实现。
## 1. 默认不上传全量历史文档
原因：
- 旧文档假定用户端是 uni-app，当前实际为 Vue 3 H5。
- 旧文档假定管理端采用 GeekerAdmin，当前实际是自研单页后台。
- 旧数据库、Provider、队列和视频能力与当前代码差异明显。
- 同一能力可能在系统 A/B 中重复定义，容易让 Work 得出相互冲突的结论。
## 2. 可按需查阅的历史资料
| 历史资料 | 适合回答 | 使用条件 |
| --- | --- | --- |
| `docs/system_a/` | 小说、漫剧和早期平台业务设想 | 必须与当前状态文档对照 |
| `docs/system_b/` | 真人动态视频的早期需求与合并思路 | 不得推断已全部实现 |
| `CURRENT_ARCHITECTURE.md` | 某阶段架构演进 | 先核对日期和源码 |
| `NOVEL_IP_SYSTEM_DESIGN.md` | 小说/IP 资产设计来源 | 只采纳未过时的规则 |
| `CODEX_PROGRESS.md` | 开发过程和阶段记录 | 不作为验收结果 |
| `AI_VIDEO_TEST_LESSONS.md` | 视频生产经验 | 已复制版本化快照到同步包 |
## 3. 上传历史文档的格式
如 Work 需要某份旧文档，应在文件顶部增加外部说明或上传备注：
```text
状态：历史参考
不代表当前实现
当前基线：WORK_SYNC_2026-07-15_V1
需要对照：PROJECT_STATUS_V1.md
讨论目的：<为什么需要这份旧文档>
```
不要直接修改原历史文件来伪装成当前设计；有价值的结论应提炼到新的 FEATURE、ADR 或当前领域文档。
## 4. 何时归档当前文档
当前领域文档升级版本后，旧版移入此区的对应子目录，并在新文档和 CHANGELOG 中说明替代关系。状态快照不移除，持续保留 V1、V2、V3。
docs/work-sync/AI_REQUEST_INSPECTOR_IMPLEMENTATION_REPORT_V1.md
+69
View File
@@ -0,0 +1,69 @@
# AI 请求参数检查器实施报告 V1
> 实施日期：2026-07-16
> 状态：用户端与管理端已上线，后端统一 Provider Trace 待后续增强
> 目标：让所有 AI 生成、审核、质检、预检与合成入口具备可追溯的页面参数视图。
## 1. 用户入口
登录用户端或管理端后，页面右侧固定显示“AI 请求参数”入口。面板默认关闭，点击后从右侧滑出；移动端改为全屏抽屉并保留横向请求历史。两端复用同一个共享组件和同一套路由规则，避免实现漂移。
抽屉支持：
- 最近 30 条会话级请求历史。
- 请求状态、HTTP 方法、接口路径、时间与 Request ID。
- 完整 `path_params`、`query_params` 与明文 `body`。
- 请求预览/预检的完整后端响应。
- 正式生成返回的 `task.input_json`、Generation Plan、Provider 路由、最终请求与成本证据。
- 一键复制与清空历史。
## 2. 捕获位置
检查器接入 `UserApiClient.request()` 与管理端 `ApiClient.request()`，在应用层加密之前复制一份仅用于诊断的安全快照，因此可以看到页面实际提交的可读参数，又不会改变原请求。
当前动作级白名单覆盖：
- Provider Lab 与提示词直出。
- 原著分析、改编圣经、角色/场景/道具提取与 Prompt 优化。
- 分集、场景剧本、分镜及其请求预览。
- 人物图片、人物三视图、角色元素测试与视觉质检。
- 关键帧、语音、单句 TTS 重试、字幕、音乐与视频生成。
- 视频预检、成本估算、自动 QC、重试与成片合成。
- 管理端 Provider 实测、小说方案/IP圣经/章节任务与爆款案例 AI 分析。
普通项目保存、人工审核、素材绑定、候选选择和确认操作不进入历史，避免诊断面板被非 AI 写请求污染。
## 3. 数据安全
- `password`、Authorization、API Key、Token、Secret 自动隐藏。
- Base64 与二进制正文不写入面板，只保留文件名、MIME、字节数或字符数摘要。
- 历史仅写入浏览器 `sessionStorage`，最多 30 条，不进入业务数据库。
- 检查器故障或浏览器存储已满时，不得阻断真实生成。
## 4. 两层事实边界
### 页面提交事实
始终记录前端实际送入 API 的路径参数、查询参数和请求体。这一层适合检查漏参、错参、Provider 选择与人工覆盖值。
### 后端执行事实
后端返回请求预览、Task、Generation Plan、Provider 路由或成本信息时，检查器同步展示。这一层适合检查 Prompt 编译、参考图、模型参数、回退与成本。
若旧接口没有返回执行证据，面板会明确显示“尚未返回”，不会把前端请求体伪装成最终 Provider 载荷。后续如需覆盖所有同步旧接口，应增加统一的后端 Provider Trace，而不是在前端猜测。
## 5. 验证
- `ai-request-inspector.spec.ts`：36/36 通过。
- User App 与 Admin TypeScript、Vite 生产构建：通过。
- `git diff --check`：通过。
- Nginx 已提供本次新构建静态资源。
- Backend 健康检查：`ok`。
- 本次验证未触发任何付费 AI 调用。
## 6. 后续
1. 在后端统一 Provider 执行层增加脱敏 Trace ID 与最终载荷摘要。
2. 让同步旧接口也能通过 Request ID 查询 Provider Trace。
3. 将请求记录与不可变 Generation Plan、ProviderLog 和成品 QC 建立可点击关联。
4. 按真实漏项继续维护动作级白名单，普通保存和人工操作必须保留误捕获测试。
docs/work-sync/KLING_S_PLUS_MODEL_ROUTING_SPEC_V1.0.md
+1237
View File
File diff suppressed because it is too large Load Diff
docs/work-sync/KLING_V3_OMNI_API_UPDATE_V1.md
+59
View File
@@ -0,0 +1,59 @@
# Kling v3 Omni API 参数基线 V1
> 同步日期：2026-07-15
> 适用模型：`kling-v3-omni`
> 代码驱动：`kling_omni_video`
## 官方基线
- 创建任务：`POST /v1/videos/omni-video`
- 查询任务：`GET /v1/videos/omni-video/{task_id}`
- 鉴权：新版 API Key，`Authorization: Bearer <KLING_API_KEY>`
- 区域域名：`https://api-singapore.klingai.com`
- 清晰度：`std`=720P、`pro`=1080P、`4k`=原生 4K
- 时长：3-15 秒
- Prompt：最多 2500 字符
- 自定义多镜头：最多 6 段，每段 Prompt 最多 512 字符，各段时长总和必须等于任务总时长
## 输入限制
- 无参考视频时：`image_list` 图片数与 `element_list` 元素数合计最多 7 个。
- 有参考视频时：图片与元素合计最多 4 个。
- 参考视频最多 1 个；存在参考视频时 `sound` 必须为 `off`。
- 使用首帧/尾帧时，元素最多 3 个。
- 图片支持 JPG/JPEG/PNG，单图不超过 10MB，宽高均不低于 300px，宽高比范围 1:2.5 至 2.5:1。
- 视频支持 MP4/MOV，3-15.5 秒，最大 200MB，24-60fps。
## 平台生产画幅
- 当前平台不再生产竖屏，新冻结的 S+ Generation Plan 固定为 `16:9`。
- 1080P视频为1920×1080，原生4K为3840×2160，关键帧基线为2560×1440。
- 已冻结的历史计划和既有素材不原地改写；重新生成时必须冻结新的16:9修订。
## 视频角色元素
- Kling 元素库的视频角色元素源视频要求单一角色、3-8秒，并建议包含正面与左右轻侧角度。
- 平台默认生成8秒、1080P、16:9的中性角色身份视频；该视频只用于建立角色元素，不承载剧情表演。
- 当前未确认存在可公开调用的“创建视频角色元素”API，因此平台不伪造自动创建能力：用户在 Kling 元素库完成上传后，将真实 `element_id` 导入平台。
- 正式 Omni 请求同时提交 `element_list` 与 `<<<element_n>>>` Prompt 引用；网页端 `@元素名` 仅是人工操作语法，不代替 API 绑定。
- 无参考视频时，图片与元素总数不超过7；平台按 `可用图片数 = 7 - 已绑定元素数` 动态收紧图片输入。视频角色元素最多3个。
- S+ 镜头中每个出场角色都必须有质检分不低于90的已审批元素，否则在冻结计划前阻断付费生成。
## 平台映射
| Provider | `mode` | 官方价格 |
| --- | --- | ---: |
| `kling-v3-omni-native-audio-720p-video` | `std` | $0.112/s |
| `kling-v3-omni-native-audio-1080p-video` | `pro` | $0.14/s |
| `kling-v3-omni-native-audio-4k-video` | `4k` | $0.42/s |
三个 Provider 默认禁用。启用前必须在后台写入新版 `KLING_API_KEY`，并以单镜头小样验证账号权限、4K 可用性和实际账单。
## 官方资料
- [Kling v3 Omni API](https://kling.ai/document-api/api/video/3-0-omni/video-omni)
- [Authentication](https://kling.ai/document-api/api/get-started/authentication)
- [Billing Method](https://kling.ai/document-api/productBilling/billingMethod)
- [Kling Video 3 Omni Guide](https://kling.ai/quickstart/klingai-video-3-omni-model-user-guide)
- [Kling Element Library Guide](https://kling.ai/quickstart/klingai-element-library-3-user-guide)
- [Kling Video 3 Model Guide](https://kling.ai/quickstart/klingai-video-3-model-user-guide)
docs/work-sync/LANDSCAPE_CHARACTER_ELEMENT_IMPLEMENTATION_REPORT_V1.md
+148
View File
@@ -0,0 +1,148 @@
# 16:9 与 Kling 视频角色元素实施报告 V1
> 实施日期：2026-07-15
> 状态：工程完成，真实元素创建与付费镜头待人工验收
> 适用范围：新 S+ 图片、关键帧、视频、Generation Plan 与 Kling V3 Omni 正式请求
## 1. 本阶段目标
1. 新生产链路停止使用9:16，统一到16:9。
2. 建立可复用的视频角色元素资产与审批流程。
3. 让角色元素与关键帧、音色、视频参数、QC、成本共同冻结进不可变 Generation Plan。
4. 正式 Omni 请求提交真实供应商元素 ID，而不是只依赖角色描述词。
## 2. 16:9 生产合同
平台新增单一生产格式常量：
```text
视频：1920×1080 / 16:9 / 默认1080P
关键帧：2560×1440 / 16:9
原生4K：3840×2160 / 16:9
```
该常量已接入关键帧、真人视频、Prompt Builder、Production Contract、Provider Lab、媒体合成和用户端表单。数据库中42个 ImageProvider/VideoProvider 的 `production_aspect_ratio` 与 `allowed_aspect_ratios` 已统一为16:9。
历史素材、历史项目与已冻结 Generation Plan 不原地改写。旧镜头如需重生，应创建新的16:9计划修订，保留原执行证据。
## 3. 角色元素源视频
平台复用角色锚点视频测试执行器，新增 `video_character_element_source` 目的：
- 单一人物，3-8秒，默认8秒。
- 16:9、1080P、固定机位、浅灰中性背景、均匀正面光。
- 腰部以上入镜，正面、左侧约30度、回正、右侧约30度、回正。
- 只允许自然呼吸、眨眼与克制头部转动。
- 可输入一句中性台词以提取自然声线。
- 禁止字幕、文字、BGM、环境噪声、特效、切镜与遮脸。
生成是显式付费动作，不会因打开页面自动触发。输出保存为普通私有视频素材，并标记下一步为上传 Kling 元素库。
## 4. 供应商绑定与审批
新增 `CharacterProviderBinding`：
```text
global_character_id
look_version_id
source_asset_id
provider_code
provider_asset_type
provider_element_id
element_name / element_description
source_duration
voice_bound / voice_id / voice_description
validation_score / validation_report_json
binding_version / status / is_primary
```
约束：
- 视频元素源素材若已提供，必须是视频且时长3-8秒。
- 同一供应商元素 ID 不能绑定到两个角色。
- 质检分低于90不能标记 `approved` 或主元素。
- 正式生成只读取 `approved` 绑定。
当前公开文档没有提供已验证的“创建视频角色元素”API，因此平台不伪造自动上传能力。用户在 Kling 网页或 App 的元素库创建元素后，把真实 `element_id` 导入平台。后续若官方开放稳定接口，再单独增加自动创建执行器。
## 5. Generation Plan 与请求执行
冻结计划时，平台把以下信息写入 `element_plan_json.actor_lock.provider_elements`：
- 平台绑定 ID。
- 项目角色 ID 与全局角色 ID。
- 供应商代码、元素 ID、元素名称。
- 是否绑定声线与 voice ID。
执行时只读取这份冻结快照：
```json
{
"element_list": [
{ "element_id": "供应商真实元素ID" }
]
}
```
Prompt 同时按数组顺序写入 `<<<element_1>>>`、`<<<element_2>>>` 等引用，避免角色、台词和声线互换。网页端 `@元素名称` 不是 API 绑定，不能替代 `element_list`。
对于新 S+ Kling Omni 镜头，只要有出场角色缺少已审批元素，系统即抛出 `SPLUS_CHARACTER_ELEMENT_BINDING_REQUIRED`，在付费提交前停止。
## 6. 输入数量规则
- 无参考视频时，Omni 图片与元素合计最多7个。
- 视频角色元素最多3个。
- 平台运行时按 `最大图片数 = min(模型图片上限, 7 - 元素数量)` 动态裁剪参考图。
- 有参考视频时仍按官方更严格的4个合计上限和声音互斥规则执行。
## 7. 模型注册表
迁移后重新发布114个 Provider 的注册表：
| 注册表 | 当前数量 | 变化原因 |
| --- | ---: | --- |
| 能力版本 | 156 | 42个图片/视频 Provider 新增16:9能力修订 |
| 参数 Schema 版本 | 156 | 42个图片/视频 Provider 只允许16:9的新修订 |
| 价格版本 | 114 | 本阶段没有改价，继续复用原价格版本 |
旧注册表修订保留，旧 Generation Plan 仍可审计原参数。
## 8. 前端入口
全局角色页新增：
- 供应商模型族、元素 ID、元素名称。
- 可选源视频素材 ID。
- 声线绑定与 voice ID。
- 候选导入、质检分、审批为主元素。
项目角色页新增“生成元素源视频”。Generation Plan 详情会展示画幅、冻结元素 ID、角色名和元素名。
## 9. 验证结果
- Prisma schema：有效。
- 迁移：40/40 已部署。
- Backend 生产构建：通过。
- User App 生产构建：通过。
- Model Registry 与 Generation Plan 定向测试：6/6 通过。
- Prompt Builder 定向测试：7/7 通过。
- 全量 Backend 测试：269通过、34失败，与上一同步基线一致。
- Backend 与 Worker 受控重启后均为 `active`，健康检查返回 `ok`。
- 未触发新的付费角色源视频或正式视频生成。
LiveAction 历史测试仍有19条失败，其中多数来自旧 Prisma mock 与既有导演策略断言漂移，不是本阶段新接口的编译错误；需作为独立测试债处理。
## 10. 官方依据
- [Kling Element Library Guide](https://kling.ai/quickstart/klingai-element-library-3-user-guide)
- [Kling Video 3 Model Guide](https://kling.ai/quickstart/klingai-video-3-model-user-guide)
- [Kling Video 3 Omni Guide](https://kling.ai/quickstart/klingai-video-3-omni-model-user-guide)
- [Kling V3 Omni API](https://kling.ai/document-api/api/video/3-0-omni/video-omni)
## 11. 下一步验收
1. 选择一名已通过三视图与锚点审核的角色，生成8秒身份源视频。
2. 人工检查正侧脸一致性、服装、年龄、口型和声线。
3. 在 Kling 元素库创建视频角色元素，导入真实 ID 并完成90分门禁。
4. 用一个全新 S+ 单人物镜头冻结计划并生成候选。
5. 对照 Generation Plan、ProviderLog、Kling 任务、QC 与真实账单。
docs/work-sync/PROMPT_RULE_AUDIT_V1.md
+116
View File
@@ -0,0 +1,116 @@
# Prompt 规则去劣取优审计 V1
> 审计日期：2026-07-15
> 适用内核：`splus_v1`
> 审计基线：`S_PLUS_SHORT_DRAMA_CODEX_OPTIMIZATION_V1_1.md`
> 代码实现：`backend/src/production-kernel/prompts/prompt-rule-registry.ts`
## 1. 审计原则
历史 Prompt 是生产经验来源，不是公共模板真相。处理规则如下：
1. 历史记录和素材快照不改写、不删除。
2. 项目专名、素材编号、临时 URL 和单次返修上下文不得进入公共模板。
3. 能跨项目解释、能转换为可执行约束的经验，去除项目事实后进入候选规则。
4. 未经 A/B 证明的题材或 Provider 经验只允许处于 `testing`，不能默认激活。
5. 规则必须记录阶段、范围、激活条件、预期改善、证据和版本。
6. 公共规则之间冲突时，以来源事实、已批准改编、连续性和 Provider 可执行性为先。
## 2. 已批准保留
| 规则 ID | 提取出的有效经验 | 适用范围 | 处理结果 |
| --- | --- | --- | --- |
| `shot.performance_arc` | 表演包含起点、触发、可见反应和余韵 | 全局 / 镜头 | 保留并结构化 |
| `shot.dialogue_reaction_timing` | 对白前有准备、句尾有反应与安全余量 | 全局 / 镜头 | 保留并结构化 |
| `shot.motivated_camera` | 运镜有起点、动机、速度和落点 | 全局 / 镜头 | 保留并结构化 |
| `shot.first_last_frame_continuity` | 首尾帧同空间、光源、轴线和运动方向 | 全局 / 首尾帧 | 保留并结构化 |
| `shot.cross_space_boundary` | 跨物理空间分别建立，用可剪切点桥接 | 全局 / 镜头 | 保留并抽象 |
| `shot.scene_anchor_lock` | 连续场次锁定空间结构、光源与固定物件 | 全局 / 连续性 | 保留并结构化 |
| `shot.character_state_lock` | 身份母版与当前服装/伤势状态分工 | 全局 / 角色资产 | 保留并结构化 |
| `shot.asset_visibility_boundary` | 资产检索标签不等于必须入画 | 全局 / 资产 | 保留并结构化 |
| `shot.axis_and_screen_direction` | 连续动作记录轴线和画面方向 | 全局 / 连续性 | 保留并结构化 |
| `shot.state_handoff` | 前镜结束状态与后镜开始状态接力 | 全局 / 连续性 | 保留并结构化 |
| `shot.dialogue_integrity` | 对白保持说话人、语义、顺序和完整性 | 全局 / 对白 | 保留并结构化 |
| `shot.sound_is_story_action` | 环境声、拟音、对白和声音桥服务剧情 | 全局 / 声音 | 保留并结构化 |
| `shot.transition_responsibility` | 视频模型与后期合并层职责分离 | 全局 / 转场 | 保留并结构化 |
| `shot.suspense_sound_pressure` | 悬疑声音绑定证据、动作和心理压力 | 悬疑题材 | 保留为题材规则 |
| `shot.suspense_inner_monologue` | 内心独白只用于悬疑关键心理转折 | 悬疑题材 | 保留为题材规则 |
| `shot.ui_text_post_composite` | 精确中文 UI、进度条和字幕由后期合成 | 全局 / UI | 保留并结构化 |
| `shot.ui_reaction_placeholder` | UI 占位由构图、视线、停顿和反应构成 | 全局 / UI | 保留并结构化 |
| `shot.reference_image_responsibility` | 每张参考图分配唯一主职责和优先级 | 全局 / Provider 输入 | 保留并结构化 |
| `shot.one_primary_action` | 单片段只承担一个主要动作链或转折 | 全局 / 镜头 | 保留并结构化 |
| `shot.no_mechanical_filler` | 不为满足数量补空镜、反应或证据镜 | 全局 / 分镜规划 | 新增硬规则 |
| `episode.hook_truth_and_payoff` | 钩子来自当前冲突并在本集兑现 | 全局 / 分集 | 保留并结构化 |
| `timeline.subtitle_spoken_content_only` | 字幕只含实际语音并跟随语音时点 | 全局 / 时间线 | 保留并结构化 |
## 3. 已抽象重写
| 历史写法 | 问题 | 新写法 |
| --- | --- | --- |
| 用某酒店、宴会厅和红毯示范所有开场 | 项目场景污染公共模板 | 开场运镜由事件、情绪和空间边界决定 |
| 用具体两个人名说明对话轴线 | 角色污染 | 使用当前角色关系轴线和画面运动方向 |
| 用具体文件、礼服、胸针作为资产示例 | 道具和服装污染 | 使用当前镜头的角色状态、主场景和关键道具 |
| 所有开场都要求俯冲、快速推进 | 风格机械化 | 冲突、悬疑、庄重、悲伤等开场分别选择动势 |
| 所有跨空间镜头按“楼外到宴会厅”解释 | 单一案例过拟合 | 任何独立物理空间均分别建立并设计桥接 |
| 终局必须出现特定底牌、地点和两个名字 | 某故事终局污染分集评分 | 检查核心冲突结果、主角选择、状态变化和余波 |
## 4. 已废弃
| 行为 | 废弃原因 | 代码保护 |
| --- | --- | --- |
| `导演补拍节奏点` 自动补满镜头数 | 凭空造剧情，产生平庸填充 | `fitScriptStoryboardBeatsToCount` 与 `expandStoryboardSeeds` 不再增删剧情点 |
| 按说话人自动拆成多个对白反打镜头 | 把一场表演切成对白素材块 | `normalizeStoryboardDraftsForVideo` 保持已批准戏剧单元 |
| 用关键词命中宣称固定 `96+`、`98+` | 分数未经样本校准且可被堆词作弊 | 新内核只认硬门、版本化 Rubric、媒体 QC 和人工校准 |
| 公共模板直接出现历史人物、地点和道具 | 污染新项目 | 污染扫描器与静态回归测试阻断 |
| 生成失败经验自动追加到公共 Prompt | 单次事故可能是素材或 Provider 原因 | 只进入 `PromptRuleCandidateV1`，审核/A-B 后晋升 |
## 5. 待验证候选
以下经验可能有价值，但证据不足，暂不默认激活：
| 候选 | 需要验证的问题 |
| --- | --- |
| 近景/特写占比约 80% | 不同题材、动作密度和平台是否同样适用 |
| 开场前 5 镜最多 1 个环境镜 | 长镜头、史诗场面和慢悬疑是否需要例外 |
| UI 占位统一为 1.2-3 秒 | 字数、屏幕尺寸和观众阅读速度应如何计算 |
| 特定时长档位 5/10/15 秒 | 必须由真实 Provider 能力档案决定，不能写死 |
| 复杂多角色场景默认多图参考 | 不同模型的图数上限、权重和身份一致性差异 |
## 6. 本轮代码变更
- 新增五级生产合同、质量结果、QC Delta 和规则候选合同。
- 新增严格验证器，覆盖来源引用、钩子兑现、场景转折、对白时长、资产职责和首尾帧连续性。
- 新增版本化规则注册表和按阶段/题材/Provider 激活机制。
- 新增 Prompt 污染扫描器，检测历史项目词、数据库 ID、临时 URL 和素材编号写法。
- 公共脚本 Prompt 已接入经批准的镜头规则。
- 公共脚本和分集服务已清除当前审计到的历史项目事实。
- 生产构建通过；中性合同与污染回归测试通过。
## 7. 剩余隔离区
以下旧服务仍含历史项目专属分支，当前不得作为 `splus_v1` 的公共 Prompt 来源：
| 文件 | 当前命中量 | 处置策略 |
| --- | ---: | --- |
| `characters/characters.service.ts` | 28 | 区分角色资产历史兼容与公共角色生成模板，逐段迁出 |
| `images/images.service.ts` | 14 | 把关键帧项目特例改为合同驱动资产选择 |
| `live-action/live-action.service.ts` | 10 | 新项目绕过旧项目特例，后续接 Provider Compiler |
| `live-action/prompt-builder.service.ts` | 9 | 仅保留通用镜头编译，删除人物/酒店/文件专属分支 |
命中量是本轮关键词审计结果，不等同全部问题数量。清理时必须逐条判断是历史读取兼容、项目数据还是公共生成逻辑，禁止批量替换。
## 8. 晋升流程
```text
历史 Prompt / 返修记录 / QC 差异
-> PromptRuleCandidateV1
-> 去除项目事实与内部 ID
-> 明确 stage / scope / activation_condition
-> 至少两个不同项目复现
-> 低成本 A/B
-> 人工审核
-> approved 规则版本
-> 按条件进入编译请求
```
任何步骤缺失，规则只能停留在 `candidate` 或 `testing`。
docs/work-sync/README.md
+96
View File
@@ -0,0 +1,96 @@
# AI 内容生产平台 Work 同步包
> 当前批次：`WORK_SYNC_2026-07-19_V11`
> 适用对象：用于 Work 的项目知识库同步
> 代码仓库：`/www/wwwroot/ai`
## 1. 这个目录解决什么问题
本目录把“当前代码事实”和“产品设计意图”分开维护，避免 Work 继续依据旧系统 A/B 文档推演已经变化的系统。
- Work 负责产品定位、业务规则、架构决策、功能方案和路线。
- Git + Codex 负责当前代码、数据库迁移、测试、部署和运行事实。
- 本目录是两者之间的可上传同步包，不是完整源码备份。
## 2. 首次上传顺序
1. `00_文档索引.md`
2. `01_项目现状/PROJECT_STATUS_V1.md`
3. `S_PLUS_BATCH_AUTOMATED_PRODUCTION_PIPELINE_V2.md`
4. `S_PLUS_PRODUCTION_FLOW_AUDIT_V1.md`
5. `02_架构设计/SYSTEM_ARCHITECTURE_V1.md`
6. `05_AI流水线/AI_PIPELINE_V1.md`
7. `06_数据库/DATABASE_CURRENT_V1.md`
8. `03_小说引擎/NOVEL_ENGINE_V1.md`
9. `04_短剧引擎/DRAMA_ENGINE_V1.md`
10. `04_短剧引擎/AI_VIDEO_TEST_LESSONS_V1.md`
11. `S_PLUS_SHORT_DRAMA_CODEX_OPTIMIZATION_V1_1.md`
12. `PROMPT_RULE_AUDIT_V1.md`
13. `SPLUS_PHASE_0_1_IMPLEMENTATION_REPORT.md`
14. `SPLUS_PHASE_2_IMPLEMENTATION_REPORT.md`
15. `KLING_S_PLUS_MODEL_ROUTING_SPEC_V1.0.md`
16. `SPLUS_GENERATION_PLAN_IMPLEMENTATION_REPORT_V1.md`
17. `SPLUS_MODEL_REGISTRY_AND_PLAN_DIFF_IMPLEMENTATION_REPORT_V1.md`
18. `KLING_V3_OMNI_API_UPDATE_V1.md`
19. `LANDSCAPE_CHARACTER_ELEMENT_IMPLEMENTATION_REPORT_V1.md`
20. `SPLUS_CHARACTER_TURNAROUND_ITERATION_REPORT_V1.md`
21. `SPLUS_CHARACTER_TURNAROUND_PROMPT_V4_AUDIT.md`
22. `AI_REQUEST_INSPECTOR_IMPLEMENTATION_REPORT_V1.md`
23. `SPLUS_CHARACTER_TURNAROUND_SPLIT_PANEL_IMPLEMENTATION_REPORT_V1.md`
24. `SPLUS_EXECUTION_BRIDGE_EXTERNAL_ASSET_WORKFLOW_V1.md`
25. `07_版本记录/CHANGELOG.md`
26. `08_维护规范/WORK_SYNC_PROTOCOL.md`
27. `SYNC_MANIFEST.md`
若 Work 只支持少量资料，优先上传 1-10；实施报告和维护模板可以第二批上传。
## 3. 不要默认上传的内容
- `backend/`、`workers/`、`user-app/`、`admin/` 完整源码。
- `.env`、API Key、JWT、数据库密码和 Worker Secret。
- `storage/`、`tmp/`、用户上传素材和 Provider 临时 URL。
- 数据库导出中的用户明细、支付信息和私有内容。
- `docs/system_a/`、`docs/system_b/` 全量历史设计。
- 未审阅的对话记录、临时 Prompt 和生成日志。
历史文档需要讨论某项旧决策时，再按 `99_历史设计/README.md` 单独选取，并明确标记“历史参考，不代表当前实现”。
## 4. 文档类型
| 类型 | 是否可改 | 用途 |
| --- | --- | --- |
| 状态快照 | 不改，新增 V2/V3 | 某个时间点的代码、数据和运行事实 |
| 当前设计 | 可修订并升版本 | 当前有效的稳定边界和业务规则 |
| 变更记录 | 只追加 | 记录从上一同步批次发生的变化 |
| 经验总结 | 可修订并升版本 | 经多次生产验证的可复用结论 |
| 历史设计 | 不作为当前事实 | 解释旧决策和演进背景 |
## 5. 日常维护
小改动只需更新受影响领域文档和 `CHANGELOG.md`。以下变化必须生成新的项目状态快照：
- 顶层模块、数据库模型或部署拓扑变化。
- 生产 Provider、队列或存储策略变化。
- 新增完整业务流程或修改关键状态机。
- 发布基线、测试结果或重大风险变化。
- Work 与代码对同一事实出现分歧。
详细流程见 `08_维护规范/WORK_SYNC_PROTOCOL.md`。
## 6. 冲突处理
当文档互相冲突时，按以下优先级判断事实：
```text
当前源码/迁移/运行验证
> 最新 PROJECT_STATUS
> 最新当前设计文档
> CHANGELOG
> 历史设计文档
```
产品未来目标不按上述顺序覆盖，应由 Work 形成独立 `FEATURE_*.md` 或 ADR，再交给 Codex 实现。
## 7. 当前限制
`PROJECT_STATUS_V1` 是项目状态基线；各实施报告记录其对应阶段的代码事实。`S_PLUS_BATCH_AUTOMATED_PRODUCTION_PIPELINE_V2.md` 是新项目的目标流程，不代表其 P0-P5 已经全部上线。当前测试、Git 基线、队列覆盖、备份和真实内容验收风险，均以状态快照、现状审计、实施报告和 CHANGELOG 为准。
docs/work-sync/SPLUS_CHARACTER_TURNAROUND_ITERATION_REPORT_V1.md
+141
View File
@@ -0,0 +1,141 @@
# S+ 人物三视图真实迭代报告 V1
> 实施与验收日期：2026-07-16
> 验收项目：`诸葛亮与司马懿斗法`（Project #22）
> 当前状态：工程保护链完成；单画布三视图路线未达到 S+，已停止继续递归
> 结论口径：真实 Provider、真实图片、真实视觉质检和真实 ProviderLog，不以 Prompt 分代替成图质量
## 1. 本轮目标
本轮使用首个全新 S+ 项目的阻断资产计划，验证人物三视图能否作为后续关键帧、视频角色元素和正式分镜的身份母版。重点不是产出一张“看起来不错”的设定图，而是验证：
1. 同一角色的脸、年龄、发型和胡须能否跨面板稳定。
2. 正面、严格侧面和背面能否保持同一套服装裁片、鞋履与比例。
3. 失败图是否会被硬门阻断，避免自动晋升为角色主锚点。
4. 参考图、Prompt、模型、成本和视觉结论能否完整审计。
5. 迭代经验能否进入公共模板，而不是只修补诸葛亮一个角色。
## 2. 实测结果
资产计划合同为 #8，计划分为 20 项。首批只执行诸葛亮母版，司马懿、蜀军将领、九幽鬼将和五丈原场景继续被阻断，避免在路线未验证前扩大成本。
| 轮次 | 任务 | 模型 | 参考策略 | 素材 | Prompt 分 | 视觉分 | 结论 |
| ---: | ---: | --- | --- | ---: | ---: | ---: | --- |
| 1 | #749 | Seedream 5.0 | 无参考原创 | #978 | 98 | 77 | 道具、鞋履与跨视图身份漂移 |
| 2 | #750 | Seedream 5.0 | 公共 V3 模板原创 | #979 | 98 | 83 | 构图改善，年龄与鞋履仍漂移 |
| 预检 | #751 | 未调用图片模型 | 整板 #979 | - | 97 | - | Prompt 硬门阻断，无图片费用 |
| 3 | #752 | Seedream 5.0 | 显式参考 #979 | #980 | 98 | **87** | 当前最佳，但未达到 S+ |
| 4 | #753 | Seedream 5.0 | 整板递归 #980 | #981 | 98 | 82 | 质量回归，整板参考开始固化缺陷 |
| A/B | #754 | GPT Image 2 | 整板参考 #980 | #982 | 98 | 86 | 结构接近，仍复制错误鞋型 |
| 分层参考 | #755 | Seedream 5.0 | #980 左侧身份面板裁切 | #983 | 98 | 78 | 身份隔离有效，服装拓扑仍被重新设计 |
当前最佳是素材 #980、CharacterImage #147、2560x1440、视觉分 87。该图没有被审批，也没有被设置为角色主锚点。
## 3. 已进入公共底层的能力
### 3.1 公共三视图模板
- 本轮真实图片实验时公共模板为 `character_turnaround_public_v3_s_plus`；后续 Prompt 冲突审计已升级为 `character_turnaround_original_v4_s_plus`，详见 `SPLUS_CHARACTER_TURNAROUND_PROMPT_V4_AUDIT.md`。
- 身份母版默认空手；剧情武器、法器和动作道具不再混入人物母版。
- 增加古代鞋履、浅色服装高光、全身小脸年龄继承和工业级视图几何约束。
- 角色输入仍是唯一可变业务描述，公共规则不绑定某个具体人物。
### 3.2 显式参考与审计
- 图片任务支持 `reference_asset_ids`，可明确指定本轮参考资产。
- 任务记录实际参考资产，不再依赖隐式“最近一张图”。
- 三视图只保持三视图身份，不会被错误自动晋升为 `anchor`。
### 3.3 身份面板裁切
- 支持 `reference_crop_mode=turnaround_face_panel`。
- 系统从原三视图临时裁取左侧身份特写作为 Provider 参考。
- 原始素材不修改，不生成伪锚点，裁切模式进入任务审计数据。
### 3.4 确定性视觉硬门
以下问题只要被视觉报告识别，即由代码升级为硬失败，不依赖审稿模型是否正确标记 `critical`：
- 现代鞋、厚底鞋、橡胶运动鞋等时代错误。
- 跨视图身份明显漂移。
- 侧面不是严格侧面、背面不成立等视图几何错误。
### 3.5 Prompt 复用与成本控制
- 已通过 98 分且参考模式一致的活动 Prompt 可直接复用。
- 新增视觉经验不会再让同一可信 Prompt 每次重复进行多轮昂贵审稿。
- Prompt 审稿输入不再混入单独提交给图片模型的负面约束文本，减少误判污染。
## 4. 成本结论
ProviderLog #1010 至 #1038 的实际成本：
| 类型 | 实际成本 |
| --- | ---: |
| TextProvider：Prompt 审稿与视觉质检 | $2.9753 |
| ImageProvider | $0.1910 |
| 合计 | **$3.1663** |
文本审稿与视觉质检成本约为图片成本的 15.6 倍。这说明成本优化不能只盯图片单价；高分 Prompt 的重复审稿、每轮高规格视觉复核和无效递归同样需要门控。
本轮已先消除可信 Prompt 重复审稿。视觉 QC 的分层模型和关键资产终审策略仍需后续单独设计，不能为了省钱关闭最终硬门。
## 5. 失败路线与停止条件
单画布同时生成“身份大特写 + 正面全身 + 严格侧面 + 背面”的路线已出现稳定瓶颈：
1. 整板递归会把正确身份和错误鞋履、裁片一起锁定。
2. 只提供身份裁切后，模型仍会分别重建三个全身视图的服装和鞋履。
3. Prompt 达到 98 分不等于跨视图资产拓扑达到 S+。
4. Seedream 5.0 与 GPT Image 2 的 A/B 都没有解决同一类硬失败，继续换模型盲抽不构成有效优化。
因此停止对 #980、#981、#982、#983 继续整板递归。任何未达到硬门的候选不得以人工偏好绕过审批。
## 6. 下一阶段架构决策
下一阶段改为分面板人物母版，当前仅为已确认路线，尚未实现：
```text
身份主特写
-> 正面全身
-> 严格 90 度侧面全身
-> 背面全身
-> 四个面板分别做身份、服装、鞋履和视图几何质检
-> 程序化合成 16:9 白底设定板
-> 合成后执行总质检
```
建议放行规则：
- 每个子面板通过对应确定性硬门。
- 跨面板身份与服装拓扑检查通过。
- 合成总分达到 96+。
- 人工确认后才允许晋升角色母版，并用于视频角色元素源视频。
## 7. 验证结果
- ImagesService 定向测试：16/16 通过。
- Backend 生产构建：通过。
- User App 生产构建：通过。
- 真实付费图片生成：4 次有效成图，另有 1 次在图片调用前被 Prompt 门阻断。
- 当前没有任何本轮图片被误标为 S+ 或自动晋升为主锚点。
## 8. 详细项目记录
逐图问题、任务号、素材号和原图路径记录在：
```text
data/诸葛亮与司马懿斗法/7.第一批阻断母版生成记录.md
```
Work 应以本报告作为工程结论，以项目记录作为生产追溯证据。下一次同步应新增分面板实现报告和首个 96+ 真实母版验收记录，不覆盖本报告。
## 9. V4 Prompt 审计补充
2026-07-16 根据网页端复核意见完成公共 Prompt 二次审计。V4 已消除“要求高清身份脸，同时禁止清晰正脸”的目标冲突，并增加模板版本硬门、历史经验语义过滤、人类/非人双分支和资产计划原创角色约束。
这次变更只提高下一次生成输入的可控性，不把 #978 至 #983 的历史视觉分改写为高分，也没有触发新的付费生成。四个阻断角色的详细预检结果见：
```text
docs/work-sync/SPLUS_CHARACTER_TURNAROUND_PROMPT_V4_AUDIT.md
```
docs/work-sync/SPLUS_CHARACTER_TURNAROUND_PROMPT_V4_AUDIT.md
+112
View File
@@ -0,0 +1,112 @@
# S+ 人物三视图 Prompt V4 审计
> 审计日期：2026-07-16
> 审计对象：公共人物三视图模板、历史高分 Prompt 复用、优化经验注入、资产计划基础提示词，以及 Project #22 的四个阻断角色资产
> 外部输入：ChatGPT 网页版对旧生产 Prompt 的 91/100 分析
## 1. 结论
网页版分析的核心判断成立：旧提示词中“左侧高清身份脸”与“禁止清晰正脸/真人脸特写”的组合存在直接冲突。问题不在细节不足，而在目标互相抵消、重复负面词稀释注意力，以及用“8K”文字替代真实输出参数。
但数据库中 Project #22 已实际提交的六次三视图请求并没有包含那五条冲突限制。真正仍存在的工程风险是：
1. 旧 V3 Prompt 即使已有 98 分，也可能被系统直接复用。
2. 历史优化经验中曾同时存在“羽扇必须跨视图固定”和“身份母版必须空手”两套相反规则。
3. 公共资产计划示例仍使用“同一真实演员式角色身份”，容易把后续资产描述带回真人肖像语义。
4. 人类角色规则可能错误套用到多头、多臂、亡灵等非人角色。
5. 网页版复制包的顶层通用 `negative_prompt` 仍可能展示五条冲突限制，即使实际三视图专层请求已经干净，容易造成“复制内容”和“实际提交”口径不一致。
因此本轮不是照抄网页版的诸葛亮专用长 Prompt，而是把正确结论收敛进公共 V4 模板和执行硬门。
## 2. 公共模板 V4
当前模板版本：
```text
character_turnaround_original_v4_s_plus
```
主要变化：
- 使用“当前模型与 API 参数允许的最高原生质量”，不再用提示词虚构原生 8K。
- 固定工业版式显式锁定为 16:9 横版单一连续画布，不再只写语义模糊的“横版”。
- 人类角色统一定义为原创虚构电影 VFX 数字演员，不复制现实演员、公众人物或既有影视角色。
- 左侧身份特写与右侧三个全身工程视图同时保留，不再使用压低清晰正脸质量的限制。
- 负面约束压缩为身份、视图、身体、服装拓扑、摄影材质、多余元素六组。
- 身份母版默认空手，剧情道具、武器、羽扇和法器进入独立道具或状态资产。
- 新增非人分支，锁定主头部、头部与肢体数量、关节、表面材质、甲胄和标志性损伤。
- 非人角色不再被强制套用中年皱纹、法令纹、眼袋、胡须和真人皮肤规则。
网页复制包的顶层通用负面模板也已同步清理：不再禁止“清晰正脸、可识别脸部特写、高精摄影棚脸”，改为禁止复制现实演员、公众人物或未经授权真人身份，以及禁止生活摄影、商业写真和平台肖像模板。旧角色负面描述如重新注入这五条冲突词，会在编译时被过滤。
角色资产链中的主锚点、表情锚点、服装锚点、三视图和平台复制文案已统一移除提示词式 `8K` 声明。新请求只描述 Provider 最高原生质量、后续 4K 放大准备和禁止伪细节；历史保存 Prompt 在提交前会把旧 `8K/4K-detail` 营销词正规化为同一可执行口径。
代码中仍有一类有意保留的例外：只有分镜明确要求肩后、侧后、背影或 Seedance 安全首帧时，关键帧层才允许限制清晰正脸。该规则服务平台预检和指定镜头构图，不属于人物三视图、身份母版或复制总包，禁止跨层复用。
## 3. 执行硬门
三视图活动 Prompt 只有同时满足以下条件才可跳过文本复审：
1. Prompt 分达到当前门槛。
2. 使用当前 V4 模板版本。
3. 仍是左侧身份特写加右侧正面、严格侧面、背面的旗舰版式。
4. 不包含五条脸部质量冲突限制。
5. 参考模式与本次请求一致。
因此，Project #22 当前活动 Prompt Version #102 虽然为 98 分且不含五条冲突词，但仍是 V3 引擎产物，下一次生成不会直接复用，必须按 V4 重新审稿。
文本审稿模型返回的优化 Prompt 也必须保留 V4 版本和旗舰版式；如果删掉版本、破坏版式或重新引入冲突词，即使模型自报 98 分也不能通过。
## 4. 历史经验过滤
数据库当前有 243 条活动三视图优化经验，来源跨越五个 Prompt/QC 引擎版本。经验仍保留用于追溯，但进入新审稿前执行语义过滤：
- 拒绝 9:16 规则。
- 拒绝五条脸部质量冲突限制。
- 拒绝把项目角色名写入公共规则。
- 拒绝把专属道具、武器、羽扇、手机或法器升级为身份母版必备物。
- 拒绝向非人角色注入真人年龄、皱纹、胡须和皮肤规则。
- 拒绝向人类角色注入多头、多臂或鬼火结构规则。
- 按角色时代、服装颜色和物种过滤古代鞋履、浅色服装等条件规则。
- 无角色上下文的纯描述工具只吸收真正跨题材通用的结构经验。
新审稿产生的 reusable rules 在写入全局经验库前也经过同一过滤，避免污染继续累积。
## 5. 四个橙色角色卡审计
| 角色 | 数据状态 | V4 分支 | Prompt 预检 | 资产状态 |
| --- | --- | --- | --- | --- |
| 诸葛亮 #92 | locked | 人类历史角色 | 16:9、V4、无冲突、无人名串线 | 尚无批准主锚点；旧六图最高 87 分 |
| 司马懿 #93 | locked | 人类历史角色 | 16:9、V4、无冲突、无人名串线 | 尚未生成身份母版 |
| 蜀军将领 #94 | locked | 人类历史角色 | 16:9、V4、无冲突、无人名串线 | 尚未生成身份母版 |
| 九幽鬼将 #95 | locked | 非人多头多臂角色 | 16:9、V4、无冲突、无人名串线 | 尚未生成造型母版 |
数据净化：
- #94 的负面描述由点名“复制诸葛亮或司马懿面孔”改为“复制其他主要角色面孔”。
- #95 的身份描述由“司马懿鬼道召出”改为“由九幽鬼道召出”，避免另一角色名字进入造型 Prompt。
四个角色仍是资产计划中的阻断项。Prompt 预检通过不等于图片资产通过；没有生成、视觉硬门和人工审批前，不得进入视频角色元素或正式分镜。
## 6. 上游基础流程审计
Project #22 当前七份已确认合同：原著分析、改编圣经、三集计划、第 1 集场景剧本和第 1 集资产计划，未检测到旧项目专属词或 9:16 数据污染。
资产计划仍保留旧项目素材作为 `manual_review_required` 候选，且 `reuse_decision=create`、`existing_ref=null`。这是可追溯库存，不是自动参考图。新 Asset Planner Prompt 已增加硬规则：候选图的人脸、服装、风格、项目名称和历史 Prompt 不得进入新资产的 `visual_brief`、连续性锁和验收标准。
基础资产示例已由“同一真实演员式角色身份”改为“同一原创虚构角色资产”，并区分人类数字演员与非人角色结构锁。
## 7. 验证
- 三视图模板、CharactersService 复制总包、ImagesService、Production Kernel、资产计划 Prompt 与旧行为保护定向测试：60/60 通过。
- ProductionKernelService 资产计划提示词测试新增原创虚构角色断言。
- Backend TypeScript 生产构建：通过。
- `git diff --check`：通过。
- 四个角色 V4 Prompt 本地预检：全部当前版本、16:9、无五条冲突限制、无旧项目人名串线。
- 本轮未调用付费图片或视频 Provider。
## 8. 下一步
本轮只完成 Prompt 与资产输入层收口，没有改变此前“单画布三视图最高仅 87 分”的真实结论。下一阶段仍应执行分面板路线：身份特写、正面、严格侧面、背面分别生成和质检，再程序化合成 16:9 母版。
先用诸葛亮做 V4 分面板小样，通过 96+ 总质检后，再依次放行司马懿、蜀军将领和九幽鬼将，避免四个阻断角色同时付费试错。
docs/work-sync/SPLUS_CHARACTER_TURNAROUND_SPLIT_PANEL_IMPLEMENTATION_REPORT_V1.md
+118
View File
@@ -0,0 +1,118 @@
# S+ 人物四面板母版实施与诸葛亮小样报告 V1
> 实施与验收日期：2026-07-16
> 验收项目：`诸葛亮与司马懿斗法`（Project #22 / Character #92）
> 当前结论：分面板工程链路成立；首轮真实母版为 A+ 88 分，未达到 S+，不得晋升主锚点
## 1. 已落地生产路线
系统不再要求图片模型在一张画布中同时解决四个视图，而是执行：
```text
身份特写 -> 独立视觉质检
严格正面 -> 独立视觉质检
严格 90 度右向侧面 -> 独立视觉质检
严格 180 度背面 -> 独立视觉质检
FFmpeg 确定性合成 16:9 母版
母版总质检
```
四个面板均使用真实 `gpt-image-2`、`quality=high`、`3840x2160`。最终母版由本地 FFmpeg 合成，不使用生成模型再次绘制，避免在最后一步换脸或改服装。
## 2. 身份参考链
本次从旧候选素材 #980 只提取身份线索，随后逐步累积已完成面板：
| 面板 | CharacterImage | 素材 | 实际参考素材 |
| --- | ---: | ---: | --- |
| 身份特写 | #151 | #984 | #980 的脸部面板裁切 |
| 严格正面 | #152 | #985 | #984、#980 |
| 严格侧面 | #153 | #986 | #984、#985、#980 |
| 严格背面 | #154 | #987 | #984、#985、#986、#980 |
| 程序母版 | #155 | #988 | #984、#985、#986、#987 |
母版 #988 为真实 3840x2160 PNG，约 10.82 MB；版式宽度为身份特写 1200 px，正面、侧面、背面各 880 px。
## 3. 真实质量结论
| 资产 | 视觉分 | 结论 |
| --- | ---: | --- |
| 身份特写 #984 | 91 | 身份清晰；主体略宽、年龄略老、存在轻微 CG 皮肤感 |
| 正面 #985 | 质检 JSON 被旧 2600 token 上限截断；原始返回首项分数为 86 | 图像成立；手部、微材质与现代鞋底是主要问题 |
| 侧面 #986 | 88 | 严格右向侧面成立；胸前结构仍略展开，鞋底现代化 |
| 背面 #987 | 89 | 严格背面成立；后领被长发遮挡，手部和布料拓扑不足 |
| 母版 #988 | **88** | A+；命中现代白色橡胶鞋底一票否决，不可用于 S+ 视频身份锁定 |
本轮证明“分别生成”明显改善了严格侧面、背面、人物完整裁切和程序版式稳定性，但 S+ 仍取决于跨面板服装拓扑、时代鞋履、手部和年龄一致性，不能只看脸是否相似。
## 4. 公共模板 V1.1
公共模板升级为 `character_turnaround_split_panel_v1_1`，吸收本轮通用问题，不写入诸葛亮专属五官或服装：
- 鞋履必须是角色时代对应的同色软底传统鞋靴。
- 禁止白色橡胶中底、运动鞋弧形底、现代休闲鞋头、拉链和工业胶边。
- 正、侧、背锁定同一头脚高度、肩宽、腰线、四肢长度和服装层级。
- 侧面要求胸腔、腰带和衣襟中线压缩为真实侧面厚度。
- 背面要求露出后领中心、背部接缝、后腰带与衣摆拓扑。
- 中老年角色在侧背面通过发色、后颈、耳部、手部皮肤与姿态继续保持年龄。
- 身份特写安全区由中央约 31% 收紧为 27%，减少母版裁切挤压。
- 面板视觉质检 `max_tokens` 从 2600 提高到 5000，避免合法 JSON 被截断。
## 5. 断点续跑与单面板返修
接口：
```text
POST /api/characters/:characterId/turnaround-master/generate
```
支持：
```json
{
"force": false,
"regenerate_image_types": ["turnaround_side_panel"]
}
```
系统会复用其余已完成面板，只重新生成指定面板，然后重新合成和质检母版。用户端每个未通过面板提供“只重生此面板”按钮；完整提交参数进入全局 AI 请求检查器。
## 6. 成本审计
ProviderLog #1039 至 #1047 的真实成功成本：
| 类型 | 成本 |
| --- | ---: |
| 4 张 GPT Image 2 4K 图片 | $1.7386 |
| 4 次面板质检 + 1 次母版质检 | $0.4652 |
| FFmpeg 程序合成 | $0 |
| 合计 | **$2.2038** |
最初接口回执只汇总 RenderTask 图片成本，低估了视觉质检费用。现已修复为分别返回图片、视觉质检、本地合成和总成本，并附任务 ID 与视觉质检 ProviderLog ID。
## 7. 额外修复
- 视觉质检必须信任落盘文件元数据；3840x2160 或 2560x1440 不得因留白误判为非 16:9。
- 质检 Provider 失败只新增失败审计，不再把上一轮有效分数和状态覆盖为空。
- API 返回上一轮有效质检，同时保留最新失败尝试的状态与错误。
- 断点续跑测试确认身份特写、正面不会被重复生成和重复计费。
- 指定面板返修测试确认只调用所选面板。
补跑旧图质检时 OpenAI 返回 429 配额错误，两次失败调用成本均为 0；图片未损坏，原有有效状态已恢复，系统未继续发起付费请求。
## 8. 验证
- 相关后端测试：29/29 通过。
- Backend 生产构建：通过。
- User App 生产构建：通过。
- 真实 4K 图片元数据、背面和最终母版已人工查看。
- 母版没有被误标为 S+，也没有自动晋升角色主锚点。
## 9. 下一步放行条件
待账户配额恢复后，只返修未通过的全身面板，优先处理鞋履、手部和服装拓扑。只有四个子面板和最终母版均达到 96+ 且无一票否决项，才允许：
```text
人工确认 -> 晋升人物母版 -> 生成 6-8 秒角色身份视频 -> 创建 Kling 视频角色元素
```
docs/work-sync/SPLUS_EXECUTION_BRIDGE_EXTERNAL_ASSET_WORKFLOW_V1.md
+57
View File
@@ -0,0 +1,57 @@
# S+ 执行桥接与外部资产流程 V1
## 目标
允许 S+ 项目在暂不调用图片生成模型的情况下，继续完成“确认场景剧本 -> 确认资产计划 -> 导演镜头执行草案”，然后在外部素材导入后才进入付费生成。
## 新执行桥
```text
POST /api/production/contracts/:assetPlanContractId/materialize-execution-draft
```
输入：`ShotExecutionSpecV1[]`。
硬门：
- 资产计划和场景剧本必须已确认且版本链一致。
- 镜号必须连续。
- 单镜表演、对白、声音、轴线、验收和负向结果必须通过 `shot_execution_v1` 校验。
- 所有逻辑资产引用必须来自已确认资产计划。
- 镜头总时长必须严格等于场景剧本时长，每个场次也必须单独对齐。
- 已有确认分镜或冻结 Generation Plan 时禁止覆盖。
## 落地语义
- 创建或更新 `Episode`。
- 保存可审核的 `EpisodeScript` 版本。
- 将执行草案物化为 `StoryboardShot`。
- `video_status = external_assets_pending`。
- `video_prompt = null`。
- `active_generation_plan_id = null`。
- 不调用 Provider，不产生 AI 费用。
## 外部资产路线
```text
外部生成角色/场景/道具
-> 导入私有素材库
-> 人工 QC
-> REQ_* 逻辑需求绑定真实 Asset ID
-> 镜头资产预检
-> 编译 Provider Prompt 和完整请求参数
-> 人工对比修订
-> 冻结 Generation Plan
-> 关键帧/视频生成
```
## 实际验证
项目 `#22 诸葛亮与司马懿斗法` 已以此流程落地第1集：
- 9 镜，总时长 60,000ms。
- 四场时长严格为 8s / 17s / 16s / 19s。
- 所有分镜状态为 `external_assets_pending`。
- Generation Plan 为 0，没有伪造已绑定素材。
- 生产内核定向测试 24/24 通过，Backend 和 User App 构建通过。
docs/work-sync/SPLUS_GENERATION_PLAN_IMPLEMENTATION_REPORT_V1.md
+71
View File
@@ -0,0 +1,71 @@
# S+ 不可变 Generation Plan 实施报告 V1
> 状态：工程已完成，真实付费小样待验收
> 日期：2026-07-15
> 适用引擎：`splus_v1`
## 1. 目标
每个可生成镜头在关键帧之前冻结唯一执行计划。关键帧、参考资产、角色元素、音色、视频请求、质量门、重试、回退和成本审计共同读取该计划，禁止执行阶段静默换模型或重算资产。
## 2. 不可变规则
- 计划使用规范化内容的 SHA-256 作为 `plan_hash`。
- 相同输入复用同一修订；输入变化创建下一修订。
- 历史修订只读，不执行 `update`。
- `StoryboardShot.active_generation_plan_id` 只指向当前活动修订。
- `ShotImage`、`VideoClip`、`RenderTask` 保存 `generation_plan_id`，形成结果与成本追踪链。
- S+ 正式执行必须存在状态为 `frozen` 的活动计划；旧项目继续走 `legacy_v1`，不强制回填。
## 3. 冻结内容
单个计划固定保存：
- Provider、模型、接口、能力版本、路由理由和回退链。
- 推荐分辨率、实际生成分辨率、画幅、时长、原生声音、多镜头和4K候选状态。
- 角色/场景/道具参考资产及 Provider 请求装配快照。
- 角色元素与逐说话人音色计划。
- 关键帧模型、尺寸、质量与参考图上限。
- 视频请求、Prompt、质检阈值、重试上限和成本/价格快照。
## 4. 共同读取链路
```text
镜头分析与路由
-> freeze generation_plan
-> 关键帧读取资产与关键帧参数
-> 视频队列读取 Provider、参数、声音与分辨率
-> VideoClip/RenderTask 绑定 plan_id
-> QC 读取计划阈值
-> 重试读取计划上限与回退链
-> TTS/后期读取逐角色音色
-> ProviderLog 通过 RenderTask 进入成本审计
```
正常请求不能覆盖冻结 Provider；系统定向修复只能使用计划内已批准的回退链。关键帧缓存也必须与活动计划 ID 一致，避免旧图被新修订误用。
## 5. 数据与接口
数据库迁移：`20260715223000_shot_generation_plan_v1`。
新增接口：
- `GET /episodes/:episodeId/live-action/generation-plans`
- `POST /episodes/:episodeId/live-action/shots/:shotId/generation-plan/freeze`
镜头、视频片段和任务安全响应均返回对应计划 ID，便于前端和后台展示真实执行来源。
## 6. 验证
- Prisma Client 生成、schema 校验和迁移部署通过。
- Backend、User App、Admin、Workers 生产构建通过。
- Generation Plan 与 AI Router 定向测试 9/9 通过。
- 全量后端测试 299 条中 265 通过、34 失败；失败属于既有旧测试桩和历史断言漂移，本阶段新增测试全部通过。
- 未触发真实付费生成。
## 7. 下一步
1. 活动计划、历史修订与字段级差异查看已完成。
2. 版本化模型能力、参数 Schema 和价格注册表已完成并绑定 Generation Plan。
3. 下一步把 Kling 元素创建/验证结果纳入供应商绑定，并在计划冻结前硬校验。
4. 用一个全新 S+ 项目做单镜头真实验收，核对计划快照、请求日志、QC 与成本是否完全一致。
docs/work-sync/SPLUS_MODEL_REGISTRY_AND_PLAN_DIFF_IMPLEMENTATION_REPORT_V1.md
+95
View File
@@ -0,0 +1,95 @@
# S+ 模型注册表与 Generation Plan 修订对比实施报告 V1
> 状态：工程、迁移与本地注册表初始化已完成；真实付费镜头待验收
> 日期：2026-07-15
> 适用引擎：`splus_v1`
## 1. 本阶段目标
把会变化的 Provider 工作配置与正式执行事实分开：Provider 配置仍可编辑，但每次正式冻结计划必须引用发布后不可变的模型能力、参数 Schema 和价格修订。前端能够查看镜头当前生效计划，并比较两个历史修订的真实执行差异。
## 2. 不可变模型注册表
新增三类独立版本：
- `ModelCapabilityVersion`：支持能力、输入上限、时长、分辨率、声音、参考图/视频和官方文档来源。
- `ModelParameterSchemaVersion`：字段类型、必填项、枚举、数量上限和参数冲突规则。
- `ModelPricingVersion`：币种、计费单位和完整价格规则快照。
发布规则：
- 使用规范化内容的 SHA-256 作为 `content_hash`。
- 内容相同复用原修订；内容变化创建下一修订。
- 三张版本表不提供更新或删除接口。
- `ProviderConfig` 是可编辑工作区，不能直接充当历史执行凭证。
- 当前 114 个 Provider 已完成首版初始化，三类注册表各 114 条。
## 3. 参数 Schema 硬门
计划冻结前会组装最终 `video_request + provider api_payload`，再按当时发布的参数 Schema 校验：
- 必填参数。
- string/number/boolean/array 类型。
- 枚举、数值范围、Prompt 长度、数组数量上限。
- Kling Omni `video_list` 存在时必须 `sound: off`。
- Kling Omni 携带参考视频时，图片数量按更严格上限校验。
校验失败返回 `MODEL_PARAMETER_SCHEMA_VALIDATION_FAILED`，不会进入视频 Provider 或产生付费调用。
## 4. Generation Plan 绑定
`ShotGenerationPlan` 新增：
- `capability_registry_version_id`
- `parameter_schema_version_id`
- `pricing_version_id`
计划同时冻结三个版本键和内容快照。关键帧、视频请求、QC、重试、声音与成本审计继续读取同一计划，Provider 后续修改不会改变历史计划含义。
## 5. 接口
新增：
- `GET /model-registry?provider_code=`：查看已发布版本，需要 `providers:read`。
- `POST /admin/model-registry/sync`：按当前 Provider 配置发布或复用版本，需要 `providers:write`。
- `GET /episodes/:episodeId/live-action/generation-plans/compare?base_plan_id=&target_plan_id=`：比较同一镜头两个计划修订。
既有计划列表接口现在返回镜头号、场景名和 `is_active`。
## 6. 前端
真人短剧制作台新增“生成计划与修订对比”：
- 按镜头选择计划历史。
- 展示当前生效修订、模型、分辨率、时长、声音、成本与三个注册表版本 ID。
- 任选两个修订比较。
- 差异按模型路由、能力、参数、价格、素材、声音、关键帧、Prompt、质检和重试分类。
## 7. 数据库
迁移：`20260715233000_model_registry_versions_v1`。
当前：
- Prisma Model：68 个。
- Prisma 迁移：39 个，全部已部署。
- 三类注册表各 114 条首版记录。
## 8. 验证
- Prisma Client 生成、schema 校验和迁移部署通过。
- Backend、User App、Admin 与 Workers 生产构建通过。
- 新增注册表与计划修订测试 6/6 通过。
- 全量后端测试 303 条中 269 通过、34 失败；失败数与上一基线一致。
- 参数冲突、4K合法请求、内容哈希复用和字段级计划差异均有定向测试。
- Backend 与 Worker 已受控重启，服务均为 `active`，后端健康检查返回 `ok`。
- 未触发真实付费 AI 生成。
现有 `live-action.service.spec.ts` 仍有 19 条已知旧失败，其余 15 条旧失败分布于旧测试桩和质量策略旧断言；本阶段新增定向测试全部通过。
## 9. 下一步
1. 用一个全新 `splus_v1` 镜头做真实单镜验收，核对计划版本、Provider 请求、ProviderLog 和账单。
2. 将注册表版本与参数校验结果加入后台 Router 审计。
3. 为 Provider 配置保存动作增加“预览待发布差异”，由管理员确认后发布。
4. 修复历史 Live Action 测试桩，恢复全量测试基线。
docs/work-sync/SPLUS_PHASE_0_1_IMPLEMENTATION_REPORT.md
+141
View File
@@ -0,0 +1,141 @@
# S+ 内核 Phase 0-1 实施报告
> 日期：2026-07-15
> 范围：保护基线、Prompt 去污染、生产合同与硬门
> 付费 AI 调用：无
> 数据迁移：无
> 生产服务重启：无
## 1. 本轮完成
### 保护基线
- 数据库完整逻辑备份：`/www/wwwroot/ai-backups/20260715-splus-phase0/database.sql`
- 私有素材归档：`/www/wwwroot/ai-backups/20260715-splus-phase0/storage-private.tar`
- 校验文件：`/www/wwwroot/ai-backups/20260715-splus-phase0/SHA256SUMS`
- 数据库约 90MB，私有素材约 4.7GB。
- 两份备份均通过 SHA-256 回读校验。
### 生产内核
新增 `backend/src/production-kernel/`：
```text
contracts/production-contracts.ts
validators/production-contract-validators.ts
prompts/prompt-rule-registry.ts
prompts/prompt-contamination.ts
fixtures/neutral-production-fixtures.ts
production-kernel.spec.ts
legacy-behavior-guard.spec.ts
index.ts
```
已定义：
- `SourceAnalysisSpecV1`
- `AdaptationBibleSpecV1`
- `EpisodePlanSpecV1`
- `SceneScriptSpecV1`
- `ShotExecutionSpecV1`
- `StageQualityResultV1`
- `ShotQcDeltaV1`
- `PromptRuleCandidateV1`
硬门已覆盖：
- 来源与事实引用；
- 改编决策账本；
- 开场钩子时间线与本集兑现；
- 分集目标、阻力、高潮选择和不可逆变化；
- 场景目标、人物策略、阻力、转折和结果；
- 中文台词时长预算；
- 镜头资产、表演、运镜、声音和验收条件；
- 参考图数量与职责；
- 首尾帧同空间轴线和运动方向；
- 非首镜连续性接力。
### 去劣取优
- 建立版本化 Prompt 规则注册表，当前批准 22 条公共/题材规则，另保留 1 条废弃规则作为防回归标记。
- 历史规则已按 global、genre、provider、project 分级。
- 公共规则可按 stage、genre、provider 条件激活。
- 脚本分镜和分集 Prompt 已接入规则注册表。
- 新增污染扫描，阻断项目专名、内部数据库 ID、临时 URL 和嵌入素材编号进入公共规则。
- 脚本与分集公共链路已清除本轮命中的历史项目人物、地点和终局专名。
- 终局质量检查已从特定故事关键词改为通用的冲突结果、主角选择、状态变化和余波。
- 镜头目标数量不再增删已确认剧情点。
- 删除自动“导演补拍节奏点”。
- 删除按说话人自动拆分对白素材的后处理行为。
- 无法从已确认剧本提取可追溯动作/台词/反应时，直接阻断，不再生成一套都市会议室兜底剧情。
详细规则见 `PROMPT_RULE_AUDIT_V1.md`。
## 2. 验证结果
| 检查 | 结果 |
| --- | --- |
| 后端生产构建 | 通过 |
| 新内核合同/硬门测试 | 7/7 通过 |
| 公共污染与旧行为守卫 | 2/2 通过 |
| 保持真实镜头数的脚本回归测试 | 1/1 通过 |
| 全仓后端测试 | 248 通过，34 失败，共 282 条 |
| 备份 SHA-256 回读 | 通过 |
| `git diff --check` | 通过 |
全仓失败没有在本轮伪装修复。主要仍是：
- Prisma 新字段/新查询加入后旧 mock 未补齐；
- 旧分集样本不满足当前制作蓝图和闭环质量门；
- Provider 成本展示文案断言仍是旧格式；
- Live Action 的旧参考图预检、BGM/SFX 和导演计划断言漂移。
审计基线为 238 通过、35 失败；本轮新增测试后为 248 通过、34 失败。
## 3. Schema 影响
本轮没有修改 Prisma schema，也没有执行数据库迁移。
原因：当前工作区已有大量未提交迁移与测试 mock 漂移；先完成可独立验证的合同、验证器和规则清理，避免在同一批次叠加持久化风险。
Phase 2 前需要评审并落库：
- 项目 `engine_version` 与生命周期；
- 五级合同的版本、状态、输入哈希、来源和质量结果；
- Prompt 规则候选、A/B 证据、审核与回滚版本；
- Provider 编译请求快照和参考图职责；
- 结构化 QC Delta。
现有 `ProjectPipelineConfig.video_engine_version` 与角色/图片 Prompt 版本字段可复用，但不能替代完整生产合同版本。
## 4. 尚未清理的隔离区
以下旧服务仍存在项目专属分支，暂不允许成为 `splus_v1` 公共规则来源：
- `characters/characters.service.ts`
- `images/images.service.ts`
- `live-action/live-action.service.ts`
- `live-action/prompt-builder.service.ts`
下一轮必须逐段判断哪些属于历史项目读取兼容、哪些是公共生成逻辑，不能批量替换。
## 5. 未解决风险
1. 新合同尚未落库，也尚未成为新项目唯一写路径。
2. 公共脚本 Service 仍是大文件，旧 Prompt 文本与新规则并存；本轮只先切断确定有害行为。
3. Provider Compiler 和能力档案未实现，模型时长、参考图数量和音频能力仍由旧链路判断。
4. 污染扫描已实现并保护公共规则，但还没有覆盖所有 Prompt 生成入口。
5. 全仓类型检查仍被旧测试 fixture 类型漂移阻断；生产构建可以通过。
6. 没有浏览器 E2E，也没有真实 Provider A/B；本阶段按要求未产生付费调用。
## 6. Phase 2 建议
下一阶段只推进“原著分析 -> 改编圣经 -> 分集计划”三段：
1. 评审生产合同持久化 schema。
2. 为新项目建立 `splus_v1` 唯一写入口，旧项目只读。
3. 实现 Source Analyst、Adaptation Showrunner、Episode Planner 的阶段请求与 Reviewer Delta。
4. 用三个中性样本验证事实引用、改编决策、钩子兑现和跨集状态。
5. 只批准其中一集进入 SceneScript，暂不接真实视频生成。
进入 Phase 2 前，建议先单独处理测试 mock 基线，避免新合同测试与历史失败混在一起。
docs/work-sync/SPLUS_PHASE_2_IMPLEMENTATION_REPORT.md
+152
View File
@@ -0,0 +1,152 @@
# S+ 内核 Phase 2 实施报告
> 日期：2026-07-15
> 范围：原著分析、改编圣经、分集计划的结构化写路径
> 工程状态：已部署，真实新项目内容验收待执行
> 付费 AI 调用：无
> 数据迁移：`20260715143000_splus_production_contracts_v1`
## 1. 本轮结论
Phase 2 的工程链路已经形成，但尚未宣称通过内容生产验收。
当前系统已经可以安全执行：
```text
连续原文快照
-> 原著分析合同
-> 改编圣经合同
-> 分集计划合同
-> 三集连续性检查
-> 人工只放行其中一集
```
新链路不会覆盖旧 `StoryBible`、`Episode` 或历史 Prompt。所有结构化结果均版本化保存，审核失败也保留为可诊断草稿。
## 2. 数据与状态
### 项目标记
`Project` 新增：
- `engine_version`：数据库默认 `legacy_v1`；应用创建的普通新项目写入 `splus_v1`。
- `production_lifecycle`：记录来源准备、合同写入、确认、三集检查和单集放行状态。
直接提示词实验项目继续标记为 `tool_direct_v1`，不伪装成 S+ 正式生产项目。
迁移后数据库中原有 20 个项目全部为 `legacy_v1`，没有自动迁移、改写或删除历史项目。
### 新增持久化对象
- `ProductionSourceSnapshot`：保存不可变原文、章节清单、内容哈希和版本。
- `ProductionContract`：保存合同类型、schema 版本、父版本、输入哈希、来源引用、正文、质量结果和下游状态。
- `ProductionContractReview`：保存 Reviewer 版本、轮次、问题清单、修复差异和评分。
当前迁移刚完成，三张新表均为 0 条记录；真实内容只会在用户明确创建新 S+ 项目后写入。
## 3. 唯一写路径
### 原著分析
1. 从项目小说源选择最多 20 个章节。
2. 章节号必须连续，单次正文最多 180,000 字。
3. 固化不可变来源快照和逐章哈希。
4. `SourceAnalysisSpecV1` 必须引用本次快照中的来源。
5. 不允许在原著分析阶段提前写改编结论。
### 改编圣经
1. 必须绑定一个已确认的原著分析版本。
2. 改编决策必须记录操作、来源、原因、影响、连续性风险和批准状态。
3. 未批准的改编决策不能被分集计划使用。
4. 修改时创建新版本，不覆盖已确认版本。
### 分集计划
1. 必须绑定一个已确认的改编圣经版本。
2. 第 2 集以后要求上一集已确认。
3. 每集必须包含开场钩子、目标、阻力、升级、高潮选择、不可逆变化和集尾钩子。
4. 连续三集必须同属一个改编版本、集号连续，并严格继承上一集退出状态。
5. 三集通过连续性检查后仍不会自动进入剧本；必须人工选择一集执行 `release`。
## 4. Reviewer 与修复
- Writer 负责输出完整结构化合同。
- 确定性验证器负责字段、来源、批准状态和跨集状态硬门。
- Reviewer 使用版本号记录，只输出问题与 `StageReviewDeltaV1`，不静默重写正文。
- 失败结果保存为 `draft + blocked`，通过硬门的结果保存为 `validated`。
- 确认时重新执行审核；同一范围旧确认版本会被标记为 `superseded`。
## 5. Prompt 构建
新增三个阶段的干净模板：
- Source Analyst
- Adaptation Showrunner
- Episode Planner
公共模板与项目正文分离，运行时才注入来源快照、已确认父合同和上一集状态。请求预览可在付费调用前查看和复制；本轮没有在 UI 暴露一键付费生成入口。
## 6. API 与界面
新增 `ProductionKernelModule` 及接口，覆盖：
- 创建/查询来源快照。
- 保存、查询、评审和确认合同。
- 预览阶段 Prompt。
- 三集连续性检查。
- 放行一个分集计划进入下一阶段。
- 保留受控的阶段 Provider 调用能力，但本轮未触发。
用户端新增 `SplusProductionPipeline.vue`：
- 原著分析、改编圣经、分集计划三个阶段标签。
- JSON 导入、确定性校验、版本列表和问题定位。
- Prompt 预览与复制。
- 评审、确认、三集检查和单集放行。
`splus_v1` 项目不再显示旧 StoryBible/旧分集写入口；历史项目仍走旧页面读取。旧 `StoryBiblesService` 和 `EpisodesService` 的写方法也增加了后端守卫，不能靠直接调用 API 绕过界面。
## 7. 部署与验证
### 部署
- 数据库和私有素材备份继续使用 Phase 0 已校验备份。
- Prisma 迁移从 33 个增加到 34 个，并成功部署。
- 后端已受控重启。
- `GET /api/health` 返回 `status: ok`。
### 自动验证
| 检查 | 结果 |
| --- | --- |
| Phase 2 合同/Service 定向测试 | 13/13 通过 |
| 后端生产构建 | 通过 |
| 用户端生产构建 | 通过 |
| Prisma schema 校验 | 通过 |
| 数据库迁移 | 34/34 已部署 |
| 后端全量测试 | 254 通过，34 失败，共 288 条 |
34 条失败与本轮开始前的既有失败面一致，主要是旧测试 mock 未补齐、旧质量断言和当前实现漂移。本轮没有批量改断言掩盖问题。
## 8. 尚未完成
1. 尚未选择一部全新项目和连续故事段实际写入三阶段合同。
2. 尚未产出并确认连续三集，也未执行“只放行一集”的真实内容验收。
3. 尚未开放前端一键付费阶段生成。
4. 尚未进入 `SceneScriptSpecV1` 场景剧本写路径。
5. 旧角色、记忆等下游页面仍可见，后续需要按阶段状态进一步收口。
6. 全仓 34 条历史测试失败仍需作为独立基线修复。
## 9. 进入 Phase 3 的条件
只有完成以下验收，才进入场景剧本：
1. 新建一个 `splus_v1` 项目。
2. 选取一个连续故事段并生成来源快照。
3. 原著分析与改编圣经通过审核并确认。
4. 连续三集分集计划通过状态继承检查。
5. 人工只放行其中一集。
6. 保存本次 Prompt、合同版本、Reviewer 问题和人工判断作为首个 Phase 2 样本。
在此之前不接视频生成，也不以“页面可操作”代替内容质量验收。
docs/work-sync/SYNC_MANIFEST.md
+78
View File
@@ -0,0 +1,78 @@
# Work 同步清单 V11
> 批次：`WORK_SYNC_2026-07-19_V11`
> 生成日期：2026-07-19
> 根目录：`docs/work-sync/`
> 校验算法：SHA-256
## 1. 同步目录文件
| 文件 | 类型 | 来源/维护方式 | SHA-256 |
| --- | --- | --- | --- |
| `00_文档索引.md` | 索引 | 本批次更新 | `995140fcb1d749a531149ba46ceaf073f3cd2fd37f5af6a001348f807d3190da` |
| `01_项目现状/PROJECT_STATUS_V1.md` | 不可变状态快照 | 根目录同名文件原样复制 | `23d9f0669b54a1bb5d56ba930376c1fe8ec4d08326dbfc752cad252cffca1226` |
| `02_架构设计/SYSTEM_ARCHITECTURE_V1.md` | 当前设计 | 本批次按代码现实生成 | `f2efe8ba4ccf6e889547e296e0663407d780bf9e0c7c0c60834e9fd1acb6a730` |
| `03_小说引擎/NOVEL_ENGINE_V1.md` | 当前设计 | 本批次按代码现实生成 | `1f8ba7e73cced96efaf9dfb609fee17ea15c1b4f5a4fbb38d1f7f120aba68cc1` |
| `04_短剧引擎/DRAMA_ENGINE_V1.md` | 当前设计 | 增补16:9与角色元素执行规则 | `81c6fa3a199000e4f2ebe606a69725e824bd8e2845ac6fba9e17b67388fb042f` |
| `04_短剧引擎/AI_VIDEO_TEST_LESSONS_V1.md` | 生产经验快照 | 根目录 `AI_VIDEO_TEST_LESSONS.md` 原样复制 | `a697a77dbff0f42bcf9d31e3cc5455289df1f79f0e2f3a68744dc3a25c405a4c` |
| `05_AI流水线/AI_PIPELINE_V1.md` | 当前设计 | 增补角色元素 Preflight 与请求绑定 | `06987b334efc26de9209aa7710d871c95039b9ea99d130c1821bd4a85f40961f` |
| `06_数据库/DATABASE_CURRENT_V1.md` | 当前设计 | 增补角色供应商绑定与新注册表统计 | `6359ea8f58a1db5cc83667bb09d71a87130f9d77faec486ecb090dd8c907bb07` |
| `07_版本记录/CHANGELOG.md` | 追加记录 | 追加 V2 目标流水线和现状流程审计 | `67a708701f630267c24a984433585b1ea16323027ddc70e77947e74c4c684387` |
| `08_维护规范/WORK_SYNC_PROTOCOL.md` | 维护规范 | 本批次生成 | `fe70b955f43b350ca78429a0a5cb86c6a19dffee2aecfa978d4463c30973addf` |
| `08_维护规范/DOCUMENT_TEMPLATE.md` | 模板 | 本批次生成 | `90dba248b7e06e791d3f3e68729500f1319cf9ff7ea4439e554afb4a03c6676a` |
| `99_历史设计/README.md` | 历史隔离说明 | 本批次生成 | `2882ed0f46e136e641830eb1045130b3e14b9faded3f3d2abfb57a833fe8f37e` |
| `README.md` | 使用说明 | 本批次更新 | `9c61886a2b973aaf994b59cc8d0c3a75b39bf1531ab902b67e8efbc6359fccfb` |
| `S_PLUS_BATCH_AUTOMATED_PRODUCTION_PIPELINE_V2.md` | 目标流程规范 | 批量自动化与 S+ 唯一目标流程 | `4356c36dab9caa389b3b1768888d7ba4b6adccaee60ff7c8b23f1b0572864eac` |
| `S_PLUS_PRODUCTION_FLOW_AUDIT_V1.md` | 现状流程审计 | 按当前代码、数据库和项目 #22 生成 | `7b0d1f29cf3a6514321b191c86c4d6a2f5894dedfc3da4432aabf603d561c527` |
| `S_PLUS_SHORT_DRAMA_CODEX_OPTIMIZATION_V1_1.md` | 当前目标架构 | 生产画幅收敛为16:9 | `811afabeed20fbad99df20c051409d76f3918599160cbe187f9612a9b51968b7` |
| `PROMPT_RULE_AUDIT_V1.md` | Prompt 规则审计 | Phase 0.5 审计结果 | `f655fa6b81c60bafbc1641477c40d3eb4bbce34ed351d24d94028c5745e5365d` |
| `SPLUS_PHASE_0_1_IMPLEMENTATION_REPORT.md` | 实施报告 | Phase 0-1 代码与验证记录 | `2b865ccc4c4fdaebdd26be9f19e69bccde418d2792e9ca4cde9cdfdda80b6223` |
| `SPLUS_PHASE_2_IMPLEMENTATION_REPORT.md` | 实施报告 | Phase 2 代码、迁移、部署与验证记录 | `bae06ed1d38fab73f88d1a1747a98bfaeacecfe4390090f25933d04f8d76db4b` |
| `KLING_S_PLUS_MODEL_ROUTING_SPEC_V1.0.md` | 当前模型路由规范 | 统一16:9参数、尺寸与母版策略 | `e3b5bfa2513e98392b259e16a1d7fd1afea12f41b463c42b2bb15e56b4dd0fe0` |
| `KLING_V3_OMNI_API_UPDATE_V1.md` | 官方能力快照 | 增补横屏与视频角色元素规则 | `98357cd2443b100f00d1138363b3d0e3919072e561bb0ab34f7cf4af3dd01ba1` |
| `LANDSCAPE_CHARACTER_ELEMENT_IMPLEMENTATION_REPORT_V1.md` | 实施报告 | 本批次代码、迁移、测试与部署事实 | `ac181c79fab41e0344dc25b07105c60798fbba05cd302ac803c2449ef7a66871` |
| `SPLUS_GENERATION_PLAN_IMPLEMENTATION_REPORT_V1.md` | 实施报告 | Generation Plan 数据、执行、测试与后续记录 | `b4eb98e9c8d13a9cd753459d3ccf30bd7d68c3a5325a205426146104b7a10360` |
| `SPLUS_MODEL_REGISTRY_AND_PLAN_DIFF_IMPLEMENTATION_REPORT_V1.md` | 实施报告 | 注册表、参数硬门、修订对比与部署验证 | `dafa7734315d1bfb61b9a522e55c480b306e892afbb89b1697a9c9f2395b4135` |
| `SPLUS_CHARACTER_TURNAROUND_ITERATION_REPORT_V1.md` | 真实验收报告 | 补充 V4 Prompt 审计引用，不改写历史成图分数 | `25a2353e0cb72f08f949430ba9db063af9fb994e7908333a8c0cfad811475ee0` |
| `SPLUS_CHARACTER_TURNAROUND_PROMPT_V4_AUDIT.md` | Prompt 与资产输入审计 | 本批次按代码、数据库和四角色实际输入生成 | `6386fbd02ec0317a1b1ca8dd3ff5e6dadb27c5f9bc99dab95dae6ba32cd5e27a` |
| `AI_REQUEST_INSPECTOR_IMPLEMENTATION_REPORT_V1.md` | 实施报告 | 用户端与管理端共享 AI 请求参数及执行证据抽屉 | `f495b0569e820edd71f293c57777881772c0e2ee177efd52bb53f70ac4ca4fb5` |
| `SPLUS_CHARACTER_TURNAROUND_SPLIT_PANEL_IMPLEMENTATION_REPORT_V1.md` | 实施与真实验收报告 | 四面板独立生成质检、断点续跑、单面板返修、4K母版与诸葛亮小样 | `a5800fd3a789b3a1c9ba32c6194e03b9ee283b61af053f455edf2667f9b62fb1` |
| `SPLUS_EXECUTION_BRIDGE_EXTERNAL_ASSET_WORKFLOW_V1.md` | 实施报告 | 确认资产计划到导演分镜草案的外部资产等待桥接 | `12cf606e59c8370b71fedab3ada9844a5d037b60ba9a1cd6f51af1e7620d1ff3` |
| `S_PLUS_SHORT_DRAMA_CODEX_OPTIMIZATION_V1.md` | 本地追溯输入 | 已由 V1.1 取代，不默认上传 | `ac40820de9eea05b74e072a930ee77181be5ad15e99346eaff3a8173e5b7c888` |
| `豆包讨论.txt` | 本地追溯输入 | 结论已吸收，不默认上传 | `fb180e8e96d454be8b5ac1c7fe49edda64f6cf79ac79826e4914657ab35945a2` |
`SYNC_MANIFEST.md` 不记录自身校验和，因为写入校验和会改变文件本身。
## 2. 完整性检查
在仓库根目录执行：
```bash
find docs/work-sync -type f ! -name SYNC_MANIFEST.md -print0 \
| sort -z \
| xargs -0 sha256sum
```
校验结果应与上表一致。文档内容变化后，必须更新对应校验和、`CHANGELOG.md` 和批次号。
## 3. 上传状态
| 项目 | 状态 |
| --- | --- |
| 文档生成 | 已完成 |
| 敏感信息扫描 | 已完成，未发现凭据或私有连接信息 |
| 文件一致性验证 | 已完成，31 个受校验文件全部匹配 |
| 默认上传范围 | 29 个；排除两份本地追溯输入 |
| 上传 Work | 未执行 |
| Work 批次标记 | 未执行 |
## 4. 上传完成后记录
```text
Work 名称：AI 内容生产平台
上传批次：WORK_SYNC_2026-07-19_V11
上传时间：
上传人：
缺失/跳过文件：
Work 中的生效说明：
```
docs/work-sync/S_PLUS_BATCH_AUTOMATED_PRODUCTION_PIPELINE_V2.md
+858
View File
@@ -0,0 +1,858 @@
# S+ 批量自动化短剧生产流水线 V2
> 文档类型：目标流程与实施基线
> 状态：当前目标规范；P0 执行门禁与 Scene Geography 导演硬门已落地，完整流水线尚未全部实现
> 适用范围：所有新建 `splus_v2` 项目，统一 16:9 横屏
> 核心目标：批量生产、自动化闭环、异常驱动人工介入、S+ 质量可追溯
> 前置审计：`S_PLUS_PRODUCTION_FLOW_AUDIT_V1.md`
> P0 落地记录：`S_PLUS_P0_EXECUTION_GATES_IMPLEMENTATION_V1.md`
> 场景地理落地记录：`S_PLUS_SCENE_GEOGRAPHY_BLOCKING_IMPLEMENTATION_V1.md`
## 0. 最终决策
新流程不再以“能调用模型并合并视频”为完成标准，而以以下五项同时成立为完成标准：
1. 一部作品可以按集、场、镜形成可恢复的任务 DAG。
2. 正常镜头无需人工改 Prompt，异常镜头只返修差异。
3. 任何付费生成都读取已批准资产和可追溯执行计划。
4. 任何未通过质量门的素材都不能被选中、合并或发布。
5. 用户只看到制作流程，工程合同和 Provider 参数默认收进高级抽屉。
这是一条“真人剧组生产逻辑 + AI 自动执行”的流水线，不是旧页面步骤的改名。
## 1. 成功指标
### 1.1 批量生产
- 同一项目支持连续多集生产。
- 项目、集、场、镜和资产均可独立暂停、恢复、返修和重跑。
- 相同角色、场景和道具只生产一次主母版，跨集复用。
- 独立镜头可并行执行，同场连续镜头按依赖顺序执行。
- 上游局部修改只失效受影响的下游，不全项目重跑。
### 1.2 自动化
- 自动生成阶段合同、制作拆解、镜头执行规格和 Provider 请求。
- 自动完成确定性校验、风险分级、模型路由、预算预检和任务排队。
- 自动完成低风险素材的 QC、定向返修、候选比较和合并准备。
- 人工只处理创作决策、高风险镜头、边界分数和最终发布。
### 1.3 S+ 质量
- S+ 不由单一总分决定。
- 所有硬门必须通过。
- 身份、空间、动作、台词、声音和连续性关键维度均有证据。
- 自动评分必须经过真实样本和人工盲评校准。
- 不宣称外部平台官方等级，S+ 是平台内部生产标准。
### 1.4 成本与审计
- 每个付费请求都有输入版本、资产 ID/hash、Prompt、参数、模型、价格版本和实际成本。
- 项目、集、镜分别设置预算上限和自动执行额度。
- 预算内的已批准批次可自动执行；超预算、模型降级或高风险请求进入人工确认。
- 计划请求、选择请求和实际发送请求必须分层展示。
## 2. 真人剧组映射
| 真人剧组阶段 | AI 平台阶段 | 主要产物 |
| --- | --- | --- |
| 项目开发 | 项目与原著 | 原文快照、项目规格、版权状态 |
| 编剧开发 | 剧本开发、分集规划、分集剧本 | 改编规则、分集结构、锁定剧本 |
| 剧本拆解 | 制作拆解 | 角色、状态、场景、道具、服装、VFX、声音清单 |
| 选角、美术、勘景 | 资产制作 | 角色/场景/道具母版、元素和声线 |
| 导演、摄影、预演 | 导演分镜 | 空间调度、镜头表、分镜和关键帧 |
| 拍摄计划 | 拍摄准备 | 执行计划、参数、成本和任务 DAG |
| 正式拍摄 | 分镜拍摄 | 视频候选、现场声音、单镜 QC |
| 剪辑、声音、视效 | 剪辑后期 | 粗剪、精剪、字幕、BGM、SFX、UI、调色 |
| 审片、交付 | 成片交付 | 技术 QC、叙事 QC、批准版本和导出 |
## 3. 用户端唯一流程
用户端只显示以下十步：
```text
0 项目与原著
1 剧本开发
2 分集规划
3 分集剧本
4 制作拆解
5 前期筹备
6 拍摄准备
7 分镜拍摄
8 剪辑后期
9 成片交付
```
内部的 Source Analysis、Adaptation Bible、Generation Plan、Model Registry、Parameter Schema 和 Pricing Version 不作为顶级步骤。
### 3.1 页面分组
```text
开发：0-3
前期：4-6
生产：7
后期：8-9
```
### 3.2 每步固定展示
每一步只回答五个问题：
1. 输入是什么。
2. 这一阶段产出什么。
3. 当前通过、阻断和待人工数量。
4. 用户现在需要做什么。
5. 下一步何时自动开始。
所有 AI 请求、合同 JSON、Provider 路由、成本和差异放进“高级信息 / 完整生成请求”右侧抽屉。
## 4. 两种剧本路线
平台不能用一套顺序同时处理短篇完整故事和长篇连载小说。
### 4.1 短篇完整故事
适合单个完整故事拆成少量短集：
```text
原文
-> 完整改编总剧本
-> 项目级资产粗提取
-> 分集切分
-> 分集剧本锁定
-> 分集级精确制作拆解
```
完整总剧本是唯一叙事母版，分集只切分和局部节奏调整，不能静默重写故事。
### 4.2 长篇连载小说
适合长小说、季播和持续生产：
```text
原文范围快照
-> 原著分析
-> 改编圣经/季纲
-> 分集规划
-> 分集剧本
-> 分集级制作拆解
-> 项目资产库增量合并
```
长篇项目不得先生成全季逐句对白剧本，以免上下文、成本和连续性失控。
### 4.3 路线确认
项目创建时系统可以建议路线，但必须由用户确认：
```text
短篇完整故事
长篇连载小说
现成分集剧本
```
路线一旦进入正式制作，只能通过版本迁移变更，不能在中途静默切换。
## 5. 十步生产流程
### Step 0：项目与原著
输入：
- 小说、故事或现成剧本。
- 项目类型、目标集长、画幅、题材和预算。
- 版权与授权信息。
系统自动：
- 创建不可变原文快照和内容 hash。
- 建立章节、段落和来源引用索引。
- 检查缺页、乱码、重复和明显格式问题。
- 建议短篇或长篇路线。
人工门：确认来源、生产路线和项目规格。
产物：`SourceSnapshot`、`ProjectProductionProfile`。
### Step 1：剧本开发
系统自动：
- 原著事实分析。
- 改编目标、题材承诺、人物弧光和故事主线。
- 短篇模式生成完整改编总剧本。
- 长篇模式生成改编圣经和季级故事结构。
必须单独展示的高影响决策：
- 新增剧情。
- 删除剧情。
- 调换顺序。
- 合并角色。
- 改变人物动机或结局。
人工门：逐项批准高影响改编决策，不能只确认整份 JSON。
产物：`SourceAnalysisSpec`、`AdaptationBibleSpec`、短篇模式的 `MasterScriptSpec`。
### Step 2：分集规划
系统自动：
- 根据故事转折而不是固定字数拆集。
- 计算每集目标、阻力、高潮、不可逆变化和集尾钩子。
- 检查连续三集的入口/出口状态。
- 避免连续重复相同钩子模式。
人工门：批量审核集卡，批准进入分集剧本。
产物：版本化 `EpisodePlanSpec[]`。
### Step 3：分集剧本
系统自动：
- 生成可读、可演、可拍、可听的完整分集剧本。
- 计算中文对白时长、动作时长和场景总时长。
- 检查人物声音、动机、潜台词和上下集连续性。
- 对照原文和已批准改编决策，阻断擅自增删。
人工门：以完整剧本阅读器审核并锁定每集剧本。
锁定后修改必须产生新版本，并计算影响范围。
产物：`SceneScriptSpec`、`ScriptApproval`。
### Step 4：制作拆解
这是 AI 版剧组“剧本拆解”，不是生成图片。
系统自动提取：
- 角色身份。
- 角色状态、年龄阶段、服装、妆发、伤势和情绪。
- 场景、时间、天气、光线和空间结构。
- 道具、持有人、尺寸、材质和交互方式。
- 神兽、怪物、法阵、召唤物和其他 VFX 实体。
- 群演、军队、车辆、动物和环境组件。
- 对白、声线、环境声、拟音、音乐和 UI/字幕需求。
系统执行两级去重：
```text
项目级身份资产
分集/场景级状态资产
```
自动分类：
```text
必须制作母版
可复用已有母版
只需 Prompt 描述
交给后期制作
```
人工门：只审核冲突、重复和高成本资产，不逐条手工确认普通条目。
产物：`ProductionBreakdownSpec`、`AssetRequirementManifest`。
### Step 5：前期筹备
本步骤采用双轨并行，不强制资产和分镜完全串行。
#### A. 资产轨
```text
角色身份母版
-> 角色造型/状态母版
-> 角色元素源视频
-> Provider element_id 和声线绑定
```
```text
场景概念
-> 场景空间母版
-> 时间/天气/破坏状态版本
```
```text
道具概念
-> 正式道具母版
-> 尺寸和交互规则
```
每类资产使用不同视觉 QC，不再只检查数据库是否有图片。
#### B. 导演轨
```text
场景地理与调度
-> 粗镜头表
-> 表演/摄影/声音设计
-> 分镜执行规格
```
场景地理必须明确：
- 人物和阵营归属。
- 固定方位和屏幕方向。
- 视线和动作方向。
- 攻击起点、路径和落点。
- 180 度轴线与允许越轴方式。
- 同场可用机位。
双轨合流条件：
- 镜头引用的正式资产已批准，或明确使用占位资产且不得进入付费视频。
- 分镜空间、动作、时长和声音规格已通过。
- 资产状态与镜头要求没有冲突。
产物：`AssetApproval`、`SceneGeographySpec`、`ShotExecutionSpec[]`。
### Step 6：拍摄准备
系统自动：
- 按镜头风险选择生成策略。
- 生成关键帧、首尾帧或多图预演方案。
- 编译 Shot Intent Plan。
- 对关键帧做身份、空间、动作和构图 QC。
- 生成整集关键帧联系表。
- 批量展示实际参考资产、模型、参数、元素、音色和成本。
关键帧状态：
```text
generated_candidate
-> qc_passed
-> approved
-> locked_for_video
```
只有批准后的关键帧才能编译不可变 `GenerationExecutionPlan`。
人工门：
- 低风险且 96+ 的关键帧可按批次批准。
- 中风险以联系表批审。
- 高风险镜头必须逐镜批准。
产物：`ShotIntentPlan`、`KeyframeApproval`、`GenerationExecutionPlan`。
### Step 7：分镜拍摄
系统自动：
- 按任务 DAG 和 Provider 并发限制提交。
- 生成视频候选，不自动选中。
- 抽帧、读取视频、转写音频并对照镜头规格做 QC。
- 失败时按差异修 Prompt、参考图、时长或路由。
- 在预算和重试上限内自动恢复。
视频候选状态：
```text
generated_candidate
-> qc_passed
-> approved
-> selected
-> merge_ready
```
人工门：只处理高风险、边界分数、候选难分和自动返修耗尽的镜头。
产物：`VideoCandidate`、`ShotQcDelta`、`SelectedClip`。
### Step 8：剪辑后期
系统自动：
- 按镜头入点、出点和声音桥生成粗剪。
- 检查漏镜、重复镜、黑帧、卡帧和时长偏差。
- 生成转场、字幕、UI、BGM、SFX、环境音和响度时间线。
- 对对白优先级、BGM 压限和字幕安全区做确定性检查。
- 生成精剪候选。
声音分工：
- 视频原生音频负责对白、现场动作和必要环境声。
- 后期负责 BGM、补充 SFX、系统提示音、字幕和 UI。
- 不让视频模型生成需要精确显示的文字。
人工门：整集粗剪审核和节奏调整。
产物：`EditDecisionList`、`PostProductionPlan`、`RenderedCandidate`。
### Step 9：成片交付
系统自动：
- 技术 QC：分辨率、帧率、音轨、响度、黑帧、编码和文件完整性。
- 叙事 QC：剧情是否完整、台词是否完整、镜头是否错序。
- 连续性 QC：角色、场景、道具、方向和声音是否漂移。
- 发布 QC：字幕、敏感内容、版权、封面和交付格式。
人工门：最终成片批准。
产物：`FinalQcReport`、`ReleaseApproval`、交付文件。
## 6. 风险分级与候选策略
批量生产不能每镜都生成三份，也不能每镜都人工审批。
### 6.1 低风险镜头 L1
特征：
- 单人物或无人物。
- 无对白或短句。
- 固定场景、轻动作、无复杂 VFX。
- 不承担关键身份首次建立。
策略：
- 默认 1 个候选。
- 自动 QC 96+ 且无硬失败可自动批准。
- 失败后最多 1 次定向返修。
### 6.2 中风险镜头 L2
特征：
- 双人对话。
- 明确道具交互。
- 中等运镜或跨镜连续动作。
- 普通法术、环境变化或情绪转折。
策略：
- 默认 2 个候选或 1 个候选加 1 次条件重试。
- 96+ 可进入批量人工抽检。
- 92-95 进入人工比较。
- 低于 92 自动定向返修。
### 6.3 高风险镜头 L3
特征：
- 多人物对白或明确台词归属。
- 战斗、群体、复杂神兽和大规模 VFX。
- 首次建立角色、场景或关键世界观。
- 精确文字/UI、复杂口型或高连续性长镜头。
- 高成本 4K 或不可替代高潮镜头。
策略：
- 关键帧逐镜批准。
- 默认 2-3 个候选，按预算动态决定。
- 必须人工选择，不能自动进入合并。
- 失败优先拆解风险，不盲目重复同一请求。
## 7. S+ 质量门
### G0：来源和版本门
- 输入快照、来源引用和版本链完整。
- 上游变更影响范围已计算。
### G1：剧本门
- 改编决策已批准。
- 人物动机、场景转折、对白时长和上下集状态通过。
### G2：资产门
- 资产不是普通 candidate。
- 身份、视角、服装、空间或交互专项 QC 通过。
- 主母版和状态版本关系明确。
### G3：导演门
- 场景空间、阵营归属、视线、动作向量和轴线可验证。
- 每个镜头都有存在理由、入点、出点和验收标准。
### G4：请求门
- 关键帧已批准。
- 实际资产、元素、音色、模型、参数和价格版本已冻结。
- 请求满足 Provider 能力和预算上限。
### G5：媒体门
- QC 真实读取图片、视频、音频和转写，不使用只看 Prompt 的 mock 结果。
- 身份、空间、动作、台词、声音、运镜和连续性均有证据。
### G6：合并门
- 只允许 `approved + selected + merge_ready` 片段。
- 片段的 Generation Plan 与当前镜头版本一致。
- rejected 素材不得保留在任何活动指针中。
### G7：交付门
- 技术、叙事、连续性、字幕、声音和版权审核全部通过。
## 8. 分数与自动决策
硬失败永远优先于总分。
```text
有 fatal：立即拒绝
有 major：阻断并定向返修
总分 >= 96 且关键维度 >= 96：自动通过候选
总分 92-95：人工复核
总分 < 92：自动返修或拒绝
```
高风险 L3 即使达到 96，也必须人工批准。
每个分数必须保存：
- rubric 版本。
- 观察证据。
- 置信度。
- 关键维度分。
- 扣分原因。
- 修复范围。
本地结构校验分不得显示成“S+ 视觉质量分”。
## 9. 自动化 DAG
### 9.1 任务层级
```text
Project
-> Episode
-> Scene
-> Asset / Shot
-> Keyframe
-> GenerationExecutionPlan
-> VideoCandidate
-> SelectedClip
-> RenderedEpisode
-> Release
```
### 9.2 并行规则
- 不同集的独立资产提取可以并行。
- 项目共享身份资产只生成一次。
- 同场无连续动作依赖的镜头可以并行。
- 需要上一镜尾帧、姿态或声音桥的镜头必须串行。
- 合并和最终 QC 必须等待本集所有必需镜头 `merge_ready`。
### 9.3 幂等与恢复
任务幂等键至少包含：
```text
stage
input_contract_hash
asset_version_hashes
prompt_rule_version
provider_schema_version
requested_parameters
```
相同输入不得重复付费生成；失败重试沿用同一业务任务并新增 attempt 记录。
### 9.4 局部失效
| 上游变化 | 自动失效范围 |
| --- | --- |
| 原文或高影响改编变化 | 相关分集及全部下游 |
| 分集剧本某场变化 | 该场拆解、分镜、计划和视频 |
| 角色身份母版变化 | 所有引用该角色版本的未发布镜头 |
| 场景空间母版变化 | 所有引用该场景版本的未发布镜头 |
| 单镜执行规格变化 | 该镜关键帧、计划和视频 |
| 关键帧变化 | 该镜 Execution Plan 和视频 |
| BGM、字幕或 UI 变化 | 只失效后期和成片，不重拍镜头 |
已发布版本不原地修改，返修产生新发布候选。
## 10. 人工介入策略
批量生产采用“异常工作台”，不采用“每一步都让用户点一次”。
### 10.1 强制人工门
1. 项目路线和规格确认。
2. 高影响改编决策。
3. 分集剧本锁定。
4. 首次角色/场景主母版批准。
5. 高风险 L3 关键帧和视频选择。
6. 整集粗剪审核。
7. 最终发布批准。
### 10.2 可批量批准
- 分集卡。
- 资产提取清单。
- 同一场景的关键帧联系表。
- 中低风险镜头候选。
- 字幕、UI 和后期时间线。
### 10.3 自动执行
- 结构检查和来源追踪。
- 普通资产去重与复用。
- 低风险镜头生成、QC 和返修。
- 预算内 Provider 路由。
- 合并前确定性检查。
- 技术 QC 和文件交付检查。
## 11. 预算、并发和停止条件
### 11.1 预算层级
```text
project_budget
episode_budget
shot_budget
attempt_budget
```
项目预算确认后，预算内且不改变模型等级的任务可自动执行。以下情况重新请求人工批准：
- 超过集或项目预算。
- 从 1080P 升级到原生 4K。
- 候选数量增加。
- 切换到更高成本 Provider。
- 自动返修达到上限。
### 11.2 并发控制
- 按 Provider 配额和限流动态调整并发。
- 文本、图片、视频、QC 和本地 FFmpeg 使用独立队列。
- 高成本视频队列优先执行已通过全部门禁的任务。
- 同一项目保留公平额度，避免单项目占满队列。
### 11.3 停止条件
每个阶段必须有：
```text
max_attempts
max_candidates
max_repair_rounds
max_cost
timeout
fallback_limit
```
耗尽后进入 `manual_required`，不无限重试。
## 12. 状态机
### 12.1 合同
```text
draft -> validated -> review_passed -> approved -> locked
draft/validated -> rejected
approved/locked -> superseded_by_new_version
```
### 12.2 资产
```text
candidate -> qc_passed -> approved -> bound
candidate/qc_passed -> rejected
approved -> superseded
```
### 12.3 关键帧
```text
generated_candidate -> qc_passed -> approved -> locked_for_video
generated_candidate/qc_passed -> rejected
```
### 12.4 视频
```text
generated_candidate -> qc_passed -> approved -> selected -> merge_ready
generated_candidate/qc_passed -> rejected
```
### 12.5 成片
```text
rendered_candidate
-> technical_qc_passed
-> editorial_qc_passed
-> release_approved
-> published
```
禁止继续使用没有定义的自由状态字符串。
## 13. 前端信息架构
### 13.1 项目总览
展示：
- 十步生产进度。
- 各阶段通过、运行、阻断、人工数量。
- 项目和本集预算。
- 下一项必须处理的异常。
- 批量继续、暂停和取消。
### 13.2 阶段页面
每个阶段包含：
- 主产物预览。
- 质量门结果。
- 版本与差异。
- 批量操作。
- 异常列表。
- 高级信息抽屉。
### 13.3 异常工作台
按原因聚类，而不是按任务流水罗列：
```text
剧本决策待确认
资产缺失或冲突
空间/方向错误
身份漂移
台词不完整
成本超限
Provider 失败
候选需要人工选择
最终成片问题
```
用户修复一次规则后，可批量应用于同类未执行任务。
### 13.4 高级信息抽屉
完整显示：
```text
上游合同版本
计划资产
选择资产
实际发送资产
角色元素和声线
完整 Prompt
负向约束
Provider/模型/端点
完整参数
价格版本和估算
实际请求和响应摘要
QC 证据
重试与回退记录
```
## 14. 新旧能力处理
### 14.1 保留
- Source Snapshot 和来源引用。
- 版本化生产合同。
- Prompt Rule Registry。
- Model Capability、Parameter Schema、Pricing Registry。
- Provider 路由和请求检查器。
- 资产私有存储和 Range 预览。
- RenderTask、BullMQ、成本和审计日志。
- FFmpeg 合成、字幕、BGM、SFX 和转场能力。
### 14.2 重构
- 五级合同扩展为完整制作合同链。
- Generation Plan 拆成可修订 Intent Plan 与不可变 Execution Plan。
- Asset Plan 升级为制作拆解和资产批准体系。
- 分镜增加 Scene Geography 和导演审核。
- 视频生成改为候选优先，不再自动选中。
- QC 改为读取真实媒体。
- 用户端只保留十步制作流程。
### 14.3 废弃
- 用 `generated` 表示所有阶段完成。
- 用结构完整度 100 分代表 S+。
- 视频生成后立即写入正式选中指针。
- 人工拒绝后继续保留活动指针。
- 只看 Prompt 的视频 QC。
- 未批准素材进入付费视频请求。
- 工程合同名称占据用户主导航。
## 15. 实施顺序
### P0：停止错误素材进入成片
1. 视频生成只创建候选，默认不选中。
2. 拒绝候选时原子清空活动指针。
3. 合并只接受 `merge_ready` 且 Plan 匹配的片段。
4. 关键帧增加批准状态，未批准禁止视频生成。
5. Execution Plan 移到关键帧批准后冻结。
验收：项目 #22 的 rejected 视频 #1002 无法进入任何新合并任务。
### P1：建立可理解的新生产台
1. 新增 `splus_v2`，不改变已存在项目。
2. 用户端替换为十步流程和四阶段导航。
3. 工程合同移入高级抽屉。
4. 项目总览增加异常和批次状态。
验收：新用户不需要理解 Production Contract 或 Generation Plan，也能从原著走到成片。
### P2：补齐剧本与制作拆解
1. 加入短篇/长篇/现成剧本三种路线。
2. 增加高影响改编逐项确认。
3. 增加 Production Breakdown。
4. 增加项目级和分集级资产去重。
验收：锁定剧本可以稳定生成角色、场景、道具、状态、VFX 和声音清单。
### P3：补齐前期双轨和导演门
1. 增加 Scene Geography。已完成合同、校验、前端查看、镜头强绑定和项目 #22 首份确认合同。
2. 资产 QC 与导演分镜并行。
3. 增加分镜执行规格批审和关键帧联系表。
4. 增加局部失效图。
验收：阵营、视线、动作方向或轴线错误在关键帧前被阻断。
### P4：真实媒体 QC 和风险路由
1. 接入视频抽帧、视频理解和音频转写。
2. 实现 L1/L2/L3 风险分类。
3. 实现动态候选数量和差异返修。
4. 自动选择只开放给低风险 96+ 镜头。
验收：错误说话者、漏词、变脸、方向错误和动作未完成可被自动发现。
### P5：批量 Orchestrator 与最终交付
1. 以 DAG 编排项目、集、场、镜和资产。
2. 完成预算自动批准、并发、恢复和停止条件。
3. 完成粗剪、后期计划和全片 QC。
4. 建立批量指标和人工校准数据集。
验收：连续三集可以在有限人工门下批量完成，异常可局部恢复。
## 16. 总体验收
选择一个全新 S+ 项目，连续生产三集，每集 6-12 镜，满足：
- 不人工改写 Provider Prompt。
- 所有付费请求可复现实际输入。
- 100% rejected 素材无法进入合并。
- 100% 视频使用批准关键帧和批准资产。
- 首轮镜头自动通过率达到 70% 以上。
- 人工介入镜头比例低于 30%，并随校准逐步下降。
- 成本不超过批准预算，预估与实际偏差小于 10%。
- 台词完整率、说话者正确率和字幕覆盖率达到 100%。
- 阵营、空间、攻击方向和跨镜连续性无致命错误。
- 整集无需人工逐镜裁切和重新排列台词。
- 最终人工盲评达到内部 S+ 发布标准。
未满足以上条件前，不宣称自动化 S+ 流水线已经完成。
docs/work-sync/S_PLUS_P0_EXECUTION_GATES_IMPLEMENTATION_V1.md
+135
View File
@@ -0,0 +1,135 @@
# S+ P0 执行门禁落地记录 V1
> 日期：2026-07-19
> 范围：关键帧批准、不可变执行计划、视频候选审核、选用指针与合并门禁
> 目标：先消除“生成即选用、未审即合并、计划与实际素材不一致”的高风险旁路。
## 1. 本次落地结果
### 1.1 关键帧不再直接进入视频生成
当前状态链：
```text
generated_candidate
-> approved
-> 冻结 ShotGenerationPlan
-> 才允许视频预检与提交
```
- 上传或 AI 生成关键帧后，只写入候选状态。
- 候选会清空旧的执行计划指针和旧的视频选用指针。
- 新增关键帧批准接口：
```text
POST /api/episodes/:episodeId/live-action/shots/:shotId/keyframe/approve
```
- 批准动作完成后才冻结不可变 Generation Plan。
- 预检会返回 `LIVE_ACTION_KEYFRAME_APPROVAL_REQUIRED`，阻断未批准候选。
### 1.2 视频生成结果不再自动选中
当前状态链：
```text
generated_candidate
-> 人工审核 passed
-> approved
-> 用户设为选用
-> merge_ready
```
- 已移除 `autoSelectClip` 业务逻辑。
- 队列审计字段固定记录 `auto_select_clip=false`。
- 同步生成与异步回收都只创建 `generated_candidate`。
- AI Provider 返回后不再写 `storyboard_shots.video_clip_asset_id`。
### 1.3 选用指针成为受控活动指针
只有以下条件同时满足，候选才允许设为选用：
- `VideoClip.status=approved`
- `VideoClip.quality_status=passed`
- 存在输出素材
- 候选的 `generation_plan_id` 与镜头当前计划一致
选中后：
- 当前候选变为 `merge_ready`。
- 同镜头其它 `merge_ready` 候选降回 `approved`。
- 镜头活动指针原子更新到选中素材。
关键帧重新批准时，旧计划下的 `merge_ready` 片段统一变为 `superseded`。
### 1.4 驳回会原子清除旧选用
如果被驳回的候选正是当前选用片段：
- 候选变为 `rejected`。
- `video_clip_asset_id` 同一事务内清空。
- 镜头回到不可合并状态。
重试、进入人工处理或质量失败时也会清理失效的活动指针。
### 1.5 合并只读取严格可合并片段
整集合并现在要求每个镜头都满足：
```text
有活动素材指针
+ 对应 VideoClip.status=merge_ready
+ quality_status=passed
+ S+ 项目存在 active_generation_plan_id
+ VideoClip.generation_plan_id 与活动计划一致
```
任何镜头不满足都会抛出 `LIVE_ACTION_CLIP_NOT_MERGE_READY`，FFmpeg 不会启动。
## 2. 用户端变化
小样页现在明确显示：
1. 生成或上传关键帧候选。
2. 预览候选。
3. 点击“批准并冻结计划”。
4. 生成视频候选。
5. 质检并人工确认可用。
6. 点击“设为选用”。
7. 所有镜头到达 `merge_ready` 后才开放整集合并。
候选列表中的“设为选用”按钮会在审核通过前保持禁用，避免页面误导。
## 3. 数据实现
本次没有新增数据库字段，也没有执行数据迁移。
复用现有字段：
- `ShotImage.status`
- `VideoClip.status`
- `VideoClip.quality_status`
- `StoryboardShot.active_generation_plan_id`
- `StoryboardShot.keyframe_asset_id`
- `StoryboardShot.video_clip_asset_id`
这样先建立安全门禁，后续再按生产合同补充独立 Approval、QC Evidence 和活动版本表。
## 4. 本次没有完成的内容
以下仍属于后续阶段，不应误认为本次已解决：
- 场景地理、阵营、屏幕方向、攻击向量和 180 度轴线合同。
- 对关键帧真实像素内容的自动视觉 QC。
- 对视频逐帧、声音和台词归属的多模态自动 QC。
- 项目/集/场/镜完整任务 DAG 与局部失效传播。
- 自动批准低风险镜头的校准机制。
- 后台批量审核台、审核证据和盲评标定。
## 5. 验证
- 后端 TypeScript 构建通过。
- 用户端 Vue TypeScript 与生产构建通过。
- 新增状态门禁测试覆盖：未批准关键帧阻断、批准后冻结计划、视频候选禁止自动选中、未审核候选禁止选用、驳回后清除活动指针、未到 `merge_ready` 禁止合并。
- 本次 6 条定向门禁测试全部通过。
- 后端全量测试当前为 343 条中 313 条通过、30 条失败。失败集中在旧测试桩、Prompt V5/导演策略断言、人物三视图旧模板断言和其它历史模块，不应误报为全仓测试已通过。
docs/work-sync/S_PLUS_PRODUCTION_FLOW_AUDIT_V1.md
+626
View File
@@ -0,0 +1,626 @@
# S+ 短剧完整生产流程审计 V1
> 审计日期：2026-07-19
> 审计对象：当前 S+ 设计文档、前后端实现、数据库状态，以及项目 #22《诸葛亮与司马懿斗法》的第一集实际执行记录
> 审计性质：只读流程审计。本次不修改剧本、不修改数据库、不触发付费生成。
> 2026-07-19 更新：P0-3、P0-4、P0-5 与合并门禁的第一阶段代码整改已落地，详见 `S_PLUS_P0_EXECUTION_GATES_IMPLEMENTATION_V1.md`。场景地理合同、自动视觉 QC 和完整 DAG 仍待后续阶段。
## 1. 结论
当前流程的方向是对的，但还没有形成真正闭环的 S+ 生产线。
目前系统擅长：
- 保存版本化合同。
- 检查 JSON 结构和上下游引用。
- 规划资产、模型、参数和成本。
- 调用图片、视频 Provider 并保存审计记录。
目前系统缺失的关键能力：
- 高影响改编决策的独立人工确认。
- 场景地理、阵营归属、视线、攻击方向和镜头轴线的正式合同。
- 资产是否真的表达了所需空间关系的视觉质检。
- 分镜执行规格和关键帧的 S+ 视觉准入。
- 冻结计划与实际提交素材完全一致的不可变执行快照。
- 真正观看视频内容的自动质检。
- “通过质检后才能选中、通过选中后才能合并”的状态门禁。
- 成片画面、声音、字幕和叙事完整性的最终审核。
因此，第一镜失败不是单个 Prompt 写差，而是多个流程缺口叠加：
```text
原著被改成结果先置
-> 没有单独确认这项叙事重排
-> 场景母版没有双军站位信息
-> 分镜把鬼将写在画面中央而不是魏军上空
-> 关键帧生成后没有视觉质检
-> 冻结计划仍引用旧关键帧
-> 视频生成后先自动选中
-> 自动 QC 不读取视频画面
-> 人工拒绝后仍保留在分镜选中字段
-> 合并门禁仍可能放行
```
## 2. 当前实际流程
### 2.1 S+ 合同链
当前 S+ 页面展示：
```text
不可变原文快照
-> 原著分析
-> 改编圣经
-> 分集计划
-> 场景剧本
-> 资产计划
-> 执行联调 Generation Plan
```
前五阶段后端已经提供文本模型自动生成接口，但当前 S+ 页面主要操作仍是：
```text
生成阶段 Prompt
-> 复制到外部模型
-> 粘贴结构化 JSON
-> 校验并保存合同
```
证据：
- 自动生成接口：`backend/src/production-kernel/production-kernel.service.ts:627`
- 当前页面导入方式：`user-app/src/components/production/SplusProductionPipeline.vue:775`
### 2.2 旧工作流仍并存
用户端全局工作流仍是：
```text
来源 -> 版权 -> 故事 -> 角色 -> 记忆 -> 分集
-> 脚本 -> 分镜 -> 图片 -> 音频字幕 -> 成品
```
证据：`user-app/src/workflow.ts:66`
这条旧流程没有表达 S+ 的原著分析、改编圣经、资产计划、Generation Plan、关键帧审核和视频 QC。当前系统实际上存在两套流程语义，页面状态容易互相污染。
## 3. P0 问题
### P0-1：高影响改编决策没有独立确认
项目 #22 的原文是顺叙：
```text
两军对峙
-> 司马懿挑衅
-> 司马懿施法
-> 阴兵、乌鸦和九幽鬼将出现
```
改编圣经新增了“结果先置”钩子，分集计划和场景剧本因此改成：
```text
开场直接出现完整鬼将和巨掌
-> 再切回两军对峙与司马懿施法
```
这不是压缩，而是叙事顺序重排。当前系统只要求整份合同确认，没有把 `add / remove / reorder` 这类高影响决策单独列出来确认。
后果：分镜与已确认场景剧本形式上一致，却与用户期望的完整故事不一致。
整改要求：
- `keep`、轻量 `compress` 可以批量确认。
- `add`、`remove`、`reorder`、角色动机变化必须逐项确认。
- 未确认的高影响决策不得进入分集计划。
### P0-2：缺少“场景地理与调度圣经”
当前资产计划检查了：
- 是否存在场景引用。
- 是否存在角色身份引用。
- 引用是否属于当前项目。
但没有检查：
- 蜀军和魏军的固定方位。
- 两军是否相向而立。
- 司马懿、诸葛亮分别属于哪一侧。
- 鬼将必须从魏军上空出现。
- 巨掌必须从魏军方向拍向蜀军。
- 镜头是否越过 180 度轴线。
证据：`backend/src/production-kernel/production-kernel.service.ts:1863`
项目 #22 的场景资产 #989/#990 只是空战场，没有双军、角色、攻击方向和镜头轴线，却被当成正式空间母版使用。
整改要求：在资产计划与分镜切割之间增加正式合同：
```text
Scene Geography & Blocking Bible
```
至少包含：
```json
{
"world_axis": "魏军西侧，蜀军东侧，两军隔原相望",
"screen_axis_a": "常规正打保持魏军画面左侧、蜀军画面右侧",
"faction_ownership": {
"司马懿": "魏军",
"九幽鬼将": "魏军召唤物",
"诸葛亮": "蜀军"
},
"attack_vectors": [
"九幽鬼将从魏军阵地上空显形",
"巨掌由魏军方向压向蜀军诸葛亮所在位置"
],
"forbidden_results": [
"两军背向而立",
"鬼将出现在蜀军上空",
"巨掌拍向魏军",
"无动机越轴"
]
}
```
### P0-3：关键帧没有视觉准入门
当前关键帧生成后会立即写入：
- `storyboard_shots.keyframe_asset_id`
- `shot_images.status=generated`
但没有：
- 空间关系视觉检查。
- 阵营归属检查。
- 攻击方向检查。
- 人物身份和服装一致性检查。
- 人工“批准为视频首帧”状态。
证据：`backend/src/live-action/live-action.service.ts:8322`
项目 #22 第一镜关键帧 #1001：
- `shot_images.quality_score = null`
- `shot_images.status = generated`
- 素材却已经是 `selection_status = selected`
整改要求：
```text
generated_candidate
-> visual_qc_passed
-> human_approved
-> locked_for_video
```
任何关键帧未到 `locked_for_video`，禁止提交视频 Provider。
### P0-4：Generation Plan 冻结得太早
S+ 当前在生成关键帧前先冻结 Shot Generation Plan。
证据：`backend/src/live-action/live-action.service.ts:1388`
项目 #22 第一镜的 Plan #15：
- 状态为 `frozen`。
- `video_request_json.provider_clip_segments[0].source_keyframe_asset_id = 1000`。
- 实际视频任务使用关键帧 #1001。
这意味着“不可变计划”和“实际执行请求”已经不一致。
整改要求：拆成两类计划。
#### Shot Intent Plan
- 在关键帧前生成。
- 包含戏剧目的、空间关系、资产需求、模型建议和成本区间。
- 可修订，不叫 frozen。
#### Generation Execution Plan
- 关键帧批准后生成。
- 包含实际关键帧 ID 与 hash。
- 包含实际发送的每张参考图 ID 与 hash。
- 包含实际元素 ID、音色 ID、Provider、模型、Schema、参数和价格版本。
- 冻结后请求不得替换素材。
### P0-5：视频先选中，后质检
当前任务默认：
```text
auto_select_clip = true
```
视频生成成功后，立即写入：
```text
storyboard_shots.video_clip_asset_id
```
此时 `VideoClip.quality_status` 仍为空。
证据：
- 默认自动选中：`backend/src/live-action/live-action.service.ts:3332`
- 视频落库后立即选中：`backend/src/live-action/live-action.service.ts:3574`
整改要求：
```text
generated_candidate
-> qc_passed
-> human_approved
-> selected
-> merge_ready
```
生成完成只能成为候选，不能自动写入正式选中字段。
### P0-6：视频自动 QC 不看视频
当前视频 QC 固定使用 `mock-qc`，输入只有：
- clip ID。
- 时长。
- MIME。
- 素材状态。
- Prompt 文本。
没有视频文件、抽帧、音轨或转写文本。
证据：`backend/src/live-action/live-action.service.ts:2766`
因此它无法检查：
- 两军是否相向。
- 鬼将出现在哪一侧。
- 巨掌拍向谁。
- 角色是否变脸。
- 台词是否漏读、抢词或说错语言。
- 音画是否同步。
整改要求：QC 至少读取：
```text
首帧 + 25%帧 + 50%帧 + 75%帧 + 尾帧
音频转写
镜头执行规格
关键帧和身份母版
```
高风险镜头需要直接上传视频给支持视频理解的模型复核。
### P0-7：人工拒绝后仍可进入合并
当前人工拒绝只更新：
- `video_clips.quality_status`
- `storyboard_shots.video_status`
不会清空：
```text
storyboard_shots.video_clip_asset_id
```
证据：`backend/src/live-action/live-action.service.ts:2384`
项目 #22 第一镜已被人工拒绝：
- Clip #287：`quality_status=rejected`
- Asset #1002：`selection_status=rejected`
- Shot #969：`video_status=sample_rejected`
- 但 Shot #969 仍指向 `video_clip_asset_id=1002`
合并门禁目前只处理“多候选时是否选了其中一个”，不检查所选素材是否通过 QC。
证据：`backend/src/live-action/live-action.service.ts:4913`
整改要求：
- 拒绝视频时，若分镜正指向该素材，必须在同一事务中清空指针。
- 合并只接受 `quality_status=passed`、`selection_status=selected`、`approval_status=approved`、`generation_plan_id` 匹配的片段。
## 4. P1 问题
### P1-1：结构评分被误解为 S+ 质量评分
合同本地审核分数从 100 开始，按结构问题扣分：
```text
fatal -30
major -15
其他 -5
```
证据：`backend/src/production-kernel/production-kernel.service.ts:1999`
因此“100 分”通常代表：
```text
字段齐全、引用合法、结构连贯
```
不代表：
```text
剧本好看、运镜高级、笑点有效、空间正确、成片达到 S+
```
整改要求：页面分开显示：
- 结构完整度。
- 叙事质量。
- 导演可执行性。
- 视觉连续性。
- S+ 综合评审。
### P1-2：资产“存在”被当成资产“合格”
当前资产门禁主要检查引用存在与 `missing_requirements`，没有统一检查：
- `selection_status`。
- 视觉质量分。
- 是否人工批准。
- 是否真的表达角色、场景和道具语义。
项目 #22：
- 场景 #989 是 `candidate`，无视觉质量分，却被当作场景锁定资产。
- 九幽鬼将 #995 是非主母版的三视图辅助图，却满足了“正式身份母版”需求。
整改要求：不同资产类型使用不同 QC 合同。
```text
角色：脸、年龄、服装、体型、视角一致性
场景：空间结构、光源、方位、可拍机位、轴线
道具：形状、材质、尺寸、持有方式、交互面
特效实体：结构、归属、运动方向、尺度、物理交互
```
### P1-3：计划资产与实际 Provider 输入没有清晰区分
第一镜 Plan 选择的是：
```text
#995 九幽鬼将
#989 战场
```
实际视频请求使用：
```text
首帧 #1001
附加参考 #995
```
场景 #989 没有作为独立参考图发送。
系统需要同时展示三层信息：
```text
计划需要什么
-> 选择了什么
-> 实际 API 发了什么
```
不能只展示计划包，否则无法复盘生成偏差。
### P1-4：视频角色元素链路尚未真正接通项目 #22
“元素源视频”不是“可灵视频角色元素”。完整链路应为：
```text
生成 3-8 秒元素源视频
-> 上传可灵元素库
-> 获得真实 element_id
-> 导入 CharacterProviderBinding
-> 状态 approved 且评分 >= 90
-> 项目角色关联对应 GlobalCharacter
-> Generation Plan 写入 element_list
```
项目 #22 当前四个项目角色的 `global_character_id` 全为空，数据库没有可解析的 Provider Element Binding。第一镜 Plan #15 的：
```text
element_list = []
provider_elements = []
```
而第一镜走的是普通 `kling-v3-native-audio-video`，不是要求元素门禁的 `kling-v3-omni`。
结论：此前生成的诸葛亮元素源视频目前只是素材候选，并没有参与正式分镜生成。
### P1-5：最终“视频审核”仍是内容安全审核，不是成片质量审核
当前成品视频审核只把素材类型、MIME、文件路径和一段文本交给 Moderation Provider，没有读取成片视频。
证据：`backend/src/reviews/reviews.service.ts:86`
它能做的是内容风险审核，不能替代：
- 漏镜检查。
- 画面连续性检查。
- 字幕缺失检查。
- 音量与对白完整性检查。
- BGM 高潮点检查。
- 黑帧、卡帧和转场检查。
### P1-6：状态名称不能反映真实完成度
项目 #22 当前：
- Project：`live_action_shots_prepared`
- Episode：`storyboard_draft`
- 9 个 Shot：全部 `status=generated`
- 但只有第 1 镜有关键帧和视频，且视频已拒绝。
整改要求：项目、集、镜头必须使用可推导状态，不由多个服务随意写自由字符串。
## 5. P2 问题
### P2-1：S+ 页面和旧制作台没有统一
S+ 页面只到“执行联调”，旧制作台负责分镜、关键帧、视频和合并。用户需要跨两个世界理解同一个项目。
整改要求：S+ 项目使用一条完整的可视化流水线，旧项目保留旧入口，但新项目不再进入旧状态机。
### P2-2：Prompt 过度承担数据库合同职责
当前 Prompt 同时承载：
- 戏剧目的。
- 空间关系。
- 人物站位。
- 运镜。
- 声音。
- 资产绑定。
- 禁止结果。
文本再长也不能替代结构化字段。应把关键约束存入可校验 JSON，再由 Provider Adapter 编译成模型 Prompt。
## 6. 建议的完整 S+ 流程
### 阶段 A：内容合同
1. 原文不可变快照。
2. 原著分析。
3. 改编圣经。
4. 高影响改编决策逐项确认。
5. 连续三集计划与连续性检查。
6. 完整场景剧本 S+ 审核。
### 阶段 B：导演合同
7. 场景地理与调度圣经。
8. 角色、场景、道具、特效实体抽取。
9. 资产需求计划。
10. 镜头切割与时长预算。
11. 分镜执行规格审核。
### 阶段 C：资产准入
12. 外部导入或内部生成素材。
13. 类型专项视觉 QC。
14. 人工批准主母版。
15. 视频角色元素创建、导入与绑定。
16. Shot Intent Plan 编译。
### 阶段 D：关键帧准入
17. 关键帧生成。
18. 关键帧自动视觉 QC。
19. 关键帧联系表人工审核。
20. 关键帧批准并锁定。
### 阶段 E：不可变执行
21. 编译 Generation Execution Plan。
22. 展示完整实际 API 请求与成本。
23. 人工确认付费调用。
24. 视频生成，只创建候选。
25. 视频画面、声音、台词和连续性 QC。
26. 人工选择最佳候选。
### 阶段 F：合成与发布
27. 合并准入检查。
28. 转场、BGM、SFX、字幕和 UI 后期。
29. 全片技术 QC。
30. 全片叙事与 S+ 审核。
31. 发布或返修。
## 7. 必须执行的状态机
### 资产
```text
candidate -> qc_passed -> approved -> bound
candidate -> rejected
```
### 关键帧
```text
generated_candidate -> qc_passed -> approved -> locked_for_video
generated_candidate -> rejected
```
### 视频片段
```text
generated_candidate -> qc_passed -> approved -> selected -> merge_ready
generated_candidate -> rejected
```
### 成片
```text
rendered_candidate -> technical_qc_passed -> editorial_qc_passed -> approved -> published
```
## 8. 项目 #22 的正确恢复点
项目 #22 不应该从“优化第一镜 Prompt”继续，也不应该直接重新生成。
正确恢复顺序：
1. 回到已确认的完整场景剧本，取消未经重新确认的结果先置开场。
2. 建立五丈原场景地理与调度圣经。
3. 明确两军相望、魏蜀归属、鬼将生成点和巨掌攻击向量。
4. 重新切第一集分镜并审核时长、轴线和运镜。
5. 生成双军空间关键帧小样。
6. 关键帧通过后再编译新的不可变执行计划。
7. 只跑第一镜视频样片。
8. 通过视频 QC 和人工审核后，再进入其余分镜。
第一镜旧 Plan #10-#15、关键帧 #1001、视频 #1002 只保留为失败审计样本，不再作为正式链路输入。
## 9. 实施优先级
### 第一批：先堵住继续烧钱的漏洞
1. 禁止视频生成后自动选中。
2. 人工拒绝时原子清空 Shot 的视频指针。
3. 合并必须检查 QC、批准状态和 Plan 匹配。
4. 关键帧增加批准门，未批准不能生成视频。
5. 将冻结计划移到关键帧批准之后。
### 第二批：修正创作流程
6. 增加高影响改编决策审核。
7. 增加场景地理与调度圣经。
8. 增加分镜执行规格审核页。
9. 资产增加类型专项视觉 QC。
### 第三批：形成真正 S+ 闭环
10. 接入可读取视频与音频的真实 QC。
11. 增加最终成片技术和叙事审核。
12. 统一 S+ 页面、状态机和完整 API 请求审计。
## 10. 验收标准
新版流程应能在付费视频调用前自动阻断以下任意情况：
- 两军不是相望关系。
- 阵营左右与空间圣经冲突。
- 召唤物没有绑定召唤方。
- 攻击向量指向错误阵营。
- 场景母版仍为候选或没有视觉审批。
- 关键帧未通过视觉 QC 或人工批准。
- Execution Plan 的关键帧 ID 与实际请求不一致。
- 视频元素源素材没有真实 element_id。
- 生成视频尚未通过 QC 就被选中。
- 被拒绝视频仍留在 Shot 正式指针中。
- 合并输入包含 rejected、未批准或 Plan 不匹配片段。
只有这些门禁全部成立，流程才算从“会调用模型”升级为“可控的 S+ 流水线”。
docs/work-sync/S_PLUS_SCENE_GEOGRAPHY_BLOCKING_IMPLEMENTATION_V1.md
+160
View File
@@ -0,0 +1,160 @@
# S+ 场景地理与人物调度硬门落地记录 V1
> 落地日期：2026-07-19
> 适用范围：新 S+ 生产内核，统一 `16:9`
> 状态：第一阶段已实现并验证
## 1. 本次目标
在镜头执行和关键帧生成之前增加正式 `Scene Geography` 合同，机器可验证：
- 阵营方位、人物站位和视线。
- 场景空间区和世界坐标。
- 180度关系轴与允许/禁止机位。
- 攻击、移动和特效汇聚的起点、路径、方向与目标。
- 跨镜连续性、空间锚点和致命禁项。
解决仅靠自然语言 Prompt 导致的两军不相望、阵营交换、鬼将漂移和攻击己方问题。
## 2. 新合同
新增合同：
```text
scene_geography_v1
```
合同上游：
```text
confirmed scene_script
-> confirmed asset_plan
-> confirmed scene_geography
-> shot_execution
```
合同包含：
- `scene_geographies[]`
- `coordinate_system`
- `zones[]`
- `placements[]`
- `primary_axis`
- `camera_positions[]`
- `action_vectors[]`
- `blocking_beats[]`
- `continuity_locks[]`
- `forbidden_outcomes[]`
- `required_spatial_anchor_refs[]`
- `acceptance_criteria[]`
## 3. 硬门规则
确定性校验会阻断：
1. 非16:9或非米制右手坐标。
2. 场景缺少空间区、主体站位或关系轴。
3. 活动角色没有世界坐标与朝向。
4. 关系轴端点没有对应站位。
5. 场景没有安全机位。
6. 禁用轴侧机位被标记为允许。
7. 攻击向量起止区不存在。
8. 攻击回到施法者自身或同一空间区。
9. 调度节拍引用不存在的空间区或动作向量。
10. 场景地理未覆盖已确认剧本全部场景。
11. 空间锚点不属于上游资产计划。
12. 镜头未绑定精确地理合同、轴线、批准机位、空间区或动作向量。
## 4. 执行链变化
旧链路：
```text
asset_plan -> shot_execution
```
新链路：
```text
asset_plan
-> scene_geography
-> shot_execution
-> approved keyframe
-> immutable Generation Plan
-> video candidate
```
`materializeExecutionDraft` 现在只接受已确认的 `scene_geography`，不能再使用资产计划绕过导演空间门。
## 5. Prompt 编译
新增地理调度专用 Prompt Builder，要求模型只完成 Production Designer 与 Blocking Director 工作：
- 不切分镜。
- 不写视频 Prompt。
- 不生成图片。
- 不改剧本和对白。
- 逐场输出坐标、空间区、站位、轴线、机位、动作向量与验收标准。
- 巨型召唤物必须绑定召唤方上方或后方。
- 攻击必须有可验证的 source、target、world direction 和 screen direction。
- 禁止视觉上攻击自己。
## 6. 前端
S+ 生产合同页新增“场景地理”阶段，位于“资产计划”和“镜头执行”之间。
页面可查看：
- 世界布局和坐标轴。
- 空间区和人物站位。
- 主轴、越轴政策和批准机位。
- 攻击与特效动作向量。
- 禁止结果与验收条件。
- 完整 AI 提交参数仍通过高级请求查看器展开。
## 7. 项目 #22 实证
`诸葛亮与司马懿斗法` 第一集已建立：
- 场景剧本：`#15`
- 资产计划：`#16`
- 场景地理：`#17`
- 状态：`confirmed`
- 硬门评分：`100/100`
- 场景覆盖：4/4
项目文档：
- `data/诸葛亮与司马懿斗法/20.第一集场景地理与人物调度圣经V1.md`
- `data/诸葛亮与司马懿斗法/21.第一集分镜执行重切V2待确认.md`
本次未触发任何付费图片或视频生成。
## 8. 代码范围
- `backend/src/production-kernel/contracts/production-contracts.ts`
- `backend/src/production-kernel/validators/production-contract-validators.ts`
- `backend/src/production-kernel/production-stage-prompt-builder.service.ts`
- `backend/src/production-kernel/production-kernel.dto.ts`
- `backend/src/production-kernel/production-kernel.service.ts`
- `backend/src/production-kernel/fixtures/neutral-production-fixtures.ts`
- `user-app/src/api/client.ts`
- `user-app/src/components/production/SplusProductionPipeline.vue`
## 9. 验证
```text
production-kernel.spec.ts 14 passed
production-kernel.service.spec.ts 12 passed
focused production-kernel tests 26 passed
backend TypeScript build passed
scene geography contract #17 hard gate 100/100
```
## 10. 下一步
1. 人工确认第一集10镜重切稿。
2. 编译10份 `shot_execution_v1`，全部绑定合同 `#17`。
3. 先做第1-3镜空间关键帧联系表。
4. 对空间关键帧执行阵营、轴线、鬼将归属和攻击方向专项 QC。
5. 全部通过后才允许视频候选生成。
docs/work-sync/S_PLUS_SHORT_DRAMA_CODEX_OPTIMIZATION_V1.md
+1327
View File
File diff suppressed because it is too large Load Diff
docs/work-sync/S_PLUS_SHORT_DRAMA_CODEX_OPTIMIZATION_V1_1.md
+1152
View File
File diff suppressed because it is too large Load Diff
docs/work-sync/豆包讨论.txt
+2252
View File
File diff suppressed because it is too large Load Diff