OTA 升级改了射频参数，要不要备案
判断标准只有一条：升级后的状态是否还在证书覆盖范围内。动了功率、频段、充电阈值，就要停推、复测、办变更。
- 固件决定射频功率与信道配置，属于证书冻结的技术状态
- 只改界面与本地功能留版本记录，触及受限参数需复测变更
- 灰度发布不构成豁免，已推送的设备都算变更后产品
- 每版固件与校验值要存档，抽检时会比对备案版本
- 停推与回滚预案要在发布前准备好，不能出事再想
结论：改到射频、充电、基带就要停推
OTA 本身不违规，问题在于升级后的状态是否还在证书覆盖范围内。只改界面、提示音、本地存储逻辑，留版本记录即可；一旦动了发射功率、频段、信道、调制参数、充电保护阈值、蜂窝基带配置，就要先停推、复测、办变更。灰度发布不是豁免通道，推出去的每一台都算已变更产品。先判改动落在哪一层，再判能不能推，这个顺序不能反。
为什么固件也算技术状态
证书冻结的不只是硬件。射频功率、占用带宽、频率容限这些指标，最终由固件里的功率表与信道配置决定。同一块板子，固件把功率档位抬 3 dB，EIRP 和杂散就全变了。所以硬件没动不构成免测理由。
抽检怎么发现：读固件版本号与备案版本比对，测发射功率与频段占用，查 OTA 服务器的发布记录。三项一对，改没改很清楚。很多企业栽在第三步，服务器上的发布日志比设备本身更能说明问题，时间线对不上时解释成本比补测高得多。
进网许可这一侧还多一层。蜂窝终端的基带配置、频段支持、IMEI 写入逻辑都在许可范围内，OTA 改了这些，等于换了入网参数，需要通信项复测。
三档判定
| 改动内容 | 是否复测 | 申报动作 |
|---|---|---|
| 界面、提示音、本地功能、日志上报 | 否 | 版本记录备案 |
| 发射功率、信道、调制方式、天线切换逻辑 | 是，射频项 | 变更后复测，再推送 |
| 充电保护电压电流、电池管理阈值 | 是，安规与电池项 | 变更后复测 |
| 蜂窝频段、基带配置、IMEI 写入逻辑 | 是，通信项 | 变更并复测后推送 |
版本管理要留三样东西
固件包与校验值。每版发布包按型号与版本号归档，附哈希值。抽检时能证明设备里跑的是哪一版，比口头解释有用。
发布记录与推送范围。什么时候推的、推给了哪些批次、推送比例多少、有没有回滚。这份记录同时也是影响范围评估的依据，出事时能快速圈定需要处理的设备。
变更单与复测报告的对应关系。哪次变更触发了哪份报告，报告覆盖了哪些项目，要能一条线串起来。三样东西齐了，OTA 就从不可控的运维动作变成可审计的变更。改动越靠近物理层，需要复测的范围越大，这条次序可以作为研发与认证之间的共同语言。
怎么做：把 OTA 纳入变更管理
- 建变更评审。每版固件提交变更单，逐项标注是否触及受限参数，由认证与研发共同签字。
- 定版本号规则。版本号能区分硬件平台与发布批次，设备端可读，便于抽检时比对。
- 发布前验证。灰度前做小批实测，测功率、频段与充电曲线，确认与备案值一致。
- 准备停推与回滚。发布包与回滚包同时上架，明确停推触发条件与责任人。
- 留包存档。每版固件、校验值、发布记录按型号存档，保存期与证书周期匹配。
- 变更闭环。需要复测的，先完成变更再全量推送，不要用灰度替代申报。
评审表可以很简单，四列就够：改了什么、影响哪些指标、是否需要复测、谁批准。四列填不满的变更，通常说明影响没评估清楚，先退回补充再谈发布。已经量产的型号，把受限参数清单固化成一份文档，研发改代码前对照一遍，比事后追溯省事。
常见误判
- “只降功率不用报”。降功率同样改变发射状态，属于变更，只是复测项目少一些。
- “灰度不算正式发布”。设备已在用户手里，状态已改变，与发布比例无关。
- “参数写在配置文件就不算改”。判定看实际发射，不看实现方式。
- “OTA 记录不用留”。抽检时服务器日志是直接证据，缺失反而更难解释。
- “刷错固件再刷回来就行”。刷写过程可能覆盖射频校准值，功率漂移后即使回滚也未必恢复。
什么时候该找外部帮忙
两类场景适合外部介入：一是产品已量产，固件迭代频繁，需要一套可执行的变更判定规则；二是已经推送了触及受限参数的版本，需要评估影响范围并补做复测与变更。
把判定规则前置到研发流程里，比每次发布前临时讨论有效，审批链也短。蜂窝终端合规要点见工业与蜂窝终端，消费类整机见家用产品线，变更申报安排可联系工程师。