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

构建Discord与GitHub知识库：llmcord项目实战与RAG应用

news 2026/5/15 1:32:39

1. 项目概述与核心价值

最近在折腾一些AI应用，发现一个挺有意思的现象：很多开发者习惯在Discord上讨论技术、分享进度，但Discord本身的消息流是“实时”且“瞬时”的，有价值的讨论很容易被淹没。同时，像GitHub Issues、Pull Requests这类开发协作信息，又散落在另一个平台。有没有一种工具，能把这两个地方的关键信息“拉”到一起，形成一个可查询、可追溯的知识库？这就是我今天要聊的llmcord项目。

简单来说，llmcord是一个开源工具，它的核心功能是将Discord服务器中的对话内容，与GitHub仓库的Issues、PRs等信息进行关联、索引，并构建成一个可供大型语言模型（LLM）高效检索的本地知识库。它不是一个聊天机器人，而是一个“信息连接器”和“记忆增强器”。想象一下，你可以在一个统一的界面里，用自然语言提问：“上周关于‘用户认证模块重构’的讨论，最后达成了什么共识？相关的PR链接是什么？” 系统能立刻从历史Discord聊天记录和GitHub动态中，找到最相关的信息片段并呈现给你。

这个工具特别适合开源项目社区、远程技术团队以及任何将Discord作为主要协作沟通阵地，同时使用GitHub进行代码管理的组织。对于项目维护者，它能快速回溯技术决策过程；对于新加入的贡献者，它是绝佳的“历史档案”查阅工具，能极大降低融入社区和了解项目背景的成本。其背后的核心技术栈围绕着信息抓取、向量化存储与检索展开，我们接下来会深入拆解。

2. 核心架构与工作流程拆解

llmcord的架构设计清晰地反映了其“连接”与“索引”的使命。它不是一个大而全的All-in-One应用，而是由几个职责分明的模块组成，通过清晰的管道（Pipeline）串联起来。理解这个架构，是后续进行部署、定制和问题排查的基础。

2.1 核心组件解析

整个系统可以划分为四个核心层：

数据采集层（Ingestion）：这是信息入口。它包含两个主要的“爬虫”或“采集器”。
- Discord采集器：通过Discord官方API（需要Bot Token），以指定的时间频率或触发条件，读取特定频道、特定时间范围内的消息。这里的关键在于，它不仅要采集纯文本消息，还需要处理消息的上下文（回复链）、附件（如图片、代码片段）、以及发送者信息，以保留对话的完整脉络。
- GitHub采集器：通过GitHub API（需要Personal Access Token），定时或按事件（如Webhook）抓取指定仓库的Issues、Pull Requests、Comments甚至Wiki页面。采集时需要关注标题、正文、标签、状态、关联的提交等元数据。
数据处理与向量化层（Processing & Embedding）：原始数据不能直接用于语义检索。这一层负责“加工”。
- 文本分块（Chunking）：无论是长篇的GitHub Issue描述，还是冗长的Discord讨论串，都需要被切割成大小适中的文本块。分块策略直接影响检索质量。llmcord通常会采用基于标记（Token）数量或自然段落（如\n\n）的滑动窗口法，并可能重叠部分内容以避免割裂关键信息。
- 向量化（Embedding）：这是核心步骤。每个文本块通过一个预训练的嵌入模型（如text-embedding-ada-002、BGE或本地部署的all-MiniLM-L6-v2）转换为一个高维向量（例如1536维）。这个向量在数学空间中的“位置”代表了该文本的语义。语义相近的文本，其向量在空间中的距离也更近。
存储层（Vector Database）：用于存储上一步生成的向量及其对应的原始文本（元数据）。llmcord通常集成主流的向量数据库，如ChromaDB、Qdrant或Pinecone（云服务）。向量数据库的核心能力是进行“近似最近邻搜索（ANN）”，即快速从海量向量中找出与查询向量最相似的几个。元数据则用于存储来源（是Discord消息#xxx，还是GitHub PR #123）、时间戳、作者等信息，便于结果溯源。
查询接口层（Query Interface）：这是面向用户或上层应用（如Chatbot）的界面。它接收一个自然语言问题，首先使用与向量化层相同的嵌入模型将问题转换为查询向量。然后，将该查询向量发送给向量数据库进行相似性搜索，返回最相关的K个文本块。最后，这些文本块及其元数据被封装成结构化的结果返回。更高级的实现可能会将检索到的文本块作为上下文，送入LLM（如GPT-4、Claude或本地LLM）进行总结或重组，生成更人性化的答案。

2.2 端到端工作流程

一次完整的数据更新与查询流程如下：

配置与初始化：填写Discord Bot Token、GitHub Token、目标频道ID、仓库名等配置信息。选择并初始化向量数据库（如本地ChromaDB实例）。
数据抓取：调度器触发采集任务。Discord采集器从上次记录的位置开始抓取新消息；GitHub采集器拉取最新的Issues/PRs活动。
清洗与分块：对抓取的原始JSON数据进行解析，提取出有意义的纯文本内容和关键元数据。然后应用分块算法，将长文本切割。
生成嵌入向量：将每个文本块送入嵌入模型，获得其向量表示。
向量入库：将(向量, 文本块, 元数据)这个三元组，作为一个记录，存入向量数据库。数据库会自动为向量创建索引以加速后续检索。
用户查询：用户提出问题，如“如何设置项目的开发环境？”。
查询向量化与检索：系统将问题转化为向量，在向量数据库中搜索相似向量，返回前5个最相关的文本块。
结果呈现与增强：直接返回这些文本块及其来源链接。或者，将它们作为提示词的一部分，发送给LLM：“请基于以下上下文回答问题：... [检索到的文本块] ... 问题：如何设置项目的开发环境？”。LLM会生成一个连贯、准确的答案。

注意：步骤8中的LLM生成答案功能，在llmcord的基础版本中可能是一个可选项或需要额外集成。其核心价值首先在于完成了从多源异构数据到统一可检索向量库的构建。

3. 关键配置与实操部署指南

理论清晰后，我们来动手部署一个属于自己的llmcord实例。这里假设我们在一个Linux服务器或本地开发环境（Mac/Linux）上进行操作。我们将使用Python作为主要环境，并选择ChromaDB作为本地向量数据库，以简化部署。

3.1 环境准备与依赖安装

首先，确保你的系统有Python 3.10或更高版本。推荐使用conda或venv创建独立的Python环境，避免包冲突。

# 创建并激活虚拟环境 python -m venv llmcord_env source llmcord_env/bin/activate # Linux/Mac # llmcord_env\Scripts\activate # Windows # 升级pip pip install --upgrade pip

接下来，安装核心依赖。llmcord项目本身可能没有直接打包到PyPI，我们需要从GitHub克隆源码并安装。

# 克隆仓库（假设这是项目地址，请替换为实际地址） git clone https://github.com/jakobdylanc/llmcord.git cd llmcord # 安装项目依赖 # 通常项目根目录会有 requirements.txt 或 pyproject.toml pip install -r requirements.txt

如果项目没有提供明确的requirements.txt，根据其架构，我们可能需要手动安装以下关键库：

pip install discord.py # Discord API交互 pip install PyGithub # GitHub API交互 pip install chromadb # 向量数据库 pip install openai # 如果使用OpenAI的嵌入模型 # pip install sentence-transformers # 如果使用本地嵌入模型如all-MiniLM-L6-v2 pip install langchain # 常用于编排链条，可能被依赖 pip install python-dotenv # 管理环境变量

3.2 关键凭证获取与配置

这是最重要且敏感的一步。我们需要申请两个API凭证。

1. Discord Bot Token:

访问 Discord Developer Portal 。
点击“New Application”，为你的Bot起个名字。
在左侧边栏进入“Bot”页面，点击“Reset Token”或“Copy Token”。务必妥善保管，它一旦显示后就不会再次完整显示。
在同一个页面，确保关闭“Public Bot”开关（除非你想公开），并开启“Message Content Intent”特权。这是Bot读取消息内容所必需的。
在“OAuth2” -> “URL Generator”页面，勾选bot作用域，并在Bot权限中勾选Read Message History。生成邀请链接，用这个链接将Bot邀请到你的目标服务器。

2. GitHub Personal Access Token (Classic):

登录GitHub，点击头像 -> Settings -> Developer settings -> Personal access tokens -> Tokens (classic)。
点击“Generate new token (classic)”。给它一个描述性名称（如llmcord-indexer）。
选择权限范围。至少需要repo（访问仓库内容）和read:org（如果仓库在组织下）。对于公开仓库，public_repo权限可能足够。
生成令牌并立即复制保存。和Discord Token一样，它只显示一次。

配置管理：绝对不要将令牌硬编码在代码中。最佳实践是使用环境变量或.env文件。

# 在项目根目录创建 .env 文件 touch .env

在.env文件中填入你的凭证：

# .env 文件内容 DISCORD_BOT_TOKEN=你的Discord_Bot_Token_字符串 GITHUB_ACCESS_TOKEN=你的GitHub_Personal_Access_Token_字符串 DISCORD_CHANNEL_IDS=123456789012345678,234567890123456789 # 要监听的频道ID，多个用逗号分隔 GITHUB_REPO_OWNER=your_org_or_username GITHUB_REPO_NAME=your_repo_name # 嵌入模型配置，例如使用OpenAI EMBEDDING_MODEL=text-embedding-ada-002 OPENAI_API_KEY=sk-... # 如果使用OpenAI模型 # 或使用本地模型 # EMBEDDING_MODEL=sentence-transformers/all-MiniLM-L6-v2

在你的主配置脚本或代码中，使用python-dotenv加载这些变量。

# config.py 或主脚本开头 import os from dotenv import load_dotenv load_dotenv() # 加载 .env 文件中的变量到环境变量 DISCORD_BOT_TOKEN = os.getenv('DISCORD_BOT_TOKEN') GITHUB_ACCESS_TOKEN = os.getenv('GITHUB_ACCESS_TOKEN') # ... 其他配置

3.3 首次运行与数据索引

配置完成后，就可以运行数据索引脚本了。通常项目会提供一个主脚本，比如main.py或ingest.py。

# 假设入口脚本是 main.py python main.py --mode ingest

这个ingest模式可能会执行以下操作：

初始化连接到Discord和GitHub的客户端。
初始化或连接到本地的ChromaDB集合（Collection）。集合是向量数据库中存储相关数据的基本单位，你可以为每个Discord服务器+GitHub仓库的组合创建一个独立的集合。
开始抓取Discord历史消息（可能从最近几天开始，或全量抓取，取决于配置）和GitHub Issues/PRs。
对抓取的内容进行分块、向量化，并存入ChromaDB。

首次全量索引可能会花费较长时间，具体取决于历史数据的多少。你可以在控制台看到日志输出，了解进度。

实操心得：对于非常大的历史数据，建议分批次进行，或者设置一个合理的回溯时间限制（例如只索引最近6个月的数据），避免首次运行时间过长或触发API速率限制。可以在代码中为Discord和GitHub的采集器添加since参数来控制。

3.4 查询功能测试

索引完成后，可以测试查询功能。项目可能提供了一个简单的查询脚本或交互式界面。

# 假设有 query.py python query.py "如何提交一个Pull Request？"

如果配置正确，你应该能看到返回的相关文本片段，每个片段都附带了来源信息，例如：

来源: Discord - #general - 用户Alice (2023-10-26) 内容: “提交PR前，记得先fork仓库，然后在自己的fork里创建分支，再发起Pull Request。模板在.github/PULL_REQUEST_TEMPLATE.md里。” 来源: GitHub Issue #45 - “关于PR流程的文档更新” 内容: “我们更新了贡献指南，强调了在PR描述中需要关联相关Issue编号，并使用‘Fixes #’语法。”

这证明你的llmcord系统已经成功构建并可以工作了。

4. 高级定制与优化策略

基础功能跑通后，我们可以根据实际需求进行深度定制和优化，以提升系统的实用性、准确性和效率。

4.1 数据源与采集策略定制

1. 扩展数据源：llmcord的架构是插件化的。除了Discord和GitHub，你可以相对容易地集成其他数据源。

Slack/Teams：原理与Discord类似，需要对应平台的Bot Token和API。
Confluence/Notion：通过其API抓取页面内容，构建项目文档知识库。
邮件列表/Zendesk：将客服邮件或支持工单纳入索引，用于快速查找已知问题解决方案。实现时，你需要编写一个新的“采集器”类，实现统一的fetch_data()和parse_to_documents()接口，输出格式化的文本块和元数据。

2. 优化采集策略：

增量同步：全量索引后，后续运行应只抓取新增或修改的内容。对于Discord，记录最后一条已处理消息的ID；对于GitHub，利用API的since参数或监听Webhook事件。
速率限制处理：Discord和GitHub API都有严格的速率限制。必须在代码中实现指数退避的重试逻辑，并合理设置请求间隔，避免被禁。
选择性采集：不是所有频道或所有类型的Issue都需要。可以通过配置白名单/黑名单，忽略#off-topic这类闲聊频道，或只采集带有特定标签（如bug，documentation）的Issue。

4.2 文本处理与向量化优化

这是影响检索质量最关键的环节。

1. 分块策略的权衡：

块大小（Chunk Size）：通常设置在256-1024个标记（Token）之间。太小会丢失上下文，太大会引入噪声并降低检索精度。对于代码讨论，可能需要更小的块来精确匹配函数或错误信息；对于设计讨论，可能需要更大的块来保持逻辑完整。
块重叠（Chunk Overlap）：设置50-150个标记的重叠，可以确保一个概念如果恰好被分块边界切断，它在相邻块中仍然存在，提高被检索到的概率。
智能分块：超越简单的滑动窗口。可以尝试按语义分割，例如使用langchain的RecursiveCharacterTextSplitter，它优先按段落、句子等自然边界分割，效果通常更好。

2. 嵌入模型选型：

云端API（易用、强大）：如OpenAI的text-embedding-3-small/large。优势是效果稳定，无需本地GPU，但会产生持续费用，且数据需发送到第三方。
本地模型（可控、私有）：如sentence-transformers库提供的all-MiniLM-L6-v2（通用）、multi-qa-mpnet-base-dot-v1（针对问答优化）。优势是数据完全私有，无网络延迟，但需要本地计算资源，且效果可能略逊于顶级云端模型。
选型建议：初期验证可用小型本地模型或OpenAI的低成本模型。对隐私要求极高或数据量巨大时，考虑在本地部署更大的嵌入模型（如BGE-large），并可能使用GPU加速。

3. 元数据增强：在存储向量时，附加上丰富的元数据，可以在后续检索和过滤中发挥巨大作用。

基础元数据：source(discord/github),channel/repo,author,timestamp,url(直接链接)。
语义元数据：在索引时，可以用一个轻量级模型或规则为文本块打上标签，例如topic: authentication,type: error_log,sentiment: positive。这样，在检索时不仅可以做语义搜索，还可以进行过滤：“找出Discord中关于‘认证’且情绪为‘负面’的讨论”。

4.3 检索与查询增强

1. 混合搜索（Hybrid Search）：单纯的向量搜索（语义搜索）有时会忽略精确的关键词匹配。混合搜索结合了：

稀疏检索（如BM25）：基于关键词匹配，擅长查找包含特定术语（如函数名、错误代码）的文档。
稠密检索（向量搜索）：基于语义相似度。将两者的结果按分数融合（如加权求和），能同时保证召回率和精确度。许多现代向量数据库（如Qdrant, Weaviate）已内置支持混合搜索。

2. 重排序（Re-ranking）：向量搜索初步返回了Top K个相关块（例如K=20）。我们可以用一个更精细但更耗时的“重排序模型”对这20个结果进行二次排序，选出最精准的Top 3或5个作为最终上下文。例如，使用BGE-reranker或Cohere的rerank API。这能显著提升最终答案的质量，尤其当初步检索结果较多时。

3. 查询理解与扩展：在将用户问题转换为向量前，可以对问题进行优化。

查询改写：如果用户问“咋装？”，系统可以将其改写为“如何安装此软件？”。
查询扩展：基于问题生成同义词或相关术语。例如，对于“OOM错误”，可以扩展为“内存不足错误 OutOfMemoryError”。这能增加检索到相关文档的机会。

将这些策略组合起来，一个增强的查询流程可能是：原始问题 -> 查询理解/扩展 -> 向量化 -> (混合搜索) -> 获取Top 20候选 -> 重排序 -> 获取Top 3上下文 -> 送入LLM生成答案。

5. 集成应用与场景拓展

构建好llmcord核心引擎后，如何将它用起来？以下是几种典型的集成和应用模式。

5.1 与聊天机器人（Chatbot）集成

这是最直接的应用。你可以创建一个Discord Bot或Slack Bot，它将用户的问题转发给llmcord的查询接口，并将返回的答案或生成的总结发送回频道。

实现模式：

检索增强生成（RAG）模式：Bot接收到问题后，调用llmcord检索出最相关的3-5个文本块，然后将“问题+上下文”组合成一个提示词（Prompt），发送给LLM（如通过OpenAI API或本地运行的Ollama+Llama 3）生成友好、准确的答案。
直接引用模式：对于事实性非常强的问题（如“某功能的PR编号是多少？”），Bot可以直接返回检索到的原始文本块和链接，避免LLM“胡编乱造”。

示例提示词模板：

你是一个技术社区助手，请严格根据以下提供的上下文信息来回答问题。如果上下文信息不足以回答问题，请直接说“根据现有资料无法回答”，不要编造信息。 上下文信息： --- {context_chunk_1} 来源：{source_1} --- {context_chunk_2} 来源：{source_2} --- （更多上下文块...） 问题：{user_question} 请基于上述上下文，给出准确、简洁的回答，并在末尾附上相关信息的来源链接。

5.2 构建内部知识库门户

为团队打造一个简单的Web界面，提供一个统一的搜索框。员工可以在这里搜索过去所有的技术讨论、决策记录、问题解决方案和PR链接。这个门户可以集成用户认证，确保信息安全。

技术栈可以非常轻量：用FastAPI或Flask构建后端API（封装llmcord的查询逻辑），用Vue或React构建一个简单的前端页面。搜索结果可以美观地展示内容摘要、来源、时间和相关度分数。

5.3 自动化工作流触发

llmcord不仅可以被动查询，还可以主动监控和触发。

新人入群欢迎与指引：当检测到新成员加入Discord特定频道时，Bot可以自动发送一条消息，内容是基于历史问答总结出的“常见问题（FAQ）”或“入门指南”。
重复问题自动应答：监控频道中的新消息，实时将其向量化并与知识库比对。如果发现与历史已解决问题高度相似（相似度超过阈值），Bot可以自动回复：“这个问题我们之前讨论过，可以参考[链接]”。这能极大减轻维护者的负担。
周报/月报自动生成：定期（如每周一）运行一个查询，检索过去一周内讨论热度高（消息数多）或标记为decision的文本块，利用LLM总结生成一份“社区动态周报”，自动发布到特定频道。

5.4 场景拓展思考

游戏开发社区：将Discord中的玩法讨论、Bug反馈与GitHub上的策划文档、Issue跟踪关联。策划可以快速查询玩家对某个新系统的真实反馈。
开源项目治理：将社区讨论、RFC（Request for Comments）帖子与最终的代码实现（PR）关联，形成完整的决策链路，便于审计和传承。
客户支持团队：集成客服聊天记录（如Intercom）、帮助中心文章和内部解决方案文档。新客服人员可以快速找到类似客户问题的处理方案。

6. 常见问题、故障排查与优化心得

在实际部署和运行llmcord的过程中，你一定会遇到各种问题。下面是我踩过的一些坑以及总结的排查思路。

6.1 数据采集类问题

问题1：Discord Bot 无法读取消息历史或新消息。

检查点：
1. 权限：确保Bot在邀请链接中已授予Read Message History和View Channel权限。在服务器设置中，检查Bot所在角色是否有访问目标频道的权限。
2. 意图（Intents）：在Discord开发者门户的Bot设置页面，必须启用MESSAGE_CONTENT_INTENT。这是2022年后Discord的新规，没有它，Bot看不到消息内容。
3. 频道ID：确认配置中的频道ID是正确的。在Discord设置中开启“开发者模式”，然后右键点击频道即可复制ID。

问题2：GitHub API 速率限制（Rate Limit）频繁触发。

排查与解决：
1. 使用Token：未经验证的请求速率限制极低（60次/小时）。使用GitHub Personal Access Token可以大幅提升限制（对于认证用户，通常为5000次/小时）。
2. 检查剩余次数：API响应头中包含X-RateLimit-Remaining和X-RateLimit-Reset。在你的代码中实现监控，当剩余次数过低时暂停或报警。
3. 实现指数退避：在请求失败（返回429状态码）时，不要立即重试。读取Retry-After响应头，或实现一个指数增长的等待时间（如1秒，2秒，4秒...）。
4. 优化请求：尽量使用条件请求（如If-Modified-Since头）和增量同步，避免全量拉取。合并请求，例如使用GraphQL API在一次请求中获取多种数据。

问题3：采集到的文本杂乱，包含大量机器人命令、无关引用等。

解决策略：在数据处理层（分块之前）增加一个清洗过滤器。
- 使用正则表达式过滤掉以特定前缀（如!，/）开头的消息（通常是Bot命令）。
- 移除纯URL、纯表情符号的消息。
- 对于Discord，可以尝试剥离消息中的<@userID>提及标记，替换为用户名。
- 可以基于发送者ID，过滤掉某些特定Bot的消息。

6.2 检索质量类问题

问题4：检索结果不相关，总是返回一些泛泛而谈的内容。

优化方向：
1. 调整分块大小和重叠：这是首要怀疑对象。尝试将块大小调小（如从512调到256），并增加重叠（如从50调到100）。对于问答场景，较小的块往往更精准。
2. 检查嵌入模型：你使用的嵌入模型是否适合你的文本领域（主要是英文技术讨论？中文？）。可以尝试换一个模型，例如从text-embedding-ada-002切换到针对问答优化的text-embedding-3-large，或本地的BGE模型。
3. 尝试混合搜索：如果你的向量数据库支持，开启关键词（稀疏检索）与向量检索的混合模式，并调整两者的权重比例。
4. 增强查询：对用户的问题进行预处理，如提取关键词、进行同义扩展，或者让LLM先对问题进行重写和丰富，再用于检索。

问题5：LLM基于上下文生成的答案出现“幻觉”，编造了不存在的信息。

解决策略：
1. 强化提示词（Prompt）：在给LLM的指令中，必须强调“严格基于上下文”，“如果上下文没有提到，就说不知道”。可以使用更严厉的措辞。
2. 提供引用源：要求LLM在答案中指明依据的是哪一段上下文（例如，用[1]，[2]标注），并在最终回复中附上这些上下文的原始链接。这既增加了可信度，也方便用户溯源。
3. 减少上下文长度：给LLM喂太多的上下文可能会让它混淆。尝试只提供相似度最高的前1-3个文本块，而不是前10个。
4. 使用“引用检查”后处理：生成答案后，可以再用一个简单的程序检查答案中的关键事实（如日期、名称、数字）是否在提供的上下文中出现，如果没有，则标记答案可能不可靠。

6.3 性能与运维类问题

问题6：向量数据库（如ChromaDB）在数据量增大后，检索速度变慢。

优化建议：
1. 索引类型：ChromaDB默认使用HNSW索引，这是一种近似搜索算法，在速度和精度上有很好的平衡。确保你使用的是合适的索引参数（如ef_construction，M）。对于纯内存操作，速度通常不是瓶颈。
2. 持久化与内存：如果使用persist_directory将数据保存到磁盘，每次查询都需要加载数据。确保服务器有足够的内存，或者考虑使用客户端-服务器模式的ChromaDB，让数据库常驻内存。
3. 数据分区：如果数据量极大（超过百万条），考虑按时间或主题创建多个集合（Collection），查询时根据问题范围选择对应的集合，而不是扫描全部数据。
4. 升级硬件或换用专业向量数据库：对于生产环境，可以考虑使用性能更优的向量数据库，如Qdrant、Weaviate或Milvus，它们为大规模向量检索做了更多优化。

问题7：如何持续更新知识库？

方案设计：
- 定时任务（Cron Job）：最简单的方式。使用系统的cron或Python的APScheduler库，每隔一段时间（如每小时）运行一次增量索引脚本。
- Webhook实时触发（更优雅）：对于GitHub，可以在仓库设置中配置Webhook，当有新的Issue、PR或Comment时，GitHub会主动向你的服务发送一个POST请求，触发对该特定内容的即时索引。对于Discord，Bot本身就在实时监听消息，可以在收到消息后立即或批量进行索引。实时触发能保证知识库的“新鲜度”。

最后，维护这样一个系统，监控是必不可少的。建议记录每次数据抓取的数量、耗时，查询的响应时间，以及用户反馈的答案质量。这些日志能帮助你持续优化系统参数，比如调整抓取频率、分块策略或模型选型，让llmcord真正成为团队效率的助推器，而不是一个摆设。

查看全文

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