16 KiB

Raw Blame History

给 Codex 的上下文：video-workbench 重构说明

0. 本说明的目的

你不需要再去比对旧版「强哥的徒弟」、旧版「强哥的策划导演」、新版「强哥的策划导演 V2」和旧知识库。

本说明就是本次重构后的上下文摘要。

核心变化一句话：

ChatGPT 端的「强哥的策划导演 V2」不再负责图像 Prompt、不再负责 Codex JSON 执行包、不再负责执行层试错；它只负责阶段0—阶段5的策划、总纲、公共表达与视觉系统、页面/分镜/内容骨架。
Codex / video-workbench 从阶段6开始接手，负责执行层工作，包括 Prompt Advisor、图像生成、参考图组合、试跑、迭代、失败归因、资产落盘和最终交付。

1. 项目背景

原来的「强哥的策划导演」是从更早的「强哥的徒弟」单智能体提示词演化来的。

早期流程里，GPT 同时承担了很多职责：

降维内容策划；
视频总纲；
分镜清单；
分镜深潜；
生图 / 图生图 Prompt；
Codex JSON 执行包；
video-workbench 路径和任务设计。

这在当时是合理的，因为执行链路还不成熟。

但这次试运行后发现：

Codex 的 Prompt 能力更强，尤其是有 gpt-image-2 skill / Advisor 后；
人物形象、MV 分镜、PPT 背景模板、风格一致性，都不是靠 GPT 写一条长 Prompt 就能解决；
图像生成需要试错、参考图组合、review、失败归因和迭代；
这些都属于执行层，不应该由「策划导演」负责；
GPT 如果继续输出 Prompt 或 JSON 交接包，反而会干扰 Codex 的执行判断。

因此，本次重构的方向是：

GPT 上移，Codex 下沉。
GPT 做策划导演。
Codex 做执行导演 + 图像 Prompt 工程师 + 资产生成与试错系统。

2. 新版「强哥的策划导演 V2」的工作边界

新版 GPT 只负责阶段0—阶段5。

阶段0：任务路由

判断任务属于哪种媒介：

科普 / 降维视频；
客户方案 PPT；
培训 / 科普 AI PPT；
科普口播；
科普文章；
MV / 歌曲视觉分镜。

输出任务识别结果，不进入执行层。

阶段1：原始势能扫描

从材料中提取：

核心观点；
冲突；
反直觉点；
受众理解阻抗；
可传播隐喻；
关键概念；
情绪线；
标题势能；
风险点。

阶段2：降维方向提案

给出 2-3 个方向。

每个方向说明：

切入点；
核心隐喻；
适合媒介；
预计体量；
优势；
风险。

阶段3：媒介总纲设计

根据媒介输出：

视频总纲；
PPT 总纲；
课程结构；
文章结构；
口播结构；
MV 情绪结构。

阶段4：通用表达与视觉系统设计

这是本次新增的关键阶段，也是所有媒介的必经步骤。

它必须在分镜清单 / 页面清单 / 内容骨架之前完成。

原因：

过去科普视频通常有前置 IP 设计、文字风格、运营指标、视觉风格等公共内容；但现在「强哥的策划导演」扩展到 MV、PPT、客户方案、培训课件等场景，用户不一定提供这些公共内容。

因此无论用户是否提供公共内容，GPT 都要在阶段4建立项目级公共系统。

阶段4包括：

语言风格；
叙事姿态；
统摄性隐喻；
视觉母题；
色彩基调；
场景系统；
背景系统；
人物造型系统；
服装 / 道具系统；
PPT 页面模板系统；
图示 / 信息图风格；
公式 / 图表 / 页面文字承载策略；
参考图需求；
后续分镜或页面生成规则。

对于 MV / 剧情类内容，阶段4相当于建立人物、场景、服装、道具、情绪色彩和镜头规则。

对于 PPT，阶段4相当于建立页面模板、背景风格、图示系统、信息密度和文字/图表承载策略。

阶段5：分镜 / 页面 / 内容骨架

在阶段4的公共系统约束下，GPT 生成：

科普视频：分镜清单骨架；
MV：镜头清单骨架；
客户方案 PPT：页面清单骨架；
培训 / 科普 AI PPT：页面 / 教学单元骨架；
科普口播：分段口播骨架；
科普文章：章节骨架。

阶段5是 GPT 默认工作的终点。

3. GPT 明确不再做的事

新版「强哥的策划导演 V2」不做以下事情：

1. 不输出最终图像 Prompt

不输出：

text-to-image Prompt；
image-to-image Prompt；
Negative Prompt；
可直接给图像模型执行的最终 Prompt；
图像模型参数；
出图任务单。

GPT 只输出视觉目标、画面功能、页面功能、镜头功能、人物/场景/风格设定。

2. 不输出 Codex JSON 执行包

不再输出：

Codex JSON；
video-workbench task list；
output_path；
dependencies；
asset task schema；
执行顺序 JSON；
落盘路径任务单。

原因：

这类交接包会把 GPT 的旧判断带入 Codex，反而可能干扰 Codex 的执行规划。

Codex 应该直接读取 GPT 产出的阶段0—阶段5 Markdown 策划结果，然后自己做执行层拆解。

3. 不负责执行层试错和失败归因

GPT 不负责：

图像试跑；
人物一致性失败归因；
风格失败归因；
构图失败归因；
参考图组合；
重跑策略；
批量出图；
资产命名和落盘；
PPT 文件生成；
音频生成；
剪辑合成。

这些都由 Codex / video-workbench 承担。

4. 不再全局禁止图片中文字

旧案例里曾经有“no readable text”规则，但这只是当时某些图像任务的局部策略，不再作为全局规则。

新版原则：

是否让视觉资产承载文字、公式、图表、标签、流程节点，由内容目标和媒介需求决定。

对于培训 PPT、科普 PPT、公式讲解、原理图、流程图、框架图，文字、公式、图表往往是核心表达，不应被禁止。

GPT 只说明页面或画面需要承载什么信息。
具体由 PPT 层、设计层、图像模型、后期编辑还是其他工具实现，由 Codex / 执行层决定。

4. Codex / video-workbench 的新职责

Codex 从阶段6开始接手。

阶段6：执行层启动

输入不再是 GPT 生成的 Codex JSON，而是 GPT 输出的阶段0—阶段5 Markdown。

Codex 需要自行解析：

项目类型；
媒介类型；
阶段3总纲；
阶段4通用表达与视觉系统；
阶段5分镜 / 页面 / 内容骨架；
用户提供的原始素材；
用户提供的参考图、定妆照、模板、歌词、PPT素材等。

5. Codex 应新增或强化的能力

1. 读取策划 Markdown，而不是依赖 GPT JSON

video-workbench 应该支持从 Markdown 策划稿中识别：

project_type
medium
stage_3_outline
stage_4_expression_visual_system
stage_5_skeleton
asset_requirements
reference_requirements
visual_system_rules
page_specs
shot_specs

不要再假设 GPT 会给 JSON task list。

2. Codex 自己生成执行计划

Codex 应该根据阶段0—阶段5内容，自动生成自己的执行计划，包括：

项目目录；
资产目录；
中间文件；
参考图目录；
prompt 文件；
review 文件；
迭代记录；
最终交付目录。

这些属于 video-workbench 内部执行逻辑，不再由 GPT 指定。

3. Codex 成为图像 Prompt Owner

所有最终图像 Prompt 由 Codex 负责。

尤其是使用 gpt-image-2 skill / Advisor 时，Codex 应根据 GPT 的策划结果，自己拆解：

type
goal
layout
subject
scene
style
constraints
reference_images
must_preserve
must_avoid
text_policy
acceptance_criteria

GPT 不再提前写 Prompt。

4. Codex 负责通用视觉系统试跑

阶段4输出的是“通用表达与视觉系统”，但它只是策划层设计。

Codex 要做的是把它执行出来并固定下来。

对 MV / 剧情类项目，Codex 需要先试跑：

人物身份锚点；
服装 / 身体锚点；
姿态锚点；
场景锚点；
风格锚点；
道具锚点。

对 PPT 项目，Codex 需要先试跑：

封面模板；
章节页模板；
概念页模板；
案例页模板；
图表页模板；
练习页模板；
背景风格；
图示风格。

对科普视频，Codex 需要先试跑：

公共画面基调；
核心隐喻母题；
固定角色或象征物；
关键图示风格；
页面文字 / 图表承载方式。

5. Codex 负责执行层迭代

Codex 应该把试跑、review、失败归因、迭代固化为 video-workbench 的标准能力。

失败归因可以包括：

身份失败；
服装失败；
姿态失败；
构图失败；
场景失败；
风格失败；
情绪失败；
画幅失败；
页面密度失败；
文字 / 公式 / 图表可读性失败；
与 PPT / 视频 / MV 用途不匹配。

这些归因不要求 GPT 预先定义成固定模板，但 video-workbench 应该支持记录和复用。

6. video-workbench 推荐的新工作流

建议 video-workbench 从以下流程重构：

用户素材 / GPT 策划稿
→ ingest_project_context
→ parse_stage_outputs
→ build_execution_plan
→ create_project_structure
→ materialize_visual_system
→ generate_reference_assets
→ review_and_iterate_visual_system
→ generate_page_or_shot_assets
→ review_and_iterate_assets
→ export_final_assets
→ write_project_handoff

7. Codex 接收的输入形态

以后 Codex 不应期待 GPT 给 JSON，而应支持以下 Markdown 输入。

输入1：阶段3媒介总纲

例如：

## 视频总纲
- 标题候选
- 核心议题
- 目标受众
- 统摄性隐喻
- 叙事结构
- 时长与字数预算
- 风险点

或：

## MV 总纲
- 歌曲核心情绪
- 歌词情绪线
- 视觉母题
- 人物设定摘要
- 场景系统摘要
- 镜头结构
- 风险点

输入2：阶段4通用表达与视觉系统

例如：

## 阶段4：通用表达与视觉系统设计

### 1. 本项目的表达任务
### 2. 语言风格
### 3. 统摄性隐喻 / 视觉母题
### 4. 内容承载策略
### 5. 视觉基调
### 6. 固定元素
### 7. 变化规则
### 8. 后续骨架生成规则

这是 Codex 最重要的输入之一。

它决定项目的公共风格、模板和参考资产。

输入3：阶段5分镜 / 页面 / 内容骨架

例如视频 / MV：

| 镜头 | 对应歌词 / 段落 | 情绪功能 | 核心画面 | 人物可见度 | 景别 / 镜头类型 | 场景 | 视觉母题 | 与前后镜关系 |

例如 PPT：

| 页码 | 页面标题 | 页面功能 | 核心结论 | 页面结构 | 视觉资产设计 |

Codex 应把这些骨架转化为执行层任务。

8. video-workbench 内部建议的数据结构

Codex 可以在内部生成自己的结构化数据，但这不应要求 GPT 提供。

建议内部 schema 大致分层：

project:
  id:
  name:
  medium:
  source_files:
  goal:

planning_inputs:
  stage_3_outline_md:
  stage_4_visual_system_md:
  stage_5_skeleton_md:

visual_system:
  language_style:
  visual_motifs:
  color_palette:
  layout_rules:
  character_system:
  scene_system:
  template_system:
  text_and_diagram_policy:
  reference_requirements:

assets_to_materialize:
  common_assets:
    - id:
      type:
      purpose:
      source_spec:
      output_path:
      status:
  page_or_shot_assets:
    - id:
      page_or_shot_id:
      type:
      purpose:
      source_spec:
      prompt_owner: codex
      output_path:
      status:

reviews:
  - asset_id:
    version:
    issues:
    failure_causes:
    decision:
    next_action:

final_outputs:
  assets:
  index:
  handoff_note:

重点：

prompt_owner 应该默认是 codex；
source_spec 来自 GPT 的阶段4/阶段5，而不是 GPT Prompt；
reviews 是 Codex 执行层自己的记录；
GPT 不再生成这个 YAML，Codex 内部自行生成。

9. 旧文件 / 旧案例的处理原则

旧版「强哥的策划导演」

旧版曾经包含：

图像 Prompt；
Codex 执行包；
video-workbench JSON；
分镜深潜里的 Prompt 字段。

这些都已经废弃。

不要以旧版为准。

旧版附录 B/C/D/E

旧版附录中出现的以下内容不再继承：

“镜头 Prompt”；
“生图 / 图生图 Prompt”；
“图片任务必须有 prompt”；
“Codex JSON 执行包”；
“输出路径由 GPT 指定”；
“图片默认 no readable text”。

这些属于旧职责边界。

30_CASE / 31_CASE

30_CASE 和 31_CASE 只作为旧案例颗粒度参考。

可以参考：

分镜清单的完成度；
页面设计的颗粒度；
讲师备注与页面文案分层；
科普视频的叙事节奏；
培训 PPT 的教学单元意识。

不要继承：

GPT 输出生图 Prompt；
GPT 输出 Codex 字段；
“图片不生成文字”的全局化理解；
旧路径或旧执行包结构。

10. Codex 以后应怎样理解 GPT 输出

GPT 输出的是“导演意图”和“策划骨架”，不是执行命令。

Codex 不要机械执行 GPT 的字面文本，而要把它转成适合执行层的资产计划。

比如 GPT 写：

人物需要一个50岁东亚男性，黑色矩形眼镜，胡茬，凌乱头发，深色长外套，旧背包，泥靴，疲惫但继续前行。

Codex 应理解为：

这不是最终 Prompt。
这是人物系统规格。
需要先生成 / 固定 identity、wardrobe、pose、style 等参考资产，再进入镜头生成。