夜雨聆风
做 AI 漫剧工具,为什么我们最后还是上了 Flink 风控?
我们在做 AI 漫剧工具时，核心能力主要依赖第三方大模型，包括：
-
文生图
-
图生图
-
图生视频
业务看起来是“用户发起一次生成请求，我们调用一次模型接口”，但真正跑起来之后，很快会遇到几个典型问题：
-
有人高频刷接口，消耗免费额度
-
有人批量注册账号薅模型调用次数
-
有人不断试探敏感 prompt
-
有人反复重试高成本的视频生成能力
-
同一设备或同一 IP 挂多个账号轮流调用
这类问题本质上都不是离线问题，而是 实时风控问题。
因为如果等第二天再看报表，成本已经消耗了，视频已经生成了，接口也已经被刷了。
所以在这个场景里，我们比较适合用 Flink 做实时风控。
一、这个场景为什么适合 Flink？
因为 AI 工具天然就是事件流系统。
平台里会持续产生这些事件：
-
用户登录
-
提交 prompt
-
上传图片
-
发起文生图请求
-
发起图生图请求
-
发起图生视频请求
-
模型返回结果
-
审核返回结果
-
计费成功或失败
-
重试请求
这些数据持续进入 Kafka，然后由 Flink 消费处理。
Flink 在这里主要做三件事：
-
按用户、设备、IP 维护实时状态
-
统计短时间内的高频行为
-
多流关联后输出风险结果
二、一个典型风控案例
我们重点看一个很常见的场景：
识别高频滥用高成本模型的用户
比如某个用户在 10 分钟内出现下面这些行为：
-
连续发起很多次生成请求
-
多次调用图生视频
-
失败后快速重试
-
多次命中审核边缘规则
-
同一设备切多个账号继续调用
这种用户大概率不是正常创作，而是在：
-
薅免费额度
-
批量跑素材
-
试探审核边界
-
滥用高成本模型能力
这就是一个很典型的实时风控场景。
三、Flink 实战里怎么做？
1）先定义统一事件流
不管是文生图、图生图还是图生视频，建议先统一成一类生成事件，比如：
{
"user_id": "u1001",
"device_id": "d2001",
"ip": "1.1.1.1",
"action_type": "image_to_video",
"request_id": "r9001",
"prompt": "一个少女在雨夜街头回头",
"cost_type": "high",
"event_time": "2026-03-17 10:01:03"
}这样后面做风控统计会简单很多。
2）按用户维度做 keyBy
核心逻辑一般先按 user_id 聚合：
stream
.keyBy(GenerateEvent::getUserId)
.process(new RiskProcessFunction());然后在状态里维护用户短周期行为，比如：
-
最近 10 分钟请求次数
-
最近 10 分钟图生视频次数
-
最近 10 分钟失败次数
-
最近 10 分钟审核命中次数
3）用 State 保存实时画像
这一步是重点。
比如可以维护：
-
requestCnt10m
-
videoCnt10m
-
failCnt10m
-
reviewHitCnt10m
-
deviceSet
-
ipSet
如果发现：
-
请求次数过高
-
视频生成次数异常
-
失败重试很多
-
设备/IP 变化异常
就可以打上高风险标签。
4）接入审核流和结果流做关联
单看“请求流”还不够，最好把这几类流一起接进来：
-
生成请求流
-
生成结果流
-
内容审核流
-
账号登录流
这样可以拼出完整链路：
-
用户发请求
-
审核是否命中
-
生成是否失败
-
失败后是否快速重试
-
是否切账号继续调用
这个比单纯做一个 count 更有价值。
四、一个简单规则示例
比如定义这样一条规则：
风险规则
用户在 10 分钟内满足以下条件：
-
总请求数 >= 20
-
图生视频次数 >= 5
-
失败重试次数 >= 5
则输出高风险告警。
伪代码可以理解成这样：
if (requestCnt >= 20 && videoCnt >= 5 && retryCnt >= 5) {
outputRisk(userId, "HIGH_RISK");
}输出结果可以写到 Kafka、Redis 或风控服务：
{
"user_id": "u1001",
"risk_level": "high",
"hit_rules": [
"10m_request_cnt_ge_20",
"10m_video_cnt_ge_5",
"10m_retry_cnt_ge_5"
]
}然后业务侧决定是否：
-
限流
-
禁止图生视频
-
强制人工审核
-
临时封禁账号
五、这个场景里 Flink 的价值是什么？
核心就三点。
第一，实时拦截成本风险
AI 业务和普通业务最大的区别是：
每次请求都在花钱。
尤其图生视频这种能力，一旦被刷，损失是实时发生的。
所以必须在调用链路中间就把高风险请求拦下来。
第二，能看连续行为，不只看单次请求
单条请求可能很正常，但连续看就很异常：
-
短时间高频调用
-
失败就立刻改 prompt 重试
-
切设备、切账号继续生成
这类问题更适合 Flink 这种流式处理。
第三，方便做多维度风控
AI 平台不能只看账号，还要看：
-
用户
-
设备
-
IP
-
请求类型
-
成本等级
-
审核结果
Flink 比较适合把这些维度串起来。
六、落地时最容易踩的坑
1. 只看账号，不看设备
很多刷子账号是一次性的，但设备会复用，所以设备维度一定要做。
2. 只做内容审核，不看成本滥用
AI 产品里，“没违规但很烧钱”本身也是风险。
3. 状态不清理
如果状态里一直存历史数据，任务很容易越来越重，必须做好 TTL 和过期清理。
4. 规则写死
建议把阈值做成可配置，比如请求数阈值、视频次数阈值、失败次数阈值，都支持动态调整。
七、总结
对于 AI 漫剧工具来说，风控不只是审核内容，还要控制：
-
接口滥刷
-
免费额度薅取
-
高成本模型滥用
-
多账号多设备作弊
-
连续试探审核边界
这类问题的共同特点是：都发生在实时链路里。
所以比较自然的做法就是：
-
Kafka 接入事件
-
Flink 实时计算行为特征
-
规则命中后输出风险结果
-
业务系统做限流、审核或拦截
一句话总结：
在 AI 漫剧工具里，Flink 风控的核心价值，不是做复杂大而全的平台，而是在高成本模型调用链路上，尽早识别异常行为。