开发者 AI 调用命中敏感词后怎么处理？
AI 自动化办公、客服回复和运营文案接入模型后，内容安全不能只靠一句“不要违规”。当返回内容命中敏感词、禁用承诺或内部合规规则时，系统要能判断是直接拦截、二次改写，还是进入人工复核。
适用场景：不是所有命中都要直接失败
实际业务里，命中规则分很多种。客服回复里出现“保证赔付”应该阻断；营销文案里出现过度承诺，可能适合让模型改写；合同摘要包含客户姓名，应先脱敏再给外部角色查看。若把这些都处理成同一个错误码，用户只会看到“生成失败”，客服和开发也无法判断是哪条规则触发。
有些团队把中间接入层叫作 GPT 中转，但这不是品牌名，也不该作为页面主卖点。更准确的做法，是把 AI 模型接口接入、规则引擎、内容审核、人工复核和日志留证组成一条可解释链路。永沃云枢建议先把风险类型写清楚，再决定是否调用模型二次改写。
操作步骤：先分级，再决定动作
第一步，整理风险词和业务规则，把它们分成硬拦截、可改写、需复核三类。硬拦截适合违法违规、隐私泄露和明确禁用承诺；可改写适合语气过强、格式不符、缺少免责声明；需复核适合金额、医疗、法律、售后赔付和客户投诉。第二步，让每次 AI API 接入调用都输出 rule_hits、risk_level、rewrite_allowed 和 reviewer_role，而不是只返回一段文本。
第三步，在后端保存原始回答、审核后回答和触发规则，但敏感原文要做字段级脱敏。可以用 rg "moderation|risk_level|review_status|rewrite" server pages 检查代码里是否已经有状态字段。第四步，如果通过 CCSwitch 配置切换不同模型，仍要让每个模型经过同一套审核出口，避免备用模型绕过规则。
验收标准：用户看到的是处理结果，不是内部规则
对外展示要克制。硬拦截时可以提示“内容需要人工确认后再发送”，不要把敏感词列表原样暴露；可改写时要保留改写前后的差异，方便运营复盘；需复核时要生成任务，带上 request_id、业务来源、命中规则和推荐处理动作。AI 自动化办公尤其要注意，不能让生成结果直接覆盖工单、邮件或公告。
Codex 接入这类改动时，适合让 Codex 先补状态枚举、日志字段和本地样本，再人工决定规则表。开发者 AI 调用的提示词可以要求模型给出“安全版本”，但最终判定不应只依赖模型自评。
常见问题/避坑
第一个坑是只在前端检查敏感词。用户绕过页面或接口重放后，风险内容仍会进入下游。第二个坑是把命中规则写进 prompt，却没有服务端校验。第三个坑是二次改写没有次数上限，模型反复改写导致费用上升。第四个坑是日志保存太完整，排错方便了，却把客户隐私留在普通日志里。
检查清单：发到用户前最后看这些项
上线前检查：规则是否分级；每类规则是否有明确动作；AI 模型接口返回是否带结构化状态；拦截和改写是否都有 request_id；人工复核队列是否能看到来源和建议；日志是否脱敏；CCSwitch profile 切换后审核仍生效；Codex 生成的改动是否有样本测试；站内说明是否链接到 AI API 接入专题、AI 自动化办公专题、Codex 安装专题 和 CCSwitch 配置专题。
内容安全的目标不是让模型少说话，而是让每次输出都有边界、有证据、有复核路径。这样处理后，模型调用管理才真正进入可运营状态。
复核队列设计：让风险内容有去处
人工复核不是把所有失败都丢给运营。队列里至少要展示原始任务、脱敏后的模型回答、命中规则、推荐动作、业务截止时间和处理人。客服类内容可以按客户等级和投诉状态排序，合同类内容要按金额和条款类型排序，AI 自动化办公生成的公告或邮件则要保留发送前预览，避免审核通过后直接群发。
还要给二次改写设置上限。一次改写仍命中规则，就不要继续循环调用 AI 模型接口，而是转人工，并记录 rewrite_count。这样既能控制 AI API 接入成本，也能避免开发者 AI 调用在异常内容上反复消耗。Codex 修改这部分逻辑时，应同步补充样本和状态流转说明。
如果业务允许用户编辑模型草稿，还要区分“模型生成命中”和“人工编辑后命中”。前者可以用提示词和规则优化，后者更像发布审核问题。两类命中共用同一套日志，但处理责任、复核角色和用户提示应分开，否则复盘时会误判 AI API 接入质量。