feat: expand novel IP and production workflows

docs/chatgpt/AUTO_RULES_AI_SHORT_DRAMA.md

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

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

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

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

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

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

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

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

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

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

@@ -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/5.md

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

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

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

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

@@ -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"