wantsong
/
knowledge-vault
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
knowledge-vault/discussions/creative/在路上/在路上-video3-人物锚板规则.md

15 KiB
Raw Blame History

1

我们之前完成了人物锚板，风格锚板。 做了5个镜头的比较“重”的测试，都是生成md，我审批，生成图片，我查阅。 之后，从slide 01 向后自动生成时，发现： slides/broad-generation-self-audit-v1.md

你先理解这些问题。

我理解了。问题不是“批量图生成质量不稳定”这么简单，而是流程边界被简化过头了：

  1. 本来只该去掉“每镜头人工审批”，实际却连“每镜头 brief/prompt 证据”和“显式引用人物/风格锚点”一起去掉了。自审文件已经把这个根因写清楚了：broad-generation-self-audit-v1.md。

  2. 人物锚板是存在且有效的，但批量生成只用了文字描述，没有把 visual-system/characters/ 下的 v2 anchor/slice 作为每镜头引用写进 prompt，也没有实际传给图像工具。s14、s33 这种脸部镜头因此漂成了另一个人，尤其黑框眼镜缺失，这不是小偏差。

  3. 批量生成留下了图片，但 s02-s34 缺少逐镜头 shot-brief-v1.md / shot-prompt-v1.md，所以现在很难判断每张坏图到底是镜头理解错、人物引用没用、风格引用没用，还是宿主生成随机性导致。这个也违反了仓库要求的“prompt/spec 可审阅项目文件”规则：VIDEO_WORKBENCH.md。

  4. s34 是单独的状态不一致：图片已存在，但 slides.md 仍是 not started，run log 也没有结果条目。这个应先修账，再决定它是不是可用候选。

  5. 正确的轻量流程应改成：每镜头 brief + 每镜头 prompt + 不逐镜头人工审批 + 批量级人工 review。也就是保留可追溯性和引用锁定，去掉人工审批负担，而不是退化成“批量日志 + 文本锚点”。

我没有改文件。下一步如果要修，我会先修流程/状态，再处理高风险镜头，不会直接继续从 s35 往后生成。

2

先做一步小修。

  1. 修复Sxx下的文件命名。
  2. s34 的状态

这个修复完，我们才可以做一次提交。为后续修复打下基础。

3

本轮只回答问题。

提交这个，我可以自己提交么？我准备做全路径的提交：

  1. 完成了intake的修复
  2. 完成了人物锚板的生成
  3. 完成了风格锚板的生成
  4. 完成了5次核心镜头的测试
  5. 开始自动化生成后续镜头

我觉得造成此次严重错误的原因有可能是

  1. 我在上一个会话中做了太多的事，上述的后4个工作都是在一个会话中去做的，从而造成会话窗口的多次自动压缩。
  2. 在5次核心镜头测试时，我没仔细检查，有可能也没用人物锚板

人物锚板和风格锚板都是花了大力气做的，目的是图生图。 但是在实际生成场景图片时：

  1. 人物锚板未经验证，即未做图生图，而是文生图
  2. 风格锚板的作用是什么，这部分我估计包括核心镜头测试在内也都是文生图

可以，你可以自己提交，而且这个提交现在很有必要。

但我建议把它定义成阶段性检查点 / 修复前基线提交，不要写成“镜头批量生成完成”或“核心流程验证通过”。因为这次提交里同时包含：

  1. intake 修复；
  2. 人物锚板、风格锚板；
  3. 5 个核心镜头测试；
  4. 批量自动生成的候选图；
  5. 批量生成暴露的问题和小修后的文件命名、s34 状态修复。

你的判断基本成立：上一个会话做太多事、多次压缩，很可能让执行约束逐步丢失。更关键的是，人物锚板和风格锚板的“存在”没有等于“被图生图验证并实际作为引用输入使用”。核心镜头测试如果也是文生图，那它验证的是“文字提示词能否生成接近方向的图”，不是验证“锚板能锁定人物 / 风格”。

所以这次提交建议命名成类似：

checkpoint on-the-road anchors and broad-run pause

或中文：

提交在路上锚板与批量生成暂停基线

提交说明里最好明确一句：

Broad-run images are candidates, not accepted finals. Identity/style reference workflow needs repair before further generation.

这样后续修复就有干净基线：不是否定前面所有工作，而是承认“锚板资产已完成，但锚板到场景图生成的引用链没有被真正验证”。

4

我已经全部提交。

本轮只回答问题。

那么接下来，应该先做验证测试吧？ 而在验证测试前，应该先调整一些规则，比如在生成Prompots，应该除了调用skill外（这个应该已经记录了），还要加上人物锚板和风格锚板的使用。 风格锚板，我是觉得不一定要用图生图吧；但是人物锚板必须用。

对，接下来应该先做验证测试，但测试前要先收紧规则。顺序应该是：

  1. 先修规则；
  2. 再做人物锚板图生图验证；
  3. 再做风格锚板使用方式验证；
  4. 最后才恢复后续镜头生成。

关键规则我建议这样定：

  • 每个 sNN-v1-prompt.md 必须有 Reference Inputs 区块，列出人物锚板、风格锚板、已接受核心镜头等实际使用材料。
  • 凡是出现可识别人物的镜头，尤其是中景、半脸、侧脸、背影行走，都必须使用人物锚板或人物切片作为图像引用。
  • 如果当前生成路径不能真实传入人物参考图，就不得生成身份关键镜头，只能生成环境类或低身份风险镜头。
  • 文本描述人物只能作为辅助，不得替代人物锚板。
  • 风格锚板可以不一定图生图，但 prompt 里必须说明它的角色：色调参考、构图参考、质感参考、情绪参考，还是反漂移参考。

你对风格锚板的判断也对：风格不一定必须图生图。风格锚板更像“视觉判准”和“风格约束”，可以通过文本化规则、参考图说明、核心镜头对照来生效。但人物锚板不同，它承担的是身份锁定，不能只靠文本。

所以验证测试最小集可以是：

  • 侧脸/半脸一张：验证眼镜、脸型、发型、胡须。
  • 背影行走一张：验证体态、背包、长外套。
  • 侧身行走一张：验证姿态和轮廓。
  • 中景环境人物一张：验证人物进入场景后是否仍然像同一个人。

这组通过前，不应该继续自动生成后续人物镜头。风格可以同步观察，但本轮真正的硬门槛应该是：人物锚板能否在场景图中被真实引用并锁住身份。

5

如果当前生成路径不能真实传入人物参考图，就不得生成身份关键镜头，只能生成环境类或低身份风险镜头。 这一条不成立，人物锚板就是根据我的证件照生成的，所以必须传入人物参考。 只是测试的是传入人物锚板，还是人物的front、back这些裁剪出来的。

这样看，首先应对characters做一个修复/清理，你知道现在哪些是人物锚板，哪些是裁剪出来要用的front这些么？

知道，基于现有文件名和自审记录，可以先这样分：

主人物锚板 / 总锚点

  • character-anchor-v2-codex-posture-test.png
    这是当前最重要的人物锚板，总体身份、正侧背、行走姿态、外套、背包、靴子都在里面。

辅助历史/文档类：

  • character-anchor-v1-codex-test.png：旧版测试图，应该不是当前主用。
  • character-anchor-board-v1.md
  • character-anchor-brief-v1.md
  • character-anchor-prompt-v1.md
  • character-anchor-prompt-v2.md
  • character-anchor-review-v1.md
  • character-anchor-review-v2.md
  • character-anchor-trial-plan.md
  • character-identity-lock.md

从 v2 锚板裁出来、应该用于图生图/引用的局部参考

脸/身份方向：

  • character-anchor-v2-front-reference-crop-tight.png
  • character-anchor-v2-front-reference-crop.png
  • character-anchor-v2-side-reference-crop-tight.png

背影/姿态方向：

  • character-anchor-v2-back-reference-crop-tight.png
  • character-anchor-v2-walk-side-reference-crop-tight.png
  • character-anchor-v2-walk-back-reference-crop-tight.png

从锚板抠出来的透明人物切片，适合用于姿态/轮廓/构图引用

当前应优先看 v2：

  • character-slice-front-v2-from-anchor.png
  • character-slice-side-v2-from-anchor.png
  • character-slice-back-v2-from-anchor.png
  • character-slice-walk-side-v2-from-anchor.png
  • character-slice-walk-back-v2-from-anchor.png

这些对应的 *-preview.png 是预览，不应作为主要生成输入；*-raw-alpha.png 更像中间产物。

旧版或制作过程素材，清理时要降级

  • character-slice-front-v1.png
  • character-slice-side-v1.png
  • character-slice-back-v1.png
  • character-slice-walk-side-v1.png
  • character-slice-walk-back-v1.png
  • *-v1-chroma-src.png

这些可以保留进 archive/source，别作为当前默认引用。

所以是的，下一步应该先整理 characters/，把“当前主锚板”“可用于图生图的裁剪参考”“可用于姿态/轮廓的透明切片”“历史/过程文件”分清楚，并写成一个明确 registry。

6

同意建立archive/。 archive/characters/放清理出来的人物文件，visual-system\characters/下只放有用的。 这个应该是人物锚点环节做完后的，一个步骤。

  1. 记录这个到规则
  2. 做人物锚板文件夹的清理

已完成，未提交。

我做了两部分：

  1. 在 VIDEO_WORKBENCH.md 记录规则：人物锚点阶段接受后，visual-system/characters/ 只保留当前可用人物引用；历史候选、过程 prompt/review、预览、中间文件移动到 archive/characters/；身份关键镜头必须从 active registry 选择人物图像引用。

  2. 清理了项目人物目录：

验证结果：

  • active characters/ 现在只剩 14 个文件：12 个 registry 引用图、character-identity-lock.md、character-reference-registry.md。
  • registry 中列出的 12 个图像引用都存在。
  • active 目录里没有 v1、preview、chroma、raw-alpha、prompt、review、trial、board 等过程文件名。
  • archive/characters/ 当前有 32 个归档文件。
  • git diff --check 通过，只有 LF/CRLF warning。

注意：因为只是移动文件，git status 现在会显示旧路径删除、新 archive/ 路径未跟踪；stage 之后 Git 才会把它们识别成 rename/move。

7

我手动做了提交。

那么下一个，风格锚板：

  1. 也要做类似的整理或清理
  2. 首先需要检查下核心镜头测试时，应该没有做图生图，只是做了文生图。

但是这个图片效果我觉得可以。那么风格锚板，是不是更应提供的是一套风格提示词母版。

是的，风格锚板更应该沉淀成一套风格提示词母版，而不是强制要求图生图。

我刚查了 5 个核心镜头记录，结论基本明确：它们不是实际图生图。比如 s10-v1-prompt.md 和 s46-v1-prompt.md 都写了使用 standalone prompt，host image tool 没有显式 file-reference 参数；review 里也写了 reference 只是本地 read/viewed，不是 attached。

所以风格锚板和人物锚板应该分开处理：

  • 人物锚板：身份锁定，必须图像引用，不能只靠文字。
  • 风格锚板：可以主要转化为提示词母版，因为它控制的是色调、构图逻辑、质感、情绪、反漂移边界，不一定必须图生图。
  • 风格图像仍然有价值，但角色更像“视觉样本 / 校准板 / 回看标准”，不是每次生成都必须作为输入图。

我建议下一步整理 visual-system/style/ 时保留三类核心资产：

  1. style-anchor-board-v1.png：总风格板，用于人工/视觉校准。
  2. style-anchor-c-repair-v1.png：C 风格已修复接受样本。
  3. 新建一个 style-prompt-master.md 或 style-reference-registry.md：把 A/B/C/D 的可复用提示词母版、禁止项、适用镜头类型、参考图角色写清楚。

其他 brief/spec/review/trial/html 这类过程文件，可以像人物一样归档到 archive/style/。重点不是让风格锚板每次参与图生图，而是让每个镜头 prompt 都明确继承哪一个风格模块。

8

现在又快到了窗口上限，是交接，还是压缩？

建议交接，不建议继续压缩。

原因很简单：接下来要做的是“规则修复 + 风格目录清理 + 风格提示词母版 + 人物图生图验证测试”，这些都需要清楚的阶段边界。继续压缩容易再次丢掉刚刚理清的关键差异：

  • 人物锚板 = 必须真实图像引用；
  • 风格锚板 = 更适合提示词母版 + 视觉校准板；
  • 核心 5 镜头实际是 standalone prompt，不是图生图；
  • 后续生成前必须先修 prompt 规则和验证路径。

最好现在写一个 file-backed handoff，然后新开会话继续。handoff 应该包含：

  1. 已提交到哪里；
  2. 当前结论；
  3. 已完成的人物目录清理；
  4. 风格目录待清理；
  5. 5 个核心镜头的证据结论；
  6. 下一步建议顺序。

这样新会话可以直接从文件开始，不依赖压缩后的聊天摘要。

9

包括需要阅读的资料。 现在准备一个交接文档。

已准备好交接文档，未提交。

主文档： handoff/2026-06-24-on-the-road-style-reference-handoff.md

辅助 context/manifest： review-context.md
review-file-manifest.json

里面包含了新会话必须阅读的资料、当前结论、五个核心镜头不是实际图生图的证据、人物锚板已清理状态、风格锚板下一步、以及不要继续做什么。

验证也跑了：

  • context-builder 已生成 handoff context。
  • lifecycle/status scan：PASS，0 blocking findings。
  • git diff --check：无输出，退出码 0。
  • 当前新增文件都在 handoff/ 下，未提交。