案例：序号错乱字幕的自动规范化

在视频制作流程中，最经常发生的动作就是：反复删改。 当一部电影的素材因为审核被剪掉了随后的两分钟，字幕组对应地砍掉了第 120 句 到第 150 句的台词。或者当两段短视频的独立 .srt 字幕被人为在记事本中暴力拼接合并。

这个操作带来的直接后遗症是：字幕内部的 Index (序号) 崩溃。

故障前置：逻辑破碎的序列树

一份拼凑版的 .vtt 会长成这个样子：

WEBVTT

121
00:10:04.100 --> 00:10:05.500
等等，你听见了吗？

50
00:10:06.100 --> 00:10:08.200
是谁在说话。

50
00:10:09.500 --> 00:10:11.800
这是哪里？

在这个极为糟糕却真实的案例里：

1. 逆向错乱：第一句序号是 121，第二句却突降到 50。
2. 重复占位：第二句话和第三句话由于人为粘贴的失误，撞车并占用了同一个序列编号（皆为 50）。

由于 SRT/VTT 高度依赖顺序索引在硬件层面上解析时轴树，这种乱码轻则让进度条在拉动时画面显示错乱，重则导致播放设备死机。

介入：ZiZhun R0 连击重排

如果你试图依靠 Excel 表格或者是手工输入去一个个拉正这 2000 多行的队伍，通常是个消磨了整整一天还吃力不讨好的脏活。

在 ZiZhun 引擎 内核，**R0 规则（基础语法与序列结构分析）**是所有的检测大项中最先触发的前置防线。

无论你上传的字幕文本里标写的是 121 还是莫名其妙的单词字母。ZiZhun 将完全忽视字幕作者主观留给它的乱码废标号。 系统将按照全局绝对时钟的 Start Time 为整篇时间线重新做一次冒泡排序与时序重做扫描（Chronological Reordering）。

重生后 (After)

一键点击文件导出后，刚刚那段车祸现场将像艺术品一样整洁地落向硬盘内：

WEBVTT

1
00:10:04.100 --> 00:10:05.500
等等，你听见了吗？

2
00:10:06.100 --> 00:10:08.200
是谁在说话。

3
00:10:09.500 --> 00:10:11.800
这是哪里？

一切自然递增，绝无断层。甚至你不需要为“排号”这种琐碎的杂事分心，它是在清理、去重、剥离所有特效垃圾步骤内隐性自带的全自动天赋。