规则引擎
第一代AI助手技术，基于预设规则和固定模板响应用户输入，以早期Siri为代表，无法处理表达变化。
核心事实
时间轴 (近 90 天)
规则适合边界清晰、变化少的场景；检索适合需要引用私有知识、要求可追溯的场景；纯生成适合开放式、容错率高的任务。
规则引擎指用预设的if-else逻辑或正则表达式处理确定性任务，优势是速度快、成本低、结果可预测。
在电信反欺诈中，纯规则容易被绕过，纯模型在冷启动和可解释性上偏弱，常见做法是规则负责高确定性的硬拦截，模型负责发现规则覆盖不到的新型模式。
传统自动化方案通常依赖规则引擎或简单关键词匹配，难以理解上下文和语义关联，例如无法区分“温度略高于设定值但持续时间极短”与“温度持续超标”的语义差异。
如果一条普通规则、过滤器、更好的表单或常规算法就能解决问题，就不应使用大语言模型，因为LLM按消息计费且永远计费，而规则运行不花钱。
规则引擎的输出完全可复现、可解释，能充当数据进入账簿前的守门人。
很多流程用规则引擎或简单条件判断就能跑得很好，硬塞模型反而增加成本和不确定性
健康架构是“规则先行、AI兜底”，即先用确定性规则过滤常规情况，仅将边角案例交给模型处理
规则引擎基于预定义条件执行自动化动作，不依赖模型推理，行为可预测、可审计、成本近乎为零
将 AI 审查输出接入 CI 流水线并配置规则引擎，仅当问题触发特定代码模式（如内存分配后无释放、锁未释放路径）时才阻断合并，其余问题以注释记录但不阻塞流程，可以解耦发现量与修复量。
还有 24 条时间轴事件
全部知识事实 (20)
样本过于简单则模型无学习价值，过于困难则可能引入噪声学习信号干扰训练，最有效的学习发生在略高于当前能力但仍可企及的区域
65%已验证微调适合让模型学习特定输出风格或领域语气，而RAG通过外挂知识库实现即改即用，两者在工程中常结合使用
65%待验证规则适合边界清晰、变化少的场景；检索适合需要引用私有知识、要求可追溯的场景；纯生成适合开放式、容错率高的任务。
50%待验证规则引擎指用预设的if-else逻辑或正则表达式处理确定性任务，优势是速度快、成本低、结果可预测。
50%待验证在电信反欺诈中，纯规则容易被绕过，纯模型在冷启动和可解释性上偏弱，常见做法是规则负责高确定性的硬拦截，模型负责发现规则覆盖不到的新型模式。
50%待验证传统自动化方案通常依赖规则引擎或简单关键词匹配，难以理解上下文和语义关联，例如无法区分“温度略高于设定值但持续时间极短”与“温度持续超标”的语义差异。
50%待验证如果一条普通规则、过滤器、更好的表单或常规算法就能解决问题，就不应使用大语言模型，因为LLM按消息计费且永远计费，而规则运行不花钱。
50%待验证规则引擎的输出完全可复现、可解释，能充当数据进入账簿前的守门人。
50%待验证规则引擎基于预定义条件执行自动化动作，不依赖模型推理，行为可预测、可审计、成本近乎为零
50%待验证健康架构是“规则先行、AI兜底”，即先用确定性规则过滤常规情况，仅将边角案例交给模型处理
50%待验证很多流程用规则引擎或简单条件判断就能跑得很好，硬塞模型反而增加成本和不确定性
50%待验证将 AI 审查输出接入 CI 流水线并配置规则引擎，仅当问题触发特定代码模式（如内存分配后无释放、锁未释放路径）时才阻断合并，其余问题以注释记录但不阻塞流程，可以解耦发现量与修复量。
50%待验证规则引擎与AI模型结合的混合架构在医疗、金融、教育等对可信度要求较高的领域正变得越来越常见。
50%待验证在需求—方案对照表中，精确算术用确定性代码，业务规则执行用规则引擎，结构化数据检索用SQL或API，关键词精确匹配用搜索引擎，需求预测用统计或ML模型；灵活文档摘要、语义文档发现、自然语言界面适合LLM，高风险自动化操作必须配合确定性控制和人工监督。
50%待验证在数据积累不足时，可先用简单的规则引擎加A/B测试逐步迭代提醒策略，避免过早引入模型带来的维护成本和不可解释性。
50%待验证传统智能文档处理（IDP）流水线通常由 OCR、模板匹配、规则引擎三部分组成，对已知文档格式识别准确率不错，但面对新格式往往失效。
50%待验证纯规则引擎做漏损检测只能发现数据对不上的情况，无法判断差异是否值得追、该怎么追，会产生大量误报。
50%待验证选型时建议先用规则引擎跑基线，若规则能覆盖 80% 的情况，剩余长尾交给 d1-3B 处理。
50%待验证自动客服系统通常基于‘知识库+规则引擎’或轻量级对话模型运行，设计目标是用最小交互完成高频标准化请求，倾向用静态字段替代人工核验
50%待验证仅靠规则引擎或静态策略很难覆盖智能体行为的所有场景
50%