人审慢！机审贵又差！我做了一套能降本增效的内容审核系统

在之前公司的时候，我被调到另外一个项目组，负责一个刚上线的社交项目。 在熟悉项目、体验功能的过程中，我发现了一个比较严重的问题：项目里的朋友圈功能体验非常差。

当时我随手发一条动态，竟然要等好几分钟才能展示出来。 对于社交类产品来说，这几乎是致命的。做过产品的都知道，圈子/动态是用户活跃度的核心指标，这种体验会大大降低用户的留存。

我去找老板聊了下，才知道问题出在审核机制上：

• 项目刚上线时，只有2个客服负责所有审核，包括头像、昵称、朋友圈动态等。

• 审核时间只到下班，晚上没人审核。

• 但偏偏，晚上才是用户最活跃的时间段。

很显然，这样的体验非常不友好。 于是我提了一个改进方案：引入轮班制。

• 每班2个客服，同时负责审核头像、昵称、圈子内容；

• 一班从早上到下午；

• 另一班从下午到晚上12点，并且允许居家审核。

轮班制上线后，朋友圈的审核延迟问题明显改善，用户体验提升非常大。

随着老板不要命地烧钱买量、打广告，用户就像潮水一样涌进来。 朋友圈的发布量、评论量、私信量一夜之间翻了几倍，审核压力瞬间爆表。

虽然我们已经在轮班制的基础上加派了客服人手，但依旧完全跟不上节奏。 总不能要求客服“1 秒 10 审核” ，这显然不太现实。

更麻烦的是，随着监管越来越严格，我们不得不接入机器审核。于是上线了数美天网的机审服务，但很快就踩了坑：

1）成本高得吓人——每一条内容调用机审都要钱，用户量一上来，费用飙得飞快。

2）误判不少——正常的内容也会被误伤。比如“恐龙”被判成涉恐，“黄子韬”被判成涉黄，用户投诉直接爆。

3）不减反增——本来机审是为了减轻人工压力，结果误判太多，反而让客服需要二次处理，工作量不降反升。

老板看到账单后直接拍板：

我们也去和合作方谈，希望拿到点大客户折扣。结果对方很淡定：

至于误判问题，对方轻描淡写地说：“你们多调调模型阈值就行。”

但我们都懂，这根本不是一时半会能解决的。

于是我们就陷入了一个死循环：

• 全靠机审 → 成本爆炸，还带来一堆客诉；

• 全靠人工 → 人手不够，效率跟不上；

• 审核标准 → 又不可能降低，毕竟监管要求越来越严。

老板又不愿意加客服，只剩下一条路：

用技术来破局，既要省钱，又要保证体验和准确性。

所以我们只能从技术手段上想办法： 既要降低机审调用量，节省成本， 又要保证用户体验和敏感词拦截的准确性。

前面聊到的几个问题，其实归结起来就是：

• 人工审核不够用

• 机审成本太高

• 误判导致客诉增加，客服还要二次处理

• 老板要求降本增效，但不能影响用户体验

基于这些现状，我们重新审视了整个内容审核体系，最终梳理出以下几个核心目标：

1）降低机审调用量—— 尽量把能本地拦截的都拦截掉，只在必要时才调用机审。

2）保证用户体验—— 内容审核要快，朋友圈/评论必须秒级展示，不能再出现“发条动态等好几分钟”的情况。

3）减少误判带来的客 —— 允许后台随时加白/加黑，策略能快速调整，避免一错再错。

4）动态可控—— 敏感词库支持实时更新，Redis Pub/Sub 秒级生效，保证新策略能立刻落地。

5）成本可控—— 第三方机审作为兜底，而不是主力，保证整体审核成本可控。

最开始，我们发现如果每一条用户内容都直接丢给机审平台（比如数美、天网），成本会非常高，而且很多敏感词本身是高度确定的，根本不需要调用机审。比如涉黄、涉政、涉恐、赌博、广告等，这些词没有争议，一旦出现就是必拦。

所以第一步，我们决定先建立一套自己的本地黑名单体系。自己先维护一份“核心高危敏感词库”，把确定要拦截的词都本地化存储并匹配，做到本地优先拦截，减少外部机审调用。我们设计了一张专门的敏感词表 api_sensitive_words，表结构大概如下：

CREATE TABLE `api_sensitive_words` (    `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增ID',    `keyword` VARCHAR(255) NOT NULL COMMENT '敏感词',    `type` ENUM('BLACK','WHITE','NORMAL') DEFAULT 'NORMAL' COMMENT '类型: 黑名单/白名单/普通',    `category` ENUM('PORN','POLITICS','TERROR','AD','INSULT','OTHER') DEFAULT 'OTHER' COMMENT '分类: 色情/涉政/涉恐/广告/辱骂等',    `source` ENUM('HUMAN','VENDOR','AUDIT') DEFAULT 'HUMAN' COMMENT '来源: 人工录入/机审回流/客服审核回流',    `status` TINYINT(1) DEFAULT 1 COMMENT '状态: 1启用 0停用',    `hit_count` BIGINT DEFAULT 0 COMMENT '命中次数(统计用)',    `updated_by` VARCHAR(64) DEFAULT NULL COMMENT '最后操作人',    `updated_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '最后更新时间',    PRIMARY KEY (`id`),    KEY `idx_keyword` (`keyword`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='敏感词表';

• keyword需要建索引，因为 Trie 初始化和后台搜索都依赖它。

• type预留三种：

• BLACK → 必拦词

• WHITE → 误判词，机审命中但人工确认是正常的

• NORMAL → 低风险词，比如“红包”“裸聊”这种，看业务需求决定是否提示或拦截

• category用于统计和调优，比如我们可以知道涉黄类词汇占比多少，优化策略时更有针对性。

• source标记词的来源：

• 人工运营导入的

• 机审平台回流的

• 客服审核回流的 这样可以后续做精准策略，比如只清理机审回流的低置信度词

• hit_count统计命中次数，用于评估词的“热度”，如果命中率很低可能考虑降级或移除。

这样设计的好处是：

• 后台可以灵活维护词库，客服、运营、算法、机审回流的数据都能统一管理；

• 本地维护的“必拦词”能直接走 Trie 匹配，不用浪费一次外部机审请求；

• 后续可以在此基础上继续扩展“白名单”“热更新”“误判回流”能力。

这一部分做好了，就相当于为整个敏感词体系打下了地基。

建立了自己的黑名单体系后，接下来就遇到了一个问题：怎么高效地做敏感词匹配？ 我们有了 api_sensitive_words 表，里面可能会有几万甚至几十万条敏感词，如果每次用户发朋友圈、评论、昵称、签名都要去查数据库，那基本上等于自杀。

我们最开始考虑过直接用 MySQL，比如这样：

SELECT keyword FROM api_sensitive_words WHERE INSTR(:content, keyword) > 0;

或者用 LIKE：

SELECT keyword FROM api_sensitive_words WHERE :content LIKE CONCAT('%', keyword, '%');

这种做法有几个致命问题：

1）性能差 一旦词库过万，SQL 就会非常慢，LIKE 和 INSTR 都没法走索引。 如果并发上来，整个 DB 直接被拖垮。

2）匹配不全 比如用户发了“爆🍉新闻”，词库里是“爆料新闻”，MySQL 的匹配是基于字符串的，根本识别不出来。

3）更新不及时敏感词库经常在更新，每次都要走数据库，缓存起来又不方便做模糊匹配。

所以很快我们就放弃了这种方案。

有同事提出过用 「Elasticsearch」 做全文检索来解决匹配效率问题。 理论上，ES 的倒排索引确实比 MySQL 快很多，但我们分析后觉得并不合适：

• 部署和运维成本高引入 ES 就意味着多一套集群、多一套运维，单独维护压力大。

• 场景不适配我们只是做“是否包含敏感词”的二值判断，不需要复杂的相关性计算。

• 依旧难搞谐音和模糊匹配 ES 虽然有拼音分词器，但实现复杂，而且更新敏感词库的延迟依然存在。

所以 ES 对我们来说有点“杀鸡用牛刀”，最后也被否掉了。

最终我们选择了基于Trie 树 + Aho-Corasick 自动机的方案。

1）Trie 树的优势

• Trie 是一棵“前缀树”，非常适合敏感词这种「固定词库 + 高频匹配」的场景。

• 词库更新后只需重新构建 Trie，一次加载到内存即可。

• 匹配效率高，时间复杂度是 O(文本长度)，跟词库大小几乎无关。

2）Aho-Corasick（AC 自动机）的增强

如果只用 Trie，匹配效率还行，但每次遇到不匹配字符时需要回溯，性能会有瓶颈。 AC 自动机在 Trie 的基础上引入了“失败指针”，让匹配可以“平移”而不是回溯，效率更高。 这样即便有几万条敏感词，也能在毫秒级完成匹配。

3）为什么比 MySQL 和 ES 更合适

• 全量内存匹配 → 无需查库

• 支持模糊匹配 → 可以针对同音字、变体词做归一化，比如“黄赌毒”、“黄🌸毒”都能识别

• 支持秒级热更新 → 后台改了词库，Trie 直接重建，几秒内所有应用生效

• 低成本高性能 → 既避免了机审全量调用，又不需要引入额外的 ES 集群

我们对比了 MySQL、ES 和 Trie + AC 自动机的业务场景区别，最终我们选择了基于 Trie 树 + Aho-Corasick 自动机 的方案。

接下来，我们就简单实现，构建一套高性能、低延迟、可动态更新的敏感词审核体系，确保在海量用户请求下也能稳定高效地工作。

核心架构围绕MySQL 持久存储 + Redis 缓存 + Go 内存引擎 + 秒级热更新 + 机审兜底：     

┌────────────────────────┐             │   api_sensitive_words   │ ← MySQL 持久存储敏感词             └──────────┬─────────────┘                        │             后台管理系统增删改词                        │             ┌──────────▼─────────────┐             │       Redis缓存         │ ← 存储最新词表             └──────────┬─────────────┘                        │           Redis 发布订阅 (sensitive:update)                        │             ┌──────────▼─────────────┐             │   Go 服务内存中的 Trie │             │ + Aho-Corasick 自动机   │             └──────────┬─────────────┘                        │       用户请求 → 本地匹配          │ 命中                   │ 未命中          ▼                        ▼     拦截 / 标记 / 上报       调用第三方机审

1）核心思路

• MySQL — 敏感词的最终存储所有敏感词、黑名单、白名单的权威数据源，保证数据完整性与可追溯性。

• Redis — 高速缓存层缓存最新的敏感词表，避免频繁查 MySQL，支撑高并发低延迟。

• Trie + AC 自动机 — 高性能内存匹配引擎在 Go 内存中一次性加载所有敏感词，基于 Trie 构建 Aho-Corasick 自动机，实现 「O(文本长度)」 的高效匹配。 同时支持模糊匹配、黑白名单、归一化处理（“黄赌毒”、“黄🌸毒”都能识别）。

• 后台管理系统 — 人工可控提供增删改词、添加黑白名单、风险词分类等操作，变更后立即推送到 Redis，通过发布订阅机制触发内存引擎自动热更新。

• 秒级热更新机制当后台修改敏感词时，会向 Redis 发布一个 sensitive:update 事件，Go 服务订阅该事件后会立即重建 Trie + AC 自动机，整个过程通常在 「100ms~1s」 内完成。

• 机审兜底 — 降低成本对于内存引擎未命中的文本，请求会进入第三方机审（如数美天网）。 这样大幅降低了机审的调用量和成本，同时仍然保留了机审对复杂文本、图片、视频的检测能力。

2）这样设计的效果总结

• 高性能 → 绝大多数请求走本地内存匹配，毫秒级返回结果

• 低成本 → 通过 Trie + AC 自动机拦截大部分敏感词，极少命中机审

• 高可控 → 黑白名单、误判复核、秒级热更新，运营可以灵活调整

• 高扩展性 → 后续可以无缝接入图片、视频机审，形成多模态内容安全体系

在这种架构下，用户在发朋友圈、评论、私信时，99% 的请求只需走内存匹配；只有极少数复杂或新型敏感词才会触发机审，既保证了性能，又有效控制了成本。

在完成了敏感词表设计和架构方案分析后，我们就需要落地一个高性能、可热更新的敏感词检测引擎。

核心目标是：

• 毫秒级检测 → 高频场景下用户无感

• 秒级热更新 → 后台改词立刻生效

• 机审兜底 → 未命中本地词库再调用机审，降低成本

1）设计思路

我们在设计这套敏感词检测引擎时，有几个关键考量：

①词库加载策略

• 所有敏感词存 MySQL，启动时全量加载到内存

• 后台变更敏感词 → 写 MySQL → 写 Redis → Redis 发布更新通知

• Go 服务收到通知 → 重新构建 Trie + AC 自动机 → 秒级热更新

②检测流程

• 用户请求 → 本地内存检测

• 命中 → 返回结果 & 上报

• 未命中 → 走第三方机审

③高并发优化

• 敏感词检测走内存，无需查库

• Trie + AC 自动机构建在启动时一次性完成

• AC 匹配是单次扫描，复杂度 O(N)，无论几万词都能控制在毫秒级

这样，99% 的请求在 Go 内存中毫秒级返回，只对剩余 1% 的高风险内容调用机审。

2）代码实现：Go + Trie + AC 自动机 + Redis 热更新

这一节我们落地完整方案，做三件事：

• 敏感词本地检测 → Trie + AC 自动机，毫秒级匹配

• Redis 热更新 → 后台改词 → 发布事件 → 内存引擎秒级重建

• 未命中兜底调用机审 → 降低调用量 + 保证高风险内容兜底拦截。

我们来实现一个非常简单的demo示例。

①敏感词检测引擎（ACTrie.go）

用 Trie + Aho-Corasick 自动机实现，支持并发检测 + 秒级热更新。

package trieimport (    "container/list"    "sync")type TrieNode struct {    children map[rune]*TrieNode    fail     *TrieNode    isEnd    bool    word     string}type ACTrie struct {    root *TrieNode    mu   sync.RWMutex}funcNewACTrie() *ACTrie {    return &ACTrie{        root: &TrieNode{children: make(map[rune]*TrieNode)},    }}// 构建 Trie 树 + AC 自动机func(ac *ACTrie) Build(words []string) {    ac.mu.Lock()    defer ac.mu.Unlock()    // 重新初始化    ac.root = &TrieNode{children: make(map[rune]*TrieNode)}    // 构建 Trie    for _, word := range words {        node := ac.root        for _, ch := range []rune(word) {            if node.children[ch] == nil {                node.children[ch] = &TrieNode{children: make(map[rune]*TrieNode)}            }            node = node.children[ch]        }        node.isEnd = true        node.word = word    }    // 构建 AC 自动机失败指针    ac.buildFailPointers()}func(ac *ACTrie) buildFailPointers() {    queue := list.New()    for _, node := range ac.root.children {        node.fail = ac.root        queue.PushBack(node)    }    for queue.Len() > 0 {        e := queue.Front()        queue.Remove(e)        current := e.Value.(*TrieNode)        for ch, child := range current.children {            failNode := current.fail            for failNode != nil && failNode.children[ch] == nil {                failNode = failNode.fail            }            if failNode == nil {                child.fail = ac.root            } else {                child.fail = failNode.children[ch]            }            queue.PushBack(child)        }    }}// 匹配文本func(ac *ACTrie) Match(text string) []string {    ac.mu.RLock()    defer ac.mu.RUnlock()    var result []string    node := ac.root    for _, ch := range []rune(text) {        for node != ac.root && node.children[ch] == nil {            node = node.fail        }        if node.children[ch] != nil {            node = node.children[ch]        }        // 收集所有可能的命中        temp := node        for temp != ac.root {            if temp.isEnd {                result = append(result, temp.word)            }            temp = temp.fail        }    }    return result}

② Redis 热更新 + 检测逻辑（service.go）

后台添加/删除敏感词 → 发布 sensitive:update → 内存 Trie 自动重建。

package serviceimport (    "context"    "log"    "time"    "sensitive/trie"    "github.com/redis/go-redis/v9")// 从 Redis 拉取最新词库funcfetchWordsFromRedis(rdb *redis.Client) []string {    ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)    defer cancel()    words, err := rdb.SMembers(ctx, "sensitive:words").Result()    if err != nil {        log.Println("获取敏感词失败:", err)        return nil    }    return words}// 监听热更新funcListenUpdate(ac *trie.ACTrie, rdb *redis.Client) {    sub := rdb.Subscribe(context.Background(), "sensitive:update")    for msg := range sub.Channel() {        log.Println("接收到词库更新事件:", msg.Payload)        words := fetchWordsFromRedis(rdb)        ac.Build(words)        log.Println("Trie + AC 引擎已完成热更新")    }}

③兜底调用第三方机审（audit.go）

这里我们实现 callVendorAudit 方法，模拟调用第三方机审平台（例如数美、天网），并支持异步回调。package serviceimport (    "bytes"    "encoding/json"    "io/ioutil"    "log"    "net/http")type VendorAuditRequest struct {    Text string `json:"text"`    UserID int  `json:"user_id"`}type VendorAuditResponse struct {    Code    int    `json:"code"`    Message string `json:"message"`    Risk    bool   `json:"risk"`}// 兜底调用第三方机审funccallVendorAudit(text string, userID int) (bool, error) {    payload := VendorAuditRequest{        Text:   text,        UserID: userID,    }    body, _ := json.Marshal(payload)    resp, err := http.Post("https://vendor.example.com/audit", "application/json", bytes.NewReader(body))    if err != nil {        log.Println("调用机审失败:", err)        return false, err    }    defer resp.Body.Close()    data, _ := ioutil.ReadAll(resp.Body)    var result VendorAuditResponse    if err := json.Unmarshal(data, &result); err != nil {        log.Println("解析机审响应失败:", err)        return false, err    }    return result.Risk, nil}

④敏感词检测入口

funcCheckContent(ac *trie.ACTrie, text string, userID int) (bool, []string) {    matches := ac.Match(text)    if len(matches) > 0 {        // 本地命中敏感词，直接拦截        return true, matches    }    // 本地未命中 → 调用第三方机审    risk, err := callVendorAudit(text, userID)    if err != nil {        log.Println("调用机审异常:", err)        return false, nil    }    // 如果机审返回高风险 → 拦截    if risk {        return true, []string{"[机审命中]"}    }    // 否则允许通过    return false, nil}

我们这样设计思路

• 为什么本地检测优先？

内存中 Trie + AC 自动机 → 「毫秒级响应」

机审 QPS 成本高且延迟大，本地检测可拦截绝大多数内容

• 为什么机审兜底？

有些谐音、变体、图文混排等复杂场景，本地 Trie 难以覆盖

我们不放弃机审，而是“只用在必要场景”，降低调用量

• 为什么热更新用 Redis 发布订阅？

后台添加/删除敏感词 → 发布更新事件

Go 服务感知 → 重建 AC 引擎，秒级生效

在上线基于 Trie + AC 自动机的本地高性能检测引擎后，我们在未命中的情况下会调用第三方机审（例如数美、天网）兜底拦截。

但是很快，我们遇到了一个新的问题：机审的误判率偏高。

一开始，我们和数美平台的同学沟通过，他们建议我们在数美后台调整模型阈值，并多喂数据让平台模型更适应我们的业务。但实践证明：

1）模型调优需要时间

数美的后台虽然可以微调大模型，但这通常需要几周甚至几个月，短期内无法解决。

2）误判直接影响用户体验

大量正常用户的评论、昵称、动态会被错误拦截，造成投诉率上升。

3）过度依赖机审，成本偏高

即便我们用Trie + AC 自动机拦了一部分，剩下的“边缘内容”仍然大量送到机审，每次都要消耗调用额度，且返回的结果未必可靠。

所以我们决定引入一层机审回流机制：

机审命中的内容不再直接信任，而是进入我们的本地回流队列，由运营/算法标注后再落地到敏感词库或白名单。

这样，我们既降低了机审误杀用户的风险，又能持续“喂养”我们自己的本地引擎，让检测效果越来越精准。

整个机审回流机制的核心是“引入人工二次确认”：

1）用户发内容 → 本地 Trie + AC 检测；

2）如果命中敏感词 → 直接拦截，无需机审；

3）如果未命中 → 调用第三方机审；

4）根据机审返回的状态：

• PASS→ 暂时放行，但如果机审返回了疑似高风险候选词，写入候选表，供客服确认；

• REVIEW → 机器认为可疑，直接写入候选表，由人工复核；

• REJECT → 机器判定违规，直接拦截，但仍写入候选表等待人工确认；

5）后台运营审核候选表，确认结果后：

• 如果确认违规 → 加入黑名单，Trie 热更新；

• 如果确认误判 → 加入白名单，避免重复拦截。

以数美为例，常见返回状态有三种：

这种分级机制让我们在业务层面更加灵活，既不盲目信任机审，又不会因为误判直接影响用户。

我们新增了api_sensitive_candidates 表，用来记录第三方机审命中的可疑词：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineCREATE TABLE `api_sensitive_candidates` (    `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,    `keyword` VARCHAR(255) NOT NULL COMMENT '候选敏感词',    `vendor` VARCHAR(64) DEFAULT NULL COMMENT '机审来源，例如数美、天网',    `risk_level` TINYINT DEFAULT 1 COMMENT '1低风险 2中风险 3高风险',    `status` ENUM('PENDING','CONFIRMED','REJECTED') DEFAULT 'PENDING' COMMENT '状态',    `created_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP,    PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='机审候选敏感词';

• PENDING → 默认状态，待运营人工审核

• CONFIRMED → 确认违规，加入黑名单，Trie 热更新

• REJECTED → 确认误判，加入白名单，避免误拦

funcauditContent(userID int64, content string) (bool, error) {    // 1. 先走本地 Trie + AC 自动机    if acEngine.Match(content) {        return false, errors.New("命中本地敏感词，拦截")    }    // 2. 调用第三方机审    resp, err := callShumeiAPI(content)    if err != nil {        log.Printf("[ERROR] 调用机审失败: %v", err)        return true, nil // 容错策略：机审挂了就先放行    }    switch resp.RiskLevel {    case "PASS":        // 暂时放行，但写入候选表供人工复核        saveCandidates(resp.HitWords, "数美", 1)        return true, nil    case "REVIEW":        // 写入候选表，等待客服确认        saveCandidates(resp.HitWords, "数美", 2)        return false, errors.New("内容可疑，等待人工复核")    case "REJECT":        // 直接拦截，同时写入候选表        saveCandidates(resp.HitWords, "数美", 3)        return false, errors.New("内容违规，已拦截")    default:        return true, nil    }}funcsaveCandidates(words []string, vendor string, risk int) {    for _, word := range words {        _, err := db.Exec(`            INSERT INTO api_sensitive_candidates (keyword, vendor, risk_level)            VALUES (?, ?, ?)        `, word, vendor, risk)        if err != nil {            log.Printf("[WARN] 保存候选词失败: %v", err)        }    }}

• 减少误判 → 不盲目信任机审，用户体验更好

• 词库自动进化 → 命中新词可回流，Trie 引擎实时热更新

• 降低成本 → 随着词库完善，机审调用量显著下降

• 可控性更强 → 运营、算法可以在后台快速干预

在引入机审回流机制之后，我们的敏感词检测体系已经形成了一个“人机协同”的闭环：

• 本地Trie + AC 自动机 → 毫秒级检测

• 机审兜底 → 保证高风险内容不漏网

• 机审回流 → 候选词进入二次审核，减少误判

但是，光靠人工去不断确认候选词，仍然有几个问题：

1）人工压力依然存在

机审每天可能返回上千条候选词，如果全部依赖客服逐条确认，工作量依然巨大。

2）词库维护效率不高

敏感词的热词更新非常快，比如某些热点事件、网络流行词，一旦被用户恶意利用，如果没有及时补充到词库，就会产生“窗口期”。

3）重复误判问题

某些词一旦被误判，如果没有白名单兜底，可能会反复影响不同用户。

所以我们在第四步的基础上，进一步做了一个 「智能化词库演进机制」，让系统能“越用越准”。

我们把候选词的流转分成三个阶段：

1）机审 → 候选词表

第三方机审命中的内容不直接生效，而是进入 api_sensitive_candidates。

2）二次确认 → 黑白名单

人工确认违规 → 写入黑名单，进入 api_sensitive_words 表；

人工确认误判 → 写入白名单，避免后续重复拦截。

3）自动学习 → 热更新引擎

黑名单 / 白名单更新后 → Redis 发布 sensitive:update → Go 内存引擎秒级热更新；

下次用户再发同类内容时，系统直接在本地完成判定，无需机审。

在第四步中，我们有两个关键表：

1）机审候选敏感词表（待审核池）

CREATE TABLE `api_sensitive_candidates` (    `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,    `keyword` VARCHAR(255) NOT NULL,    `vendor` VARCHAR(64) DEFAULT NULL COMMENT '机审来源',    `risk_level` TINYINT DEFAULT 1 COMMENT '1低风险 2中风险 3高风险',    `status` ENUM('PENDING','CONFIRMED','REJECTED') DEFAULT 'PENDING',    `created_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP,    PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='机审候选敏感词';

2）敏感词主表（黑名单 / 白名单）

CREATE TABLE `api_sensitive_words` (    `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,    `keyword` VARCHAR(255) NOT NULL,    `type` ENUM('BLACK','WHITE','NORMAL') DEFAULT 'NORMAL' COMMENT '黑名单/白名单/普通',    `category` enum('PORN','POLITICS','TERROR','AD','INSULT','OTHER') DEFAULT 'OTHER' COMMENT '分类',    `source` enum('HUMAN','VENDOR','AUDIT') DEFAULT 'HUMAN' COMMENT '来源: 人工/机审/审核回流',    `status` TINYINT(1) DEFAULT 1 COMMENT '1=启用 0=停用',    `hit_count` bigint(20) DEFAULT '0' COMMENT '命中次数',    `updated_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,    PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='敏感词表';

在人工复核的基础上，我们还做了几层优化：

1）高频候选词自动标记

如果某个词连续多次出现在 api_sensitive_candidates，即使还没人工确认，也可以先标记为“高优先级”，提醒运营重点关注。

2）白名单优先级

如果某个词已被确认进入白名单，即使机审再次判定为违规，也会优先放行，避免反复误判。

3）规则兜底

对于某些常见的变体（比如 Emoji、拼音替代），我们在检测层加了一层归一化处理，让“黄🌸毒”这种形式也能被映射到“黄赌毒”。

经过这一层机制迭代，我们的系统表现明显改善：

1）机审调用量下降 70%+

因为更多的新词被回流到本地引擎，减少了依赖机审。

2）误判率降低到 <1%

白名单机制避免了大规模误拦，用户体验显著提升。

3）客服压力减少 50%

只有真正疑难的词才需要人工二次确认，重复问题被系统自动兜底。

4）系统自我进化

每次机审命中 → 候选池 → 人工确认 → 黑白名单 → 热更新 → 下次直接拦截 / 放行，形成闭环。

做到这一步，我们的敏感词检测体系从纯人工 → 机审兜底 → 回流机制 → 智能演进，形成了一条完整的进化链路。

可以说，这时候的系统已经具备了简单的自我学习、自我修复的能力。

按照我们上面的流程，如果用户的内容在本地敏感词库和黑名单里都没命中，那下一步就会走机审服务去做二次校验。

但这时候可能就会有同学疑问了：“那我正常内容基本都不会被拦截，是不是就等于所有正常内容都要再过一遍机审？正常内容量那么大，本地黑名单和敏感词库不就成了摆设？这样成本不还是一样很高吗？”

其实不是的哈，我们不是“没命中词库就一股脑全发给机审”。

大部分内容，如果本地的敏感词库和黑名单都没命中，系统会默认它是“正常的”，直接放行，根本不会走机审。

那哪些内容会走机审呢？我们设了一套机制来识别“可疑内容”。不是靠人工，而是靠程序根据几个维度来自动打分的，如下图：

上面的风险因子模型这里我大概解释下：

用户想发违规词，但又不想被系统拦，就开始搞各种变种：

• 加空格：“黄 毒”

• 加表情把词拆开：“黄🌸毒”

• 拼音发音替代：“huangdu”

• 字母和数字混用：“黄d毒”

这些写法本身可能不是黑名单词，但看上去就是故意绕规则的，所以会加分。

如果一条内容里出现了外部联系方式或引流信息，我们会直接加高风险分，因为这类内容通常和广告、灰产、甚至非法交易有关。

常见表现有：

• 带网址或短链链接，比如：“www.xxx.com”、“t.cn/xxxx”

• 留微信、QQ、手机号：比如“加我VX：abc123” 或者 “QQ：123456”

• 描述二维码或加群：比如“扫码进群”、“进群看资源”、“VX联系我”

还有一些更隐蔽的写法：

• 比如“加我微⚪️信”，或者用 emoji 表示数字：“VX：1⃣️2⃣️3⃣️4⃣️5⃣️”
• 把联系方式拆成一句一句发：“先加这个VX，一二三，四五六...”

这些内容虽然不一定包含敏感词，但一看就知道是“在绕规则”引导你加好友或者跳出平台。所以即使它没命中黑词，本地打分也会高，后续一定要再机审一遍，防止放漏。

哪怕没完全命中黑词，但“像”也得引起注意：

• 少了一个字或改了拼音：“黄堵毒”、“huang du”

• 同音字或相似字：“黄嘟毒”

我们会比对编辑距离、拼音等，如果太接近，也会加分。

同样一句话，出现在不同地方，影响也不一样：

• 发在评论区，问题不算太大

• 发在昵称、群名、私信里，就隐蔽多了

• 特殊时段（比如深夜、活动期）也会加分

原因很简单：越隐蔽的地方，违规后果越严重，所以风险分就高一点。

除了看内容，我们还会看是谁发的、怎么发的。现在搞违规的很多都是灰产，一人控制上百个账号轮流发，这种操作靠内容本身很难识别，但行为上一定不正常。

我们会重点加分这些情况：

• 新注册账号：刚注册就发内容、发评论，系统默认风险更高。

• 最近频繁被拦截：说明这个账号老想“钻空子”，系统会自动打上“风险标签”。

• 同一个 IP 换着账号不停发：比如短时间发几十条、每条换个号，看着像在“刷屏”。

• 异常加速：正常人怎么可能“2 秒发 5 条”？要么复制粘贴、要么脚本自动发。

这些行为我们统称为 “批量操作”，背后常见的是：

• 灰产公司搞的“群控设备”，几十台手机连一台电脑操作；

• 自动发广告、导流、刷粉、刷评论；

• 甚至用来测试绕过我们的内容安全机制。

我们会根据这些行为给账号打“风险分”，如果高，就会配合内容一起决定要不要送去机审兜底。

如果内容和以前我们记录的垃圾信息很像，比如：

• VX秒回，进群看福利，真实资源，永久有效

这种内容多半是“复制粘贴发模板”，会直接打上批量标签，加分。

我们是这样决定“走不走机审”的：

• 分数低于 T1，系统直接放行，不送机审（绝大多数正常内容都在这）

• 分数在 T1 到 T2 之间，送一遍机审兜底一下

• 分数高于 T2，直接拦截或进人工复核

每个场景的 T1/T2 也可以独立配置，比如评论区放宽一点，私信就收紧；新账号要求更高。

另外我们也不会完全信任程序判断，系统里还做了两道补充机制：

1）人工随机抽查：比如每隔一段时间，运营同学会从正常放行的内容里，抽一批出来人工看看，确认有没有“漏网之鱼”。

2）用户举报通道：一旦有用户点了“举报”，我们会触发人工审核，并把结果反推给模型，还会给积极举报的用户发奖励积分。

这样双保险兜底，既防止系统“看不到的盲区”，又让用户参与进来，越来越精准。

总的来说，结合我们前面讲的这些流程和规则，其实这套内容安全系统跑起来之后，有几个很直接的好处：

一是大部分正常内容，压根不会进入机审流程。本地检测机制本身就是为了拦住绝大多数无风险的内容，直接放行，减少不必要的审核开销。

二是风险打分的作用就是“筛可疑”，不是谁都送去机审，只有那些带明显特征、风险比较高的内容，才会进一步校验。这部分内容本身就值得多花一点成本，避免漏掉关键问题。

三是后续的机审结果也不是丢掉就完了，我们会做回流，把命中的典型样本或词语更新进本地词库或规则配置，系统用得越久、识别能力也就越强。

整体看下来，我们这套机制的重点就是：本地为主，机审兜底，规则可控。既能压住整体成本，又不牺牲检测效果，适合长期稳定跑在线上。

至于“风险打分”规则本身，是怎么来的？其实都是我们平时不断复盘“漏网之鱼”来的。一旦发现系统没拦住的违规内容，我们就会反过来分析为什么没识别出来，把这些特征总结出来，慢慢沉淀进风险配置里，系统就是这样一点点被打磨出来的。

回头看这套敏感词检测，基本就是一路“打补丁 → 优化 → 再进化”的过程：

一开始，全靠人工盯，效率低不说，用户体验还特别差；

后来上了 Trie + AC 自动机，本地内存里就能解决大部分情况；

再后来，为了防止遗漏，就接了机审兜底；

但机审的误判实在多，于是加了回流机制，让客服二次确认，把结果再喂回系统。

整条链路其实就一句话：

“能自己搞定的就自己搞定，搞不定的交给机审，机审再回流回来让自己更聪明。”

• 快：用户发评论、朋友圈、聊天消息，检测全在内存里走，几乎是秒回。

• 省钱：以前所有请求都丢机审，花钱像流水；现在绝大多数在本地解决，机审调用量直接砍掉一大半。

• 准：有了回流机制，误判能拉白，新违规词能拉黑，检测效果越来越准。

• 灵活：后台一加黑/加白，Redis 一推送，所有服务立刻热更新，不用重启。

这套机制并不是只能用在评论和朋友圈。

像用户昵称、群聊名字、私信聊天都能走同样流程。

再往后拓展，图片可以先 OCR 把文字识别出来，视频可以先转语音文本，然后也能丢进检测引擎里。

甚至还能做风险分级：比如评论可以稍微宽松点，私信要严格点。

或者智能提示：某些候选词老是出现，就自动标记高优先级，提醒运营重点盯一下。

说实话，如果单看业务需求，靠人工 + 机审也能凑合把内容审核跑起来。

但身为技术，我们需要考虑的不光是能不能用，还要考虑能不能撑得住规模、能不能压下成本。

人工再加人就是烧钱，机审再开额度也是烧钱，最后账一算，公司运营成本根本顶不住。

所以我们才决定用技术来改造这一块：把能在本地搞定的尽量留在本地，把复杂的丢给机审兜底，再通过回流机制让系统自己进化。这样做下来，不光用户体验提升了，公司在成本上也真正省下了一大块。

回头看，这套内容安全体系已经不只是一个“审核工具”，而是一个能跟着业务规模一起成长的系统。它能抗住流量高峰，也能帮公司省钱，更重要的是，它让我切身感受到——用技术解决问题，能直接改变运营成本。