WeClaw_75｜L0 关键词闸门：<1ms 零 IO 的危机念头第一道防线

系列文章第 75 篇 - 深入 L0Gate 的纯内存判定引擎：三类词表、区间抵消、LRU 去重与 casefold 大小写折叠

📚 专栏信息

《从零到一构建跨平台 AI 助手：WeClaw 实战指南》专栏

本文是模块八【心理健康与危机守护】第 2 篇。上一篇（74）建立了 L0–L4 分层治理的全局认知，本篇深入第一道防线——L0 关键词闸门的内部实现：它如何在 <1ms 内、零磁盘 IO、零网络调用的前提下，从一条用户消息中捕获危机信号并决定是否"拉响警报"。

🧠 模块八【心理健康与危机守护】(9 篇)： 74 分层总览 / 75 L0 关键词闸门 / 76 L1-L2 双重确认 / 77 RiskLevel 全序 Bug / 78 危机资源零编造红线 / 79 词表校准 / 80 L4 监护人告警 / 81 伦理边界 / 82 校准测试框架

👨‍💻 作者与项目

作者简介：翁勇刚 WENG YONGGANG 新概念龙虾-WeClaw 开发团队负责人，一群专注于跨平台 AI 应用的实践者理念："再复杂的技术，也能用代码讲清楚"

💻 项目地址：https://github.com/wyg5208/weclaw.git
🌐 官网地址：https://weclaw.link
📝 作者 CSDN：https://blog.csdn.net/yweng18
⭐ 欢迎 Star⭐、Fork🍴、贡献代码🤝

⚠️ 本文涉及心理危机话题。如果你或身边的人正处于危机中，请立即联系专业资源（文末附经核验热线）。

📝 摘要

本文结构概览：本文从"L0 为什么必须 <1ms"的工程约束出发，逐层拆解 L0Gate 的判定流水线： HMAC-LRU 去重 → 预算/日上限熔断 → 显式求助短路 → 三类词表关键词命中（MOOD 区间抵消 + ESCALATION 独立评估）→ 连续负向节流触发。重点讲解 NEGATIVE_LOOKALIKE 区间抵消算法（为什么"麻烦你帮我"不该命中"烦"）、英文 casefold 大小写折叠（全大写"I WANT TO DIE"如何被捕获），以及"关键词只升级、不下结论"的核心安全反转。

背景：L0 运行在 EventBus.emit 的顺序 await 链上——它的每一毫秒都会叠加为每轮对话的固定延迟。

核心问题：如何在纯内存、零 IO 的极端约束下，做到高召回（不漏危机）与低误报（不扰用户）的平衡？

解决方案：三类词表分工（DIRECT/IMPLICIT/MOOD）+ 区间抵消排除 + LRU 去重 + 连续负向节流 + casefold 英文覆盖。

关键成果：

单条评估 <1ms，命中率目标 <8%，未命中零成本零延迟
中文子串匹配 + 英文 casefold，覆盖全大写/混合大小写
NEGATIVE_LOOKALIKE 区间抵消，将"麻烦/困难/积累/系统崩溃"类误报降为零
"L0 禁止触碰 sqlite"写入测试断言，架构纪律代码化

适合读者：对 NLP 关键词系统、实时事件处理、安全检测引擎感兴趣的开发者

阅读时长：约 15 分钟

关键词：L0Gate、关键词闸门、区间抵消、casefold、LRU去重、零IO、纯内存判定

一、为什么要"<1ms 零 IO"？——从事件循环的固定延迟说起

1.1 场景重现：每轮对话都在等你

想象这个场景：

用户发了一句"今天天气不错"——一句完全无害的闲聊。
但 USER_INPUT 事件在 LLM 调用之前发射，所有订阅者按 priority 顺序 await。
如果 L0 闸门里查了一次 sqlite（~2ms）或发了一次网络请求（~200ms），那么每一轮对话——无论用户说了什么——都要为心理检测付出这个固定代价。

一天对话 200 轮 × 2ms = 400ms 的无谓等待。如果是网络调用，那就是 40 秒！

L0 的设计约束因此极为苛刻：

约束	原因	实现手段
<1ms	叠加为每轮固定延迟	纯字符串扫描 + 内存字典
零磁盘 IO	sqlite 访问 ~2ms/次	禁止查 storage（测试断言）
零网络	LLM 往返 ~800ms	L0 不调 LLM（只升级）
命中率 <8%	绝大多数消息无需升级	关键词初筛 + 长度过滤

1.2 为什么不用正则或 embeddings？

初学者常问："用正则表达式或者句向量相似度不是更灵活吗？"

答案是：在 <1ms 约束下，它们各有致命短板。

# ❌ 正则：灵活但维护噩梦
import re
CRISIS_PATTERN = re.compile(r"(想死|不想活|结束.*生命|消失.*世界)")
# 问题：每加一个词就要改正则；区间抵消无法用正则表达；性能随模式数线性退化

# ❌ 句向量：语义丰富但太慢
# embedding = model.encode(text)  # ~50ms（本地）或 ~200ms（云端）
# 问题：违反 <1ms 约束；需要模型加载；无法做到"零 IO"

# ✅ WeClaw 做法：纯子串匹配 + 区间抵消
# 简单、可预测、O(n×m) 但 n 和 m 都很小（文本≤500字、词表~100词）

核心取舍：L0 不追求"理解语义"——那是 L1/L2 LLM 的工作。 L0 只追求"高召回、零漏报、可接受误报"。宁可误升级（L1 会过滤），不可漏升级（危机不可逆）。

1.3 核心挑战：三个"既要又要"

既要高召回，又要低误报："想从楼上飞下去"必须命中，"这个 bug 把我搞死了"不该命中。
既要中文覆盖，又要英文覆盖：用户可能中英混用或全大写输入。
既要简单可维护，又要精确可控：词表能随时增删，但行为必须可预测、可测试。

答案就在 L0Gate 的六步判定流水线中...

二、核心概念解析 —— L0Gate 的六步判定流水线

2.1 什么是"L0 闸门"？

官方定义：

L0Gate 是一个同步、零 IO、纯内存的危机信号初筛器。它运行在 EventBus.emit 的顺序 await 链上，对每条用户消息做 <1ms 判定，决定是否"升级"至 L1 云端分析。关键词永不能单独判定 critical——它只是"拉响警报"。

大白话解释：机场安检的金属探测门——它不判断你是不是坏人，只判断"需不需要进一步检查"。

生活化比喻：

用户消息 ──→ [金属探测门 L0] ──→ 没响 → 直接放行（零成本）
                    │
                    └── 响了 → 升级至人工开包检查（L1/L2 LLM）

2.2 工作原理：六步判定流水线

┌─────────────────────────────────────────────────────────────────┐
│                    L0Gate.evaluate(text)                         │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  Step 0: 空文本 / 过短 → suppress(too_short)                     │
│     │                                                           │
│  Step 1: HMAC → LRU(256) 查重 → suppress(lru_dup)               │
│     │                                                           │
│  Step 2: 日调用上限 / 预算熔断 → suppress(daily_cap/budget)       │
│     │                                                           │
│  Step 3: 显式求助词命中（不受长度限制）→ escalate(help_request)    │
│     │                                                           │
│  Step 4: len≥8 → 三类词表命中 + 区间抵消 → escalate(keyword)      │
│     │                                                           │
│  Step 5: len≥8 + 连续负向节流 → escalate(consecutive_negative)    │
│     │                                                           │
│  Default: suppress(no_hit)                                      │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

关键步骤：

Step 1 LRU 去重：同一文本不重复升级（HMAC-SHA256 摘要做键，避免存原文）。
Step 3 求助短路：用户显式说"救救我"时，不受 8 字长度限制，直接升级。
Step 4 核心判定：MOOD 词经区间抵消后 + ESCALATION 词独立评估，任一命中即升级。
Step 5 节流触发：连续 ≥3 天负向情绪时，窗口内最多凭此条件升级 1 次。

2.3 对比：L0 vs L1/L2 的职责边界

维度	L0 关键词闸门	L1/L2 LLM 分析
延迟	<1ms	~800ms × 2
数据源	纯内存（词表 + 快照）	云端模型
判定权	只升级，不下结论	输出 RiskLevel + confidence
语境理解	无（子串匹配）	有（虚构/玩笑/引述判别）
误报处理	容忍（L1 会过滤）	严格（双确认才 confirmed）
运行位置	EventBus 主链路	asyncio.create_task 后台

为什么这样分？ 因为"快"和"准"是天然矛盾的——L0 用速度换召回，L1/L2 用时间换精确。两者互补，而非替代！

📚 学术支撑：Weber 等（2026）在心理健康聊天机器人的危机风险检测研究中指出，分层检测（先快速初筛再精确确认）比单一模型端到端判断更能平衡延迟与准确性。 Thomas 等（2025）在 Nature Scientific Reports 中验证了 LLM 在危机文本分诊中可达到人类专家水平——这支撑了"L0 升级后交给 LLM 做精确判定"的设计选择。

三、实战代码详解 —— 逐行拆解 L0Gate

3.1 数据结构设计

首先看 L0Gate 的构造与判定结果：

# src/core/mental_health/analyzer.py
@dataclass
class L0Decision:
    """L0 判定结果。"""
    escalate: bool               # 是否升级至 L1
    reason: str = ""             # keyword / consecutive_negative / help_request
    suppress_reason: str = ""    # lru_dup / daily_cap / budget / too_short / no_hit
    matched: list[str] = field(default_factory=list)  # 命中的词
    text_hmac: str = ""          # 文本 HMAC（审计用，不存原文）


class L0Gate:
    """L0 闸门：同步 <1ms、零 IO、纯内存判定。

    命中率目标 <8%；未命中直接返回，零成本零延迟。
    禁止在此类内引入任何 sqlite/文件/网络访问（测试断言）。
    """
    def __init__(self, *, hmac_fn, settings, snapshot, budget_exceeded_fn=None):
        self._hmac_fn = hmac_fn              # HMAC-SHA256 函数（storage 注入）
        self._settings = settings            # MHSettings 配置
        self._snapshot = snapshot            # ProfileSnapshot 内存画像
        self._budget_exceeded_fn = budget_exceeded_fn or (lambda: False)
        self._lru: OrderedDict[str, None] = OrderedDict()  # LRU(256) 去重

字段说明：

hmac_fn：对文本做 HMAC-SHA256 摘要——LRU 里存摘要而非原文（隐私：内存不留敏感文本）。
snapshot：内存画像快照（连续负向天数、L1 调用计数等），启动时预热，L0 唯一数据源。
_lru：OrderedDict 实现的 LRU 缓存，容量 256，防止同一文本反复升级。

3.2 核心方法：`evaluate` 六步流水线

def evaluate(self, text: str) -> L0Decision:
    """纯内存判定是否升级为 L1。不触发任何 IO。"""
    text = (text or "").strip()
    if not text:
        return L0Decision(False, suppress_reason="too_short")

    # Step 1: LRU 去重（HMAC 摘要做键）
    digest = self._hmac_fn(text)
    if digest in self._lru:
        return L0Decision(False, suppress_reason="lru_dup", text_hmac=digest)

    # Step 2: 预算/日上限熔断
    today_str = date.today().strftime("%Y%m%d")
    if self._snapshot.l1_calls_for(today_str) >= self._settings.l1_daily_limit:
        return L0Decision(False, suppress_reason="daily_cap", text_hmac=digest)
    if self._budget_exceeded_fn():
        return L0Decision(False, suppress_reason="budget", text_hmac=digest)

    # Step 3: 显式求助（不受 8 字长度限制）
    help_hits = _find_phrases(text, HELP_REQUEST_KEYWORDS)
    if help_hits:
        self._lru_add(digest)
        return L0Decision(True, reason="help_request",
                          matched=[p for _, _, p in help_hits], text_hmac=digest)

    # Step 4: 关键词（MOOD 区间抵消 + ESCALATION 独立评估）
    if len(text) >= MIN_TEXT_LEN:  # MIN_TEXT_LEN = 8
        text_cf = text.casefold()  # ✅ 英文大小写不敏感
        mood_hits = _find_mood_hits(text)
        lookalike_spans = [(s, e) for s, e, _ in _find_phrases(text, NEGATIVE_LOOKALIKE)]
        surviving = [
            (s, e, p) for s, e, p in mood_hits
            if not _contained_in_any(s, e, lookalike_spans)  # 区间抵消
        ]
        esc_hits = _find_phrases(
            text_cf,
            ESCALATION_KEYWORDS_DIRECT + ESCALATION_KEYWORDS_IMPLICIT
            + ESCALATION_KEYWORDS_EN,
        )
        if surviving or esc_hits:
            self._lru_add(digest)
            return L0Decision(True, reason="keyword",
                              matched=[p for _, _, p in surviving] + [p for _, _, p in esc_hits],
                              text_hmac=digest)

    # Step 5: 连续负向节流触发
    if len(text) >= MIN_TEXT_LEN and self._check_consecutive_negative():
        self._lru_add(digest)
        return L0Decision(True, reason="consecutive_negative", text_hmac=digest)

    return L0Decision(False, suppress_reason="no_hit", text_hmac=digest)

代码解析：

第 3 行：text.casefold() 而非 lower()——casefold 处理德语 ß→ss 等特殊折叠，英文场景等效但更规范。
第 5-8 行：区间抵消——MOOD 词"烦"被"麻烦"包含时，该命中被排除。
第 9-12 行：ESCALATION 词在 casefold 后的文本上匹配（英文词表全小写），中文不受影响。
关键设计：MOOD 和 ESCALATION 走不同的匹配路径——MOOD 可被区间抵消，ESCALATION 永不抵消。

3.3 三类词表分工

词表 1：ESCALATION_DIRECT（直白自伤类）

ESCALATION_KEYWORDS_DIRECT: tuple[str, ...] = (
    "不想活", "活不下去", "撑不下去", "想死", "想自杀", "自杀", "轻生",
    "结束生命", "结束自己", "结束这一切", "伤害自己", "自残", "自伤", "割腕",
    "想消失", "消失就好了", "从这个世界消失", "看不到希望", "绝望",
    # 坠楼/自伤方式类（2026-08-02 实测缺口补充）
    "想死的心", "想跳楼", "跳下去", "飞下去", "一跃而下", "纵身一跃",
    "跳河", "跳桥", "卧轨", "上吊", "吞药", "喝农药", "烧炭",
)

词表 2：ESCALATION_IMPLICIT（隐晦告别类）

ESCALATION_KEYWORDS_IMPLICIT: tuple[str, ...] = (
    "永别", "和大家告别", "来世再见", "替我照顾好",
    "交代后事", "安排后事", "写好了遗书", "遗书",
    "把东西都送给", "我的东西都给你们",
    "不想再麻烦大家", "不想再拖累", "我是累赘", "是大家的负担",
    "没有我大家会更好", "没有我会更好",
    "想去很远的地方", "去一个很远的地方", "离开这里再也不回来",
    "突然想通了", "终于想通了", "都安排好了",
    # "麻烦/拖累/负担"变体（实测缺口补充）
    "不想麻烦任何人", "不想再麻烦任何人", "不想拖累任何人",
    "不想连累", "不想成为负担", "不想成为别人的负担",
)

词表 3：MOOD（情绪类，来自 companion_topics.py）

MOOD_KEYWORDS = {
    "negative": ["累", "烦", "难过", "不开心", "压力大", "焦虑", "担心", "难受", "郁闷", "伤心"],
    "stressed": ["忙死了", "压力大", "受不了", "崩溃", "烦死了", "没时间", "头疼", "焦头烂额"],
    "tired":    ["累", "困", "疲惫", "没精神", "想睡觉", "好困", "太累了", "精力不足"],
    "positive": ["开心", "高兴", "不错", ...],  # ← positive 不参与升级！
}

设计亮点：

DIRECT 和 IMPLICIT 永不抵消：即使"不想活"出现在"系统不想活了"里，也照样升级——L1 会判别语境。
MOOD 可被抵消：因为"累""烦""崩溃"在日常吐槽中太常见，需要区间抵消降低误报。
positive 不参与：MOOD 只看 negative/stressed/tired 三组。

3.4 区间抵消算法：NEGATIVE_LOOKALIKE

为什么需要区间抵消？

# 用户说："麻烦你帮我查一下天气"
# MOOD 词 "烦" 被命中了！但这显然不是情绪表达。

# 用户说："这个系统崩溃了，程序崩溃了"
# MOOD 词 "崩溃" 被命中了！但这只是在描述技术问题。

排除表与抵消逻辑

NEGATIVE_LOOKALIKE: tuple[str, ...] = (
    "麻烦",           # "麻烦你帮我…" 内含 MOOD 词 "烦"
    "困难", "困境", "困惑", "困扰",   # 内含 MOOD 词 "困"
    "积累", "累计", "累积",           # 内含 MOOD 词 "累"
    "系统崩溃", "程序崩溃", "服务器崩溃", "电脑崩溃", "软件崩溃",
)

def _contained_in_any(start: int, end: int, spans: list[tuple[int, int]]) -> bool:
    """命中区间是否被某个排除表区间完整包含（区间抵消）。"""
    return any(s <= start and end <= e for s, e in spans)

图解抵消过程：

文本："麻烦你帮我查一下"
       ────
       "麻烦" → lookalike span = (0, 2)

MOOD 词 "烦" 命中位置 = (1, 2)
判断：0 ≤ 1 且 2 ≤ 2 → True → 被包含 → 抵消！

结果：不升级 ✅

文本："我真的好烦，活着好烦"
             ─         ─
MOOD 词 "烦" 命中位置 = (5, 6) 和 (10, 11)
lookalike_spans = []（没有"麻烦"等排除词）
判断：无区间包含 → 保留 → 升级！

结果：升级至 L1 ✅（L1 会进一步判别是否真的情绪困扰）

核心规则：区间抵消只作用于 MOOD 词，ESCALATION 高危词命中独立评估、永不受排除表影响。这保证了"想死"即使出现在"系统想死了"里，也会升级——安全优先于精确。

3.5 英文 casefold：大小写不敏感匹配

# 英文词表（全小写定义）
ESCALATION_KEYWORDS_EN: tuple[str, ...] = (
    "want to die", "wanna die", "kill myself", "end my life", "end it all",
    "suicide", "suicidal",
    "don't want to live", "do not want to live",
    "no reason to live", "no point in living",
    "better off dead", "wish i was dead",
    "self-harm", "self harm", "hurt myself", "cut myself",
    "tired of living", "can't go on", "cannot go on",
    "no way out", "give up on life",
    "want to disappear", "disappear forever",
    "better off without me",
    "don't want to be a burden",
    "goodbye forever", "final goodbye", "say my goodbyes",
    ...  # 共 34 条
)

# 匹配时对文本做 casefold
text_cf = text.casefold()
esc_hits = _find_phrases(text_cf, ESCALATION_KEYWORDS_DIRECT + ESCALATION_KEYWORDS_IMPLICIT + ESCALATION_KEYWORDS_EN)

为什么用 casefold 而非 lower？

lower()："ß".lower() → "ß"（德语 sharp-s 不变）
casefold()："ß".casefold() → "ss"（更激进的大小写折叠）
英文场景两者等效，但 casefold 是 Unicode 推荐的"忽略大小写比较"方式。

实测验证：

输入："I WANT TO DIE"
casefold → "i want to die"
匹配 "want to die" → 命中 ✅

输入："I Want To Die"
casefold → "i want to die"
匹配 "want to die" → 命中 ✅

易错点：为什么不收 "die"/"dead"/"killing me"？

# ❌ 如果收了 "die"：
# "Let's jump off the call and die laughing" → 误报！
# "This bug is killing me" → 误报！
# "10 reasons to die" (笑话标题) → 误报！

# ✅ 只收明确短语（"want to die"/"kill myself"），不收单字：
# 高召回由 L1 兜底，L0 宁可少收几个词也不要高误报

这个教训来自真实实测——初版含 "jump off the"，结果"Let's jump off the call"（挂电话会议）被误升级，当场删除并以 FP 语料钉住回归（第 79 篇详解）。

3.6 LRU 去重与 HMAC 隐私

_LRU_CAPACITY = 256

def _lru_add(self, digest: str) -> None:
    if not digest:
        return
    self._lru[digest] = None
    self._lru.move_to_end(digest)        # 最近使用移末尾
    while len(self._lru) > _LRU_CAPACITY:
        self._lru.popitem(last=False)     # 淘汰最久未用

为什么存 HMAC 而非原文？

隐私：LRU 在内存中常驻，存原文等于在内存里保留用户敏感文本。
效率：HMAC-SHA256 固定 64 字符，比原文短且定长。
等效：相同文本 → 相同 HMAC，去重效果完全一致。

四、问题诊断与修复 —— 从"飞下去漏报"到词表精准扩充

4.1 问题现象：最高危的消息没有触发升级

实测回放（v9.0.0，12 条真实模拟消息）：

回放结果：仅 1 条被升级——而且是一条无关吐槽。两条最高危的消息"想从楼上飞下去"和"我不想麻烦任何人"——双双 no_hit！

奇怪：词表里明明有"跳下去"和"不想再麻烦大家"，为什么没命中？

4.2 根因分析：子串不匹配

排查步骤：

1️⃣ "飞下去"不在词表：

# 词表有 "跳下去"，但用户说的是 "飞下去"
"飞下去" in ESCALATION_KEYWORDS_DIRECT  # → False！
# 子串匹配：文本 "想从楼上飞下去" 不包含 "跳下去"

2️⃣ "我不想麻烦任何人"与"不想再麻烦大家"子串不匹配：

# 词表有 "不想再麻烦大家"
# 用户说的是 "我不想麻烦任何人"
"不想再麻烦大家" in "我不想麻烦任何人"  # → False！
# "任何人" ≠ "大家"，"不想麻烦" ≠ "不想再麻烦"

3️⃣ 发现问题本质：

词表设计假设：用户会用"标准表达"
现实：用户的表达千变万化

"跳下去" → "飞下去" / "一跃而下" / "纵身一跃"
"不想再麻烦大家" → "不想麻烦任何人" / "不想成为负担" / "不想拖累任何人"

根本原因：词表覆盖不足——只收了"标准说法"，没覆盖同义变体。

4.3 修复方案：精准扩充 + 英文覆盖

修复 1：DIRECT 补充坠楼/自伤方式类 +13

# —— 坠楼/自伤方式类（2026-08-02 实测缺口："想从楼上飞下去"漏报）——
"想死的心", "想跳楼", "跳下去", "飞下去", "一跃而下", "纵身一跃",
"跳河", "跳桥", "卧轨", "上吊", "吞药", "喝农药", "烧炭",

修复 2：IMPLICIT 补充"麻烦/拖累/负担"变体 +6

# —— 实测缺口："我不想麻烦任何人"与"不想再麻烦大家"子串不匹配漏报
"不想麻烦任何人", "不想再麻烦任何人", "不想拖累任何人",
"不想连累", "不想成为负担", "不想成为别人的负担",

修复 3：新增英文词表 +34（casefold 后匹配）

ESCALATION_KEYWORDS_EN: tuple[str, ...] = (
    "want to die", "kill myself", "end my life", "suicide", "suicidal",
    "don't want to live", "no reason to live", "better off dead",
    "self-harm", "hurt myself", "cut myself",
    "can't go on", "no way out", "want to disappear",
    "better off without me", "goodbye forever", ...
)

验证结果：

✅ "想从楼上飞下去" → 命中 "飞下去" → 升级
✅ "我不想麻烦任何人" → 命中 "不想麻烦任何人" → 升级
✅ "I WANT TO DIE" → casefold → 命中 "want to die" → 升级
✅ "Let's jump off the call" → 无命中 → 不升级（已删除过宽词）
✅ "This bug is killing me" → 无命中 → 不升级（未收 "killing me"）

4.4 经验教训

Checklist：

词表是否覆盖了同义变体（"飞下去"/"跳下去"/"一跃而下"）？
英文词表是否只收明确短语，不收高误报单字（die/dead/killing me）？
每次误报是否以 FP 语料钉住回归？
新增词后是否跑全量召回 + 误报语料集验证？

避坑指南：

子串匹配的局限：它不理解同义词——"飞下去"和"跳下去"对子串匹配来说是完全不同的字符串。必须手动穷举变体。
过宽词的代价：一个 "jump off the" 就能让"挂电话会议"误升级。收词原则：宁可少收（L1 兜底），不可过宽（误报摧毁信任）。
实测回放是金标准：坐在办公室里想词表永远不够——必须用真实对话回放验证。

五、性能优化与最佳实践

5.1 性能实测

测试环境：Intel i7-12700H / Python 3.12 / 纯内存

L0Gate.evaluate("想从楼上飞下去")     : 0.03ms  （ESCALATION 命中）
L0Gate.evaluate("今天天气不错")        : 0.02ms  （no_hit，全表扫描）
L0Gate.evaluate("麻烦你帮我查天气")    : 0.04ms  （MOOD 命中 + 区间抵消）
L0Gate.evaluate(500字长文本)           : 0.12ms  （最长场景）
LRU 命中（重复文本）                   : 0.01ms  （dict 查找即返回）

结论：即使最坏情况（500 字 × ~100 词表全扫描），也远低于 1ms 红线。

5.2 为什么 O(n×m) 在这里够用？

n = 文本长度（≤500 字，ring buffer 截断）
m = 词表总大小（DIRECT ~40 + IMPLICIT ~40 + EN ~34 + MOOD ~30 + LOOKALIKE ~13 ≈ 157）

最坏操作次数：500 × 157 = 78,500 次 str.find()
每次 str.find() 在 CPython 中为 C 实现的 Boyer-Moore 变体，极快。
实测：0.12ms（含 Python 循环开销）

不需要 Aho-Corasick：词表 ~157 条、文本 ≤500 字——这个规模下，纯 Python 循环 + C 级 str.find() 已经足够快。引入 AC 自动机反而增加维护复杂度。

5.3 最佳实践总结

Do's：

✅ 词表用 tuple[str, ...]（不可变、hashable、IDE 友好）
✅ LRU 存 HMAC 摘要而非原文（隐私 + 定长）
✅ 区间抵消只作用于 MOOD 词，ESCALATION 永不抵消（安全优先）
✅ 英文词表全小写定义 + 文本 casefold 后匹配
✅ 每次词表变更后跑全量语料集回归

Don'ts：

❌ 在 L0 里引入 sqlite/文件/网络访问（测试断言会失败）
❌ 收高误报单字（die/dead/崩溃/累）作为 ESCALATION 词
❌ 用正则替代子串匹配（维护噩梦 + 区间抵消无法表达）
❌ 让 L0 下"critical"结论（关键词只升级，判定权归 L1/L2）

黄金法则：

L0 的哲学是"宁可误升级，不可漏升级"—— 误升级的代价是 L1 白跑一次（~800ms，后台异步，用户无感）；漏升级的代价是一条危机消息被静默放过（不可逆）。

六、总结与展望

6.1 核心要点回顾

本文深入拆解了 L0 关键词闸门的内部实现：

3 个关键点：

<1ms 零 IO 是硬约束：L0 运行在每轮对话主链路上，任何 IO 都会叠加为固定延迟。
三类词表 + 区间抵消：ESCALATION（永不抵消）+ MOOD（可被抵消）+ HELP（短路），分工明确。
关键词只升级、不下结论：这是核心安全反转——判定权全部交给 L1/L2 双独立 LLM。

1 个核心公式：

L0 判定 = LRU去重 → 熔断检查 → 求助短路 → (MOOD×区间抵消 + ESCALATION×casefold) → 连续负向节流

6.2 下一步学习方向

前置知识：

✅ Python str.find() 与子串匹配
✅ OrderedDict 实现 LRU 缓存
✅ HMAC-SHA256 摘要

后续主题：

📖 下一篇 76：《L1–L2 双重确认：为什么一个 LLM 说了不算？》
🔜 77：《RiskLevel 全序 Bug：一个缺失的 __lt__ 如何让告警链路静默失效》
🔜 79：《词表校准与误报治理：从实测回放看召回率与误报率的平衡术》

扩展阅读：

系列第 74 篇：《分层风险治理总览：为什么 AI 心理陪伴需要 L0–L4 五层安全阀》
系列第 26 篇：《意图识别与工具智能路由：17 维关键词矩阵如何让 LLM 精准选择 38 个工具》

6.3 互动环节

思考题：

为什么区间抵消只作用于 MOOD 词而不作用于 ESCALATION 词？如果对"想死"也做区间抵消，会引入什么风险？
LRU 为什么存 HMAC 摘要而不是原文？如果直接存原文，在隐私和效率上各有什么问题？

讨论话题：

如果你的系统也需要一个"纯内存、<1ms"的初筛层，你会选择子串匹配、正则、还是轻量 ML 模型？在"可维护性"与"召回率"之间，你怎么取舍？

下期预告：《WeClaw_76｜L1–L2 双重确认：为什么一个 LLM 说了不算？》

独立小模型分析：glm-4.7-flash / 600 max_tokens / 12s 超时 / temperature 0.3 的取舍
L2 为什么必须是"另一次独立推理"而非"同一结果复读"
双 critical 且 confidence ≥ 0.85 才 confirmed 的占位阈值设计

敬请期待！

附录 A：完整代码清单

文件路径	作用
`src/core/mental_health/analyzer.py` L49-118	词表定义（DIRECT/IMPLICIT/EN/HELP/LOOKALIKE）
`src/core/mental_health/analyzer.py` L276-396	L0Gate 类 + L0Decision + LRU
`src/core/mental_health/analyzer.py` L398-427	辅助函数（_find_phrases/_find_mood_hits/_contained_in_any）
`src/core/companion_topics.py` L417-434	MOOD_KEYWORDS 定义
`tests/corpus/mh_crisis_recall.json`	召回语料集（30 条，含英文）
`tests/corpus/mh_false_positive.json`	误报语料集（52 条，含英文钉）

关键方法：L0Gate.evaluate / _find_phrases / _contained_in_any / _lru_add 词表规模：DIRECT ~40 + IMPLICIT ~40 + EN 34 + MOOD ~30 + LOOKALIKE 13 + HELP 9 ≈ 166 条

附录 B：参考文献（APA 7）

Thomas, et al. (2025). LLM performance vs human expert crisis text lines. Nature Scientific Reports, s41598-025-22402-7.
Weber, et al. (2026). Suicide- and crisis-risk detection using LLMs in mental-health chatbots. medRxiv, 2026.01.12.26343914.
Reichenpfader, et al. (2026). Detecting suicidal ideation signals in synthetic conversations.
上一篇：《WeClaw_74｜分层风险治理总览：为什么 AI 心理陪伴需要 L0–L4 五层安全阀》
下一篇：《WeClaw_76｜L1–L2 双重确认：为什么一个 LLM 说了不算？》

🆘 危机求助资源（静态核验） 如果你或身边的人正处于心理危机中，请立即联系以下经核验资源：

全国心理援助热线：988

心理援助热线：12356

北京心理危机研究与干预中心：010-82951332

境外用户：请拨打当地急救电话或前往就近医院急诊

原文链接：https://blog.csdn.net/yweng18

L0 关键词闸门：<1ms 零 IO 的危机念头第一道防线