BBS 驱动的导演编排与 Shot 包装

01 · 杨涛需要牵头确定什么

业务目标是提高相同 topic 下的内容消费价值。系统目标是让“人类为什么这样剪”能够被记录、转成可执行策略、在不同案例上验证，再持续改进下一版策略。离线偏好与表达理解度用于早期代理指标；真实消费价值仍需后续线上对照验证，不能由一条演示片或一个模型分数代替。

杨涛的关键工作包： 先把“业务表达 → 中间合同 → 执行工程 → 评价反馈”的连接方式设计清楚；以两个贯穿样例推动联调；每阶段对效果、稳定性、成本共同作出继续、缩范围或回退的判断。应避免把所有包装实现、素材修复和日常问题都集中到杨涛一人。

首轮评审建议产出五份小而完整的附件： 现状与增量矩阵；三个核心 JSON 实例；两个案例的端到端对应图；带责任人的依赖清单；质量/延迟/成本门槛表。本文分别给出了初稿。

02 · 当前方案能承接什么，还需要补什么

当前方案已把任务编排、模型决策、确定性工具、可编辑 Draft 和渲染区分开。这是新需求可沿用的基础。会议带来的增量，是让表达意图、证据关系和可迁移的剪辑经验，成为系统中的正式数据，而不是只留在设计师或 Prompt 中。

三条现状限制，直接影响路线

• 不能把全部品类视作同一条链路。 Type1 无额外 TTS；Type2 用真实 TTS；Type3 音乐混剪与固定模板混剪入口、状态和修改机制不同，虽然可能共享 MIX_EDIT genre；Type4 是解说。先统一合同，再逐一接适配器。（P4、P22）
• 不能宣称已经能“只重做任意两个 Shot”。 当前音乐混剪 replay 是节点级；其他 workflow 的 complete/rerun 也有适用范围与状态冲突约束。局部重新规划、局部重新计算与只渲染局部片段是三件事。（P16–17）
• 不能从存在工具推断主链已接通。 Reframe 是独立离线支线，材料没有证明所有主流程普遍消费其结果；新增标注、对比、时间线、词级对齐也需要核验具体能力。P0 要逐项实测，不按名称认定可用。（P21）

对现有质量与成本目标的承接： 保留良品率 ≥X%、优质率 ≥Y%、剪辑主责问题视频占比 <Z%，数值仍待产品、设计与技术共定；保留动作完整、事实一致、音乐主次、构图稳定等标准。原文 Reframe <0.1 元/源视频分钟是该能力的独立目标，不等于整片成本预算。飞书正文

03 · 把会议共识翻译成系统要求

导演包装与 Shot 包装的边界： 导演层决定“用哪些证据、按什么关系与节奏表达”；Shot 层决定“在这个素材和时间窗口里，怎样让证据/情绪被看见”。二者通过同一个表达计划连接，避免导演只产文案、Shot 只产样式。

“正推”不等于一次生成后不允许修改。先形成不带虚构源时间码的意图，再由真实素材约束计划；实际 TTS、动作完整性或渲染能力使计划不可行时，只在受影响范围内修订。允许这两类有界回路，是让正推可落地的必要条件。

内容变更规则建议： 默认允许素材选择、画面顺序、包装、停顿与局部时间安排；默认锁定主题、关键事实、引用数据和用户指定素材。旁白压缩沿用现有受约束机制；更改事实、核心论证骨架或上游指定内容时，生成明确 diff 返回上游或进入既有人工处理流程。正常剪辑不增加逐镜确认负担。

04 · 总体架构：在线成片链与离线经验链

采用现有服务中的模块化增量实现。以下是逻辑模块，不要求首期拆成多个微服务。Workflow 负责阶段依赖和恢复；模型负责语义判断与候选计划；确定性服务负责时间、边界、能力和成本约束；Draft 仍是可编辑工程的统一事实源。

在线链各模块的输入、输出与失败出口

一次生产任务保存两类产物： 交付层保存成片与 Draft；过程层保存计划、证据、候选摘要、选择理由、版本、检查、成本与反馈。不要把检索候选和全部过程日志塞进 Draft，也不要只保存最终 MP4，导致后续无法知道一处编辑为何发生。

05 · 最小必要的数据合同与状态

采用“公共版本信封 + 明确业务对象”。所有对象使用稳定 ID、不可变 revision、父依赖引用、来源版本和生产者版本；大文件放对象存储，结构化元数据放现有数据库。首期用 JSON 表达关联图，不引入图数据库前置依赖。

公共字段建议： schema_version / artifact_id / revision / parent_refs / source_version / producer_version / created_at。任务另带 project_id / execution_id / generation / idempotency_key，所有生产输出固定 recipe、模型/Prompt、能力与输入版本，避免重放时悄悄换策略。

必须分开三种状态：

• 证据状态： verified / uncertain / rejected。模型置信度与人工/工具核验来源单独记录；“高置信”不自动等于事实正确。
• 执行状态： valid / invalid，以及失败阶段、可重试性、错误码。能成功渲染不等于表达成立。
• 表达评价： preferred / tie / not_preferred，含具体时间段和理由。更好看不能覆盖证据错误的否决。

还要区分“素材本身已核验”与“该素材支撑当前命题”。每个 EvidenceNeed 单独输出 satisfied / partial / unsatisfied，引用支持判断、claim 版本和可见事实；编译前检查核心 need 已满足。素材 verified 但与当前 claim 无关，仍必须被拒绝；纯评价性主张标明证据能力边界，不能伪装成已证实事实。

三个核心合同示例

以下为库里案例的提案格式示例，ID 均为占位；没有真实素材引用与已核验源时间区间时，不能直接执行。符号锚点将在素材核验、TTS 对齐后绑定，避免先拍脑袋填秒数。

{
  "schema_version": "director-plan.v0",
  "artifact_id": "plan-demo-001",
  "revision": 1,
  "beat_id": "beat-range",
  "audience_takeaway": "看清投篮位置远，并看到同一球的结果",
  "claim_ref": "claim-shooting-range",
  "role": "visual_evidence",
  "speech_visual_relation": "establish_then_reveal_then_reflect",
  "relations": [{"to": "next-beat", "type": "evidence_to_conclusion"}],
  "evidence_needs": [{
    "need_id": "need-midcourt-shot",
    "required_visual_facts": ["人物已核验", "位置参照可见", "出手到结果属于同一事件"],
    "forbidden_substitution": ["不同进球拼接", "无来源的精确距离数字"]
  }],
  "anchors": ["position_recognized", "shot_release", "shot_result", "reflection_end"],
  "editable_scope": {"visual_order": true, "pauses": true, "core_claim": false}
}

{
  "schema_version": "asset-evidence.v0",
  "artifact_id": "evidence-demo-001",
  "asset_ref": "<待绑定的源素材 ID 与 hash>",
  "source_range_ms": null,
  "event_id": "<待核验>",
  "required_landmarks": ["投篮位置参照", "篮筐"],
  "action_anchors_ms": {"release": null, "result": null},
  "supports_claim_refs": [],
  "verification": {"status": "uncertain", "method": "pending", "review_ref": null},
  "execution_ready": false
}

{
  "schema_version": "shot-program.v0",
  "shot_id": "shot-evidence",
  "recipe_ref": "spatial-evidence@1",
  "evidence_refs": ["evidence-demo-001"],
  "preconditions": ["evidence.verified", "need.satisfied_for_current_claim_revision", "source_range.bound", "action.result_visible"],
  "operators": [
    {"op": "play_source", "range_ref": "verified_action_context", "preserve": ["release", "result"]},
    {"op": "hold", "at": "shot_result", "duration_policy": "brief_reflection"},
    {"op": "annotate", "target_ref": "verified_position", "when": "position_recognized",
     "enabled_if": "capability.annotation && layout.safe"}
  ],
  "layout_constraints": ["keep_position_reference", "keep_ball_and_result", "avoid_subtitle_zone"],
  "fallback": "natural_playback_with_readable_context",
  "execution_ready": false
}

对合同的验收应包含至少三个路径：可成功编译的正例；证据未核验时被拒绝；能力不支持时采用已声明降级。合同字段名与类型在 P0 对照真实代码确定；示例不能作为当前已存在的 API/schema。

06 · 导演规划：先决定表达什么，再让素材约束方案

6.1 全篇理解与初步导演计划

先读取整篇 BBS、旁白与前后 beat，提取主题、核心论点、人物/事件/数字、叙事阶段、情绪变化、受众背景和制作约束。每个 beat 必须回答：观众进入这一段时已知什么；离开时应多理解或感受到什么；哪一段画面/声音承担这种变化。

导演计划使用少量清晰关系，例如铺垫、事实支撑、对比、因果说明、反应和收束。关系是表达意图；如果因果或时间先后缺证据，不应因为选了一个关系标签就被当成事实。字幕、旁白、图形中的数据继续引用事实来源。

输出每个 beat 的主表达方案与少量备选，包含证据需求和失败出口。P1 建议最多保留 2 个可执行候选；先控住路径数量和诊断难度，数量上限通过基线再调整。

6.2 素材落地后的二次编排

已有 Story 在 shot_assets 确定后运行整体创意，这一约束值得保留。新流程在其前面增加“需要什么表达与证据”，在其后面细化“这些真实素材怎样表达”。Grounded Beat Composer 根据素材覆盖、动作阶段、TTS 时间和能力集合，把抽象计划落成镜头顺序与时间锚点。

镜头间需要显式记录：同事件连续、解释前一镜、前后对比、反应、主题转折、时间跳跃等。对连续动作要求同事件与合理源区间；对有意跳跃要求表达上可辨识，不能把所有不连续都判成错误，也不能让不同事件误装成同一动作。

6.3 两个有界修订回路

首期建议每类新回路最多 1 次自动修订，失败继续走明确出口；与已有 Story 旁白修复的最多 3 次尝试共同纳入任务总预算，不能相乘形成隐性调用爆炸。次数是初始配置建议，P0/P1 实测后确定。（现有旁白次数依据 P8 备注。）

07 · 素材检索与理解：从“相似”到“支撑表达”

输入检索器的是 EvidenceNeed。例：“找库里接近中场位置的真实投篮，投篮位置有参照，出手到结果可核验，允许同一事件的多机位”，而不是直接把“伟大的射手”整句做向量搜索。

建议的路径是：精确条件过滤 → 语义召回 → 候选片段定位 → 动作/画面可见性核验 → 对论点的支持核验 → 返回可用区间与备选。 各步可复用现有搜索、理解和素材服务，接口统一比首期重建索引更重要。

与内容理解侧的协作方式

向杨正云提出统一的结构化交付合同：素材/事件 ID、可见事实、动作锚点、ASR/OCR 引用、空间参照、质量与核验状态。短期剪辑可用人工核验包或已有工具填合同；内容理解侧逐步替换生产者，避免新方案依赖一次完整理解系统重建，也保护其现有实时主业务。

素材理解以资产为单位缓存：源文件 hash、理解模型/Prompt 版本、采样方案与语言等参与缓存键。共用原片的不同工程优先复用元数据；只对高不确定、低覆盖或关键动作区间补看。不能把“读取更少帧”直接当成“相同效果且同比例省钱”，需要记录召回与证据核验质量。

缺口处理顺序

1. 优先回源或扩大合理召回范围，保留实体/事件等硬约束。
2. 若存在等价且真实的表达，修改视觉方案并记录原因。
3. 采用预先允许的朴素呈现，例如真实素材自然播放、带来源的静态信息；不得用文字包装补造证据。
4. 核心论点仍无可用证据时，标记未满足需求并进入产品规定的人工/失败出口。不可为了成功率静默配一段“看起来差不多”的视频。

08 · Shot 包装、时间求解与 Draft 编译

8.1 包装程序采用有限组合

ShotProgram 使用经过验证的算子及参数化 recipe。模型选择“为了什么做哪些操作”，确定性代码决定源区间合法性、位置边界、时间与能力兼容。首期不允许模型在线生成任意渲染代码或任意插件。

“字幕可渲染”不等于“任意时间线图表可渲染”。每个 Capability 条目应声明输入 schema、适用范围、版本、时间/布局限制、前端表示、渲染实现、回读能力、校验器、降级与实测状态。已有 Draft 轨道提供表达位置，但不自动证明每个高级效果已实现。

8.2 真正把旁白、画面与停顿联合起来

保留真实 TTS 作为时长基准；词/句级对齐是否现成需要 P0 核验，没有时先采用句级区间或离线对齐适配器。导演计划的 position_recognized / release / result / reveal / reflection_end 等符号锚点，在素材和语音明确后才落成具体毫秒。

时间合同显式区分 source_time_ms（源素材）、speech_time_ms（语音音频）和 draft_time_ms（成片），并标明 asset/track ID、revision。求解结果输出分段 TimeMap：源区间如何经过取段、变速、定格映射到成片；语音如何放置、插入停顿并对齐字幕。定格是单一源时刻对应成片区间，不能按普通线性播放换算。同名锚点通过 ID 和对应 TimeMap 解析，不在不同时间域直接复用毫秒值。词级时间缺失时不承诺词级同步，采用句级能力并标明误差范围。

求解器输入包含硬约束和可优化偏好。硬约束包括源区间、关键事实、动作阶段、语音不截断、字幕和数值最短可读时间、目标总时长边界等；偏好包括切点自然、揭示时机、停顿长度、音乐呼吸、包装密度。P1 采用规则与现有区间求解服务；只有在约束冲突成为实测瓶颈时再考虑引入通用约束优化器。

调度可采用“提前生成或复用最终交付 TTS → 导演/素材绑定 → 对齐并求解”；复用已验证语音，不因视觉修改重做整段 TTS。如果先用临时语音估时，最终音频生成后必须重新对齐和求解，不能以临时结果直接交付。需要改旁白时显式失效对应语音、字幕与后续受时长影响的时间线。保留动作结果后的一点停留是表达选择，具体时长必须按素材、语速和设计评审确定。

8.3 编译保持工程可编辑

编译器负责将已解 ShotProgram 映射到 canonical Draft 六类轨道、模板控制及转场关系，保留 plan_node_id → draft_part_id。包装图形如果无法在前端编辑，必须在 Capability 中说明并采用双方接受的受限方案，不能交付一个只能播放但完全无法修改的黑盒结果。

检查分为三层：编译前验证 schema/能力/证据与时长；编译后验证轨道覆盖/引用/布局/音轨；渲染后检查实际画面、字幕、动作结果、声画关系。应针对风险使用确定性检查、模型辅助和人工抽检；“支持关系成立”“情绪表达好”无法完全靠时间线检查证明。

8.4 各品类如何接入

09 · 贯穿案例：库里中场投篮如何支撑表达

会议例子是“通过库里中场投篮视频，支撑他是伟大射手、把投篮范围扩大到中场的观点”。下面是工程化示范，尚未绑定或核验真实视频，不是已完成的样片效果。

“伟大”是评价性总结；单个中场投篮片段可以帮助表达射程与能力，不能单独证明历史地位、比赛普遍表现或精确统计。这一边界必须体现在 claim 与证据绑定中。

两个明确反例

• 只有人物近景，没有投篮位置参照： 它可以表达人物或情绪，不能承担“射程非常远”的主要视觉证据。回源或更换表达，不能仅叠“中场”字样冒充证明。
• 出手与入网来自不同事件： 不能拼成同一球；若是说明性蒙太奇，应在表达与标注上避免制造该事实关系，并重新判断是否满足核心证据要求。

第二个集成样例：有来源的前后对比

建议与设计侧共同选取或补充一条“同一指标在两个时间点发生变化”的案例，会议未确认此类案例已经存在。导演层确认对比口径与时间关系；证据层记录来源、页/表/字段定位、原始值、单位、统计范围及素材；Shot 层选择可读的双栏/顺序揭示；求解器给足读数时间；QA 检查数值、单位、缩放和旁白一致。若口径不同，不能通过视觉包装暗示可直接比较。若短期拿不到可靠数据案例，先用有证据的非数值前后对比完成集成，数值包装延后。

这两个样例分别覆盖“视频动作证据”和“多模态信息证据”，足以暴露合同是否实用。首期不应只用一类炫技镜头验证整个架构。

10 · 数据飞轮：什么数据进入，怎样证明迭代有效

飞轮的最小单位是一个可追溯的“案例 → 决策 → 执行 → 反馈 → 改版 → 新案例验证”闭环。设计师作品是经验来源；原素材、编辑工程和决策解释帮助抽象规则；成片偏好与人工修改用于判断规则是否有效。

10.1 四类资产要分别定义

产品沈凡琳牵头把这四类对象从 Before/After 中抽象清楚；技术为它们建立稳定 ID 与引用关系。知识不等于 Prompt 文本；策略不等于具体素材；基础能力不等于导演规则；模板也不应成为四者混杂的容器。

10.2 设计交付的最小案例包

每个案例至少包含原 BBS、Before/After、原素材引用与区间、可编辑工程或关键时间点清单，以及 3–5 个主要决策说明：改了什么、为什么、何时不能这样改。可增加被放弃的方案、制作耗时和已知缺陷。缺失的字段明确标注，不要求设计师先手填所有技术 schema。

P0 由技术/产品和设计一起拆 2 个案例，形成一页标注模板。自动抽取可以辅助整理；如果只拿到成片，作者意图只能标为 inferred / unverified，等待设计确认后再晋级，避免把系统猜测当成人类经验。

10.3 策略生命周期与一次真实闭环

draft → tested → shadow → approved → retired：草稿策略经过正例、反例、可执行性验证；影子任务产生成片但不直接替换用户交付；设计/产品确认表达收益，技术确认执行与预算后发布；发现回退信号时固定旧版本继续生产。

例如第一版“结果后定格”在人物故事里有效，但在依赖连续动作的场景显得拖沓：评审记录对应时间点，人工删除定格并给出原因；第二版增加“连续动作优先时禁用/缩短”的条件；在未参与这次修订的新案例上比较 v1/v2。如果只是重放原例变好，不能宣称具备经验泛化能力。

首期闭环必须真实跑完一次： 至少一个来自设计的经验条目成为可执行 recipe；发生一次有依据的修改；修改后经过新案例与反例检查；发布版本能够在生产任务的 manifest 中准确定位。只做自动采集、不做改版验证，不算闭环。

10.4 反馈采集与因果边界

编辑器保存 Draft 修改前后 diff，通过 plan/Draft 映射关联到 beat/shot、策略和证据。默认记录结构变化，关键改动附轻量理由标签，如事实不符、时机不对、节奏拖沓、遮挡、信息难读、偏好调整。P1 可以由案例包/导出差异完成，不要求第一天改完整编辑器；P2 再减少人工录入。

人工修改不天然意味着模型错误，未修改也不代表高质量。反馈需区分客观修复、主观偏好、需求变化；对改动原因和数据质量保留置信/确认状态。多个策略同时变化时，不将全部收益归给一个 recipe。

数据集按主题/事件/原始素材分组划分设计集、开发集和保留评估集，避免同一事件不同裁切跨集泄漏。用于当前版本调参的评估样例不再作为该版本的独立验收依据；新版本持续补入未见案例，同时保留固定回归集。

11 · 技术选型与策略实现

11.1 推荐决策表

这些选型强调复用现有工程；引用的官方规范说明实现方法，不构成对当前仓库依赖版本或部署状态的确认。

11.2 一个 Recipe 需要包含什么

策略可描述一个 beat 级表达子图，再引用若干 Shot 操作。调用时先检查适用条件，生成有限候选，检查能力、证据、时长与预算；符合条件的方案才进入执行。自然呈现是合法候选，不需要每次挑最复杂的包装。

recipe: spatial-evidence
version: 1
goal: 让观众理解空间上的反常程度，并看到动作结果
applies_when:
  - 主张需要可见的空间证据
  - 位置参照与关键动作属于可核验事件
reject_when:
  - 只有近景且无法识别参照
  - 出手与结果无法对应
  - 裁剪后核心证据不可见
plan:
  - establish_reference
  - show_complete_action
  - allow_result_to_register
optional_capabilities:
  - safe_annotation
fallback: natural_playback_with_reference
postconditions:
  - 核心参照、动作和结果在成片中仍然可辨
  - 不添加未经核验的数字
evaluation:
  positive_cases: required
  counterexamples: required
  heldout_transfer_result: required_before_approval

候选排序先按硬条件剔除，再综合表达适配、证据覆盖、风格兼容、执行可行与预算选择。P1 用规则和模型比较；P2 根据明确的偏好数据校准。不要提前给“情绪 51%、故事 23%”等经验优先级套成自动评分权重；P12 引用的 Murch 原则不是本业务测得的权重。

12 · 版本、修改与可靠执行

12.1 先利用阶段重跑，再做细粒度依赖分析

P1 保持原 workflow 的缓存与重跑边界，新节点输出不可变 artifact。P2 补足输入/输出依赖和编辑映射；P3 再基于依赖图返回影响范围。修改一个 Shot 时，要检查相邻逻辑、转场、BGM 和总时长，不默认“只有这个 Shot 受影响”。

最小可靠性从 P1 就实现：父依赖引用、plan/Draft 映射、总预算/超时、幂等键、固定策略版本和回退到旧策略/流程。P2/P3 完善自动化、覆盖范围与生产演练，不把这些基础能力推迟到上线前才补。

缓存键至少含输入内容/素材 hash、schema、模型/Prompt、recipe 与能力版本。源文件、事实、全片风格、TTS 或规划版本变化时按真实依赖失效；显式锁定素材/旁白不能被重跑静默替换。不复用已失效的证据判断，避免缓存让错误看起来更稳定。

建议新增的修改影响接口（P3，不是现有 API）： 输入项目 revision、目标节点/Shot、修改 patch、锁定项；先 dry_run 返回失效节点、预计调用与成本范围、保留项、阻塞条件；正式提交带 expected_revision、幂等键和预算。版本冲突返回明确冲突，不自动全量重跑。该接口优先调用已有类型适配器；不绕开现有 dev_user、任务状态与权限限制。

12.2 失败与降级要有明确语义

每个节点输出 completed / degraded / needs_review / failed 与原因、产物、费用。degraded 只有达到预先约定的最低交付标准才计入可用；未满足核心论点、动作结果缺失或事实冲突不计“成功”。

设置任务级最大调用次数、费用、墙钟时间和可修订次数。区分临时网络故障、可修复约束冲突、证据缺口、模型输出错误和不可重试输入错误。重试重用输入版本并保持幂等；错误不能只以一句“重新生成”隐藏。

发布采用场景白名单、固定策略版本、影子对照、小流量灰度与一键回退。回退到已知可用的 workflow/recipe 组合，保留失败轨迹；新模型与新策略尽量分开发布，避免无法判断是哪项变化导致回归。

13 · 验收：表达价值、稳定性、成本三条线同时看

13.1 先分开两个实验

两者分别统计，不把更好的素材召回都归因于包装，也不把只在固定素材上验证的结果宣称为完整检索链提升。交付时同时展示输入、对比片段、差异和失败例。

13.2 延续原文 12 个 QA 维度

产品/设计制定表达与优质标准；创作对输入事实/结构负责，搜索/理解对素材匹配与事实标注负责，剪辑对成片汇总与装配质量负责。需要区分输入问题与剪辑引入问题，但面向业务展示总问题率，不能通过责任分类从分母中删除坏结果。

13.3 推荐的阶段验收口径

以下数值是待 P0 基线后签收的建议门槛，不是原文已有指标，也不是当前实测结果。样本量用于控制验证工作量；若统计不确定性仍大，需要补样本或缩小结论。

偏好计算建议： 每对先按评审票形成案例胜/平/负；偏好得分 =（新方案胜例数 + 0.5 × 平例数）/ 全部预先登记的配对案例数。新失败而旧可用计负，旧失败而新可用计胜；双方都失败保留在分母并按 0 分计入该保守分数，同时独立报告双失败率。这样不会用“失败算平局”抬高结论。除总分外，另报双方可用条件下的偏好、有效配对数及无效原因。按主题/事件组做 bootstrap 区间，避免把三位评审或同一事件多裁切当成独立案例。判定单元、冲突裁决与最低组数在 P0 固定。

P0 预先固定样本规模、独立主题/事件组数和查看结果的时点；不能反复补样直到普通 95% 区间越过门槛。修改策略、调整发布场景或根据结果改口径后，使用新的独立验证样本；如需连续查看，另行采用适合连续检验的规则。最终可用率与良品/优质标准分别定义：前者衡量请求能否获得满足最低交付要求的结果，后者衡量成片质量等级。

这些早期门槛还不能证明线上留存或观看时长提高。P3 条件成熟后，由产品设计同 topic/人群分层的灰度对照，观察有效观看、完播、理解反馈等业务指标，并控制流量分配与内容差异；不在本稿预设业务 uplift 数字。

13.4 成本账必须重建口径

PPT P18 的约 $0.07/分钟是历史已记录 AI/API 费用除以全部完成工程时长的下限，含缺成本记录的工程在分母，不含完整渲染、存储、带宽、共享预处理和人工。P17 的 $0.09 是未实际执行的两个 Shot 按比例估算；97.60% 是预算对比，不能当成实际节省。P20 的视觉检查降本是情景测算，不是本方案已达成收益。

建议建立两本可对账视图：单次增量成本（本次实际新增调用/渲染等）和完整交付成本（增量 + 共享处理摊销 + 人工 + 基础设施分摊）。分别报告每有效请求、每可用成片、每输出分钟；素材预处理再报每源视频分钟，不能混用分母。

费用记录关联供应商请求、节点、execution/generation、尝试次数、币种、价目版本、缓存命中与估算/实记状态；对同一实际供应商调用去重，不能因跨 generation 复用业务 ID 而漏记新调用。未取得价格/用量记录的项目标为未知，并报告费用覆盖率，不能记零。失败、重试、回退和人工修复计入总体成本。

预算分配顺序建议：先约束总任务，再分配检索/理解/规划/执行/修订额度；低成本硬条件筛选在前，关键区间精看在后；复用原片理解、真实 TTS 和未失效阶段产物。质量达到同一标准后比较成本，避免以漏做检查制造“节省”。

14 · 分阶段实现节奏与明确出口

资源假设： 约 3 名工程同学持续投入，杨涛约 0.5 人力负责牵头与关键集成，设计/产品有固定案例与评审时间；内容理解/创作提供接口协作。现有维护、休假与其他业务需预留容量。会议没有确认人力或日期，以下按有效研发周估算，W1 是正式启动周，不能据此自动承诺上线日。

原文标题的“9–10 月目标”与这里约 10 周的完整建设估算不是同一个时间承诺。若 10 月底仍是硬截止，应按剩余有效研发周折算，优先交付 P1 和可完成的 P2 范围；P3 受控生产以及实时/训练能力另设出口，不把所有长期目标压进原周期。

P0 · W1：冻结首期合同、样例与基线

目标： 所有人对“输入什么、产出什么、为什么这样剪、何时算成功”有可检查的一致理解。

交付 BBS 兼容映射、三核心合同 v0、现有节点/能力/编辑器/渲染核验表、素材证据适配器方案、6–10 个案例的获取清单；至少完整拆解 2 个案例及 1 个反例。测旧链路质量、调用、成本和延迟，定义 X/Y/Z、预算 B 与评审规范。确认设计可交付素材/工程，避免后面拿不到可复现实例。

阶段出口： 两个实例能沿 BBS → 计划 → 证据 → Shot → Draft 映射；所有首期原语有可用证据或明确降级；核心接口、责任人、资源和门槛已签收。样例或能力不足则缩小范围，不跳过这一阶段。

杨涛抓手： 主持架构评审、拆掉跨团队阻塞、冻结第一版接口和场景范围，避免各模块从不同定义开始写。

P1 · W2–3：人物故事的最小端到端闭环

目标： 由真实设计案例驱动成片，形成一次实际经验修订与新案例验证。

在 Type2 中接 BBS Adapter、简版导演/证据计划、2–3 类表达 recipe、少量可靠原语、真实 TTS 求解和 Draft 编译；检索/核验必要时采用人工证据包，但经过同一接口。保存 manifest 和评审，允许人工辅助案例标注/版本审批，不以搭完整管理后台为前置。

阶段出口： 6–10 个真实案例完成链路验证，至少一组固定素材的 Before/After 被设计/产品认可；至少一次“案例 → recipe v1 → 评审/改动 → v2 → 新案例/反例验证 → 发布”闭环；每次输出可追踪且失败有明确出口。该规模证明链路可用，不宣称统计意义上的优质率提升。

杨涛抓手： 用库里类视频证据和有来源对比两个样例牵引联调，检查语义计划是否真正进入 Draft，而不只停留在日志里。

P2 · W4–6：经验迁移、检索增强与 Type4 适配

目标： 证明 recipe 可以跨案例使用，并减少依赖人工素材包。

完善策略注册/版本/条件，接结构化素材理解与证据重排，加入有界计划修订、反馈 diff 和经验审核；建立开发/保留数据分组。人物故事达标后接 Type4 适配器，验证数值/时间线或另一类高频表达，不要求所有高级包装全部上线。

阶段出口： ≥30 个保留案例的方向性评估、≥2 次有可追踪结果的经验迭代；效果和失败分类按场景展示；确认某些策略应该被拒用；完成 Type4 接口与至少一类表达的影子验证。若 Type2 质量尚不稳定，先延后 Type4 扩展。

杨涛抓手： 重点审“新案例为什么有效/无效”，决定保留规则、调整素材要求还是增加原语，防止不断加 Prompt 掩盖边界问题。

P3 · W7–10：生产约束、受控发布与修改能力

目标： 在可控质量、延迟与完整成本下持续交付，并能定位问题、保护确认内容、回退版本。

落实任务预算与超时、幂等、错误分类、影子/灰度/回退；补齐依赖影响分析、编辑映射和用户修改保护；完成端到端配对评估及受控试产。细粒度重规划以核验过的范围上线，不把局部渲染作为必要承诺。

阶段出口： 达到 P0 签收的 X/Y/Z、SLO、预算和 P3 建议样本/可用率门槛；核心事实和执行红线通过；至少两个受控发布/回退演练周期；未達标场景保持白名单外。上线取决于出口，不以周数到期自动放量。

杨涛抓手： 对效果—成本—稳定性作合并决策，给出可以扩量的品类/表达清单、仍受限场景和后续投入依据。

P4 · W11+ 或条件满足后：训练、实时化及更多品类

目标： 将已验证的经验和轨迹转为模型可吸收的数据，探索更低延迟的执行方式。

与凯歌/Wayne、杨正云共同定义数据集与任务：导演计划/证据需求生成、策略选择、结构化理解、修订偏好等。先离线比较检索经验、规则、微调/蒸馏的增益，再决定训练路线。实时链路可采用预计算素材理解、已发布策略检索、轻量规划和确定性编译；复杂离线理解留在后台资产处理。

阶段出口： 新模型在隔离评估集上同时满足事实、表达、延迟与成本门槛；不牺牲现有实时核心业务。数据量、任务边界和收益尚未验证，不能仅按“第 11 周到来”认定训练条件成熟。Type1/音乐混剪等扩展根据各自评估单独排期。

15 · 分工建议、接口与前十个工作日

会议明确杨涛牵头总技术方案；技术同学的具体模块分配未指定。下表是便于评审的建议安排，需结合现有职责和可投入时间调整，不代表他人已承诺。

BGM、混音和 QA 跨模块，不另造责任真空：杨涛协调共用接口，章可可承接时间线，相关能力由执行负责人接入；若现有人员分工不同，以评审确认结果为准。素材/搜索服务的具体对接人也应在 P0 补齐，不能默认全部归内容理解同学实现。

前十个工作日建议安排

每周用一次集成演示和一次案例/失败评审协调进度；演示输入、成片、关键变化、成本与失败，不以各模块各自完成率替代整链结果。接口变化保留小型决策记录，写明动机、影响对象、迁移策略和验收案例。

16 · 风险、降级路径与待确认事项

首轮评审需确认的六件事

1. 首期是否接受 Type2 单领域先行、Type4 在 P2 适配；两个贯穿案例由谁提供完整包。
2. BBS 实际 schema、稳定 ID 和可改边界；创作/剪辑遇到内容变更如何交接。
3. 具体人力与原 9–10 月目标的截止约束，是否能满足这里的有效研发周假设。
4. 素材/搜索/理解的对接人、字段覆盖和实际可用性；人工证据适配器的过渡范围。
5. 现有 renderer/editor/TTS/Reframe 的能力核验结果与首期原语白名单。
6. X/Y/Z、成本预算 B、p95 延迟 SLO、盲评组织与阶段签收人。

这些事项影响实施范围与承诺日期；不妨碍先完成合同、案例拆解、现状核验和基线采集。

17 · 给创作与内容理解侧留下什么长期资产

长期价值来自可验证的结构化数据：全篇上下文与表达目标、需要的证据、真实素材及可见事实、选择的策略与参数、执行结果、人工修改与偏好。记录的是可审阅的业务决策理由与事实依据，不要求保留模型隐藏思维过程。

可逐步形成五类训练/评估样本：BBS → 导演/证据计划的专家示范；上下文与素材 → 策略选择；素材 → 可见事实/动作锚点；同条件成片的偏好对；失败状态 → 修复 diff。每类都带来源、版本、核验与使用范围，拒绝样本和不适用条件同样有价值。

训练路线应按瓶颈决定：如果主要问题是检索不到经验，先改善注册与检索；如果能找到策略但参数常错，考虑结构化输出或针对性训练；如果实时延迟是主要瓶颈，再比较蒸馏、预计算和轻量规划。部署前用隔离数据验证真实收益，同时保留确定性证据/执行门禁。训练成功不意味着可以移除素材事实核验与工程约束。

18 · 依据、引用与本稿边界

主要依据： 飞书《剪辑 Agent 9–10 月目标｜导演编排与情绪表达》；附件《剪辑 Agent：从创作意图到视听编排》（2026-09-15）22 页及备注；用户本轮提供的会议纪要。附件已在前序任务完整读取，本稿重新核对了相关正文/备注的本地提取资料。

技术选型参考为 JSON Schema 2020-12、Milvus 过滤搜索、OpenTelemetry Traces。均用于支持实现方法，没有据此宣称当前系统已接入。

证据边界： PPT 中提及的代码依据为当时 main 10f76c6d，部分 Type1 更新参考 cc8e7658；这不等于本轮对当前代码/生产部署的审计。P2 为播放提示，P15 样片待补；本稿没有据此虚构已观看效果。未递归读取飞书正文指向的全部其他文档。本文所有新合同、接口、策略、排期、分工与验收数值均为方案建议，实施前按阶段核验。

阅读方式： HTML 为单文件，内容、样式、图示与交互均内嵌，无需联网阅读；来源链接联网可打开。配套 Markdown 是可编辑原稿，便于继续评审和转入团队文档。