基于Python的规则引擎：从零构建症状筛查聊天机器人

1. 项目概述与背景

2020年初，当一种新型呼吸道疾病开始在全球范围内传播时，我坐在电脑前，萌生了一个想法：能否用代码构建一个简单的工具，帮助人们在焦虑和不确定性中，获得一些初步的自我评估指引？这个想法最终落地成了一个用Python编写的命令行聊天机器人，我把它叫做“Chatbot-Covid finder”。它的核心逻辑并不复杂：通过一系列结构化的问答，收集用户的症状、旅行史等关键信息，然后基于当时已知的、相对有限的医学知识库，给出一个风险评估和行动建议。今天回过头看，这个项目的代码本身可能显得有些稚嫩，但其背后关于如何用技术应对公共健康挑战的思考，以及从零构建一个完整交互流程的实践，对于任何想入门编程或了解基础症状筛查逻辑的朋友来说，依然是一次非常有价值的旅程。

这个项目本质上是一个基于规则的专家系统雏形。它没有使用任何复杂的机器学习模型，而是将当时卫生机构发布的常见症状清单（如发热、咳嗽、嗅觉味觉丧失、呼吸困难等）和风险因素（如旅行史）转化为一系列if-elif-else判断语句。用户就像在和一位极其耐心、但逻辑刻板的医生助理对话，一步步描述自己的状况。虽然它不能替代专业的医疗诊断——这一点必须再三强调——但在信息混乱的初期，这样一个工具能提供一种结构化的自我审视方式，缓解部分恐慌，并提示用户何时需要寻求进一步的医疗帮助。

从技术学习的角度看，它涵盖了Python入门阶段的多个核心概念：用户输入输出、变量与数据类型、条件判断、循环控制，以及最基本的程序流程设计。对于刚学完Python语法、想找个实际项目练手的朋友，这类需求明确、逻辑清晰、能直接看到交互效果的小项目，是巩固知识、培养“计算思维”的绝佳选择。接下来，我将完整拆解这个项目的设计思路、代码实现、可优化点以及背后的思考，你可以把它看作一份详细的“项目复盘报告”。

2. 核心设计思路与逻辑拆解

在动手写代码之前，明确设计目标是关键。这个聊天机器人的核心使命是：在安全边界内，进行初步的症状收集与风险提示。这意味着设计上必须遵循几个原则：第一，逻辑判断必须基于当时权威机构发布的、相对公认的症状列表；第二，输出结果必须是建议而非诊断，必须包含“咨询医生”的提示；第三，交互要足够简单，降低用户使用门槛。

2.1 信息维度的选择

我选择了以下几个信息维度进行收集，这些维度在2020年初被认为是相关的：

1. 基础信息：姓名、年龄、性别。年龄和性别可能影响某些症状的表现或风险等级（例如，当时有报道称部分男性患者可能出现睾丸疼痛或肿胀）。
2. 核心症状：
   • 发热：这是关键指标。不仅问“是否发热”，还追问了温度（华氏度）和持续时间，因为高热和长期发热是更值得关注的信号。
   • 呼吸道症状：咳嗽/喉咙痛、流鼻涕、呼吸困难。呼吸困难是重症的潜在标志，需要单独强调。
   • 特殊感官症状：嗅觉和味觉丧失。这在当时被认为是COVID-19比较特异的症状之一。
3. 流行病学风险：近期个人或家庭成员的旅行史。在疫情早期，旅行史是重要的风险判断依据。
4. 特定性别相关症状：针对男性用户，询问了睾丸肿胀或疼痛的情况。这是基于当时一些零星的临床观察报告，虽然并非普遍症状，但作为风险提示的一部分被纳入。

注意：症状清单会随着医学认识的深入而更新。例如，现在我们知道腹泻、头痛、极度疲劳等也是常见症状。这个项目反映的是2020年初的认知水平，在实际应用中，症状库需要根据最新的官方指南动态更新。

2.2 评估逻辑的设计

评估逻辑采用了分层判断和组合判断相结合的方式。

• 分层判断：某些严重症状会触发即时、强烈的建议。例如，只要用户报告了“呼吸困难”，程序会立即建议监测血氧饱和度，并指出低于95%即为紧急情况。这是一种“红色警报”式的处理。
• 组合判断：更多的情况是通过多个症状的组合来评估风险。程序里有一长串if-elif语句，用来匹配不同的症状组合模式。例如：
  • 发热 + 咳嗽 + 流鼻涕 + 呼吸困难 + 发热>3天-> 建议进行检测。
  • 仅流鼻涕或咳嗽-> 提示可能是普通感冒或过敏，但仍建议保持警惕和隔离。
  • 完全无症状-> 提示状态良好，但仍建议做好防护。

这种设计模仿了医生诊断时的思维过程：先排除危及生命的紧急情况，再对一系列症状进行综合研判。代码中的每一个if条件，都相当于一条“经验规则”。

2.3 交互流程的规划

交互流程设计为线性问卷式，但加入了简单的输入验证。对于所有“是/否”问题，如果用户输入了其他内容，程序会通过while循环持续提示，直到获得有效的“yes”或“no”输入。这确保了后续逻辑判断所依赖的数据是干净的。整个对话以问候开始，以按任意键结束，形成了一个完整的、有头有尾的交互会话。

3. 代码逐行解析与实现要点

让我们深入代码内部，看看每一个功能块是如何实现的，并讨论其中的技术细节和可以改进的地方。我将使用提供的代码作为基础进行解析。

3.1 环境准备与基础信息收集

程序的开头是标准的Python脚本结构，没有复杂的依赖，只需要Python 3环境。它从收集用户的基础信息开始。

print ("Hello,I am covid finder. What is your name?") name= input() print ("How old are you?") age= int(input()) print("Are you a male or female?") gender=input() gender=gender.lower() print ("OK "+ name + ", now answer the following questions in Yes or No.")

代码解读与要点：

1. input()函数用于获取用户从键盘输入的字符串。
2. int(input())将输入直接转换为整数。这里存在一个风险：如果用户输入的不是数字（例如“二十五”），程序会抛出ValueError异常并崩溃。这是一个需要改进的鲁棒性问题。
3. gender.lower()将用户输入的性别字符串转换为全小写。这是为了后续的条件判断（if gender == 'male'）不受大小写影响，确保逻辑一致性。这是一种很好的数据规范化实践。
4. 在问候语中直接嵌入用户姓名（"OK "+ name + ", ..."），能增加交互的亲切感，是设计上的一个小巧思。

改进建议： 对于年龄输入，应该增加异常处理（try-except块），防止非数字输入导致程序中断。

while True: try: age = int(input("How old are you? ")) break # 如果转换成功，跳出循环 except ValueError: print("Please enter a valid number for your age.")

3.2 核心症状采集与输入验证

这是程序最核心的部分，通过一系列问答收集症状。以“发热”为例，逻辑最为复杂。

print ("Do you have fever?") feveryn=input() feveryn=feveryn.lower() if (feveryn=='yes'): print ("How many degree fahrenheit?") feverdegree=int(input()) if(feverdegree>102): print("That is quite a high temperature.") print ("For how many days? Please write the number only.") feverdays=int(input()) print ("Have you taken any medicine? If so, please mention the name.") medicine=input() elif (feveryn=='no'): feverdegree=int(0) feverdays=int(0) else: while(1): print("Please answer in yes or no.") feveryn=input() feveryn=feveryn.lower() if(feveryn=='yes'or feveryn=='no'): break # ... (后续重复if-elif逻辑为发热的yes/no分支赋值)

代码解读与要点：

1. 条件分支（if-elif-else）：这是程序的骨架。根据用户对“是否发热”的回答，进入不同的分支。回答“yes”则收集详细信息；回答“no”则将相关变量设为0；回答其他内容则进入else分支。
2. 输入验证循环（while）：在else分支中，使用while(1)（一个无限循环）来强制用户输入有效答案。只有当输入被规范化为‘yes’或‘no’后，才用break语句跳出循环。这个逻辑在后面的是/否问题中被提取成一个更简洁的模式。
3. 变量初始化：即使用户回答“no”，也显式地将feverdegree和feverdays设置为0。这确保了后续所有判断逻辑中这些变量都有定义，避免了潜在的NameError。这是一种防御性编程的好习惯。
4. 单位问题：代码中温度单位使用了华氏度（Fahrenheit）。这对于非美国地区的用户可能不友好。在更通用的版本中，应该提供选项或使用摄氏度。

改进建议：

1. 抽象输入验证函数：后面所有的是/否问题都重复了类似的验证循环。可以定义一个函数来封装这个逻辑，使代码更简洁、易维护。

   def get_yes_no_input(question): while True: response = input(question + " (yes/no): ").lower().strip() if response in ['yes', 'y']: return 'yes' elif response in ['no', 'n']: return 'no' else: print("Please answer with 'yes' or 'no'.")

   然后调用它：feveryn = get_yes_no_input("Do you have fever?")
2. 温度输入处理：同样需要增加异常处理，并考虑单位转换。

   while True: try: feverdegree = float(input("How many degree fahrenheit? ")) break except ValueError: print("Please enter a valid number.")

3.3 逻辑判断与建议输出

在收集完所有数据后，程序进入一系列复杂的条件判断来输出建议。这些判断语句是项目“知识”的核心。

if(feveryn=='no' and coughyn=='yes' and runnyyn=='no' and breathingyn=='no' and smellyn=='yes' and tasteyn=='yes'): print ("May be it is a normal cough. Try home remedies like honey,lemon & hot water drink,licorice etc.") print("If anything serious occurs like continuous coughing for hours or breathing difficulty, contact a doctor soon.") if(breathingyn=='yes'): print ("Try to manage an oxymeter and measure your oxygen saturation. Below 95% is an emergency and needs medical attention.") if(travelyn=='yes' or travelyn2 =='yes'): print("I believe the travel history that you have provided has enough reasons to be afraid of. Even if you have no symptoms, you are at risk.") if(smellyn=='no' and tasteyn =='no'): print("Difficulty in smelling and tasting are prominents symptoms. I think you should go for a COVID -19 test.")

代码解读与要点：

1. 判断的优先级：注意，代码中是一系列独立的if语句，而不是if-elif-else链。这意味着一个用户的情况可能匹配多个条件，从而接收到多条建议。例如，一个有呼吸困难（breathingyn=='yes'）和旅行史的用户，会同时收到关于监测血氧和旅行风险的两条建议。这在实际中是合理的，因为多条风险因素并存需要多重警示。
2. 建议的措辞：建议的表述非常谨慎，使用了“May be”（可能是）、“I suggest”（我建议）、“you should”（你应该）等词语，并频繁出现“consult a doctor”（咨询医生）、“go for a test”（去做检测）的指引。这严格划清了工具提示与医疗诊断的界限。
3. 特定逻辑：例如对男性用户睾丸肿胀的判断（if(gender=='male'): ... if(swelling=='yes'):），展示了如何将特定人群的风险因素纳入评估。
4. 最后的通用建议：无论前面匹配了哪条，最后几条关于年龄和合并症的判断（if(age>=50):）都会执行，为高风险年龄段用户提供额外提醒。

潜在问题与改进：

1. 逻辑完备性：这一长串if语句试图覆盖很多组合，但依然可能遗漏。随着症状组合的复杂化，这种“硬编码”逻辑会变得难以维护和扩展。更高级的做法是使用决策表或规则引擎，将症状和结论的映射关系数据化。
2. 建议冲突：虽然多条建议并存通常没问题，但如果逻辑设计不当，理论上可能出现轻微建议和紧急建议同时出现的情况，可能造成信息混淆。需要仔细审核规则间的互斥性或优先级。

4. 项目优化与扩展方向探讨

原始的“Chatbot-Covid finder”是一个功能完整但代码结构初级的原型。从工程化和实用性的角度，我们可以从多个层面对其进行优化和扩展。

4.1 代码结构与可维护性优化

当前的代码是典型的“面条式代码”，所有逻辑都线性地铺展在主程序中。这不利于阅读、调试和修改。

优化方案一：模块化函数将不同功能拆分成函数。

• collect_personal_info(): 收集姓名、年龄、性别。
• collect_symptom(symptom_name): 通用症状收集函数，处理是否出现、严重程度、持续时间等。
• assess_risk(symptoms_dict): 接收一个包含所有症状的字典，进行评估并返回建议列表。
• main(): 主函数，协调整个流程。 这样，主程序会变得非常清晰：

def main(): user_info = collect_personal_info() symptoms = {} symptoms['fever'] = collect_fever_info() # 专门处理发热 symptoms['cough'] = collect_yes_no_symptom('cough') # ... 收集其他症状 recommendations = assess_risk(user_info, symptoms) display_recommendations(recommendations)

优化方案二：使用数据结构使用字典或类来存储用户数据，而不是一堆独立的变量。

class PatientProfile: def __init__(self): self.name = "" self.age = 0 self.gender = "" self.symptoms = { 'fever': {'present': False, 'degree': 0.0, 'days': 0}, 'cough': False, 'shortness_of_breath': False, # ... } self.travel_history = False

这使数据传递和管理更加方便，也更容易保存或导出。

4.2 评估逻辑的进阶：从硬编码到规则引擎

当规则超过20条时，像原代码那样用if语句堆砌就非常笨重了。我们可以考虑将规则外部化。

方法一：使用列表字典存储规则

risk_rules = [ { 'conditions': {'shortness_of_breath': True}, 'advice': '监测血氧饱和度，低于95%需紧急就医。', 'priority': 'HIGH' # 优先级标识 }, { 'conditions': {'fever': True, 'fever.days': {'>=': 4}}, 'advice': '发热持续超过3天，建议咨询医生是否需要检测。', 'priority': 'MEDIUM' }, # ... 更多规则 ] def evaluate_rules(profile, rules): matched_advice = [] for rule in rules: if condition_match(profile, rule['conditions']): # 需要一个条件匹配函数 matched_advice.append((rule['priority'], rule['advice'])) # 按优先级排序后返回 return matched_advice

方法二：集成轻量级规则引擎对于更复杂的场景，可以使用像durable_rules或business-rules这样的Python库。它们允许你用更接近自然语言的语法定义规则，并且引擎会自动进行匹配和冲突消解。

4.3 交互体验与部署方式升级

1. 从命令行到图形界面（GUI）：

   • 使用tkinter（Python标准库）、PyQt或Kivy可以快速构建一个带有单选按钮、复选框和文本框的桌面应用。这能极大提升用户体验，避免输入错误。
   • 示例（Tkinter思路）：为每个症状创建一个Checkbutton（复选框）或一组Radiobutton（是/否单选按钮）。发热程度和天数用Entry（输入框）或Spinbox（数字微调框）。一个“评估”按钮绑定到评估函数。

2. 从桌面到Web服务：

   • 使用Flask或Django框架，可以将评估逻辑包装成一个Web API或一个完整的网页应用。
   • 优势：无需安装Python环境，用户通过浏览器即可访问；便于更新规则（只需更新服务器端代码）；可以更容易地集成数据库来匿名化收集数据（用于统计分析，但必须严格遵守隐私法规）。
   • 简单Flask示例：

     from flask import Flask, request, jsonify app = Flask(__name__) @app.route('/assess', methods=['POST']) def assess(): data = request.json symptoms = data.get('symptoms') advice = assess_risk(symptoms) # 调用你的评估函数 return jsonify({'recommendations': advice})

3. 输入验证与用户体验强化：

   • 除了验证“是/否”，还要验证数字范围（年龄不能为负数，体温在合理区间内）。
   • 提供进度提示，让用户知道问卷进行到哪一步了。
   • 在最后，不仅显示建议，还可以生成一个简单的“报告摘要”，供用户保存或截图。

4.4 医学合规性与局限性思考

这是此类健康评估工具最需要严肃对待的部分。

1. 明确的免责声明：必须在交互开始前和结果页面上，用醒目字体提示：“本工具仅为健康信息提示，不能替代专业医疗诊断、治疗或建议。如有不适，请及时咨询医生或前往医疗机构就诊。”
2. 动态更新知识库：症状和风险评估标准是动态变化的。理想情况下，应该有一个后台管理界面，允许授权的医学专业人士在不修改代码的情况下，更新症状列表和判断规则。这可以将程序逻辑与医学知识分离。
3. 隐私保护：绝对不要存储任何能关联到具体个人的信息（如姓名、身份证号、精确住址）。如果为了改进算法需要收集数据，必须进行严格的匿名化处理，并获取用户知情同意。
4. 局限性透明化：向用户说明工具的局限性，例如：无法检测无症状感染者、无法区分COVID-19与流感或其他呼吸道疾病、评估结果受限于当前输入信息的准确性等。

5. 常见问题与调试实录

在开发和完善这类项目的过程中，你可能会遇到一些典型问题。以下是我在编写和思考优化方案时遇到或预见的一些坑点及解决思路。

5.1 程序逻辑错误与调试

问题1：用户输入非数字时程序崩溃。

• 现象：当提示输入年龄或体温时，用户输入了文字，程序抛出ValueError: invalid literal for int()并停止运行。
• 原因：int(input())或float(input())会尝试直接转换输入，失败则抛出异常。
• 解决：使用try-except块进行异常捕获，并在循环中提示用户重新输入，直到成功。

  def get_numeric_input(prompt): while True: try: value = float(input(prompt)) return value except ValueError: print("Invalid input. Please enter a number.")

问题2：条件判断覆盖不全或逻辑冲突。

• 现象：某个特定的症状组合没有触发任何建议，或者同时触发了两条相互矛盾的建议。
• 原因：if语句的条件设置可能存在漏洞，或者多个独立if的判断条件有重叠部分且建议不一致。
• 解决：
  1. 制作决策表：在纸上或Excel中，列出所有症状（是/否），枚举所有可能的组合（2^n种，n为症状数），手动填写每种组合应有的建议。然后对照检查代码中的条件是否覆盖了所有重要组合。
  2. 使用if-elif-else链明确优先级：对于互斥的情况（例如，高风险建议和低风险建议），使用if-elif-else确保只执行其中一个分支。对于可以共存的建议，则保留多个if，但要确保建议内容不矛盾。
  3. 单元测试：为不同的症状组合编写测试用例，验证程序输出是否符合预期。这是保证逻辑正确性的最可靠方法。

问题3：代码重复严重，难以修改。

• 现象：每个“是/否”问题都有一段几乎相同的输入验证和格式化代码。
• 原因：没有使用函数来封装通用逻辑。
• 解决：如前所述，抽象出get_yes_no_input()、get_numeric_input()等工具函数。当需要修改验证逻辑时（比如想把“yes/no”也接受“y/n”），只需修改一个地方。

5.2 用户体验与交互问题

问题4：用户输入大小写或空格导致判断失效。

• 现象：用户输入了“Yes”、“YES”或“ yes ”（带空格），程序判断feveryn == 'yes'失败。
• 原因：字符串比较是大小写和空格敏感的。
• 解决：使用.lower().strip()对输入进行标准化处理。strip()方法可以移除字符串首尾的空格。

  user_input = input().lower().strip()

问题5：长问卷导致用户疲劳或中途退出。

• 现象：问题太多，用户失去耐心。
• 解决：
  • 进度提示：在每几个问题后显示“已完成X/Y题”。
  • 分支逻辑：并非所有用户都需要回答所有问题。例如，如果用户没有发热，那么关于发热天数和温度的问题就可以跳过。原代码在发热为“no”时跳过了这些追问，这是一个好的分支设计。
  • 默认值：对于非核心的次要信息，可以提供合理的默认值，允许用户快速跳过。

5.3 项目扩展时的考量

问题6：如何方便地更新或添加新的症状与规则？

• 现象：每发现一个新的相关症状（如“腹泻”），都需要程序员去修改代码，添加问题收集和判断逻辑。
• 解决：采用数据驱动设计。将症状和规则定义在外部配置文件（如JSON或YAML文件）中。

  // symptoms.json [ { "id": "fever", "question": "Do you have fever?", "type": "boolean_with_followup", "followup": [ {"question": "Temperature (F):", "type": "number"}, {"question": "Days of fever:", "type": "integer"} ] }, { "id": "cough", "question": "Do you have cough or sore throat?", "type": "boolean" } ]

  程序启动时加载这个配置文件，动态生成问卷和评估逻辑。这样，更新医学知识只需要修改配置文件。

问题7：评估逻辑越来越复杂，if语句难以管理。

• 现象：规则增加到几十条后，代码可读性急剧下降，容易产生隐藏的逻辑错误。
• 解决：如前所述，引入规则引擎。或者，至少将评估逻辑单独写在一个函数或模块中，与数据收集和用户界面分离开，遵循“关注点分离”的原则。

这个始于2020年初的简单项目，从一个侧面记录了那个特殊时期的技术响应。它的价值不仅在于那几百行代码实现了一个功能，更在于它完整地展示了一个想法从问题定义、逻辑设计、代码实现到思考优化的全过程。对于学习者而言，你可以把它当作一个模板，将其逻辑套用到其他领域的简单专家系统或决策支持工具上，比如植物病害诊断、设备故障初步排查、学习风格评估等。记住，好的项目始于一个清晰的问题，成于严谨的逻辑和持续的迭代。