# 1

`projects/2026-06-23-在路上/`是我刚建立的项目。
现在已经完成了与策划的全部讨论。

由于，现在尚未完整跑过完整流程。
我们本次以这个项目为试运行项目，既有探索的部分——涉及到规则调整，又有项目的实操部分。

所有GPT的产出，我已经全部放在`intake/`下。

你可以先阅读`第一轮策划工作总结.md`，了解前五个阶段都做了什么。

通过`阶段三-MV 总纲.md`可以了解到这个视频工作的整体方向。

---

我有几个问题：
1. GPT的回复格式是乱的，我们可能需要一个清理/修正的工作。它的回复总是经常性标题错乱，所以这个我们可能需要一个工具——Skill。
2. 现在的md格式，是否能支撑后续轮次的工作进展？
   我们是否需要以intake为原版，从里面提炼出来更易于后续工作开展的形式的文档。
3. 阶段四的文档比较多。我理解的是，这个应该算是公共的内容；或者基于公共能力/规则，就能产生的文档。
   这个说明一下，之前旧项目`2026-06-22-在路上`已经删除了，当时发现的问题就是人物形象不一致。然后做了这些调整：
   1. 调研发现Codex的skill生图提示词比GPT稳。从GPT中剥离生图提示词能力，交给Codex；对video-workbench做了重构。解决场景对人物的形象提示词的控制问题。
   2. 以前没有阶段四，人物造型/公共风格这些，这是重点打造的。
   3. 旧项目类似于`写真`，而本次类似于风景或纪录片，从风格上降了级。

---

在正式开始前，谈谈你的问题和想法。

**我的判断**

同意，`fix-title` 能力不够。它现在只是“把 ATX 标题整体加 N 级”的小工具，适合把 GPT 回复塞进某个父标题下面；但你这个场景需要的是：

- 识别 GPT 回复里的闲聊开头、过渡语、重复标题；
- 修正“多个 `#` 顶级标题并列”的结构问题；
- 保留 `intake/` 原文；
- 生成更适合 Codex 后续执行的派生文档；
- 最好能输出清洗报告，而不是静默改写。

所以我不建议把当前项目直接建立在 `intake/` 这些原始 GPT Markdown 上。`intake/` 应该作为原版归档；正式执行层应从中提炼出 `project.md`、`execution-plan.md`、`visual-system/visual-system.md`、`slides/slides.md` 这类本地执行文档。

**关于 Skill**

我更倾向于新建或重命名成一个更准确的 Skill，比如：

`normalize-llm-markdown-intake`

而不是继续叫 `fix-title`。因为这已经不是“修标题”，而是“清洗 LLM 策划稿并生成可继续工作的 Markdown 结构”。`fix-title` 可以保留为其中一个低层脚本或子能力。

按当前仓库边界，这个能力属于 `skills-vault`，`video-workbench` 这里可以先写一个 `requirements/skills-vault/` 需求单，把本项目的这些 `intake/` 文件作为真实压力样本。

**关于阶段四**

阶段四不是普通项目杂项，它是这次试运行的关键新增层：人物锚点、风格锚点、镜头规则、母题规则。它有两种属性：

- 项目内公共规则：本支 MV 全部镜头都要遵守；
- 可复用能力雏形：人物锚点板、风格锚点板、审图规则这套流程未来别的 MV 项目也会用。

所以我建议先把阶段四提炼成 `visual-system/` 下的执行态文档，再从中判断哪些值得沉淀成通用 Skill 或模板。

**我建议下一步**

先不开始生图，也不直接展开 51 镜。先做两个小闭环：

1. 写 `requirements/skills-vault/llm-markdown-intake-normalizer.md`，定义这个新 Skill/改造 Skill 的真实需求。
2. 把本项目 `intake/` 提炼成执行态骨架：项目索引、执行计划、视觉系统、镜头表初版。

我的关键问题只有一个：你是希望我先在 `video-workbench` 里写这个 `skills-vault` 需求单，还是直接切到 `skills-vault` 源仓开始改造 Skill？

# 2

你提出 `skills-vault` 需求单，我到 `skills-vault` 里建技能。
这个应该是第一步，现在的文档格式容易让人产生误解。
直接从这个文档里抽取资料，容易错误。

---

等`intake`文档OK了，再抽执行态骨架。

你是否同意？

同意。顺序应该是：

1. 先把 `intake/` 变成可信的清洗输入层；
2. 用户确认清洗结果 OK；
3. 再从清洗后的文档抽取 `project.md`、`execution-plan.md`、`visual-system/`、`slides/` 这些执行态骨架。

我已经在 video-workbench 提了需求单：[llm-markdown-intake-normalizer.md](<C:\Users\wangq\Documents\Codex\video-workbench\requirements\skills-vault\llm-markdown-intake-normalizer.md>)。

这个需求单明确了：不覆盖原始 `intake/`，不做执行态抽取，不生成提示词；只做 LLM Markdown intake 清洗、标题结构修正、聊天壳识别、重复/拼接内容检测和清洗报告。你可以据此到 `skills-vault` 建技能。

# 3

`fix-title`技能已经更新了，可以用来修复intake的文档。

调用`fix-title`，我觉得：
1. 可以直接覆盖原始文档
2. 调用时，还有report什么的，放哪里？
3. 用Agent/子会话，不撑爆当前主会话
4. 可以一次性传入所有的intake，让它批量做

你核对一下。


同意使用新版 `fix-title`，但第 1 点我建议改成：

**可以最终覆盖原始文档，但不要让子代理第一步直接覆盖。**

更稳的流程是：

1. 子代理批量处理全部 `intake/*.md`，`mode=artifact`。
2. 输出 fixed 文件、heading-map、heading-plan、单文件 report、batch report。
3. 主会话核查 report 和抽样 fixed 文件。
4. 核查 OK 后，再用 fixed 文件覆盖原始 `intake/*.md`。

这样既满足你“intake 最终就是修好的文档”的目标，也避免一次语义修复失误后直接污染原始文件。

**Report 放置**

建议放这里：

`projects/2026-06-23-在路上/intake-repair/fix-title-2026-06-23/`

这个目录里放：

- `*.fixed.md`
- `*.heading-map.json`
- `*.heading-plan.json`
- `*.heading-report.md`
- `fix-title-batch-report.md`

不要放进 `intake/` 根目录，避免后续抽取时把 report 当作 intake 正文。

**子会话**

可以用子代理。当前环境已经有 `spawn_agent`，而新版 skill 也明确 Codex 优先用 subagent。这里不需要开用户可见的新 Codex Thread，除非你想在侧边栏保留一个独立线程记录。

**批量**

可以一次性传入所有 `intake/*.md`，不传 `imgs/`。模式统一用 `artifact`，因为这些是独立策划/产物文档，不是讨论记录。

我建议下一步就按这个策略跑：子代理生成修复输出和报告，主会话核查后再覆盖原始 `intake` Markdown。

# 4

同意。

已按你确认的方式跑完。

`fix-title` 通过子代理批量处理了 9 个 `intake/*.md`，报告和中间产物放在：

[fix-title-2026-06-23](<C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23>)

我已经把修复结果覆盖回原始 `intake/`。同时做了三处主会话裁决：

- `第一轮策划工作总结.md`：补了文件名标题，并把原有标题整体降一级。
- `阶段五-镜头清单骨架.md`：只保留镜头清单本体；拼接进去的关键单镜和第一轮总结块没有丢，分别已有独立文件和原始备份。
- `阶段四-人物锚点板文案标注稿.md`：补了文件名标题，把 GPT 解释句降为二级标题。

原始 Markdown 已备份在：

[originals-before-replacement](<C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\originals-before-replacement>)

验证结果：

`VERIFIED intake_md=9 h1_each=1 backups=9 heading_reports=9 skeleton_appended_markers=0`

当前没有 staging/commit。`git status` 仍显示整个新项目目录和之前的 `requirements/skills-vault/llm-markdown-intake-normalizer.md` 是 untracked。

# 5

我们可以继续了，从清洗后的文档抽取骨架。

已从清洗后的 `intake/` 抽出执行态骨架，新增了：

- [project.md](<C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\project.md>)
- [execution-plan.md](<C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\execution-plan.md>)
- [visual-system/visual-system.md](<C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\visual-system\visual-system.md>)
- [slides/slides.md](<C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\slides\slides.md>)

也创建了 `visual-system/refs`、`iterations`、`characters`、`scenes` 目录，供后续锚点板和测试资产落盘。

骨架里的当前执行路径是：先人物锚点板，再风格锚点板，然后做五镜测试包：`S-01`、`S-10`、`S-46`、`S-47`、`S-51`。`slides.md` 已把 51 个镜头都抽成执行事实表，但没有开始写最终 prompt。

验证已跑过：

`VERIFIED files=4 h1_each=1 shot_rows=51`  
`VERIFIED intake_refs=9`

当前 `git status` 仍显示整个新项目目录和之前的 `requirements/skills-vault/llm-markdown-intake-normalizer.md` 是 untracked。

已提交：`1af1ce1 Initialize On The Road video project`。

提交后我核对了 `git status --short`，输出为空，工作区干净。之前的结构校验结果也在本轮收口前确认过：`skeleton_files=4`、`shot_rows=51`、`intake_md=9`、`intake_h1_each=1`。

我的建议：第 6 阶段开新会话，不要继续靠本会话压缩。现在关键上下文已经落盘，新会话只需要首读：

`project.md` → `execution-plan.md` → `visual-system/visual-system.md` → `slides/slides.md`

然后从人物锚点板、公共风格锚点、五镜头试跑开始。这样第 6 阶段的生图提示词、资产验证、规则调整不会混在这次 intake 清洗和骨架抽取的长上下文里。

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