1. 课程导入

在风控系统中，策略的准确性、可解释性与迭代效率往往决定业务能否在风险与增长之间取得平衡。很多团队在早期用大量 if/else 堆叠规则，随着规则数量增长，代码迅速变得难以维护：同一个条件组合散落在多个分支中，新增一条规则可能影响已有逻辑，测试用例难以覆盖，业务方也无法直接确认策略是否符合预期。决策表（Decision Table）正是为解决这类问题而生的结构化建模工具，它把复杂的条件组合与对应动作以二维表格形式显式表达，让策略从“藏在代码里”变成“摆在桌面上”。

一、决策表在风控中的价值定位

决策表的核心价值可以概括为三点：可读、可验证、可治理。可读，是指业务、产品、风控、研发可以用同一张表沟通，减少需求传递中的歧义；可验证，是指每一行规则对应明确的条件组合与动作，便于逐条设计测试用例；可治理，是指规则可以版本化、灰度发布、快速回滚，并支持审计追踪。在反欺诈、授信审批、交易拦截、营销反作弊等场景中，决策表常被用作规则引擎的配置载体，或作为策略文档与代码之间的“单一事实来源”。

二、从需求到决策表：方法流程

设计一张可落地的决策表，通常遵循以下流程：

1. 明确决策目标：确定这张表要输出什么结果，例如“通过/拒绝/人工审核”，或风险等级、额度区间。
2. 识别条件维度：列出影响决策的输入字段，如设备指纹、历史逾期次数、交易金额、IP 归属地等。
3. 枚举条件取值：把连续值离散化，例如“逾期次数”分为 0、1-2、3 及以上。
4. 定义动作集合：明确每个决策结果对应的动作，如拒绝、通过、转人工、加验证码。
5. 填充规则行：为每种有意义的条件组合指定动作，避免遗漏与冲突。
6. 检查完备性与互斥性：确认所有可能输入都有匹配规则，且同一输入不会命中多条冲突规则。
7. 评审与版本化：由业务与技术共同评审，纳入版本管理并记录变更原因。

下面是一个简化的决策表结构示例，用于说明条件与动作的对应关系：

条件维度：
  risk_level      : low | medium | high
  is_blacklist    : true | false
  amount          : small | large

动作：
  decision        : pass | review | reject

规则示例：
  IF risk_level = high   AND is_blacklist = true  THEN reject
  IF risk_level = high   AND is_blacklist = false THEN review
  IF risk_level = medium AND amount = large       THEN review
  IF risk_level = low    AND is_blacklist = false THEN pass

三、实战案例概览：交易反欺诈决策表

本课程将围绕一个贯穿始终的实战案例展开：某电商平台的交易反欺诈决策表。该场景的输入包括用户历史行为、设备信息、交易金额、收货地址等，输出为“通过、验证、人工审核、拒绝”四类动作。随着课程推进，我们会从最简单的三条件决策表开始，逐步引入优先级、默认规则、冲突检测、命中日志、灰度发布与性能优化等内容。你会在每一章看到同一案例的演进，从而理解决策表不是静态文档，而是可运行、可观测、可迭代的风控资产。

四、常见误区与复盘思路

初学者在设计决策表时容易陷入几个误区。第一，把决策表当成“万能表格”，试图在一张表里表达所有逻辑，导致条件维度爆炸；第二，忽略默认规则，认为所有输入都能被显式覆盖，结果线上出现未命中；第三，条件取值边界模糊，例如“金额较大”没有明确阈值，评审时各执一词；第四，只关注规则本身，不记录命中日志，导致线上问题无法复盘。正确的做法是：分层设计决策表，明确默认动作，所有阈值可配置，并为每次决策保留可追溯的输入与命中规则。

五、本课程学习目标与整体框架

完成本课程后，你将能够：独立完成从需求到决策表的建模；识别并解决规则冲突、覆盖与优先级问题；将决策表落地为可配置的规则引擎；设计命中日志与监控指标；并在团队中推动决策表的评审与治理流程。课程整体分为五个模块：基础概念与建模方法、条件组合与冲突处理、工程化落地与性能优化、实战案例迭代、治理与复盘。每一章都围绕一个可操作的问题展开，最终你会得到一套可复用的决策表设计方法论。

接下来，我们将从决策表的基本结构与条件组合开始，逐步进入真实的风控决策场景。请准备好你的案例背景，因为从第一章开始，我们就会用同一张表贯穿始终。