494 lines
22 KiB
Markdown
494 lines
22 KiB
Markdown
# 1
|
||
|
||
首先阅读：
|
||
[2026-06-24-character-consistency-session-subagent-third-test-handoff.md](C:/Users/wangq/Documents/Codex/video-workbench/handoff/2026-06-24-character-consistency-session-subagent-third-test-handoff.md)
|
||
|
||
下面准备做流程试运行的第三轮测试。
|
||
准备的镜头有两个：
|
||
1. 人物一致性单镜骨架文件：`C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake\阶段五-人物一致性单镜.md` 中的最后一个镜头，S-33
|
||
2. 无单镜骨架支撑的，随便选一个镜头，S-06
|
||
|
||
计划分为两步：
|
||
1. 调起子会话，发送s-33制作要求，无review
|
||
其工作完成后，你重点检查：
|
||
* 子会话调起
|
||
* 子会话的Agent s-33运作
|
||
* 提示词中是否有对人物、风格的引用
|
||
我检查图片结果是否可以通过。
|
||
|
||
2. 继续调起前子会话，发送S-06制作要求，无review
|
||
检查内容同前
|
||
|
||
---
|
||
|
||
先对齐思路。有问题提出。
|
||
|
||
|
||
|
||
# 2
|
||
|
||
首先，你的思路和我一致。
|
||
|
||
**接下来讨论处理机制/规则，不做具体执行**
|
||
|
||
我发现每次准备时，你都要花大量Tokens在子会话（session）和Agent（SubAgent）的机制实现调查下。比如本次，一个回合下来你已经用了95K，37%的Context，总共258K。
|
||
能否做个简化：
|
||
* 当我说子会话，就是session，可以看到一条单独的会话；我说Agent就是内部的subagent。
|
||
* 然后机制也不用调取过多原始文档查阅，直接有实现方法
|
||
|
||
这样每次新开的会话，或者子会话都不需要查阅而浪费Tokens。
|
||
|
||
可以，应该简化。
|
||
|
||
我建议把它固定成一条“运行时词典 + 默认实现合同”：
|
||
|
||
| 你的说法 | 固定含义 | 默认实现 |
|
||
| --- | --- | --- |
|
||
| 子会话 / session | 用户可见的单独 Codex 会话 | `codex_app.fork_thread` 新建；`send_message_to_thread` 续发；`read_thread` 检查 |
|
||
| Agent / SubAgent | child session 内部一次性 worker，不应出现在用户可见会话列表 | `multi_agent_v1.spawn_agent(agent_type="worker")`；一个 Agent 只处理一个镜头 |
|
||
| 继续前子会话 | 不新建 session，只给已记录 thread id 发消息 | `send_message_to_thread(threadId=...)` |
|
||
| 无 review | 不写 `sNN-vN-review.md`，只写 return / ledger / task log | 父会话检查 review 文件不存在 |
|
||
|
||
这样以后不需要每次重新调查机制。默认直接按这个执行，只有三种情况才重新查工具/原始文档：
|
||
|
||
1. 工具不可用或返回异常。
|
||
2. 出现“Agent 变成可见 thread”“重复 worker”“目标文件碰撞”这类机制偏差。
|
||
3. 你明确要求复查机制或改规则。
|
||
|
||
我会把后续默认预检压到很小：确认目标 session id、扫描目标 slide 当前最高版本、确认 `review disabled`、确认 child session 要用内部 `spawn_agent`，然后发任务。父会话检查也只查：child thread id、ledger、packet、return、prompt 里的人物/风格引用、review 是否缺席、目标文件是否唯一。
|
||
|
||
如果要持久化，最合适不是写长文档，而是在 `AGENTS.md` 或 slide-task workflow 里加一个很短的“Runtime Vocabulary / Default Carrier”小节。之后新会话读到这几行，就不需要再从 handoff 和历史产物里反复推断。
|
||
|
||
# 3
|
||
|
||
好的，AGENTS.md 增加这个小节。
|
||
然后，我会自己全workbench手动提交一次，保证我们在一个干净的基础上。
|
||
|
||
已在 [AGENTS.md](C:/Users/wangq/Documents/Codex/video-workbench/AGENTS.md:76) 增加 `Runtime Vocabulary / Default Carrier` 小节，固定了：
|
||
|
||
- `子会话/session` = 用户可见 Codex session
|
||
- `Agent/SubAgent` = 内部一次性 worker
|
||
- 默认工具映射：`fork_thread/send_message_to_thread/read_thread/spawn_agent`
|
||
- 最小预检项
|
||
- 只有工具异常、可见线程污染、重复 worker、文件碰撞或你明确要求时才重新调查机制
|
||
|
||
我没有提交。核对时 `git diff` 里还显示一条 `New slide-task execution...` 的改动，但那条在我编辑前已经存在于工作树中，我没有动它。
|
||
|
||
# 4
|
||
|
||
我已经提交了。
|
||
现在开始第一步，S-33的制作与检查。
|
||
|
||
我停止了当前会话和你启动的子会话。
|
||
|
||
# 5
|
||
|
||
这个子会话上下文不对，你是从当前会话中派生的；而不是启动一个新的子会话，准备它的上下文这些，这个和前面的测试都有差异。
|
||
你先检查一下：
|
||
* 你是编排会话，子会话应该只有制作相关的上下文；你把你的上下文发过去，会有污染，为什么会这样？
|
||
|
||
**暂停派发任务，做调用检查**
|
||
|
||
已修正 [AGENTS.md](C:/Users/wangq/Documents/Codex/video-workbench/AGENTS.md:82)。
|
||
|
||
改动内容很窄：
|
||
|
||
- `子会话/session` 的新建 carrier 从 `fork_thread` 改为 `create_thread`
|
||
- 明确 `fork_thread` 会继承父会话历史，制作型子会话默认禁止使用
|
||
- `tool_search` 暴露列表改为 `create_thread/send_message_to_thread/read_thread/spawn_agent`
|
||
- preflight 改为“用 `create_thread` 创建一个干净 visible session”
|
||
|
||
没有提交，也没有继续派发任务。
|
||
|
||
# 6
|
||
|
||
我手动提交了。现在重启S-33的制作与检查。
|
||
|
||
# 7
|
||
|
||
因为我能看见子会话的思考过程，工作过程。我看见了子会话中的Agent调起过程。
|
||
本次子会话的工作时长为10m3s，使用的Tokens为92K。
|
||
S-33的成果图片检查通过。
|
||
|
||
第一步完成测试。
|
||
|
||
现在开始第2步。
|
||
|
||
第二步 S-06 已完成，机制检查通过。
|
||
|
||
- 继续使用同一个可见子会话：`019ef876-c5b2-7202-b204-774cb5fb95fd`
|
||
- 新内部 Agent：`Agent S-06` / `019ef886-8797-7243-9427-d45065fcfc47`
|
||
- 与 S-33 Agent 不同，且没有额外可见 `Agent S-06` / `s06-v2` 线程
|
||
- 产物存在：`s06-v2-brief.md`、`s06-v2-prompt.md`、`s06-v2-image.png`、return、S-06 handoff
|
||
- `s06-v2-review.md` 不存在，符合无 review
|
||
- Prompt 使用了 `gpt-image-2`、A 风格模块、character registry，并明确使用 back/walking 参考图 `Image 1/2/3`
|
||
- 未提交；工作树现在有 S-33、S-06 和 `session-04/` 的新增产物
|
||
|
||
S-06 图片如下，等你做视觉判断：
|
||
|
||
|
||
|
||
|
||
# 8
|
||
|
||
第二步流程检查通过。
|
||
S-06 图片也可用。
|
||
|
||
先做本次测试的归档——更新Slides及其他相关的项目文档。
|
||
|
||
---
|
||
|
||
# 9
|
||
|
||
由于前面上下文被自动压缩了。这是我们这个会话最开始时我发的任务：
|
||
|
||
```md
|
||
|
||
首先阅读：
|
||
[2026-06-24-character-consistency-session-subagent-third-test-handoff.md](C:/Users/wangq/Documents/Codex/video-workbench/handoff/2026-06-24-character-consistency-session-subagent-third-test-handoff.md)
|
||
|
||
下面准备做流程试运行的第三轮测试。
|
||
准备的镜头有两个：
|
||
1. 人物一致性单镜骨架文件：`C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake\阶段五-人物一致性单镜.md` 中的最后一个镜头，S-33
|
||
2. 无单镜骨架支撑的，随便选一个镜头，S-06
|
||
|
||
计划分为两步：
|
||
1. 调起子会话，发送s-33制作要求，无review
|
||
其工作完成后，你重点检查：
|
||
* 子会话调起
|
||
* 子会话的Agent s-33运作
|
||
* 提示词中是否有对人物、风格的引用
|
||
我检查图片结果是否可以通过。
|
||
|
||
2. 继续调起前子会话，发送S-06制作要求，无review
|
||
检查内容同前
|
||
```
|
||
|
||
我们第3次测试已经做完了，算是圆满结束。
|
||
上个回合我让你做了归档工作。
|
||
|
||
---
|
||
|
||
下面，我们讨论一下机制层面的事项。
|
||
|
||
本次测试：
|
||
1. 子会话处理s-33，总共耗时10m3s，使用的Tokens为92K
|
||
2. 子会话处理S-06，总共耗时9m48s，累计使用Tokens为145K。第二次的Tokens实际为53K。
|
||
|
||
这是因为：
|
||
1. 一些公共的在第一次加载了
|
||
2. 我们在Agents.md中加了`Runtime Vocabulary / Default Carrier`小节，减少了工具调用的检查Tokens
|
||
|
||
---
|
||
|
||
这是子会话的思考过程：
|
||
```
|
||
All planned S-06 targets are absent, and the selected A-style plus back/walking character references exist. I’m adding a separate S-06 continuation section to the ledger, leaving the S-33 evidence intact.
|
||
|
||
The S-06 plan, brief, packet, and prelaunch ledger section are written. I’m launching exactly one new internal worker now, separate from Agent S-33, with the selected back/walking references attached.
|
||
|
||
Agent S-06 launched as internal worker 019ef886-8797-7243-9427-d45065fcfc47, distinct from S-33. I’m recording that launch in the existing ledger, then waiting for its prompt/image/return.
|
||
```
|
||
从内容上看，没有问题。启动了独立的Agent。
|
||
|
||
我觉得机制上可以更“狠”一点，当子会话的Agent完成后，直接销毁。这样它后面想调起来也没了。
|
||
也不用去过度考虑“会话污染”的问题了。
|
||
|
||
我不知道我这样想的对不对，你判断下。
|
||
|
||
你的判断方向是对的，而且可以作为默认机制收紧。
|
||
|
||
我建议把它表述成：**Agent/SubAgent 是一次性运行时，不是可继续会话。完成 return 后立即进入 terminal/closed 状态；后续不能继续、不能复用、不能追加任务。**
|
||
|
||
关键区别是：
|
||
|
||
- **不要物理删除证据**：Agent id、packet、return、image hash、ledger 仍然要保留，方便审计和归档。
|
||
- **要逻辑销毁运行时句柄**：从机制上规定完成后不可再向这个 Agent 发消息；如果要重做或修订，必须新建 Agent，并使用新的 slide version。
|
||
- **子会话可以继续**：子会话负责编排和持有公共上下文；但它只能读取已关闭 Agent 的 return/artifact，不能继续那个 Agent。
|
||
- **下一镜头必须新 Agent**：S-06 这次就是正确模式，同一个 clean child session 继续，但启动独立 `Agent S-06`，不复用 `Agent S-33`。
|
||
|
||
这会解决两类问题：
|
||
|
||
1. **会话污染风险下降**：Agent 的内部上下文不会被带到下一镜头。
|
||
2. **重复/误用风险下降**：旧 Agent 一旦 closed，就不可能被当成“还能继续工作的角色”。
|
||
|
||
但它不会显著降低子会话本身的 token。S-06 的 53K 主要来自子会话继续编排、扫描文件、读 prompt/规则和组织新 packet；销毁 Agent 主要是机制安全，不是 token 优化。token 优化还要靠共享规则前置、文件证据少读、固定 packet 模板和更短的检查清单。
|
||
|
||
我建议规则写成这样：
|
||
|
||
```text
|
||
Agent/SubAgent lifecycle:
|
||
- A slide Agent is one-shot.
|
||
- It receives exactly one immutable packet.
|
||
- It writes exactly one return for one slide/version.
|
||
- After return is recorded, it is terminal/closed.
|
||
- Closed Agents must not be continued, reused, or assigned follow-up work.
|
||
- Any repair, retry, or next slide must launch a new Agent with a new packet and, when writing slide artifacts, a new append-only version.
|
||
- Ledger keeps closed Agent evidence, but active worker list must remove/close it.
|
||
```
|
||
|
||
所以结论：**你这个“更狠”的方向是对的；实现上叫“终态化/不可复用”，不要叫删除或抹除。** 子会话继续存在，Agent 完成即封存。
|
||
|
||
# 10
|
||
|
||
**另外是关于编排会话（即当前会话）：**
|
||
|
||
由于测试你在子会话完成后去做大量的检查，我没意见；但是这样会占用编排会话的大量Tokens。导致，我们这里做了两次调用，会话空间就不足，自动压缩。
|
||
|
||
在将来的正式运行过程中，子会话负责返回完成状态，编排会话不应该负责结果检查，看到完成结果，直接继续。
|
||
结果检查应该是子会话要做的。结果检查包括两部分：
|
||
1. 完整性，这个默认必须要
|
||
2. 指令检查，就是review。这个看编排会话是否有要求。
|
||
|
||
另一个就是等待时间，基于前两次测试的时间每次都是10m左右，我觉得正式运行，第一次直接sleep 10m，还没出来再sleep 1m，这样基本上得到结果，可以继续了。
|
||
|
||
---
|
||
|
||
对此，你怎么考虑？
|
||
|
||
我同意，而且这应该成为正式运行规则。
|
||
|
||
编排会话的职责应收窄成：**派发、等待、读取子会话返回摘要、决定下一步**。不应默认打开 prompt、return、ledger、图片路径做重复检查。测试阶段我做大量检查是为了验证机制；正式生产继续这么做，会把编排会话变成审计会话，token 成本太高。
|
||
|
||
我建议机制分三层：
|
||
|
||
1. **子会话内置完成门**
|
||
每个子会话在返回前必须自检完整性：版本是否 append-only、目标文件是否存在、hash 是否记录、packet/return 是否对应、review 是否按要求生成或缺席、Agent 是否 one-shot closed。
|
||
|
||
2. **子会话按需做 review**
|
||
如果编排会话要求 `review: none`，子会话只做完整性门，不做语义/画面/指令 review。
|
||
如果要求 `review: instruction`，子会话再检查 prompt/图片是否符合人物、风格、镜头意图等要求，并写 review 文件或 review 段落。
|
||
|
||
3. **编排会话只读返回摘要**
|
||
子会话返回一个固定格式的短摘要即可：
|
||
```text
|
||
status: complete
|
||
slide: s06
|
||
version: s06-v2
|
||
child_session_id: ...
|
||
agent_id: ...
|
||
files_written: ...
|
||
completeness_gate: pass
|
||
review_mode: none
|
||
review_file: absent as requested
|
||
references_in_prompt: character yes / style yes
|
||
agent_lifecycle: closed
|
||
warnings: none
|
||
```
|
||
编排会话看到 `complete + gate pass` 就继续下一镜头；除非状态是 `blocked/failed/warning`，才进入检查。
|
||
|
||
关于等待时间，我也赞成你这个策略：**正式运行默认第一次 sleep 10m，未完成再每 1m 轮询一次**。这比频繁读线程省 token，也符合这两次测试的实际耗时。可以加一个上限，例如 15m 或 20m，超过才读详细状态或人工介入。
|
||
|
||
我会把原则概括成一句：**测试期主会话验机制；生产期子会话验结果，主会话只消费状态。**
|
||
|
||
这个方向是对的，尤其适合后面批量生产。
|
||
|
||
# 11
|
||
|
||
同意，加一个上限，按照15m。
|
||
|
||
另外，根据测试，子会话承接3次镜头制作也没问题；workflow里默认是3，本项目中，将这个改成2了，这个可以改成3。
|
||
|
||
我还计划后续新会话中做第4次试运行测试，重点为：
|
||
1. 主要模拟正式运行，编排会话不做审计
|
||
2. 看子会话的镜头承接量
|
||
|
||
这样，基于以上共识，我们需要调整两部分：
|
||
1. docs下的workflow
|
||
2. 本项目的对应文档
|
||
|
||
然后一个交接文档，说明本次工作，和第4次要做的。
|
||
|
||
---
|
||
|
||
你看下这个要改哪些，怎么改。
|
||
有问题提出。
|
||
|
||
我看下来，改动范围可以很清楚，不需要大拆。
|
||
|
||
**要改的文件**
|
||
|
||
1. `docs/workflows/slide-task-orchestration.md`
|
||
这是主规则，应该新增/调整四块：
|
||
|
||
- **Main Session 生产职责**
|
||
- 测试期可审计，生产期默认不审计。
|
||
- 编排会话只做：派发、等待、读取短 handoff、继续下一组。
|
||
- 只有 `blocked / failed / warning / user requests audit` 时才打开详细 prompt/return/ledger。
|
||
|
||
- **等待/轮询规则**
|
||
- 派发后第一次等待 `10m`。
|
||
- 未完成则每 `1m` 轮询一次。
|
||
- 总等待上限 `15m`。
|
||
- 15m 未完成才读取线程状态或进入异常处理。
|
||
|
||
- **子会话完成门**
|
||
- 子会话返回前必须做 `completeness_gate`，这是默认必须项。
|
||
- 检查文件存在、版本 append-only、无覆盖、packet/return 对应、image hash/路径记录、review 是否按要求存在或缺席、Agent 已 closed。
|
||
- `instruction_review` 只在编排会话要求 review 时做。
|
||
|
||
- **Agent 生命周期**
|
||
- Agent/SubAgent 是 one-shot。
|
||
- 一个 packet、一个 slide/version、一个 return。
|
||
- return 后 terminal/closed，不能继续、不能复用。
|
||
- retry/repair/下一镜头必须新 Agent，新 packet，写图时新版本。
|
||
|
||
2. `docs/workflows/slide-task-templates.md`
|
||
模板要补字段，否则子会话不知道该怎么短返回：
|
||
|
||
- `Child Session Handoff` 增加：
|
||
- `Completion Gate`
|
||
- `Review Mode / Result`
|
||
- `Agent Lifecycle`
|
||
- `Parent Summary`
|
||
- `Slide Agent Packet` 增加：
|
||
- `Lifecycle Rule`
|
||
- `Completion Gate Rule`
|
||
- `Slide Agent Return` 增加：
|
||
- `Completeness Gate`
|
||
- `Review Result`
|
||
- `Agent Lifecycle`
|
||
- `Parent Summary`
|
||
|
||
3. 项目文档
|
||
需要改这些：
|
||
|
||
- `projects/2026-06-23-在路上/execution-plan.md`
|
||
- 把“identity-heavy child sessions capped at 2 slides” 改回 `maximum 3 slides per child session`。
|
||
- 下一步改成第 4 次试运行：模拟正式运行、编排会话不审计、测试子会话承接 3 镜头能力。
|
||
- 记录等待策略：10m + 1m polling，15m 上限。
|
||
|
||
- `projects/2026-06-23-在路上/project.md`
|
||
- 当前 focus 从 `session-04` 归档，推进到 “R4 formal-run simulation prep”。
|
||
|
||
- `projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/task-plan.md`
|
||
- 把本项目 `at most 2` 的覆盖规则撤掉或标成历史测试阶段规则。
|
||
- 增加 `session-04` 后的机制结论：默认恢复 3 slides per child session，下一轮验证 3 镜头承接量。
|
||
|
||
- `projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/task-log.md`
|
||
- `Open Decisions` 改成：R4 待执行，目标为生产模拟和 3 镜头承接量。
|
||
- `session-04` 作为通过依据，不再把 2-slide cap 当当前规则。
|
||
|
||
4. 新交接文档
|
||
建议放：
|
||
`handoff/2026-06-24-character-consistency-r4-formal-run-handoff.md`
|
||
|
||
内容包含：
|
||
- 本次第三轮结论：S-33 / S-06 通过，`session-04` 机制通过。
|
||
- 新规则摘要：主会话不审计、子会话完成门、review 可选、Agent closed、等待 10m/1m/15m。
|
||
- 第 4 次试运行目标：
|
||
- 编排会话模拟正式运行；
|
||
- 只读子会话短 handoff；
|
||
- 不打开 prompt/return 做审计，除非失败；
|
||
- 测试一个子会话连续承接 3 个镜头。
|
||
- 待用户在新会话指定或确认第 4 次测试镜头范围。
|
||
|
||
**我建议额外同步一个文件**
|
||
|
||
`AGENTS.md` 也应该改一小段。原因是它现在是新会话减少 token 的快捷规则层；如果 workflow 改了但 `AGENTS.md` 没写“主会话不审计 / 10m 等待 / Agent closed”，新会话仍可能重新调查或重复审计。
|
||
|
||
我建议加，但可以很短，不把 workflow 全复制进去。
|
||
|
||
**需要确认的问题**
|
||
|
||
1. 第 4 次试运行的 3 个镜头是否现在就指定？
|
||
如果不指定，交接文档里就写“新会话开始时由用户确认”。
|
||
|
||
2. `AGENTS.md` 是否一起同步？
|
||
我建议同步，因为它正是避免新会话浪费 token 的入口。
|
||
|
||
# 12
|
||
|
||
## 第 4 次试运行的镜头
|
||
|
||
这个需要你先做一个盘点，看看slides中哪些记录完成了。我计划第4次，既是试运行，又是从头开始做一些没完成的。
|
||
|
||
我这边确认完成的，应该一共11个。
|
||
1. intake中的核心镜头，5个
|
||
2. intake中的人物一致性镜头，5个
|
||
3. 我们本次临时选的，无骨架的，1个
|
||
|
||
之前做了一些的，有人物的都是错的，没有人物出现的：
|
||
1. 没法回溯
|
||
2. 没法证明使用了风格母版
|
||
都需要重做。
|
||
|
||
## `AGENTS.md` 是否一起同步？
|
||
|
||
同意一起同步。
|
||
|
||
---
|
||
|
||
**先盘点，不做具体文档输出。**
|
||
|
||
盘点结论：你说的 **11 个完成镜头** 和当前文件状态基本对得上。
|
||
|
||
**已完成 / 可保留的 11 个**
|
||
|
||
| 类别 | 镜头 | 说明 |
|
||
| --- | --- | --- |
|
||
| 核心 / 锚点测试 | S-01, S-10, S-46, S-47, S-51 | 都有 `brief/prompt/image/review`，并已记录用户接受。注意：`阶段五-核心单镜.md` 本身只展开 S-10/S-46/S-51，S-01/S-47 是五镜测试范围补入。 |
|
||
| 人物一致性 5 镜 | S-05, S-14, S-21, S-25, S-33 | 对应 `阶段五-人物一致性单镜.md` 的五个镜头。S-05 有覆盖缺陷但有 prompt/review/引用证据；S-14 图可用但有 duplicate Agent 机制缺陷；S-21/S-25/S-33 已接受。 |
|
||
| 临时无骨架测试 | S-06 | `s06-v2` 已接受，且是 `session-04` clean mechanism pass。 |
|
||
|
||
**生成过但需要重做的 26 个**
|
||
|
||
这些基本只有 `sNN-v1-image.png`，没有可追溯 brief/prompt/review，不能证明使用了风格母版或人物引用：
|
||
|
||
`S-02, S-03, S-04, S-07, S-08, S-09, S-11, S-12, S-13, S-15, S-16, S-17, S-18, S-19, S-20, S-22, S-23, S-24, S-26, S-27, S-28, S-29, S-30, S-31, S-32, S-34`
|
||
|
||
处理口径建议：保留旧 `v1` 作为历史 broad-run evidence，但正式生产从 `v2` 开始重做。
|
||
|
||
**完全未开始的 14 个**
|
||
|
||
`S-35, S-36, S-37, S-38, S-39, S-40, S-41, S-42, S-43, S-44, S-45, S-48, S-49, S-50`
|
||
|
||
这些后续从 `v1` 开始。
|
||
|
||
**第 4 次试运行候选**
|
||
|
||
如果目标是“模拟正式运行 + 从头补没完成的”，我建议第 4 次用：
|
||
|
||
`S-02, S-03, S-04`
|
||
|
||
理由：它们是 S-01 之后最早的连续未完成段；正好覆盖三种压力：
|
||
|
||
- S-02：远景/小人物，测试人物引用在远景里的控制。
|
||
- S-03：局部人物道具/身体细节，测试人物一致性。
|
||
- S-04：无人风景，测试风格母版可追溯但不加载人物引用。
|
||
|
||
这组适合验证“一个子会话连续承接 3 镜头”，也符合正式生产从头推进的节奏。S-05 已经有可用版本，不建议放进第 4 次重测。
|
||
|
||
# 13
|
||
|
||
这个盘点和建议也放在交接文档里。
|
||
若第四次顺利的话，可以不限制于只做3个镜头了。
|
||
|
||
基于以上现在开始落盘文档。
|
||
你的文档全部修复完毕后，我会手动做一次提交。
|
||
|
||
第4次就是一个干净的环境。
|
||
|
||
检查过，落盘是完整的，断网没有造成半写。
|
||
|
||
已完成的文档更新包括：
|
||
|
||
- `AGENTS.md`
|
||
- `docs/workflows/slide-task-orchestration.md`
|
||
- `docs/workflows/slide-task-templates.md`
|
||
- `projects/2026-06-23-在路上/project.md`
|
||
- `projects/2026-06-23-在路上/execution-plan.md`
|
||
- `projects/2026-06-23-在路上/slides/slides.md`
|
||
- `projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/task-plan.md`
|
||
- `projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/task-log.md`
|
||
- 新增 `handoff/2026-06-24-character-consistency-r4-formal-run-handoff.md`
|
||
|
||
验证结果：
|
||
|
||
- R4 交接文档存在。
|
||
- `at most 2 / capped at 2` 这类旧限制没有真实残留；唯一命中是旧 return 里的 `Image 2 visible-context`，不是规则残留。
|
||
- `10 minutes / 15 minutes / completion gate / terminal closed / R4 / S-02 S-03 S-04` 都已同步到规则和项目文档。
|
||
- `git diff --check` 通过，只有 Windows 的 CRLF 提示。
|
||
|
||
当前 `git status` 里还包括本轮生成产物的未跟踪文件：`s06-v2-*`、`s33-v2-*`、`session-04/`，以及新增 handoff。你手动提交时需要一起纳入，才能让第 4 次新会话从干净基础开始。
|