我一开始以为，既然现在可以用草稿方式处理模板，就可以直接把一句自然语言交给系统：比如“人像镂空字加九宫格 3D 出框，做成夏日涂鸦风，再配一句文案”。系统只要识别几个关键词，调用对应能力，最后拼出一个视频，事情就完成了。
但这次真正开始盘点模板以后，我发现困难不在于能不能识别“镂空字”或“九宫格”。困难在于，识别出来以后，系统并不知道这两个东西能不能放在一起、各自需要什么素材、应该占多长时间、哪些参数可以替换，以及怎样判断生成的草稿没有悄悄失真。
这件事让我重新意识到，自由语言不是视频生产的中间结果，而是需求的入口。入口后面必须有一层稳定的结构，把人的表达翻译成机器可以查询、组合和验收的计划。否则，所谓自然语言驱动，很容易退化成模型凭印象安排一串操作。
先承认模板不是成片
当时的模板来源并不只有一种。有现成的剪映模板，也有本地编译出来的镂空字和九宫格 3D 效果，还有风格、字体、滤镜、特效等可以复用的能力。它们的保存方式、参数形式和草稿结构并不完全一致。有些能力能被看成一个完整段落，有些只是某个素材槽位或一组图层关系。
如果把这些东西都叫“模板”，后续就会产生一个很大的误会：好像每个模板天然就是一段可以直接拼接的视频。实际上，模板更像能力的载体，它提供一种画面组织方式，却不应该替用户决定最终时长。一个短模板可以被重复使用，也可以和别的模板混合，最后组成 1 分钟、10 分钟，甚至更长的内容。
模板提供的是可复用的表达能力，不是对最终成片时长的承诺。
这个区分很重要。若不先把模板和成片分开，系统就会把“模板长度”当成“用户要的长度”。当用户提出做一组 1 分钟的九宫格 3D 出框，或者做一组 1 分钟的夏日涂鸦风时，系统可能只能机械地重复一段；当目标变成 10 分钟，它又会被迫临时发明一套拼接规则。结果不是内容自然变长，而是同一段画面被拉长，或者不同风格被无解释地混在一起。
表面问题是解析，真正问题是缺少中间层
自然语言需求通常把好几种判断揉在了一句话里。“人像镂空字”说的是视觉能力，“九宫格 3D 出框”说的是另一种画面结构，“夏日涂鸦风”更接近风格约束，“配一句文案”则涉及文字内容和素材槽位。这些词的粒度不一样，却经常同时出现。
最容易误判的是，把这句话直接翻译成一串界面动作，或者直接让模型生成一份草稿数据。这样看起来很快，但模型必须在一次输出里同时猜模板名称、参数、组合顺序、素材关系和时间安排。任何一个猜错，都可能生成“能打开但不对”的草稿：画面缺素材，字体不匹配，效果互相覆盖，或者整体时长和需求不一致。
真正需要结构化的不是一句话本身，而是这句话背后的能力、约束和验收条件。
所以我没有选择先做“自然语言到成片”的大闭环。我选择先做一个可查询的中间层，是因为它能把不确定性拆开。语言解析错了，可以单独检查解析结果；组合关系不成立，可以在排镜前拒绝；时间线算错了，可以用纯函数测试；草稿落地失败，也能定位是编译还是素材问题。每一层都能独立验收，系统才有机会逐步变可靠。
先给能力命名，再谈自由组合
第一步不是设计一句漂亮的提示词，而是建立命名单元表。每个单元需要有稳定名称、能力类型、输入素材、可调参数、典型时长、画幅要求和输出形式。比如，人像镂空字可以是一个带人物抠图和文字槽位的视觉单元；九宫格 3D 出框可以是一个带多图片槽位、景深关系和出框参数的视觉单元；某种风格则不必假装成独立模板，也可以表达成调色、字体、贴纸和转场的组合约束。
命名不是为了让表格好看，而是为了让后面的查询有依据。用户说“做一组夏日涂鸦风”，系统不能只凭词面找一个标题相似的模板，而应该先查风格池，再查满足画幅和素材要求的单元。用户说“九宫格 3D 出框”，系统也应该知道它需要几张素材、是否允许重复，以及它能否和文字单元叠加。
在命名单元之外，还要有命名组合表。它描述哪些单元可以前后串接，哪些只能作为同一段里的叠加层，哪些需要统一画幅、调色或音乐。镂空字和九宫格 3D 既可以前后排列，也可能在同一段中发生遮挡；如果没有组合关系，系统只能把“都找到”误认为“能组合”。
特效底座表解决的是另一类问题。字体、滤镜、贴纸、转场、音乐节拍等能力，不一定应该各自变成一个完整模板，但需要有统一的参数和适用范围。这样，风格可以附着到一组单元上，文案可以落到明确的文字槽位，特效也可以按约束进入计划，而不是在最后一步临时补缀。
从语言意图到排镜计划
有了这些基础，完整链路可以拆成几层。第一层把自然语言提取成意图：主题、风格、效果、文案、目标时长、节拍和素材偏好。第二层把意图映射到能力单元，给每个单元补齐输入和参数。第三层检查组合约束，确认这些单元能不能共同出现。第四层根据目标时长和节拍生成排镜表，决定每段出现几次、持续多久、何时换素材。最后才把排镜表交给草稿操作层，去生成或修改草稿。
这里的关键是，时间线规划必须是一个相对独立的纯函数：输入目标时长、节拍和单元池，输出排镜表。它不应该一边计算时长，一边打开工作台或修改草稿。因为只有把时间规划从具体操作中拿出来，才能测试“60 秒需要几段”“余数如何处理”“重复同一模板时如何换素材”等问题。
成组至少有两种方式。一种是同一模板重复多次，每次替换素材和文案；另一种是同风格的不同模板组合，也可以把两者混合。重复适合能力稳定、素材差异足够大的场景，组合适合需要节奏和变化的内容。对于 1 分钟成片，系统可以根据单元的典型时长计算需要的段数，再处理余数；余数可以通过裁剪、轻微变速、结尾停帧或调整某一段解决，但不能让系统无声无息地改变用户的目标。
目标时长应该约束排镜计划，而不是被某个模板的默认时长反过来支配。
音乐和节拍也应该进入计划，而不是等草稿已经拼完才补。若整组内容使用同一首音乐，切段点需要服从节拍；若每段使用各自音乐，就要明确段落之间的过渡。素材去重、文案去重、顺序变化和转场变化同样属于计划层的约束。否则，系统虽然完成了“重复 N 次”，观众看到的却只是同一个画面的机械复制。
为什么不能跳过验收层
这套中间层看起来比直接生成草稿多了几步，但每一步都在减少一种具体风险。模板结构没有读清，可能出现参数名看似相同、实际含义不同的问题；本地模板来源没有纳入，可能重复创建已经存在的能力；缓存短标识或内容指纹没有命中，可能让同一个模板在系统里出现多个版本；素材槽位没有校验，草稿可能打开了，却无法正常渲染。
当时还特别强调了本地模板库来源、缓存短标识和内容指纹命中要进入构建流程。这不是实现细节，而是身份问题。一个能力如果每次构建都被当成新东西，组合表会逐渐失去稳定性，测试也无法判断这次使用的到底是不是之前验证过的单元。
错误捷径是先做一个“万能解析器”，让它看到自然语言就直接寻找最像的模板，再把结果交给草稿生成。这个方案在演示时可能很有冲击力，却无法说明失败发生在哪里。如果不处理，后果是每次需求都可能得到一份不同结构的草稿，问题只能靠重新生成或人工打开工作台排查，最后自然语言带来的便利反而被返工抵消。
我更愿意先保守地限制能力：单元必须可命名、可查询，组合必须有规则，时间线必须能测试，草稿生成必须有结构校验。语言解析可以一开始只支持少量明确字段，不能识别的内容就保留为待确认信息，而不是假装已经理解。一个流程成熟的标志，不是它能在一次演示里什么都答应，而是它知道哪些地方不能猜。
这套方法真正留下了什么
把自由语言接到视频生产上，最终留下的不是一条更长的提示词，也不是一串自动点击记录，而是一份可追踪的单元计划。它应该能回答：用了哪些能力，为什么这样组合；每个单元需要什么素材，哪些参数被替换；总时长怎样凑出来，节拍如何落点；草稿生成后要检查什么，失败时回到哪一层处理。
这件事让我重新意识到，工具真正改变的不是速度，而是能不能把判断过程留下来。一次组合成功也许只是巧合；当能力、关系、计划和验收都被保存下来，下一次面对另一种风格、另一组素材或更长的目标时，系统才不必重新从猜测开始。
我更愿意把它看成一种工作习惯，而不是一个技巧：先把模糊表达拆成可验证的对象，再把对象放进有边界的组合，最后才让自动化去执行。自由语言可以保留人的意图，但不能替代结构。越想让系统听懂人话，越要先让系统拥有一套不容易误解的中间语言。
下次我会怎么做
下次遇到“某种风格加某种效果和文案”的需求，我会先问自己这句话能否落成一份单元计划，而不是急着让模型生成成片。第一步，查已有能力和来源，确认是否已经有可复用单元；第二步，补齐单元的输入、参数、时长和组合约束；第三步，把目标时长、节拍、素材池和去重规则交给时间线规划；第四步，经过结构校验后，才进入草稿操作。
如果需求包含多个效果，我会先区分它们是叠加关系、串接关系，还是同一风格下的候选池。如果需求包含长视频，我会先决定是重复、混合还是两者并用，再计算段数和余数处理方式。如果语言中出现暂时没有对应单元的表达，我会记录缺口，不让系统用一个相似名称蒙混过去。
下一次真正值得自动化的，不是把一句话直接变成一份草稿，而是让每个判断都有一个能被查询、组合和验收的位置。
这样做可能不会让第一个原型看起来最神奇，却能让它在第二次、第三次使用时更可靠。先建立中间层，之后再逐步扩大语言解析的覆盖范围；先把结构守住，视频的自由度才不会变成不可追踪的随机性。