企业官网建设流程全解析

1. 项目概述

1.1 核心需求解析

产生式系统是人工智能领域最经典的知识表示与推理模型之一，它在专家系统、智能决策、规则引擎等方向都有广泛应用。很多人在学习《人工智能》课程时都会遇到这个概念，教材里往往用“三枚钱币”或“动物识别”这类小例子来讲原理，但真正到动手实现时却容易卡壳——规则库怎么设计？推理机怎么写？事实库用什么数据结构？冲突消解怎么处理？

本文要做的，就是基于Python写一个完整的产生式系统示例，应用场景选为医疗诊断系统。选医疗诊断这个方向，是因为它的规则结构天然适合IF-THEN表达，比如“如果体温高于38.5度 且 有咳嗽 且 有咽痛，则诊断为上呼吸道感染”，这种知识表示非常直观，读者很容易理解产生式系统的设计思路。

项目包含三个核心模块：规则库（存储专家知识）、综合数据库（存放已知事实和推理中间结果）、推理机（控制规则的匹配、冲突消解和执行）。代码用纯Python实现，不依赖任何第三方库，适合入门学习和课设参考，稍微改造也能用到其他领域——比如设备故障诊断、电商推荐规则引擎、论文审稿意见分类等。

1.2 这个示例能解决什么问题

先说说学习产生式系统常见的痛点。教材上讲的产生式系统通常包含三个部分——规则库、综合数据库和控制系统（推理机），概念上很好懂，但一到编码就发现无从下手：规则是存在列表里还是字典里？匹配过程要不要做去重？多个规则同时满足条件时选哪个？循环终止条件怎么判断？

这套代码的价值在于，它把上述问题全部落实为可直接运行的Python代码，并且附带完整的推理路径输出。你运行程序后，输入几个症状，就能看到系统一步一步匹配规则、得出结论的过程，对理解产生式系统的正向推理流程非常有帮助。

无论你是AI方向的学生、准备面试的开发者，还是单纯对专家系统感兴趣的技术爱好者，都可以直接复用这套代码骨架，把它移植到自己的场景中去。

2. 产生式系统的基本结构与设计思路

2.1 三个核心组件的功能拆解

产生式系统之所以叫“产生式”，核心在于它的知识表示形式——产生式规则，也就是大家熟悉的“IF-THEN”结构。一个完整的产生式系统由三部分组成：

规则库（Rule Base）。规则库是系统的“知识大脑”，存储所有IF-THEN规则。每条规则包含条件部分（前件）和结论部分（后件）。在医疗诊断系统里，前件是患者的症状组合，后件是诊断结论。规则质量决定系统智能程度，设计时要注意规则之间的逻辑关系，避免矛盾或重复。

综合数据库（Working Memory）。综合数据库也叫全局数据库，是系统的“工作台”，存放初始输入的事实（比如“发热=38.7度”“咳嗽=有”）、推理过程中产生的中间结果和最终结论。在代码实现中，我使用一个列表来模拟这个数据库，每产生一条新事实就追加进去。

推理机（Inference Engine）。推理机是系统的“发动机”，负责完成三件事：模式匹配——扫描规则库，找出条件都被综合数据库满足的规则；冲突消解——当多条规则同时满足条件时，按照某种策略决定先执行哪一条；执行操作——把选定规则的结论添加到综合数据库中，然后继续下一轮匹配，直到无法推出新事实为止。

用生活化的比喻来说：规则库像一本菜谱，综合数据库像你手头现有的食材，推理机就像厨师——厨师看着菜谱，对照手里有什么食材，决定能做哪道菜，做完一道后再看看有没有新菜能做，直到食材组合不出任何新菜为止。

2.2 推理策略：正向推理与反向推理的选择

产生式系统的推理方式主要分正向推理和反向推理两种。

正向推理（Forward Chaining）从已知事实出发，不断匹配规则推出新结论，适用于“数据驱动”的场景，比如医疗诊断——你给系统输入症状，它为你推出疾病结论。反向推理（Backward Chaining）则先设定一个目标假设，然后反向寻找支持该假设的证据，适用于“目标驱动”的场景，比如故障排查——你怀疑是某个部件坏了，系统反向验证排查前提条件是否成立。

在医疗诊断场景里，患者往往会描述多个症状，医生需要综合考虑这些症状得出一个诊断结论，这本质上是一个从证据到结论的过程，所以本系统采用正向推理，更加贴近实际应用。后续如果想做“假设性诊断”，也可以扩展反向推理模块，两种推理各自的适用场景不同，并不冲突。

2.3 为什么用Python实现产生式系统

Python有三个特性让它在实现产生式系统时非常顺手：

第一是数据结构天然匹配。规则可以表示为字典，条件用列表存储，事实用字符串列表表示，这套组合用Python写起来极其自然。

第二是动态类型带来的灵活性。在推理过程中，事实和规则的结构可能随时变化，Python的动态特性减少了类型约束层面的负担，集中精力处理逻辑本身。

第三是生态优势。虽本示例不依赖第三方库，但后续如果想要扩展——比如用Flask做Web化问诊界面、用Pandas分析诊断数据——Python生态都能无缝衔接。

3. 医疗诊断系统的具体设计与代码实现

3.1 诊断领域与规则库设计

作为一个教学示例，不可能覆盖所有疾病，但要确保规则之间的逻辑关系真实合理。我设计了七种常见呼吸道相关疾病的诊断规则，覆盖发热、咳嗽、咽痛、流涕、头痛、肌肉酸痛、乏力等常见症状，规则设计如下：

• R1: IF 发热 且 咳嗽 且 流涕 THEN 普通感冒
• R2: IF 发热 且 头痛 且 肌肉酸痛 且 乏力 THEN 流感
• R3: IF 发热 且 咽痛 且 吞咽困难 THEN 扁桃体炎
• R4: IF 发热 且 咳嗽 且 胸痛 THEN 支气管炎
• R5: IF 发热 且 咳嗽 且 呼吸困难 THEN 肺炎
• R6: IF 发热 且 头痛 且 皮疹 THEN 麻疹
• R7: IF 咳嗽 且 咽痛 且 声音嘶哑 THEN 喉炎

规则设计有几条经验值得分享。第一条，规则之间尽量不要有嵌套依赖，否则会增加推理过程的复杂度；如果必须嵌套，要确保中间结论也在规则库中有对应的“源头规则”。第二条，条件数量不宜过多，3到4个条件比较合适，条件太多会导致匹配困难，一次性满足条件的概率过低，系统在诊断时可能什么也推不出来。第三条，症状用布尔值或枚举值（有/无）表示最合适，而不要用模糊值，否则规则匹配时你需要额外处理阈值问题，代码复杂度会大很多。

3.2 规则的数据结构选择

在Python中表示规则，我选择了字典加列表的组合：

rules = [ { "id": "R1", "conditions": ["发热", "咳嗽", "流涕"], "conclusion": "普通感冒", "description": "发热伴咳嗽流涕，多为普通感冒" }, # 其他规则类似 ]

每条规则是一个字典，包含四个字段：id是规则编号，conditions是条件列表（所有条件必须同时满足），conclusion是结论，description是对规则的文字说明，用于推理路径输出。所有规则放在一个列表里，推理机通过遍历这个列表来完成匹配。

为什么不用单独的Rule类？因为面向对象写法虽然规范，但对教学示例来说反而增加了理解成本。字典结构直观、访问方便、转JSON容易，后续如果要接入Web系统，直接序列化就能用。规则数量增加时，用列表存储天然支持顺序遍历和优先级控制。

3.3 综合数据库与事实表示

综合数据库用列表表示即可：

facts = []

初始时，用户输入的症状作为初始事实加入facts。推理过程中，规则结论也会作为新事实不断加入。比如用户输入“发热”“咳嗽”，规则R1匹配成功后，facts列表会增加“普通感冒”这个事实。

为了输出推理路径，我额外定义了一个全局变量用于存放启用过的规则：

used_rules = []

每触发一条规则，就把规则编号和结论记录下来。这样用户能清楚看到系统从症状到结论的完整推理链路，而非只给一个结果。

3.4 推理机的核心实现

推理机实现的核心是一个循环：反复遍历规则库，不断触发可匹配的规则，直到一轮遍历中没有产生任何新事实为止。

def forward_reasoning(facts): used_rules = [] changed = True while changed: changed = False for rule in rules: # 条件全部满足才算匹配 if all(cond in facts for cond in rule["conditions"]): conclusion = rule["conclusion"] if conclusion not in facts: facts.append(conclusion) used_rules.append({"rule_id": rule["id"], "conclusion": conclusion}) changed = True return facts, used_rules

这段代码的核心逻辑是：外层while循环负责控制推理轮次，内层for循环遍历全部规则，all()函数判断某条规则的所有条件是否都已在facts中。如果满足且结论尚未存在，则把结论加入facts，并记录启用规则。

这里的关键点在于，一条规则在一轮中最多触发一次改动。如果某个结论已经在facts中，就不需要重复加入，这样可以避免死循环。同时，因为新事实的产生可能让之前不匹配的规则变得可匹配，所以需要持续循环到某轮无变化为止。

3.5 输入处理与运行入口

完整的程序入口是这样的：

def main(): print("欢迎使用产生式系统——医疗诊断系统") print("请输入症状编号，多个症状用空格分隔，输完后回车") print("可选症状：1.发热 2.咳嗽 3.流涕 4.头痛 5.肌肉酸痛 6.乏力 7.咽痛 8.吞咽困难 9.胸痛 10.呼吸困难 11.皮疹 12.声音嘶哑") input_str = input("请输入症状编号：") input_ids = input_str.split() symptom_map = { "1": "发热", "2": "咳嗽", "3": "流涕", "4": "头痛", "5": "肌肉酸痛", "6": "乏力", "7": "咽痛", "8": "吞咽困难", "9": "胸痛", "10": "呼吸困难", "11": "皮疹", "12": "声音嘶哑" } facts = [] for i in input_ids: if i in symptom_map: facts.append(symptom_map[i]) if not facts: print("未输入有效症状，程序退出") return print("初始事实：", facts) final_facts, used_rules = forward_reasoning(facts) print("\n推理过程：") for item in used_rules: print(f"使用规则{item['rule_id']} → {item['conclusion']}") print("\n最终事实库：", final_facts) conclusions = [item["conclusion"] for item in used_rules] if conclusions: print("\n诊断结论：", "，".join(conclusions)) else: print("\n未匹配到任何诊断规则，请补充症状信息")

这段代码做了几件事：一是通过症状编号映射表降低用户输入成本，不用打中文，直接输数字，对初学者更友好；二是做输入校验，非法输入直接忽略；三是分步输出推理过程和最终结论，让整个系统行为透明可观察。

3.6 完整源代码

把上述代码整合成一个文件，完整代码如下：

# 医疗诊断产生式系统 rules = [ {"id": "R1", "conditions": ["发热", "咳嗽", "流涕"], "conclusion": "普通感冒"}, {"id": "R2", "conditions": ["发热", "头痛", "肌肉酸痛", "乏力"], "conclusion": "流感"}, {"id": "R3", "conditions": ["发热", "咽痛", "吞咽困难"], "conclusion": "扁桃体炎"}, {"id": "R4", "conditions": ["发热", "咳嗽", "胸痛"], "conclusion": "支气管炎"}, {"id": "R5", "conditions": ["发热", "咳嗽", "呼吸困难"], "conclusion": "肺炎"}, {"id": "R6", "conditions": ["发热", "头痛", "皮疹"], "conclusion": "麻疹"}, {"id": "R7", "conditions": ["咳嗽", "咽痛", "声音嘶哑"], "conclusion": "喉炎"}, ] def forward_reasoning(facts): used_rules = [] changed = True while changed: changed = False for rule in rules: if all(cond in facts for cond in rule["conditions"]): conclusion = rule["conclusion"] if conclusion not in facts: facts.append(conclusion) used_rules.append({"rule_id": rule["id"], "conclusion": conclusion}) changed = True return facts, used_rules def main(): print("欢迎使用产生式系统——医疗诊断系统") print("请输入症状编号，多个症状用空格分隔") print("1.发热 2.咳嗽 3.流涕 4.头痛 5.肌肉酸痛 6.乏力") print("7.咽痛 8.吞咽困难 9.胸痛 10.呼吸困难 11.皮疹 12.声音嘶哑") input_str = input("请输入症状编号：") input_ids = input_str.split() symptom_map = { "1": "发热", "2": "咳嗽", "3": "流涕", "4": "头痛", "5": "肌肉酸痛", "6": "乏力", "7": "咽痛", "8": "吞咽困难", "9": "胸痛", "10": "呼吸困难", "11": "皮疹", "12": "声音嘶哑" } facts = [] for i in input_ids: if i in symptom_map: facts.append(symptom_map[i]) if not facts: print("未输入有效症状，程序退出") return print("初始事实：", facts) final_facts, used_rules = forward_reasoning(facts) print("\n推理过程：") for item in used_rules: print(f"使用规则{item['rule_id']} → {item['conclusion']}") print("\n最终事实库：", final_facts) conclusions = [item["conclusion"] for item in used_rules] if conclusions: print("\n诊断结论：", "，".join(conclusions)) else: print("\n未匹配到任何诊断规则，请补充症状信息") if __name__ == "__main__": main()

4. 实操运行与测试结果

4.1 运行环境与基础配置

运行这段代码，只需要本机装有Python 3.6以上版本即可，不需要安装任何第三方库。如果你之前在本地没有配置过Python环境，可以参考以下流程快速搞定：

第一，从Python官网下载对应操作系统的安装包，安装时务必勾选“Add Python to PATH”选项，这样后续能在命令行中直接执行python命令。第二，安装完成后打开命令行，输入python --version确认版本号，正常会输出版本信息。第三，将上述代码保存为medical_diagnosis.py文件，在命令行中执行python medical_diagnosis.py，出现欢迎语即表示环境配置成功。

4.2 测试场景一：普通感冒的诊断

在程序提示下输入症状编号组合： 请输入症状编号：1 2 3

这个输入对应“发热”“咳嗽”“流涕”三个症状，程序执行结果如下：

初始事实： ['发热', '咳嗽', '流涕'] 推理过程： 使用规则R1 → 普通感冒 最终事实库： ['发热', '咳嗽', '流涕', '普通感冒'] 诊断结论： 普通感冒

这个测试场景验证了规则匹配和结论生成的正确性。输入三个症状，R1的三个条件全部满足，推理机触发R1，把“普通感冒”加入事实库，整个过程清晰可控，输出结果符合预期。

4.3 测试场景二：多重规则的触发

再测试一个更复杂的输入： 请输入症状编号：1 2 4 5 6

这个输入对应“发热”“咳嗽”“头痛”“肌肉酸痛”“乏力”五个症状，其中发热、头痛、肌肉酸痛、乏力恰好满足R2的条件，发热加咳嗽可能触发R1，但R1还差流涕条件。

程序执行结果：

初始事实： ['发热', '咳嗽', '头痛', '肌肉酸痛', '乏力'] 推理过程： 使用规则R2 → 流感 最终事实库： ['发热', '咳嗽', '头痛', '肌肉酸痛', '乏力', '流感'] 诊断结论： 流感

这里值得留意的细节是：R1虽然没有完全匹配，但它的“发热”“咳嗽”条件都已满足，只缺“流涕”，这个信息在更复杂的系统中可以作为“候选规则”的参考输出。本示例中没有做这个功能，但不失为一个后续扩展方向。

4.4 测试场景三：冲突消解的实际案例

来一个更有意思的场景： 请输入症状编号：1 2 3 7

这个输入对应“发热”“咳嗽”“流涕”“咽痛”。此时R1的三个条件全部满足，而R7“咳嗽”“咽痛”“声音嘶哑”还差“声音嘶哑”，所以不会触发。程序会输出：

初始事实： ['发热', '咳嗽', '流涕', '咽痛'] 推理过程： 使用规则R1 → 普通感冒 最终事实库： ['发热', '咳嗽', '流涕', '咽痛', '普通感冒'] 诊断结论： 普通感冒

但如果我们假设R7的条件也包括发热，即规则库是“R7: IF 发热 且 咳嗽 且 咽痛 THEN 喉炎”，那么输入“发热”“咳嗽”“咽痛”时，R1和R7会同时满足条件，产生两条候选规则，这时就涉及冲突消解。

本系统中由于不会同时出现两条规则的结论相同的情况，所以默认选择第一条匹配规则执行。这种策略是产生式系统中“按规则顺序优先”的典型做法。在实际应用中，可以让症状出现频率更高的规则排在前面，提高匹配命中率，保证诊断准确。

4.5 测试场景四：无匹配结果的情况

最后测试一个症状组合不足的场景： 请输入症状编号：6

输入“乏力”一个症状，程序执行结果：

初始事实： ['乏力'] 推理过程： 最终事实库： ['乏力'] 未匹配到任何诊断规则，请补充症状信息

这个输出也是预期内的行为。系统在没有足够证据的情况下不做盲目诊断，而是提示用户补充信息，这符合医疗诊断的基本安全逻辑——证据不足不下结论。

5. 常见问题与性能优化思路

5.1 规则无限循环的隐患排查

产生式系统最容易踩的坑是规则无限循环。比如你有两条规则——“IF A THEN B”和“IF B THEN A”，初始事实包含A，系统会不断在A和B之间来回切换，永不停止。

我的推理机通过两个机制避免这个问题：一是结论加入事实库前先检查是否已存在，如果已存在就不重复加入；二是只有事实库发生变化时才会开启新的一轮循环。这两个机制合在一起，保证了最终一定会在某轮不做任何修改后终止。

但如果你是扩展设计，规则数量多且相互依赖复杂时，建议再加一个计数器，限制最大推理轮数（比如100轮），超过直接报错退出，防患于未然。

# 在while循环中加入计数器 max_iterations = 100 iteration_count = 0 while changed and iteration_count < max_iterations: changed = False iteration_count += 1 # 原有遍历逻辑不变

5.2 规则冲突的处理策略

当多条规则同时可触发时，不同策略会带来不同结果。业界常用以下方法：

• 优先级排序：每条规则设置priority字段，冲突时优先执行高优先级规则
• 最近优先：优先执行结论与最近事实有关的规则
• 特定性优先：优先执行条件更具体（即条件数量更多）的规则
• 随机选择：在候选规则中随机选一条

在医疗场景下，推荐用优先级策略，因为不同症状和疾病之间的重要性不同。比如高热比低热更紧急，那么诊断高危疾病的规则应该优先匹配和触发。

5.3 规则库规模增大后的性能问题

本示例的规则库只有7条，性能可以忽略不计，但如果规则库扩展到数百条，每次遍历全部规则就会发现性能明显下降。优化方向主要有三个：

一是索引机制：按结论类型建立规则索引，比如所有结论为“呼吸道疾病”的规则放到一起，匹配时先根据当前事实缩小搜索范围。二是Rete算法：这是产生式系统最经典的高效模式匹配算法，CLIPS和Drools的底层都用它，核心思想是利用网络结构保存已匹配的中间状态，避免重复计算。但Rete实现复杂，教学示例中一般不展开。三是数据层优化：把规则和事实存入数据库，通过查询来加速匹配，适合规则库非常大且需要持久化的场景。

5.4 从教学示例到工程应用的扩展建议

写完这个教学示例之后，如果想把它做成真正可用的医疗诊断系统，还需要在以下方面下功夫：

融合不确定性推理。真实诊断中，症状对疾病的指向并非百分百确定，比如“发热”既可能是感冒也可能是肺炎。可以在规则中加入置信度字段，推理时根据置信度传播算法计算结论的不确定度，最终输出带置信水平的多个可能诊断。

支持逆向推理。正向推理适合数据驱动的场景，但医生有时会先假设某个疾病，再反向验证症状是否齐全。增加反向推理模块后，系统可以从目标假设出发，询问患者缺失的关键症状，更加贴合真实的问诊过程。

人机交互优化。目前是一次性输入全部症状，现实中患者可能一开始只描述主要症状，医生问一句答一句。改成交互式模式，推理到条件缺失时主动向用户提问，系统会更智能。

可视化决策过程。把推理路径渲染成决策树或流程图，对教学展示和系统调试都很有帮助，患者也能更直观地理解诊断结论。

6. 三个钱币问题——最简形式化示例

如果你刚接触产生式系统，看医疗诊断的代码可能还觉得复杂，不妨先看一个更经典的入门示例——三个钱币问题。题目描述是：有3枚钱币，排列状态是“正、正、反”，要求用产生式系统描述这个过程。

这个问题的形式化方式是：设置规则库，综合数据库存储当前三枚钱币的状态，推理机每次翻转一枚钱币，并在匹配条件时执行对应翻转规则。它可以很好展示产生式系统的状态空间搜索能力，适合作为理解和调试产生式系统的最小测试用例。

这个示例的核心代码如下：

# 三枚钱币产生式系统示例 facts = ["正", "正", "反"] rules = [ {"id": "F1", "condition": lambda f: f[0] == "正", "action": lambda f: f.__setitem__(0, "反")}, {"id": "F2", "condition": lambda f: f[1] == "正", "action": lambda f: f.__setitem__(1, "反")}, {"id": "F3", "condition": lambda f: f[2] == "反", "action": lambda f: f.__setitem__(2, "正")}, ] for rule in rules: if rule["condition"](facts): rule["action"](facts) print(f"触发规则{rule['id']}，当前状态：{facts}")

这里每条规则用lambda表达式封装条件判断和动作执行。执行结果会依次翻转第一枚和第二枚钱币，第三枚不变。换一个角度看，这个示例展示了产生式系统中“条件→动作”的执行模式，比医学诊断更接近底层逻辑，初学者可以把两者对照理解。

代码中的facts是一个列表，fact[0]表示第一枚钱币。lambda条件函数接收facts列表作为参数，返回布尔值决定是否执行动作。这个写法足够简单，也保留了产生式系统的结构特征，配合医疗诊断的完整代码，基本可以横扫教材中关于产生式系统的编程练习。

7. 实操心得与踩坑记录

7.1 设计规则时的坑

我在最初版规则设计时，把R2设计成“IF 发热 且 头痛 且 肌肉酸痛 THEN 流感”，但在测试时发现，输入“发热”“头痛”“肌肉酸痛”，系统会得出流感结论，然而这个结论在医学上站不住脚——没有乏力症状，流感诊断太草率。

后来我给R2补上了“乏力”条件，减少了误诊率。这给我的启发是：规则条件的设置不仅要满足逻辑匹配条件，还要考虑领域本身的专业约束，宁可条件多一个，也不要条件不足导致错误结论。对于规则数量大的系统，建议设计一张规则表，逐条审校条件组合的合理性。

7.2 代码实现上的教训

第一次写推理机时，我用的是for循环套while循环，判断条件写成了“if any(cond in facts for cond in rule['conditions'])”——这是一个经典的笔误。any表示任意一个条件满足就触发规则，而正确逻辑必须是all，即全部条件满足才触发。这个错误导致的后果是：只要患者有“发热”一个症状，就会被匹配到几乎所有的七条规则里。排错时花了很长时间，最后通过打印中间事实对比才找出来。

7.3 事实去重的重要性

推理机执行过程中，如果不检查结论是否已存在于事实库中，会出现重复触发同一规则的情况。比如R1第一次执行后把“普通感冒”加入facts，下一轮循环时R1条件依然满足，如果不去重就会再次触发R1，导致事实库中反复出现多条“普通感冒”，不仅记录冗余，还会干扰最终结论的输出。

在医疗诊断这样对准确性和可解释性要求高的场景中，推理过程的每一步都要保证可读，推理记录必须清晰无冗余，每一轮触发都应有对应的新事实产生，这才是产生式系统“可解释性”价值的真正体现。

7.4 扩展思考：把规则改造成可配置化

当我尝试把规则数量从7条扩展到20条时，直接在代码里手写规则已经变得难以维护。于是我把规则抽到了一个JSON文件中，运行时通过json.load加载。这么做的好处是：修改规则不需要改动代码，运营人员也能维护规则库。

import json with open("rules.json", "r", encoding="utf-8") as f: rules = json.load(f)

rules.json的内容结构如下：

[ {"id": "R1", "conditions": ["发热", "咳嗽", "流涕"], "conclusion": "普通感冒"}, {"id": "R2", "conditions": ["发热", "头痛", "肌肉酸痛", "乏力"], "conclusion": "流感"} ]

这个改造只要五分钟，却让系统的可维护性提升了一个档次。同理，症状编号映射表也可以放到配置文件里，这样前端展示的症状列表和后端推理匹配的事实集合就能统一管理。

7.5 关注推理路径的可解释性

做这个项目最大的体会是，产生式系统的价值不止在于“得出一个结论”，更在于“能说清楚是怎么得出这个结论的”。专家系统与传统机器学习算法的核心区别就在这里——专家系统不会给你一个黑盒预测，而是给你一条清晰的推理链路。这条链路对要求高可解释性的行业场景非常关键，比如医疗诊断辅助、法律辅助决策、设备故障定位等领域。

所以代码里我特意用used_rules记录每一步触发的规则，并在输出中按顺序打印。后续在真实业务落地时，你应该把这条推理路径连同结论一起输出给用户，虽然可能牺牲一点简洁性，但换来的信任度增长是值得的。实际部署中，我还会在推理路径里记录触发时间和条件匹配详情，出了问题可以直接回溯是哪条规则判断失误，排查效率会高很多。

如果你正在学习产生式系统相关课程，或者需要实现一个简单的规则引擎，这份代码可以直接在你的环境里运行，动手改改规则库和事实，观察推理路径的变化，你对产生式系统的理解会比看十遍教材都更深刻。我个人踩过一轮坑之后的建议是，先把代码原样跑通，再改规则，最后才扩展结构，循序渐进会顺利很多。