441 lines
22 KiB
Markdown
441 lines
22 KiB
Markdown
# 《在路上》项目从无到有到全量 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 表的全部图片生产。
|
||
|
||
更准确地说，它完成了两件事：
|
||
|
||
1. 《在路上》作为一个 MV / slide-image 项目，从策划文本变成了有视觉系统、有角色锚点、有 51 个画面单元、有完整图片产物的本地生产包。
|
||
2. `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。
|
||
|
||
最后沉淀下来的规则是：
|
||
|
||
```text
|
||
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 有自己的目录：
|
||
|
||
```text
|
||
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：项目复盘型
|
||
|
||
1. 开头：为什么不是 prompt 成功，而是工作流成功。
|
||
2. 第一部分：`video-workbench` 为什么要先定边界。
|
||
3. 第二部分：《在路上》如何从 GPT 策划变成四文件执行骨架。
|
||
4. 第三部分：视觉系统如何用 A/B/C/D 和人物锚点稳定下来。
|
||
5. 第四部分：reference-capable generation 为什么是关键转折。
|
||
6. 第五部分：从 Agent-heavy 到 production-light 的演化。
|
||
7. 第六部分：容量验证和全量完成。
|
||
8. 结尾：AI 视频生产的真正对象，是“可续跑生产线”。
|
||
|
||
### 写法 B：方法论型
|
||
|
||
1. 输入不是 prompt，是 accepted intake。
|
||
2. 输出不是图片，是 append-only project state。
|
||
3. 审美不是感觉，是 visual-system rule。
|
||
4. 失败不是删掉，是版本化。
|
||
5. 协作不是等人盯，是 callback。
|
||
6. 批量不是并行，而是轻量生产线。
|
||
|
||
### 写法 C：人机协作型
|
||
|
||
1. GPT 负责想象和策划。
|
||
2. 用户负责决定与接受。
|
||
3. Codex 负责本地化、执行、记录和续跑。
|
||
4. 子会话负责小批量生产。
|
||
5. 文件系统负责记忆。
|
||
6. 最后形成的不是一个 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 细节，强化“从灵感到生产线”的叙事。
|
||
|