205 lines
9.9 KiB
Markdown
205 lines
9.9 KiB
Markdown
# 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"}
|