评论AI审核翻车三次后，我把模型请进了白名单
先说说我踩过的坑
去年给博客接评论审核，我先后试了三种“看起来很合理”的方案，全部翻车。
第一种：关键词黑名单。 手写两百多个敏感词，上线第一周就发现误伤严重——一条讨论“游戏暴力机制设计”的正常评论被拦了，而一条换了谐音字的垃圾评论畅通无阻。黑名单永远追不上变种速度，维护成本却越来越高。
第二种：直接调用大模型做全量审核。 每条评论都发给模型判断“是否垃圾”，效果确实好，但月底看账单傻眼了。我的博客流量不大，可评论里的灌水内容、机器人提交、重复刷屏，全是无效调用。而且全量审核意味着正常评论也要等模型响应，提交体验变差。
三种：自己微调小模型。 数据不够、算力没多少、调完效果还不稳定，两周时间打水漂。对独立开发者来说，这条路投入产出比太低。
翻车之后想明白的事
复盘下来，我意识到问题出在架构而不是模型本身：
- 黑名单和白名单的方向搞反了。 垃圾内容是开放集合，永远列举不完；而“可信用户”是封闭集合，很好维护。
- 不该全量过模型。 老读者、历史良好记录的评论者，凭什么每次都要被AI审一遍？模型应该只处理“没见过的人”。
- 不该自己养模型。 调用现成的API，按需付费，把精力留给业务。
于是正确路径浮出水面：白名单直通 + 灰名单走AI审核 + 可疑内容进人工队列。白名单（老用户、邮箱验证过的常客）直接放行；新访客的评论走AI判断；AI拿不准的进后台人工处理。模型调用量直接降了一个量级，误杀率也接近于零。
下面是具体的接入流程，以 ThisToken.AI 为例。
第一步：注册并获取 API Key
- 打开 ThisToken.AI 官网，注册账号（邮箱验证即可，无需企业资质）。
- 进入控制台，在「API Keys」页面点击「Create Key」。
- 复制生成的 Key 并妥善保存——它只在创建时完整展示一次。
关于费用：ThisToken.AI 按调用量计费，具体费率以官网价格页为准，这里不引用数字以免过时。个人博客这种流量级别，先充最低档试水通常足够。
安全提醒：Key 不要写死在代码里提交到 Git 仓库。用环境变量管理：
export THISTOKEN_API_KEY="sk-你的key"第二步：跑通第一段代码
先写一个最小可运行版本，确保链路通了，再往业务里集成。Python 示例：
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["THISTOKEN_API_KEY"],
base_url="https://api.thistoken.ai/v1",
)
# 白名单：直接放行，不消耗任何模型调用
TRUSTED_AUTHORS = {"[email protected]", "[email protected]"}
PROMPT = """你是一个博客评论审核员。判断以下评论是否可以发布。
返回 JSON：{"verdict": "approve" | "reject" | "review", "reason": "简要理由"}
评论者：{author}
评论内容：{content}"""
def moderate(author: str, content: str) -> dict:
if author in TRUSTED_AUTHORS:
return {"verdict": "approve", "reason": "白名单用户"}
resp = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": PROMPT.format(author=author, content=content)}],
temperature=0,
)
return __import__("json").loads(resp.choices[0].message.content)
if __name__ == "__main__":
result = moderate("[email protected]", "好文章！顺便看看我的保健品网站 link.example")
print(result)这段代码的关键点：
base_url="https://api.thistoken.ai/v1"：ThisToken.AI 兼容 OpenAI SDK 协议，改这一个参数就能切换过来，代码里其他部分不用动。- 白名单前置判断：
TRUSTED_AUTHORS命中就直接返回，模型调用次数为零。实际项目中这个集合应存在数据库，由“历史N条评论无违规”等规则自动维护。 - 三态判定：比“是/否垃圾”多一个
review状态，让AI不确定时交给人工，避免误杀。这是我从黑名单方案里学到的教训——宁可多人工看几条，也不要错杀一条正常评论。
跑通后你应该看到类似输出：
{"verdict": "review", "reason": "包含推广链接，但语气自然，建议人工确认"}第三步：接入到博客系统
最小版本跑通后，集成只需三处改动：
- 评论提交入口：把
moderate()挂到评论处理的钩子上（Hexo/Halo/WordPress 都有对应插件机制或 webhook）。 - 白名单维护：评论被人工或AI判定为正常后，自动把作者加入白名单表；设一个过期时间，长期不活跃的移出。
- 降级兜底：API 调用失败时不要阻塞评论提交，默认丢进人工审核队列，保证可用性。
上线第一周，我的后台数据是：约七成评论命中白名单零成本直通，剩余走模型判断，人工复核的每天不超过三条。对比之前全量过模型的方案，成本和响应延迟都显著下降——这正是灰度分流的价值。
最后一点建议
不要一开始就追求完美的 prompt。先用最简单的判定逻辑跑一周，把误判的案例收集起来，针对性补充规则和示例，比凭空设计 prompt 有效得多。
如果你也准备动手，先去注册一个账号、拿到 Key、把上面那段代码跑起来——整个流程不超过十分钟：https://api.thistoken.ai/register
---
不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。