223 lines
14 KiB
Markdown
223 lines
14 KiB
Markdown
# 1
|
||
|
||
阅读[2026-06-25-on-the-road-formal-production-handoff.md](C:/Users/wangq/Documents/Codex/video-workbench/handoff/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](C:/Users/wangq/Documents/Codex/video-workbench/handoff/2026-06-25-on-the-road-formal-production-handoff.md)
|
||
3. [project.md](C:/Users/wangq/Documents/Codex/video-workbench/projects/2026-06-23-在路上/project.md)
|
||
4. [execution-plan.md](C:/Users/wangq/Documents/Codex/video-workbench/projects/2026-06-23-在路上/execution-plan.md)
|
||
5. [slides.md](C:/Users/wangq/Documents/Codex/video-workbench/projects/2026-06-23-在路上/slides/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，而不是完全依赖会话记忆。它不需要是重型“生产任务计划文件”，可以很薄，例如：
|
||
|
||
```text
|
||
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个/包。
|
||
|
||
另外，现在剩余的不多了，不需要单独开新会话来做剩余的了。就在这里做完剩余的，你直接发包就可以。
|
||
|
||
|
||
|