这次检查一份视频草稿时，我先看到的不是画面问题，而是字幕问题：有的句子太长，已经接近甚至超过字幕边界；有的句子还带着标点。它们并不是完全没有写进草稿，反而是被完整写进去了。正因为如此，画面看起来像是“生成成功”，细看却会发现字幕阅读困难，后面还得逐条返工。
我当时首先问的是一个责任边界问题：这些规则究竟应该由剪辑软件负责，还是由组合草稿的程序负责？如果把不合规字幕原样写进去，再寄希望于剪辑软件或人工打开以后修正，问题就已经进入了最难追溯的阶段。字幕是否合规，应该在它进入视频草稿之前就被判断，而不是等渲染完成后再补救。
先分清谁拥有修改时机
上游程序负责提供字幕，剪辑软件负责按照草稿里的数据渲染画面，中间还有一层负责把素材和字幕组合成草稿。真正适合做规范化的，是这层仍然掌握原始文本、时间区间和样式信息的组稿环节。
剪辑软件通常只会渲染写入的数据，并没有一个会替调用方检查“这一行是不是太长”“这里有没有标点”的钩子。把数据写进去以后再改，往往意味着重新打开草稿、定位字幕、调整时间和样式。即使最终修好了，也很难知道它为什么曾经不合规，下一份草稿还会不会再犯。
如果不在组稿前处理，后面会出现两个后果：一是坏字幕已经成为草稿的一部分，修复成本随草稿复杂度一起上升；二是责任边界变模糊，上游以为自己只需提供文字，剪辑软件又不会承担内容判断，最后只能靠某个人打开成片后肉眼发现问题。
我选择把约束放在组稿层，是因为那里既能看到上游输出，也能在写入前拒绝错误输入。这不是要求上游永远输出完美字幕，而是把“接收外部输出后做规范化”明确成我们自己的职责。上游给什么先收下，是否允许进入草稿由组稿正门决定。
先切分，再清洗，再分配时间
规则确定以后，真正难的是处理顺序。字幕里的标点并不是多余字符，它通常还携带着天然的断句线索。如果一开始就把标点全部删除，后面再面对一整条长句，就只能凭字数硬切，很容易把语义拆开。
因此，我把流程排成了 4 步。第一步按标点切割，让逗号、句号等成为优先断点；第二步去除标点，让最终写入的字幕保持干净；第三步按照每个新片段的字数比例，重新分配原字幕的时间区间；最后再过一遍严格的合规检查，不通过就停止写入。
这个顺序不是形式上的偏好。先切割，保留的是语义；按比例分配时间，保留的是语音与字幕的对应关系；最后拦截，保留的是交付边界。任何一步省略，都会把问题推给下一步：只去标点会丢断句依据，只按固定时长拆会让字幕和声音错位，只靠人工检查又无法稳定复用。
这次处理时，没有从 0 到 1 另造一个字幕处理器，而是复用了已有的拆条工具。它本来就支持按分隔符拆分、保留原时间范围并完成写后回读。调整的地方也很小：除了能拆成多条的长句，只有末尾标点的短句也要进入同一套清洗流程。这样既解决了尾部标点，又避免复制一套容易分叉的逻辑。
字数上限不是唯一的规则
当时把每条字幕的上限定为 14 个汉字，是因为外部传入的字幕长度并不统一，有些是 9 个字，有些是 12 个字，有些已经接近 14 个字。只要不超过屏幕可承受的范围，没有必要为了追求某个更短的固定长度再做一次无意义的切割。
但“最多 14 个字”只是一个容易理解的入口，不是完整的显示约束。字号、水平缩放、字距、字幕位置和画幅都会影响最终画面。如果只数汉字，不检查这些变量，仍然可能出现字叠字，或者字幕虽然没有超过字数上限，却因为位置偏移而出屏。
所以后续规则采用了两层判断。第一层是文本约束：每条字幕不能超过 14 个汉字，不能含有禁止的标点。第二层是几何约束：根据字符数量、字号和缩放计算宽度占比，再把横向位置纳入边界判断；纵向则同时考虑字号、画布宽高比和垂直位置。负字距直接拒绝，避免字符彼此覆盖；同一轨道的时间区间重叠也拒绝，避免两条字幕在同一位置同时出现。
这里最容易误判的错误捷径，是把“14 个字”当成一个放之四海而皆准的安全结论。它在当前标定和余量内是有效上限，却不能替代对字号、位置和画幅的检查。能用数学表达的显示边界，就不应该只靠经验提醒；算出来超界，就必须让草稿创建失败。
样式要继承，规则要集中
字幕被拆成多条以后，还有一个实际问题：字体、字号、位置和样式会不会丢？如果新字幕只是重新创建文本，很容易出现内容合规了，视觉却和原草稿不一致。
这次的处理方式是从原字幕克隆，再替换文本和时间区间。这样新字幕能够继承原来的字体、字号、位置和其他样式，规范化只改变确实需要改变的部分。这个选择也减少了另一个风险：把“字幕内容处理”和“模板视觉设计”混成一件事，最后为了修文字顺手改坏画面。
我判断样式应该继续由模板和原字幕负责，是因为组稿层的任务是把外部输入变成符合既定契约的数据，而不是在每次拆条时重新设计字幕。好的规范化不是把所有东西重做一遍，而是只改越过边界的部分，同时保留原本已经正确的结构。
规则本身则不能只写在说明文档里。其他程序可能不会完整阅读说明，或者调用者换了一个入口以后根本不知道还有这些限制。因此字幕策略需要有一份机器可读的唯一来源，里面写清轨道范围、标点规则、字数上限、布局公式、豁免条件和补救方向。组稿程序读它，验收程序也读它，避免两个地方各自维护一套看似相同、实际逐渐漂移的判断。
两道门把错误挡在不同位置
机器可读策略解决了“规则在哪里”，但还不够。规则要真正可靠，还需要在创建前和创建后各有一道门。
第一道是组稿正门。其他程序准备创建草稿时，先对字幕文本和布局参数做预检。只要发现标点、超长、负字距、位置越界或时间重叠，就直接报错，草稿不创建。错误信息还要说明是哪一条字幕、违反了哪条规则，以及应该走什么补救流程。这样，调用者不需要先读完整套背景，也能从失败信息知道下一步。
第二道是成稿验收。它面对的是已经存在的草稿，负责检查文本、字数、布局和样式等结果。一次验收不应只回答“有没有字幕”，还要回答“是不是每条都合规”。这次的闭稿检查后来补齐了 4 个维度：字数、负字距、透明度和对比度，与创建预检形成对称关系。创建前防止坏数据出生，创建后确认最终数据没有在中间环节变形。
这两个门禁并不重复。前者保护创建动作，后者保护最终结果。如果只做前检，存量草稿和其他来源的草稿仍然可能无人负责；如果只做闭稿验收，错误已经进入系统，失败成本和定位成本都会更高。一个成熟的流程，不是只相信某一个环节永远正确，而是让相邻环节互相校验。
从一次修复变成可复用流程
这次实测处理了 59 条不合规字幕，原草稿从 60 条变成 96 条。处理之后，最长字幕是 14 个汉字，没有残留标点，时间仍然分布在原字幕区间内，样式也由原字幕继承。这个结果说明，拆条并不等于把字幕和语音关系打散；只要时间分配有依据，规范化可以在不改变整体表达的前提下完成。
更重要的是，后来把规则同时落到了机器可读策略、组稿红灯和可发现的秒级验收命令上。验收不再依赖某个人记得“应该查什么”，其他程序也不必把所有细节重新实现一遍。它们只要经过正门，或者调用统一验收入口，就能得到明确结果。
这套方法可以迁移到很多外部输入场景：先把上游数据视为待规范化输入，找到现有变换器，保留已经正确的结构；再把文本约束、几何约束和样式约束写成机器可读策略；最后让创建预检和闭稿验收共享同一套判定。缺少任意一层，规则就可能停留在“大家都知道”，却没有真正变成流程。
这件事让我重新意识到，自动化的价值不只是替人完成动作，还在于把边界提前写出来。工具只会忠实执行输入，不会替我们承担“这条字幕不能这样出现”的判断。真正难的不是把字幕写进草稿，而是让错误在最便宜、最容易解释的位置停止。
下次我会怎么做
下次接入任何外部字幕，我会先确认 3 件事：规则是否已经有机器可读来源，组稿前是否有明确红灯，成稿后是否有秒级验收。没有这 3 项，我不会把“写入成功”当作“字幕完成”。
处理顺序仍然固定为先按标点切割，再去标点，按字数比例分配时间，最后 fail-closed 拦截。文本不超过 14 个汉字只是基础线，字号、缩放、字距、位置、画幅和时间重叠也要一起进入检查。能从原字幕继承的样式就不重建，能复用的拆条工具就不另造一套。
如果某个上游程序输出了不合规字幕，我会把它当作待规范化输入，而不是把责任推回上游或交给剪辑软件。下次真正要复用的，不是某个草稿的修复动作，而是“策略统一、创建前拦截、创建后验收”的双门禁方法。