UGC 内容审核的 AIGC 初筛方案

放在审核链路的哪一步

最常见的错误是把它当成「自动拦截器」放在提交链路上。检测是概率判断，必然有误判， 而提交链路是同步的——一旦检测服务抖动或误判，用户侧看到的就是发帖失败。合理的摆法是异步、旁路、只做排序：

1. 01内容正常入库，用户侧立即成功。此时还没有任何检测结果，不要因此阻塞。
2. 02异步任务取内容做检测，把置信度、分段结果与 task_id 回写到内容记录。 失败重试即可，重试仍失败就当作「未检测」，不要当作「人工写作」。
3. 03人工审核队列按置信度倒序排列：高置信度的排在前面先看，而不是先被拦掉。 审核员的判断仍然是人做的，检测只改变「先看哪一条」。
4. 04对已发布内容，检测结果只用于推荐权重、是否加标识这类可逆动作； 删除、封号这类不可逆动作必须由人做出。

阈值分三档，不要分两档

只设一个阈值（比如 0.5）意味着把「模型没把握」和「模型很确信」混在一起处理。 实际运营中更稳的做法是三档，中间那档是缓冲区：

• 高置信度：加标识、降权、或优先送人工。可逆动作，错了能撤。
• 中间区间：不处置，只记录。这一档最容易踩坑——短文本、模板化文案、混合写作都落在这里， 强行判定就是在制造申诉。
• 低置信度：正常放行。不要因为「反正分数低也检测一下」就把它当成人工写作的证明—— 它只说明模型没看出机写特征。

阈值具体定在哪，取决于你更怕误判还是更怕漏判。活动公告、商品描述这类模板化文本占比高的 平台，阈值要往高调，否则人工队列会被误判淹没。

批量与并发的工程细节

• 单次批量有上限，超过要拆分。拆的时候按内容长度而不是条数切，长文几条就能占满额度。
• 并发不要一次打满：留出重试余量，遇到限流按指数退避，而不是原地重试。
• 结果落库时同时存内容哈希：同一内容再次提交时直接命中缓存，既省钱也保证同一内容两次判断一致。
• 保存 task_id 与原始返回 JSON。 事后要复盘某次判定时，只有分数没有原始返回，等于没有证据。

误判与申诉：先把证据留住

误判不是异常，是这类服务的固有属性。能控制的是误判发生之后能不能说清楚： 当时检测的是哪一版文本、什么时间、返回了什么。三样东西缺一不可——文本快照、task_id、原始返回。 只存一个分数，用户在三个月后申诉时你无法复现，也无法解释。

申诉流程本身建议写明三件事：检测结果是概率判断、不是事实认定；处置是可逆的、 复核后可以撤销；复核由人做。这三句话同时出现在用户协议与站内提示里， 比在客服话术里临时解释有效得多。

如果目的是合规标识

生成合成内容的标识要求，和「判定某段内容是不是 AI 写的」是两件事：前者要求 生成方主动声明，后者是事后推测。检测结果可以作为标识的辅助依据，但不能替代 生成方的声明义务。实际做法通常是双轨——能拿到生成方的声明或内容凭证就按声明处理， 拿不到再用检测结果做兜底标注，并在标注文案里保留「疑似」二字。

具体到接口怎么调、字段怎么读，见AI 文本检测 API与接口文档。