MAcode/1-prd-IPTV.md

TCS-IPTV 内容可信锁定系统 — 产品需求文档（PRD）

版本：V1.0 编制日期：2026年6月 上游文档：0-req-IPTV.md（需求规格说明书） 文档编号：1-prd-IPTV

---

一、产品概述

1.1 产品定位

TCS-IPTV 是一套架设在 内容提供商（CP）、审核和监管部门、运营商 三方现有系统之上的内容可信身份映射层。它通过"MA码（监管身份）+ 哈希码（技术指纹）"双锚定机制，让每一条 IPTV 内容拥有全网唯一、不可篡改、可追溯的可信身份，实现"审过即锁定，锁定即通行，通行可追溯"。

一句话定位：不替代任何现有系统，只在三方之上加一层"可信锁"，把"是谁、是不是、在哪里"三个问题一次性解决。

1.2 产品要解决的核心问题

现状痛点	根因	TCS-IPTV 的解法
同一内容反复审核，边际成本不降	三方编码体系割裂，无法互认	MA码+哈希一次锁定，跨省凭证复用
版本替换、换壳重发难识别	缺乏内容级技术指纹	文件哈希比特级锁定 + 感知哈希跨格式识别
违规下架指令逐层翻译，响应滞后	编码不互通，需人工逐层映射	一个MA码自动翻译为三方下架指令，秒级同步
跨省跨运营商复用要重走全流程	审核结果无法跨域信任	凭MA码+哈希证书快速准入，审核简化为抽检
三方数据对账差异大	统计口径不统一	以MA码为统一维度聚合，口径一致

1.3 目标用户

用户	关注点	产品价值主张
内容提供商（CP）	审核成本、跨省复用效率、版权保护	一次录入全网复用，重复审核成本大幅下降
审核和监管部门	管得住、管得省、管得准	审播一致、精准溯源、秒级下架、数据可信
运营商	分发合规、防篡改、对账准确	注入即校验，杜绝劫持篡改，数据口径统一

---

二、产品目标与成功指标

2.1 产品目标

• G1 审播一致：送审版=播出版，任何篡改秒级识别
• G2 一码通行：一省过审，全网凭 MA码+哈希准入
• G3 精准溯源：凭 MA码秒级定位三方系统与全链路状态
• G4 数据可信：播放量、结算、上报以统一标识聚合
• G5 最小侵入：不改造三方现有系统，仅在关键节点嵌入校验

2.2 成功指标（North Star & 关键指标）

指标	现状	目标	对应需求
跨省复用审核周期	15-30天	3-5天	需求13、18
违规内容下架响应	2-24小时	分钟级	需求11、18
内容版本替换识别率	几乎无法识别	100%自动识别	需求4、12、18
三方数据对账差异	15-30%	<5%	需求9、18
CP重复录入成本	每省每运营商重复	一次录入全网复用	需求13
分账对账争议金额	高（数据各执一词）	以可信数据为准，争议大幅下降	需求21
违规追责定位耗时	数天（人工扯皮）	分钟级（链上取证）	需求22
追更内容处理耗时	重走全流程	秒级（增量哈希）	需求24
接入CP数（三期）	—	≥10家主流CP	—
覆盖省份（三期）	—	全国IPTV贯通	—

---

三、用户画像与核心场景

3.1 用户画像

画像A — CP内容运营专员（小赵）

• 职责：负责剧集送审、跨省发行
• 痛点：每进一个省、对接一个运营商就要重新录入、重新走审核
• 期望：一次过审，凭证全网通行，不再重复劳动

画像B — 审核和监管部门审核员/监管员（王主任）

• 职责：内容合规审核（CSPS）、违规处置、全网监管
• 痛点：出问题难定位，下架指令逐层打电话翻译，慢且易漏
• 期望：一个MA码看清全链路，一键下架全网生效

画像C — 运营商分发工程师（老李）

• 职责：CDN注入、EPG发布、数据上报
• 痛点：收到的内容真假难辨，被篡改/劫持难发现，对账总对不平
• 期望：注入前自动校验，数据口径和上游统一

3.2 核心使用场景

场景1：内容首次送审与赋码（端到端正向流程） 小赵在 CP 媒资系统完成制作 → 用哈希SDK对母版计算哈希包 → 登录备案系统提交节目信息+哈希包 → 审核和监管部门审核通过、签发MA码并强绑定哈希 → 小赵拿到"MA码+哈希证书"。

痛点解法：让内容从源头就获得全网唯一、不可篡改的可信身份，为后续一切流转奠定基础。

场景2：内容入库发布（审核→媒资库→运营商） 送审文件验真通过 → CSPS审核合规 → 转码并绑定各版本哈希 → 合格内容进入媒体资源库 → 从媒体资源库携带MA码+哈希证书向运营商发布 → 运营商注入CDN前校验哈希 → 校验通过注入分发。

痛点解法：保证"送审版=播出版"，转码多版本各自锁定，杜绝入库到分发环节的偷换。

场景3：跨省快速复用 小赵已在A省过审 → 向B省仅提交MA码+哈希证书（不传文件） → 系统三重校验（MA码有效+哈希一致+非黑名单） → B省快速准入，审核简化为合规抽检。

痛点解法：跨省复用从"重走全流程15-30天"压缩到"验真+抽检3-5天"，CP边际成本大幅下降。

场景4：违规应急下架 王主任发现违规 → 下发"下架MA码第XXX号"单一指令 → 系统解析该MA码绑定的全部三方编码与CDN端点 → 自动翻译为媒资库撤除发布+运营商下架CDN资源 → 秒级全网同步。

痛点解法：下架响应从"2-24小时逐层人工翻译"升级为"一码下发、秒级全网生效"。

场景5：版本篡改识别 内容被剪辑/替换 → 哈希变化 → MA码与哈希绑定断裂 → 系统标记reaudit_required → 通过Merkle Tree定位被篡改的具体集数 → 阻断分发并触发重审。

痛点解法：版本替换/换壳重发从"几乎无法识别"升级为"100%自动识别并定位到具体集"。

场景6：可信播放数据与自动分账结算（利益核心） 内容在多个运营商分发播出 → 各运营商以MA码为唯一维度上报播放数据 → 可信数据空间链上聚合，形成不可篡改的可信播放量 → 作为CP与运营商分账结算的统一依据 → 对账差异从15-30%降至5%以内，回款争议大幅减少。

痛点解法：解决CP与运营商"播放量各执一词、分账扯皮、回款慢"的真金白银痛点。

场景7：违规责任精准界定与追责（权责对等） 出现违规内容需追责 → 监管按MA码调取全链路哈希存证 → 逐环节比对（CP送审哈希 / CSPS审核结论 / 转码版哈希 / 媒资库发布哈希 / 运营商注入哈希 / 终端抽检哈希）→ 精准定位"问题出在哪个环节、是哪一方改动" → 责任落到具体方与具体节点。

痛点解法：终结CP、审核监管、运营商三方"互相甩锅"，实现权责对等、有据可查。

场景8：版权确权与维权举证（权利保护） CP内容被盗版/换皮 → 凭MA码+哈希+上链时间戳形成不可抵赖的"谁先锁定谁有权"证据链 → 可直接用于侵权投诉与司法诉讼举证 → 系统识别盗版内容感知哈希与正版高度相似，辅助锁定侵权。

痛点解法：解决CP"被盗用拿不出有法律效力证据"的确权维权痛点。

场景9：追更与增量更新（效率提升） 剧集追更/片尾修正/临时插播 → 仅对变化的集或片段重新计算哈希 → 基于Merkle Tree只更新变化叶子节点与根哈希 → 未变化部分复用原审核结论 → 追更内容秒级完成赋码与发布。

痛点解法：解决微短剧/剧集"每追一集、改个片尾都要重走全流程"的高频重复劳动。

场景10：授权链可信核验（权利+利益） CP上链授权信息（信息网络传播权的地域/期限/平台范围）→ 审核监管与运营商在发布/注入前实时核验授权范围 → 超出授权地域、过期、或非授权平台的分发当场被拦截 → 授权变更可追溯。

痛点解法：解决线下授权PDF"易伪造、难核验、越权分发"的权利与利益痛点。

---

四、产品范围与功能清单

4.1 功能模块总览

系统分为五大功能域，覆盖三方角色的关键节点：

┌─────────────────────────────────────────────────────────────┐
│  ① CP工作域      ② 审核监管域       ③ 运营商域               │
│  哈希生成SDK     验真+CSPS对接      CDN注入校验               │
│  送审申报        MA码签发引擎       终端抽检SDK               │
│                  媒资库映射         数据上报                  │
│                  监管大屏+应急下架                            │
├─────────────────────────────────────────────────────────────┤
│  ④ 可信数据空间（核心）：CTID模型 / 双哈希 / 映射表 / 智能合约 │
│  ⑤ 开放接口域：register / verify / mappings / 鉴权           │
└─────────────────────────────────────────────────────────────┘

4.2 功能清单与优先级（MoSCoW）

编号	功能	所属域	优先级	对应需求
F01	母版多维哈希生成SDK（文件/分段Merkle/感知）	CP工作域	Must	需求1
F02	送审申报与哈希上链	CP工作域	Must	需求2
F03	MA码签发与1:1强绑定	审核监管域	Must	需求3
F04	送审文件验真	审核监管域	Must	需求4
F05	CSPS审核对接与转码版哈希绑定	审核监管域	Must	需求5
F06	媒体资源库入库/发布与编码映射	审核监管域	Must	需求6
F07	CDN注入校验	运营商域	Must	需求7
F08	终端播放哈希抽检	运营商域	Could	需求8
F09	统一维度数据上报与聚合	运营商域/可信空间	Should	需求9
F10	全生命周期监管大屏查询	审核监管域	Must	需求10
F11	违规应急下架（一键全网）	审核监管域	Must	需求11
F12	版本变更与重审触发	可信空间	Must	需求12
F13	跨省复用快速准入	审核监管域	Should	需求13
F14	角色权限控制（三角色矩阵）	全局	Must	需求14
F15	异常处理规则引擎	全局	Must	需求15
F16	可信数据空间存证与智能合约	可信空间	Must	需求16
F17	标准化开放API（register/verify/mappings）	开放接口域	Must	需求17
F18	可信播放数据聚合与分账结算依据	可信空间/运营商域	Should	需求21
F19	全链路责任界定与追责取证	审核监管域/可信空间	Should	需求22
F20	版权确权与维权举证（证据链导出）	CP工作域/可信空间	Should	需求23
F21	追更与增量哈希更新	CP工作域/可信空间	Should	需求24
F22	授权链上链与发布前授权核验	全局	Should	需求25

4.3 不在本期范围（Out of Scope）

• OTT、手机APP等大小屏融合接入（规划至四期，需求19.4 为可扩展性预留）
• 内容推荐、计费结算的业务逻辑（系统仅提供以MA码为维度的数据聚合，不做结算）
• CSPS审核算法本身的改造（系统仅对接其审核结论，不介入审核规则）

---

五、关键产品流程

5.1 端到端主流程（正向）

[CP] 制作母版
   → 哈希SDK计算哈希包（本地，不传原文件）
   → 送审申报（节目信息+哈希包）→ 获送审流水号
        │
[审核监管] MA码签发引擎 审核通过 → 签发MA码 + 哈希1:1强绑定上链
   → CP获"MA码+哈希证书"
        │
[审核监管] 送审文件验真（哈希比对）
   → 匹配 → 进入CSPS合规审核
   → 转码 → 各版本哈希绑定（父子关系）
   → 合格内容入媒体资源库（建立 媒资编码↔MA码↔哈希 映射）
        │
[审核监管→运营商] 从媒体资源库发布（携带MA码+哈希证书）
        │
[运营商] CDN注入校验（哈希比对）
   → 匹配 → 注入CDN + 生成分发编码 + 注册映射
   → EPG发布 → 用户点播
   → （可选）终端片段哈希抽检
        │
[运营商] 以MA码为维度上报播放数据 → 可信空间统一聚合

5.2 应急下架流程（逆向）

[审核监管-监管主体] 下发"下架 MA码第XXX号"
   → 可信空间解析MA码 → 查出全部三方编码+CDN端点
   → 自动翻译为：
        · 媒体资源库：撤除发布
        · 运营商：下架分发编码YYY + CDN资源ZZZ
   → 秒级全网同步 → 各方执行下架

5.3 异常分支（摘要）

触发点	异常	系统动作
送审验真	哈希不匹配	退回CP，标记"疑似版本替换"
CDN注入	哈希不匹配	拒绝注入，告警审核监管部门，暂停分发
终端抽检	哈希不匹配	断流，切备用源，上报异常日志
内容变更	哈希变化	绑定断裂，reaudit_required=true，触发重审
换壳重发	哈希已存在	拒绝重复申报，关联原MA码

---

六、角色权限矩阵（产品视角）

操作	内容提供商	审核和监管部门	运营商
签发MA码	✗	✅（仅监管主体）	✗
注册哈希	✅（送审时）	✅	✗
验真查询	✅（自查）	✅	✅
映射管理	✅（本方）	✅	✅（本方）
CSPS审核	✗	✅（审核主体）	✗
媒资库入库/发布	✗	✅	✗
发起应急下架	✗	✅（仅监管主体）	✗
执行下架指令	✗	✅	✅

注：审核和监管部门内部区分"监管主体"（行政权力：签发、下架发起）与"审核主体"（把关职责：CSPS审核、媒资发布）。

---

七、版本规划（Release Plan）

阶段	周期	范围	包含功能	目标
MVP（一期）	3个月	单省单运营商微短剧全流程	F01-F07、F10-F12、F14-F17	跑通"送审→赋码→审核→入库→发布→注入→下架"闭环
二期	6个月	多省多运营商，扩品类，强化权益	+F08、F09、F13、F18-F22	3-5省、网络剧/网络电影、10+ CP；上线可信分账、追责取证、确权举证、追更、授权核验
三期	12个月	全国IPTV贯通	全功能稳定 + 备案系统对接	成为全国IPTV内容准入基础设施
四期	18个月	大小屏融合	OTT/APP接入扩展	MA+哈希机制延伸至OTT、手机APP

MVP 验收标准

• CP可完成哈希生成→送审→获MA码全流程
• 审核监管部门可完成验真→CSPS审核对接→媒资库入库→发布
• 运营商可完成CDN注入校验→分发
• 监管可完成按MA码查询全链路 + 一键应急下架（秒级生效）
• 版本篡改可被100%识别并阻断

---

八、非功能性要求（产品级）

维度	要求
性能	下架响应分钟级；哈希验真接口实时返回
兼容性	不改造CSPS、媒体资源库内部流程，仅通过映射层对接；保留三方自有编码
安全	MA码+哈希绑定不可篡改不可解绑；哈希本地计算不传原文件；关键操作链上存证
合规	完全符合广电总局网络剧片发行许可及备案制度
可扩展	支持网络剧/微短剧/网络电影/网络动画，可扩展至OTT/APP

---

九、依赖与风险

类别	内容	应对
依赖	联盟链/分布式账本基础设施	一期完成选型与部署
依赖	CSPS与媒体资源库开放对接接口	提前与审核监管部门确认接口规范
依赖	广电总局备案系统对接MA码签发	政策与技术双轨推进
依赖	授权转码中心支持转码后哈希重算上链	纳入一期改造范围
风险	三方系统改造意愿与排期	最小侵入设计 + 试点先行（广东/湖南）
风险	跨省信任机制的政策落地	与监管联合制定跨省复用规则

---

十、产品价值总结

TCS-IPTV 的核心不是让三方放弃自己的系统，而是在三方系统之上建立一层"可信身份映射层"—— 用 MA码 解决"是谁"的监管问题，用 哈希码 解决"是不是"的技术问题，用 可信数据空间 解决"在哪"的溯源问题。 三者叠加，IPTV内容才能真正实现"审过即锁定，锁定即通行，通行可追溯"。

对监管：从"逐层翻译滞后"升级为"一码穿透、秒级响应"。 对CP：从"每省重走全流程"升级为"一次录入、全网复用"。 对运营商：从"真假难辨"升级为"注入即校验、数据可对齐"。

---

本 PRD 基于 0-req-IPTV.md 编制，作为产品设计、UE/UI 设计与技术方案设计的输入。