knowledge-vault/discussions/creative/在路上/在路上-video6-流程优化.md

1

阅读：

• 主交接：2026-06-24-on-the-road-workflow-continuation-handoff.md
• 新会话索引：review-context.md
• 文件清单：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/ 模型，不急着加复杂层级：

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 已经比原始骨架更接近执行卡，但还可以进一步模板化。

prompt.md 我同意应视为 brief 的附件，不是另一个项目说明书。现在的 s46-v1-prompt.md 和 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：

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 应该很小：

- 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 的返回也要短：

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 都会重复解释项目，判断口径容易漂。

所以我建议分成：

child session:
  读取较完整上下文
  为每个镜头生成/修订 brief
  启动 shot agent

shot agent:
  只读 brief + 必要规则摘要
  生成 prompt
  按授权生图
  按需写 review
  返回短状态

这样 brief 是子会话的“项目理解产物”，prompt 是 Agent 的“执行附件”。这也符合你刚才说的：prompt.md 不应该装太多项目内容。

shot-agent-packet 就可以小很多：

- 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/：

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 个镜头，例如人物一致性试运行：

session-01: s05 -> s21 -> s14
session-02: s25 -> s33

子会话负责：

• 读取较完整公共上下文。
• 为每个镜头写 sNN-v1-brief.md。
• 为每个镜头生成一个小 packet。
• 顺序启动单镜 Agent。
• 检查 Agent 返回和落盘文件。
• 写 child-session-handoff.md，只给下一会话和主会话必要状态。

单镜 Agent 职责 Agent 一次只处理一个镜头。

Agent 输入：

- 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 输出：

- 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 单镜骨架。

建议结构：

# 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 的附件，应可复制到其他平台交叉验证。

建议结构：

# 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-2skill的advisor模式。

这些都是之前犯错的地方。

10

这次是做视频的子会话及配套镜头Agent。 将来可能还会有做PPT的，因为需要读取的知识库不一样；本次这个没有额外知识库，但是PPT的会有，docs/cases/

这个是本次Plan中记录预留接口；还是将来，做到PPT，再调整？

可以，后续已经可以按这个体系做 5 镜人物一致性测试了。我准备了交接说明：

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。