511 lines
22 KiB
Markdown
511 lines
22 KiB
Markdown
# 1
|
||
|
||
阅读：
|
||
- 主交接：[2026-06-24-on-the-road-workflow-continuation-handoff.md](C:/Users/wangq/Documents/Codex/video-workbench/handoff/2026-06-24-on-the-road-workflow-continuation-handoff.md)
|
||
- 新会话索引：[review-context.md](C:/Users/wangq/Documents/Codex/video-workbench/handoff/2026-06-24-on-the-road-workflow-continuation-context/review-context.md)
|
||
- 文件清单：[review-file-manifest.json](C:/Users/wangq/Documents/Codex/video-workbench/handoff/2026-06-24-on-the-road-workflow-continuation-context/review-file-manifest.json)
|
||
|
||
---
|
||
|
||
目前人物一致性调研已经完成，下一步我计划是修复流程。
|
||
|
||
GPT在阶段五会输出`镜头清单骨架`，及`核心镜头骨架`，由于前面跑的时候出错，我让它又出了做人物一致性检查的一组单镜。
|
||
人物一致性检查的单镜尚未展开；核心单镜已经全部展开并验证。
|
||
|
||
`video-workbench`收到intake的资料后，流程应该是：
|
||
1. `visual-system`下的细化和成果，主要是场景锚板和场景提示词母版；有人物时，去做人物锚板和不同体位的裁切图。
|
||
2. 核心单镜展开的试运行
|
||
3. 其他单镜展开的试运行
|
||
4. 其余单镜的运行
|
||
|
||
---
|
||
|
||
本次流程优化，集中在单镜展开的过程。
|
||
|
||
1. 有单镜骨架的，应该怎么展开，现在的brief、prompt、review是否够用，是否冗余
|
||
2. 没单镜骨架的，应该怎么展开，是否在brief、prompt、review基础上补充什么，还是填充brief文档。
|
||
|
||
即，我们需要一个什么样的文档目录，文档里应该有什么结构，没有单镜骨架（GPT给的）我们应该补什么。
|
||
|
||
---
|
||
|
||
此外review阶段经常会调用MCP服务-Minimax，而导致权限不足的失败。后续review默认都用本地能力，不用mcp。
|
||
|
||
首先，需要你谈谈你的理解，有什么问题？
|
||
|
||
|
||
我的理解是：这次不是继续生图，也不是重做参考图能力验证，而是修复 `slides/sNN/` 的单镜生产单元。
|
||
|
||
现在的问题核心是旧广跑把流程压得太薄了：有 `sNN-v1-image.png`，但缺少每镜自己的 `brief` 和 `prompt`，导致失败后追不回“这个镜头怎么理解、用了哪些参考、prompt 怎么渲染、是否真的加载了人物图”。所以修复方向应该是：
|
||
|
||
- `brief`：把 GPT 镜头骨架或 `slides.md` 行信息，转换成本地执行卡。它负责镜头功能、风险等级、人物可见度、参考选择、验收点。
|
||
- `prompt`：必须保留，且是生成前的正式凭证。它负责 `gpt-image-2` 工作流、来源文件、Reference Inputs、最终 rendered prompt、生成路径说明。
|
||
- `review`：不应每镜默认写长报告。核心试跑、人物一致性、失败修复、用户接受节点才写；普通批量镜头可以批量审查 + 表格状态更新。
|
||
- 没有 GPT 单镜展开的镜头，不应重新做一份长篇“导演阐释”。更轻的做法是在 `brief` 里补足执行所需字段：镜头功能、风险分类、风格模块、人物/道具参考、首读顺序、禁区、验收标准。
|
||
|
||
我认为目录上先保持现有 `slides/sNN/` 模型，不急着加复杂层级：
|
||
|
||
```text
|
||
slides/sNN/
|
||
sNN-v1-brief.md
|
||
sNN-v1-prompt.md
|
||
sNN-v1-image.png
|
||
sNN-v1-review.md # 只在核心、修复、争议、验收时需要
|
||
```
|
||
|
||
另一个明确修复点：review 默认必须本地化。后续不要默认调用 Minimax MCP 做图片理解；普通 review 用本地文件元数据、人工/本地视觉检查、项目验收表。若以后要自动视觉评估，应另开“本地能力或供应请求”，不能让 MCP 权限失败成为常规流程的一部分。
|
||
|
||
我现在唯一需要先确认的问题是：没有 GPT 单镜展开的镜头，你倾向于 **只补 `sNN-v1-brief.md`**，还是希望另外创建一个稳定的 `sNN-unit-spec.md`？我的建议是先只补 `brief`，测试通过后再决定是否需要 `unit-spec`。
|
||
|
||
# 2
|
||
|
||
同意：先只补 `brief`，测试通过后再决定是否需要 `unit-spec`。
|
||
而`brief`的结构，我建议你至少读核心镜头中，一两个镜头的骨架，和对应的brief。
|
||
然后再判断brief应该有什么，而且这个结构，应该不考虑镜头骨架是否有，是一个通用的结构。
|
||
|
||
因为风险点，在核心单镜部分已经验证了。
|
||
而其他单镜展开的试运行，比如本次人物一致性，是因为第一次跑项目，不熟悉而已。将来这个在新项目里就不存在；新项目也可能产生另外的`其他单镜展开`。
|
||
|
||
---
|
||
|
||
而prompt.md我认为可以认为是brief的一个来附件考虑：
|
||
1. 可以直接作为提示词运行，或者附着一些少量的操作描述，而不是内容/业务描述
|
||
2. 我可以拿着这个，在其他平台上做交叉验证。
|
||
|
||
现在的prompt有太多不是prompt，而是规则，项目的内容。
|
||
|
||
这个也需要你读一两份prompt才能判断。
|
||
|
||
|
||
同意，而且我已经读过对应材料：`S-10 / S-46 / S-51` 的 GPT 核心骨架、对应 `brief`，以及 `S-10 / S-46 / S-47 / S-51` 的 `prompt`。
|
||
|
||
我的判断是：
|
||
|
||
`brief` 应该是通用“单镜执行卡”，不区分有没有 GPT 单镜骨架。有没有骨架只影响信息来源深度，不影响文档结构。它应该固定回答：
|
||
|
||
1. 这个镜头在片子里的功能是什么
|
||
2. 第一眼应该读到什么
|
||
3. 人物是否出现、出现到什么程度
|
||
4. 使用哪个风格模块
|
||
5. 使用哪些人物/风格参考，为什么
|
||
6. 构图、尺度、光色、禁区是什么
|
||
7. 本镜的风险等级和验收点是什么
|
||
|
||
现有 `brief` 方向是对的，但可以更收紧：不要再重复太多 GPT 骨架里的长段阐释，只保留执行判断。比如 [s46-v1-brief.md](C:/Users/wangq/Documents/Codex/video-workbench/projects/2026-06-23-在路上/slides/s46/s46-v1-brief.md) 已经比原始骨架更接近执行卡，但还可以进一步模板化。
|
||
|
||
`prompt.md` 我同意应视为 `brief` 的附件，不是另一个项目说明书。现在的 [s46-v1-prompt.md](C:/Users/wangq/Documents/Codex/video-workbench/projects/2026-06-23-在路上/slides/s46/s46-v1-prompt.md) 和 [s51-v1-prompt.md](C:/Users/wangq/Documents/Codex/video-workbench/projects/2026-06-23-在路上/slides/s51/s51-v1-prompt.md) 里面有很多状态、来源、Skill 文件、规则解释，这些更适合留在 `brief`、批次记录或运行日志里。`prompt.md` 应该更像：
|
||
|
||
- 简短元信息：shot、version、brief 路径、输出路径
|
||
- Reference Inputs：实际要挂载/引用的图片及角色
|
||
- Operation Notes：少量运行说明，比如是否要加载 `Image 1`
|
||
- Final Prompt：可复制到其他平台直接跑的完整提示词
|
||
- Negative Prompt / Avoid：可复制的禁区
|
||
- Output Intent：目标文件名或交叉验证说明
|
||
|
||
关键变化是：`prompt.md` 只保留“生成时需要带走的东西”，不承担“解释这个项目为什么这样做”。
|
||
|
||
我接下来的一个问题是：`brief` 里是否要保留“Source Files Actually Used”这类来源清单？我的建议是保留，但压缩成一小节，列关键源即可；详细溯源放到批次运行日志或 review/context 包里。
|
||
|
||
# 3
|
||
|
||
再补充一个关键信息。
|
||
再运行过程，生成brief、prompt、review（按需），生图时，会耗费大量Context，导致经常的上下文压缩。
|
||
|
||
在试运行阶段还好一些，我可以控制开启新会话。但是在连续执行阶段，有问题。
|
||
|
||
1. 可不可以考虑把生成放到Agent里。这样可以省下主会话的Context，以免信息压缩后的信息丢失。
|
||
所以，这个变成了：构造Agent，传递哪些上下文，它的工作安排，返回少量的状态信息/交接。
|
||
|
||
2. 即使主会话窗口快满了，亦可以启动子会话，来承接后续的镜头加工，让子会话继续调用Agent实现。
|
||
|
||
这个算是任务编排的事情。
|
||
|
||
|
||
是的，这已经是任务编排问题，而且我觉得它应该成为流程设计里的核心层，不是后补优化。
|
||
|
||
我会把它拆成三层：
|
||
|
||
1. 主会话只做调度和判断
|
||
维护项目状态、选择批次、决定哪些镜头要跑、检查返回结果、写少量控制文件。主会话不长时间承载每个镜头的完整生成上下文。
|
||
|
||
2. 子 Agent 做单镜加工
|
||
每次接收一个很小的 invocation packet：项目规则摘要、`brief` 模板、相关 `slides.md` 行、必要的视觉系统摘要、引用文件路径、输出路径、禁止事项。它生成或更新 `brief`、`prompt`，按授权生图，按需写 `review`，然后返回短状态。
|
||
|
||
3. 文件系统承接连续性
|
||
子 Agent 的返回不靠聊天记忆，而靠落盘文件：`sNN-v1-brief.md`、`sNN-v1-prompt.md`、`sNN-v1-image.png`、按需 `sNN-v1-review.md`，以及一个批次级 `run-log / handoff`。主会话被压缩也不影响继续。
|
||
|
||
我建议后续流程里明确一个 `shot-worker invocation packet`，里面只传“够执行”的上下文，而不是把整个项目文档塞给 Agent。这样可以避免每个镜头都重复消耗主上下文，也避免子 Agent 自由发挥。
|
||
|
||
关键点：这不应该走形式化 CCPE 角色扮演，除非你要正式 CCPE 参与者输出。这里更像本地执行 worker：真实子会话/Agent 承载，产物落盘，主会话只验收和调度。
|
||
|
||
我需要先确认一个编排边界：你希望这个 Agent 默认一次处理 **一个镜头**，还是一次处理 **一个小批次，比如 3-5 个同类镜头**？我的建议是默认一个镜头；等模板稳定后，再允许低风险环境镜头批处理。
|
||
|
||
# 4
|
||
|
||
是的，这不是CCPE的事，是我们本地。CCPE只做通用的专家智能体。
|
||
我们这套流程，显然别的项目是不适用的。得我们自己打造。
|
||
|
||
Agent默认一次处理 **一个镜头**，而且后续我也不希望它做批次。宁肯系统开销大些，也避免会话污染，职责不清晰。
|
||
|
||
批次，是在会话/子会话级别进行维护的。比如：
|
||
* 会话编排管理，计划共几次会话，每个会话做哪些镜头，然后启动会话1
|
||
* 会话1，启动了5次Agent，分别完成了5个镜头的工作。然后自行启动会话2：
|
||
* 会话2，启动了4次Agent，分别完成了4个
|
||
* ……
|
||
|
||
我理解的会话编排就是主会话，可以完全“不干事”，只是发起子会话；子会话调度Agent，Agent干具体事。
|
||
|
||
比如以`人物一致性检查的单镜`为例，编排会话（主会话）决定启动两个子会话：
|
||
* 子会话1，调度Agent完成前三个
|
||
* 子会话2，调度Agent完成后两个
|
||
|
||
这里，子会话现在完全做成顺序的，不要并行。这样：
|
||
* 一系统开销（线程）可控
|
||
* 过程可控
|
||
* 质量/结果可控
|
||
|
||
对于我这样的构想，你的建议？
|
||
|
||
# 5
|
||
|
||
你的构想是对的，我建议保留这三级，不要压扁：
|
||
|
||
1. **编排主会话**
|
||
只负责“怎么拆会话、先后顺序、当前批次边界、启动哪个子会话”。它不写单镜 `brief/prompt`，也不生图。主会话接近项目经理/调度器。
|
||
|
||
2. **执行子会话**
|
||
每个子会话负责一个小范围，例如人物一致性测试里的 `s05/s21/s14`。它顺序启动 3 次单镜 Agent，检查每次产物是否落盘，然后写交接给下一个子会话。子会话是“批次维护者”，但不亲自做镜头内容。
|
||
|
||
3. **单镜 Agent**
|
||
一次只处理一个镜头。输入固定 packet，输出固定文件和短状态。它不理解全项目，只理解“这个镜头该怎么从现有文件生成 `brief`、`prompt`、按授权生图、按需 review”。
|
||
|
||
我强烈支持“不并行、不批处理”的限制。这里省线程不是第一目标，避免污染才是。单镜 Agent 的上下文一旦混入多个镜头，很容易把人物参考、风格模块、验收点互相串味，尤其是 S14/S25/S33 这种近脸镜头。
|
||
|
||
我建议把这个固化成一个本地编排协议，而不是 CCPE：
|
||
|
||
```text
|
||
main orchestration session
|
||
-> child session 01
|
||
-> shot worker s05
|
||
-> shot worker s21
|
||
-> shot worker s14
|
||
-> write child-session handoff
|
||
-> child session 02
|
||
-> shot worker s25
|
||
-> shot worker s33
|
||
-> write child-session handoff
|
||
```
|
||
|
||
每个单镜 Agent 的输入 packet 应该很小：
|
||
|
||
```text
|
||
- workspace rules summary
|
||
- project id
|
||
- target shot id
|
||
- source row from slides.md
|
||
- optional GPT single-shot skeleton path
|
||
- required brief template
|
||
- style master path
|
||
- character registry path
|
||
- output paths
|
||
- allowed actions: brief only / prompt only / generate / review
|
||
- local-only review rule: no Minimax MCP
|
||
```
|
||
|
||
每个 Agent 的返回也要短：
|
||
|
||
```text
|
||
shot: s05
|
||
status: brief_created | prompt_created | image_generated | review_needed | blocked
|
||
files_written:
|
||
- ...
|
||
needs_user_decision: ...
|
||
handoff_note: ...
|
||
```
|
||
|
||
我建议下一步设计时，把重点放在两个协议文件：`child-session-plan` 和 `shot-agent-packet`。前者解决“一个子会话做哪几个镜头、怎么顺序推进”；后者解决“一个 Agent 到底拿什么、产出什么、不能做什么”。
|
||
|
||
# 6
|
||
|
||
我同意重点放在两个协议文件：`child-session-plan` 和 `shot-agent-packet`
|
||
|
||
但是这个packet 应该很小，我不确定。
|
||
主要就是，谁来生成brief，这个需要较完整的/较多的项目上下文，才能写出有用的。
|
||
brief交给子会话，那么Agent就可以小；brief交给Agent写，它也需要足够的上下文。
|
||
|
||
我的建议是：**brief 交给子会话写，Agent 不写 brief，至少第一版这样。**
|
||
|
||
原因很直接：`brief` 是“理解项目后做执行判断”，不是机械填表。它需要看：
|
||
|
||
- `visual-system.md`
|
||
- `style-prompt-master.md`
|
||
- `character-reference-registry.md`
|
||
- `slides.md` 当前行
|
||
- GPT 单镜骨架或镜头清单骨架
|
||
- 已接受核心镜头的做法
|
||
- 当前阶段目标，比如人物一致性测试
|
||
|
||
这类上下文如果塞进每个单镜 Agent，packet 就不小了，而且每个 Agent 都会重复解释项目，判断口径容易漂。
|
||
|
||
所以我建议分成：
|
||
|
||
```text
|
||
child session:
|
||
读取较完整上下文
|
||
为每个镜头生成/修订 brief
|
||
启动 shot agent
|
||
|
||
shot agent:
|
||
只读 brief + 必要规则摘要
|
||
生成 prompt
|
||
按授权生图
|
||
按需写 review
|
||
返回短状态
|
||
```
|
||
|
||
这样 `brief` 是子会话的“项目理解产物”，`prompt` 是 Agent 的“执行附件”。这也符合你刚才说的：`prompt.md` 不应该装太多项目内容。
|
||
|
||
`shot-agent-packet` 就可以小很多：
|
||
|
||
```text
|
||
- target shot id
|
||
- brief path
|
||
- style master path
|
||
- character registry path
|
||
- output prompt/image/review paths
|
||
- allowed actions
|
||
- generation/reference rule
|
||
- local-only review rule
|
||
```
|
||
|
||
子会话的 packet 可以大一点，叫 `child-session-plan` 或 `child-session-context`，因为它的职责就是维护本轮几个镜头的上下文一致性。上下文压力转移到子会话是可以接受的；关键是它一次只管 2-5 个镜头，并且顺序启动单镜 Agent。
|
||
|
||
我会避免让 Agent 同时承担“理解项目”和“执行生成”。那会把 worker 变成小主会话，边界又糊了。
|
||
|
||
# 7
|
||
|
||
我同意你的判断，这样子会话是否能承接5个镜头，而不爆上下文窗口，我们得测试了。
|
||
所以，先按子会话每次承接3个镜头，这样公共信息可以复用2次。
|
||
|
||
另外，将来我只会与主会话交流。以免产生干扰。
|
||
|
||
---
|
||
|
||
基于以上，我觉得你可以先出一个计划。
|
||
核心原则是：
|
||
* 我们这个不是开发项目，在保证质量的情况下，避免过度治理，只记录最小审计/日志。
|
||
* 我/专家有生物限制，不能参与到所有的检查，非核心不要让我参与检查，太费力了。
|
||
|
||
计划中要规定目录、文件，文档结构。
|
||
|
||
然后再基于这个Plan调整。
|
||
|
||
下面是计划草案，不落盘，先用于对齐。
|
||
|
||
**推荐方案**
|
||
我建议采用：**主会话编排 → 子会话写 brief 并调度 → 单镜 Agent 写 prompt / 生图 / 按需 review**。
|
||
|
||
不建议让 Agent 写 brief。`brief` 需要项目理解，应该由子会话承接公共上下文后生成。Agent 只处理一个镜头，拿 `brief` 当输入，避免每次重复读全项目，也避免把多个镜头混在一个 worker 里。
|
||
|
||
**目录结构**
|
||
新增项目本地运行目录，不放到根 `handoff/`，也不放 `investigations/`：
|
||
|
||
```text
|
||
projects/<project-id>/
|
||
runs/
|
||
<run-id>/
|
||
run-plan.md
|
||
run-log.md
|
||
session-01/
|
||
child-session-plan.md
|
||
child-session-handoff.md
|
||
packets/
|
||
s05-v1-shot-agent-packet.md
|
||
returns/
|
||
s05-v1-shot-agent-return.md
|
||
session-02/
|
||
...
|
||
slides/
|
||
s05/
|
||
s05-v1-brief.md
|
||
s05-v1-prompt.md
|
||
s05-v1-image.png
|
||
s05-v1-review.md # 按需
|
||
```
|
||
|
||
`runs/` 只记录最小编排证据；真正单镜产物仍放 `slides/sNN/`。
|
||
|
||
**主会话职责**
|
||
主会话只和你交流，不做单镜内容生产。
|
||
|
||
主会话负责：
|
||
|
||
- 维护总计划：哪些镜头、拆成几个子会话、每个子会话最多 3 镜。
|
||
- 写或更新 `run-plan.md`。
|
||
- 顺序启动子会话，不并行。
|
||
- 读子会话 `child-session-handoff.md`，决定是否继续下一子会话。
|
||
- 只在核心问题、阻塞、质量失控、规则变更时找你确认。
|
||
|
||
**子会话职责**
|
||
子会话是小批次维护者，但不并行，不跨批次。
|
||
|
||
每个子会话负责最多 3 个镜头，例如人物一致性试运行：
|
||
|
||
```text
|
||
session-01: s05 -> s21 -> s14
|
||
session-02: s25 -> s33
|
||
```
|
||
|
||
子会话负责：
|
||
|
||
- 读取较完整公共上下文。
|
||
- 为每个镜头写 `sNN-v1-brief.md`。
|
||
- 为每个镜头生成一个小 packet。
|
||
- 顺序启动单镜 Agent。
|
||
- 检查 Agent 返回和落盘文件。
|
||
- 写 `child-session-handoff.md`，只给下一会话和主会话必要状态。
|
||
|
||
**单镜 Agent 职责**
|
||
Agent 一次只处理一个镜头。
|
||
|
||
Agent 输入：
|
||
|
||
```text
|
||
- target shot id
|
||
- brief path
|
||
- style master path
|
||
- character registry path
|
||
- prompt/image/review output paths
|
||
- reference image roles if generation is allowed
|
||
- allowed actions
|
||
- local-only review rule
|
||
```
|
||
|
||
Agent 输出：
|
||
|
||
```text
|
||
- sNN-v1-prompt.md
|
||
- sNN-v1-image.png, if generation authorized
|
||
- sNN-v1-review.md, only when required
|
||
- short return file
|
||
```
|
||
|
||
Agent 不写 `brief`，不处理第二个镜头，不做批次判断。
|
||
|
||
**brief 结构**
|
||
`brief` 是通用单镜执行卡，不区分有没有 GPT 单镜骨架。
|
||
|
||
建议结构：
|
||
|
||
```text
|
||
# S-NN Shot Brief V1
|
||
|
||
## Status
|
||
## Source Basis
|
||
## Shot Function
|
||
## First Read
|
||
## Risk Class
|
||
## Reference Plan
|
||
## Visual Requirements
|
||
## Character Handling
|
||
## Composition / Scale
|
||
## Light / Color / Texture
|
||
## Forbidden Drift
|
||
## Acceptance Checklist
|
||
## Prompt Handoff
|
||
```
|
||
|
||
`Source Basis` 保留简短来源即可，不做长审计。详细上下文在 `run-log.md` 或交接包里。
|
||
|
||
**prompt 结构**
|
||
`prompt.md` 是 `brief` 的附件，应可复制到其他平台交叉验证。
|
||
|
||
建议结构：
|
||
|
||
```text
|
||
# S-NN Shot Prompt V1
|
||
|
||
## Status
|
||
## Based On Brief
|
||
## Reference Inputs
|
||
## Operation Notes
|
||
## Final Prompt
|
||
## Negative / Avoid
|
||
## Output Intent
|
||
```
|
||
|
||
不再塞大量项目规则、Skill 文件解释、完整来源审计、生成后 review 结论。生成结果和状态进 `return`、`run-log` 或按需 `review`。
|
||
|
||
**review 结构**
|
||
`review` 默认不生成长报告，只在这些情况需要：
|
||
|
||
- 核心镜头试跑。
|
||
- 人物一致性或身份风险镜头。
|
||
- 失败修复。
|
||
- 用户明确要求验收记录。
|
||
- Agent 判断有阻塞或不确定。
|
||
|
||
默认 review 规则：本地能力优先，不调用 Minimax MCP。外部视觉分析只有在你明确授权时才用。
|
||
|
||
**关键待定点**
|
||
有一个规则需要你确认：当前仓库规则要求“prompt 保存后等用户批准才生图”。如果要让连续执行不打扰你，需要把它改成“你批准 `run-plan.md` 后，该 run 内列明的非核心镜头视为已授权生成；核心/修复/高风险镜头仍单独停下”。我建议采用这个 run-level 授权，否则 Agent 编排省不了你的检查成本。
|
||
|
||
|
||
# 8
|
||
|
||
调整：
|
||
* `runs/` -> `tasks/`，所有run改成task，下面子目录结构不变。
|
||
* 可以把这Agent套分为两种：
|
||
1. 直接跑Prompt和生成图片
|
||
2. 分开，先出prompt。然后我可能会重新发起一次task，再跑生成图片。我可以对Prompt做抽样检查——到ChatGPT上试跑。
|
||
|
||
> 当前仓库规则要求“prompt 保存后等用户批准才生图”。如果要让连续执行不打扰你，需要把它改成“你批准 `run-plan.md` 后，该 run 内列明的非核心镜头视为已授权生成；核心/修复/高风险镜头仍单独停下”。我建议采用这个 run-level 授权，否则 Agent 编排省不了你的检查成本。
|
||
|
||
这个，在主会话中，我来下具体指令：
|
||
1. Agent的运行方式
|
||
2. 镜头范围
|
||
|
||
对应的规则按照这个进行更新。
|
||
|
||
还有其他问题么？
|
||
没有的话，可以写这个plan。
|
||
这里应该会有Agnent，docs/等不同文件的修改吧，Plan中应该有一个文件、文件夹更新/新增的列表。
|
||
`review 结构`、`Prompt结构`和`brief结构`，及tasks规则应该落到docs里，对吧。
|
||
|
||
|
||
# 9
|
||
|
||
plan中：
|
||
|
||
子会话、Agent中应强调对`visual-system`的使用情况，这个是视频生成保持风格或人物统一的核心：
|
||
* 有人物时，需要图生图
|
||
* 风格使用风格母版提示词
|
||
|
||
Agent应强调使用`image-2`skill的advisor模式。
|
||
|
||
这些都是之前犯错的地方。
|
||
|
||
|
||
# 10
|
||
|
||
这次是做视频的子会话及配套镜头Agent。
|
||
将来可能还会有做PPT的，因为需要读取的知识库不一样；本次这个没有额外知识库，但是PPT的会有，`docs/cases/`
|
||
|
||
这个是本次Plan中记录预留接口；还是将来，做到PPT，再调整？
|
||
|
||
|
||
可以，后续已经可以按这个体系做 5 镜人物一致性测试了。我准备了交接说明：
|
||
|
||
[2026-06-24-character-consistency-slide-task-handoff.md](C:/Users/wangq/Documents/Codex/video-workbench/handoff/2026-06-24-character-consistency-slide-task-handoff.md)
|
||
|
||
里面明确了下一会话要读的文件、任务目录、`video-slide-production` profile、`prompt only / prompt and generate` 两种模式、`session-01: s05/s21/s14` 与 `session-02: s25/s33` 的拆分，以及 `visual-system`、`style-prompt-master.md`、`character-reference-registry.md`、`gpt-image-2` Advisor、local-only review 的硬规则。
|
||
|
||
我没有创建实际 `tasks/2026-06-24-character-consistency/` 目录，也没有启动测试任务。下一步需要你在主会话里给出具体模式和范围后再开始。
|
||
|
||
验证过：
|
||
- 交接文件存在。
|
||
- 关键规则可检索到。
|
||
- 交接文件里没有 `shot-agent` 或 `runs/` 旧术语残留。
|
||
- 当前未提交变更包括 `AGENTS.md`、`VIDEO_WORKBENCH.md`、`docs/workflows/` 和这份新 handoff。
|
||
|