# 1

我正在ChatGPT上打造`强哥的导演`。这是基于讨论的上下文，ChatGPT整理的对你的配合要求：
`C:\Users\wangq\Documents\Codex\video-workbench\intake\Codex 上下文：初始化 video-workbench 项目.md`。

先阅读这个文档，然后需要你检查现在的项目情况，有没有冲突的地方。

它的这个`初始化推荐目录结构`，我觉得需要商榷：
* 比如每次，我启动时，其实都是一个项目，可不可以按照项目的结构来管理。
* `adapters`，其实能力已经都内化成Skill了，是否不需要这个文件夹。
  * 我们前面测试了本地文生图、图生图的能力。这是你前个回合的回复：
    ```md
    **两个技能的区别**
    - `imagegen`：当前最直接可用的出图技能。它调用 Codex 内置图像生成工具，不需要你本地配置 `OPENAI_API_KEY`。生成后默认落到 `.codex\generated_images`，我再复制到你指定的项目目录。
    - `gpt-image-2`：更像“GPT Image 2 工作流/提示词工程技能”。它有本地 API 模式、宿主出图模式、纯 prompt 顾问模式。当前环境检测结果是 Host-Native 模式，所以它负责整理高质量 prompt，再交给 `imagegen` 这种宿主图像工具出图。
    ```
  * 生成语音，我也打造了skill，`voice-generation`。

另外，这个路径下的内容与GPT的知识库是同步更新的`C:\Users\wangq\Documents\Codex\knowledge-vault\prompts\GPT\强哥的策划导演\`，也包括了`强哥的策划导演`的原始指令。
其中文件说明为：
```md

### 八、知识库文件构成与调用协议

你的知识库包含以下几类文件。调用知识库时，必须区分“规则文件、风格文件、系统文件、案例文件、历史归档文件”的不同用途，不能混用。

#### 1. 核心规则文件：最高优先级知识

以下文件是当前版本“强哥的策划导演”的核心执行规则，必须优先遵循：

- 00_CORE_附录A_Wantsong降维输出风格蓝图.md
- 00_CORE_附录B_媒介路由与流程裁剪表.md
- 00_CORE_附录C_视频与分镜模板.md
- 00_CORE_附录D_PPT设计模板.md
- 00_CORE_附录E_Codex执行包Schema.md

调用原则：
- 附录 A 用于控制 Wantsong 的降维表达风格。
- 附录 B 用于判断任务属于哪种媒介，以及不同媒介如何裁剪流程。
- 附录 C 用于科普视频、分镜、口播与图像 Prompt。
- 附录 D 用于客户方案 PPT 与培训 / 科普 AI PPT。
- 附录 E 用于生成 Codex JSON 执行包。

当用户任务涉及具体媒介时，必须优先调用对应核心附录，而不是凭空生成。

#### 2. 风格补充文件：用于增强表达质感

- 10_STYLE_Wantsong视频科普风格蓝图完整版.md

该文件用于补充 Wantsong 的语言质感、叙事风格、隐喻方式和科普表达细节。

调用原则：
- 当任务是科普文章、科普口播、科普视频、培训 / 科普 AI PPT 时，可以调用该文件增强表达。
- 该文件不能覆盖 00_CORE 附录中的当前流程规则。
- 如果完整版风格蓝图与当前核心附录存在冲突，以 00_CORE 附录为准。

#### 3. 系统执行文件：用于 Codex 与 video-workbench

以下文件用于理解 video-workbench 项目和 Codex 的真实执行能力：

- 20_SYSTEM_video-workbench项目说明.md
- 21_SYSTEM_Codex_JSON执行样例.md

调用原则：
- 当用户要求“交给 Codex 执行”“生成执行包”“落到 video-workbench”“生成图片 / 音频 / PPT 资产”时，必须优先参考这两个文件。
- 生成 JSON 执行包时，要尽量遵循其中的真实字段、路径、任务类型和输出目录。
- 不要编造 video-workbench 中不存在的能力。当前默认不自动生成完整视频成片，不自动发布平台，除非系统文件或用户明确说明已经支持。

#### 4. 案例文件：用于学习成品颗粒度

以下文件是示范案例，用于理解输出的完成度、颗粒度和呈现方式：

- 30_CASE_典型视频分镜案例.md
- 31_CASE_典型培训AI_PPT案例.md
- 32_CASE_典型客户方案PPT案例.md

调用原则：
- 案例只作为参考，不是硬性规则。
- 不要机械套用案例中的行业、主题、客户、画风或具体表达。
- 要学习案例的结构、颗粒度、页面设计方式、备注写法、分镜深度和 Codex 资产组织方式。
- 当用户任务与案例类型相似时，可参考对应案例的输出形态。

#### 5. 历史归档文件：仅作风格与历史参考

- 90_ARCHIVE_旧版强哥的徒弟_仅作历史参考.md

调用原则：
- 该文件只用于理解历史上的“强哥的徒弟”风格、关系感和部分视频降维经验。
- 不得继承其旧版视频专用流程。
- 不得继承其 Thinking 输出要求。
- 不得继承其单智能体全栈执行定位。
- 不得继承其强阶段锁死规则。
- 新版身份始终是“强哥的策划导演”，不是旧版“强哥的徒弟”。

#### 6. 冲突解决优先级

当指令、附录、案例或历史文件之间发生冲突时，按以下优先级处理：

1. 当前 GPT Instructions
2. 00_CORE 核心附录
3. 20_SYSTEM 系统执行文件
4. 10_STYLE 风格补充文件
5. 30_CASE 案例文件
6. 90_ARCHIVE 历史归档文件

如果知识库没有检索到足够信息，不要编造文件内容。应基于当前 Instructions 和已知附录规则继续工作，并在必要时提示强哥补充项目说明或案例材料。


```
我觉得你不一定能用的上，你可以根据需要自行查阅。

---

先理解要做什么，有问题可以提出。

我理解这次不是要我直接按 intake 初始化，而是先判断它和当前 `video-workbench` 的真实状态有没有冲突。我已读取 intake、当前仓库文件、历史边界记录和 GPT 知识库同步目录；没有改文件。

**结论**
intake 里的定位大体对：GPT 做策划，Codex/video-workbench 做执行资产落盘；不默认自动剪辑、图生视频、自动发布，这和现有仓库一致。真正需要商榷的是目录结构。

主要冲突点有 4 个：

1. `初始化推荐目录结构` 假设项目是空的，但当前仓库已经有项目化结构：`series/active|completed|abandoned`、`standalone/active|completed|abandoned`、`templates/episode-project/EPISODE_STRUCTURE.md`。现有规则明确每个视频应落在 series 或 standalone 项目里，而不是全局 `inputs/outputs` 扁平池。[VIDEO_WORKBENCH.md](C:/Users/wangq/Documents/Codex/video-workbench/VIDEO_WORKBENCH.md:38)、[EPISODE_STRUCTURE.md](C:/Users/wangq/Documents/Codex/video-workbench/templates/episode-project/EPISODE_STRUCTURE.md:5)

2. 顶层 `inputs/` / `outputs/` 容易和“每次启动其实都是一个项目”的实际用法冲突。更合理的是每个项目目录内保存 `source-map.md`、执行包、生成资产、metadata、asset-log，而不是把所有资产混在仓库根部。

3. 顶层 `adapters/` 不适合作为当前默认目录。现有边界是：可复用自动化在 `skills-vault`，本地 work agent/runtime 在 `ccpe-system`，video-workbench 只是消费和记录请求。[PROJECTS.md](C:/Users/wangq/Documents/Codex/video-workbench/PROJECTS.md:36)、[requirements/skills-vault/README.md](C:/Users/wangq/Documents/Codex/video-workbench/requirements/skills-vault/README.md:9)  
   现在 `imagegen`、`gpt-image-2`、`voice-generation` 已经是 Skill 能力，不需要再建 `adapters/voiceover`、`adapters/image_generation` 这种能力目录。最多需要一个 `docs/capabilities.md` 或 `ccpe-consumption/runtime-links.md` 更新，记录“当前可调用哪些 Skill、状态是什么”。

4. GPT 知识库同步目录里，`20_SYSTEM_video-workbench项目说明.md` 和 `21_SYSTEM_Codex_JSON执行样例.md` 目前是 0 字节；真正已有内容主要在 `强哥的策划导演.md` 和 `00_CORE_附录E_Codex执行包Schema.md`。所以这两个 SYSTEM 文件确实需要生成，但应按当前仓库真实结构生成，而不是按 intake 的旧初始化树生成。

**我建议的结构方向**
保留当前主干：

```text
series/
  active/
  completed/
  abandoned/

standalone/
  active/
  completed/
  abandoned/
```

每个具体项目内部再放：

```text
execution-package.json
source-map.md
04-deep-production/
05-assets/
  images/
  audio/
  slides/
  metadata/
  asset-log.md
```

仓库根部可以新增但不要喧宾夺主：

```text
schemas/execution-package.schema.json
examples/*.example.json
docs/20_SYSTEM_video-workbench项目说明.md
docs/21_SYSTEM_Codex_JSON执行样例.md
docs/capabilities.md
```

不建议新增顶层 `adapters/`。如果未来真的需要本仓库里有很薄的调用封装，也应先写成 `requirements/skills-vault/` 供应请求；只有用户明确要求本地临时脚本，才放 `scripts/`，并标注为 local helper，不当成 canonical adapter。

需要你确认两个决策：

1. `schemas/`、`examples/`、`docs/20_SYSTEM...`、`docs/21_SYSTEM...` 是否可以加入本仓库，作为 GPT 知识库同步源？
2. 项目内资产目录是否采用“每个 series/standalone 项目自带执行包和 assets”的结构，而不是根目录 `inputs/outputs`？

# 2

之前的这个结构也有问题：

```text
series/
  active/
  completed/
  abandoned/

standalone/
  active/
  completed/
  abandoned/
```

1. 项目若是完成或者作废，都需要移动目录。若正式跑起来会大动干戈。
2. 是否是一个系列，有时很难在项目初期确定；即使按照一个`standalone`制作，反响好，大概率会拍续集。

我觉得应该：
1. 删除这种割裂形式的目录，直接建立`projects`，
2. 状态可以在`projects/具体项目/`文件夹下project自己文件内部管理。
3. series，只要一个系列索引文件就能解决。

---

项目内部的文件夹也比较割裂：我去具体加工一个镜头，或者翻找一个镜头的资料，得在不同目录中翻找。
我觉得按照分镜头设计，而不是产出物。
项目根目录下放项目整体资料，比如总纲，总计划，分镜头清单这些。
而分镜头的资料放在`分镜1/`下，不论是提示词脚本、口播稿、还是生成后的图片，或者语音文件。

---

**一个核心指导性原则：** 这个不是写代码的项目，避免各种冗余的审计、日志，从而导致治理过度。
之前不论是知识库，还是写作库，抑或是项目库（其他系统）都出现了治理过度的问题。
减少记录，简化步骤。
写作库最近完成了一篇文章的正文初稿工作：`C:\Users\wangq\Documents\Codex\writing-workbench\projects\水晶裹尸布与生命体\drafting\`
你可以看到`sessions/`里面，有20多次CCPE的智能体调用返回，文件也就20来个。

没必要的文件，我觉得就需要了。
若需要的目录或者文件，需要你解释下，这个干啥用的。

---

基于以上，你的想法？

我同意你的判断，而且我会比你说得更硬一点：`series/active/completed/abandoned` 和 `standalone/active/completed/abandoned` 这套结构不适合这个库。它把“状态”和“类型”变成了物理目录，但视频项目的状态和系列关系都会变化。正式跑起来以后，移动目录就是在制造维护成本。

我建议改成这个主干：

```text
video-workbench/
  projects/
    2026-06-22-project-slug/
      project.md
      outline.md
      storyboard.md
      references/
      shots/
        shot-01-name/
          shot.md
          image-prompt.md
          voiceover.md
          image-v1.png
          voiceover-v1.wav
        shot-02-name/
          shot.md
      execution-package.json
      sessions/
  series.md
  schemas/
  examples/
  docs/
```

核心规则：

- `projects/` 是唯一项目入口，不按 active/completed/abandoned 搬家。
- 项目状态写在 `project.md` 里：`drafting / producing / paused / done / abandoned`。
- 是否属于系列，不由目录决定。写在 `project.md` 的 `series_id`，同时在根部 `series.md` 里维护系列索引。
- 一个 standalone 反响好要变系列，只改 `project.md` 和 `series.md`，不用移动文件。
- 镜头是工作单元，所以镜头资料应该集中在 `shots/shot-xx/` 下，而不是散落在 `04-deep-production/images/audio/prompts` 这种阶段目录里。

我认为必要文件只有这些：

- `project.md`：项目身份证。记录标题、状态、媒介类型、来源、系列关系、当前下一步。这个是续作入口。
- `outline.md`：项目总纲。包括主题、目标受众、整体节奏、视觉方向。
- `storyboard.md`：分镜清单和每个镜头的索引。它负责导航，不承载所有细节。
- `shots/shot-xx/shot.md`：单个镜头的主文件。视觉、口播、设计意图、执行状态都在这里。
- `series.md`：全局系列索引。只解决“哪些项目属于同一系列、顺序是什么”。
- `execution-package.json`：只有当 GPT 真给 Codex 执行包，或我们要批量执行时才需要。
- `sessions/`：只有发生真实智能体/Skill 调用且需要保留返回时才需要。写作库的 `drafting/sessions/` 模式是好参照：少量 prompt/returned 对，不搞审计系统。

我不建议默认建这些：

- `active/ completed/ abandoned/`
- 顶层 `inputs/ outputs/`
- 顶层 `adapters/`
- `audit/ logs/ validation/ metadata/ reports/` 这类治理味很重的目录

`schemas/` 和 `examples/` 可以保留，但它们是给 GPT 和 Codex 对齐 JSON 用的“系统说明层”，不是每个项目都要碰的工作目录。正常做视频时，人应该主要进 `projects/具体项目/`，再进 `shots/shot-xx/`。

如果按这个方向，我下一步会建议先改文档和模板，不急着做复杂迁移。因为当前 `series/`、`standalone/` 里面基本还是 `.gitkeep`，现在纠偏成本很低。

# 3

因为三个角色协作，gpt规划，我决策，你执行。

- `project.md`，你负责维护，但是大部分来自于GPT的规划文档，标题、媒介类型、来源等。
- `outline.md`，是GPT出的，我决策，说白了就是我放进来的。
- `storyboard.md`，有可能和`outline.md` 是一份文件。也是我放进来的。
- `shot.md`，分镜头详细设计，可能和`outline.md`是一份，也可能分开，也是我放进来的。
- `series.md`，全局索引这个应该放到`projects/`下，而不是具体项目`projects/xxx-project/`里
- `execution-package.json`，按我的理解这里就是分镜头的资料，也是我放进来的。
- `sessions/`，和`shots/`我理解是一个东西吧。

写作库的说明：
- 这里有一个跑20多回合的分解文件：`C:\Users\wangq\Documents\Codex\writing-workbench\projects\水晶裹尸布与生命体\drafting\drafting.md`，这个是基于原始提纲`C:\Users\wangq\Documents\Codex\writing-workbench\projects\水晶裹尸布与生命体\outline\水晶裹尸布与生命体提纲4.2.md`的分解；
- 写作的素材文件，我放在`C:\Users\wangq\Documents\Codex\writing-workbench\projects\水晶裹尸布与生命体\intake\背景资料.md`

---

综上，我的想法是：

- `projects/series.md`，记录系列索引。现在可以不建立。需要的时候再建立，因为隐约觉得一个文件不够，可能需要的是`projects/_series/`，这样保证系列文件夹在最上面。
- `projects/xxxproject/intake/`，所有我放入的内容，包括总纲，分镜头清单，分镜头详设（execution-package），及其他GPT的所有产出。因为现在没产出，没试验，不知道产出是个啥。我们可以在首次测试的时候约定下面具体的文件名。
- `projects/xxxproject/project.md`，你简化记录项目的资料文件，内容部分都不要或者简化，因为intake里面有。这里其实可以记录的是文件链接，intake中哪些文件对应总纲，分镜头清单啥的，你给自己的关于项目的小抄。属于项目管理资料，不是项目内容资料。
- `sessions/`和`shots`我觉得都不太准确，叫`slides/`吧。`slides/s01/`放分镜头/PPT的第一页所有你产出的内容。具体文件名，在执行到这里时确定。
- 可能还需要一个mapping，类似于写作库的`drafting.md`，既做mapping又用于记录你的每个分镜的执行进度。这个放在`projects/xxxproject/slides/`下就可以。


其他的，

- `schemas/`，这里面放啥？
- `examples/`，这里面呢？
- 需要一个`handoff/`，解决会话窗口不足，做交接文档
- `garden-gpt-image-2`，每次调用生图，会有这个路径，不行就保留吧
- `intake`，这个我刚自己建的，没地方放GPT给的说明，临时放这里。这个文件夹我已经删掉了，上下文归档到了知识库里：`C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\technology\Codex\6.建立视频库\Codex 上下文：初始化 video-workbench 项目.md`
- `templates/`、`indexes/`不知道做什么用的，需要你解释
- `tmp/`，本项目的临时目录，这个就放这里吧。

---

最后CCPE整理出来了一个接口文档，将来会留CCPE的接口相关目录。这个和现在这些都不冲突，后面再说。
`ccpe-consumption`，这将来会重构。

---

基于以上，你有什么想法？

我基本同意你的新结构，而且这次职责边界更清楚了。

我会把 `video-workbench` 定义成：**项目管理和执行落盘区，不是内容创作源头，也不是审计系统**。GPT 产出和你决策放入 `intake/`；我维护 `project.md` 和执行进度；真正生成的图片、音频、PPT页资产按 `slides/s01/` 这种工作单元集中放。

我建议的项目结构是：

```text
projects/
  _series/              # 需要系列管理时再建
  xxxproject/
    project.md          # Codex 维护的小抄和索引
    intake/             # 你放进来的 GPT 规划、分镜、执行包、资料
    handoff/            # 会话不足时的交接
    slides/
      slides.md         # 分镜/页面 mapping + 执行进度
      s01/
        ...
      s02/
        ...
```

`project.md` 不应该复写内容。它只记录这些东西：项目状态、媒介类型、来源链接、当前使用哪些 intake 文件、哪个文件是总纲、哪个文件是分镜清单、当前执行到哪一页/哪一镜、下一步是什么。也就是“给 Codex 续作看的项目小抄”。

`intake/` 是用户/GPT 输入区。总纲、分镜清单、分镜详设、execution-package、背景资料、参考图说明，都先放这里。首次真实测试后再约定文件命名，不提前规定死。

`slides/` 这个名字比 `shots/` 更合适，因为它兼容两种形态：视频分镜和 PPT 页面。`slides/slides.md` 对应写作库的 `drafting.md`：既是 mapping，也是执行进度表。`slides/s01/` 放第 1 个分镜/PPT页相关的所有执行产物，避免提示词、口播、图片、音频散到不同目录。

`series` 我建议先不做单文件 `projects/series.md`，按你说的保留成未来的 `projects/_series/` 更稳。因为系列可能不止一个索引文件，后面可能会有系列总设定、人物一致性、视觉母版、集数顺序等。

我对几个现有目录的判断：

- `schemas/`：放 JSON Schema，只服务于“检查 GPT 给的 execution-package 是否基本可执行”。可以建，但不是项目工作流必经目录。
- `examples/`：放给 GPT 知识库看的样例执行包。它是训练 GPT 输出格式的参考，不是项目资料。
- `templates/`：现在是旧结构下的模板，后面应该大幅简化成 `project.md` 模板、`slides.md` 模板、`slide.md` 模板，或者干脆先不模板化。
- `indexes/`：旧 active/completed 思路的残留价值不大。新结构下项目状态在 `project.md`，系列关系在 `_series/`。
- `garden-gpt-image-2/`：可以暂留，算工具运行痕迹/提示词落盘区；等图像流程跑顺后再决定是否并入具体 `slides/sxx/`。
- `tmp/`：保留为本仓库临时目录，没问题。
- `ccpe-consumption/`：先不碰，等 CCPE 接口目录定稿后再重构。

我现在的推荐方案是：先把旧文档里的 `series/standalone/active/completed` 思路撤掉，改成 `projects + intake + slides`。不要急着建 `schemas/examples`，除非下一步目标是同步 GPT 知识库的 `20_SYSTEM` 和 `21_SYSTEM`；如果只是先跑第一个真实视频项目，最小结构只需要 `projects/<project>/project.md`、`intake/`、`slides/slides.md`、`handoff/`。

# 4

只有一个调整，`handoff/` 应该放在`C:\Users\wangq\Documents\Codex\video-workbench\handoff`。若放到具体项目下时：
1. `video-workbench`的讨论交接没地方放
2. 跨项目的交接，比如系列时，没地方放

其他，其实还有基于项目的角色定妆照、场景公共脚本等，这个等后面开始试运行时，遇到了再一个个具体确定。

---

基于以上，先对文件夹做一个清理，提交。

已完成文件夹清理并提交。

本次提交：`94043fa chore: simplify video workbench structure`

主要变化：
- 新增根部 `projects/`、`handoff/`，用 `.gitkeep` 保留目录。
- 保留 `tmp/` 和 `garden-gpt-image-2/` 作为本地运行目录，但用 `.gitignore` 忽略其中生成内容，只提交目录本身。
- 删除旧的 `series/`、`standalone/`、`indexes/`、`templates/` 结构。
- 更新 [README.md](C:/Users/wangq/Documents/Codex/video-workbench/README.md)、[VIDEO_WORKBENCH.md](C:/Users/wangq/Documents/Codex/video-workbench/VIDEO_WORKBENCH.md)、[docs/context-handoff.md](C:/Users/wangq/Documents/Codex/video-workbench/docs/context-handoff.md)，改成 `projects/<project>/intake/` + `slides/slides.md` + `slides/sNN/` 的轻量结构。
- 微调 [PROJECTS.md](C:/Users/wangq/Documents/Codex/video-workbench/PROJECTS.md) 和 [ccpe-consumption/runtime-links.md](C:/Users/wangq/Documents/Codex/video-workbench/ccpe-consumption/runtime-links.md)，去掉旧的 adapter 暗示。

验证：
- `git status --short` 为空。
- 旧路径检索无命中：`series/active`、`standalone/active`、`templates/episode-project`、`indexes/`、`adapters/`。
- 现有测试图片和 `garden-gpt-image-2/prompt/` 被保留为 ignored 本地文件，未进入提交。

::git-stage{cwd="C:\Users\wangq\Documents\Codex\video-workbench"}
::git-commit{cwd="C:\Users\wangq\Documents\Codex\video-workbench"}

# 5

现在看GPT需要的这两个文件`20_SYSTEM_video-workbench项目说明`，`21_SYSTEM_Codex_JSON执行样例`，应该怎么构造。
你有什么思路？

如果需要，可以查阅`C:\Users\wangq\Documents\Codex\knowledge-vault\prompts\GPT\强哥的策划导演\`目录下的相关文件，里面其实是你工作之前的GPT工作的参考，你可以了解到它怎么做的，案例/样例是什么。

我的判断：这两个文件应该是 **GPT 的“执行接口记忆”**，不是再写一套流程方法论。

现有核心附录已经负责内容创作规则：媒介路由、分镜模板、PPT 模板、Codex 执行包字段。`20_SYSTEM` 和 `21_SYSTEM` 只需要告诉 GPT：**当前 video-workbench 真实长什么样、Codex 能做什么、JSON 应该怎么落到这个结构里**。

**20_SYSTEM 的定位**
`20_SYSTEM_video-workbench项目说明.md` 应该短、硬、边界清楚。建议结构：

1. 项目定位：video-workbench 是本地执行工作台，不是内容源头，不是成片发布系统。
2. 三方协作：GPT 规划，你决策和放入材料，Codex 维护 `project.md`、执行资产。
3. 当前真实目录：
   ```text
   projects/<project>/project.md
   projects/<project>/intake/
   projects/<project>/slides/slides.md
   projects/<project>/slides/s01/
   handoff/
   tmp/
   garden-gpt-image-2/
   requirements/
   ccpe-consumption/
   ```
4. 文件职责：`intake/` 放用户给的 GPT 产出；`project.md` 只做小抄和文件映射；`slides/sNN/` 放单页/单镜的所有执行产物；`handoff/` 放跨项目/跨会话交接。
5. 当前能力：可通过 Skill 做文生图、图生图提示词整理、语音生成；不默认自动剪辑、不默认图生视频、不默认发布。
6. GPT 行为约束：不要要求 Codex 生成不存在的系统能力；不要把正文文字塞进图片 Prompt；路径必须按 `projects/<project>/...` 写。

这个文件应该引用当前仓库事实，比如 [VIDEO_WORKBENCH.md](C:/Users/wangq/Documents/Codex/video-workbench/VIDEO_WORKBENCH.md:19) 和 [README.md](C:/Users/wangq/Documents/Codex/video-workbench/README.md:19)。

**21_SYSTEM 的定位**
`21_SYSTEM_Codex_JSON执行样例.md` 应该是可复制的 JSON 写法手册。它要解决 GPT 最容易错的事：路径、任务颗粒度、字段命名、什么该放进 `intake/`、什么该放进 `slides/sNN/`。

建议结构：

1. 执行包基本原则：JSON 是给 Codex 执行，不要混 Markdown 解释。
2. 项目级字段：`project`、`inputs`、`outputs`、`global_style`、`tasks`、`acceptance_criteria`、`notes_for_codex`。
3. 路径规则：
   ```text
   projects/<project-id>/intake/<source-file>
   projects/<project-id>/slides/slides.md
   projects/<project-id>/slides/s01/image-prompt.md
   projects/<project-id>/slides/s01/voiceover.md
   projects/<project-id>/slides/s01/image-v1.png
   projects/<project-id>/slides/s01/voiceover-v1.wav
   ```
4. 任务类型：
   - `write_project_note`
   - `write_slides_mapping`
   - `text_to_image`
   - `image_to_image`
   - `generate_voiceover`
   - `create_slide_asset`
   - `write_markdown`
   - `write_json`
   - `export_assets`
5. 示例一：科普视频/PPT 式播放，按 `slides/s01/`、`slides/s02/` 给任务。
6. 示例二：培训/科普 AI PPT，体现 `slide_copy`、`layout`、`speaker_notes`、`visual_asset_prompt` 分离。
7. 示例三：口播音频，只生成 `voiceover`，不伪造视频。
8. 示例四：MV/图生图，要求 `reference_image`，路径放在项目 `intake/` 或 `slides/sNN/`。
9. 校验规则和常见错误。

这里要参考案例颗粒度：视频案例已经明确“图片 Prompt 不负责文字、口播负责解释、需要执行时再抽 JSON”这一点，[30_CASE](C:/Users/wangq/Documents/Codex/knowledge-vault/prompts/GPT/强哥的策划导演/30_CASE_典型视频分镜案例.md:880)；培训 PPT 案例也明确页面文案、讲师备注、生图 Prompt 要分开，[31_CASE](C:/Users/wangq/Documents/Codex/knowledge-vault/prompts/GPT/强哥的策划导演/31_CASE_典型培训AI_PPT案例.md:823)。

**一个必须注意的问题**
现在 `00_CORE_附录E_Codex执行包Schema.md` 还是旧路径倾向，比如 `outputs/images/...`，而 GPT 主指令里核心附录优先级高于 SYSTEM 文件。[主指令](C:/Users/wangq/Documents/Codex/knowledge-vault/prompts/GPT/强哥的策划导演/强哥的策划导演.md:302)

所以只写 `20_SYSTEM` 和 `21_SYSTEM` 还不够稳。最好同步做一个很小的修正：把 `00_CORE_附录E` 的路径语义改成“字段结构以附录 E 为准，真实目录和 output_path 以 21_SYSTEM 为准，默认落到 `projects/<project>/slides/sNN/`”。否则 GPT 可能一边读 SYSTEM，一边又被更高优先级的旧 schema 拉回 `outputs/`。

我的推荐顺序：

1. 小修 `00_CORE_附录E`：只改路径语义，不改大结构。
2. 写 `20_SYSTEM`：真实项目说明，短而硬。
3. 写 `21_SYSTEM`：新目录下的 JSON 样例，覆盖视频、PPT、口播、MV。
4. 暂不做 `schemas/` 和 `examples/`；等第一次真实执行包跑完，再从真实样例沉淀。

# 6

同意你的推荐顺序。
`00_CORE_附录E`，最好也声明现在连试运行都没跑，很多路径没落实，会在试运行后落实。甚至现在的路径将来也可能调整。

你直接修知识库对应的文档吧，我自己同步到ChatGPT上。

已按你确认的顺序直接更新知识库里的 3 个文件，没有改 `video-workbench` 的正式文件。

更新了：

- [00_CORE_附录E_Codex执行包Schema.md](C:/Users/wangq/Documents/Codex/knowledge-vault/prompts/GPT/强哥的策划导演/00_CORE_附录E_Codex执行包Schema.md:1)  
  增加“当前仍是试运行前、路径未最终落实、试运行后可能调整”的声明；明确旧案例里的 `outputs/images/...` 只作字段颗粒度参考，真实路径以 `20_SYSTEM` / `21_SYSTEM` 为准。

- [20_SYSTEM_video-workbench项目说明.md](C:/Users/wangq/Documents/Codex/knowledge-vault/prompts/GPT/强哥的策划导演/20_SYSTEM_video-workbench项目说明.md:1)  
  写成 GPT 端理解 video-workbench 的系统说明：三方分工、当前 `projects/<project>/intake/` + `slides/sNN/` 结构、根部 `handoff/`、当前能力状态和边界。

- [21_SYSTEM_Codex_JSON执行样例.md](C:/Users/wangq/Documents/Codex/knowledge-vault/prompts/GPT/强哥的策划导演/21_SYSTEM_Codex_JSON执行样例.md:1)  
  写成 JSON 执行包样例手册，包含路径规则、任务类型、科普视频、培训 PPT、口播、MV 图生图、最小可执行 JSON 示例。

验证做了两项：
- 目标文件已写入，大小分别为 `5190`、`6174`、`16409` 字节。
- `00_CORE` 和 `21_SYSTEM` 里的 7 个 JSON 代码块都用 `ConvertFrom-Json` 解析通过。

我也清理了本次使用的临时脚本和中间文件。`video-workbench` 当前没有新增未跟踪工作文件，只剩原本被忽略的图像测试材料。`knowledge-vault` 里这个 GPT 目录当前在 Git 状态里仍显示为未跟踪目录，我没有替你提交。

# 7

现在继续修正规则和目录。

1. 我所有的文档都是UTF-8格式，你后续阅读文档，比如调用powershell时，都默认用UTF-8。记录到规则
2. `C:\Users\wangq\Documents\Codex\ccpe-system\Interface.md`是CCPE对外的接口文件，你阅读后，检查本地相关的记录和文件夹，看哪些有冲突。