社区治理、举报处置与合规：从规则到可执行的治理流水线

规则分层：
□ 法律底线（必须执行）：
  违法内容（涉恐/涉毒/色情/侵权）→ 强制下架 + 上报
□ 社区规则（平台自主）：
  辱骂/引战/垃圾广告/色情擦边 → 下架/限权/警告
□ 产品规范（平台偏好）：
  低质量灌水/标题党 → 降权/限流（不删除）

优先级：
法律底线 > 社区规则 > 产品规范
处置强度也从「封禁/下架」递减到「降权/限流」

治理动作谱系（由轻到重）：
降权（限流/不推荐） → 警告 → 内容限权 → 内容下架
 → 账号限权（禁言） → 账号封禁 → 上报执法

举报类型（结构化）：
□ 内容举报：辱骂/垃圾/色情/侵权/引战/违规广告
□ 账号举报：骚扰/冒充/恶意行为
□ 必须允许「补充说明」（自由文本）

举报去重与合并：
□ 同一内容被多人举报 → 合并成「一次举报事件」（按类型）
□ 举报权重：真实用户举报 > 新号举报（防刷举报）
□ 举报达到阈值 → 进入人工/优先队列

响应时效：
□ 高危类型（色情/暴力）→ 实时/分钟级处置
□ 一般类型 → 小时/天内处置
□ 未处置的举报要有「看板」，防止积压

举报数据模型：
report(id, target_type, target_id, reporter_id, report_type,
       description, status, created_at, handled_at)
  + 唯一去重：(target_type, target_id, report_type) 半开窗

处置流程：
发现（AI 审核 / 用户举报） → 初审 → 处置 → 通知当事人
  → 当事人申诉 → 复核 → 维持或撤销

处置原则：
□ 先处置：违规内容先下架/限权，避免持续传播
□ 可申诉：处置必须给「申诉入口」与「处置理由」
□ 可复核：人工复核 AI 判定；申诉复核原处置

角色分离：
□ 初审与复核分离（避免同一个人既判又复核）
□ 高危处置（封禁）需二次确认（双人/上级）

申诉处理：
□ 申诉单与处置单关联（可追溯）
□ 申诉在 SLA 内响应（如 24h）
□ 维持/撤销都要「更新处置状态 + 通知」

下架 = 状态置为 hidden/removed（软删除，见数据模型篇）：
□ 内容列表不再返回（查询带状态过滤）
□ 个人主页不显示（除非「仅自己可见」）
□ 分享链接显示「内容不可见」

传播链清障：
□ 下架内容的转发/评论 → 一并隐藏（连带处理）
□ 时间线缓存里残留 → 墓碑过滤（见数据模型篇）
□ 图片/视频 → 替换为占位图（CDN 层处理）

特殊内容（需要「拉黑传播」）：
□ 色情/暴力 → 加入「敏感内容 hash 库」，新上传同 hash 直接拦截
□ 侵权 → 通知侵权方，走投诉-处理流程

下架的两种形态：
□ 软隐藏（可申诉恢复）：status = hidden，数据保留
□ 彻底清除（执法/隐私）：物理删除 + 传播链清除

处置阶梯（由轻到重）：
□ 警告：首次轻微违规，通知即可
□ 限权：限制发帖/评论/私信（禁言），按时间阶梯（1d/7d/30d）
□ 功能降级：不推荐其内容（算法侧限流）
□ 封禁：永久/限期，账号不可登录
□ 执法上报：严重违法，配合执法部门

阶梯依据：
□ 违规次数：首次轻、累犯重
□ 违规性质：法律底线直接重处置
□ 处置记录：全账号维度的违规历史（累犯检测）

工程实现：
□ 账号状态字段（active/limited/banned）+ 处置到期时间
□ 限权期间：发布/评论走「状态检查」拒绝
□ 封禁：登录态失效 + 内容按账号维度处理
□ 累犯计数：违规记录表按账号聚合

核心指标：
□ 处置量（按类型/按手段）与时效（处置到处置完成的时长）
□ 申诉率（被处置内容中申诉的比例）→ 误判率代理指标
□ 申诉维持率（复核后维持原判的比例）→ 处置质量
□ 举报有效率（有效举报占比）→ 防刷效果
□ 违规复发率（处置后再次违规的比例）

处置留痕（审计）：
□ 每个处置：谁发起的（AI/用户/人工）、谁处置的、何时、依据规则、结果
□ 留痕不可改（append-only），供内部审计与外部检查
□ 处置理由要「可解释」：为什么下架（依据哪条规则）

审计查询：
按内容 → 处置历史；按账号 → 全部处置记录
按规则 → 哪些内容因此处置；按审核员 → 其处置质量

内容安全法（如中国《网络安全法》《网络信息内容生态治理规定》）：
□ 违法信息必须「发现即处置」，平台有主动发现义务
□ 需要「内容安全团队 + 系统化审核流水线」的证明

个人信息保护（个保法/GDPR）：
□ 用户数据的收集/使用需授权，删除需响应
□ 注销账号 → 数据删除/匿名化（见数据模型篇）
□ 跨境数据存储限制（数据本地化）

数据留存：
□ 日志/处置记录按法定时限留存（如网络日志 6 个月）
□ 执法协助：按执法要求提供数据（有合规流程）

内容安全团队的日常：
□ 定期演练「违规内容处置」的时效与完整性
□ 建立「内容安全审查台账」，应对监管抽查

架构要求总结：
□ 处置留痕永久保存（append-only 审计日志）
□ 数据删除/匿名化能力（按账号维度）
□ 区域化数据存储（多区域部署/数据本地化）
□ 主动发现能力（审核流水线的覆盖率证据）

规则演进：
□ 规则版本化（规则库 / 规则引擎配置）
□ 新规则先小流量灰度（只对新内容生效）
□ 旧内容按需回溯处置（重大规则变更时）
□ 规则变更日志（何时、为何、谁批准的）

规则引擎：
□ 规则从「代码硬编码」抽到「配置化」：
  类型 + 条件 + 动作（如 辱骂 + 首次 → 下架 + 警告）
□ 配置变更走发布流程（灰度 + 回滚）

回溯处置：
□ 新规则上线 → 存量内容是否需要回溯
□ 回溯 = 批量重跑审核/处置（异步任务，限速）

灰度示例：
新举报类型上线 → 先「仅记录不处置」→ 观察误报率
  → 再「小流量处置」→ 全量

失败模式 1：只删不查
  AI 处置了但无留痕/无申诉入口 → 误删无法挽回，公信力崩

失败模式 2：举报积压
  举报进队列无人处理 → 用户觉得「举报没用」→ 放弃举报

失败模式 3：误判伤及无辜
  清洗器太激进误删正常内容 → 用户流失（比漏判更伤留存）

失败模式 4：规则与处置脱节
  规则写着「辱骂下架」，系统实际只警告 → 规则形同虚设

失败模式 5：无合规证据
  被问「处置了多少、留痕在哪」时拿不出来 → 监管风险

对治：
□ 闭环：处置 → 申诉 → 复核 → 留痕 全打通
□ 看板：举报/处置积压可视化，时效 SLA
□ 护栏：AI 处置设「误删阈值」，人工抽查
□ 审计：规则-动作映射表 + append-only 日志