1. 项目概述当AI成为聊天机器人的“默认答案”最近几年只要一提到“聊天机器人”几乎所有人的第一反应就是“AI”、“大语言模型”、“GPT”。仿佛没有这些前沿技术就根本不可能构建一个能用的对话系统。作为一个在自动化工具和对话系统领域摸爬滚打了十多年的从业者我想说这种认知其实是一个巨大的误区。今天我们就来聊聊一个被忽视但极其重要的主题为什么你并不总是需要AI来构建一个聊天机器人。这个项目标题的核心是挑战当前技术选型中的“唯AI论”。它探讨的是在特定场景下如何利用更简单、更可控、成本更低的技术栈来实现一个高效、稳定且完全满足需求的聊天机器人。这背后涉及的核心领域是对话系统设计、自动化流程构建以及业务逻辑的工程化实现。潜在的需求非常明确许多团队尤其是初创公司、中小企业或特定垂直领域的业务部门他们需要的不是一个能吟诗作对、天马行空的“AI伙伴”而是一个能精准、可靠、7x24小时解决特定问题的“自动化助手”。适合阅读这篇内容的人包括正在为客服、内部工具、产品导览等场景寻找自动化解决方案的产品经理和业务负责人被AI模型的高成本和复杂性劝退但又急需对话功能的技术决策者以及所有希望理解技术方案本质不被潮流裹挟的开发者。我们将一起拆解在哪些场景下基于规则和流程的“非AI”聊天机器人不仅是够用的甚至是更优的选择。2. 核心思路拆解回归问题本质而非追逐技术热点2.1 明确聊天机器人的核心价值在决定使用何种技术之前我们必须回归原点聊天机器人的核心价值是什么在我看来其根本价值在于在特定交互场景下以自动化的方式高效、准确地完成信息传递、任务执行或问题解答。这个定义里关键词是“特定场景”、“自动化”、“高效准确”。AI特别是大语言模型只是实现“高效准确”的一种手段而且是一种通用性强、但可控性相对较低的手段。举个例子一个电商网站的退货政策咨询机器人。用户90%的问题都集中在“如何申请退货”、“退货期限是多久”、“运费谁承担”、“退款多久到账”这几个固定模式上。对于这类问题一个精心设计的决策树规则引擎就能做到100%的准确率响应时间在毫秒级且零成本。如果硬要接入一个AI模型它首先需要针对你的业务数据进行微调或提供精准的上下文这产生了额外的训练或提示工程成本其次它仍然存在极小概率的“幻觉”即编造一个不存在的退货政策这带来了风险最后它的单次响应成本Token消耗虽然看似很低但在海量咨询下累积成本远高于静态的规则系统。注意这里并不是全盘否定AI的价值。AI在处理开放域对话、语义理解、内容生成方面具有不可替代的优势。我们的核心论点是技术选型应始于业务需求分析而非技术本身的酷炫程度。很多需求用“锤子”规则引擎就能完美解决没必要动用“工程机械”大模型。2.2 非AI聊天机器人的技术栈构成一个不依赖AI的聊天机器人其技术核心通常由以下几部分组成它们共同构成了一个稳定可靠的系统自然语言理解NLU模块简化版这里不需要复杂的深度学习模型。我们可以采用“模式匹配”或“意图分类”的轻量级方案。关键词/正则表达式匹配直接匹配用户输入中的特定关键词或短语。例如用户说“我想退货”系统匹配到“退货”关键词即触发退货流程意图。这种方式简单粗暴但对于封闭域、句式固定的场景非常有效。基于规则的意图解析结合关键词、词序和简单的句法规则来判断意图。例如定义规则(“怎么”|“如何”) (“申请”|“办理”) (“退货”|“退款”)可以更精准地捕捉用户咨询退货流程的意图。第三方轻量NLU服务例如使用 Rasa NLU可配置基于规则的管道、Microsoft LUIS 或 Google Dialogflow CX 中的“意图”功能它们也支持非机器学习的规则匹配。这些工具提供了比纯手工编码更友好、更易维护的意图管理界面。对话管理DM模块这是机器人的“大脑”负责维护对话状态决定下一步该做什么。在非AI机器人中这通常是一个状态机State Machine或流程引擎。有限状态机FSM将对话建模为一系列状态如“问候”、“询问订单号”、“确认问题类型”、“提供解决方案”、“结束”。每个状态下机器人等待特定的用户输入意图然后根据输入跳转到下一个状态并执行相应的动作如查询数据库、调用API、回复消息。业务流程建模对于更复杂的、多分支的对话如故障排查、多步骤表单填写可以使用专门的流程设计工具如 Camunda、Flowable或图形化对话设计平台来绘制对话流程图然后由引擎驱动执行。知识库与响应生成机器人回答的内容从哪里来结构化响应模板针对每个意图或对话状态预先编写好回复模板。模板中可以包含变量由对话管理器填充如您好订单{order_id}的物流状态是{status}。这是最可控、最稳定的方式。查询数据库/API将用户查询转化为对内部数据库如产品库、订单库、FAQ知识库或外部服务API的查询然后将查询结果格式化后返回给用户。文档检索对于需要从非结构化文档如帮助文档、政策文件中查找答案的场景可以使用传统的全文检索技术如 Elasticsearch。根据用户问题中的关键词检索最相关的文档段落然后直接返回该段落作为答案。这比让AI总结更精准且不存在编造风险。集成与渠道如何让用户接触到机器人通过网页插件、社交媒体Messenger、企业内部通信工具如钉钉、飞书、Slack、短信或电话IVR系统进行集成。这部分技术与是否使用AI无关。2.3 方案选型背后的核心考量成本、可控性与效率为什么在许多场景下要优先考虑非AI方案其决策逻辑基于以下几个维度的权衡成本Cost开发与维护成本基于规则的机器人其逻辑对于开发者和业务人员都是透明、可理解的。修改一个回答或增加一个流程分支就像修改配置或代码一样直接无需数据科学家介入也无需重新训练模型。维护门槛和成本极低。运营成本规则机器人部署后除了服务器资源几乎没有持续的现金支出。而使用商用大模型API每一次对话都会产生费用。当对话量达到百万、千万级别时这笔费用将非常可观。可控性与准确性Control Accuracy100%的确定性规则系统的行为是完全确定的。输入A必然输出B。这对于处理金融、法律、医疗、客户订单等敏感且要求零错误的业务至关重要。你可以对机器人的每一句回答进行审计和合规审查。无“幻觉”风险大语言模型的“幻觉”是其固有特性之一在需要绝对准确性的场景下是致命缺点。规则系统从根本上杜绝了这一点。易于调试与优化当机器人回答错误时你可以清晰地追溯到是哪条规则被触发哪个流程分支走错了修复起来目标明确。而AI模型出错往往需要分析训练数据、调整提示词或微调参数过程复杂且结果不确定。效率与性能Efficiency Performance响应速度规则匹配和状态跳转是计算量极小的操作响应延迟通常在几十毫秒内。而调用大模型API即使是最快的模型也难免有网络延迟和模型推理时间通常需要数百毫秒到数秒。资源消耗规则引擎可以轻松部署在轻量级的服务器甚至边缘设备上。而运行一个大模型则需要昂贵的GPU资源。启动速度Time-to-Market对于一个业务逻辑明确的场景设计和实现一个规则机器人可能只需要几天或几周。而准备高质量的标注数据、微调模型、进行提示工程和效果评估周期要长得多。3. 核心细节解析与实操要点3.1 意图识别从关键词到模式匹配的进阶意图识别是非AI聊天机器人的第一道关卡也是最需要精心设计的地方。我们不能仅仅依赖简单的关键词否则会遇到大量误匹配。基础方案关键词列表这是最简单的起点。为每个意图维护一个关键词列表。# 示例退货意图的关键词 return_intent_keywords [退货, 退款, 退钱, 不想要了, 取消订单, 拒收]问题用户说“你们的产品不退吗”也会触发退货意图但这实际是一个反问句。或者“推荐一款不退色的口红”“不退色”中的“退”会造成误匹配。进阶方案正则表达式与规则组合使用正则表达式可以定义更精确的模式。import re # 匹配明确的退货申请 pattern_return_apply re.compile(r(我想|我要|申请|办理|如何|怎么)(一下)?\s*(退货|退款)) # 匹配询问退货政策 pattern_return_policy re.compile(r(退货|退款)(的)?\s*(政策|规定|流程|时间是|多久|怎么算))实操心得不要试图用一个复杂的正则表达式解决所有问题。应该为同一个意图设计多个不同模式分别覆盖不同的常见问法。例如“怎么退货”和“退货流程”虽然语义相同但句式不同最好有两个模式来匹配。同时可以结合简单的否定词过滤如“不”、“没”、“非”来减少误判。高级方案基于规则的语义槽填充对于需要提取具体信息的场景如“我要退订单号123456”我们需要提取订单号。这可以通过正则表达式的捕获组来实现。pattern_extract_order re.compile(r订单(号)?\s*([A-Z0-9]{6,})) match pattern_extract_order.search(user_input) if match: order_id match.group(2) # 提取出123456注意事项正则表达式虽然强大但可读性和可维护性会随着复杂度上升而下降。建议为每个模式编写清晰的注释并建立完善的测试用例集确保任何修改都不会破坏已有的匹配逻辑。3.2 对话状态机设计从线性流程到带条件的跳转对话状态机是非AI机器人的灵魂。设计一个好的状态机关键在于平衡用户引导的明确性和处理用户随意跳转的灵活性。基础线性流程 最简单的状态机是线性的像一份问卷。[欢迎] - [询问姓名] - [询问问题类型] - [提供解决方案] - [结束]这种设计适用于信息收集类任务如注册、预约用户只能按部就班回答。带分支的条件流程 更常见的是带条件分支的流程根据用户输入或业务逻辑跳转到不同状态。[开始] | v [询问问题类型] / \ (技术问题) (账单问题) | | v v [引导提供设备型号] [询问订单号] | | v v [提供解决方案A] [提供账单详情]实现技巧在代码中不要用一堆if-else嵌套来实现状态机。这会导致“面条代码”难以维护。推荐两种方式显式状态表使用字典或配置定义每个状态以及从该状态接收到不同意图时应跳转到的下一个状态和要执行的动作。state_transitions { GREETING: { intent_greet: (ASK_PROBLEM_TYPE, action_ask_problem), intent_return: (HANDLE_RETURN, action_ask_order_id), *: (FALLBACK, action_sorry) }, ASK_PROBLEM_TYPE: { intent_tech: (ASK_DEVICE_MODEL, action_ask_model), intent_billing: (ASK_ORDER_ID, action_ask_order_id), # ... } }使用专门的工作流/状态机库对于复杂流程使用像transitions(Python)、xstate(JavaScript) 这样的库它们提供了更清晰的状态、事件、守卫条件Guard和动作Action的定义和管理方式。处理用户“跳题”用户不会总是跟着你的流程走。在状态A时他可能突然问一个属于状态C的问题。一个健壮的状态机需要处理这种“全局意图”。常见的做法是在每个状态的处理逻辑中除了检查当前状态特定的意图也检查一批“全局意图”如“返回主菜单”、“转人工客服”、“查询联系方式”这些意图在任何状态下都会被识别并触发相同的跳转和动作。3.3 知识库构建与检索让机器人“有据可依”当用户的问题超出预设的流程或者需要查询具体信息时一个本地的知识库就显得尤为重要。构建结构化知识库FAQ 这是最推荐的方式。将常见问题与答案整理成结构化的数据例如一个CSV文件或数据库表。ID问题标准问法答案关键词用于检索分类1退货期限是多久自收到商品之日起7天内在商品完好不影响二次销售的情况下可以申请无理由退货。退货, 期限, 几天, 多久售后政策2运费谁承担非商品质量问题导致的退货运费由您承担商品质量问题导致的退货运费由我们承担。运费, 承担, 谁出售后政策检索逻辑当用户输入一个问题时首先用意图识别判断是否为流程性问题。如果不是则进入知识库检索流程对用户问题进行分词提取关键词。计算与知识库中每个“问题”或“关键词”字段的相似度。初期可以使用简单的词频-逆文档频率TF-IDF结合余弦相似度来计算。虽然不如深度学习模型精准但对于封闭域、问题表述相对固定的FAQ效果已经足够好且速度极快。返回相似度最高的1-3个答案。如果最高相似度低于某个阈值如0.5则触发“未找到答案”的兜底逻辑可以提示用户重新表述或转人工。集成外部数据源 对于需要实时数据的查询如“我的订单123456到哪了”机器人识别出“查询物流”意图和订单号槽位后应直接调用内部的订单系统API获取最新的物流信息然后填充到预设的响应模板中返回。这里的核心是接口的稳定性和数据的准确性与AI无关。4. 实操过程构建一个客服退货咨询机器人让我们通过一个完整的例子将上述理论付诸实践。假设我们要为一个中型电商平台构建一个处理退货咨询的机器人。4.1 需求分析与流程设计首先我们与业务部门沟通梳理出用户关于退货的核心诉求点如何申请退货流程退货有什么条件政策退款多久能到账时效运费谁来承担费用查询某个订单的退货进度。状态查询基于此我们设计一个混合型对话流程对于前4个标准政策问题走知识库检索路径对于第5个个性化查询走多轮对话的状态机路径引导用户提供订单号然后调用API查询。对话流程设计图文字描述初始状态Greeting机器人欢迎用户并询问需要什么帮助。用户输入用户表达需求。意图识别如果匹配到“查询退货进度”意图进入状态机子流程 a. 状态ASK_ORDER_ID请求用户提供订单号。 b. 状态VALIDATE_ORDER验证订单号有效性及是否属于可退货范围。 c. 状态SHOW_RETURN_STATUS调用get_return_status(order_id)API展示进度。如果匹配到其他关键词如“如何退”、“期限”、“运费”、“到账”进入知识库检索路径 a. 在FAQ知识库中检索最相关问题。 b. 返回答案。如果均未匹配进入澄清或转人工状态。4.2 技术实现与核心代码解析我们选择Python的Flask框架作为后端因为它轻量且快速。前端可以是一个简单的网页聊天窗口通过WebSocket或轮询与后端通信。第一步搭建基础框架与意图识别# app.py from flask import Flask, request, jsonify import re import json app Flask(__name__) # 简单的规则式意图识别器 class RuleBasedIntentClassifier: def __init__(self): self.patterns { return_progress: [ re.compile(r(查|查询|查看).*退货进度), re.compile(r订单.*退货.*到哪了), re.compile(r退货.*状态), ], return_howto: [ re.compile(r(怎么|如何|怎样).*退货), re.compile(r退货.*流程), ], return_deadline: [ re.compile(r退货.*期限|多久|几天), re.compile(r几天内.*可以退), ], # ... 其他意图 } def classify(self, text): text text.strip() for intent, pattern_list in self.patterns.items(): for pattern in pattern_list: if pattern.search(text): return intent, pattern.search(text).groups() # 返回意图和可能的捕获组 return unknown, None intent_classifier RuleBasedIntentClassifier() # 简单的对话状态管理使用内存生产环境需用数据库 conversation_state {} app.route(/chat, methods[POST]) def chat(): data request.json user_id data.get(user_id, default) user_message data.get(message, ) # 获取或初始化当前用户的状态 current_state conversation_state.get(user_id, {state: GREETING}) # 根据当前状态和用户消息决定下一步 response_message, next_state handle_dialog(current_state, user_message, user_id) # 更新状态 current_state[state] next_state conversation_state[user_id] current_state return jsonify({reply: response_message}) def handle_dialog(state, message, user_id): intent, slots intent_classifier.classify(message) # 状态机逻辑 if state[state] GREETING: return 您好我是退货助手。请问您需要查询退货进度还是了解退货政策呢, WAITING_INTENT elif state[state] WAITING_INTENT: if intent return_progress: return 好的为您查询退货进度。请提供您的订单号。, ASKING_ORDER_ID elif intent in [return_howto, return_deadline, return_freight, return_refund_time]: # 走知识库路径 answer query_knowledge_base(intent, message) return answer, WAITING_INTENT # 回答后回到等待意图状态 else: return 抱歉我没太明白。您可以问我关于退货流程、期限、运费或到账时间的问题或者直接告诉我订单号查询进度。, WAITING_INTENT elif state[state] ASKING_ORDER_ID: # 这里可以更精细地提取订单号例如用正则 order_id_pattern re.compile(r(\d{10,})) # 假设订单号是10位以上数字 match order_id_pattern.search(message) if match: order_id match.group(1) # 验证订单并查询状态模拟 status mock_get_return_status(order_id) return f订单 {order_id} 的退货状态是{status}。, GREETING # 查询完毕回到初始 else: return 您提供的格式好像不是订单号呢请重新提供一下通常是纯数字。, ASKING_ORDER_ID return 系统繁忙请稍后再试。, state[state] def query_knowledge_base(intent, question): # 这里简化处理实际应从数据库或文件读取FAQ faq { return_howto: 申请退货流程1. 登录账号进入我的订单2. 找到对应订单点击申请退货3. 选择退货原因提交申请4. 等待审核通过后按提示寄回商品。, return_deadline: 自您签收商品之日起7天内商品完好且不影响二次销售可申请无理由退货。, # ... } return faq.get(intent, 抱歉我暂时没有找到这个问题的答案请咨询在线客服。) def mock_get_return_status(order_id): # 模拟调用内部API statuses [待审核, 审核通过待寄回, 仓库已收货质检中, 退款处理中, 退款完成] import random return random.choice(statuses) # 模拟返回 if __name__ __main__: app.run(debugTrue)代码解析RuleBasedIntentClassifier类封装了基于正则表达式的意图识别逻辑。每个意图对应一个模式列表提高了匹配的鲁棒性。handle_dialog函数是核心的状态机。它根据当前对话状态和识别出的意图决定回复内容和下一个状态。状态WAITING_INTENT是一个关键设计。它作为中枢根据用户意图决定是进入“查询进度”的线性状态机还是直接通过知识库回答问题并回到等待状态。这实现了流程与问答的混合。query_knowledge_base函数模拟了从结构化数据字典中获取答案的过程。实际应用中这里应替换为更智能的检索逻辑如TF-IDF相似度计算。4.3 知识库检索的增强实现上面的query_knowledge_base函数过于简单。我们来实现一个基于TF-IDF和余弦相似度的简易检索器。# knowledge_retriever.py import jieba # 中文分词库 from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_similarity import numpy as np class SimpleFAQRetriever: def __init__(self, faq_data): faq_data: list of dict, [{q: 问题, a: 答案, keywords: ...}, ...] self.faqs faq_data self.questions [item[q] for item in faq_data] # 使用 jieba 分词并构建 TF-IDF 向量器 self.vectorizer TfidfVectorizer(tokenizerjieba.lcut, stop_words[的, 了, 在, 是, 我]) self.question_vectors self.vectorizer.fit_transform(self.questions) def get_answer(self, user_query, threshold0.3): # 将用户查询向量化 query_vec self.vectorizer.transform([user_query]) # 计算与所有问题的余弦相似度 similarities cosine_similarity(query_vec, self.question_vectors).flatten() # 找到最相似的问题索引 best_match_idx np.argmax(similarities) best_score similarities[best_match_idx] if best_score threshold: return self.faqs[best_match_idx][a], best_score else: return 抱歉我没有找到相关答案。您可以尝试换一种问法或直接联系人工客服。, best_score # 初始化示例 faq_list [ {q: 退货期限是多久, a: 自收到商品之日起7天内..., keywords: 退货 期限 几天}, {q: 退货运费谁承担, a: 非质量问题退货运费自理..., keywords: 运费 承担 谁出}, # ... 更多FAQ ] retriever SimpleFAQRetriever(faq_list) # 在 handle_dialog 中调用 # answer, score retriever.get_answer(user_message) # if score 0.4: # 使用更高的阈值确保准确性 # return answer, WAITING_INTENT实操要点分词质量中文检索的核心是分词。jieba是基础选择对于专业领域可以加载自定义词典来提升分词准确性如加入产品名、品牌名。停用词移除“的”、“了”等无实际意义的停用词能提升相似度计算的有效性。阈值调优threshold参数至关重要。设置过高会导致很多本可回答的问题被拒绝设置过低则会返回不相关的答案。需要通过真实对话数据反复测试和调整。冷启动问题初期FAQ数量少检索效果可能不稳定。可以人工维护一个“问题-标准问法”的映射表在检索前先进行一轮精确的关键词或规则匹配作为补充。5. 常见问题与排查技巧实录在实际开发和运维基于规则的聊天机器人过程中你会遇到一些典型问题。以下是我总结的“避坑指南”。5.1 意图识别不准经常“答非所问”问题表现用户的问题明显属于A意图但机器人识别成了B意图或者识别为“unknown”。排查思路检查规则覆盖度收集一批真实的用户问法可以从客服日志中提取看看你的正则表达式或关键词列表是否覆盖了这些常见表达。经常有开发者只凭想象写了几个规则与实际用户语言差异很大。规则冲突与优先级两个意图的规则可能存在重叠。例如“怎么退款”和“退款多久到账”可能都包含“退款”关键词。需要调整规则让“多久到账”这类包含时间疑问词的规则优先级更高或者为“退款多久到账”设计更特化的正则表达式如r退款.*(多久|几天|何时).*到账。引入否定判断对于“不能退货吗”这种反问或否定句简单的关键词匹配会误触发。需要在规则中增加对句首否定词如“不”、“没”、“非”、“是否”的简单判断逻辑当检测到这些词时触发一个特殊的“澄清”流程而不是直接回答政策。使用更健壮的相似度匹配作为后备当所有规则都不匹配时不要直接回复“我不懂”。可以将用户问题送入前面提到的TF-IDF检索器与所有意图的“标准问法”进行相似度计算。如果与某个意图的相似度超过一个较高阈值如0.7则可以按该意图处理。这能有效处理用户问法的微小变体。5.2 对话流程僵化用户感觉被“绑架”问题表现用户想中途切换话题或者回答了一个机器人没问的信息机器人却坚持原来的流程导致对话不自然。解决方案设计“全局意图”在状态机的每个状态都并行检查一批全局意图如“返回主菜单”、“转人工”、“重新开始”、“查询联系方式”等。无论当前处于什么状态只要用户触发这些意图就立即跳转到对应流程。实现“槽位填充”的灵活性在多轮收集信息时如同时需要订单号和手机号允许用户在一次输入中提供多个信息。例如在询问订单号的状态下用户回复“订单号是123456手机号138xxxx”。你的系统应该能同时提取出订单号和手机号并填充到对应的槽位中然后直接跳转到后续状态而不是傻傻地再问一遍手机号。实现方法在每个状态的处理函数中不仅检查当前期待的信息也运行所有其他信息槽的提取规则。如果提前提取到了就记录下来并跳过对应的询问状态。设置对话超时与上下文重置如果用户长时间不回应或明确说“算了”状态机应该能重置到初始状态避免残留的旧上下文干扰新对话。5.3 知识库检索效果不佳找不到答案或找到错误答案问题表现用户问“退货要包装盒吗”知识库里有“退货需要商品完好包括原包装”但检索不到。排查与优化丰富FAQ的“标准问法”不要只写一条标准问法。对于同一个答案尽可能多地列举不同的用户表达方式都作为“问题”字段存入知识库。例如对于退货条件可以添加“退货要什么条件”、“什么东西不能退”、“退货有什么要求”、“商品怎样才算完好”。这能极大提升TF-IDF检索的召回率。利用“关键词”字段在FAQ表中增加一个“关键词”字段人工填入与答案核心相关的词汇如“包装盒”、“完好”、“配件”、“标签”。在检索时将用户问题与“问题”和“关键词”两个字段一起计算相似度或者将关键词作为权重加成。实施同义词扩展建立业务相关的同义词库。例如用户说“盒子”系统能联想到“包装”、“包装盒”、“外包装”。在检索前对用户查询进行同义词替换扩展然后再进行匹配。记录未命中问题建立一个日志系统记录所有检索相似度低于阈值的问题。定期分析这些日志你会发现哪些是知识库的空白需要补充哪些是用户的新问法需要添加到标准问法中。这是迭代优化知识库最重要的数据来源。5.4 系统扩展性差添加新功能改动大问题表现每增加一个新的业务功能如“查询优惠券”就需要在意图识别、状态机、响应模板等多个地方修改代码容易出错。设计模式建议配置驱动将意图规则、状态转移表、响应模板、FAQ知识库都抽取到外部配置文件如JSON、YAML或数据库中。核心引擎只负责读取配置并执行。添加新功能时只需要在配置文件中添加新的条目无需修改核心代码。模块化设计将意图识别器、对话状态机、知识检索器、API调用客户端等设计成独立的模块或微服务。它们之间通过清晰的接口如HTTP API、消息队列通信。这样升级或替换某个模块比如把规则识别升级为更复杂的模型不会影响其他部分。使用专业的对话平台对于业务复杂且长期发展的项目可以考虑使用开源的对话机器人框架如Rasa。Rasa虽然以AI为核心但其对话管理部分非常强大且完全支持基于规则的对话流设计。它提供了图形化的故事编辑器和丰富的策略能很好地管理复杂的对话逻辑并且所有对话流程都通过YAML文件定义易于版本管理和协作。