O4.08.2Reporter feedback loop设计
处理结果需反馈给举报者
别名: 举报反馈 · case status notification · reporting loop
概念解释
处理结果的反馈闭环决定举报系统的长期健康：举报者收到「已处理或未处理」的通知与理由摘要，才会继续举报；石沉大海的举报教会用户「举报没用」，真实举报率随之下滑，系统里只剩下恶意举报。反馈不是礼貌，是举报系统自我维持的燃料。
机制
反馈有三个功能：维持举报动机（行为被看见）、校准举报预期（什么会被告受理）、建立程序公正感。程序公正研究的结论在这里直接适用：人们对不利结果的接受度主要取决于过程是否被公正对待——给出理由的拒绝好过无理由的沉默。工程约束来自安全：通知举报者「内容已删除」等于向恶意举报者泄露对方被处理，可被用于定向攻击；所以反馈分两级——结果通知（受理/未受理/需补充）给举报者，处置细节（对方受何处罚）不给。反馈的时效结构同样重要：复杂案件处理周期以周计，阶段性状态（已受理→核查中→已办结）比一次性终局更维持信任。反馈不可伪造：自动回复「已收到，会认真处理」之后无声无息，比不回复更伤——通知状态必须与真实处理状态绑定。
边界
反馈的上界是不暴露处置细节：处罚内容（封禁时长、扣分）属于被处置者的隐私，举报者的知情到「平台已采取措施」为止。极端量级下逐条反馈有成本：日举报百万级的平台用分级方案——明确类别即时反馈、复杂案件状态跟踪，放弃的是「人人同等颗粒度」而不是「有人没有反馈」。反馈措辞本身可被滥用：理由摘要若写成模板化官话，公正感不升反降——理由要针对案件类别具体化。
怎么落地
- 举报单状态机化：已受理/核查中/已办结/需补充四态与通知系统绑定，状态变更即通知，禁止「提交后无回音」。
- 反馈内容三级：结果（受理与否）、理由摘要（类别不符/证据不足等针对性理由）、后续动作（如何补充材料、如何申诉）。
- 验证：反馈闭环上线前后对比举报者回访调查的「再次举报意愿」与「认为处理公正」比例；同时监控剔除恶意举报后的真实举报量——闭环有效应表现为上升。