feat: 统一命名平台门禁/网络探针，明确CC码中心核心枢纽定位，补充API调用说明

docs/CC码监管方案-业务版.md

@@ -9,24 +9,26 @@
 
 CC码（广电内容编码）是广电总局推出的**强制性视频内容标识制度**，要求全网所有视频内容——包括影视剧、综艺、新闻、短视频、UGC用户创作——上线前必须取得CC码，所有视频平台必须接入CC码验证体系，**无码不得上线**。
 
-本方案采用**"双层架构"**实现CC码的全网监管：
+本方案以**CC码中心**为核心枢纽，由其统一运行两套系统，实现CC码的全网监管：
 
 | 防线 | 机制 | 响应速度 | 覆盖范围 |
 |------|------|---------|---------|
-| **第一层：平台侧预防** | 在上传、播出、CDN、终端四个环节嵌入CC码验证，无码拦截、违规秒级下架 | **秒级** | 所有对接平台 |
-| **第二层：独立监控兜底** | 爬虫巡查+水印提取+指纹比对+AI语义识别，不依赖平台配合 | **分钟级** | 全网（含未对接平台、境外平台） |
+| **平台门禁** | CC码中心提供监管API，各平台调用API在上传、播出、CDN、终端四个环节验证CC码，无码拦截、违规秒级下架 | **秒级** | 所有对接平台 |
+| **网络探针** | CC码中心直接运行的独立巡查系统，爬虫巡查+水印提取+指纹比对+AI语义识别，不依赖平台配合 | **分钟级** | 全网（含未对接平台、境外平台） |
+
+> **平台门禁**是CC码中心提供给平台使用的API能力，**网络探针**是CC码中心自己运行的巡查系统。两者都由CC码中心统一管理，数据互通、协同处置。
 
 **关键设计要点**：
 
 - **UGC专项**：平台代理赋码（码段授权+实时赋码），分级检测（快速筛查→重点检测→深度检测），合理使用与二创界定
 - **直播专项**：频道/主播级赋码，播出中实时校验，分钟切片检测+秒级断流
-- **存量处置**：12个月过渡期，分批补码（头部3个月→一般6个月→全量12个月），过渡期内第二层重点巡查
+- **存量处置**：12个月过渡期，分批补码（头部3个月→一般6个月→全量12个月），过渡期内网络探针重点巡查
 - **误判申诉**：48小时申诉+24小时审核，分级处置+人工兜底+白名单+秒级恢复
 - **水印嵌入**：CC码+平台代码+时间戳嵌入视频像素，不可见、抗压缩、抗裁剪，是全链路追溯的技术基础
 - **CC码生命周期**：申请→审核→有效→暂停→恢复/下架→过期，全程状态管理，变更可追溯
 - **组织保障**：5个团队约30~44人，7×24小时告警处理，平台考核与牌照续期挂钩
 
-**实施路线**：5个阶段，18个月完成全量上线——3个月持证平台秒级拦截，6个月UGC赋码+独立监控，9个月存量补码+直播监管，12个月全量运行，18个月运营优化。
+**实施路线**：5个阶段，18个月完成全量上线——3个月持证平台秒级拦截，6个月UGC赋码+网络探针，9个月存量补码+直播监管，12个月全量运行，18个月运营优化。
 
 **核心价值**：从"人工巡查、天级发现、小时级下架"升级为"自动检测、秒级拦截、秒级全网下架"，实现全网全量视频内容的实时监管闭环。
 
@@ -72,23 +74,36 @@ CC码（广电内容编码）是广电总局和相关部门推出的**强制性
 
 | 比喻 | 对应方案 | 作用 |
 |------|---------|------|
-| 门口安检 | 第一层：平台侧预防 | 在内容上传/播出时查验CC码，无码不让进 |
-| 商场巡检 | 第二层：独立监控 | 安检被绕过时，巡检员在全网巡查发现违规 |
+| 门口安检 | 平台门禁 | 在内容上传/播出时查验CC码，无码不让进 |
+| 商场巡检 | 网络探针 | 安检被绕过时，巡检员在全网巡查发现违规 |
 
 ### 为什么需要两道防线
 
-- **只有第一层**：平台如果不配合（不装安检门），就完全失控
-- **只有第二层**：发现违规后还要等平台配合才能下架，时延不可控
+- **只有平台门禁**：平台如果不配合（不装安检门），就完全失控
+- **只有网络探针**：发现违规后还要等平台配合才能下架，时延不可控
 - **两层并行**：配合的平台秒级拦截，不配合的平台也能分钟级发现并处置
 
-> CC码作为强制要求，所有平台必须接入第一层。但行政强制不能保证100%执行到位，第二层独立监控作为技术兜底，确保"制度管得到的秒级管，制度暂时管不到的分钟级管"。
+> CC码作为强制要求，所有平台必须接入平台门禁。但行政强制不能保证100%执行到位，网络探针作为技术兜底，确保"制度管得到的秒级管，制度暂时管不到的分钟级管"。
 
 ---
 
-## 三、第一层：平台侧预防（秒级）
+## 三、平台门禁（秒级）
 
 ### 3.1 工作方式
 
+平台门禁的核心是：**各视频平台调用CC码中心提供的监管API**，在业务流程中实时验证CC码的合法性和状态。平台不需要自建验证系统，只需对接CC码中心的统一API接口：
+
+```
+视频平台                    CC码中心
+    │                          │
+    ├── 上传时 → 调用API验证CC码 ──→ 返回：合法/非法/已下架
+    ├── 播出时 → 调用API查询状态 ──→ 返回：有效/已暂停/已下架
+    ├── CDN分发时 → 调用API校验哈希 ──→ 返回：一致/被篡改
+    └── 终端播放时 → 调用API抽检 ──→ 返回：一致/异常
+```
+
+> 平台只需对接一套API，不需要理解CC码的内部逻辑。CC码中心负责所有验证判断，平台根据返回结果执行拦截或放行。
+
 在视频平台的四个关键环节嵌入CC码验证，类似"四道安检关卡"：
 
 | 关卡 | 在什么环节检查 | 检查什么 | 不通过怎么办 | 用户是否有感知 |
@@ -105,12 +120,12 @@ CC码（广电内容编码）是广电总局和相关部门推出的**强制性
 ```
 监管方下达指令："下架 CC码 第XXX号"
         │
-        │  系统自动查找该CC码关联的所有：
+        │  CC码中心自动查找该CC码关联的所有：
         │  · 哪些平台有这个内容
         │  · 哪些CDN缓存了这个内容
         │  · 哪些运营商在分发这个内容
         │
-        ▼  同时通知所有相关方（1秒内）
+        ▼  CC码中心通过API同时通知所有相关方（1秒内）
         │
    ┌────┼────────────┬────────────┬────────────┐
    ▼    ▼            ▼            ▼            ▼
@@ -119,7 +134,7 @@ CC码（广电内容编码）是广电总局和相关部门推出的**强制性
  (1秒)    (1秒)      (1秒)        (1秒)       (1秒)
 ```
 
-**关键点**：监管方只需说"下架这个CC码"，系统自动翻译成各平台、各CDN能理解的执行指令，不需要人工逐个通知。
+**关键点**：监管方只需在CC码中心后台说"下架这个CC码"，CC码中心自动翻译成各平台、各CDN能理解的执行指令，通过API下发，不需要人工逐个通知。
 
 ### 3.3 适用范围
 
@@ -131,18 +146,20 @@ CC码是强制性要求，所有视频平台必须对接：
 | 持证视频平台（爱奇艺/腾讯/优酷等） | 强制对接，行政要求 | 秒级拦截+秒级下架 |
 | 短视频平台（抖音/快手/B站等） | 强制对接，UGC批量发码（详见第五章） | 上传环节拦截+批量验证 |
 | 直播平台 | 强制对接，直播前预告赋码+播出中实时校验（详见第五章） | 播出环节秒级拦截 |
-| 中小视频平台 | 强制对接，分批过渡 | 过渡期内由第二层重点巡查 |
-| 境外平台 | 无法对接 | 依靠第二层检测+DNS封锁 |
+| 中小视频平台 | 强制对接，分批过渡 | 过渡期内由网络探针重点巡查 |
+| 境外平台 | 无法对接 | 依靠网络探针检测+DNS封锁 |
 
 ---
 
-## 四、第二层：独立监控兜底（分钟级）
+## 四、网络探针（分钟级）
 
-### 4.1 为什么需要第二层
+网络探针是**CC码中心直接运行**的独立巡查系统，不需要各平台配合接入，主动在全网范围内发现和识别违规内容。
 
-CC码虽是强制要求，但第一层仍有管不到的地方：
+### 4.1 为什么需要网络探针
 
-| 场景 | 第一层为什么管不到 | 第二层怎么管 |
+CC码虽是强制要求，但平台门禁仍有管不到的地方：
+
+| 场景 | 平台门禁为什么管不到 | 网络探针怎么管 |
 |------|-----------------|------------|
 | 平台对接有过渡期 | 中小平台分批接入，过渡期内未对接 | 系统自动巡查全网，发现违规 |
 | 平台执行不到位 | 形式上对接但实际未严格执行 | 系统独立检测，不依赖平台 |
@@ -153,7 +170,7 @@ CC码虽是强制要求，但第一层仍有管不到的地方：
 
 ### 4.2 工作方式
 
-第二层像一个**自动巡查系统**，分三步工作：
+网络探针是CC码中心运行的**自动巡查系统**，独立于各平台运行，发现违规后直接通过CC码中心处置。分三步工作：
 
 **第一步：采集（发现视频）**
 
@@ -177,6 +194,8 @@ CC码虽是强制要求，但第一层仍有管不到的地方：
 
 **第三步：处置（告警+下架）**
 
+网络探针发现违规后，直接上报CC码中心，由CC码中心通过平台门禁API下达下架指令：
+
 | 检测结果 | 处置方式 | 响应速度 |
 |---------|---------|---------|
 | 发现伪造/无码内容 | 紧急电话+短信通知监管方，要求平台立即下架 | 立即 |
@@ -185,14 +204,14 @@ CC码虽是强制要求，但第一层仍有管不到的地方：
 
 ### 4.3 下架后的验证
 
-第二层还有一个重要职责——**验证下架是否真的执行了**：
+网络探针还有一个重要职责——**验证下架是否真的执行了**：
 
 ```
 监管方下达下架指令
     │
-    ├── 第一层通知各平台下架（秒级）
+    ├── 平台门禁通知各平台下架（秒级）
     │
-    └── 第二层验证下架效果（分钟级）
+    └── 网络探针验证下架效果（分钟级）
         ├── 自动巡查该视频的URL → 还能访问吗？
         ├── 已下架 → 记录确认
         ├── 仍能访问 → 升级告警："XX平台未执行下架指令"
@@ -217,17 +236,17 @@ UGC短视频与影视剧有本质区别，不能简单套用同一套流程：
 
 ### 5.2 UGC发码机制
 
-UGC不能要求每个用户都去广电总局申请CC码，需要设计**批量发码+平台代理**机制：
+UGC不能要求每个用户都去广电总局申请CC码，需要设计**批量发码+平台代理**机制。平台通过调用CC码中心的API完成批量赋码和备案：
 
 ```
 用户上传短视频
     │
     ├── 平台自动审核（AI初筛+人工复核）
     │
-    ├── 审核通过 → 平台代理向CC码系统批量申请CC码
+    ├── 审核通过 → 平台调用CC码中心API批量赋码
     │   ├── 平台获得码段授权（广电总局分配号段给平台）
-    │   ├── 平台在号段内为每条UGC内容自动赋码
-    │   └── 赋码信息回传CC码系统备案
+    │   ├── 平台在号段内为每条UGC内容自动赋码（本地完成，无需逐条联网）
+    │   └── 赋码信息通过API批量回传CC码中心备案
     │
     └── 审核不通过 → 拒绝发布
 ```
@@ -239,18 +258,18 @@ UGC不能要求每个用户都去广电总局申请CC码，需要设计**批量
 | **码段授权** | 广电总局给各平台分配CC码号段，平台在号段内自行赋码 |
 | **平台代理** | 用户无需直接对接广电系统，平台代为赋码 |
 | **实时赋码** | 用户上传审核通过后秒级赋码，不影响上传体验 |
-| **回传备案** | 平台定期将赋码清单回传CC码系统，纳入监管 |
-| **码段管控** | 广电可随时收回或冻结平台码段，形成约束 |
+| **API批量回传** | 平台定期通过API将赋码清单批量回传CC码中心，纳入监管 |
+| **码段管控** | 广电可随时通过API收回或冻结平台码段，形成约束 |
 
 ### 5.3 UGC检测策略
 
-UGC量巨大，不可能全量深度检测，采用**分级检测**策略：
+UGC量巨大，不可能全量深度检测，采用**分级检测**策略。检测同样依赖平台调用CC码中心API + 网络探针独立检测双轨进行：
 
-| 检测级别 | 触发条件 | 检测方式 | 处理速度 |
-|---------|---------|---------|---------|
-| **快速筛查** | 所有UGC | CC码元数据验证（有无码、码是否在有效号段内） | 毫秒级 |
-| **重点检测** | 疑似搬运正版内容 | 内容指纹比对（是否匹配已登记的影视剧指纹） | 秒级 |
-| **深度检测** | 疑似违规或高传播量内容 | 水印提取+AI语义分析 | 分钟级 |
+| 检测级别 | 触发条件 | 检测方式 | 由谁执行 | 处理速度 |
+|---------|---------|---------|---------|---------|
+| **快速筛查** | 所有UGC | 平台调用CC码中心API验证元数据（有无码、码是否在有效号段内） | 平台门禁 | 毫秒级 |
+| **重点检测** | 疑似搬运正版内容 | 平台调用CC码中心指纹比对API，与影视剧本纹库匹配 | 平台门禁 | 秒级 |
+| **深度检测** | 疑似违规或高传播量内容 | 网络探针独立提取水印+AI语义分析 | 网络探针 | 分钟级 |
 
 **如何判断"疑似搬运正版内容"**：
 
@@ -286,7 +305,7 @@ UGC视频上传
 
 ### 5.5 直播场景专项设计
 
-直播与点播有本质区别：直播是实时的，不能等审核完再播出。需要单独设计赋码和监管流程：
+直播与点播有本质区别：直播是实时的，不能等审核完再播出。需要单独设计赋码和监管流程。直播赋码和校验同样通过CC码中心API完成，但增加实时校验机制：
 
 **直播赋码机制**：
 
@@ -305,11 +324,11 @@ UGC视频上传
     └── 未赋码 → 平台不得开播
 
 直播进行中
-    ├── 第一层：实时校验CC码状态（是否已被下架）
+    ├── 平台门禁：调用CC码中心API实时校验CC码状态（是否已被下架）
     │   ├── CC码有效 → 继续播出
     │   └── CC码已下架 → 秒级断流
     │
-    └── 第二层：实时录制片段 → 水印提取 + 指纹比对
+    └── 网络探针：实时录制片段 → 水印提取 + 指纹比对
         ├── 内容正常 → 继续监控
         ├── 发现违规 → 秒级告警 + 断流指令
         └── 发现无码直播 → 紧急告警 + 行政通知
@@ -325,7 +344,7 @@ UGC视频上传
 |------|------|
 | **频道/主播级赋码** | 不需要每场直播单独申请，一次赋码长期有效 |
 | **实时校验** | 播出过程中持续校验CC码状态，下架指令秒级生效 |
-| **片段录制** | 第二层对直播流按分钟切片录制，逐片检测 |
+| **片段录制** | 网络探针对直播流按分钟切片录制，逐片检测 |
 | **应急码段** | 突发新闻等无法提前申请的场景，平台使用应急码段，事后补审 |
 | **录像存档** | 直播结束后录像自动存档，供事后追溯和补检 |
 
@@ -360,7 +379,7 @@ UGC视频上传
 | **抗裁剪** | 画面裁剪后仍可部分提取 |
 | **多帧冗余** | 水印重复嵌入在多帧中，部分帧丢失不影响提取 |
 
-> 水印嵌入是CC码监管的技术基础。没有水印，第二层检测就无法识别视频内容的来源。广电总局应制定水印嵌入标准，所有平台和制作方按统一标准执行。
+> 水印嵌入是CC码监管的技术基础。没有水印，网络探针检测就无法识别视频内容的来源。广电总局应制定水印嵌入标准，所有平台和制作方按统一标准执行。
 
 ---
 
@@ -373,7 +392,7 @@ UGC视频上传
 内容制作 → 送审取得CC码 → 上传平台（第一关验证通过）→ 平台审核 → 观众播放
                                                                     │
                                                               一切正常
-                                                           第二层不介入
+                                                           网络探针不介入
 ```
 
 **UGC短视频**：
@@ -381,12 +400,12 @@ UGC视频上传
 用户创作 → 上传平台 → 平台审核 → 平台代理赋码 → 发布上线 → 观众播放
                                                     │
                                               一切正常
-                                           第二层快速筛查通过
+                                           网络探针快速筛查通过
 ```
 
 ### 6.2 异常情况（违规内容）
 
-| 场景 | 第一层 | 第二层 | 最终结果 |
+| 场景 | 平台门禁 | 网络探针 | 最终结果 |
 |------|--------|--------|---------|
 | 无CC码内容上传 | 第一关拦截，拒绝上传 | - | 内容根本不上线 |
 | UGC未赋码就发布 | 平台赋码流程异常，拦截 | - | 内容不上线，平台修复流程 |
@@ -403,9 +422,9 @@ UGC视频上传
 ```
 监管方一条指令
     │
-    ├──→ 第一层：秒级通知全网下架（平台+CDN）
+    ├──→ 平台门禁：秒级通知全网下架（平台+CDN）
     │
-    └──→ 第二层：分钟级验证下架效果
+    └──→ 网络探针：分钟级验证下架效果
          ├── 确认下架 → 结案
          └── 未下架 → 升级处理
 ```
@@ -433,7 +452,7 @@ CC码制度实施后，全网已有海量存量视频没有CC码，必须制定
     │
     ├── 过渡期（12个月）
     │   ├── 存量内容可继续在线，但必须分批补码
-    │   ├── 补码完成前，纳入第二层重点巡查
+    │   ├── 补码完成前，纳入网络探针重点巡查
     │   └── 过渡期内新发现违规的存量内容，立即下架
     │
     └── 过渡期结束
@@ -447,8 +466,8 @@ CC码制度实施后，全网已有海量存量视频没有CC码，必须制定
 |------|------|
 | 广电总局 | 发布补码指令，分配码段 |
 | 各平台 | 负责本平台存量内容的批量补登记 |
-| CC码系统 | 提供批量赋码接口，支持平台批量提交 |
-| 第二层监控 | 验证各平台补码进度，对未按时完成的重点巡查 |
+| CC码中心 | 提供批量赋码API，支持平台批量提交 |
+| 网络探针 | 验证各平台补码进度，对未按时完成的重点巡查 |
 
 ---
 
@@ -467,7 +486,7 @@ CC码制度实施后，全网已有海量存量视频没有CC码，必须制定
     │   通知包含：下架原因、CC码、检测证据
     │
     ├── 平台/创作者发起申诉（48小时内）
-    │   申诉渠道：CC码系统申诉接口 / 平台代申诉
+    │   申诉渠道：CC码中心申诉API / 平台代申诉
     │
     ├── 申诉审核（24小时内）
     │   ├── 自动复核：重新检测，确认是否误判
@@ -492,7 +511,7 @@ CC码制度实施后，全网已有海量存量视频没有CC码，必须制定
 
 | 场景 | 恢复方式 | 速度 |
 |------|---------|------|
-| 申诉成功 | CC码状态恢复为"有效"，第一层播出校验自动放行 | 秒级 |
+| 申诉成功 | CC码状态恢复为"有效"，平台门禁播出校验自动放行 | 秒级 |
 | 申诉成功+CDN缓存 | CC码恢复+通知CDN清除下架标记 | 分钟级 |
 | 误批量下架 | 批量恢复CC码状态，批量通知平台 | 分钟级 |
 
@@ -506,8 +525,8 @@ CC码制度实施后，全网已有海量存量视频没有CC码，必须制定
 
 | 阶段 | 时间 | 目标 |
 |------|------|------|
-| **第一阶段** | 3个月 | 第一层上线：监管API+秒级下架，对接IPTV+1~2家持证平台 |
-| **第二阶段** | 6个月 | 第二层起步版上线+UGC赋码机制上线，对接短视频平台 |
+| **第一阶段** | 3个月 | 平台门禁上线：监管API+秒级下架，对接IPTV+1~2家持证平台 |
+| **第二阶段** | 6个月 | 网络探针起步版上线+UGC赋码机制上线，对接短视频平台 |
 | **第三阶段** | 9个月 | 存量补码启动+直播监管上线+GPU加速检测 |
 | **第四阶段** | 12个月 | 全量上线：全网平台对接+存量补码完成+完整监管覆盖 |
 | **第五阶段** | 18个月 | 全量运行+对抗加固+运营优化 |
@@ -517,7 +536,7 @@ CC码制度实施后，全网已有海量存量视频没有CC码，必须制定
 | 时间点 | 里程碑 | 验收标准 |
 |--------|--------|---------|
 | 第3个月 | 持证平台秒级拦截上线 | 试点平台上传验证+播出校验+秒级下架 |
-| 第6个月 | UGC赋码+独立监控跑通 | 短视频平台批量赋码上线，日检测5000条，准确率≥90% |
+| 第6个月 | UGC赋码+网络探针跑通 | 短视频平台批量赋码上线，日检测5000条，准确率≥90% |
 | 第9个月 | 存量补码+直播监管 | 存量Top1000补码完成，50路直播实时监测 |
 | 第12个月 | 全量运行 | 全网覆盖，存量补码完成，完整告警+下架+验证+申诉闭环 |
 | 第18个月 | 运营优化 | 误判率<2%，对抗测试通过，全量稳定运行 |
@@ -535,9 +554,9 @@ CC码制度实施后，全网已有海量存量视频没有CC码，必须制定
 | CDN注入校验 | 无需改动 | 已有关卡，直接复用 |
 | 终端播放抽检 | 无需改动 | 已有关卡，直接复用 |
 | 应急下架指令 | 秒级全网同步 | 从"逐层通知"升级为"一键全网下架" |
-| 全生命周期监管 | 独立外部监控 | 新增"不依赖平台配合"的监管视角 |
+| 全生命周期监管 | 网络探针外部监控 | 新增"不依赖平台配合"的监管视角 |
 
-> **核心理念：不替代现有系统，在关键节点嵌入验证能力，新增独立监控兜底。**
+> **核心理念：不替代现有系统，在关键节点嵌入验证能力，新增网络探针兜底。**
 
 ---
 
@@ -545,9 +564,9 @@ CC码制度实施后，全网已有海量存量视频没有CC码，必须制定
 
 | 风险 | 发生概率 | 影响 | 应对措施 |
 |------|---------|------|---------|
-| 平台对接进度滞后 | 中 | 第一层覆盖不全 | 行政强制+分批过渡+第二层重点巡查未对接平台 |
+| 平台对接进度滞后 | 中 | 平台门禁覆盖不全 | 行政强制+分批过渡+网络探针重点巡查未对接平台 |
 | UGC赋码性能瓶颈 | 中 | 短视频平台上传受阻 | 码段授权+平台本地赋码+异步回传，不依赖实时联网 |
-| 水印被技术手段去除 | 低 | 第二层检测难度增大 | 三种检测手段层层兜底，去水印还有指纹识别 |
+| 水印被技术手段去除 | 低 | 网络探针检测难度增大 | 三种检测手段层层兜底，去水印还有指纹识别 |
 | 爬虫被网站反爬阻挡 | 中 | 部分网站采集不到 | 多种采集策略；群众举报通道补充 |
 | CDN厂商不配合下架 | 低 | 下架不彻底 | 行政处罚；DNS封锁作为最终手段 |
 | 误判正常内容为违规 | 中 | 影响正常播出和创作 | 分级处置+人工兜底+申诉通道+阈值持续优化 |
@@ -563,7 +582,7 @@ CC码制度实施后，全网已有海量存量视频没有CC码，必须制定
 
 | 维度 | 现状 | 本方案实现后 |
 |------|------|------------|
-| **发现速度** | 人工巡查，天级~周级 | 秒级（平台预防）+ 分钟级（独立监控） |
+| **发现速度** | 人工巡查，天级~周级 | 秒级（平台门禁）+ 分钟级（网络探针） |
 | **下架速度** | 逐级通知，小时级~天级 | 一键指令，秒级全网下架 |
 | **覆盖范围** | 依赖平台配合，UGC基本失管 | 全量覆盖：影视剧+UGC+直播，持证平台+短视频+境外 |
 | **追溯能力** | 难以追溯来源 | CC码+水印+指纹，全链路追溯 |
@@ -579,13 +598,13 @@ CC码制度实施后，全网已有海量存量视频没有CC码，必须制定
 
 ## 十三、决策建议
 
-1. **尽快启动第一阶段**（第一层平台侧预防），投入小、见效快，3个月即可实现持证平台秒级拦截
-2. **同步启动第二层MVP和UGC赋码机制**，UGC是最大的监管盲区，必须尽早覆盖
+1. **尽快启动第一阶段**（平台门禁），投入小、见效快，3个月即可实现持证平台秒级拦截
+2. **同步启动网络探针MVP和UGC赋码机制**，UGC是最大的监管盲区，必须尽早覆盖
 3. **同步启动存量补码计划**，存量内容量大，越早启动越主动
 4. **推动CC码制度法规落地**，技术方案需要政策支撑，平台配合度取决于行政强制力
 5. **分阶段扩容**，先验证再投入，避免一次性大规模建设
 6. **建立申诉机制**，误判处理是业务领导最关切的实操问题，必须在上线前就绪
-7. **第一层+第二层缺一不可**，只有第一层会被绕过，只有第二层下架慢，两层并行才能实现全覆盖、秒级响应
+7. **平台门禁+网络探针缺一不可**，只有平台门禁会被绕过，只有网络探针下架慢，两层并行才能实现全覆盖、秒级响应
 
 ---
 
@@ -619,7 +638,7 @@ CC码不是一次性发放就结束的，每个CC码都有完整的生命周期
 | 操作 | 谁有权执行 | 生效速度 |
 |------|-----------|---------|
 | 申请CC码 | 内容制作方/平台代理 | - |
-| 审核签发 | 广电总局CC码系统 | 审核通过后即时 |
+| 审核签发 | 广电总局CC码中心 | 审核通过后即时 |
 | 暂停 | 监管方/平台举报 | 秒级 |
 | 恢复 | 监管方核实后 | 秒级 |
 | 下架 | 监管方 | 秒级全网同步 |
@@ -637,7 +656,7 @@ CC码不是一次性发放就结束的，每个CC码都有完整的生命周期
 |------|------|----------------|
 | **监管中心** | 统筹CC码签发、下架决策、申诉审核 | 5~8人 |
 | **审核团队** | CC码申请审核、误判申诉复核、合理使用界定 | 8~12人 |
-| **监控运营团队** | 第二层监控系统运营、告警处理、爬虫策略调整 | 6~10人 |
+| **监控运营团队** | 网络探针系统运营、告警处理、爬虫策略调整 | 6~10人 |
 | **平台对接团队** | 推动各平台对接API、技术支持、进度跟踪 | 4~6人 |
 | **技术运维团队** | 系统运维、水印/指纹/AI模型优化 | 6~8人 |
 
@@ -672,6 +691,6 @@ CC码不是一次性发放就结束的，每个CC码都有完整的生命周期
 | 信息网络传播视听节目许可证 | **平台级并行** | 平台持此证是前提，CC码是平台必须接入的验证体系 |
 | IPTV集成播控牌照 | **天然对接** | 已有TCS-IPTV系统，CC码验证API直接复用 |
 | 广播电视节目制作经营许可证 | **内容制作方并行** | 制作方持此证制作内容，内容上线前还需取得CC码 |
-| 现有内容审查制度 | **前置环节** | 内容审查通过后，方可申请CC码；CC码系统不替代审查 |
+| 现有内容审查制度 | **前置环节** | 内容审查通过后，方可申请CC码；CC码中心不替代审查 |
 
 > **核心理念：CC码不替代任何现有制度，而是在现有制度之上增加一个"数字身份证"层，实现从"审批管理"到"实时监管"的升级。**