Stripe 用一个 AI 助手，把风控规则从 30 分钟压缩到 1 分钟

在 Stripe 的 AI Day 上，一个看似不起眼的功能演示，暴露了风控领域正在发生的深层变化：不是更强的模型，而是 AI 开始直接接管“人最痛苦的那段工作”。规则编写，这个长期依赖经验和语法记忆的活，被大语言模型彻底重构了。

真正的反转：风控最难的不是模型，而是“人写规则”

在大多数人的认知里，欺诈管理的核心是模型准不准。但 Stripe Radar 的演示一上来就给了一个反直觉的事实：机器学习这部分，很多用户早就“够用了”。Radar 的模型基于 Stripe 全网数据，对单笔交易的一千多项特征打分，自动放行正常交易、拦截高风险流量。

真正让风控团队头疼的，是第二层：规则。因为当业务规模起来后，欺诈不再是“随机噪声”，而是带着模式、有针对性的进攻。诈骗者会迅速试探你的防线，你一拦，他就换姿势再来。于是规则变成一场长期拉锯战。

问题在于，把“我感觉这类交易不对劲”转成一条可执行的规则，本身就很反人性：字段在哪、运算符怎么写、通配符如何匹配、规则之间怎么组合——这些都不是风险分析师真正擅长的事。模型很聪明，但人被规则语法拖慢了。

一个演示，把规则编写的痛点摊在台面上

Stripe 让 Radar 团队的工程师 Vibhav 扮演一家虚构公司的风险分析师。这家公司卖的是高端定制地毯，业务火了，欺诈也跟着来了。

Vibhav 先演示了“传统正确姿势”：进入风控页面、新建拦截规则、查找和邮箱相关的字段、翻文档确认语法、理解运算符和通配符……这一套流程对新人极不友好，而且哪怕是熟手，也很难说一次就写对。

然后他切换到 Radar assistant：直接用自然语言描述——“拦截包含或以 lolhi 结尾的电子邮件地址”。助手基于大语言模型理解意图，反复澄清细节，生成最终规则表达式，并且可以立刻在历史数据上回测。

效果很直观：原本需要二三十分钟的工作，被压缩到了一分钟以内。不是因为规则变简单了，而是人终于不用再当“语法编译器”。

从“帮你写规则”到“帮你想规则”，这一步更关键

如果说自然语言写规则只是效率提升，后半段关于恶意退款的演示，才真正显露出 Radar assistant 的野心。

恶意退款的问题在于：交易本身是“合法”的。真实银行卡、真实收货地址、真实用户，但在收到商品后发起争议。对卖高价羊毛地毯的 Floorence 来说，一次失败的争议，意味着既没了货款，还要吞下高昂的生产成本。

当 Vibhav 问“我该怎么写规则”时，Radar assistant 给出的不是单一答案，而是多条不同维度的规则思路：从银行卡层面、顾客历史行为，到账单地址，再进一步聚焦到高风险产品类型。

这里发生了一个角色转变：AI 不再只是把你的想法翻译成规则，而是在帮你缩小复杂规则空间，提示你“哪些方向值得试”。这对经验不足的分析师尤其重要，相当于随时有一个资深同事在旁边给建议。

连代码都帮你补上：AI 成了风控团队的“翻译层”

演示里还有一个很容易被忽略，但对实际团队协作极其重要的细节。

当分析师意识到“我需要按产品类型来做规则”时，却不知道系统里该怎么传这个元数据。过去，这一步通常意味着开需求、找工程师、来回解释背景。

Radar assistant 直接给出了 Python 示例代码，说明如何把产品类型信息传入系统。这不是写代码本身的价值，而是把业务语言翻译成工程语言。

对很多 AI 从业者来说，这一幕非常熟悉：真正拖慢落地的，往往不是模型能力，而是沟通和上下游对齐。Stripe 的选择是，用 LLM 把这层摩擦直接抹掉。

总结

这场演示透露的关键信号是：AI 在企业里的第一波价值，未必来自“更聪明的决策”，而是来自加速那些本就正确、但极其耗人的流程。Stripe Radar assistant 并没有取代风险分析师的判断，而是让判断更快变成行动。

如果你在做 AI 产品或内部工具，这里有一个很现实的启发：与其执着于再提升 1% 的模型指标，不如问一句——你的用户，是否每天都被某些“人肉 glue work”卡住？那些地方，往往才是 LLM 最容易、也最有价值的切入点。

关键词： Stripe Radar， AI 风控， 大语言模型， 规则引擎， AI 助手

事实核查备注： 需要核查：视频发布时间（2023-07-14）；Radar assistant 是否处于内测阶段及开放时间表；“一分钟 vs 二三十分钟”的时间对比是否为演示原话；Radar 模型分析“一千多项特性”的表述是否准确。