跳到主要内容

第 8 篇｜如何设计 Risk Engine，让系统真正“提前感知风险”

在第 7 篇，我们讲清楚了一件关键的事：

没有 Risk Engine 的 Harness，本质上是在“放大效率的同时放大风险”。

很多团队已经能做到：

  • AI 帮你找代码
  • AI 帮你改代码
  • AI 甚至能跑通流程

但上线之后，问题开始出现：

  • 改动范围判断错误
  • 隐性约束被破坏
  • 历史 bug 被“重新引入”

于是你会发现一个残酷的现实：

AI 提高了“变更速度”，但没有提高“变更正确率”

而 Risk Engine，就是解决这个问题的核心。

一、什么才叫“真正的风险感知”？

先明确一个误区：

❌ 风险感知 ≠ 写一堆规则校验 ❌ 风险感知 ≠ 静态代码扫描

真正的 Risk Engine，要做到的是：

在改代码之前，回答：这次改动“像不像过去出过事故的改动”？

这句话非常关键。

因为在企业系统里：

绝大多数事故，本质都是“历史问题的变种重演”

二、Risk Engine 的核心模型（必须理解）

Risk Engine 本质是一个“三段式推理”：

变更（Diff） → 语义表示 → 历史经验匹配 → 风险判断

拆开来看：

1️⃣ 输入不是“代码”，而是“变更”​

很多团队第一步就做错了：

去分析完整代码

但真正需要分析的是：

- updateStatus(order, "PAID")
+ updateStatus(order, "COMPLETED")

👉 风险永远来自“变化”，而不是“现状”

2️⃣ 把变更变成“语义向量”​

关键问题：

AI怎么理解这段 diff 的“含义”？

不是字符串匹配，而是：

  • 变量语义（order status）
  • 行为语义（状态变更）
  • 业务语义（订单生命周期）

👉 最终转成 embedding（语义向量）

3️⃣ 用“事故库”做相似度匹配​

核心逻辑：

当前变更 → embedding → 搜 incidents → 找最像的历史事故

如果命中：

{
  "incident": "订单状态错误导致资金重复结算",
  "similarity": 0.82
}

👉 就可以提前预警

三、Risk Engine 的数据基础（决定上限）

Risk Engine 的效果，不取决于算法，而取决于数据。

必须有三类数据：

1️⃣ Incidents（事故库，最关键）​

{
  "title": "库存重复扣减",
  "rootCause": "MQ重复消费",
  "affected": ["InventoryService.deduct"],
  "pattern": "非幂等操作 + 重试机制"
}

👉 核心不是记录“发生了什么”，而是：

抽象出“事故模式（pattern）”

2️⃣ Constraints（约束库）​

{
  "ORDER_STATUS_IMMUTABLE": {
    "description": "订单状态不可回退",
    "scope": ["OrderService.updateStatus"]
  }
}

👉 用于：

  • 提供风险解释
  • 增强判断可信度

3️⃣ Flow Graph（调用路径）​

👉 用于判断：

  • 影响范围
  • 是否跨关键链路（支付 / 库存 / 订单）

四、风险评分模型（可落地）

一个简单但有效的评分模型：

Risk Score = 相似事故权重 + 影响范围权重 + 约束冲突权重

1️⃣ 相似事故（最高权重）​

similarity > 0.8 → 高风险
0.6 ~ 0.8 → 中风险
< 0.6 → 低风险

2️⃣ 影响范围​

看 flow graph：

  • 是否影响核心链路（订单 / 支付）
  • 是否跨服务
  • 是否涉及 DB 写操作

3️⃣ 约束冲突​

检测：

  • 是否修改受约束方法
  • 是否违反已知规则

示例输出：​

{
  "riskLevel": "HIGH",
  "score": 0.87,
  "reasons": [
    "匹配历史事故：库存重复扣减（0.82）",
    "涉及核心链路：订单 → 库存",
    "违反约束：库存扣减必须幂等"
  ]
}

五、关键实现细节（90%团队会忽略）

⚠️ 1. Incident 必须“结构化抽象”​

错误做法：

{
  "title": "4月1号库存问题"
}

正确做法：

{
  "pattern": "幂等缺失 + 重试",
  "trigger": "MQ重复消费",
  "impact": "库存错误"
}

👉 Risk Engine 识别的是“模式”，不是“事件”

⚠️ 2. Diff 要做“语义增强”​

不能只看代码行，要补充：

  • 所属模块
  • 所属业务
  • 上下文方法

⚠️ 3. 必须引入“反例机制”​

否则会出现：

什么都报风险

解决方法：

{
  "safeCases": [
    "只读查询",
    "日志修改",
    "UI字段调整"
  ]
}

六、Risk Engine 的正确接入点

很多团队会问：

Risk Engine 应该放在哪？

答案是：

1️⃣ 必须在“代码生成之前”​

需求 → 分析 → Risk → 决策 → 生成代码

👉 否则只是“事后报警”

2️⃣ 同时在 CI 阶段再跑一遍​

PR → Risk Check → 阻断 or 放行

👉 形成“双保险”

七、从“提示风险”到“改变行为”

Risk Engine 的终极目标不是提示，而是：

改变开发行为

表现为：

  • AI主动规避高风险方案
  • AI建议更安全的实现路径
  • 系统拒绝明显危险的改动

八、企业落地的三个阶段

第一阶段：提示型​

  • 输出风险报告
  • 不阻断流程

👉 目标：建立信任

第二阶段：建议型​

  • 提供替代方案
  • 强制注入约束

第三阶段：控制型​

  • 高风险直接阻断
  • 必须人工确认

九、一个现实结论（很重要）

很多团队会问：

Risk Engine 能不能做到 100% 准确？

答案是：

不能，也不需要

它的价值在于：

  • 提前暴露 60% 的风险
  • 避免 80% 的重复事故

这已经足够改变团队质量曲线。

十、这一篇的本质

如果说前几篇解决的是：

  • AI怎么写代码
  • AI怎么理解系统

那么这一篇解决的是：

AI什么时候应该“停下来”

结尾

真正成熟的工程体系，不是“跑得更快”，而是：

知道什么时候该慢下来

Risk Engine，就是那个“刹车系统”。

下一篇，我们会继续往下走一层：

👉 如何设计 Constraint Engine，让AI在复杂系统中“始终做对的事”

当 Risk + Constraint 同时存在时，你的 Harness 才真正具备：

可控进化能力