22 KiB

Raw Blame History

《在路上》项目从无到有到全量 slide 完成：文章素材文案

文档定位

类型：文章素材底稿 / case material。
用途：为未来写一篇关于 video-workbench 和《在路上》项目实践过程的文章提供素材、时间线、案例细节和可引用表述。
状态：素材草稿，不是工作流规则，不替代 VIDEO_WORKBENCH.md、project.md、execution-plan.md 或 slides/slides.md。
项目路径：projects/2026-06-23-在路上。
当前项目状态：当前 51-shot 表的 shot-image production 已完成，项目进入 assembly / closeout 待启动阶段。

一句话主线

这个项目的关键，不只是“用 AI 生成了 51 个画面”，而是从一个还没有稳定形状的视频工作台开始，把一套 GPT 前期策划，逐步压缩成本地可执行的项目骨架、视觉系统、参考图规则、slide 生产流水线、子会话协作机制和生产轻量化规则，最后完成了《在路上》当前 51-shot 表的全部图片生产。

更准确地说，它完成了两件事：

《在路上》作为一个 MV / slide-image 项目，从策划文本变成了有视觉系统、有角色锚点、有 51 个画面单元、有完整图片产物的本地生产包。
video-workbench 作为一个工作台，从“需要摸索机制”演化成了“能用 production-light 直接批量生产，并靠 handoff / callback 可靠续跑”的工作流。

可直接放进文章的开场素材

一开始，video-workbench 并不是一个已经完全定型的生产系统。它更像一个本地工作间：有方向，有一些相邻仓库，有 GPT 输出的前期规划，也有 Codex 可以执行的本地文件系统，但真正的问题是，怎样把这些东西变成一个可持续生产的视频项目。

《在路上》就是这个工作台的第一个完整压力测试。

它不是从一张 prompt 开始的，也不是从“批量生成 51 张图”开始的。它从一组已经被接受的 GPT V2 策划材料开始：MV 总纲、通用表达与视觉系统设计、人物锚点板说明、风格锚点板结构、51-shot 镜头骨架、核心单镜扩展。Codex 的任务不是再写一遍策划，而是把这些材料转成仓库能持续执行的控制文件。

这一步很关键。因为真正能把项目带到结尾的，不是更长的灵感文本，而是几个能被反复读取、被子会话继承、被任务记录续接的文件：project.md、execution-plan.md、visual-system/visual-system.md 和 slides/slides.md。

从那一刻开始，《在路上》不再只是一个构想，而变成了一个本地生产项目。

阶段一：工作台先定边界

在项目早期，video-workbench 最先解决的不是图片，而是边界。

仓库被明确成一个“本地视频 / slide 执行工作台”，不是深度文章写作区，不是长期知识库，不是 CCPE canonical agent 存放地，也不是可复用自动化源码仓库。它和周边仓库的关系被切清楚：

knowledge-vault 提供长期知识和来源材料。
writing-workbench 负责深度文章生产。
ccpe-system 提供正式 agent / runtime / model / interface。
skills-vault 提供可复用自动化技能。
video-workbench 只负责把已接受的策划和来源材料，落地成视频 / slide 项目的本地执行文件、素材、prompt、图片和 handoff。

这个边界后来非常重要。它避免了一个常见问题：把 GPT 的规划文本、Agent 机制、Prompt 模板、项目产物、工具源码全部塞进一个目录，最后谁也不知道哪个文件才是当前事实。

最终形成的规则是：真实项目都进入 projects/<project-id>/；项目状态写在文件里，不靠移动目录表达；跨阶段交接写在 handoff/；可复用能力缺失时写 supplier request，而不是在项目里临时发明一套不可复用工具。

阶段二：从 GPT 策划到本地执行骨架

《在路上》的输入不是空白 prompt，而是一批前期策划文件。Codex 先把它们安置在 intake/，再从中抽取本地执行骨架。

这一步形成了四个核心文件：

project.md：项目地图，记录状态、阶段、已接受输入、核心方向、当前执行重点和下一步。
execution-plan.md：执行控制文件，记录当前 medium branch、小批量策略、已完成轮次、当前默认生产路线。
visual-system/visual-system.md：视觉系统权威文件，记录人物、风格、色光、构图、母题和关键镜头规则。
slides/slides.md：51-shot 的执行事实表，记录每个 sNN 单元的来源、功能、风格锚点、状态和产物。

这里有一个方法论转折：GPT 策划不是被复制成新的“真相文件”，而是被保留为来源。Codex 维护的是执行控制层。

这套骨架让项目有了长期可读性。后续无论主会话压缩、子会话切换、任务中断、图片失败、prompt 重试，都可以回到这几个文件上继续，而不是依赖某一段聊天记忆。

阶段三：视觉系统先于批量生产

《在路上》的视觉核心后来被凝练成一句话：

世界比人更大，路比人更长，人只是持续前行的坐标。

英文控制句是：

World before face; road before pose; the traveler is a small coordinate that keeps moving.

这个规则决定了整个项目不是 portrait MV，也不是旅行宣传片，而是 landscape-led road documentary / poetic realism。

视觉系统被拆成几个稳定部件：

人物：50 岁男性旅人，疲惫但没有垮掉，旧长外套、旧背包、旧靴子，形象要能持续走下去。
风格 A：清晨泥泞旷野，世界先于人出现。
风格 B：高位观察和城市边缘，表现系统压力。
风格 C：泥泞里的星空，低处看见宇宙，是项目的灵魂画面。
风格 D：夜路小火，远方也有人在走，但不是团聚、胜利或露营。

第一批真正重要的生产不是全量镜头，而是锚点验证：

人物锚点板 accepted。
从人物锚点板切出的透明人物切片 accepted。
风格锚点板 accepted。
C 风格修复样本 accepted。
五个核心镜头 S-01、S-10、S-46、S-47、S-51 accepted。

这一步证明了项目的视觉方向：画面可以保持现实质感，也可以有诗性，但不能变成广告、英雄海报、赛博城市、魔法宇宙、露营团建或胜利结尾。

阶段四：第一次大问题不是审美，而是引用路径

项目早期曾经出现过一个关键问题： broad generation 的画面能出，但缺少可追溯的 per-shot prompt、真实参考图加载证据和稳定的身份控制。尤其是人物一致性场景，不能靠文字描述去维持身份。

这促成了 S14 reference-capable generation investigation。

最后沉淀下来的规则是：

gpt-image-2 Skill Advisor prompt/spec
-> 把真实参考图加载进对话可见上下文
-> 使用宿主 image_gen 生成
-> 把结果复制进项目目录
-> 在 prompt / handoff / slides.md 中记录参考角色和产物路径

这个结论非常重要。它把问题从“AI 能不能参考图片”转成了“项目文件怎样记录参考图片被如何使用”。也就是说，技术可行性不再反复争论，后续重点转向生产追踪和工作流清洁度。

从这里开始，gpt-image-2 在项目中承担的是 prompt/spec Advisor，而不是默认 Garden / API 出图路径。身份关键画面必须加载真实参考图；在 prompt 里写本地路径只算 traceability，不算真正加载。

阶段五：从单张试验到 slide task orchestration

为了让长生产可控，项目把每个画面、页面、镜头单元统一叫 slide。每个 slide 有自己的目录：

slides/sNN/
  sNN-vN-brief.md
  sNN-vN-prompt.md
  sNN-vN-image.png
  sNN-vN-review.md   # 只在 test/audit 或显式 review 时出现

这里又形成了一个重要原则：append-only。

每次新执行都扫描已有 sNN-v*-* 文件，选择下一个未占用版本。旧版本即使失败，也保留为历史证据。默认 Overwrite allowed: no。

这个规则不是形式主义。它是从实际失败里长出来的。早期有 broad-run 候选、覆盖缺陷、重复 worker、transport failure、 rejected image、incomplete evidence。只要允许“为了让目录好看而覆盖旧文件”，项目历史就会被抹掉，后续根本无法判断哪个 prompt 生成了哪个图，哪个失败被修复过，哪个版本是用户真正接受的。

所以最终形成的共识是：失败不是垃圾，失败是生产系统的一部分证据。

阶段六：Agent 流程的试错

角色一致性阶段最早使用的是主会话、可见子会话和内部 one-shot slide Agent 的组合。

这个阶段产生了很多有效结果，也暴露了机制问题：

S-05 单张试验证明了 reference-capable route 可以跑起来，但也留下了 overwrite defect 的历史记录。
S-21、S-14、S-25 等画面视觉上被接受，但 S-14 出现了 duplicate worker 问题。
session-04 处理 S-33 和 S-06，形成更干净的 visible child session + one-shot SubAgent 模式。
R4 处理 S-02、S-03、S-04 时，图片被接受，但 brief / packet ownership 出现偏差：文件由 slide Agent 写，而不是由 visible child session 预先拥有。
R5 处理 S-07、S-08、S-09 时，修正了 brief ownership，让成功输出在 worker 启动前已有 child-owned brief / packet。

这一段的意义在于：项目并不是一次设计出完美工作流，而是用实际画面生产暴露机制缺陷，再把缺陷转成规则。

早期的 Agent 并不是失败。它们帮助证明了 per-slide isolation、返回 receipt、reference role、review suppression、append-only retry 等机制。但当项目进入正式生产时，这套机制显得太重。

阶段七：callback-only 和父子会话关系定型

长任务真正可持续，还需要解决一个上下文问题：主会话不能一直盯着子会话轮询，也不能把所有生产细节都塞回父线程。

R6 阶段把 callback-only 流程验证出来：

子会话完成所有允许的项目写入。
子会话更新 slides/slides.md。
子会话写 compact child-session-handoff.md。
子会话最后一步 callback 父会话。
callback 后子会话不再写文件、不再检查项目。

这改变了主会话的职责。主会话不再是细节审计员，而是调度者和用户接口。它只需要读 callback 和 handoff 中的关键字段：

status；
topology；
resolved versions；
image paths；
problems；
needs_user。

如果 clean completion，没有问题，父会话就不再打开 prompt、图片细节、return ledger 重新审一遍。

这一步对后来的批量生产非常关键。它把生产从“人盯着每个 worker 过程”变成“文件状态 + callback 驱动的可续跑流程”。

阶段八：从 test/audit 到 production-light

项目真正提速发生在 R7。

在 R7 之前，很多生产还围绕 Agent / packet / return / review / completion gate 展开。这适合 test/audit，但不适合正式批量生产。

R7 的核心优化是 production-light：

normal production 由 clean child session 直接完成。
不默认启动 Agent / SubAgent。
不默认写 packet / return。
不默认写 review 文件。
不做 routine final audit。
保留必要的写入保护：版本扫描、append-only、no overwrite、slides.md 更新、compact handoff、callback final action。

这个优化不是偷懒，而是把已经被证明的流程从“测试形态”压缩成“生产形态”。

session-12 先生成 S-26、S-27、S-28，用户接受，记录约 25m48s / 134K tokens。

session-13 再生成 S-29、S-30、S-31，直接 child session、无 Agent/SubAgent，用户接受，记录约 10m32s / 114K tokens。

从 session-13 开始，direct-child production-light 成为正式默认模型。

阶段九：容量验证

生产路线定型后，项目继续做容量验证，而不是立刻假设可以无限扩张。

先是 5-slide validation：

范围：S-32、S-34、S-35、S-36、S-37。
topology：direct child。
review：none。
结果：五张图被用户接受。
用户观察：callback 时约 152K tokens / 58% context；最终约 164K tokens / 63% context。
发现：callback-order defect，子会话在 callback 后仍做了部分文档 / 检查工作。
修正：未来 child prompt 必须明确 callback 是最终动作。

然后是 8-slide compression validation：

范围：S-38 到 S-45。
topology：direct child。
review：none。
结果：8 张图进入 production-pass。
用户观察：174K tokens / 67% context / 38m37s。
机制结果：callback-final contract 被验证，callback 后没有再观察到 child project writes 或 checks。

这一步把普通 production-light 子会话容量提升到最多 8 个 ordinary slides，同时保留降级规则：身份重、修复重、核心风险高或上下文昂贵的任务仍然用 1 到 3 个 slide。

阶段十：最后一包 S48-S50 收口

最后的默认生产范围只剩 S-48、S-49、S-50。

这一包已经不再是工作流发明，也不是机制辩论。它按已经定型的 production-light route 直接执行：

direct child session；
no Agent/SubAgent；
review mode none；
写 brief、prompt、image；
更新 slides/slides.md；
写 child-session-handoff.md；
callback 父会话作为最终动作。

最终记录：

S-48 -> s48-v1-image.png；
S-49 -> s49-v1-image.png；
S-50 -> s50-v1-image.png；
child reported complete；
problems: none；
needs_user: none；
parent verification found expected files present, review files absent, slide rows updated, and no post-callback child writes。

到这里，当前 51-shot 表的 shot-image production 完成。项目状态进入 assembly-closeout。

素材时间线

0. 工作台定位期

明确 video-workbench 是本地视频 / slide 执行工作台。
确立 projects/ 为唯一真实项目根。
确立 project.md、execution-plan.md、visual-system/、slides/、tasks/ 的职责。
确立 GPT / User / Codex 分工。

1. 《在路上》项目初始化

接收 GPT V2 前期策划文件。
清理 intake。
提取四文件执行骨架。
建立 51-shot slides/slides.md 事实表。
确立核心视觉方向：landscape-led road documentary / restrained poetic realism。

2. 视觉锚点建立

人物锚点板 accepted。
透明人物切片 accepted。
A/B/C/D 风格锚点建立。
C 风格修复 accepted。
五个 anchor-test shots accepted：S-01、S-10、S-46、S-47、S-51。

3. 参考图机制证明

S14 investigation 证明 host visible-context reference path 可用。
项目规则更新为 gpt-image-2 Advisor + loaded reference image + host image_gen。
identity-critical shots 不允许 text-only 身份生成。

4. 角色一致性和 per-slide traceability

从 S-05、S-21、S-14、S-25、S-33 等试验开始。
发现并记录 overwrite、duplicate worker、brief ownership、transport failure 等问题。
固化 append-only、no overwrite、one-shot worker、review suppression、visible-reference evidence 等规则。

5. callback-only 定型

子会话完成写入和 handoff 后 callback 父会话。
父会话不再 routine polling。
clean callback 后父会话只消费 compact handoff。

6. production-light 定型

session-12：S-26、S-27、S-28 accepted。
session-13：S-29、S-30、S-31 direct-child accepted。
direct-child, no-Agent, review none 成为正式生产默认路线。

7. 容量验证

5-slide validation：S-32、S-34、S-35、S-36、S-37 accepted，发现 callback-order defect。
8-slide validation：S-38 到 S-45 production-pass，验证 callback-final contract。
默认 ordinary package size 提升到最多 8 slides。

8. 完成当前 51-shot 表

final package：S-48、S-49、S-50 complete。
当前 51-shot shot-image production complete。
下一阶段转入 assembly / export / closeout。

可以支撑文章的几个观点

观点一：AI 生产不是 prompt 工程，而是本地执行系统工程

《在路上》不是靠一条万能 prompt 完成的。它靠的是文件结构、版本策略、参考图规则、子会话边界、callback、handoff 和生产线轻量化。

Prompt 很重要，但 prompt 只有在能被追溯、能被续跑、能和参考图 / 版本 / 输出路径绑定时，才真正成为生产资产。

观点二：失败记录比成功截图更有价值

项目里保留了 rejected image、incomplete evidence、transport failure、duplicate worker、sequencing warning、callback-order defect。它们没有被清掉，而是被转化为规则。

这些失败让系统知道：

不能覆盖旧文件；
不能把 text-only 当身份参考；
不能让 worker 抢写 brief；
不能 callback 后继续写文件；
不能每次都重开完整 audit。

观点三：正式生产不是更复杂，而是把复杂度收回去

早期 test/audit 需要 Agent、packet、return、review、completion gate。它适合发现问题。

但正式生产阶段，复杂度必须被压缩。production-light 的价值就是在保留必要安全线的前提下，去掉 routine review、routine audit、packet / return 和默认 Agent，把生产变成 direct-child package。

这不是降低标准，而是把“已经证明过的标准”变成更低成本的执行方式。

观点四：长任务续跑靠文件，不靠记忆

从 project.md 到 production-run-status.md，从 slides/slides.md 到 child-session-handoff.md，整个项目不断把聊天过程固化为可读文件。

这使得主会话压缩、子会话切换、上下文中断都不再是灾难。下一轮只要按 load order 读文件，就能继续。

观点五：人的角色不是每张图都 review，而是决定何时相信生产线

在 production-light 阶段，用户不再逐张 image review。用户做的是更高层的判断：

核心路线是否成立；
哪些包可以进入 production-pass；
默认生产容量能不能从 3 张提升到 5 张、再到 8 张；
什么时候停止生产，转入 assembly / closeout。

这改变了人机协作的焦点：人不是流水线质检员，而是生产路线的 owner。

可引用句子

《在路上》的完成，不是“生成 51 张图”的故事，而是“把一个不稳定的 AI 生产现场，逐步压成可续跑生产线”的故事。
GPT 给了方向，Codex 把方向变成文件系统里的执行秩序。
真正让项目继续下去的，不是某一次聊天记忆，而是 project.md、execution-plan.md、slides.md 和 handoff。
失败没有被抹掉。失败被留在版本里，变成下一条规则。
从 test/audit 到 production-light，核心变化不是更大胆，而是更克制。
生产线成熟的标志，不是记录越来越多，而是知道哪些记录可以不写。
当 callback 成为子会话的最后动作，长任务才真正从“盯进度”变成了“等状态”。
人不必 review 每张图，但必须决定什么时候一条路线已经值得信任。
这个项目的经验是：AI 创作要规模化，必须先把创作过程变成可追溯的本地工程。

文章可展开的结构建议

写法 A：项目复盘型

开头：为什么不是 prompt 成功，而是工作流成功。
第一部分：video-workbench 为什么要先定边界。
第二部分：《在路上》如何从 GPT 策划变成四文件执行骨架。
第三部分：视觉系统如何用 A/B/C/D 和人物锚点稳定下来。
第四部分：reference-capable generation 为什么是关键转折。
第五部分：从 Agent-heavy 到 production-light 的演化。
第六部分：容量验证和全量完成。
结尾：AI 视频生产的真正对象，是“可续跑生产线”。

写法 B：方法论型

输入不是 prompt，是 accepted intake。
输出不是图片，是 append-only project state。
审美不是感觉，是 visual-system rule。
失败不是删掉，是版本化。
协作不是等人盯，是 callback。
批量不是并行，而是轻量生产线。

写法 C：人机协作型

GPT 负责想象和策划。
用户负责决定与接受。
Codex 负责本地化、执行、记录和续跑。
子会话负责小批量生产。
文件系统负责记忆。
最后形成的不是一个 prompt，而是一套可被复用的生产经验。

关键证据路径

项目状态与结论：

projects/2026-06-23-在路上/project.md
projects/2026-06-23-在路上/execution-plan.md
projects/2026-06-23-在路上/slides/slides.md
handoff/2026-06-25-on-the-road-formal-production-handoff.md

视觉系统：

projects/2026-06-23-在路上/visual-system/visual-system.md
projects/2026-06-23-在路上/visual-system/style/style-prompt-master.md
projects/2026-06-23-在路上/visual-system/characters/character-reference-registry.md

工作流规则：

VIDEO_WORKBENCH.md
docs/workflows/project-lifecycle.md
docs/workflows/slide-task-orchestration.md
docs/workflows/slide-task-templates.md

关键 handoff：

handoff/2026-06-24-on-the-road-workflow-continuation-handoff.md
handoff/2026-06-24-character-consistency-r6-notification-s16-handoff.md
handoff/2026-06-25-on-the-road-formal-production-handoff.md

后期生产任务：

projects/2026-06-23-在路上/tasks/2026-06-25-production-capacity-validation/production-run-status.md
projects/2026-06-23-在路上/tasks/2026-06-25-8slide-compression-validation/production-run-status.md
projects/2026-06-23-在路上/tasks/2026-06-25-final-production-s48-s50/production-run-status.md

待补充素材

这些内容如果未来写正式文章，建议再补：

选几张关键图片作为插图：人物锚点板、C 修复样本、S-16 rejected / accepted 对照、8-slide validation 中的一组连续画面。
补一段用户视角：为什么《在路上》的主题需要“世界先于人”。
补一段操作截图或目录截图：展示 slides/sNN/sNN-vN-* 的 append-only 结构。
如果文章面向工程读者，可加入 callback-only 子会话流程图。
如果文章面向创作者，可弱化 Agent / token 细节，强化“从灵感到生产线”的叙事。

22 KiB Raw Blame History Unescape Escape