knowledge-vault/discussions/creative/在路上/在路上-video7-测试流程运行8.md

1

阅读2026-06-25-on-the-road-formal-production-handoff.md

之前做了7轮优化，从质量到测试管控再到生产流程优化。 现在已经可以准备进入正式生产环节了。

本次有几个目标，你的加载机制，当前项目阶段、范围界定：

1. 我在Codex上进入video-workbench，我说在路上项目开始继续，这时候你的加载顺序是什么
2. 当前项目阶段，我们需要再次统一一下，我认为分为这么几个，你看看：
   1. 清理intake：拿到GPT的intake，对intake进行修复
   2. 确定视觉系统：基于GPT的阶段四的指示，形成本地确认后的visual-system
   3. 核心镜头的验证与测试：进入核心镜头、其他关键镜头的实验/测试
   4. 生产阶段：开始批量生产镜头
3. 在生产阶段的目标镜头范围界定，可能还需要两三个步骤：
   1. 确定当前后续待完成的镜头范围
   2. 确定进入下一轮子会话的生产镜头范围
   3. 等待子会话反馈，然后继续新的子会话的新镜头范围生产

---

之前测试阶段，由于各种审计，三层结构（主会话—子会话-Agent）的损耗，机制（最开始是轮询制，后来改到默认为订阅制），导致一个子会话最多只能做3个镜头。

在前面R7测试过程，发现按照生产流程的方式，子会话做3个镜头，用的Context不到60%，应该有足够余力再做至少2个镜头。所以本次会话也是为生产环节做一个验证，看看生产阶段子会话能承接几个镜头。

---

谈谈你的理解，先对齐思路。

我的理解是：现在不是重新进入测试阶段，而是进入正式 production-light 生产，只是用第一轮生产包顺带验证“一个直接子会话能否从 3 镜头扩大到 5 镜头”。

加载顺序 如果你进入 video-workbench 后说“在路上项目开始继续”，我应按这个顺序加载：

1. AGENTS.md
2. formal production handoff
3. project.md
4. execution-plan.md
5. slides.md

如果可能要派发生产，再加载 VIDEO_WORKBENCH.md、两个 slide workflow 文档、visual-system.md、style master、character registry。只有确定具体镜头范围后，才读对应 intake 行和 slides/sNN/ 文件夹。不读旧 session 目录，除非状态冲突。

阶段划分 你这四段我认同，但我会把它们写成“项目生命周期”，另加一条“运行线”：

1. 清理 intake：修复 GPT intake，形成可执行源材料。
2. 确定视觉系统：把阶段四指示落成本地 visual-system/，并确认角色、风格、锚点。
3. 核心镜头与机制验证：核心镜头、关键镜头、引用路径、callback、子会话承载量、Agent 边界等测试。
4. 生产阶段：批量生成镜头，默认 production-light。

当前项目状态是第 4 阶段：formal MV shot-image production。test/audit 只在失败诊断、修复、核心新规则验证时临时启用；正常生产不再带 Agent/SubAgent、review 文件、packet/return、父会话轮询和完整审计。

生产范围 范围要分三层：

1. 全局待完成范围：以 slides/slides.md 为事实表，accepted、production-pass、明确用户接受的关闭；not started、未接受 generated、broad-run candidate、不完整、被拒绝的保持打开。
2. 下一轮子会话范围：必须是一次明确包。handoff 默认是 S-32/S-34/S-35。
3. 子会话 callback 后继续：父会话只读短 handoff；如果 complete/problems:none，不打开 prompt/image 细节，直接定义下一包。

这次如果目标是验证生产承载量，我建议直接做受控 5 镜头包：S-32/S-34/S-35/S-36/S-37。其中 S-33 已接受跳过；S-32、S-34 有 broad-run 图但未接受，所以应 append-only 生成 v2；S-35/S-36/S-37 预期是 v1，但最终版本仍以子会话扫描文件夹为准。

可选路径有三种：继续 3 镜头最稳但验证不了上限；先 4 镜头是折中但多一轮；直接 5 镜头最符合这次目的。我推荐 5 镜头 production-light 试运行，记录 elapsed/context，若成功再把常规上限从 3 调整为“普通生产包最多 5，identity-heavy/repair 包保守缩小”。

我的对齐问题只有一个：下一步是否就把验证包定为 production-light / prompt and generate / review:none / direct child / S-32,S-34,S-35,S-36,S-37？

2

理解一致。

我的问题是，这个阶段/生命周期，是否在video-workbench全局定义中，这个可以认为是通用的阶段；只是不同的成果，在不同阶段工作内容稍有差异；比如科普视频，还有口播稿的制作，口播音频生成的工作。 所以，对公共流程、阶段的抽象并定义是第一工作。

然后，可以先做，验证包 production-light / prompt and generate / review:none / direct child / S-32,S-34,S-35,S-36,S-37。 若验证通过，我们需要修改workflow及本项目相关的，在生产阶段的数量定义。 这是第二步。

第三步。 你是否能看到你自己会话的Context用量？ 若可以，我理解的生产阶段过程：

1. 我打开Codex，选择video-workbench，说“在路上项目，完成所有的未完成镜头”
2. 你找到待加工全集，发送第一包给子会话；
3. 子会话反馈后，你看下你自己的Context，若足够，则发送第二包给新子会话；若不够，则你自动压缩或者你启动一个编排会话，作为你的后续，有它继续后续的镜头加工

即，生产加工过程，完全可以脱离用户。用户的介入只有因为外力造成的中断，比如网断了，Codex进程退出了，或者其他。

是的，这个生命周期应该上升到 video-workbench 全局定义，不应只写死在“在路上”项目里。建议抽象为：

1. intake-ready：清理/修复 GPT intake，确认源材料可用。
2. system-ready：把源材料转成本地生产系统。MV 是 visual-system/，科普视频可能还包括口播结构、信息图规则、术语表、声音风格。
3. pilot-validation：核心单元验证。MV 是核心镜头/风格/人物一致性；科普视频可能是 1-2 个段落、关键图解、口播样音。
4. production：批量生产单元。MV 是镜头图；科普视频可能是口播稿、音频、图解、分镜、页面。
5. assembly-closeout：组装、导出、收尾和归档。当前“在路上”还没有进入这里。

这样全局定义阶段，项目内只记录当前处于哪个阶段、当前生产分支是什么、每类成果在该阶段的具体产物是什么。

关于 context：我能看到当前会话的 threadId，但目前看不到精确 context/token 用量。get_goal 没有提供用量，运行元数据也只有 thread/turn 信息，没有 context 百分比。所以你设想的“看自己 context 是否足够”不能按精确阈值执行。

可行的无人值守模型应该改成文件状态驱动：

1. 用户说“完成所有未完成镜头”。
2. 主会话从 slides.md 算出全集，并写一个生产任务计划。
3. 主会话按包创建 clean child session，默认 callback-only。
4. 子会话完成一包后写 handoff 并 callback。
5. 父会话收到 callback 后，只读 handoff 和状态；若无问题，继续派下一包。
6. 因为父会话看不到精确 context，所以用保守规则触发继任编排会话：例如每完成 2-3 包、或 handoff/任务日志变长后，父会话创建一个新的 clean 编排会话，把当前任务文件、剩余全集、最近 callback 摘要交给它继续。
7. 用户只在 blocked/failed/warning、外部中断、范围歧义、引用缺失、工具不可用时介入。

下一步我建议按这个顺序执行：先把全局生命周期抽象落到 VIDEO_WORKBENCH.md 和/或 docs/workflows/project-lifecycle.md，然后启动验证包 S-32/S-34/S-35/S-36/S-37。如果验证通过，再把生产阶段包大小从“最多 3”调整为新的规则，例如“普通 production-light 默认最多 5；identity-heavy、repair、core-risk 包可降到 1-3”。

3

无人值守模型，还有一个简易版。 codex本身有自动压缩会话，父会话窗口满后，会自动压缩。所以我们了解了加载机制，压缩后的触发时机是父会话收到子会话时，可以有一个机制，先检查下context是否足够支持继续分发任务，不足则获取哪些信息，足够则继续分发，直到全部镜头完成。 这个能实现非生产任务计划文件的自动执行。 你觉得呢？

先讨论，不执行。

我觉得这个简易版成立，而且更贴近 Codex 的实际运行方式。

关键调整是：不要把“context 是否足够”理解成精确 token 阈值检查，而是理解成一次 callback 后的“续航检查”。

父会话收到子会话 callback 后做三件事：

1. 读取子会话 child-session-handoff.md，确认 complete/problems:none。
2. 读取最小状态面：project.md、execution-plan.md、slides.md，必要时再读当前任务日志。
3. 判断自己是否还能稳定分发下一包：如果当前上下文还清楚，就继续创建下一子会话；如果感觉上下文经过压缩或状态不完整，就先按加载机制重载最小入口，再继续。

也就是说，自动压缩不是问题，反而可以成为机制的一部分。只要每次 callback 后的恢复面足够薄、足够文件化，父会话被压缩后仍然能继续：它只需要知道“已完成哪些、下一包是什么、生产规则是什么、callback 目标是什么”。

但我会保留一个最小状态文件或 task-log，而不是完全依赖会话记忆。它不需要是重型“生产任务计划文件”，可以很薄，例如：

active production run:
- project
- line: production-light
- mode: prompt and generate
- package size
- all target slides
- completed slides
- active child session
- next unresolved slide cursor
- stop conditions

没有这个最小文件，自动压缩后的父会话可能能继续，但风险会变高：尤其是跳过已接受镜头、处理 generated but not accepted、append-only 版本扫描这些细节，不能只靠压缩摘要。

所以我会把无人值守生产定义成：

• 用户一次授权全量范围，例如“完成所有未完成镜头”。
• 父会话写入一个轻量 production-run 状态。
• 父会话只负责分包、派发、接 callback、推进游标。
• 子会话负责实际 brief/prompt/image/slides.md/handoff。
• 父会话每次 callback 后自动进入下一包，直到全集完成或遇到 stop condition。
• Codex 自动压缩发生时，父会话按入口加载机制恢复，不需要用户介入。

我认为这比“父会话另起编排会话”更轻，应该作为默认简易版；编排继任会话只作为 fallback，比如父会话工具不可用、状态混乱、callback 断链、或用户主动要求换新主会话。

4

同意这个。 那么接下来：

1. 把全局生命周期抽象落到 VIDEO_WORKBENCH.md 和/或 docs/workflows/project-lifecycle.md
2. 落最小状态文件或 task-log机制
3. 启动验证包 S-32/S-34/S-35/S-36/S-37
4. 若验证通过，把生产阶段包大小从“最多 3”调整为新的规则

这样本次工作结束。我将在新会话中开启全量生成的运行。

5

5张图片都没问题。 由于连续生产，大量资料可以复用，本次5个镜头跑完，Tokens 164K，Context占用率63%。

但是有个小问题，子会话回调你之后，还再调整slides table，落盘其他文档。这个会与你继续编排发任务产生冲突。 你检查一下，你下发的任务，回调你应该放在子会话工作的最后一步，等所有的产出完成后。 即，回调你时，Tokens 152K，占用率58%，调完写文档，变成了164K，63%。

已修正并落盘。

我核查了子会话线程，你指出的问题成立：它在 callback 成功后又更新了 handoff，并做了窄 closeout 检查。这个对连续编排有冲突风险。所以我把规则改成了：

子会话必须先完成全部允许写盘、slides.md 更新、窄检查、handoff 写入；callback 是最后一个动作；callback 成功后不得再写或检查项目文件。

同时已把这次 5 张验证结果记录为通过：

• S-32/s32-v2
• S-34/s34-v2
• S-35/s35-v1
• S-36/s36-v1
• S-37/s37-v1

项目状态、slides.md、execution-plan.md、正式 handoff、workflow docs、AGENTS.md、VIDEO_WORKBENCH.md 都已同步。普通 production-light 子会话默认上限已改为最多 5 张；identity-heavy、repair-heavy、core-risk、context-expensive 范围仍降到 1-3 张。

新会话继续时的默认下一包已经是：

S-38/S-39/S-40/S-41/S-42

验证也做了：旧的“最多 3”默认限制没有残留；S32/S34/S35/S36/S37 都是 production-pass / capacity validation accepted；git diff --check 只有既有 CRLF warning，没有 whitespace error。

6

为了验证这个：

1. 回调在工作之后
2. Context依然有富裕
3. 现在马上面临自动压缩，刚好我们也能测试一下；模拟压缩后的编排会话场景

你再发起一个后续的8个镜头的包，启动新子会话。

7

1. 现在已经经历了一次信息压缩。
2. 现在的8个镜头包，Tokens 174k，67%，用时38m37s。

已经是生产环节了吧？所有的图片应该都是默认通过，不需要人类审核意见，对吧。

我觉得可以将全局规则改成每包8个镜头，本地也用这8个/包。

另外，现在剩余的不多了，不需要单独开新会话来做剩余的了。就在这里做完剩余的，你直接发包就可以。