从“盯群报修”到智能分诊：用Qoder验证医院智能运维新思路

医院信息系统越来越多，报修入口却往往仍是微信群。临床人员发一句“（系统）打不开了”，再补一张截图，而信息中心值班人员需要从大量群消息中辨认故障、追问 IP、判断责任人并逐一通知。

我们没有要求临床改变习惯，而是借助Qoder快速搭建了一套基于多模态大模型的微信群故障智能分诊工具：系统能够理解文字和截图，生成结构化工单并通知责任人。

更值得分享的是，这套涉及Python、Vue、Go、模型调用和MacOS自动化的全栈原型，由医院信息人员以自然语言驱动Qoder，在一个周末完成了从设想到可运行版本的开发，并对整体技术路线进行了快速验证。

为什么从微信群切入

医院信息系统发生故障时，微信群因使用门槛低、反馈直接，成为许多医院事实上的报修入口。然而，“方便”也带来四个问题：报修信息容易淹没在通知和讨论中；“又不行了”“看片子卡住了”等口语描述依赖值班人员的经验判断；截图中虽可能包含错误码、IP或主机名，却难以人工快速提取；聊天记录也很难直接转化为可统计、可追踪的运维数据。

传统做法是另建工单入口，但新入口往往意味着增加临床操作步骤。我们的思路是让技术适应用户：保留微信群这一入口，在后台增加一个能够“读懂消息、判断故障、找到责任人”的智能助手。

需求看似简单，真正落地却横跨多个技术栈：既要采集指定工作群消息、关联连续发送的文字和图片，又要调用多模态模型，还要管理院内规则、生成工单、完成微信和短信通知，并提供可视化后台。对于人员有限的医院信息部门，传统开发方式的沟通和协作成本不低。Qoder由此成为项目快速落地的关键工具。

先让Qoder理解目标，而不是直接“写代码”

本项目主要使用Qoder的Quest进行开发。它并非只补全某几行代码，而是能够围绕一个目标理解项目上下文、规划任务、修改多个文件、调用开发工具并根据运行结果继续排查。开发者的工作重点，也从逐行编码转向需求定义、架构把关、业务判断和验收。

我们给Qoder的第一条需求，不是一份冗长的技术清单，而是业务目标：“监测指定微信群中的医院信息系统故障报修，理解文字和截图，按群公告匹配责任人，并自动通知。”随后再补充边界条件：不改变临床操作习惯；只处理明确配置的工作群；首条报修信息要尽快响应；同一用户后续补发的截图应并入同一工单；关键节点必须可追踪、可重试。

Qoder根据目标梳理出消息采集、聚合、AI分诊、知识规则、通知和管理后台等模块。我们逐项确认方案，再让它分阶段实施。这样的顺序很重要：AI编程并不等于把一个模糊想法一次性交给工具，而是先把目标、约束和验收标准说清楚，再让工具承担大量模式化开发工作。

在每个阶段，我们还要求Qoder先说明拟修改的模块、数据流和验证方法，再执行编码。这样既便于人工审查方案，也能把一次大任务拆成可回退、可比较的小版本。涉及消息读取、外部模型和自动通知时，权限申请与敏感操作必须由人工确认，避免以开发效率替代安全控制。

项目最终形成“采集与聚合—智能分诊—应用闭环”的架构（如图1所示）。Chatlog-bot监听指定群消息，并通过Webhook送入后端；FastAPI服务完成消息聚合、模型调用、知识增强和工单处理；Vue3管理面板提供看板、查询、规则配置与分析功能；微信自动化和短信平台负责通知。多模态模型同时理解文字和截图，输出是否故障、故障类别、责任人、IP 地址、置信度及判断依据等结构化结果。

Qoder如何参与关键功能开发

1.从自然语言需求到可运行模块

项目后端采用Python/FastAPI，前端采用Vue3/TypeScript，消息采集工具涉及Go，另有模型接口、短信接口和MacOS UI自动化。跨语言、跨框架开发通常需要不同人员配合。使用Qoder后，我们以一个真实业务场景为单位推进，例如：“同一人在三分钟内连续发送文字和多张截图，应先快速生成初始工单，后续信息到达后再合并更新，不能重复派单。”

Qoder据此修改数据结构、异步任务和接口逻辑，并协助构造测试场景。开发者不必先把需求翻译成每个函数的实现细节，但必须明确什么算同一事件、何时更新、什么情况下关闭工单。业务规则越清楚，生成结果就越接近可用状态。

2.用日志驱动复杂问题排查

最费时间的并非页面或接口，而是运行环境中的“边角问题”。例如，首次AI分诊需要十余秒，此时用户可能已经补发截图，若并发处理不当，会生成两张工单。我们把日志、复现步骤和预期行为交给Qoder，它沿着缓冲区、异步任务和工单ID的生成过程定位竞态条件，最终形成以“群ID＋发送者ID”为键的缓冲机制，并让更新任务等待初始工单就绪。

另一个难点是微信截图默认可能只有缩略图，导致IP和错误码模糊。围绕这一问题，Qoder协助完成了原图获取、超时重试和降级流程：优先通过MacOS自动化触发原图下载，失败时仍用缩略图继续分诊，避免整条链路阻塞。微信窗口最小化、遮挡或锁屏等情况，也通过状态检测、重试和失败记录逐步增强容错能力。

3.把医院知识嵌入模型，而不是只依赖通用能力

通用模型能够识别“网络不通”“打印机故障”等常见问题，却未必能理解本院系统别名和责任分工。我们把群公告中的“故障类别—联系人”对照表整理为基础知识，并在后台维护“现象—类别—责任人—联系电话”规则。例如，“看片子”“CT影像”“放射”等表述优先映射至PACS，“共享助手”类报错指向特定系统和责任人。

Qoder负责完成规则的数据模型、增删改查页面、提示词拼装和结构化输出解析；医院信息人员负责确认分类口径、联系人和误判样本。二者的分工非常清晰：AI工具擅长搭建机制，领域人员必须掌握业务标准。

一个周末完成验证，关键不是“一次生成”

本次项目集中利用一个周末完成原型开发和技术验证，形成约4000行Python后端代码、约2500行Vue3/TypeScript前端代码，并完成Go工具二次开发、AI 分诊、自动通知和短信集成。这样的速度并不意味着一句提示词就能生成全部系统，而是来自“描述—实现—实测—反馈—修正”的短循环，这也得益于Qoder对项目上下文、多个技术栈和运行日志的连续理解。

我们坚持每完成一个模块就用真实场景验证：发送一条文字报修，检查是否误判；补发截图，确认是否更新同一工单；故意缩小微信窗口，观察自动化是否恢复；让模型返回异常格式，检查解析和降级；修改一条知识规则，确认是否即时生效。Qoder读取日志和现有代码后继续修复，开发者负责判断结果是否符合医院业务规则。

这也改变了医院信息人员参与开发的方式。过去，一个需求常要经历业务说明、技术转述、排期开发和联调验收；现在，熟悉现场的人可以直接把问题、约束和样例交给AI 编程工具，并即时看到可运行结果。但“会描述”不等于“只说想法”，有效输入至少应包含业务目标、已有环境、不能触碰的边界、异常场景和验收标准。对于涉及群消息和患者相关环境的项目，还必须由人明确数据范围、权限、脱敏、留存和模型调用边界。

阶段性验证效果与复盘

目前，这项工作主要用于快速验证技术方案的可行性，尚处于试运行和持续完善阶段。该工具已在我院两个工作群的实际消息环境中开展验证，覆盖约200名成员，累计处理消息750余条，生成工单47份，其中故障工单26份、非故障消息21份；已维护14条知识规则，覆盖HIS、LIS、PACS、电子病历、OA、网络、硬件、打印机、叫号等类别。这些数据说明，从微信群消息采集、多模态理解、知识增强分诊到责任人通知的技术链路可以跑通，但不代表相关功能已经完全成熟或具备大范围推广条件。

我们还对386组历史消息进行了批量分诊和人工复核。初始准确率约为85%，针对误判样本补充13条院内知识规则后，PACS故障口语表达、Windows和打印机故障的分类更准确，致谢、闲聊和简单询问的误报也有所下降。在现阶段测试中，故障消息发出后通常可在15—30秒内完成识别并推送；截图中的IP、错误码等信息能够随工单沉淀，减少重复追问。上述结果属于阶段性测试记录，后续仍需结合更多真实故障样本，对分类规则、异常降级、通知可靠性和安全管理机制持续评估。

这次实践带来三点体会：

第一，Qoder显著降低了跨技术栈开发和调试的门槛，但需求边界、医疗业务规则和最终验收不能交给工具替代。

第二，知识规则是系统从“能演示”走向“能使用”的关键，大模型与本地知识结合比单纯追求更大的模型更有效。

第三，AI编程项目尤其适合小步验证；每次只解决一个可观察问题，并用日志和真实样例反馈，质量远高于一次性生成后集中联调。

下一步：从智能分诊走向运维闭环

下一阶段，我们将把该工具投入日常运维工作中持续观察和优化，而不是急于把验证结果等同于正式产品。重点包括：结合新增样本调整分类知识和提示词；完善重复报修、群体性故障和模型异常等边界场景；优化原图获取与通知链路的稳定性；建立人工复核、错误纠正和效果评估机制。在此基础上，再逐步探索与医院IT运维管理平台对接、增加语音转写、分析故障高发系统与时段，以及为不同院区和工作群配置独立规则。

微信群短期内不会退出医院协作场景。与其反复要求临床人员改变习惯，不如在合规边界内，让智能能力嵌入已有流程。对医院信息部门而言，本项目的更大价值也不只是一套分诊系统，而是验证了一条新的自主开发路径：由业务人员定义问题和把握边界，Qoder承担方案落地、跨栈编码与持续调试，再以真实场景反复验收。AI编程正在让一些过去因人力和周期而搁置的“小而急”需求，具备快速变成可运行系统的可能。

（资料说明：文中关于Qoder Quest的能力表述参考Qoder官方文档；运行数据来自本项目试运行记录。）

【作者简介】

陈海强，中国中医科学院西苑医院信息管理中心主任，主要研究方向为医院信息系统运维与智能化应用。