那天我先收到一个很具体的反馈：有几个关键词大字太靠近画面顶部，文字没有完整落在安全区域里。最先被指出的是“书架”，后来又提到另一类片子里也有类似问题。乍看，这像是找出几个字、往下拖一点就能解决的小问题。
但我没有马上打开编辑器。因为如果一个字在画面上沿被切掉，只修眼前这一个，很可能只是把已经看见的症状擦掉，下一条片子还会继续出现同样的错误。字幕越界表面上是排版问题，真正要查的是它为什么会被自动放到这个位置。
先确认这不是普通字幕
我先回到本地草稿的结构里看“书架”对应的对象。它并不是普通对白字幕，而是自动剪辑加上的关键词大字。两者在草稿里的形态不同：关键词通常只有 1-2 个字，透明度略低，带阴影但没有普通字幕那样的描边，字号也明显更大；对白则往往是一整句，不透明，有自己的字幕样式。
这个区别很重要。普通对白如果被顶到边缘，可能要检查字幕模板、行高和对白区域；关键词大字则有独立的类型和分类标记。只要认出这个对象，就可以直接读取草稿，把它从其他文字里挑出来，不必先打开编辑器逐条寻找。
我一开始以为问题就是“书架”这个词。后来发现，词本身不是根因。自动规则会根据字数把关键词放大到接近画面宽度，字越少，视觉上越大；同时它的中心点固定在画面上方约 15% 的位置。两个字一旦被放得很大，上半部分自然会越过画面边界。
如果不处理，后果也不只是某一帧不好看。文字一旦被裁掉，观众看到的可能是半个词；批量视频继续使用同一套草稿逻辑，问题还会随新片复制。到最后，人工只能靠逐帧发现，修过的片子也很难证明没有漏掉其他同类对象。
不按词搜，而按结构找
因此，我把检查对象从“某几个已知词”改成“所有符合关键词大字特征的对象”。具体判断不依赖文字内容，而是看它在草稿中的独立类型、分类标记、自动铺满画面的设置和位置参数。这样，即使下一条片子里出现的是别的词，也能进入同一套检查。
这一步让我重新意识到，自动化检查最先要稳定的不是结果，而是对象边界。如果连“我要检查什么”都靠几个例子来猜，后面计算得再精确也没有意义。只搜“书架”或“书评”之类的已知案例，是最容易误判的错误捷径：它看起来快，实际上把未知的问题直接排除在外。
识别之后，我没有立刻写入草稿，而是先做只读扫描。扫描结果要回答几个问题：是哪一个草稿、哪一段时间出现、文字的边界在哪里、越过的是哪条安全线、超出了多少，以及它属于横屏还是竖屏。先把这些内容变成修复计划，才能知道批量修改的范围，也才能在修改后复核同一批对象。
横屏和竖屏不能共用一把尺
安全区不是一个固定的“离顶部多少像素”。横屏和竖屏的画面比例不同，平台上的按钮和遮挡区域也不同，所以我分别计算边界。横屏按四边各留出约 5% 的区域；竖屏上方约留 10%、下方约留 15%，左右仍按约 5% 处理。
这不是为了把所有文字都强行挤进同一个框，而是给不同画面方向一个可解释的判断标准。横屏里一个看似只差几像素的顶部问题，换到竖屏可能会落在平台界面会遮挡的位置。反过来，如果把竖屏规则机械套到横屏，也可能把原本合理的设计改得过于保守。
第一次对一集横屏草稿扫描时，结果不是用户最初提到的几个“书架”，而是发现了 5 处顶部越界：包括两个“书架”，还包括“时间作品”“周报”和“第一格”。全量扫描 153 个草稿后，又发现 109 个存在同类问题，总共 405 处。这个数字改变了我的判断：它不是一条片子的偶发排版，而是同一个自动规则在许多草稿里的重复结果。
竖屏也不能用“看起来还在画面里”作为唯一标准。扫描时要按竖屏的安全区重新计算，并区分关键词大字与标题、字幕模板、花字等其他对象。后面有些文字只是略微越过我设定的安全线，却没有真正出画；如果不区分类别和程度，批量修复就可能把已经排好的版面一并打乱。
先备份，再让修改可回退
只读结果确认以后，我才进入修改阶段。每份草稿先备份，再写入调整；修改完成后立即重新扫描，而不是等导出之后才想起检查。横屏那一集的 5 处越界，第一次复扫降到了 0 处，这说明草稿层面的几何计算已经达到了预期。
我选择“备份—修改—复扫”的顺序，是因为草稿是后续导出的源头。一旦批量写错，人工很难凭记忆恢复每一处原值；如果编辑器又在同时打开草稿，还可能把某个版本覆盖掉。保留备份并把写入做成一次完整操作，至少让错误可以回退，也让每次修复有清晰的前后对照。
这里还有一个边界：如果草稿受到保护，或者某个对象被其他地方引用，就不能为了追求扫描结果为 0 而硬改。安全检查的目标是减少发布风险，不是绕过保护规则。对不能修改的对象，应该记录原因，让它进入人工判断，而不是伪装成已经修好。
数值看起来对，导出仍可能错
草稿层面的复扫通过以后，我原本以为把大字缩小就完成了。实际导出却给了一个反直觉的结果：某个缩放字段调小之后，成片里的字反而变大，第一次导出甚至整屏越界。
这说明字段名称和人的直觉并不等价。这个自动铺满画面的模式里，缩放值实际参与的是一种除法关系，数值变小，结果反而更大。继续盯着草稿里的数值，很容易把“参数已经变小”误认为“画面应该变小”。真正的验收对象不是字段，而是导出画面。
我没有继续猜，而是做了一个小样本实验：保留一个横屏样本，分别改动一个字段，导出后抽取关键词出现时的画面，比较字的实际大小和顶部边界。实验确认原来的缩放方向相反，于是换成固定尺寸的写法，同时关闭自动铺满和自动定位，再把中心位置下移到约 21%。
第二次修改后，我重新导出并抽帧检查 5 个关键词出现的时刻。最终它们都完整落在画面内，并且位于横屏上方安全线以下。之后，竖屏样本也用同样的思路验证，6 个大字都完整在上方安全区以下。这个过程让我更明确：草稿数值只能说明“准备怎么改”，导出抽帧才能说明“观众最终看到了什么”。
把一次排查变成出片前规则
这次之后，我把流程整理成 5 个连续动作。先从草稿结构识别对象，不打开编辑器也能确定关键词大字；再按横屏、竖屏分别计算安全区；然后只读扫描，输出越界对象和修复计划；接着备份后修改，修改完再次扫描；最后至少抽查一个横屏和一个竖屏成片，用实际画面确认字段方向和导出效果。
这个流程的重点不在于多写一个检查工具，而在于把判断链留下来。识别解决“查谁”，安全区解决“按什么标准查”，复扫解决“改完是否真的归零”，抽帧解决“草稿和成片是否一致”。缺掉任何一环，流程都可能在看似顺利的地方停住。
一个成熟的批量流程，不是它能一次修完 405 处，而是下一次遇到新词、新比例、新草稿时，仍然知道先看什么。真正可复用的方法，是把视觉问题先还原成结构、边界和可验证的状态，再把编辑器留给最后的确认。
下次我会怎么做
下次遇到字幕顶到画面边缘，我会先暂停“打开编辑器拖一下”的冲动。第一步是确认对象类型，看看它是否有独立的关键词大字标记；第二步是查画面方向，使用对应的横屏或竖屏安全区；第三步只读扫描全量草稿，先知道问题有多少，而不是只修用户指出的那几个词。
如果需要改，我会先留备份，再做最小范围的写入，复扫到 0 处以后才进入导出。涉及缩放、自动定位这类字段，我不会把字段名当成事实，而会用一个小样本做方向实验。只要导出的视觉结果和草稿数值出现冲突，就以抽帧看到的画面为准。
这件事让我重新意识到，很多人工逐帧试错，其实是因为前面缺少一个可计算的对象定义。表面上我是在把字幕往下挪，实际上我是在建立一条从草稿结构到最终画面的证据链。以后我更愿意把它看成一种工作习惯：先读源数据，再定边界，最后让真实成片说话。