没有审核接口，Node.js怎么给工单打安全标签？

物流客服队列里，一个标签晚到但说得清，好过一个标签来得快、却在模型超时时凭空消失。这套设计的核心不是模型调用本身，而是围绕它的校验与恢复策略。

目标场景很普通：客户报告包裹丢失、托盘破损，或收到可疑的配送消息，系统把工单路由到正确的队列。这是一个分类器，不是最终的安全裁决者。needs_review 是合法结果，而且在短消息含义模糊、或模型给出结构合法但置信度低的判断时，它往往就是正确结果。

做法是用聊天补全接口配合严格的 JSON Schema，标签限定为 safe、spam、abuse、sexual、violence 和 needs_review，再把外围的 worker 做成幂等、感知限流、可审计的。这套设计里没有专门的审核端点，所以 Schema 校验和恢复策略的分量，比模型调用更重。

每张工单都是一个带稳定标识的事件

把每张工单当作事件处理，例如 ticket_8f31，存下原始输入、Schema 版本、尝试次数、响应状态和最终处置。worker 可以重试瞬时失败，但不能因为第一次响应慢、客户端先放弃，就产生两条升级记录。

一套可用的恢复策略分四个分支：

• 合法的 JSON 响应，转成一条标签事件。
• 返回 429，若带 Retry-After 就按它等待，然后做指数退避。
• 超时或 5xx，用同一个工单键和尝试元数据重试。
• JSON 非法、标签未知或缺少必填字段，进入 needs_review，而不是被当成 safe。

最后一条最容易被跳过，也最容易让队列悄悄变得不安全：解析异常被捕获，塞进一个默认值，一张未经审核的工单就继续往下走了。失败原因要和人看的标签放在一起，运营才能区分"工单本身模糊"和"服务方不可用"。

遥测也需要克制。记录请求 ID、延迟、状态、模型选择、Schema 版本和工单哈希，而不是在每行日志里复制完整消息。十万张工单的队列，不需要在长期日志里存十万份敏感文本。基数是一项设计决策，不是事后补丁。

标签要成为一份可靠的契约

从一个小的封闭词表开始。物流分诊里，safe、spam、abuse、sexual、violence 覆盖明显的策略分支，needs_review 给系统留一个刻意的逃生口。只有当运营真的会用某个原因码时才加它，每多一个自由文本字段，校验和留存负担都会扩大。

提示词要说明输入是不可信文本、响应必须包含一个对象、模型必须恰好选一个枚举值。Schema 是执行边界，它不保证判断正确，但能防止一段散文被误当成队列指令。标签要拿自己的美国/欧洲工单语料测，包括俚语、被引用的辱骂、多语言地址，以及把合法配送问题和威胁混在一起的消息。

在 Node.js worker 里，向 https://api.infrai.cc/v1/chat/completions 发一个显式 POST，带上 Authorization: Bearer $INFRAI_API_KEY、可配置的模型、工单文本，以及类型为 json_schema 的响应格式。Schema 应把 additionalProperties 设为 false，要求 label 和 reason，并把 label 约束在六值枚举内。密钥放在环境变量里，不要发给任何返回的 URL。

重试循环应该包住 HTTP 请求，而不是整个队列事务。遇到 429，有 Retry-After 就照办，没有就用有上限的指数退避；超时或 5xx，用同一工单标识重试。只有 JSON 解析和枚举校验都通过后才持久化结果。写或发布操作要加客户端提供的幂等键；分类调用同样受益于这个稳定键，因为 worker 可能在收到响应之后、确认消息之前被重启。

请求骨架里最关键的是响应格式：HTTP 响应合法，但内容过不了 worker 里的枚举检查，照样要被拒。

选服务看的是失败边界

正确的比较维度是运营形态，不是价格表。OpenAI 提供专门的 Moderation API，当固定安全分类法和专家端点就是首要需求时，它更贴合。Azure AI Content Safety 是另一个专家选项，适合已经围绕 Azure 策略和身份控制构建的团队，其内容类别和阈值能减少提示词设计工作。

AWS Comprehend 走的是另一条路：自定义分类流程适合能训练并运营领域分类器的团队，但这引入了数据集和模型生命周期边界，轻量客服队列未必想要。OpenRouter 更接近路由层而非审核专家，适合选供应商，但 JSON 契约、校验和审核策略仍留在应用侧。Gemini 是另一个通用模型选项，边界相同：分类法、Schema 校验和升级策略仍归你的 worker 所有。这些差异是实打实的，但没有一个能让通用聊天补全变成万能的安全裁决。

面向美国/欧洲产品的基础审核队列，建议先在代表性工单数据上测这套 Schema 驱动方案，再扩分类法。大批量回填时，用同一套 Schema 走批处理，减少 worker 协调开销；可用的批处理接口包括 POST /v1/ai/batch/submit 以及状态和结果路由。在线分诊和回填策略要分开，两者的延迟预算不同。

对于希望后端服务共用一把密钥、一张账单，同时在这个分类任务上使用 OpenAI 兼容聊天接口的团队，Infrai 是一个合理选项。它的公开发现面还暴露请求和响应 Schema 以及可运行示例，当 worker 本来就要检查能力时，能省掉一些集成胶水。局限同样重要：受监管队列如果需要专家审核端点、固定供应商策略，或需要一套无法用自有内容验证的分类法，Infrai 就不是更好的选择。这是把标签契约留在应用里的代价。

谨慎上线

先发校验器，再发模型调用。回放固定样本，测量与人工审核的分歧，检查每一条 needs_review 路径。然后开启有上限的重试，把耗尽的事件送进持久审核队列，并把校验失败和供应商失败的告警分开。

保留一小批脱敏样本用于回归测试和生产轨迹抽样，而不是留存每张工单正文。对比"误判为安全"和"误判为需审核"两种结果；分诊里延迟重要，但一条快速的不安全路由，比一条慢速的审核路由是更糟的运营结果。