生图接口前面该不该加一道准入,我的答案是加

把准入和执行拆开,是我在这类系统里唯一坚持的一条。生图那次调用只负责执行一个已经被放行的请求,能不能过安全边界,交给前面一次结构化判定:让对话模型吐一个封闭 schema 的 JSON,只有放行标志、命中的分类、策略版本三样,多一个字段、少一个字段、校验不过,一律不放行——而不是让程序去猜一段自然语言想表达什么。

留证这块比判定本身更容易被做砸。我这边落库的是审计 ID、策略版本、prompt 的摘要和调用主体,原文不往通用日志里抄。还有一点:策略拒绝、限流、鉴权失败、超时后不确定,这四种状态压成一个布尔值,事后对账会直接没法查。重试要带同一个幂等键,服务端给了等待时间就按它来,别自己拍脑袋退避。

代价很实在,多一次往返就是多一份延迟和成本,首屏卡这一下的产品,这套不适合硬上。

码住

多一次调用换一条完整审计链,UGC 场景我觉得这钱该花

延迟这块确实劝退,我们最后改成先出图、复核异步跟,体验才救回来

拒绝态和超时态混一起太真实了,我们线上对账对到怀疑人生

只存摘要那条,法务一般还会问原文要留多久,这个得提前谈

1 个赞