21) LLM 规划器（Planner）：从自然语言到可执行 Patch 的“可控链路”

关键不是“让模型更聪明”，而是让它在可控轨道上输出：先定位（Locate）再规划（Plan）再校验（Validate）再执行（Execute）。

21.1 Planner 的输入

  • User Utterance：本轮用户指令
  • Project Digest：工程摘要（脚本/分镜/风格/约束）
  • Focused Snapshot：仅包含相关时间范围的对象列表
  • Policies：预算、模型白名单、品牌/安全规则
  • Tooling：可调用工具列表（locate、search、estimate…）

21.2 Planner 的输出

  • Locate Result：用户说的“那段/第二段/12 秒”映射到 scene/clip IDs
  • Patch JSON：严格 schema 的 ops 列表
  • Human Summary：给用户看的改动说明（与 patch 对齐）
  • Cost & Risk：预计 credits、耗时、可能风险（例如会重渲）

21.3 推荐的“多阶段”规划（比单次 prompt 稳很多）

Stage A: Normalize
- 把用户输入规范化成结构：{target_range?, target_scene?, change_type, constraints}

Stage B: Locate (tool + rules + LLM)
- 先用索引/规则定位候选 scene/clip，再让 LLM 选择最可能目标
- 产出：target_ids + confidence + fallback question(if needed)

Stage C: Plan
- 生成 patch（ops），每个 op 显式绑定对象 ID，不允许“模糊描述”

Stage D: Validate & Repair
- schema 校验失败 → 将错误回灌给模型让其修复（最多 N 次）
- 语义校验失败（越界/引用不存在）→ 自动重定位或请求用户澄清

Stage E: Execute
- 进入 DAG + Queue

Stage F: Summarize
- 用人话同步：改了哪里、预览何时可见、最终导出是否需要额外时间
实战建议：把 Planner 当成“编译器前端”：词法（normalize）→ 语义（locate）→ 生成 IR（patch）→ 静态检查（validate）。

22) 定位系统（Locator）：把“那段/第二点/更快一些”精确映射到工程对象

现象级体验的隐藏关键：用户永远用模糊语言说话，但系统必须精确命中对象。

22.1 三种定位信号（建议全部实现）

时间信号

  • “12 秒附近”“开头 5 秒”“结尾那段”
  • 映射：timeline range → overlap clips

语义信号

  • “第二个观点”“讲原因那段”“讲案例的地方”
  • 映射：outline/scene summaries → scene_id

文本信号

  • “把‘因此我们…’那句换掉”
  • 映射：caption/vo transcript search → segment ids

UI 选择信号（最强）

  • 用户在时间线上点选 clip/caption
  • 映射：selected_object_id（直接锁定）

22.2 Locator 工具接口（示例）

// tool: locate_targets
input:
{
  "project_id":"p_123",
  "query": "把第二个观点那段节奏加快一点",
  "hints": {"selected_ids":[], "cursor_time": 11.8}
}

output:
{
  "candidates": [
    {"type":"scene","id":"s2","range":[6.5,18.0],"score":0.86},
    {"type":"clip","id":"clip_7","range":[11.2,14.3],"score":0.63}
  ],
  "best": {"type":"scene","id":"s2"},
  "confidence": 0.86
}
定位失败怎么办：不要让模型“猜”。要么要求用户点选目标、要么给出候选让用户选 A/B（这比反复重生成要省成本且体验更稳）。

23) 风格系统（Style System）：把“好看”变成模板、约束与可复用资产

23.1 Style Token（建议结构化）

  • 主题：dark/light、品牌色、对比度
  • 字幕：字体/描边/背景条/关键词高亮规则
  • 镜头：动效强度、cut 密度、转场类型
  • 音频：BGM 类型、ducking、目标 LUFS

23.2 Style Template 的复用

  • 平台模板：Shorts/TikTok/Reels（安全区与节奏不同）
  • 行业模板：电商/教育/工具测评（字幕与结构不同）
  • 品牌模板：企业客户固定片头片尾、字体与色彩

23.3 Style Profile 示例

{
  "style_id": "style_bold_pop_v2",
  "caption": {
    "font": "Inter-Bold",
    "stroke_px": 6,
    "shadow": true,
    "highlight": {"mode":"keyword", "max_per_line":2}
  },
  "motion": {
    "kenburns_strength": 0.35,
    "transition": {"type":"whip", "duration_ms":240},
    "cut_density_per_min": 24
  },
  "audio": {
    "vo_target_lufs": -14,
    "bgm_target_lufs": -18,
    "ducking_db": -12,
    "duck_attack_ms": 80,
    "duck_release_ms": 220
  },
  "safe_area": {"top": 0.10, "bottom": 0.18}
}
工程收益：风格系统一旦结构化，LLM 的修改就变成“改 style token”，而不是让模型凭感觉改渲染参数。

24) Prompt / Tooling：把“提示词”产品化成可审计、可回放、可回归

不要把 prompt 写死在代码里。把它当成配置与版本，才能持续迭代。

24.1 Prompt 版本化（建议）

{
  "prompt_id": "planner_patch_v6",
  "purpose": "Chat → Patch",
  "schema": "PatchSchema@1.2",
  "system": "你是视频工程规划器，只输出 JSON ...",
  "fewshots": ["..."],
  "constraints": ["不得输出自然语言", "必须绑定 clip_id", "..."],
  "created_at": "2026-01-05",
  "owner": "video-platform"
}

24.2 Prompt 回放（Replay）

  • 记录：输入 context（脱敏）+ 输出 patch + validator 结果
  • 用于：回归测试、线上事故追溯、A/B 比较

24.3 Tool-first（强推荐）

  • 定位、搜索、估算都先用工具/规则做“硬事实”
  • 让 LLM 做决策与生成 patch，而不是做“计算/检索”
不要做的事：把“全工程文件”喂给模型让它重写。那会导致漂移、不可控、难以计费与回滚。

25) 内容治理与策略：把风险前置到 Planning 与导出阶段

25.1 治理放在哪两处最有效

  • Planning：在 patch 生成前，限制素材来源、模型白名单与内容类型
  • Export：在 final 导出前做最后检查（字幕/音频/版权元数据）

25.2 最小策略对象（Policy）

  • 禁止/限制的素材类型与来源
  • 敏感词与合规规则（地区/行业）
  • 企业客户的品牌词、可用字体/颜色、片头片尾

25.3 Policy 示例（概念）

{
  "policy_id": "org_brand_policy_01",
  "allowed_stock_sources": ["sourceA","sourceB"],
  "allowed_models": ["fast_video_v1","hq_video_v2"],
  "require_license_metadata": true,
  "caption_safe_area_enforced": true,
  "banned_terms": ["..."],
  "watermark": {"enabled": false}
}
工程现实：治理不是“最后加个审核按钮”。它必须渗透进“生成前、执行中、导出前”的每一步。

26) 现象级增长飞轮：工程系统如何反哺产品增长

26.1 飞轮 1：模板沉淀 → 更快成功率

  • 从用户高频需求提炼 recipe
  • recipe 让新用户“第一次就成功”
  • 成功率提升 → 留存提升 → 更多数据

26.2 飞轮 2：可回放 → 快速迭代质量

  • Patch/Job/Usage 全链路日志
  • 定位失败、字幕越界、响度不稳 → 变成可量化指标
  • 指标驱动迭代 → 质量提升 → 付费提升

26.3 飞轮 3：成本运营 → 更强定价与 SLA

  • 知道每个 recipe 的单位成本与转化率
  • 能对不同 tier 提供不同 SLA（preview 优先、final 排队）
  • 能做到“更便宜/更快/更稳”的组合，形成壁垒
现象级的工程底色：所有“体验提升”背后都有一个可量化的指标与一个可迭代的配置（recipe/style/prompt/policy）。

27) 全链路蓝图：把系统拆成可立即开工的模块清单

模块 你要实现的最小能力 第一版就要做的工程点
Project Service 工程文件 CRUD、revision、局部读取 稳定 ID、patch log、冲突检测
Planner Service Chat → Patch（JSON） schema 验证、repair、policy 注入
Locator Service 语义/时间/文本定位 索引结构、候选输出、置信度
Orchestrator DAG、队列、重试、取消 幂等、优先级、分阶段扣费
Render Service Preview/Final、Segment Cache 脏区间计算、拼接、缓存键
Asset Service 上传/检索/授权元数据 hash 去重、签名 URL、隔离
Billing/Credits 估算、预扣、结算、账本 usage_report、对账、申诉依据
Observability 日志/指标/追踪 质量门槛、告警、回归集
如果你要做技术尽调式输出：以上每个模块都可以展开成 Tech Spec（接口、数据结构、状态机、SLO、失败模式）。

附录（再续）：失败模式与防护（Failure Modes）清单

常见失败模式

  • 定位错目标 → 改错段
  • 字幕越界/被 UI 挡住
  • 音频响度不稳、削波
  • 渲染缓存失效 → 成本暴涨
  • 队列雪崩 → 所有人都慢
  • 重试重复扣费 → 争议

对应防护

  • Locator + 置信度 + 候选确认
  • Quality gate（导出前硬检测）
  • 响度标准化 + clipping 检测
  • Segment cache + 统一键策略
  • 资源池隔离 + 限流 + 优先级
  • op_id 幂等 + usage_report 账本
终极建议：把“失败模式”当成产品体验的一部分。现象级产品往往不是从不失败，而是失败时仍然可解释、可恢复、可继续迭代。