“毛片未成年人保护”落到开发层面，不能只依靠年龄弹窗，而应搭建一条从内容接入、风险识别、未成年人保护决策到拦截留痕的完整链路。系统至少要区分疑似涉未成年人内容、成人色情内容、普通内容和无法确认的内容，并通过明确的接口契约把识别结果交给审核、推荐、搜索、播放和举报模块处理。
先确定保护链路和处理结果
建议把保护能力拆成四个独立服务：内容接入服务、内容审核服务、未成年人场景判断服务、处置与审计服务。这样可以避免把模型结果直接等同于最终动作，也便于后续更换识别模型或调整平台规则。
- 内容接入：接收视频、图片、标题、描述、评论或用户举报产生的待审核对象，生成唯一内容编号。
- 内容识别：分析文本、封面、视频关键帧、音频转写结果及账号上下文，输出风险标签和置信度。
- 场景判断：结合访问者年龄状态、内容风险等级、地区规则和账号权限，确定是否允许展示、限制传播或转人工。
- 处置审计：执行下架、隐藏、阻断播放、限制搜索、限制推荐、冻结审核状态等动作，并保留可追溯记录。
其中，识别结果和处置结果应当分开保存。模型只能说明“检测到什么风险”，不能在没有业务规则的情况下直接决定“用户一定能否观看”。
设计可验证的内容识别接口
内容审核接口需要具备幂等性、版本标记和可解释的返回字段。以下是一套可作为内部服务起点的契约，实际项目应根据模型输入形式调整字段，不应把不存在的第三方接口名称写入业务代码。
| 字段 | 类型 | 要求 |
|---|---|---|
| content_id | 字符串 | 平台内部唯一编号，必填 |
| content_type | 字符串 | video、image、text 或 comment |
| content_ref | 字符串 | 内部对象引用，不直接暴露原始敏感地址 |
| scene | 字符串 | upload、search、feed、playback 或 report |
| policy_version | 字符串 | 本次审核使用的规则版本 |
| request_id | 字符串 | 请求追踪编号，用于幂等和排查 |
接口可以采用同步和异步两种模式。短文本和封面适合同步返回；完整视频通常需要提交任务后异步回调。接口名称并不重要，重要的是状态含义必须固定，例如 accepted 表示已接收，processing 表示处理中，completed 表示完成，failed 表示识别失败，而不是把“未发现风险”误写成“绝对安全”。
返回结构至少应包含以下信息：审核状态、风险分类、风险分数、命中的检测来源、模型版本、规则版本、是否需要人工复核以及结果有效期。风险分类可以设置为：
- minor_related_sexual：疑似涉及未成年人或未成年人形象的性化内容，进入最高优先级保护流程。
- adult_explicit：疑似成人色情或露骨性内容，按照平台适用规则限制传播。
- sexual_ambiguous：存在性化或色情风险，但证据不足，转人工复核。
- non_explicit：当前检测未发现需要拦截的风险，但不代表永久安全。
- technical_error：文件损坏、格式不支持、超时或模型不可用，默认不能直接放行。
未成年人保护接口要单独判断
内容识别和用户年龄判断是两个问题。系统不应只因为用户填写了出生日期，就把敏感内容直接放行。建议建立独立的保护决策接口，由它读取内容审核结果、账号年龄状态、监护或年龄确认状态、访问场景和当前策略版本，统一输出最终动作。
| 项目 | 示例含义 |
|---|---|
| content_risk | minor_related_sexual、adult_explicit 等风险标签 |
| age_status | minor、adult_verified、unknown 或 unavailable |
| access_scene | 搜索、推荐、播放、评论、私信或上传 |
| policy_version | 当前平台保护规则版本 |
| decision | allow、limit、block、review 或 error_hold |
| reason_code | 用于前端提示、客服处理和审计查询的稳定编码 |
决策规则应明确写成可测试的优先级。只要内容被判定为疑似涉未成年人性化内容，就应优先进入阻断和人工复核流程，不能因为用户声称已成年而绕过检测。访问者年龄未知时，对高风险内容不应默认放行；识别服务超时或返回异常时，也应进入保护性降级，而不是把异常当作通过。
把拦截动作接入播放、搜索和推荐
保护决策只有落实到产品链路才有效。上传阶段可以阻止内容进入公开存储或分发队列；搜索阶段应过滤标题、标签、封面和结果卡片；推荐阶段要在召回和排序两个位置检查风险状态；播放阶段还要在获取播放凭证或媒体地址前再次校验，避免用户通过缓存链接、历史记录或直接请求绕过页面限制。
建议所有展示链路都读取统一的内容状态，而不是各自调用不同的模型。一个内容被阻断后，状态应同步到搜索索引、推荐缓存、播放权限、评论区和举报处理队列。对于已经发布的内容，需要支持重新审核和主动撤回，特别是在模型、规则或举报结论发生变化时。
需要覆盖的关键状态
- pending：已提交但尚未完成检测，不能进入公开展示链路。
- review：需要人工复核，限制传播范围并保留原始证据引用。
- blocked：禁止展示、搜索、推荐和播放，相关访问返回统一的 reason_code。
- restricted：按照业务规则限制部分能力，不能与普通内容使用同一推荐权重。
- cleared：完成审核并允许进入相应场景，但仍保留版本和复审入口。
接口失败时要有保护性降级
开发时最容易忽略的是模型服务不可用。应为超时、限流、文件无法读取、回调丢失和版本不匹配分别定义错误码，并记录 request_id、content_id、服务版本和重试次数。对高风险或未完成审核的内容，失败时应保持不可公开，而不是自动切换为允许状态。
异步回调需要校验签名或内部身份、回调时间、任务编号和结果版本，防止旧结果覆盖新结果。重复回调应保持幂等；已经处置的内容收到相同结论时不重复执行副作用操作。若新结果与旧结果冲突，应以规则版本和审核时间更明确的结果进入复核，而不是静默覆盖。
用测试用例验证保护是否真正生效
上线前不要只测试“正常视频能否通过”，还要测试保护边界和绕过路径。测试数据应使用经过授权和脱敏的样本，避免在开发、日志或工单中传播真实敏感材料。至少应验证以下场景：
- 疑似涉未成年人风险被识别后，搜索、推荐和播放是否全部阻断。
- 用户年龄状态为 unknown 时，高风险内容是否仍保持保护状态。
- 审核服务超时、回调重复或返回空结果时，系统是否不会默认放行。
- 内容被重新审核为 blocked 后，旧的推荐缓存和播放凭证是否失效。
- 人工复核结论能否覆盖低置信度自动结果，并完整记录操作人和规则版本。
- 举报提交后是否生成可追踪工单，且处理状态能反馈给业务模块。
最后，日志只保留完成审计所需的信息，敏感原文、原始媒体和用户身份信息应按最小化原则处理，并设置访问权限、保存期限和删除机制。一个可用的“毛片未成年人保护”系统，核心不是宣称识别百分之百准确，而是建立清晰的接口契约、不可绕过的保护决策、失败时不放行的降级规则，以及能够复核和追责的完整记录。
