报错是这么冒出来的。azure-openai 的 2024-10-21 版本调 gpt-4o-mini 润色商品文案，返回 400，原文 The response was filtered due to triggering Azure OpenAI's content management policy，文案里只有面料和尺码，直连 openai 同一条却能通。
中间走过弯路，把「拦截发生在输出侧，模型自己写出了被判定的词」当成主因，改完现象没变。
这类报错背后常见的原因有几处，逐个排除就行。过滤策略是部署上的 DefaultV2，阈值比默认更严。还有一种是prompt 里拼了从详情页抓来的用户评价，里面带脏话。
另外，请求带了额外的检测输入字段，网关把它也送进了审核。
先把 error 里 innererror 的 code 与 responsible 打出来
python -c "import json;print(json.load(open('err.json'))['error']['innererror'])"接着把 max_tokens 压到 1，看拦截是否还在输入侧
curl https://资源名.openai.azure.com/openai/deployments/gpt4o-mini/chat/completions?api-version=2024-10-21 -H "api-key: $AZURE_KEY" -H "Content-Type: application/json" -d '{"messages":[{"role":"user","content":"面料是纯棉 尺码 M"}],"max_tokens":1}'去掉评价段落只留 system 与 user 再请求一次
python filter_probe.py --drop reviews --out probe.json剩下的就是在门户把内容过滤器改成 DefaultV1 并重新部署
az cognitiveservices account deployment show --name 资源名 --resource-group rg-ai --deployment-name gpt4o-mini恢复的判定其实很直接。响应变为 200 且 finish_reason 是 stop，同一条文案连发三次都能拿到完整结果，innererror 字段不再出现。
容易忽略的是，content_filter 不区分输入和输出，先用 max_tokens=1 判断拦在哪一侧，再决定是清洗语料还是放宽策略，盲目改提示词往往白忙。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。