上季度我们把社区医疗服务鼓号系统配套的问答小程序推上线跑了两个多月累计接待了1200多次居民提问机器人自动回答率稳定在80%以上剩下的转人工跟进也基本控制在30分钟内处理完。这篇内容不是产品宣传而是把设计和开发全过程从头到尾捋一遍需求怎么拆、技术栈怎么选、问答匹配怎么做、上线后又踩了哪些坑。如果你正在做医疗健康类的小程序或者想给传统社区服务系统加一个问答入口这篇应该能帮你省掉不少试错时间。1. 先弄清需求边界鼓号系统与问答小程序到底是什么关系1.1 鼓号系统在社区医疗里扮演的角色这套系统的名字容易让人误解它和鼓乐队没有任何关系。鼓号系统是当地社区医疗服务中心一直在用的基础业务管理系统名字取“鼓角相闻、号令清晰”的意思——社区网格员通过系统发布健康提醒、慢性病随访任务、疫苗接种安排、家庭医生签约服务通知像击鼓传令一样把服务信息逐层触达居民。系统里已经沉淀了居民健康档案、服务工单、随访记录这些核心数据但它本质上是面向工作人员的后台居民端唯一能被动接收信息的渠道就是短信通知。问题也出在这里。居民接收到通知后经常会有大量跟进问题“这个流感疫苗周六能打吗”“血糖复查需要空腹吗”“家庭医生签约在手机上怎么操作”。这些问题以前靠打电话到服务中心人工解答高峰期一天能接上百通电话重复性极高。鼓号系统的服务半径越铺越大问答压力就成了明显瓶颈。1.2 问答小程序在整个链条里的定位我们要做的问答小程序不是独立于鼓号系统以外的新平台而是作为它的居民端交互入口。核心思路是居民在微信上打开小程序看到的是基于鼓号系统数据生成的实时服务信息比如近期的疫苗安排、医生排班、体检通知同时提供一个问答入口让居民直接用自然语言提问系统先尝试自动匹配知识库匹配不上再转人工。这个定位决定了三个设计原则第一小程序必须轻不能做成复杂的业务办理客户端聚焦在“信息查询问题解答”第二问答数据必须和鼓号系统的知识库联动不能搞两套数据源第三人工兜底链路要完整居民问的问题机器人答不了时后台要有人接得住而且要能在小程序内完成会话闭环。1.3 目标用户与使用场景分解用户群体大致分三类一是中老年居民这类用户占比超过六成操作习惯偏保守提问方式经常是语音转文字或直接说方言二是年轻家属他们多数是替父母咨询关心的是预约流程、药品剂量、异地就医政策三是服务中心客服人员她们需要在小程序后台高效处理日常提问并快速将高频问题维护进知识库。场景上最高频的是“通知触发型”。比如居民收到“下周开展老年人免费体检”的短信后立刻打开小程序问“体检几点开始、要带什么”。其次是“自主查询型”居民主动搜索慢性病注意事项、开药时间、医保报销材料。这两种场景对交互路径的要求完全不同前者要从通知消息直接拉起对应问答页后者则依赖搜索和分类导航。设计时必须把这两条路径都做到尽可能短。2. 需求拆解哪些功能真正刚性哪些做了是浪费2.1 居民端搜得到、看得懂、问得通先聊居民端最核心的几个页面。首页信息聚合页。这里展示的是鼓号系统推送的近期活动和服务公告每一条公告都关联一个或多个FAQ。居民点公告卡片直接跳到对应问答组而不是进公告详情页再找入口。这个设计在实测中效果非常好公告详情页的跳出率降低了四成因为大多数居民看完标题就想知道“和我有什么关系、我该怎么做”FAQ直接给出答案。搜索问答页。这是机器问答的主战场。搜索框支持关键词命中同时也提供一个“大家都在问”的热点列表。热点列表不是拍脑袋排的而是由后台统计近7天居民提问频次动态生成。这个列表放在搜索框下方对不擅长打字的老年用户尤其友好她们点一下就能看到其他老人问得最多的问题经常能直接命中自己想要的答案。人工咨询页。当自动匹配置信度低于阈值时居民端会提示“转人工医生/客服”并展示当前排队人数和预计等待时间。居民可以发送文字、图片后台人工处理完再以模板消息触达。这里有个细节模板消息在小程序里只能在用户主动触发后的一定时间内发送所以我们设计了一个“等待卡片”让居民点击卡片把会话重新激活再回复人工消息。如果没有这张卡片很多回复根本送不出去。2.2 服务中心端问题不能只靠人肉回答服务中心后台的刚性功能只有一个半一个是会话工作台半个是知识库维护。会话工作台按会话状态分组待回复、处理中、已解决。每条会话自动关联居民健康档案标签比如“老年”“高血压”“签约居民”客服在回复前就能先看到对方的健康背景不用反复追问。工作台内置快捷回复模板模板内容从知识库高频问题里提炼比如“请空腹8小时”“请携带身份证和社保卡”。这个设计让一条咨询的平均处理时间从5分钟压到了2分钟内。知识库维护功能我只给了半个因为它的核心不是编辑器而是“从真实对话中挖掘问题”。后台每裂天统计机器人未命中的提问按语义聚类生成“待补充问题清单”客服直接在清单里点击“补充答案”输入答案后保存即生效不需要写代码。这样知识库的更新就变成运营动作而不是开发动作了。2.3 管理端用数据反哺鼓号系统的服务改进管理端不必做得很复杂但有几个数据点必须算清楚。第一问答主题分布。比如“疫苗”“体检”“开药”“报销”各自占比多少这能直接反映社区医疗服务的宣传薄弱点。如果“报销材料”类问题持续走高说明通知里报销说明写得不够清楚该回过去改鼓号系统的通知文案。第二未命中问题的趋势曲线。这些是居民真实表达但知识库没有覆盖的内容是系统最值钱的数据。我们每周会导出一次未命中清单至少在运营团队周会上过一遍。第三人工接待量的小时分布。这决定了客服排班。比如我们发现工作日上午9点到11点是咨询高峰下午受子女代问带动也有一个小高峰。按这个排班后平均响应时间降了不少。伪需求也提一个我们最初设想做一个“智能分诊”功能让居民描述症状后推荐科室。后来发现在社区医疗语境下症状自述不准确容易引起误判而且合规风险非常高。最终把功能砍掉了保留为“症状对应科室表”的静态问答只做科普不做诊断。这个取舍极为关键。3. 技术方案设计为什么用小程序后端该怎么搭3.1 产品形态选择小程序、公众号还是H5技术选型阶段我们认真对比过微信小程序、公众号H5和独立App三种形态。先说结论社区医疗服务场景小程序是性价比最高的选择。原因很直接第一微信小程序无需安装中老年用户也基本都知道“在微信里点一下就能打开”第二小程序内置的模板消息、订阅消息能力能解决服务通知触达问题第三它的开发成本和审核成本都远低于App又比H5多了原生能力比如地理位置获取——家庭医生上门服务时居民发一个位置过来客服能直接在小程序里打开地图。那为什么不用公众号H5因为公众号菜单H5页面虽然也能实现问答但体验上有两个硬伤一是H5每次打开都要重新加载对老年用户不友好二是公众号会话消息的接口限制很多做客服会话时光是处理用户上下文就很麻烦。App就不用多说了社区服务类App的推广安装成本足以让项目死在冷启动阶段。3.2 整体架构三个系统之间的数据流问答小程序不是孤岛它需要和鼓号系统主平台、消息推送服务协同工作。架构上采用三个层级接入层是微信小程序前端同时适配微信订阅消息。应用层是问答小程序的独立后端服务部署在两个服务里一个是面向居民端的API服务负责搜索、问答、会话另一个是面向运营端的知识库管理服务负责FAQ维护、会话分配、数据统计。数据层是MySQL数据库加Redis缓存。鼓号系统主平台的居民档案、通知公告数据通过API网关按需拉取到小程序服务本地不直接跨库操作。这里有个很关键的设计就是居民身份打通。小程序登录后拿到微信openid但鼓号系统里的居民健康档案用的是手机号主索引。我们的做法是首次进入小程序时引导用户绑定手机号然后调用鼓号系统提供的档案查询接口按手机号匹配健康档案匹配成功后在会话数据里保存档案ID。以后每次会话机器人答案就能带上健康档案上下文比如知道这个居民签约了家庭医生或者有高血压随访记录回答相关问题时更有针对性。3.3 数据库模型问答场景下该建哪些表数据库设计上核心是几张我建议你直接抄的表。-- 知识库问题表 CREATE TABLE faq_question ( id INT PRIMARY KEY AUTO_INCREMENT, category_id INT NOT NULL COMMENT 分类ID, title VARCHAR(255) NOT NULL COMMENT 问题标题, content TEXT COMMENT 规范化答案, keywords VARCHAR(500) COMMENT 关键词组逗号分隔, hit_count INT DEFAULT 0 COMMENT 命中次数, status TINYINT DEFAULT 1 COMMENT 1启用 0停用, created_at DATETIME, updated_at DATETIME ); -- 分类表 CREATE TABLE faq_category ( id INT PRIMARY KEY AUTO_INCREMENT, parent_id INT DEFAULT 0, name VARCHAR(50), sort_order INT DEFAULT 0 );这里我想强调一下keywords字段。它不是给用户搜索用的而是给后台运营填写扩展关键词用的。运营人员通常不是技术人员他们不知道分词和索引但知道“居民来问的时候会怎么说”。比如“疫苗”这道题的规范化标题是“流感疫苗接种时间和地点”但运营可以再填“流感针”“苗”“接种点”这些同义关键词。这样匹配准确率会显著提升。除了问题表还有用户提问记录表和会话表。用户提问记录表保存每一次提问的原文、匹配到的问题ID、是否命中、用户行为路径会话表则保存一个完整的咨询流程一个会话可能包含多条消息同时记录会话状态。会话状态机放在后面的章节细讲。3.4 问答引擎方案先做规则再谈模型关于问答引擎我们内部讨论了很久。最开始想直接接入大模型做开放问答后来被现实问题打消了一是社区医疗场景对答案准确性要求极高给居民输出半吊子医学建议一旦出错后果严重二是大模型的幻觉问题不好约束即使加了提示词限定也保证不了每次都只从知识库取材三是成本每天几千次调用云服务账单会很难看。最终我们采用了规则引擎 分类模型的两阶段策略。第一阶段先做倒排索引。把知识库每个问题的标题和关键词做分词建立倒排索引用户提问也做同样的分词处理然后计算匹配度得分。匹配度由三部分构成关键词命中数量、命中关键词的位置权重、分类偏好分。分类偏好分来自用户当前浏览的FAQ分类比如用户在“疫苗接种”分类里提问那么该分类下问题的初始得分就乘以1.2。第二阶段如果得分超过阈值比如0.72直接把对应问题答案返回。如果得分处于0.5到0.72之间返回“可能的匹配问题列表”让用户选择哪个才是她想问的用点击结果来确认命中这样比直接返回认为最像的答案要稳因为居民文化程度参差不齐问法可以不规范但她们认得出自己想问什么。如果得分低于0.5直接转人工。这套方案跑下来自动回答率在80%以上而且完全可控。每个月会挑一周时间人工复核机器人的回答中是否有不合适的目前复核了三轮没有出现原则性错误。等数据积累到十万级问答量以后我们规划再引入一个小体量的检索增强生成方案但那是后话当下规则引擎足够用。4. 核心模块开发复盘从搜索到知识库再到会话闭环4.1 搜索模块中文分词与同义扩展的落地细节问答小程序里最难做的是搜索匹配难点不在技术而在符合普通人说话习惯。中文分词我们用的是轻量级分词库jieba的Python版本没有用重型搜索引擎。之所以不引入Elasticsearch是考虑到问答规模就在几千条知识库问题重型方案反而增加运维成本而且搜索结果排序里的相关性调优更需要灵活控制。jieba库支持自定义词典我们把社区医疗常用词都加进去了比如“两癌筛查”“糖网”“家庭医生签约”避免被错误切分。用户输入“流感和新冠能一起打吗”分词器切出“流感”“新冠”“一起”“打”输入到倒排索引里匹配时优先命中标题包含“流感”和“新冠”的FAQ。但有一个常见情况是居民说“预防针”而库里写的是“疫苗”“打针”和“接种”也是同义表达。这种词级映射我们建了一个同义词映射表在分词后统一做一次同义归一化——“预防针”映射成“疫苗”“打针”映射成“接种”。这个表运营可以随时维护每次新增映射都会触发一次索引重建重建大概几秒可以放到凌晨执行。匹配分数的计算也要聊一下。我用的基础公式是score 0.65 * (命中关键词数 / 问题关键词总数) 0.25 * (命中标题词数 / 标题总字数) 0.10 * 分类偏好分分类偏好分取值0到1用户当前分类与问题分类相同时取1否则取0。这个公式虽然简陋但在我们的语料上效果不错因为它重点保护了标题命中的优先级。如果你要复现建议先用一个月真实提问日志在里面抽两三百条做回归测试逐步调整阈值参数。4.2 知识库体系结构化、轻运营、可持续知识库的初始数据从两个地方来一是鼓号系统公告文档里的常见咨询清单二是过去三个月服务中心客服电话通话记录的摘要整理。我们把300多条初始FAQ按服务领域分成了六个一级分类疫苗接种、老年体检、慢性病随访、家庭医生签约、报销与费用、门诊预约。每个分类下再细分二级标签。这里强烈建议不要把知识库设计成纯树形结构因为运营维护成本太高。我们实际用的是“分类标签”的扁平结构每个问题属于一个一级分类但可以挂多个标签。比如“高血压患者能打流感疫苗吗”这个问题一级分类是疫苗接种标签同时挂了“高血压”和“慢性病”。搜索时如果居民的问题是“我有高血压流感疫苗能打吗”即使她没有直接打开疫苗分类通过标签命中也能把得分提上来。知识库管理界面还有一个“答案生效范围”的概念。有些答案是全社区通用的比如“体检需要空腹吗”但有些答案要区分人群比如“家庭医生签约后能享受哪些服务”针对已签约居民和未签约居民回答口径不一样。所以每个FAQ可以设置一个档案标签过滤规则比如“仅对签约状态已签约的用户展示”。这个功能避免了“一刀切”答案给居民造成困惑也减轻了客服在人工会话中反复解释的压力。4.3 会话流程设计自动匹配、候选确认、人工兜底一个完整会话流程是这样走下来的。第一步居民打开小程序进入问答页面我们看到她在上一个页面浏览过疫苗接种通知就把“疫苗接种”作为上下文主题一并带到问答请求中。这一步很关键千万不要让用户每次都要自己重新描述背景。第二步提问文本来了以后先走规则引擎匹配。如果高置信匹配直接把答案渲染出来。如果是中等置信显示“您想问的是不是以下几个问题”最多列三个候选用户点选后才能看到答案。这一步虽然多了一次点击但大幅降低了错误答案带来的信任损失。第三步低置信或无置信问题时创建一条“待人工处理”会话同时弹出提示“已为您转接社区服务中心工作人员”。此时居民可以继续发消息消息会堆到该会话下。后端服务会为这条会话打上紧急程度标签紧急标签的判定规则包括问题中包含“痛”“流血”“发烧39度”等高风险词或者居民年龄超过70岁且是首次提问。紧急会话会直接推送到客服工作台的置顶区域同时给对应的网格员发一条模板消息提醒。第四步人工回复完成后居民会看到“该问题对您有帮助吗”的评价按钮。评价结果回写知识库数据表如果某个FAQ持续获得低分后台会把它标为“待优化”运营团队会重新核对答案口径。这套评价闭环让知识库质量可以持续迭代不至于上线三个月后问答失效。4.4 小程序端页面组件与交互细节前端页面虽然页面数量不多但有两个组件值得你好好打磨。第一是问答结果卡片。卡片上除了正常的答案正文还要有“相关问题”和“预约/挂号入口”。比如回答完“流感疫苗在哪里打”卡片底部自动带上对应社区卫生服务中心的地址、电话和一键导航按钮。这个组件的价值在于把问答和实际行动连接起来——居民问的是“在哪打”我们就直接给她地图路线而不是让她离开问答页去通讯录里找号码。第二是热点问题列表。我们做了一个“可能感兴趣”组件根据用户当前浏览分类和搜索历史从高频问题池里捞top5以短句形式展示。比如一位居民问过“老年人免费体检时间”热点组件的推荐池里就会优先出现“体检要带哪些证件”“体检报告多久能拿”。实际效果是约三成的会话在提问前会先点击热点问题等于提前拦截了检索请求。前端用的框架是uni-app一套代码同时发布到微信小程序和支付宝小程序。虽然日常主力是微信端但考虑到部分社区老人习惯用支付宝双端覆盖成本也不高。组件开发时注意uni-app在textarea、语音输入插件上的兼容性差异踩过坑的人都知道这两个组件在两端的行为不完全一致页面发布前要单独做双端回归。5. 开发过程中容易踩的坑权限、缓存、状态流转5.1 登录会话与贴合度openid和手机号档案的冲突第一个大坑就是登录态。微信小程序登录获取openid是异步的在弱网环境下经常出现用户已经提问但openid还没返回的情况。如果程序不做处理那一整条会话就没办法和居民档案绑定事后想补都补不回来。我们的解决方案是在小程序启动时先进入一个“预登录”状态用户允许获取手机号后立即进入首页提问请求如果发生时登录态尚未完成会把请求先放进本地队列拿到openid以后再把队列里的提问补传到后端。这在后端需要给每条提问记录加一个“会话初始化”幂等键避免因前端重试导致重复提交。这个机制上线后登录态丢失导致的会话失败率从5%降到了0.3%效果非常明显。身份绑定还有另一个坑就是同一个手机号可能对应鼓号系统里多个家庭成员档案。比如一个儿子帮父母两个老人都绑定了同一个手机号。这时候档案绑定页面要允许用户选择“当前咨询人”可以切换。我们最早没做这个功能导致不少家属提问的结果是按默认档案上下文生成的比如默认档案是父亲但实际问的是母亲的血糖问题回答语境就对不上。后来加了档案选择器每次会话创建时确认一次默认记住上次问题才解决。5.2 热点问题的缓存更新别让统计口径打架热点问题列表背后是一个聚合统计统计最近7天各问题的命中次数和人工会话的标题关键词热度。这个统计如果每次都实时跑SQL高峰期数据库压力会很大。我们的经验是做成两级缓存第一级是Redis里的热点Top50列表缓存时间设定为10分钟同时带一个版本号第二级是每天晚上定时任务生成的热点全量表供运营后台拉取。缓存要注意的是不要直接用工程层面的“当前总命中数”生成热点因为居民提问的高频词汇有很强的季节性。比如流感季的“流感疫苗”和夏天的“腹泻”两者热度完全不同。统计窗口设成滚动7天比固定自然周要好因为它更平滑不会出现周一统计口径和周五统计口径打架的情况。如果运营发现热点刷新不及时大概率不是缓存时间问题而是统计口径的时间边界没对准建议统一用“当前时间往前推7天”的滑动窗口并记录统计生成时间。缓存更新还有一个细节命中一个FAQ后要把该问题在Redis里的热度分加一而不是重建整个热点列表。这样可以在毫秒级完成增量更新再配合每10分钟的全量重排。我们第一版做成了每10分钟全量重建列表高峰期接口平均响应时间一下从120ms涨到500ms后来改成增量加分定期全量重排回落到150ms以内。5.3 会话状态机未读、处理中、已解决还是已超时状态流转这块一开始做得粗糙只用了“待回复”和“已回复”两个状态。后来发现运营根本没法区分“已发了一条回复但用户没反馈”和“完整的咨询闭环已结束”导致客服工作量统计不准也不知道哪些会话需要继续跟进。最后我们定了一套四状态流转模型NEW待分配、PROCESSING处理中、RESOLVED已解决、CLOSED已结束。加上两个分支状态EXPIRED客服超时未回复、PENDING_USER等待用户反馈。流程是这样的新建会话进入NEW客服点击接管后变PROCESSING。客服发送回复后如果消息中包含“如果还有其他问题请继续问”这类收尾词系统会自动把状态置为PENDING_USER进入冷静期如果居民在24小时内没有继续回复PENDING_USER自动转CLOSED。如果居民回复“明白了”“谢谢”这类确认词直接置为RESOLVED并通知客服归档。若客服接单后超过2小时未回复则状态置为EXPIRED同时升级给所在社区的网格员。这四条规则让整个问答服务的响应时效和质量都变得可量化。状态机代码实现上要注意并发问题。尤其是“客服正在打字”和“用户又发新消息”同时发生的情况不能用“先查后改”两步操作一定要用数据库原子更新比如UPDATE session SET status CASE WHEN status PROCESSING THEN PENDING_USER ELSE status END WHERE id ? AND status PROCESSING。如果返回影响行数为0说明状态已经被别人改掉了后端要重新拉取状态再做判断。这个部分别看简单我们上线初期因为状态并发问题丢过好几次会话流转记录后来加了乐观锁才稳定下来。6. 上线前后的运营节奏与真实数据验证6.1 冷启动阶段知识库没数据时怎么撑住知识库初始只有300条FAQ虽然覆盖了核心场景但居民的真实问法千奇百怪冷启动阶段自动回答率可能只有50%出头。这时不要慌也不用盲目扩充知识库。我们的做法是分三步走。第一步把鼓号系统近一年的客服通话记录全部导出来按主题做一次聚类。把重复率最高的前100个问题直接补进知识库。这相当于用真实用户的声音建库而不是靠运营团队拍脑袋猜测。第二步设置“未命中实时提醒”。每当机器人匹配失败并转人工时后台自动记录原始提问文本当天运营就在知识库管理后台补充对应答案第二天再遇到同样问题就能命中。这个循环在上线前两周很辛苦但坚持下来之后每日新增未命中问题数从第一天60个降到第二周末5个左右。第三步在公告推送上做引导。把高频问题以FAQ卡片的形式塞进鼓号系统的每一条通知里。比如接种通知的末尾直接带“接种前后常见问题”的卡片链接这样通知接收者可以直接点进去看答案而不必等他们来提问。这个策略不仅降低了问答压力还让知识库从“被动等待提问”变成“主动前置解答”。6.2 数据埋点与分析哪些指标真正需要盯开发和上线过程中我盯过一堆数据最后发现最值得看的只有四个指标其他可以交给周报。第一自动回答率。分子是机器人直接给出答案的会话数分母是全部有效问答会话数。我们的目标是从初期的55%逐步提高到80%以上。这个指标的涨跌直接反映知识库维护和搜索引擎调优的效果。第二转人工成功率。有些会话虽然转了人工但客服没有在约定时间内回复导致居民流失。这个指标和客服排班强相关也和服务器的模板消息通道可用性强相关。第三会话平均解决时长。从用户提出第一个问题到会话状态变为已解决或已结束中间的总时长。我们目标是把人工参与的会话控制在20分钟以内纯机器人会话控制在2分钟以内。如果这个指标升高多数情况下是知识库某类问题老化或者答案口径不清晰居民看完答案又追问了。第四次日回访率。居民第一次使用小程序问答后第二天是否还会再打开。它衡量的是小程序对居民的真实价值如果这个指标持续走低说明用户用完即走问题要么是答案质量不行要么是问答流程太长。埋点实现上我们使用的是自定义事件上报把事件名和服务端接口日志对齐。前后端共用一套traceId这样从“用户点击搜索”到“返回答案”的每一跳耗时都能串起来一旦某次会话慢能快速定位是前端渲染慢、后端查询慢还是鼓号系统接口拉取档案慢。6.3 上线后的一次真实翻车模板消息误触达的排查过程分享一个上线第三周遇到的故障也是我觉得最有价值的一次坑。那天下午运营反馈部分居民收到了重复的“服务评价邀请”模板消息而且内容带的是其他居民的问题摘要明显错乱。我们第一反应是模板消息的内容拼接出错了查了模板变量发现消息内容确实取自会话记录字段理论上一人一消息不应该串。排查链路是这样走的。先看应用日志发现同一时刻有大量获取access_token的请求存在明显的缓存失效风暴。微信模板消息发送前需要获取access_token这个token有效期2小时正常情况应该做本地缓存。但我们代码里设置的缓存时间比微信实际过期时间长了半小时导致token提前失效所有发送请求全部重新获取token。在高并发时redis里写入了一个异常值后面所有线程都以为token过期循环刷新造成部分请求拿到了重复的token实例最终消息内容绑定的session上下文被并发覆写。修复方案分两层代码层把access_token缓存时间从极值改成微信文档建议的安全值并在写入时加分布式锁架构层把消息发送改成异步队列发送失败自动重试两次后进入死信队列人工介入。那次以后模板消息误触达就再也没有出现过。这件事给我的启发是小程序问答类项目最容易出问题的往往不是问答本身而是外围的微信能力集成token管理、模板消息、订阅授权这些细节一个都不能轻视。6.4 后续扩展方向从被动问答到主动服务问答小程序上线稳定后我们已经在规划延伸能力几个方向已经过内部验证给你参考。一个方向是把问答内容和鼓号系统的用户分群标签结合做差异化答案展示。比如同样问到“家庭医生签约”签约居民看到的是“您已签约家庭医生是XX医生”未签约居民看到的是“您所在地可签约点击申请”。这其实是知识库答案的模板化能力技术上不复杂但对居民体验的提升非常明显。另一个方向是语音问答。中老年用户打字困难语音转文字输入能大幅降低使用门槛。微信小程序内置的语音识别接口可以直接用问题在于方言的识别率本地社区是南方口音普通话识别模型效果一般。我们打算在知识库匹配之前增加一层“语音同音纠错”把“流杆”自动修正为“流感”这类纠错词典可以从中老年用户的真实提问中挖掘。如果你要做类似功能建议一开始就在提问记录表里把文本的拼音索引也存下来日后纠错会很方便。第三个方向是把高频问答生成科普内容卡片通过鼓号系统推送给全体居民再从小程序内分享给微信群。这等于把问答系统的价值从“在线客服”延伸成“健康教育工具”同时也为小程序带来更多自然流量。等到这个反馈循环建立起来问答小程序就不再只是鼓号系统上的一个小功能而是社区医疗服务里一个持续自我优化的健康信息中枢。我对这套系统的核心体会是问答小程序的技术门槛并不高难的是把需求边界划清楚、把知识库运营转起来、再把微信生态的能力吃透。如果你正在做类似项目我的建议是别一开始就追求大而全的AI问答先把规则引擎和人工兜底跑稳让数据说话再逐步扩展。这样出来的系统才不会在真实社区里翻车。