企业官网建设流程全解析

前阵子大促复盘，运营同学甩给我一个让我挺难受的数据：风控拦截的订单里，有超过30%被人工复核后判定为正常订单。换句话说，差不多每三个被系统拦下来的订单里，就有一个是误伤。这个数字在平时还能忍，大促期间每个订单都是真金白银，误伤直接等于把流量和成交白送给竞对。

那段时间我一直在想一个问题：为什么我们的风控模型在存量特征上做得越来越精细，KS值一路提升，可落到业务上的"精准度感知"却变差了？后来我把思路从"这个人像不像坏人"转到了"这个人做的事合不合理"上，才慢慢摸到了Action Model的门道。

这篇文章我会把这套思路完整捋一遍，重点讲清楚三件事：传统风控模型在精细化运营里为什么越来越吃力、Action Model到底在建模什么、以及行为序列建模的三种落地路径各自适合什么场景。这是上篇，先把"道"和"术"讲透，下篇再聊具体的策略设计和工程实现。

1. 为什么传统风控在精细化运营里越来越吃力，根子出在"静态"两个字上

1.1 传统风控的两大支柱和它们共同的软肋

国内主流电商平台的风控体系，十有八九是由两部分构成的：一部分是规则引擎，一部分是评分卡模型。规则引擎长什么样？就是"如果用户在30分钟内下单超过5笔且收货地址相同，则命中XX风控策略"。简单直接，运维同学和风控同学都能看懂，出问题也好解释。评分卡模型则是把用户的注册天数、历史订单金额、登录设备数量、IP风险等级这些特征扔进一个逻辑回归或者XGBoost里，输出一个风险分，超过阈值就拦截。

这两套东西刀耕火种了很多年，到今天依然有存在的价值，但是它们的共同软肋也摆在那：依赖的全是"存量特征"。

什么叫存量特征？就是用户到当前这一刻为止，已经积累下来的历史信息。注册时间、历史消费、设备指纹、IP归属地，这些信息有一个共同特点——它们是"这个人过去是谁"的投影，而不是"这个人现在正在做什么"的描摹。

打个比方，传统风控相当于门口保安看了一眼你的工牌，觉得"嗯，这人在这儿干了三年了，应该是自己人"，就放你进去了。但如果你是一个混进来的外人，偷了一张工牌呢？保安这个动作根本发现不了。

我在实际业务里见过太多这种例子。一个黑产团伙会专门养号，把账号的注册时间、历史订单、信用分都养得很漂亮，传统评分卡模型看这些特征，完全就是一个优质用户。但如果你去观察他下单那一刻的微观行为，破绽就会露出来：他根本不浏览商品详情页、不加购、不比较，直接搜索精确款号然后秒下单、秒支付。存量特征这边是"岁月静好"，行为序列那边是"着急忙慌"，这种割裂感就是Action Model要抓的东西。

1.2 精细化运营带来的三个新挑战

再说说"精细化运营"这四个字到底给风控添了什么堵。我理解精细化运营的含义是：平台不再把用户当成一个整体，而是把用户分成新客、成熟客、高价值客、价格敏感客、大促冲动型客等不同群体，每个群体配不同的货、不同的券、不同的营销策略。

这本来是运营的事，但落到风控头上就麻烦了。

第一个挑战是用户分层变细之后，一刀切的拦截策略行不通了。以前风控就两种决策，放行或者拦截，边界清晰。现在运营给你提需求：对高价值用户尽量不要拦截，用静默验证的方式处理；对新客可以稍微严格一点，但别上来就封号；对价格敏感用户要做好券的核销校验，防止被撸。同一个行为，放在不同用户身上，要给出不同响应。传统评分卡模型就是一个分数配一个阈值，根本表达不了这么细的分层逻辑。

第二个挑战是风险形态从"身份风险"变成了"行为风险"。早年间的黑产主要靠盗号、养号、虚假注册，拼的是身份信息层面的攻防。现在身份伪造的成本越来越高，黑产也进化了，开始走"真人操作+群控系统+批量任务"的路子。账号是真的、人是真人、设备是干净的，唯一异常的是行为路径——他们会在某个时间窗口内用同样的节奏做同样的事。这种风险，静态特征几乎测不出来，必须看行为序列。

第三个挑战是误伤代价在大促期间被无限放大。大促期间流量贵、转化机会稀缺，平台每拦错一个订单，损失的不止是这个订单的GMV，还有这个人整个大促周期的消费潜力。我见过一个很典型的案例：一个价值比较高的老用户，因为账号在异地登录过，加上当晚支付速度快了一点，被模型判了高风险，下单被拦截。用户一气之下转到竞对平台完成了购买，后续一整年都没再回来消费。账面上看，风控拦下了一笔"可疑"订单，实际上平台亏掉了一个年度LTV可能上万的高价值用户。

1.3 复盘那天，运营同学的一句话点醒了我

那次大促复盘会，运营同学看完成交漏斗数据之后说了一句让我印象很深的话："你们风控现在拦人，看的都是'这个人以前干过什么'，但运营做活动看的全是'这个人现在要干什么'。两边节奏根本不在一个频道上。"

当时我第一反应是他在甩锅，但回去细想，他说到了点子上。精细化运营的本质是"在正确的时间，用正确的方式，服务正确的人"，它的落点全部在当下这个时刻。而传统风控模型的落点在历史。中间的鸿沟，就是行为序列信息。

想明白这一点之后，我开始系统地研究怎么把用户的微观行为动作利用起来。这个方向，圈内一般叫Action Model。

2. Action Model到底在建模什么：不是"做了什么"，而是"怎么做"

2.1 一个直观的对比：同样都是下单，路径天差地别

先看两组真实的用户行为序列。为了保护业务数据，细节我做了脱敏，但节奏和结构是真实的。

先说一个正常用户的典型路径。某个用户想买一台蓝牙耳机，他的行为序列大概是这样的：

打开App -> 在搜索框输入"蓝牙耳机" -> 浏览搜索结果列表，从上往下刷了大概两屏 -> 点进第一个商品看看 -> 退出来 -> 又点进第二个商品 -> 看了看评价 -> 在评价区和详情页之间来回切换了两次 -> 加了购物车 -> 没马上付款 -> 又去搜了一下"蓝牙耳机 降噪" -> 对比了两款 -> 回到购物车 -> 犹豫了一会儿 -> 提交订单 -> 选择支付方式 -> 完成支付

整个过程大约持续了12到15分钟，中间有大量"回头""比较""停顿"的细节。

再来看一个黑产账号的路径。这个账号是某个"撸券"团伙控制的，目标是某品牌放出的一张限量优惠券：

打开App -> 直接搜索精确的商品款号 -> 结果页第1个商品直接点进去 -> 详情页停留了不到3秒 -> 直接加购 -> 3秒后进入结算页 -> 使用优惠券 -> 提交订单 -> 支付成功

全程不到40秒，中间没有任何一个多余动作。

这两条路径放在存量特征里看，差异微乎其微：都是正常注册账号，都是正常IP，都是正常设备。但如果把行为序列展开，差异巨大到连不懂算法的人都能一眼看出来。

2.2 Action Model的核心洞察：行为序列是一段"永远不会说谎"的证据链

我做了这么多年风控，一个很深的体会是：行为可能会伪装，但行为序列不会完全伪装。

单个动作是可以伪装的，比如黑产可以让脚本模拟"点击详情页"这个动作。但一段序列是由无数个动作的先后顺序、时间间隔、互相关系构成的，要全部伪装得像真人，成本会指数级上升。因为人做事的节奏有天然的"不规律规律"——会有犹豫、回头、比较、分神，而脚本和自动化工具的节奏是直来直往、高度统一的。

所以Action Model真正建模的目标，不是用户"做了哪些动作"这个结果，而是用户"做出这一串动作的方式"本身。落到工程上，我一般把它拆成四个维度：

第一个维度是动作顺序。正常人买东西，通常遵循"搜索/浏览 -> 比较 -> 加购 -> 支付"的渐进链路，即使跳步，也很少从"搜索"直接跳到"支付"。黑产和脚本的行为顺序则经常是"搜索精准关键词 -> 瞬间支付"，中间所有"犹豫类"动作全部省略。顺序的合理性，本身就是区分信号。

第二个维度是时间节奏。这是最值钱的一个维度。同一个动作，真人做出来和脚本做出来，时间分布是完全不同的。真人浏览一个商品详情页，停留时长大概呈长尾分布，从几秒到几分钟都有，而且和"有没有仔细看评价""这个商品值不值得纠结"高度相关。脚本做出来的停留时长则高度集中在一个非常窄的区间里，比如每次都是2秒到3秒。我把这个叫"节奏指纹"，它很难被刻意伪装。

第三个维度是目标集中度。正常用户买东西是有"探索欲"的，即使目标明确，也会顺便看看同类商品、看看关联推荐。但风险用户的目标极其聚焦——搜什么、进哪个链接、买哪个SKU，全程几乎没有偏离。目标集中度这个指标，在"薅羊毛"场景下特别有效，因为它天然地刻画了"我是来买我想要的东西的"和"我是来完成一个任务的"之间的区别。

第四个维度是路径异常度。如果说前三个维度是"单点观察"，路径异常度就是"全局视角"。比如一个用户前5分钟还在浏览母婴用品，突然切到一个和她历史偏好完全无关的3C产品并立刻下单；再比如一个用户白天完全不活跃，凌晨3点到5点之间连续完成好几次精确购物。这些路径层面的"跳变"和"不合常理"，单独看某一个动作都正常，串在一起就不正常了。

2.3 一个帮我跟业务方解释Action Model的类比

为了跟运营和审核团队解释Action Model，我经常打一个比方：传统风控是看照片抓人，Action Model是看监控录像抓人。

看照片抓人，你只能记住这个人长什么样——这是画像特征。如果嫌疑人整了容、化了妆，照片就失效了。但看监控录像抓人不一样，你能看到他走路的姿势、在案发地附近徘徊的样子、伸手去拉门把手时的犹豫，这些是行为和动作。人可以化妆，但很难彻底改变走路的节奏和做事的习惯。

这个类比业务团队一听就懂，后面推项目的时候帮了大忙。做算法的人很容易陷入纯技术思维，但要真正把Action Model落地，让审核团队、运营团队愿意用、敢用，第一关永远是"让人看懂你在干什么"。

2.4 画像特征没有消失，只是退居二线

很多同学对Action Model有一个误解，以为搞了行为序列建模，传统的画像特征就没用了。这是不对的。在我实际的建模思路里，画像特征不但没被扔掉，反而承担了一个更重要的角色——先验概率。

一个注册了5年、历史消费20万、从来没有过纠纷记录的用户，和一个昨天刚注册、今天第一次下单的用户，即使他们现在的行为序列长得很像，风险含义也是不一样的。新用户行为怪一点可能是还不熟悉App，老用户行为突然变怪那才更值得警惕。

我习惯的做法是：用画像特征给用户一个"基础风险概率"，用Action Model产出一批"行为异常信号"，两者做融合。画像负责回答"这个人的底子干不干净"，Action Model负责回答"这个人此刻做的事情合不合常理"。精细化运营要的恰恰是这个组合——既知道这个人是谁，又知道他正在干什么。

3. 行为序列建模的三种典型路径，以及我为什么踩过复杂模型的坑

明确了Action Model建模的对象之后，下一个问题就是：技术上到底怎么建模？行为序列这个东西，本质上是变长数据，而且包含时间间隔，直接塞进传统的结构化特征框架里会非常别扭。我实际尝试过三种路径，各有各的适用场景，不存在的"哪个更好"的绝对答案。

3.1 路径A：Action Graph规则，用最直接的方式抓确定性模式

第一种路径是构建"行为图规则"，这也是我最早尝试的方式。思路很简单：把用户的行为定义成节点，行为之间的转移定义成边，然后人工去梳理哪些"行为子图"是高风险模式。

举个例子，下面这条规则就是从真实黑产样本里抽出来的：

如果用户在30秒内完成"搜索 -> 点击详情 -> 加购 -> 下单 -> 支付"整条链路，且搜索词与商品标题精确匹配，且支付方式为"新绑定的银行卡"，则命中高风险策略。

这条规则本质上是把黑产那条"直来直往"的路径，用图的形式显式地表达了出来。早期我们靠这种规则，快速拦截了一大批脚本类的薅羊毛行为，可解释性极好——审核团队看到命中记录，立刻就能明白用户干了什么，不用猜。

但它的缺点也同样明显：规则的表达能力有限，只能抓"已经见过且能总结出来的模式"。黑产稍微改一下路径，比如在搜索和点击之间插入一个5秒的随机等待，再多次刷新页面，规则就抓不住了。而且规则之间容易出现冲突，维护成本高，特征维度一多，规则集就乱成一团。

所以Action Graph规则适合用来"兜底确定性风险"——只要命中，基本可以断定是风险，误伤率极低。但它不适合用来"发现新风险"。

3.2 路径B：行为序列的统计分布建模，用异常检测的思路找偏离

第二种路径是不要尝试"定义什么是正常的路径"，而是反过来，先去统计"大部分正常用户的路径长什么样"，然后把"明显偏离大部分人的路径"标出来。

具体操作上，我会对每个关键动作做两件事：一是计算动作间隔的统计分布（比如从点击详情到加入购物车，间隔时间在正常用户中大概是多少），二是计算动作转移概率矩阵（比如从浏览详情页之后，有多大概率去比较其他商品，有多大概率直接进入结算页）。

建模的时候，不需要给每条行为序列硬编码规则，而是用统计学手段测量"这条序列跟上千条正常序列的分布差异有多大"。如果一个用户从"点击详情"到"提交订单"只用了1.2秒，而正常用户的间隔分布里这个值的99分位都要8秒，那这个用户的行为就属于"统计意义上的异常"。

这种方法的优势是比规则灵活得多，能覆盖很多"说不清哪里不对但就是不对"的模糊场景。劣势是我需要足够大的正常行为样本去刻画分布，而且一旦用户的整体行为习惯发生变化（比如App改版导致用户路径整体变化），统计分布就要重新校准。

3.3 路径C：深度序列模型，让模型自己学习动作之间的长程依赖

第三种路径，也是这两年圈子里讨论比较多的，是用LSTM、Transformer这类深度序列模型，把用户的行为序列直接喂给模型，让它自动学习什么样的序列组合是异常的。

这个思路在技术上是"最正确"的——因为行为序列本质上是时序数据，深度序列模型就是为这种数据设计的。它能自动捕捉动作之间的长程依赖关系，比如"用户在某次搜索之后，过了很久才发生支付动作"这种跨越多步的关联模式，用统计方法很难显式建模，但Transformer可以靠注意力机制学出来。

在实际应用里，我也确实看到深度序列模型在某些场景下能把AUC推高不少，尤其是数据量足够大、行为链路足够长的时候。但它在风控领域有一个绕不开的天花板：可解释性。

风控不像推荐系统。推荐系统推错了，用户的损失顶多是"刷到了一条不感兴趣的广告"；风控拦错了，直接影响用户能不能下单、能不能用券，客服会被打爆，运营会追责。模型必须能回答"为什么拦这个人"。深度模型输出的那个风险分数，很难转化成业务侧能理解的语言，这导致它更适合做"第二道防线"——在规则和统计方法漏掉的长尾风险里做补充，而不是直接站在前台做最终决策。

3.4 三种路径怎么选：我的原则是"可解释性优先，数据量决定复杂度"

很多同学来问我这三种方式到底怎么选，我给的建议很朴素：

在大多数业务落地场景里，我都是先用Action Graph规则把确定性风险兜住，再用统计分布建模覆盖"模糊异常"，最后用深度序列模型做长尾补充。三层叠加，既保证了实时决策的确定性，也保证了新风险的覆盖度。

说到深度模型，我多说一句踩过的坑。早年我特别迷信"模型越复杂效果越好"，一口气上了Transformer，效果确实不错，AUC比之前高了快两个点。但上线之后问题来了：第一，线上推理延迟翻了几倍，大促峰值根本扛不住；第二，某个策略命中之后，审核团队来问"为什么这个用户被拦了"，我解释不清；第三，模型在夜里的行为分布和白天的行为分布差别很大，数据漂移把准确率打得七零八落。后来我才意识到，风控场景里，模型效果只是及格线，可解释性、实时性和稳定性才是决定能不能上线的关键。这个认知我花了小半年才真正想明白，写在这里希望后来的人少走点弯路。

4. 落地Action Model之前，必须想清楚的五个工程问题

上篇的最后一部分，我想聊五个在工程落地时一定会踩到的问题。这些坑如果不在项目初期想清楚，后面返工的成本会非常高。

4.1 数据埋点：行为事件的定义，比模型算法更影响效果

做行为序列建模，第一步卡住你的往往不是算法，而是数据。同一个"加购"行为，在不同团队的定义可能完全不一样：是用户点了"加入购物车"按钮就算？还是加购成功弹窗出现才算？还是用户加了车之后又减了也算？如果这些事件的埋点口径没有拉齐，后面所有统计分布都是错的。

我建议项目启动的第一周，风控算法、数据开发和客户端的同学坐在一起，把关键行为事件的定义逐个对齐。像"搜索""浏览详情""加购""结算页到达""支付成功""退款申请"这类核心动作，要明确事件名、触发时机、附带属性。另外特别注意：事件的时间戳别用客户端上传时间，最好用服务端接收时间，不然用户手机时钟不准会直接干废所有间隔统计。

4.2 实时性：模型复杂度必须和工程链路匹配

Action Model的价值在于"实时识别当下正在发生的行为"，所以推理链路天然要求低延迟。如果你用的是深度序列模型，跑一次推理需要几十毫秒，在支付环节根本等不起。这个约束直接决定了你能在线上用什么模型、不能用什么模型。

我的建议是分层部署：最实时的那一层（比如支付前决策），只放Action Graph规则和轻量的统计模型，保证整体延迟在10毫秒以内；深度模型放到异步链路里，做离线的批量扫描，用于识别团伙和回溯分析。等你在离线异步里发现了新的风险模式，再把它固化成实时规则，这样既保住了实时性，又让深度模型的价值真正发挥出来，而不是为了用而用。

4.3 冷启动：新用户的行为序列太短，怎么建模

这是一个特别现实的问题。Action Model依赖行为序列，可新用户就是没有行为序列。他一进来就下了人生第一单，你怎么用行为序列判断他是不是黑产？

我的处理方式是"分层兜底"：对于行为序列长度低于阈值的新用户，以画像特征和设备风险为主，Action Model的信号只作为辅助参考，不做主要判断。等用户的行为序列足够长了，再逐步提高Action Model的决策权重。这个"行为长度阈值"我一般定在5到10个关键动作，太少的话统计意义太差，判断起来不放心。

4.4 评估体系：模型指标不等于业务结果

传统风控模型的评估，大家习惯看AUC、KS这些模型指标。但精细化运营场景下，这些指标很容易骗人。比如你用一个复杂模型把AUC从0.85提到了0.87，看起来很漂亮，结果发现它拦截的那些"高风险"订单里，真正会让平台损失钱的只增加了0.01%，反而误伤的好用户多了0.5%。这种情况下AUC是涨了，业务结果反而更差了。

所以我做精细化运营项目时，评估口径会换成一套"业务可感知"的指标：

这套指标虽然不那么"科研"，但是在业务沟通会上特别好使。运营同学关心的不是你的KS涨了多少，而是"你帮我拦住了多少风险、又让我少流失了多少正经用户"。做精细化运营的风控，本质上是在帮平台算一笔风险与体验的账，算得越清楚，越能获得业务团队的信任。

4.5 可解释性：风控场景绕不开的关卡

最后再聊一下可解释性。这可能是Action Model落地中最容易在后期被卡住的一环。我的做法是：无论内部用了多复杂的模型，对外输出的决策理由一定要回归到"人话"。

举例来说，模型内部可能是用Transformer捕捉到了"用户从搜索到支付间隔过短且没有浏览详情页"这个模式，但对外展示给审核团队看的决策理由是："用户支付速度显著快于正常用户，且未浏览商品详情，与平台正常用户的购物习惯差异较大。"这样审核团队能快速判断要不要人工复核，运营也能跟用户解释清楚。

为了做到这一点，我一般会给最终决策加一个"决策解释层"，把模型的判断映射到几个可解释的风险因子（支付过快、路径跳变、目标过度集中等），再按风险因子的贡献度排序输出。这个解释层本身不参与模型计算，但负责把模型的"黑盒结论"翻译成"业务可理解的理由"。

上篇写到这里，核心的逻辑框架差不多讲完了。老实说，我从"传统静态特征"转向"行为序列建模"的这大半年，最深的体会是：风控算法这个岗位，真正的分水岭不在于你会不会调Transformer，而在于你愿不愿意跳出"算分数、设阈值"的舒适区，去理解一段行为背后真实的人性——正常的犹豫、正常的比较、正常的比较半天最后没买，这些都是有温度的。而Action Model的本质，恰恰就是把这些"有温度的正常"变成模型眼里的先验知识，让机器学会分辨：谁在像人一样买东西，谁在像机器一样"完成任务"。

下篇我会接着写策略侧的东西：怎么基于Action Model的输出设计分级处置方案，怎么把风控决策从"放行/拦截"升级成"弹窗验证、静默监控、限权观察、人工介入"的多级体系，以及大促场景下的模型稳定性保障。如果你也在做风控或者精细化运营，欢迎带着问题来聊，我们一起把这条路踩得更实一些。