在为 YouTube 或 Bilibili 等平台制作长视频时，创作者往往会使用自动语音转换（Speech-to-Text）工具提取旁白文稿，然后直接压制进视频。这种粗放的做法往往会带来一个深度的隐患：部分句子的语速极快或者单句断句太长，导致极高的 阅读负荷（Reading Load）。

什么是 CPS 与 CPL？

在影视级字幕制作中，保证观众能够舒服地接收画面的同时读完屏幕下方的文本是一套严苛的数学题。常见的度量标准为：

CPL (Characters Per Line)：单行所含字符数。中文字幕通常建议不要超过 16-20 个汉字。
CPS (Characters Per Second)：每秒钟观众需要阅读的字符数。根据 Netflix 官方针对简体/繁体中文的交付指南，最大的安全上限为 21 个字符/秒。超速则意味着观众的大量注意力会被文字所霸占。

问题再现：被遗忘的语速极限

在一个时长 30 分钟、字数破万的编程类技术教程 SRT 字幕中，作者在讲解复杂的架构逻辑时语速极快：

83
00:15:20,300 --> 00:15:21,800
在这里我们可以看到这个分布式缓存集群为了保证它的数据一致性
使用了基于Raft协议实现的高可用心跳选举机制来杜绝单点故障。

将该 .srt 文件投入 ZiZhun 进行质量控制扫描。10 毫秒后，系统的 R2 规则（阅读负荷分析模块）亮起了橙色警报：

针对上述片段，ZiZhun 的计算节点给出了具体诊断日志：

[Warning] Line 83: CPL(38) > 20, CPS(25.3) > 21.0 - Reading Load Limit Exceeded.

这句话不仅两行的总体字数超限，而且总时间仅给出了短短的 1.5 秒（00:15:21,800 - 00:15:20,300）。这意味着观众需要在 1.5 秒内读完极度密集的 38 个中文字符，这在物理上几乎是不可能的。

这种 Major 级别的缺陷通常属于“软性故障”。由于它极大影响观感但不至于导致技术栈（如播放器）崩溃，ZiZhun 并不会像处理 闪轴 (Blocker) 那样强制执行自动修复，而是精准地将这些节点的行号挑出并在面板高亮，供人工介入。

翻译或时间轴专员（QC-er）可以根据 ZiZhun 这个导航仪给出的清单，针对这些句子进行人为的“拆句”或者“精简缩写”操作：

83
00:15:20,300 --> 00:15:21,800
可以看到这个分布式缓存集群
使用了基于Raft协议的选举机制

84
00:15:21,800 --> 00:15:23,100
以此来杜绝单点故障

修改后再次拖入引擎，系统提示 All Clear：此时句子的 CPS 回落到了约 15 字/秒 的安全绿色范围内，顺利拿到了零瑕疵的出库认证。