基于规则引擎的风控决策系统介绍与演示

项目介绍

项目地址：https://github.com/wnhyang/coolGuard

基于规则引擎的风控决策系统，旨在为企业提供高效、灵活且可扩展的风险控制解决方案。

核心功能

以下是终极目标，部分已经实现，部分未实现，开源版本不会包含所有功能

• 实时指标计算，同步决策，异步决策，反馈

• 普通字段与动态字段：普通字段支持字符串、整数、小数、日期、布尔值、枚举，动态字段通过普通计算计算而来，高度可配置

• 数据接入：灵活配置数据接入的入参和出参

• 指标：基于时间计算的指标，目前已有：求和、次数统计、最大值、最小值、平均值、关联次数、历史取值，未来计划加入：移动距离、移动速度、趋势、方差、标准差、业务链、连续次数（不同与次数统计，中间插入其他状态则重新统计）、公式等

• 规则：条件支持：普通条件、指标条件、名单条件、正则条件、公式/脚本条件，动作支持：添加标签、添加名单、设置字段、发送消息，可设置正式和模拟状态

• 策略：模式分为：顺序模式、最坏模式、投票模式、权重模式

• 策略集：编排策略，是规则引擎核心作用的体现

• 指标、规则、策略、策略集版本管理

• 事件中心：事件数据分析、可视化、报表

• 豁免管理：配置式豁免决策，临时通行

• 数据服务：名单、标签、IP/证件号/经纬度/手机解析

• 三方集成：将三方以配置的方式接入系统

• 流量治理：熔断、限流、降级

• 监控中心：指标/规则/策略/执行、结果、效率监控等

• 系统管理：用户管理、角色管理、权限管理、日志管理、系统配置等

• 高级实验特性：A/BTest、冠军挑战、回测、仿真、模型、图谱分析

技术栈

• JDK 17

• Maven 3.5+

• Spring Boot 3

• MyBatis-Plus

• Redisson

• MapStruct

• SaToken

• LiteFlow

存储与中间件

• MySQL 5.7+

• Redis

• Kafka

• Elasticsearch

架构

待补充

演示

字段

字段分为普通字段与动态字段，普通字段就是基础字段，表示接入系统的变量，类型有布尔、日期、枚举、小数、整数、字符串。动态字段是普通字段的初步加工，可以将其理解为函数，需要设置动态字段脚本，也就是公式，这里是用的是QLExpress。这里动态字段脚本只是普通的文本域，这是最简单的实现方式，如果想扩展考Mentions组件，像聊天输入框一样可以@某字段，终极方案就是使用编辑器组件，不仅能提示关键字还能提示方法等。

字段是系统的基础，用于后面的指标计算、规则配置、数据存储等等方面，非常重要。

另外，字段组是将字段进行分类，目前规划其主要作用是用于后面数据展示更清晰。

接入

字段定义了系统可以处理哪些变量，接入决定了数据接入的方式与转换方法。

接入的输入和输出都是可配置的，未来可以考虑加入加解密或者是身份认证等安全保障措施。

另外每个接入配置对应三个RequestMapping，分别是{accessCode}/test、{accessCode}/async、{accessCode}/sync，test用于接口测试，async用于异步决策，通常用于事后事件，计划是可以通过读取数据源或者订阅MQ方式接入，sync用于同步实时决策，这也是风控决策的重要体现。

已有的接入配置提供了前端快捷测试页面，参数根据配置的字段类型动态生成的，有的是输入框，有的是日期选择框，有的是开关，有的是选择框等。

应用

应用是对事件的定级划分，未来可以考虑以此做数据权限。图中展示的密钥暂时还没用。

指标

前面已经有很多篇关于指标的文章了，这里还是说一下。

之前的指标管理设置两个tab（运行区和编辑区），但后面在做策略集/策略/规则的管理时，将这个舍弃了，因为运行区的功能都能在编辑区体现，而且这样稍微有些割裂。优化后，运行的就体现在名称右面的标签上了，有历史版本但未运行的也体现了，可以通过搜索条件筛选。

目前只支持了图上这些类型，要注意的是不同的指标配置是不同的，所以整个表单也是动态的。

另外再讲一下指标有场景的划分，目前场景类型有应用和策略集，这是有点缺憾的。

如下，可以从应用和策略集的角度选择，但是缺少跨应用的，当然你说策略集角度时选择policy1.2和policy2.2这不就是跨应用吗？

确实，这样也没错，但是更好方法是为策略集设置多标签，从标签的角度选择。

如下，策略加上标签后，从标签角度选择就行了。这样既做到跨应用也有利于后面的事件分析。

比如app1和app2都有相关与登录的策略集

处置

处置就是风控决策结果，划分了等级，用于比较。

策略集

策略集编排的重要体现，目前只是文本域输入的方式写LiteFlow的EL，未来会做成像LogicFlow这样的。

可编排的不仅是策略，还有三方（其实除了本系统外都可以算三方，包含公司内部的，通常会是一些数据解析服务提供方、征信、公安涉诈等等，而且这些一般是付费通过包年包月或是计量的，未来还会加入这方面的管理），组合这些组件除了简单的条件分流，还可以是A/BTEST，仿真等等。

策略

策略我也发了好几篇文章讲过了，尤其是关于策略模式（顺序、最坏、权重、投票）推荐一看。

规则

简单来讲规则就是IF(x){a}ELSE{b}，如上条件是组合形式，命中后未命中都可以设置额外的内容，如：将本次事件中某些字段加入某些名单，为整个事件打标签，取事件中的手机、关联邮箱或webhook等等发送消息。

事件

决策的流程已经介绍完了，每笔事件都通过Kafka异步记录在ElasticSearch里，数据至少包含：1、字段；2、指标（信息、版本、结果）；3、策略集（即最终结果，包括策略集、策略与规则的信息、版本、结果等）；4、标签等等

es数据检索还未集成在项目中，计划是收费内容，敬请期待吧。

可视化是使用Kibana配置的DashBoard通过iFrame或外链方式还是使用Echart还待确定。

其他

基础的系统管理就不过多介绍了。

在线体验

计划中，方案后面再讲吧。

大致是：关注公众号，分配一个有效期为当天的账号密码，限制访问时间和权限，每天定时清空数据。

声明

前端源码仅对企业级用户开放，需付费购买。 未经授权，禁止使用本项目源码申请软著和专利，保留追究法律责任的权力！

联系

Github：https://github.com/wnhyang/coolGuard，关注项目发展

公众号：无奈何杨，关注多元内容

B站：无奈何杨，关注视频分享

QQ频道：https://pd.qq.com/s/crz7xwtsg，关注讨论聊天

服务与支持

从0到1：商业化的系统化路径与关键策略

在互联网与全球化竞争时代，商业化的成功早已不再是“灵光一现”的偶然，而是对市场规律、用户需求与资源整合的系统性实践。无论是科技初创企业还是传统行业转型，以下八个维度构成了商业化落地的核心框架。

一、市场验证：从假设到数据的科学决策

商业化的第一步是验证需求是否存在。以共享办公巨头WeWork为例，其早期通过小范围测试（MVP）发现：企业用户不仅需要灵活租赁空间，更依赖社群资源与增值服务。这一发现使其将盈利模式从“工位出租”转向“会员服务+企业生态”。
关键动作：

• 精准用户分层：例如拼多多通过聚焦“价格敏感型下沉市场”，避开与京东、天猫的直接竞争。
  
• 量化市场需求：使用TAM（潜在市场总量）、SAM（可服务市场）与SOM（可获得市场）模型，如智能硬件企业需评估技术渗透率与替代品威胁。
  
• 动态竞争分析：Netflix通过持续监测迪士尼+、HBO的内容投入与用户留存率，调整原创内容投资比例。

二、商业模式：平衡价值创造与变现效率

商业模式的本质是回答“谁付费？为何付费？”。典型案例包括：
- 订阅制（Adobe Creative Cloud）：降低用户一次性支出压力，提升长期收入稳定性。
- 生态分成（苹果App Store）：通过控制分发渠道抽取30%佣金，与开发者共享增长红利。
- 反向定价（拼多多团购）：用户规模越大，单价越低，刺激社交裂变。
设计要点：
- 避免“伪需求”陷阱：如部分O2O项目误将补贴驱动的伪需求视为真实市场。
- 成本结构优化：特斯拉通过垂直整合电池生产与软件自研，降低边际成本。

三、产品与运营：构建护城河的核心能力

商业化需确保产品具备可扩展性与差异化壁垒：
- 技术壁垒：大疆无人机凭借飞控系统专利，占据全球70%消费级市场份额。
- 用户体验：瑞幸咖啡通过App下单、自提配送网络，将咖啡消费流程压缩至1分钟。
- 供应链韧性：SHEIN凭借柔性供应链，实现从设计到上架仅需7天的快时尚模式。
关键指标：用户留存率（DAU/MAU）、客单价、交付准时率。

四、合规与风控：规避“看不见的冰山”

商业化的隐性风险常来自法律与政策：
- 行业准入：金融科技公司需申请支付牌照，医疗AI产品需通过FDA认证。
- 数据合规：欧盟GDPR要求企业明确告知用户数据用途，违规罚款可达全球营收4%。
- 知识产权：华为每年投入百亿美元研发，2022年PCT国际专利申请量全球第一。
应对策略：建立合规团队、定期审计数据流程、购买商业保险（如产品责任险）。

五、财务健康：从生存到扩张的阶梯

财务模型需回答“钱从哪来？钱去哪了？”：
- 早期阶段：依赖VC融资（如字节跳动早期获红杉资本投资），但需控制烧钱速度。
- 成长期：通过经营性现金流（如亚马逊AWS业务）反哺主业，减少外部依赖。
- 极端压力测试：假设用户增长停滞30%，现金流能否支撑6个月？

六、品牌与增长：从流量到忠诚度的跃迁

商业化需构建“认知-转化-留存”的正向循环：
- 品牌人格化：杜蕾斯通过社会化营销建立“幽默风趣”的品牌形象。
- 增长杠杆：滴滴早期用“司机邀请奖励”实现冷启动，Dropbox以“免费存储空间”驱动用户裂变。
- 私域运营：完美日记通过社群+小程序，将复购率提升至行业平均2倍。

七、团队与文化：商业化的底层驱动力

团队能力决定商业化的天花板：
- 核心能力互补：苹果“乔布斯（产品）+库克（供应链）”组合奠定硬件帝国。
- 激励机制：华为“全员持股”将个人收益与公司长期价值绑定。
- 组织敏捷性：字节跳动通过“OKR+扁平架构”快速试错，支撑多业务并行。

八、社会价值：商业可持续性的终极命题

商业化需平衡盈利目标与社会效益：
- 环境责任：特斯拉开放电动车专利，推动行业减碳。
- 伦理底线：谷歌AI团队制定“不作恶”原则，拒绝参与军事AI项目。
- 长期主义：可口可乐百年品牌建设证明，用户信任是穿越周期的终极壁垒。

结语：商业化是一场“理性与直觉”的平衡游戏

成功的商业化既需要数据驱动的理性决策（如成本测算、合规流程），也依赖对用户需求的感性洞察（如用户体验设计、品牌情感联结）。企业应在“快速试错-迭代验证”中寻找最优路径，最终实现从生存到引领的跨越。

国内社交App市场呈现“一超多强、垂直分化”的竞争格局，各平台在用户争夺、内容生态和商业化之间艰难平衡。以下为针对主流社交App的锐评，直指痛点与趋势：

1. 微信：国民级工具的“社交霸权”与生态困局

• 锐评：
  微信早已不是单纯的社交工具，而是集支付、内容、服务于一体的“数字生活操作系统”。其垄断性地位带来两大矛盾：

• • 社交绑架：朋友圈沦为“人设橱窗”，三天可见、分组屏蔽成为当代社交礼仪的讽刺；公众号打开率暴跌，订阅制被算法推荐击溃。
  • 生态过载：小程序、视频号、直播强行缝合，功能臃肿消耗用户体验，年轻用户开始用“小号”逃离熟人社交压力。
    核心矛盾：张小龙的“克制”理想 vs 腾讯的商业化焦虑。

2. 抖音/快手：短视频帝国的“社交幻觉”

• 锐评：
  短视频平台以“杀时间”能力称王，但社交属性始终薄弱：

• • 伪社交：评论区互动多为“玩梗”而非深度连接，关注关系链脆弱，用户本质是“围观者”而非“参与者”。
  • 算法霸权：推荐机制塑造信息茧房，社交推荐让位于机器意志，人际关系被流量逻辑异化。
    野望与局限：抖音强推“朋友”Tab和群聊功能，但用户心智仍停留在“刷内容”，社交转型任重道远。

3. 微博：舆论修罗场的娱乐至死

• 锐评：
  微博仍是公共事件发酵核心阵地，但已深陷结构性危机：

• • 饭圈化与撕裂：娱乐八卦霸榜热搜，社会议题常被情绪化解读，理性讨论空间萎缩。
  • 商业化反噬：广告、热搜竞价、明星营销过度透支公信力，普通用户沦为“数据劳工”。
    生存逻辑：靠“骂战”维持活跃度，用娱乐化掩盖公共性流失，成为情绪宣泄的“数字痰盂”。

4. 小红书：精致利己主义的“赛博橱窗”

• 锐评：
  小红书凭“种草经济”崛起，但面临价值观悖论：

• • 滤镜陷阱：人均中产、遍地“贵妇”的虚假人设催生焦虑，用户一边批判炫富，一边参与内卷。
  • 商业与真实性的博弈：软广泛滥、素人代写产业化，“真诚分享”标签摇摇欲坠。
    突围方向：从“炫富指南”转向实用主义，但能否摆脱消费主义裹挟仍是未知数。

5. B站：破圈后的“身份认同危机”

• 锐评：
  B站从二次元乌托邦走向大众化，代价惨重：

• • 社区文化稀释：“圈地自萌”的弹幕礼仪被流量冲垮，老用户哀叹“小破站变味”。
  • 内容通胀：知识区UP主批量生产“快餐式科普”，娱乐化内容挤压垂直小众领域。
    终极难题：如何在破圈增长与核心用户忠诚度之间找到平衡？

6. 其他平台：垂直赛道的生死局

• 知乎：“谢邀，刚编”成梗，精英人设崩塌，盐选专栏收割流量，知识付费变故事会。
• Soul：打着“灵魂社交”旗号，最终沦为“看脸App”的另一种形态，元宇宙概念难掩匹配机制空虚。
• 贴吧：远古巨兽的黄昏，盗版资源、低俗内容、机器人灌水成为“时代的眼泪”。

总结：社交App的集体困境与未来出路

• 共性痛点：

• • 流量内卷：用户增长见顶，争夺存量导致内容低质化。
  • 算法异化：人际关系被数据驯服，社交沦为“表演”。
  • 监管高压：实名制、内容审核、青少年模式压缩创新空间。

• 未来趋势：

• • 社交分层：熟人社交（微信）、兴趣社交（B站）、陌生人社交（Soul）界限模糊，跨平台“多栖生存”成常态。
  • 技术叙事：AIGC重塑内容生产，元宇宙概念试探虚实社交，但用户是否需要“另一个虚拟身份”仍需验证。
  • 返璞归真：年轻人转向线下活动、小众社群（如飞盘、剧本杀），或“反社交”产品（如专注App），折射出对数字过载的集体反抗。

最终结论：国内社交App的竞争已从“功能创新”转向“人性博弈”，谁能真正解决用户的孤独感与真实性需求，谁才能穿越周期。否则，再炫酷的算法和概念，终将沦为“数据废墟”。

个人博客：无奈何杨（wnhyang）

个人语雀：wnhyang

Github：wnhyang - Overview

前言

本文算是前文《基于LiteFlow的风控系统指标版本控制》的完善。

前文已经说明了在基于规则引擎系统中版本管理的重要性，并说明了主表+历史表的实现思路和实现方法。

依照着上篇“历史既是历史又是运行”的思路在前端项目中实现版本管理。开发版本不代表最终效果😂

指标状态流转

1、创建：无-待发布，新创建的指标都是待发布状态，数据落在主表中；

2、更新：待发布-待发布或已上线-待发布，简单来讲只要是更新都会回到待发布状态，更新并不改变指标的发布状态，只更新主表；

3、发布：待发布-已上线，发布后主表指标状态改为已发布，同时在版本库中生成一个最新版本，新增或修改LiteFlow表chain的EL表达式；

4、下线：已上线-待发布，下线后指标状态回到待发布状态，对应的LiteFlow表chain记录被删除；

5、版本切换：版本库-待发布，版本切换生效于版本库中某个版本用于切换某个版本到主表中，还需要再次发布才生效；

3、删除：待发布-无，删除某指标，清理指标历史数据。

个人博客：无奈何杨（wnhyang）

个人语雀：wnhyang

共享语雀：在线知识共享

Github：wnhyang - Overview

Elasticsearch 索引别名是一种极为灵活且强大的功能，它允许用户为一个或多个索引创建逻辑上的别名。这些别名用途广泛，涵盖查询、索引操作以及索引管理等多个方面。以下为一些常见的索引别名应用场景：

简化查询

通过创建别名，用户能够以更简洁的名称访问一个或多个索引。例如，若你有一个索引名为products_2024，可创建别名current_products以简化查询流程：

1
2
3
4
5
6

POST /_aliases
{
    "actions": [
        { "add": { "index": "products_2024", "alias": "current_products" } }
    ]
}

在执行查询时，只需使用别名：

1
2
3
4
5
6

GET /current_products/_search
{
    "query": {
        "match": { "category": "electronics" }
    }
}

如此一来，不仅使查询语句更为简洁，也降低了因索引名称变更而需大规模修改查询代码的风险，提高了代码的可维护性。

索引版本管理

当需要滚动更新索引（如按月或按年创建新索引）时，别名可用于指向当前活跃的索引。这种方式下，用户仅需更新别名，而无需对查询代码进行修改。

个人博客：无奈何杨（wnhyang）

个人语雀：wnhyang

共享语雀：在线知识共享

Github：wnhyang - Overview

此前，我们已经成功搭建起最为基础的聚类指标体系，涵盖计数、求和、最大值、最小值、平均值、历史取值以及关联次数等维度，为数据的初步洞察提供了有力支撑。与此同时，规划在未来进一步拓展指标范畴，引入方差、标准差、趋势、连续次数等更为精细化的指标，力求全方位、深层次地挖掘数据价值。而此次探索之旅的重点，则聚焦于业务链指标。

究竟什么是业务链指标呢？其实，从名称便能直观知晓，业务链即由一系列紧密相连、按特定顺序排列的业务环节所构筑的链条。就拿互联网产品来说，用户从登录应用程序伊始，继而查看头像、切回首页、查看评论，这一连串流畅自然的用户行为轨迹，便是一条典型的业务链。在现实的业务场景之中，业务链的涵盖范畴极其广泛，无论是电商购物流程里的搜索商品、加入购物车、下单支付，还是在线教育平台上的课程选择、试听、报名缴费，无一不是业务链的鲜活例证。这些业务链背后潜藏的海量信息，能够借助业务链指标进行量化呈现，进而助力企业精准把脉业务流程的运行态势、洞悉用户行为的偏好与规律，为优化产品、提升用户体验以及精心制定营销策略筑牢坚实的数据根基。

业务链｜埋点｜行为模式

从前面阐述的内容来看，这些业务链本质上不就是对用户行为采集后所做的数据分析嘛！没错，而且在互联网产品的世界里，它还有一个更为人熟知的名字 —— 埋点系统。

个人博客：无奈何杨（wnhyang）

个人语雀：wnhyang

共享语雀：在线知识共享

Github：wnhyang - Overview

前言

最近在做项目前端，使用的https://doc.vben.pro/，在登录过期时出现了无法再次登录的问题，在此记录一下。

项目前面那些直接略过，如果感兴趣直接看官方文档就可以 ，以下会根据解决过程附带部分官网说明。

个人博客：无奈何杨（wnhyang）

个人语雀：wnhyang

共享语雀：在线知识共享

Github：wnhyang - Overview

想必大家都有听过或做过职业和性格测试吧，尤其是现在的毕业生，在投了简历之后经常会收到一个什么测评，那些测评真的是又臭又长，做的简直让人崩溃，很多时候都是边骂边做，都什么玩意！？

然而，本篇就由此出发，把整个测评作为一个策略的话，其中每一项都是一条规则，通常每一条规则（问答）需要我们输入一个类似1-9的分数，1和9分别代表两个极端，最终这个策略会结合所有的问答结果计算出我们的性格/职业。这是如何做的呢？其实就是一种分类算法，就拿二维平面直角坐标系举例吧！

个人博客：无奈何杨（wnhyang）

个人语雀：wnhyang

共享语雀：在线知识共享

Github：wnhyang - Overview

参考

如何理解上下文这个概念？ | LiteFlow

🌯数据上下文的定义和使用 | LiteFlow

我的业务项目是否适合用LiteFlow？

在选择使用LiteFlow之前应该要对其有一些了解，不求熟悉源码，但对于其设计思想还是了解一下的。这将对于后面使用有很大帮助，官方文档和源码都是很好的学习路径哦！

如官网所讲的，为了实现编排，就要消除组件的差异，由此设计了上下文。而使用LiteFlow完成业务，上下文与组件的设计又是极其的关键。方法论还是交给会写论文的人来吧，我只能提供一些经验之谈。

下面还是通过项目https://github.com/wnhyang/coolGuard/来讲述吧。

个人博客：无奈何杨（wnhyang）

个人语雀：wnhyang

共享语雀：在线知识共享

Github：wnhyang - Overview

参考

手把手教你做用户画像：3种标签类型、8大系统模块-腾讯云开发者社区-腾讯云

用户画像最全解析,超详细!

复盘：如何从0到1设计触达系统 – 人人都是产品经理

用户运营：触达系统应该如何搭建 – 人人都是产品经理

触达系统进阶篇（一）：自动化消息 – 人人都是产品经理

【推荐系统】深入理解：从基础到前沿_推荐系统停留时间-CSDN博客

推荐系统[一]：超详细知识介绍，一份完整的入门指南，解答推荐系统相关算法流程、衡量指标和应用，以及如何使用jieba分词库进行相似推荐-腾讯云开发者社区-腾讯云

【机器学习：Recommendation System】推荐系统-CSDN博客

智能风控筑基手册：全面了解风控决策引擎

风控笔记06：一个完整的风控引擎，需要有哪些功能？

风控笔记07：最常用的风控工具-特征库

之前一直在讨论使用规则引擎搭建风控系统，但其实规则引擎应用可太广了。鲁迅曾经说过（假的😂）：“人类已经从IT时代走向DT时代，IT时代是以自我控制、自我管理为主，而DT(Data technology)时代，它是以服务大众、激发生产力为主的技术。这两者之间看起来似乎是一种技术的差异，但实际上是思想观念层面的差异。”

说是规则引擎的应用其实是大数据时代下，数据收集整合&分析与挖掘、实时处理、反馈、自动化、智能化过程中需要规则引擎。本文就探讨用户画像、触达、风控、推荐这些系统有哪些核心功能，又在哪里用到了规则引擎，以及它们在日常生活中的应用场景及如何协同工作，共同创造价值。

以下AI生成整理而成。

一、用户画像：构建个性化的桥梁

1.1 数据聚合与标签化管理

用户画像是个性化服务的基础，它通过收集和分析用户的行为数据、偏好信息以及社会属性等多维度数据，形成一个全面且动态的用户形象。这一过程不仅依赖于传统的CRM（客户关系管理）系统中存储的基本信息，还包括来自各种在线平台的行为轨迹，如浏览记录、购买历史、社交媒体互动等。

标签化管理是用户画像的核心之一。通过对用户进行细致入微的分类和标注，企业可以更加精准地识别出不同类型的用户群体，从而为他们提供定制化的产品和服务。例如，电商平台可以根据用户的购物习惯为其打上“时尚爱好者”、“科技发烧友”或“家庭主妇”等标签；内容平台则可能根据用户的阅读偏好设置“新闻迷”、“美食达人”、“健身爱好者”等标签。