内容审核

第二个危机 🚨

解决了恶意 URL 跳转问题后，我松了一口气。

直到那个周二的下午，我接到一通电话：

“您好，我们是网信办工作人员。” “接到举报，您的短链接平台被用于传播违法违规内容。” “请立即整改，否则可能暂停服务。”

我脑子一片空白。

打开后台查看，果然有几个短链接被大量举报：

举报记录
────────────────────────────────────────
链接：k.yz/a8x3k  举报数：127  原因：色情内容
链接：k.yz/m9p2q  举报数：89   原因：赌博网站
链接：k.yz/r4t7w  举报数：64   原因：诈骗信息
────────────────────────────────────────

我点开其中一个，跳转到充斥着违规内容的页面。

恶意 URL 识别只解决了”链接去哪”的问题。但链接指向的内容，可能是违规的。

后果不堪设想：

• ❌ 监管处罚，甚至关停
• ❌ 用户流失，声誉受损
• ❌ 法律诉讼风险

我必须立刻行动。

---

方案调研

当晚，我开始调研内容审核方案。

方案一：自建审核系统

落地思路

• 自建方案的做法是维护关键词库和规则集：命中关键词、命中 URL 特征、命中黑名单的，都算高风险。
• 判定完全在本地做，不需要任何外部调用，所以能做到毫秒级响应、零调用成本。
• 命门在规则的可维护性：关键词库一多，匹配逻辑就容易出现漏判和误判，改起来牵一发动全身。
• 结论是准确率上不去：规则只能覆盖已知的表达方式，新词、新变体不断出现，维护成本远超收益。

优点：可控、成本低、毫秒级响应

缺点：准确率仅 70%，无法识别图片视频，易被谐音绕过

测试发现误判率高达 20%。自建方案，pass。

---

方案二：第三方 API

国内主要有阿里云和腾讯云内容安全。

落地思路

• 做法是把待审内容提交给第三方内容安全服务，拿回违规类型和置信度，按结果决定放行还是拦截。
• 它的价值在覆盖面：支持多种违规类型，还能识别图片和视频，这是自建规则做不到的。
• 代价是每次调用都有 300-500ms 的延迟和按量计费的成本，不能对每个请求都无脑调用。
• 兜底是服务不可用时的行为要提前定下来：本地规则顶上，不能把整个创建接口卡死。

优点：准确率 95%+，支持多种违规类型，能识别图片视频

缺点：成本高，延迟 300-500ms，依赖外部服务

测试对比：

但审核服务挂了怎么办？

---

方案三：混合方案（最终选择）⭐

本地规则 + 第三方 API + 人工审核

落地思路

• 分工是：本地规则先跑，明确安全的直接放行（这部分占 70%，省下相应的 API 费用），明确违规的直接拦截。
• 只有本地判不准的那部分才提交给第三方 API，再由第三方结果决定放行还是转人工。
• 本地规则这一层要接缓存：同一个目标 URL 的判定结果缓存一段时间，重复内容不用反复调 API。
• 兜底是第三方服务不可用时降级为「只信本地规则」，但要把这次降级记下来，事后能统计出受影响的量。

优势：

• 70% 请求本地完成，节省 70% 成本
• 毫秒级响应 + 缓存
• 服务不可用时降级
• 误判率<4%

---

异步审核实现

同步审核体验差，我采用分级异步审核：

• 高风险：同步拦截
• 中低风险：先允许，异步审核

落地思路

• 高风险在创建时同步拦截：命中色情、赌博、诈骗这类明确违规类型的，接口直接返回拒绝，不创建链接。
• 中低风险先创建、异步审核：链接先放出去可用，审核任务投进队列，消费端出结论后再决定是否下线。
• 异步结论有两种回写：确认违规就把链接状态改成禁用并让缓存失效，确认安全就只留一条审核记录。
• 兜底是队列积压要有预案：积压超过阈值就临时把中低风险也降级成同步审核，宁可慢一点也不能漏审。

---

人工审核队列

边界情况需要人工判断：

落地思路

• 进入人工队列的是「规则判不准」的那批：本地规则和第三方 API 的结论不一致，或者两边都只是疑似。
• 队列按违规类型和举报数排序，同一批内容里举报多的优先看。
• 审核动作对应下面的处理标准：色情/赌博/诈骗立即封禁，政治敏感封禁并上报，广告营销首次警告。
• 兜底是审核结论要回写：人工确认的结果同样要更新链接状态，并作为下一轮规则调整的依据。

审核标准：

---

合规建设

律师朋友给了几个建议：

1. 用户协议

### 禁止内容
不得创建指向色情、暴力、赌博、诈骗等内容的短链接。

### 违规处理
平台有权下架违规链接、封禁账号、上报相关部门。

2. 举报机制

落地思路

• 举报入口要显眼：短链接页面和被封禁提示页上都放举报入口，用户不需要另找客服。
• 举报时必须选一个原因分类（色情、赌博、诈骗、广告、侵权等），分类决定了后续的处理和上报路径。
• 同一短码的举报数要累加展示，达到阈值就自动转成一次检测任务，不用等人工逐条翻。
• 兜底是举报人也要能查到结果：处理完给一个明确的结论，申诉通道同时保留。

3. 数据留存

日志至少留存 6 个月，建立 7x24 小时应急响应。

---

效果

首月数据：

总链接：128,456
自动拦截：3,241 (2.5%)
人工审核：487 (0.38%)
准确率：96.2%
成本：¥7,347/月

再也没接到监管电话了。

---

新问题

我以为可以放心了，但监控又告警：

创建频率
──────────────────────────────
正常用户：5 次/小时
异常账户 A：1,247 次/小时 ❗
异常账户 B：892 次/小时 ❗
──────────────────────────────

有人用脚本批量创建短链接，消耗资源。

大量 API 调用让成本飙升，攻击者还可能用合法请求掩盖违规内容。

这是资源滥用攻击。

我需要防滥用机制。

但那是下一个故事了。

---

小结

方案演进

自建规则 → 准确率低
第三方 API → 成本高
混合方案 → 平衡

要点

✅ 多层防护：本地 + 第三方 + 人工

✅ 异步处理：高风险同步，中低风险异步

✅ 降级策略：服务不可用时保守处理

✅ 合规：用户协议、举报、数据留存

✅ 成本：节省 70% API 费用

待解决

⚠️ 资源滥用 ⚠️ 审核绕过 ⚠️ 成本压力

（下一节：防滥用机制）

上一章节

防滥用机制

下一章节

恶意网址识别