混合系统关键在于控制流交叠、边界划分与兜底校验；规则应前置处理高确定性逻辑，模型处理模糊问题，需统一决策输入、配置化阈值、异常熔断及持续监控三类指标。
混合系统不是“规则加模型再拼起来”就行，关键在于控制流怎么交叠、边界怎么划、谁兜底谁校验。
规则引擎该用 rule-engine 还是手写 if/elif 链？
小规模、逻辑稳定、变更少的业务规则（比如“订单金额 if/elif 更轻量、调试直观、无额外依赖。一旦规则数超 10 条、条件嵌套深、或需热更新，就该切到专用库——rule-engine 支持 JSON 规则定义和运行时加载，但注意它不支持复杂对象方法调用；若需调用 user.is_vip() 这类逻辑，得提前把结果塞进 fact 字典里，否则会报 AttributeError: 'Fact' object has no attribute 'is_vip'。
- 避免在规则中做耗时操作（如数据库查询），应前置计算好字段
-
rule-engine的RuleSet不自动排序，规则顺序影响结果，需人工保证优先级 - 调试时启用
debug=True，它会在匹配失败时输出每条规则的评估路径
模型预测结果怎么喂给规则做二次校验？
不能直接把 model.predict_proba(x) 的原始输出丢进规则判断。要先做语义对齐：比如模型输出的是 {'fraud': 0.82, 'legit': 0.18}，规则层应只关心 fraud_score > 0.7 这个可解释信号，而不是原始 logits 或 softmax 向量。常见错误是规则直接比对 pred[0] > 0.5，但没考虑模型在验证集上的 calibrated threshold 实际是 0.63——这会导致线上误杀率跳升。
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
- 封装一个
get_decision_inputs(x)函数，统一返回字典，含model_score、model_label、rule_flags等字段 - 规则中禁止出现硬编码阈值，全部从配置文件或环境变量读取，例如
os.getenv('FRAUD_THRESHOLD', '0.7') - 模型输出异常（如 NaN、全零概率）必须被规则捕获，走 fallback 分支，不能让
np.nan > 0.7悄悄变成False
规则与模型谁该先执行？取决于延迟和确定性
高确定性、低延迟规则（如“身份证号格式非法”）必须前置——这类检查秒级返回且 100% 可靠，拦下无效输入能省掉模型推理开销。而模型更适合处理模糊边界问题（如“用户行为是否异常”）。反例是把模型放前面：当并发请求突增，GPU 显存打满导致 torch.cuda.OutOfMemoryError，整个链路卡死；而前置规则网关可快速熔断并返回 400 Bad Request。
立即学习“Python免费学习笔记（深入）”；
- 典型流水线：
input → rule_precheck() → model_inference() → rule_postcheck() -
rule_precheck返回dict(valid=True, error=None)，False则直接退出，不进模型 -
rule_postcheck负责兜底：比如模型判“高风险”，但规则发现该用户是内部测试账号，强制覆盖为“低风险”
最难的不是写代码，是界定哪些逻辑属于规则、哪些必须交给模型——这个边界会随数据分布漂移而变化。上线后得持续监控规则覆盖率（多少请求被规则直接拦截）、模型介入率（多少请求走到模型层）、以及规则-模型决策冲突率（比如规则放行但模型拦截），这三个数字比准确率更能暴露系统设计缺陷。
