当前位置：首页 > news >正文

构建全双工实时语音对话系统：从Discord Bot到AI语音助手的实践

news 2026/5/11 9:11:09

1. 项目概述：构建一个全双工实时语音对话系统

最近在折腾一个挺有意思的项目，叫 Voice Hub。简单来说，它的目标是把 Discord 变成一个能和你“打电话”的智能语音助手。想象一下，你在 Discord 的语音频道里，不是和真人队友开黑，而是和一个 AI 进行实时、自然的对话，你说完它立刻就能接上，还能随时打断它——就像真的在打电话一样。这个项目就是实现这个想法的“中间层”系统。

它本质上是一个桥梁，连接了前台的 Discord 语音机器人、负责实时语音处理的 AI 模型（比如火山引擎的豆包模型），以及后台真正执行复杂任务或生成对话内容的“大脑”（比如 OpenClaw 或 Claude Code）。我之所以花时间研究它，是因为市面上很多语音机器人要么延迟高得让人着急，要么是半双工（你说完必须等它说完，不能打断），体验很割裂。而一个真正的全双工、低延迟的对话系统，对于开发智能客服、游戏伴侣、或者仅仅是个人娱乐助手，都有很大的想象空间。

这个项目适合对实时音视频处理、AI 应用集成以及现代 TypeScript 全栈开发感兴趣的开发者。无论你是想学习如何将 Discord Bot 与云上 AI 服务深度结合，还是想了解如何设计一个高并发的实时语音中间件，甚至只是想给自己的社区服务器加一个能聊天的“伙伴”，这个项目都能提供一个非常扎实的起点。接下来，我会拆解它的核心设计、手把手带你部署调试，并分享我在搭建过程中踩过的那些“坑”。

2. 核心架构与设计思路拆解

要理解 Voice Hub，不能只看代码，得先明白它要解决的核心矛盾：如何将流式的语音输入、实时的 AI 推理和流式的语音输出，无缝地编织在一起，同时保证低延迟和会话隔离。这听起来简单，但涉及多个异步子系统协同工作，设计上很有讲究。

2.1 全双工语音的核心：事件流与背压管理

传统的语音交互多是“按次”的：用户说完一整段，发送，服务器处理，返回语音。这本质上是半双工。全双工意味着语音数据像水流一样，在用户端和 AI 端同时、持续地双向流动。

Voice Hub 实现全双工的关键，在于采用了事件流（Event Stream）和背压（Backpressure）机制。当用户在 Discord 说话时，语音包（Opus 编码）被实时抓取，并不等待一句话结束，而是立即转换成 PCM 音频流，并通过 WebSocket 或 gRPC-Stream 发送给语音识别服务。同时，AI 模型（如豆包 Omni）的文本回复也在生成中，一旦有部分文本生成，就立刻触发语音合成，生成的音频流再实时推回给 Discord 播放给用户。

这里最大的挑战是“节奏”控制。如果语音识别太快，而 AI 思考太慢，中间就会有空档；如果 AI 回复生成太快，而网络传输或播放有延迟，音频数据就会堆积，造成卡顿。Voice Hub 在中间层实现了背压控制，当下游（如 AI 处理）拥堵时，会向上游（语音接收）发送信号，适当减缓数据发送速度，或者启用音频缓冲池，平滑数据流，从而在整体上维持一个流畅的对话体验。这种设计避免了因为某个环节的瞬时高负载而导致整个链路雪崩。

2.2 插件化后台执行：解耦与灵活性

Voice Hub 另一个精妙的设计是将“大脑”功能彻底插件化。项目默认提供了 OpenClaw 和 Claude Code 两个插件，但这只是实现方式。其核心思想是：中间层只负责语音的进出和会话状态管理，而“说什么内容”完全交给后台插件决定。

这种解耦带来了巨大的灵活性：

能力可插拔：今天你可以用 Claude Code 插件，让它用代码解释你的问题；明天可以换成 OpenClaw 插件，让它操作浏览器帮你查资料。中间层的代码无需改动。
技术栈无关：后台插件可以用任何语言、任何框架实现，只要遵循 Voice Hub 定义的接口（通常是 HTTP Webhook 或 WebSocket）。这意味着你可以用 Python 的 FastAPI、Go 的 Gin，甚至是已有的 Java 服务来充当“大脑”。
资源隔离：语音处理（高 I/O，实时性要求高）和 AI 任务执行（可能消耗大量 CPU/内存）可以部署在不同的服务器上，通过内部网络通信，便于独立扩缩容。

在packages/目录下，你可以看到插件的结构：它们本质上是实现了特定接口的客户端 SDK。当中间层收到语音转文本的结果后，会通过配置好的 Webhook URL 或插件通道，将文本、会话上下文和用户信息打包发送给插件。插件处理完毕后，返回文本回复，中间层再负责将文本合成语音。这种设计让 Voice Hub 本身保持轻量和专注。

2.3 会话隔离与防串台：多用户并发支持

既然是在 Discord 这种可能有多个频道、多个用户同时使用的环境，会话隔离就是生命线。绝对不能出现用户 A 在频道 1 的问话，被 AI 在频道 2 回答了的“串台”事故。

Voice Hub 采用了复合键会话标识符。一个唯一的会话 ID 通常由DiscordGuildId:DiscordChannelId:DiscordUserId组合而成。中间层为每一个这样的组合维护独立的状态机、音频缓冲区和对话上下文。所有流入流出的音频流和数据包，都严格绑定这个会话 ID。

在代码层面，这通常体现为一个SessionManager类。它维护一个 Map，键是会话 ID，值是一个包含了 WebSocket 连接、语音合成器实例、后台插件客户端和对话历史的内存对象。当收到 Discord 的语音包时，首先提取出频道和用户信息，计算出会话 ID，然后路由到对应的 Session 对象进行处理。会话的生命周期也受到精细管理：用户加入频道时创建，用户离开或长时间无活动后销毁，防止内存泄漏。这种设计确保了即使在高压下，多个对话也能并行不悖。

3. 核心模块深度解析与实操要点

了解了宏观架构，我们深入到几个核心模块看看具体是怎么实现的，以及在实操中需要注意什么。

3.1 Discord 语音机器人：音频捕获与注入

Voice Hub 的前台入口是一个 Discord Bot。与普通处理文本命令的 Bot 不同，它需要加入语音频道，并处理原始的音频流。

技术实现要点：

库的选择：项目使用了discord.js库，并启用了Voice网关意图。关键是要使用支持接收和发送 Opus 音频流的版本。
接收语音（监听）：Bot 加入语音频道后，会订阅voiceReceiver的‘speaking’事件。当用户开始说话，会收到一个ReadableStream，里面是 Opus 编码的数据包。这里不能直接处理 Opus，需要先通过discord.js内置的opus解码器或@discordjs/opus库解码成 PCM 格式（16-bit, 48kHz），才能送给语音识别服务。
发送语音（播放）：Bot 需要通过AudioPlayer创建一个AudioResource。Voice Hub 的做法是，从语音合成服务拿到 PCM 流后，实时编码成 Opus 流，再通过createAudioResource方法，以一个Readable流的形式喂给AudioPlayer。这里要注意音频格式的匹配，否则会没声音或者杂音。

实操避坑指南：

注意：Discord 的音频流默认是立体声（Stereo），而很多语音识别服务（如豆包）要求输入是单声道（Mono）。如果你直接将立体声 PCM 流发送过去，识别率会骤降甚至失败。必须在解码后立即进行声道转换（通常是将左右声道取平均值）。同样，从语音合成服务返回的 PCM 流通常也是单声道，在送给 Discord 播放前，可能需要复制成双声道（左=右=原数据），以确保兼容性。

3.2 实时语音模型集成：火山引擎豆包 Omni

Voice Hub 选择了火山引擎的豆包端到端实时语音模型作为核心引擎。选择它有几个考量：一是它原生支持全双工和实时打断（VAD+Barge-in），二是 API 设计相对现代，支持流式传输，三是效果和稳定性在中文场景下表现不错。

集成流程解析：

初始化连接：根据配置，创建指向豆包语音服务（如openspeech.bytedance.com）的 gRPC 或 WebSocket 长连接。连接需要携带认证信息（API Key/Secret），这些信息来自用户的.env配置，符合 BYOK 原则。
建立双向流：豆包的 Omni 模型通常提供一个双向流式 RPC 方法。客户端（Voice Hub）通过这个流，可以持续发送音频数据包，同时持续接收识别出的中间文本和最终的文本结果。
处理中间结果与打断：这是实现“实时感”的关键。豆包流会实时返回partial_transcript（中间识别结果）。Voice Hub 会将这些中间文本立刻通过 Webhook 推送给后台插件，插件可以据此开始“思考”。同时，模型内置的 VAD（语音活动检测）会判断用户是否停止说话。当用户再次开口，模型会发送一个barge_in事件，Voice Hub 收到后必须立即中断当前正在进行的语音合成和播放，清空音频缓冲区，准备处理用户的新输入。这个“打断-重置”的逻辑必须在几十毫秒内完成，否则体验就会拖沓。

配置与降级策略：在.env中，你可以配置VOICE_PROVIDER。Voice Hub 贴心提供了多个选项：

doubao: 使用真实的火山引擎服务。
local-mock: 使用本地模拟服务，用于开发和测试，无需网络和密钥。
disabled: 完全关闭语音功能，仅测试文本通路。
qwen-dashscope: 理论上可切换至阿里云通义千问的语音服务（需自行实现适配器）。

这种设计保证了开发的灵活性。在本地联调时，用local-mock可以快速跑通流程；上线时再切换为真实的云服务。

3.3 后台插件通信：Webhook 与安全验签

后台插件是系统的“大脑”，中间层与它的通信必须可靠、安全。Voice Hub 主要采用HTTP Webhook的方式。

通信协议细节：

事件触发：当语音识别产生一个完整的句子（或重要的中间结果）时，Voice Hub 会构造一个 POST 请求，发送到插件配置的WEBHOOK_URL。
请求体内容：通常包含session_id、text（识别文本）、event_type（如transcription_complete或partial_transcription）、user_info等。插件根据这些信息决定如何回复。
期望的响应：插件处理完毕后，应返回一个 JSON，至少包含text字段（要合成的回复文本）。还可以包含should_stop（是否结束会话）、emotion（情感标签，供语音合成调节音色）等扩展字段。

安全验签机制：开放 Webhook 端点是危险的，可能被恶意调用。Voice Hub 实现了安全验签。其原理是：

中间层和插件共享一个预先配置的WEBHOOK_SECRET。
中间层在发送请求前，会用HMAC-SHA256算法，以secret为密钥，对请求体（或特定字符串）生成一个签名，放在请求头的X-Signature里。
插件收到请求后，用同样的算法和secret重新计算签名，并与请求头中的签名比对。只有一致才处理请求。

注意：在本地开发时，你可能为了方便会暂时关闭验签，但上线前务必开启并确保WEBHOOK_SECRET足够复杂。否则，攻击者可以向你的插件发送任意请求，伪造用户对话，甚至耗尽你的 AI 服务额度。

4. 从零开始的完整部署与调试实战

理论说得再多，不如动手跑一遍。下面我以本地开发环境为例，带你完整走一遍 Voice Hub 的部署、配置和联调过程。假设你已经有了基本的 Node.js 和 Discord 开发者经验。

4.1 环境准备与项目初始化

首先，确保你的系统满足基础要求：

Node.js：版本必须 >= 22.12.0。我推荐使用nvm来管理 Node 版本，可以轻松切换。用node -v检查。
包管理器：使用pnpm，版本 >= 9.0.0。它的 monorepo 管理和安装速度对这类项目非常友好。用pnpm -v检查。
Git：用于克隆代码。

# 1. 克隆仓库（请替换为实际仓库地址） git clone https://github.com/your-org/voice-hub-oss.git cd voice-hub-oss # 2. 安装项目所有依赖（包括各个子包） pnpm install # 这个过程会安装根目录和 packages/ 下所有子项目的依赖

安装完成后，你会看到项目采用了典型的Monorepo结构：

packages/app: 主应用，包含 Discord Bot 和核心中间层逻辑。
packages/openclaw-plugin: OpenClaw 插件。
packages/claude-marketplace-plugin: Claude Code 插件。
packages/types: 共享的 TypeScript 类型定义。
packages/config: 共享的 ESLint、Prettier 配置。

这种结构让代码复用和独立开发变得非常清晰。

4.2 关键配置详解与环境变量设置

项目根目录下有一个.env.example文件，复制它并重命名为.env，这是所有配置的核心。

cp .env.example .env

接下来，用文本编辑器打开.env文件，你需要配置以下几类关键信息：

1. Discord Bot 配置：

DISCORD_TOKEN=你的Discord_Bot_Token DISCORD_CLIENT_ID=你的Discord_Client_ID DISCORD_GUILD_ID=你的测试服务器ID（可选，用于快速注册命令）

如何获取DISCORD_TOKEN和DISCORD_CLIENT_ID？你需要去 Discord Developer Portal 创建一个应用，然后添加一个 Bot，在 Bot 设置页就能找到 Token。Client ID 在应用概览页。
记得在 OAuth2 -> URL Generator 里为你的 Bot 勾选bot和applications.commands权限，以及Connect,Speak,Use Voice Activity等语音权限，然后用生成的链接把 Bot 邀请到你的服务器。

2. 语音服务配置（以火山引擎为例）：

VOICE_PROVIDER=doubao DOUBAO_API_KEY=sk-你的火山引擎API_Key DOUBAO_API_SECRET=你的火山引擎API_Secret

你需要去火山引擎官网开通语音服务，并创建 API Key/Secret。在本地开发初期，可以先将VOICE_PROVIDER设为local-mock，跳过这一步，先测试 Discord 连接和插件通路。

3. 后台插件配置：

WEBHOOK_URL=http://localhost:3001/webhook WEBHOOK_SECRET=your_very_strong_secret_key_here PLUGIN_TYPE=openclaw # 或 claude-code

WEBHOOK_URL是你的后台插件服务监听的地址。如果你先测试中间层本身，可以暂时指向一个模拟服务，比如用npx http-server开个静态服务，或者用reqbin.com临时接收请求查看格式。
WEBHOOK_SECRET务必设置一个强密码，并在插件端使用相同的密钥。
PLUGIN_TYPE告诉中间层使用哪个插件的内部客户端来格式化请求。

4. 其他重要配置：

LOG_LEVEL=debug # 开发时设为debug，可以看到非常详细的流程日志 PORT=3000 # 中间层自身可能提供的管理API端口

4.3 启动服务与本地联调

配置好后，我们可以启动服务了。由于是 Monorepo，启动命令需要指定作用域。

# 1. 首先，构建整个项目（编译TypeScript） pnpm build # 2. 启动主应用（Discord Bot + 中间层）的开发模式 # --filter 指定只运行 packages/app 下的脚本 pnpm --filter @voice-hub/app dev

如果一切正常，终端会显示 Bot 已登录，并打印出邀请链接。用这个链接将 Bot 加入你的 Discord 测试服务器。

本地联调的核心是“分步验证”：

第一步：验证 Discord 连接
- 启动应用后，看日志是否显示Logged in as <你的Bot名>!。
- 在 Discord 频道里输入/ping命令（如果注册了），看 Bot 是否响应。这验证了基本的 Discord 连接和命令处理。
第二步：验证语音频道加入
- 让 Bot 加入一个语音频道（通常通过/join命令）。看日志是否有Joined voice channel...的提示，并且你在 Discord 客户端能看到 Bot 的用户卡在语音频道里。
第三步：验证语音接收与模拟处理（使用 local-mock）
- 确保.env中VOICE_PROVIDER=local-mock。
- 在 Bot 加入的语音频道里说话。观察应用日志。你应该能看到类似[Mock ASR] Received audio chunk, session: ...和[Mock ASR] Simulated transcription: “Hello”的日志。这说明 Discord 音频捕获和路由到语音处理模块的路径是通的。
- Mock 服务会模拟一个固定的回复，比如“这是模拟回复”。你应该能听到 Bot 在语音频道里播放这段音频。如果这一步没声音，问题大概率出在 Discord 语音发送（AudioPlayer）或音频编码环节。
第四步：验证 Webhook 调用
- 在上一步，Mock 服务除了模拟回复，还会模拟调用 Webhook。查看日志中是否有Calling webhook to URL: ...的条目。
- 你可以使用ngrok或localtunnel将本地的WEBHOOK_URL（如http://localhost:3001/webhook）暴露成一个公网 URL，然后配置到.env中。这样，你就可以在真实的公网端点（比如一个你写的测试服务器）看到中间层发送过来的请求体格式，验证验签是否正常。
第五步：集成真实语音服务与后台插件
- 将VOICE_PROVIDER改为doubao，并填入真实密钥。
- 启动你的后台插件服务（比如运行 OpenClaw 或一个简单的测试插件）。
- 现在进行完整测试：你说话 -> 豆包识别 -> 文本通过 Webhook 发给插件 -> 插件返回文本 -> 豆包合成语音 -> Bot 播放。观察每个环节的日志和延迟。

4.4 插件开发与集成示例

假设你想自己写一个最简单的 Echo 插件来测试，可以用 Node.js 快速实现：

// simple-echo-plugin.js import express from 'express'; import crypto from 'crypto'; const app = express(); const port = 3001; const WEBHOOK_SECRET = process.env.WEBHOOK_SECRET || 'your_secret'; // 需与中间层.env一致 app.use(express.json()); app.post('/webhook', (req, res) => { // 1. 安全验签 const signature = req.headers['x-signature']; const payload = JSON.stringify(req.body); const expectedSig = crypto.createHmac('sha256', WEBHOOK_SECRET).update(payload).digest('hex'); if (signature !== expectedSig) { console.warn('Invalid signature!'); return res.status(401).send('Unauthorized'); } // 2. 处理请求 const { session_id, text, event_type } = req.body; console.log(`[Plugin] Session ${session_id}, Event: ${event_type}, Text: "${text}"`); // 3. 构造回复（这里简单做回声） const responseText = `我听你说的是：“${text}”。对吗？`; // 4. 返回标准格式的响应 res.json({ text: responseText, // 可以附加其他指令，如停止会话 // should_stop: false, }); }); app.listen(port, () => { console.log(`Echo plugin listening on http://localhost:${port}`); });

运行这个插件node simple-echo-plugin.js，并将中间层的WEBHOOK_URL指向http://localhost:3001/webhook。这样，你和 Bot 的每一句对话，都会被这个插件原样反问回来，非常适合验证整个链路的通畅性。

5. 常见问题排查与性能调优实录

在实际部署和开发中，你肯定会遇到各种问题。下面是我踩过的一些坑和解决方案，希望能帮你节省时间。

5.1 音频问题：没声音、杂音、延迟高

这是最常见的问题类别。

症状：Bot 加入了频道，但不说话或播放杂音。
- 检查音频子网：Discord 语音需要 UDP 协议。某些网络环境（如公司内网、部分校园网）会封锁或限制 UDP。尝试更换网络，或用telnet discord.com 443和telnet discord.com 3478测试 UDP 可达性（后者是 STUN 服务）。
- 验证编码器：确保@discordjs/opus或opusscript已正确安装。可以尝试在代码里强制指定audioPlayer: { opusEncoder: ‘@discordjs/opus’ }。如果安装失败，可能需要系统级的opus库，在 Ubuntu 上可以sudo apt-get install libopus-dev。
- 检查音频格式：再次强调声道问题。在日志中打印出入场 PCM 数据的channels和sampleRate，确保发送给语音识别服务的是单声道（1 channel），送给 Discord 播放的是立体声（2 channels）。格式转换的代码务必仔细核对。
症状：延迟非常高（>2秒），对话体验差。
- 定位延迟环节：在代码关键节点（收到音频包、发送给 ASR、收到 ASR 结果、发送给插件、收到插件回复、开始 TTS、收到 TTS 音频包、开始播放）打上时间戳日志，计算各阶段耗时。
- 网络延迟：如果 ASR/TTS 服务在海外，延迟会显著增加。考虑使用国内节点或寻找延迟更低的服务商。
- 插件处理慢：如果插件处理逻辑复杂（如调用大语言模型），会导致整体延迟。考虑在插件端实现流式文本返回（即边生成边返回），这样中间层可以更早开始 TTS，实现“首字响应时间”的优化。
- 缓冲队列过长：检查AudioPlayer的内部缓冲区。如果积压了大量未播放的音频包，可以适当调整highWaterMark参数，或者在合成语音时使用更小的数据块。

5.2 会话与状态问题：串台、内存泄漏

症状：用户 A 的对话内容出现在了用户 B 的频道。
- 复查会话 ID 生成逻辑：确保从 Discord 事件对象（interaction、voiceStateUpdate）中提取guildId、channelId、userId的代码正确无误。特别是在处理speaking事件时，事件对象可能不直接包含频道信息，需要通过voiceState来查找。
- 检查事件监听器：确保每个会话的事件监听器是独立的，并且正确绑定了会话上下文。避免使用全局变量或单例来存储会话数据。
症状：运行一段时间后，内存占用持续升高。
- 会话泄漏：确保在用户离开频道、会话超时或出错时，正确调用session.destroy()方法，移除所有事件监听器，清理AudioPlayer、VoiceConnection等资源，并从SessionManager的 Map 中删除引用。
- 音频流未关闭：检查处理音频ReadableStream的代码，在流结束或出错时，是否调用了.destroy()或自动关闭。未关闭的流会一直占用内存。
- 使用内存分析工具：可以用node --inspect启动应用，然后用 Chrome DevTools 的 Memory 面板拍摄堆快照，查看哪些对象没有被释放。

5.3 部署与运维问题

症状：在 Docker 或生产服务器中运行失败。
- 依赖库原生编译：@discordjs/opus等库可能有原生绑定（C++ addon）。在 Docker 中构建时，需要确保镜像包含python3、make、g++等编译工具链。建议使用node:22-slim或node:22-alpine作为基础镜像，并安装build-essential（Debian）或alpine-sdk（Alpine）。
- 环境变量注入：确保生产环境的.env文件或通过环境（如 Docker-e， K8sConfigMap）正确传递了所有密钥。特别是WEBHOOK_SECRET和各个 API Key。
- 防火墙与网络策略：生产服务器的出站规则需要允许连接到 Discord 网关、语音服务器以及你使用的云语音服务（如火山引擎）的特定端口。
症状：如何监控和日志记录？
- 结构化日志：不要只用console.log。使用winston或pino库，将日志输出为 JSON 格式，并区分error、warn、info、debug等级别。便于后续用 ELK 或 Loki 收集分析。
- 关键指标监控：在代码中埋点，记录每个会话的“端到端延迟”（用户开口到听到回复）、ASR/TTS 服务调用耗时、错误率等。这些指标可以通过Prometheus客户端暴露，然后由Grafana展示。
- 健康检查端点：为中间层服务添加一个/health路由，返回服务状态、连接池状态等。便于容器编排系统（如 K8s）进行存活性和就绪性探测。

6. 扩展思路与进阶玩法

当你把基础版本跑通后，可以尝试一些更有趣的扩展，让这个系统变得更强大。

1. 多模态扩展：目前的流程是语音 -> 文本 -> AI -> 文本 -> 语音。你可以让后台插件的能力不止于文本。例如，插件可以返回一个结构化的指令：{ text: “请看这张图”, image_url: “https://...” }。中间层可以扩展，在播放语音的同时，通过 Discord 的频道消息接口将图片发送到聊天窗口，实现“语音解说图片”的效果。

2. 语音情感与音色控制：豆包等 TTS 服务通常支持通过 SSML 或参数控制语速、音调、音色。你可以在后台插件返回的响应中增加一个voice_config字段，里面包含emotion（如高兴、悲伤）、speech_rate等参数。中间层将这些参数传递给 TTS 服务，让 AI 的回复更具表现力。

3. 实现“记忆”与多轮对话：目前每次 Webhook 调用，上下文可能有限。你可以在中间层的Session对象里维护一个对话历史数组。每次将用户问题和 AI 回答都存进去。当下次请求插件时，将最近 N 轮历史一同发送。这样插件（尤其是大语言模型）就能进行连贯的多轮对话。注意要设置历史长度上限，防止上下文过长。

4. 负载均衡与高可用：当用户量增大时，一个中间层实例可能不够。你可以：

无状态化：将Session状态存储到外部 Redis 中，使多个中间层实例可以共享状态，任何一个实例宕机，会话都能被其他实例接管。
插件负载均衡：配置多个相同功能的插件实例，中间层通过简单的轮询或一致性哈希算法，将请求分发到不同的插件后端，避免单点瓶颈。

这个项目就像一个功能强大的“语音总线”，你可以在上面接驳各种有趣的“大脑”和“感官”。从简单的聊天机器人，到能控制智能家居的语音助手，再到游戏内的实时旁白系统，想象力是唯一的限制。我在实际把玩中最大的体会是，稳定和低延迟是语音交互的基石，而这需要你在音频处理、网络通信和异步编程的每一个细节上都仔细打磨。

查看全文

http://www.jsqmd.com/news/794818/