文章目录D48 · 规则写不完怎么办：模型与规则的分工边界开篇：规则写不完的时候第 1 章 决策分界：三条判据，四种处置1.1 「规则还是模型」是个伪问题1.2 三条判据1.3 三条判据组合出四种处置1.4 代价不对称：只调阈值，不改架构1.5 六个真实场景的画像1.6 本章最重要的一句话第 2 章 混合编排：三层流水线2.1 规则层要输出三种结果，不只是「是/否」2.2 模型返回分数，不返回结论2.3 冲突仲裁：两边结论不一致时谁说了算2.4 降级：模型挂掉时，系统不能变成筛子2.5 熔断：别让每个请求都去等超时2.6 安全：规则条件不要用 eval第 3 章 规则生命周期：把规则当成会变的资产3.1 规则库烂掉的四个征兆3.2 版本与影子发布3.3 影子发布：新规则先「只统计不生效」3.4 冲突检测：用样本实证，不用逻辑证明3.5 漂移监控：盯比例，不盯绝对值3.6 回滚：一键，且必须真的能用第 4 章 级联路由：成本、延迟与降级4.1 四层判断，四种成本量级4.2 预算：保证请求一定会在某个时刻结束4.3 异步层不占请求预算4.4 负载卸载：下游压力大时，少往上送4.5 缓存：被低估的成本杠杆4.6 成本对比：三条路线放一起算第 5 章 混合评测：分层指标、消融与阈值5.1 分三层看指标5.2 业务成本：唯一该优化的目标5.3 消融对比：每个组件到底值不值5.4 阈值扫描：业务成本曲线的最低点5.5 代价权重变了，阈值就得跟着变5.6 评测环节的三个纪律第 6 章 落地：团队、监控与节奏6.1 三档团队方案6.2 监控面板：盯这六个数6.3 上线节奏：四步，每步都有明确的验收标准6.4 兜底的最后一层：系统要能说「我不确定」第 7 章 什么时候不该上模型第一道门：能写成确定性的判断吗？第二道门：判断错了，程序能自动发现吗？第三道门：标准一周一变吗？还要看两个数明确不该上模型的几类场景反过来，什么时候该尽快上模型关键要点思考题下篇预告参考资料配套代码作者D48 · 规则写不完怎么办：模型与规则的分工边界写给在风控、审核、客服等场景里，被「规则还是模型」这个问题反复折磨的后端工程师本文是《60 天 AI 全栈转型：传统开发者的大模型工程师之路》S3 第三阶段第 3 篇配套代码仓库：gitcode.com/road-emblem/60-days-ai-stack开篇：规则写不完的时候上一篇 D47 我们讲法律文书，架构上给了一条明确的建议：规则优先，模型兜底。规则先过，能明确通过就通过，能明确拦截就拦截，判不了的交给模型；模型还拿不准，进人工。很多同学看完觉得「懂了，不就是规则 + 模型嘛」。但如果你真在业务里干过，就会发现这句话有个没说出口的前提：规则是可穷举的。而现实里，大量场景的规则根本穷举不完。我见过一个反欺诈团队，规则库两千三百条，运营每周要往里加策略。不是加一条，是加十几二十条——新的欺诈话术每周都冒出来。三个月后这个规则库变成了什么样？- 新人接手，问「R1847 现在还生效吗」，没人答得上来 - 改一条阈值，要跑三小时回归，因为不知道它会被哪 47 条规则间接影响 - 线上误杀率涨了 3 个点，查了三天，最后发现是半年前一条「白名单扩容」规则和新规则互相遮蔽 - 运营说「我