核验清单

  • ✓这次请求返回的HTTP状态码到底是200还是400/403之类的错误码——200代表模型已经开始生成、审核发生在生成之后或流程之中，非200状态码通常意味着请求在进入模型之前就被拦截，两者对应完全不同的排查方向
  • ✓响应体里有没有类似finish_reason/stop_reason这类字段，取值是不是stop（正常结束）或length（达到长度上限）之外的第三种取值（不同厂商命名不同，需要去对应厂商当前的官方API文档核对具体字段名和取值枚举，不要凭经验或旧文档假设）
  • ✓如果是流式（streaming）调用，检查连接是断在了收到某种明确的结束事件之后，还是在没有任何结束标记的情况下直接中断——后者更可能是网络或客户端问题，前者才是审核在流程中途触发
  • ✓去对应厂商当前的计费文档里核实：被截断或拦截的这次调用，输出的token是否仍然计入账单——不同厂商结论可能不同，不要直接套用其他厂商的规则
  • ✓如果业务场景确实需要放宽审核（比如企业内部工具、特定领域的专业内容），检查厂商控制台里是否有正式的加白/例外申请入口，而不是自己在客户端做二次过滤绕过官方审核结果

1. 现象：接口没报错、也照常计费，内容却是空的或断在一半

这是一类相当常见但容易让人摸不着头脑的问题：调用DeepSeek、通义千问这类国内大模型的Chat Completions类接口，HTTP层面一切正常——状态码是200，请求也确实被计入了调用记录，但拿到手的响应里，content字段是空字符串，或者是一段看起来毫无征兆地在句子中间戛然而止的文本。因为HTTP状态码正常、请求本身没有抛异常，很多开发者第一反应是怀疑自己的解析代码写错了，或者怀疑是网络传输把内容截断了，往返排查半天却发现请求、解析代码都没问题。这类现象的真正原因，通常和网络无关，而是内容安全审核在响应生成的某个环节介入了。

2. 为什么会有这层审核：模型自身对齐之外，还有独立的安全审核

国内大模型API返回内容异常，背后往往叠加了两层不同性质的机制。第一层是模型本身在训练阶段做的对齐（alignment），模型学会了对某些问题主动拒答或者给出委婉的回避回答，这种情况下模型确实"生成"了内容，只是内容本身是拒答文本，不是空的。第二层是独立于模型之外、由平台方额外加装的内容安全审核层——它可能作用在输入侧（在请求送进模型之前，先检测用户输入是否包含违规内容），也可能作用在输出侧（模型生成完之后，再检测输出内容是否合规，一旦命中就把内容整体或部分抹掉）。按《生成式人工智能服务管理暂行办法》等监管要求，提供生成式AI服务的平台本身就负有内容安全主体责任，这也是为什么几乎所有国内大模型API都会内置或可选接入这层独立审核，而不只是依赖模型自身的对齐效果。搞清楚"是模型拒答还是审核层拦截"，是判断该往哪个方向排查的第一步。

3. 具体该查哪个字段：不同厂商标记方式不一样，别凭经验假设

要区分"正常生成完毕"和"被审核截断"，第一手信息永远是响应体本身，而不是猜测。以DeepSeek官方Chat Completions API文档的说明为例，响应体里有一个finish_reason字段，标记模型停止生成的原因，其取值除了stop（正常结束）、length（达到最大token限制）之外，还专门有一个content_filter取值，用于表示"因内容过滤器标记而省略了部分内容"——也就是说，同样是HTTP 200、同样是完整走完了一次请求，finish_reason取值不同，代表的含义完全不同，这个字段就是排查这类问题该优先检查的位置。但要注意，不是所有厂商的审核拦截都长这样：以阿里云百炼（DashScope）为例，它的输入输出安全护栏机制在检测到请求或输出包含违规内容时，官方文档描述的是直接返回HTTP 400状态码，并带上诸如"data_inspection_failed"这样的错误码和"Input data may contain inappropriate content"这样的错误提示——这属于请求阶段就被拦截，而不是200之后再看某个字段。所以具体到你在用的这家厂商，字段名叫什么、拦截发生在200之内还是400之外，必须去它当前的官方API文档核实，不能照抄别的厂商的经验。

4. 流式场景更麻烦：内容推到一半，突然就断了

如果调用的是流式（streaming）接口，这类审核截断会变得更难判断。因为流式响应本身就是分成一个个小块（chunk）陆续推送给客户端的，如果审核是在生成过程中途才触发——比如模型已经生成了前面几十个token、客户端也已经陆续收到并展示了这部分内容，审核层这时候才判定后续内容有风险并中断了流——客户端看到的现象就是"内容显示到一半，然后就不再更新了"，这和网络中断、客户端超时在表现上几乎没有区别。要分辨清楚，关键是看这次流式响应最终有没有收到一个带着明确结束标记的收尾事件（不同厂商的具体事件名称和字段需要查对应厂商当前的流式接口文档），如果有明确的结束事件、只是finish_reason之类的字段显示了非正常停止的取值，那大概率是审核在中途介入；如果整个连接就是没有任何收尾信号地直接断开，那更可能需要先排查网络层或客户端超时设置，而不是急着怀疑审核。

5. 被截断的调用还计不计费：不同厂商结论可能不同，别套用

这是开发者最容易想当然的一点：既然内容被审核拦下来了，是不是就不该计费？实际情况因厂商而异，本文不给出统一结论，需要开发者自己去核实当前调用的这家厂商官方计费文档里对这种场景的具体说明——有的场景下模型已经实际生成了部分token、只是输出侧被过滤，这部分token的计算成本已经发生，计费与否要看厂商政策；有的场景下请求在进入模型之前就被输入侧审核拦截，模型可能根本没有运行推理，计费逻辑也可能不同。与其凭经验猜测，不如在账单出现异常时，直接对照该次调用的request id去官方计费文档或工单渠道核实，这比自己假设一个通用规则更可靠。

6. 业务确实需要豁免审核怎么办：走官方申请渠道，不要自己绕过

如果业务场景本身合法合规，只是因为专业内容（比如医疗、法律、安全研究等领域天然会涉及一些敏感词）被误判拦截，或者是企业内部工具场景需要相对宽松的审核策略，正确的做法是通过厂商提供的官方申请渠道去申请例外或白名单，而不是在客户端自己做二次处理去绕开审核结果。以阿里云百炼为例，其官方文档说明了用户可以在控制台查看安全护栏的检测结果和风险标签，如果确实需要对特定内容做例外处理，可以通过工单渠道提交加白申请；这类流程通常需要说明具体的业务场景和使用主体，走的是平台审核过的正式例外通道，而不是绕过审核本身。总的来说，接口返回200却是空内容或被截断，几乎总是内容安全审核在某个环节起作用，先查清楚是哪个字段、哪个环节触发的，再决定是调整业务侧的重试逻辑，还是走正式的例外申请渠道，比反复猜测网络问题要有效得多。