Jev 内容审核：把用户评论分为放行、复审或删除

这个审核器查什么

上面的示例是一条同时违反多条规则的电商平台评论：它说卖家是骗子，引导买家私信去站外以半价购买，还辱骂了照片里的人。一次调用问三个问题：

Choice 承载最终决定，每个选项都附一句说明——比如 review 对应"拿不准，交给人工审核员"——这样 Jev 知道每个分类在你的平台上意味着什么。两个 Noul 则说明评论为什么有问题。这对日志、申诉处理，以及对两类问题区别对待的规则都有用：你可能会悄悄隐藏广告，却对辱骂者发出警告。

三个问题针对同一条评论并行作答，多问几个几乎不增加延迟，合起来仍然算一次标准评估。

怎么写审核问题

把你的社区规则写进 criteria。 Jev 会按字面理解问题；TypeSafe 的说明指出，限定词、否定和隐含条件都会被照字面读取。"评论是否侮辱或骚扰某个人？"并不知道你的社区允许严厉批评商品，却不允许攻击卖家本人。那就写明：

{
  "type": "noul",
  "instructions": "Does the comment insult or harass a person?",
  "criteria": {
    "true": "It attacks, mocks or demeans a specific person, including the seller or anyone pictured.",
    "false": "It criticises a product, price or service without attacking a person."
  }
}

一条规则一个 Noul。 骚扰、广告、仇恨言论、个人信息、自我推广——各自单独一个问题，这样高分能直接指向具体的规则。同一条评论最多问五个问题仍然只收 1 点；最多可问 12 个，收 3 点。

让"复审"选项名副其实。 三选一里保留一个真正的"拿不准"分类，你就能把这部分概率交给人工，而不是把每个难判的评论硬塞进放行或删除。

计数交给代码。 "超过三个链接""一分钟内发了五次"这类规则本质是计数。TypeSafe 明确记录 Jev 计数不可靠；这些在代码里算，让 Jev 去判断含义。

关于措辞的更多建议，见设计 Jev 能回答的问题：Choice、Score 与 Noul。

从一次检查到审核队列

1. 标注一批样本。 取 50 到 200 条审核员已经处理过的真实评论，用同样的问题跑一遍。
2. 划三个区间。 allow 高且两个 Noul 都低的自动发布，remove 高的自动隐藏，其余排队等人工处理。边界用你的标注数据来调。
3. 精简 state。 只传评论和审核员需要的上下文。TypeSafe 指出 state 里的无关内容会降低准确度，所以不要把整个讨论串都贴进去。
4. 记录模型版本。 每次响应都带有 model 字段（例如 jev-1.13.0）。把它和每条判定一起记下，版本变化时重新校验阈值——JevStation 在部署层固定模型，不需要你在请求里指定。
5. 从流水线里调用。 同样的评估可以用 API key 通过 System One API 调用，扣点与试验台相同。

按 TypeSafe 的标价（输入每百万 token $0.042），像本例这样一次三问题的检查，token 成本约在 $0.00002 量级——便宜到可以逐条审核，而不必抽样。实测过程见一次 Jev 评估到底花多少钱：实测。

信任之前先验证

• 拿你的审核员做对照，而不是示例。 各社区的规范不同，别人平台上的阈值不是你的阈值。
• 不要在问题类型之间复用阈值。 TypeSafe 记录过，一个 Noul 和与之等价的 Choice 可能给出不一致的结果。verdict 和每个 Noul 都要分别调。
• 盯住复审区间。 如果大多数评论都落在中间，说明 criteria 写得太模糊——先把它写清楚，再考虑加审核员。
• 你服务的每种语言都要测。 英文的准确度最好。

Jev 不适合的场景

• 你必须给作者一段书面理由，或为每次删除保留文字记录。
• 内容不是文本。 Jev 读取的是文本 state；图片和视频需要别的模型。
• 规则是精确的。 屏蔽词、封禁域名、频率限制和链接数量，都应该写在代码里。
• 发广告的人能试探你的分数。 分数便宜又稳定，对方很容易反复改写措辞直到混过去，所以永远不要把分数暴露给发帖人。

同样的"放行 / 复审 / 删除"模式——一个做决定的 Choice，加上每个原因一个 Noul——也适用于客服工单等其他队列，见工单分流和 Jev 与 LLM 分类对比。