简介：MIPI M-PHY Specification v5.0 配套 PDF 面向移动端高速串行接口设计、验证与测试工程师，聚焦低引脚数、高带宽与优秀能效的物理层规范学习。压缩包仅含 1 个 PDF 文件，大小约 2.81MB，内容为 2022 年发布的 Errata 01 修订版，涵盖高速事务实现约束、4.11.1 节 RX_EYEMON 启停条件、参数定义澄清及勘误条目说明，便于对照正文定位修订位置。已有 953 人学习下载，适合需要核对最新规范、排查兼容性问题或完善测试用例的读者查阅。文档保留原始章节编号与 PDF 页码对应关系，可帮助快速追溯技术条款、理解实现影响，并降低旧版规范误用风险。
1. 一份 11 条勘误的份量：M-PHY v5.0 里真正被改的是什么
一份上千页的高速串行规范，正文标注日期 2021 年 6 月，一年后跟出来一份六页纸的勘误，一共 11 条。多数人的直觉是：正文才是主体，勘误是补丁。可真正决定一颗 M-PHY 接收机能不能被第三方测试台判合格的，恰恰是这 11 条里的大半。更反直觉的是，11 条中有 9 条明确写着「对设计无技术影响，仅用于测试」，唯一一条标注「可能影响既有设计」的，改动只是在原文里插入了一句十几词的从句。这说明 M-PHY 高速串行接口的演进已经走到语义收敛阶段：带宽不是靠改电气门限堆出来的，而是靠把早就存在的可选功能，用更精确的措辞限定清楚。搞懂这 11 条为什么这么改，比背下任何一组电压参数都值。
2. Errata 的效力：为什么「修正后的规范」才算规范
2.1 11 条修正的三类切面
先把这 11 条摊开看。它们看起来零散，实际只落在三个切面上：设计约束、测试定义、排印错误。
| 条目 | 位置 | 性质 | 技术影响 |
|---|---|---|---|
| 1 | 4.11 高速事务 | 技术 | 可能影响既有设计 |
| 2 | 4.11.1 RX_EYEMON_Start | 技术 | 仅测试 |
| 3 | 5.1.2.9 TX 眼图参数 | 编辑 | 仅测试 |
| 4 | 5.1.2.9 图 33 拆图 | 编辑 | 仅测试 |
| 5 | 表 19 fSJ0_RX | 编辑 | 无 |
| 6 | 表 19 fSJ2_RX 增 20 MHz | 技术 | 仅测试 |
| 7 | 表 19 fSJ2_RX 描述 | 技术 | 仅测试 |
| 8 | 表 19 fSJ4_RX 增 500 MHz | 技术 | 仅测试 |
| 9 | 表 19 fSJ4_RX 描述 | 技术 | 仅测试 |
| 10 | 5.2.2.3 RX 眼图参数 | 编辑 | 仅测试 |
| 11 | 5.2.2.3 图 44 拆图 | 编辑 | 仅测试 |
真正会改变硅片行为的只有第 1 条。其余十条，一条是把测试状态机的行为写死，四条是把眼图模板从「一张图」拆成「两张图」并把文字定义重写一遍，五条是在抖动容限表里加频率子行和补描述。
值得单独拎出来的是第 2 条和第 6、7、8、9 条这两组。前一组把原本含混的一段话整段替换，明确了一个测试信号的三条终止条件；后一组不是修错，而是给 HS-G5 补上它本该有的抖动频率点。这两组都标「仅测试」，但「仅测试」不代表不重要——测试定义错了，你的芯片在实验室里就是「功能正常但过不了线」的玄学状态，排查成本比设计错误还高，因为你连怀疑的方向都找不到。
还有一条容易被忽略的坑：第 5 条说 fSJ0_RX 那一行的标称值「10」要改掉，改成什么？原文后面跟的是一张图。纯文本抽取出来的勘误里，这个新值直接消失了。也就是说，靠文本版录入参数的人，会在这条上无声无息地留下一个错值。这是文档形式的坑，不是技术的坑，但它每年都能放倒一批人。
2.2 标记副本：为什么版本溯源要靠「一份文件」而不是「两份文件」
勘误开头的注意事项里有一句很重的话：建议考虑丢弃任何未带本次修正标记的旧版规范副本。不是「建议参考勘误」，而是「建议把没标记的旧副本扔掉」。
这个措辞背后是一个很现实的问题。芯片从 IP 设计到流片到量产，周期常常跨越两三年；规范在这个过程中会发勘误、发新版。如果勘误是独立成册的，团队里就会同时存在「规范 v5.0」和「v5.0 + Errata 01」两套文档，评审时甲拿着旧的那份说这条没写，乙拿着新的说写了，谁也无法一锤定音。所以标准组织的做法不是维护版本分支，而是让勘误直接把修改标记烧进正文页边，让「规范 + 勘误」变成一份物理上唯一的文件。
更关键的是那句法律意义上的声明：经过勘误修改后的这份规范，按组织章程的定义，仍然构成一份规范。这句话解决的是「以谁为准」的问题——不是「勘误优先于正文」，而是「标记副本本身就是正文」，两者不是两个东西。任何试图把勘误当成可选建议、只在出问题时才翻一翻的做法，在签核环节都是站不住的。
常见的做法是给基线文件加校验和并在目录层面隔离旧版，而不是靠人的记忆去分辨哪份 PDF 是新的：
#!/usr/bin/env bash # 锁定规范基线：只保留带勘误标记的副本，并记录校验和 set -euo pipefail SPEC_DIR="./spec_baseline" BASE="mphy_v5_0_errata01_marked.pdf" # 1. 记录基线指纹，写进评审材料的元数据 sha256sum "$SPEC_DIR/$BASE" | tee "$SPEC_DIR/baseline.sha256" # 2. 未带勘误标记的旧副本一律移出评审目录，不做删除只做隔离 find "$SPEC_DIR" -name "mphy_v5_0*.pdf" ! -name "$BASE" \ -exec mv {} "$SPEC_DIR/archive/" \; # 3. 评审脚本先校验指纹，不匹配直接拒绝出报告 sha256sum -c "$SPEC_DIR/baseline.sha256" --status || { echo "baseline mismatch: 当前文档不是已标记的勘误版本" >&2 exit 1 }这段脚本做三件事：算指纹、隔离旧副本、在出报告前强校验。第二步用-exec mv而不是-delete，是为了留后悔药——万一发现新副本缺页，还能把旧的捞回来对照，但它在评审路径上已经不可见了。第三步的--status让sha256sum -c只返回状态码不打印噪声，适合塞进自动化流程。真正起作用的是第三步：把「用哪份文档」这件事从人的自觉变成流水线的硬门禁。
2.3 「可选功能 + 强制定义」的组合逻辑
第 1 条修正在 4.11 节「for high speed transaction」之后插入一句话，大意是：如果实现了这个特性，那么必须遵循本节的定义。
这句话的技术含量不在于它说了什么新东西，而在于它堵住了一个解释口子。原文的语气容易被读成「本节描述了一种做法」，于是有的实现者会理解成「这是推荐参考，我可以自己定义一套等效的」，只要功能上能跑通就算合规。勘误把「可选」和「随意」分开了：特性本身是可选的，你完全可以不做；但一旦做了，语义就是强制的，不能自创。
为什么这条被标成「可能影响既有设计」，而其他十条都标「无影响」？因为只有这条改变了合规判定的边界。前面那些眼图参数、抖动频率点，改错了顶多是测试结果对不上，回去改测试计划就行；而这条改错了，是一颗已经流片的芯片在互操作测试里被判不合规，那才是需要重新流片的代价。理解这个区别，就能明白为什么勘误要逐条标注技术影响等级——它其实是在告诉你，哪些条目可以放进下一个迭代，哪些必须立刻回到设计评审。
3. RX_EYEMON：为什么 Start 不能脱离 Enable 单独拉高
3.1 眼图监测单元在测试链路里的位置
RX_EYEMON 不是数据通路的一部分，它是接收机里一个用于测试的统计单元：把接收到的样本跟期望值比对，累计两个计数器——一个是已比较的样本数 RX_EYEMON_Tested_Count，一个是比对不通过的样本数 RX_EYEMON_Error_Count，再拿前者跟目标值 RX_EYEMON_Target_Test_Count 比。三个信号加两个计数器，构成一个极简的误码统计器。
正因为它在数据通路之外，勘误才敢给它标「仅测试」。但也正因为它在通路之外，它的控制时序往往是设计里最容易被随手写的地方——反正不影响功能，随手拉个寄存器位就完事了。等硅后要做眼图扫描时，才发现计数永远对不上，这时候回头翻规范，才发现勘误已经把这段行为写死了。
3.2 三条终止条件与自清路径
修正后的 4.11.1 把逻辑说得很清楚。启动侧只有一条：RX_EYEMON_Start 必须与 RX_EYEMON_Enable 在同一个 RCT 时间点上一起激活。注意是「同一时间点」，不是「Enable 先拉高、几个周期后再拉 Start」。这个约束的意义是把两个信号的相位关系钉死，避免统计窗口的起点出现不确定的偏移。
终止侧有三条，每条对应一种不同的结束语：
第一条，已测样本数达到或超过目标测试数时，接收机应当把 Start 拉低。这是正常结束，计数到点就收工。
第二条，错误计数饱和时，接收机应当把 Start 拉低。饱和的意思是计数器到顶了，再数下去也表达不了更多信息。这条的存在说明设计者预期到一种场景：链路质量差到误码率极高，如果还傻等着数满目标样本数，测试时间会被拉得极长，所以干脆用溢出做提前终止。
第三条最微妙，针对目标测试数为 0 的情况——也就是无限比较模式。此时 Start 保持高电平，只要 Enable 还是 1 就一直比；等 Enable 在 RCT 被拉低之后，Start 并不是立刻跟着掉，而是要等主状态机的 LINE-RESET 或者系统复位才清除。为什么这么设计？因为无限模式没有「数满」这个天然终点，如果让 Start 跟着 Enable 同步下降，清除时刻就依赖于两个信号的相对延迟，而这个延迟在不同实现里是不一样的。把清除动作绑到 LINE-RESET 这个明确的状态迁移事件上，就消除了这层不确定性。
3.3 用状态机语言重写 4.11.1
把文字翻译成状态机，这四条约束就一目了然了。下面这段模型只表达控制语义，不含任何具体位宽和时钟周期：
class RxEyeMon: """依据 4.11.1 修正后文本建模的 RX_EYEMON 控制逻辑""" def __init__(self, width=16): self.enable = 0 # RX_EYEMON_Enable，测试使能 self.start = 0 # RX_EYEMON_Start，比较窗口开关 self.tested = 0 # RX_EYEMON_Tested_Count，已比较样本数 self.errors = 0 # RX_EYEMON_Error_Count，比对失败数 self.target = 0 # RX_EYEMON_Target_Test_Count，0 表示不限次 self.err_sat = (1 << width) - 1 # 错误计数饱和值，由实现位宽决定 self.armed = False # 是否处于「无限比较」挂起态 def on_rct(self, enable): # 约束一：Start 与 Enable 在同一个 RCT 时间点一起激活 self.enable = enable if enable: self.start = 1 self.tested = 0 self.errors = 0 self.armed = (self.target == 0) def on_sample(self, is_error): if not (self.enable and self.start): return self.tested += 1 if is_error: self.errors = min(self.errors + 1, self.err_sat) # 终止条件一：达到目标测试数 if self.target and self.tested >= self.target: self.start = 0 # 终止条件二：错误计数饱和，提前收工 if self.errors >= self.err_sat: self.start = 0 def on_line_reset(self): # 终止条件三：无限模式下 Enable 拉低后，Start 等 LINE-RESET 才清 if self.armed and not self.enable: self.start = 0 self.armed = False几个参数值得说明。target取 0 是一票否决式的开关，它同时决定了armed标志的置位——这个标志是整个模型里唯一记住「我处于哪种模式」的状态位，也是实现里最容易漏掉的一位。err_sat由实现的计数器位宽决定，规范只要求「饱和即停」，没有规定必须是多少位，这是留给实现者的自由度。on_line_reset里判断not self.enable是必要的：如果 Enable 还是 1 就来了一次 LINE-RESET，那属于链路重建，不该顺手把测试窗口关掉。
把这段代码跟传统写法对比，差别就出来了。传统写法通常是「Enable 上升沿启动、Enable 下降沿停止」，一行代码搞定，看着很干净。它在 G1 到 G4 的常规测试里也不会出问题。但在无限比较模式下，停止时刻就变成了两个寄存器写操作的竞争，跑一百次可能九十九次都对，剩那一次让你在凌晨三点怀疑人生。勘误把这个隐性竞争显式化，代价是状态机多了一个状态位。
4. 累积眼图：为什么要先过参考封装和参考通道
4.1 TEYE、VDIF_AC 与 UIHS/2 的几何关系
眼图模板的参数看着抽象，落到几何上其实只有三样东西：水平张开多大、垂直门限多高、模板中心在哪。
修正后的 5.1.2.9 把这三样说清楚了。TEYE_HS_G3_TX 是眼图的水平张开量，VDIF_AC_HS_G3_TX 是同一位置上的差分输出电压绝对值的下限，两者共同构成一个矩形禁区——累积眼图的轨迹不许进入这个矩形。模板的中点固定在 UIHS/2，也就是一个单位间隔的正中间。这个位置选择不是随手定的：把禁区放在眼图张开最大的地方，能最有效地检出幅度塌陷；如果放在边沿附近，抖动和幅度两种劣化会混在一起，分不清是谁的锅。
更重要的是关于抖动的那句定义：总发射抖动 TJTX 是围绕差分输出信号过零点分布的均值来定义的，而不是围绕理想时钟边沿。这个区别很关键。如果用理想边沿做参考，占空比失真就会被算进抖动里，而占空比失真是确定性成分，不该跟随机抖动混为一谈。用实测过零点的均值做参考，相当于先把确定性偏移扣掉，剩下的才是真正需要靠时序裕量去吸收的部分。
4.2 TX 侧：G3 单图拆成 G3/G4-G5 两图的原因
勘误第 3 条和第 4 条做的事，是把原来的一张图拆成两张，并把文字定义整段重写。重写后的文字点明了关键差异：HS-G3 的眼图在芯片输出端定义，而 HS-G4 和 HS-G5 的累积眼图，是在参考封装和参考通道均衡器之后定义的。
这个变化不是放宽要求，恰恰相反，它让要求变得可比。高速链路的眼图在引脚处和在接收端看到的完全不是一回事：中间隔着封装寄生、PCB 走线损耗、连接器不连续性。如果所有速率等级都在引脚处定眼图模板，那 G4/G5 的模板就得把通道损耗预先折算进去，而不同产品的通道千差万别，折算系数只能拍脑袋。改成在「规定的一段参考通道 + 均衡」之后定义，等于把测量点从物理引脚搬到了一个虚拟的、所有人都一样的观测面上。这样一来，两家不同封装的发射机，只要在这个虚拟观测面上的眼图都过线，就都能跟同一颗接收机互操作。
代价是测试变复杂了：你得有参考通道模型，得做去嵌（de-embedding），得把夹具的影响从测量结果里剥掉。这也是为什么这条改动标的是「仅测试」——硅片不用改，测试台要改。
# 累积眼图 mask 检查的最小模型（TX 侧） def check_tx_eye(samples, ui, gear, table): """ samples: 已按 UI 折叠的差分采样，元素为 (phase_offset, v_diff) ui: 当前 gear 的单位间隔长度（秒） table: {gear: {"t_eye": 秒, "v_dif_ac": 伏特}} """ p = table[gear] half = p["t_eye"] / 2.0 center = ui / 2.0 # 模板中点固定在 UIHS/2 for phase, v in samples: if abs(phase - center) <= half and abs(v) < p["v_dif_ac"]: return False # 禁区内部出现轨迹，判不合格 return True这段检查逻辑的关键在center：模板中点由 UI 推出来，不是从采样数据里拟合出来的。如果反过来用实测眼图中心去对齐模板，那占空比失真就被自动补偿掉了，模板也就失去了检出能力。table按 gear 分开传，是为了强制调用方显式选择速率等级——G3 和 G5 的t_eye不能混用，混用之后算出来的裕量毫无意义。
4.3 RX 侧：均衡器后处理与 TJRX 的切分
接收侧的定义在 5.2.2.3，勘误第 10、11 条重写了它。判据是两条并列：差分输入电压的绝对值要大于 VDIF_ACC_HS_G3_RX（或 G4、G5 对应的值）这个下限，同时累积眼图要符合对应的模板。注意是「大于下限」再加「符合模板」，不是单一门限——幅度和形状分开判，因为一个幅度足够但边沿一塌糊涂的信号，和一个形状漂亮但摆幅不够的信号，失效机理完全不同。
模板位置的定义也说得更死了：TEYE_HS_G3_RX 等参数的位置在眼图正中央。跟发射侧一样，中心是算出来的，不是量出来的。而 HS-G4 和 HS-G5 的累积眼图，必须用参考封装和接收机参考均衡器做后处理。这里的均衡器是规范指定的参考模型，不是你自己芯片里那个自适应均衡器——用自家均衡器的响应去替代参考模型，测出来的裕量会系统性偏乐观，因为你的均衡器本来就是为这条链路调过的。
还有一处细节：接收侧的模板是拿 TJRX/2 参与定义的，抖动被劈成两半，一半算在左边沿，一半算在右边沿。为什么不用完整的 TJRX？因为眼图模板是从中心往两边张的，左右各承担一半抖动预算，这样水平张开量 TEYE 和总抖动 TJRX 之间就有了一条可核算的关系，而不是两个互不相干的数字。
4.4 抖动频率点：fSJ2 从 10 MHz 到 20 MHz 的物理含义
勘误第 6 到第 9 条全在动表 19，也就是接收机抖动容限的频率点。这一组最能体现「测试能力反向约束规范定义」这件事。
先看 fSJ2_RX。原来只有一个标称值 10，勘误给它加了一个 20 的子行，并在描述里写明：HS-G1 到 HS-G4 用 10 MHz，HS-G5 用 20 MHz。给出的理由是「为 HS-G5 增加一个位于 CDR 带宽之上的抖动频率」。
这句话是理解整组改动的钥匙。接收机靠时钟数据恢复电路跟踪低频抖动，所以低频抖动它吃得下；一旦抖动频率高过 CDR 环路带宽，跟踪就跟不上了，这部分抖动会直接吃掉时序裕量。因此抖动容限测试必须保证施加的抖动频率确实在 CDR 带宽之上，否则测的是「接收机能不能跟踪」，不是「接收机能不能容忍」。G5 的数据率更高，CDR 带宽随之上移，原来那个 10 MHz 有可能掉到带宽之下，于是必须补一个 20 MHz 的点。
再看 fSJ4_RX。勘误给它加了 500 MHz 的子行，理由写得很直白：受测试设备限制，且更高的抖动频率没有实际用途。描述里补上：G1 到 G4 用 1/30 UIHS，G5 及以上用 500 MHz。
这里的转折很有意思。G1 到 G4 的频率点是按 UI 归一化定义的——1/30 个 UI，速率一变频率自动跟着变，物理意义是「相对数据速率的固定比例」。到了 G5，如果继续按这个规则缩放，算出来的频率会超出信号源和夹具的能力范围，于是改成一个绝对上限。也就是说，参数定义方式从「相对量」切换成「绝对量」，触发点不是电气特性的拐点，而是仪器能力的拐点。规范在这里向工程现实让了一步，并且坦白写明了让这一步的理由。
def f_sj2_rx(gear): # G1~G4 用 10 MHz；G5 起用 20 MHz，确保测试点仍高于 CDR 环路带宽 return 10e6 if gear <= 4 else 20e6 def f_sj4_rx(gear, ui_hs): # G1~G4 按 1/30 UIHS 归一化，随速率缩放 raw = ui_hs / 30.0 # G5 起封顶 500 MHz：设备能力上限，且更高频率无实际意义 return min(raw, 500e6) if gear >= 5 else rawsj4里那个min是这组改动最凝练的表达：先按归一化规则算出理论值，再拿 500 MHz 做上限钳位。写成min而不是if raw > 500e6的分支，是因为钳位在 G5 以上的所有速率都成立，分支写法会把「G6 怎么办」这个问题重新抛出来。sj2里按 gear 分档则不能这么写——10 MHz 和 20 MHz 之间不存在连续过渡，它是两个离散的测试点，硬要插值只会造出一个谁也没定义过的频率。
5. 排查：五类把勘误读错后的翻车现场
5.1 设计与实现侧的三条
第一条，现象是眼图监测跑起来后 Tested_Count 一直是 0，Start 位写 1 也读不回来。原因通常是把 Start 当成一个独立的使能位去写，而规范要求它跟 Enable 在同一个 RCT 时间点上一起激活；两个信号分两次寄存器写下去，中间隔了几个周期，硬件按「未同时激活」的逻辑直接忽略了这次启动。解决办法是把两个位的写入合并成一次，或者在硬件里加一个同步握手，让 Start 只在 Enable 的同一拍生效。
第二条，现象是链路误码率明显偏高时，眼图测试反而很快就结束了，统计到的样本数远小于设定目标。原因是没实现错误计数饱和这条终止条件，或者实现了但饱和阈值设得比预期低很多，误码一多就提前收工，采集到的样本根本不足以评估眼图。解决办法是核对计数器位宽与饱和阈值的一致性，并在测试报告里同时输出实际停止原因，区分「达标停止」和「饱和停止」。
第三条，现象是无限比较模式下（目标测试数设为 0），Enable 拉低之后 Start 迟迟不清，下一次测试启动时被判定为状态异常。原因是实现里让 Start 跟随 Enable 同步下降，或者等了一个固定延时就想清掉；规范要求的是等主状态机 LINE-RESET 或系统复位。解决办法是把清除路径接到状态迁移事件上，而不是接到计时器上。
5.2 测试与文档侧的两条
第四条，现象是 G5 的眼图裕量测试结果和硅后实测对不上，仿真里过线，实测掉线。常见原因是抖动测试频率沿用了 G1 到 G4 的 10 MHz，而这个点在 G5 上可能已经落进 CDR 带宽之内，被测链路轻松跟踪掉了，测试通过但没测到真实风险。解决办法是按速率等级分支选频率，G5 走 20 MHz，并且把这个分支固化进测试脚本而不是写在测试计划文档里靠人记。
第五条，现象是照着文本抽取的规范录入参数，fSJ0_RX 那一格填了个错值，后面所有基于这个值的裕量计算集体偏移。原因是勘误里这条修正的新值是以图形形式嵌入的，纯文本导出时会丢掉。解决办法只有一个：参数录入必须以原始版式文件为准，抽取文本只能用来检索定位，不能用来读数。
提示：勘误条目里凡是「Correction」后面跟图的地方，都要回到原始版式文件去核对，文本化流程在这里是断的。
5.3 建立一份最小自查清单
踩坑踩多了以后，我更愿意把检查项做成可以机械执行的顺序，而不是一份需要通读的文档。下面这五步是按「先锁文档、再锁参数、最后锁测试」的顺序排的，每一步都能独立验证。
第一步，确认基线文件带勘误标记，并用校验和固化下来，评审目录里不允许出现未标记副本。这一步做不实，后面全部白搭。
第二步，把 11 条修正按性质分成三堆：改设计的、改测试的、改笔误的。改设计的那一堆（本次只有一条）必须进设计评审，改测试的那一堆进测试计划，改笔误的那一堆进参数表核对。
第三步，对每一条改测试的条目，回头确认测试脚本里对应的是硬编码还是分支逻辑。硬编码的一律改成按速率等级分支，否则下一代速率出来时必然重演同样的坑。
第四步，检查所有以图形形式给出的修正值，逐条回原件核对，核对完在参数表里标注来源条目号。
第五步，跑一次反向验证：随便挑一条修正，把它改回勘误之前的样子，看测试流程能不能自动报出异常。报不出来，说明这条修正根本没进流程，只是进了文档。
6. 设计取舍：为什么标准愿意为「可测」让步
把 11 条修正放在一起看，会看到一条清晰的主线：这份勘误几乎全部在修「怎么说」，而不是修「怎么做」。唯一动到设计约束的那一条，改的是一个从句的强制性；剩下十条全在把测试定义写得更死、把测量点挪到更公允的位置、把仪器能力不足的地方明说出来。
这背后是一个不太被讨论的取舍。规范的理想形态是只描述电气行为，不干涉你怎么测；但高速串行接口的物理层有个特点——同样的硅片，在不同的测量点上会给出完全不同的眼图。如果规范不说清测量点，那「符合规范」就变成了一句空话，因为任何人都能找到一组对自己有利的测量条件。所以规范不得不往测试侧伸手，把参考通道、参考封装、参考均衡器这些本来属于测试工程的东西写进正文。代价是规范变厚了，测试变复杂了；收益是所有人在同一个观测面上比，比较才有意义。
fSJ4_RX 封顶 500 MHz 是这种让步最赤裸的一次。按归一化规则，G5 的抖动频率点该继续往上走；但仪器跟不上，于是规范直接写了个绝对上限，还把理由写在描述栏里。这种事在纯理论视角下是妥协，在工程视角下是诚实——一个测不出来的指标，写在规范里只会制造纸面合规。我见过的反例是：某项目为了「严格符合」一个实际上没有设备能验的指标，花了两个月搭测试台，最后测出来的数据谁也不敢信，白白拖了进度。
从那以后我每次拿到一份带勘误的规范，第一件事都不是去读改了哪些参数，而是先把 11 条按「设计 / 测试 / 笔误」三堆分好，再对着测试脚本一条条确认分支逻辑。这个习惯救过我一次——一条标着「仅测试、无技术影响」的修正，恰好是我当时唯一没实现的那条，而它正好卡在认证流程的最后一环。希望帮到你。
本文还有配套的精品资源，点击获取
