1. 项目概述：打造一个丝滑的AI对话机器人
最近在折腾一个挺有意思的东西，一个基于Telegram平台的ChatGPT机器人。简单来说，就是让你能在Telegram这个全球流行的即时通讯软件里，像跟朋友聊天一样，直接和AI对话、画图，还能切换不同的人设。这个项目叫V-know/ChatGPT-Telegram-Bot，核心就是用Python把OpenAI（或者Azure OpenAI）的强大能力，无缝对接到Telegram的机器人框架里。
为什么做这个？市面上虽然已经有一些类似的机器人，但要么响应慢吞吞，等一句话要半天；要么功能单一，只能问不能画；再就是配置复杂，对新手不友好。我这个项目的目标，就是提供一个“丝滑”的体验。这个词儿我反复强调，因为它确实是我设计的核心：从流式响应（你打字，AI几乎实时地、一个字一个字地回复你），到一键清除对话、预设角色快速切换，再到直观的Telegram原生按钮交互，所有细节都是为了让你感觉不到技术的存在，就像在用一款设计精良的产品。
这个机器人适合谁呢？如果你是开发者，想学习如何将大语言模型API集成到实际应用中，这是一个绝佳的、功能完整的参考项目。它涵盖了机器人交互、数据库管理、用户系统、流式处理等关键模块。如果你是普通用户，只是想拥有一个私人的、功能强大的AI助手，跟着这篇指南，你也能从零开始，部署一个完全属于自己、可控可配置的Telegram AI伙伴。接下来，我会把整个项目的设计思路、技术细节、部署踩过的坑，以及一些能让机器人更“聪明”的调优技巧，毫无保留地分享出来。
2. 核心架构与设计思路拆解
2.1 技术栈选型：为什么是它们？
一个稳定、易扩展的机器人，技术选型是地基。这里我详细拆解一下每个核心组件的选择理由。
后端框架：Python + python-telegram-bot v20+选择Python无需多言，在AI和快速开发领域，它的生态和易用性首屈一指。关键在于python-telegram-bot这个库，我选择了v20.3及以上版本。这是一个重要的分水岭。v20版本完全重构，采用了异步（asyncio）作为一等公民。对于需要同时处理大量用户消息、并进行可能耗时的AI API调用的机器人来说，异步IO是保证“丝滑”体验的基石。它能让你在等待AI回复一个用户时，毫不阻塞地处理其他用户的消息或点击事件。相比之下，旧的同步版本在并发量稍大时就会显得卡顿。
AI服务端：OpenAI API 与 Azure OpenAI 双支持直接使用OpenAI官方的API是最直接的方式，全球访问，模型更新快。但我额外集成了Azure OpenAI的支持，这主要是出于几点实际考虑：一是企业级用户或某些地区的开发者，可能对数据合规、网络稳定性有更高要求，Azure服务能提供更好的保障；二是Azure的计费方式和资源管理可能更符合某些团队的使用习惯。在代码层面，我通过一个统一的接口层来抽象这两种服务，根据配置动态切换，这增加了项目的灵活性。
数据持久化：MySQL 8为什么不用更轻量的SQLite？虽然对于极小型的机器人，SQLite足够。但考虑到这个机器人设计了用户等级、对话上下文管理、频率限制等功能，这些都需要可靠的事务支持和较好的并发性能。MySQL 8提供了更完善的JSON字段支持（便于存储灵活的对话上下文）、窗口函数（用于复杂查询分析）以及更好的性能。使用Docker Compose可以一键部署MySQL，对于生产环境来说，管理和备份也更为成熟。
配置管理：YAML将所有配置集中到config.yaml文件中，而不是硬编码在代码里。这样做的好处显而易见：部署时无需改动代码，安全性更高（避免API密钥泄露在代码仓库），并且能灵活适应不同环境（开发、测试、生产）。YAML格式对人类友好，结构清晰，比JSON更适合写配置。
2.2 核心交互流程设计
机器人的“丝滑”感，很大程度上源于其交互逻辑的设计。我摒弃了传统的“输入命令-等待-输出”模式，而是设计了一个以对话为核心的流式交互模型。
当用户发送一条消息后，后台的流程是这样的：
- 身份与权限校验：机器人首先从数据库查询用户信息，确认其用户等级，并检查在当前时间窗口内是否超过频率限制。这个检查是毫秒级的，用户无感知。
- 上下文构建：机器人会根据用户的等级（配置中的
CONTEXT_COUNT），从数据库中取出最近N轮的历史对话（包括用户消息和AI回复），连同最新的用户消息，一起构建成一个符合OpenAI API格式的对话列表。这是实现“连续对话记忆”的关键。 - 流式请求AI：这里是最核心的“丝滑”体验来源。机器人不会等待AI生成完整回复后再一次性发送给用户。相反，它会向OpenAI API发起一个流式请求。API会像流水一样，逐个token（可以粗略理解为词或字）地返回数据。机器人每收到一个或一小段token，就立即通过Telegram的“编辑消息”功能，更新到对话窗口中。用户看到的就是AI在“边想边打”，响应感极强。
- 结果处理与存储：流式传输完成后，完整的AI回复会和用户的问题一起，作为一条新的对话记录，被存储到数据库的上下文中。同时，用户的对话次数计数器会被更新，用于频率限制。
- 异常处理与反馈：任何环节出错（如网络超时、API额度不足、内容违规），机器人都会通过友好的提示信息告知用户，并将详细的错误日志发送给预设的开发者的Chat ID，便于及时排查。
注意：流式响应虽然体验好，但对网络稳定性要求略高。在代码中，我设置了合理的重试机制和超时时间，并在网络波动时，尝试将已收到的部分内容先发送给用户，而不是让用户面对一个长时间的“正在输入”状态后收到一个失败提示。
2.3 用户系统与资源管理设计
一个健康的、可持续的机器人必须有一套资源管理机制，防止被滥用导致API费用暴涨。我设计了一个轻量但有效的用户等级系统。
在config.yaml中，你可以这样定义：
RATE_LIMIT: 1: 30 # 等级1的用户，每TIME_SPAN分钟只能发起30次对话 2: 100 # 等级2的用户，100次 3: 999 # 等级3的用户，近乎无限制 CONTEXT_COUNT: 1: 5 # 等级1的用户，AI能记住最近5轮对话作为上下文 2: 10 3: 20 MAX_TOKEN: 1: 500 # 等级1的用户，单次AI回复最多生成500个token 2: 1000 3: 2000设计理由：
RATE_LIMIT（频率限制）：这是成本控制的第一道防线。TIME_SPAN定义了统计的时间窗口（比如30分钟），结合等级，可以有效防止单个用户短时间内疯狂调用，耗尽额度。CONTEXT_COUNT（上下文数量）：更多的上下文意味着AI更了解对话历史，回复更精准连贯，但同时也消耗更多的token（费用）。根据用户等级分配，既保证了核心用户的体验，又控制了成本。MAX_TOKEN（最大输出令牌）：直接限制单次回复的长度。对于总结、翻译等任务，500token可能够了；对于创意写作，可能需要更多。分级管理能做到资源按需分配。
新用户默认等级为1。你可以通过数据库直接修改用户等级，或者在未来扩展邀请、积分等系统来实现等级提升。这个设计为机器人的运营提供了极大的灵活性。
3. 核心功能模块深度解析
3.1 流式响应（Streaming）的实现与优化
流式响应是体验的“灵魂”。实现它，需要同时处理好Telegram Bot的异步消息更新和OpenAI API的流式响应。
技术实现细节：
- 发起流式请求：使用
openai.ChatCompletion.create函数，并设置stream=True。此时返回的不是一个完整的响应对象，而是一个生成器（generator）。 - 实时更新消息：在Telegram中，你不能一直发送新消息来拼接回复，那会刷屏。正确做法是：先发送一条初始消息（如“思考中...”），然后使用
message.edit_text()方法来不断更新这条消息的内容。 - 数据拼接与缓冲：API返回的流数据是零碎的。我的策略是设置一个小的缓冲区。每当收到一个新的token（存储在
chunk.choices[0].delta.content中），就将其追加到缓冲区。当缓冲区达到一定长度（比如4个字符）或收到一个完整的句子分隔符（如句号、换行）时，才执行一次edit_text更新。这至关重要：如果每收到一个字符就更新一次，Telegram的API调用频率会过高，容易触发限流，且用户体验上会显得过于“闪烁”。缓冲后，更新变得平滑而有节奏。 - 处理结束与异常：当流式响应完成（收到
[DONE]标记），更新最终消息。如果流过程中发生错误（如网络中断），则捕获异常，将缓冲区中已收到的内容作为部分回复发送给用户，并提示可能不完整。
实操心得：
- 网络超时设置：OpenAI的流式响应可能很慢，尤其是使用
gpt-4模型时。务必为请求设置一个较长的超时时间（如60秒），并使用asyncio.wait_for配合超时处理，避免一个慢响应拖死整个机器人事件循环。 - 编辑频率限制：Telegram Bot API对
editMessageText有频率限制。我的经验是，缓冲区大小设置在3-10个字符，或者根据标点符号判断，是一个比较安全的区间。实测下来，既能保证实时性，又不会触发限流。 - 用户体验细节：在流式响应开始时，可以给消息加上一个“打字中...”的状态（通过
send_chat_action(action=ChatAction.TYPING)），这是Telegram的原生特性，能进一步提示用户AI正在工作。
3.2 预设身份与自定义身份系统
让AI扮演不同角色，能极大提升趣味性和实用性。我内置了15个预设身份，比如“英语老师”、“代码助手”、“创意写手”等。更重要的是，支持用户自定义身份。
实现原理： 每个“身份”，本质上是一个系统提示词（System Prompt）。它被预先注入到每次对话上下文的最开头，用来设定AI的行为、语气和知识范围。
- 预设身份：在代码中，我定义了一个字典，键是身份ID（如
coder），值是一段精心编写的提示词。例如，代码助手的提示词可能是：“你是一个资深的软件开发专家，擅长Python和JavaScript。请用简洁、准确的语言回答技术问题，并提供可运行的代码示例。” - 自定义身份：我在数据库中为每个用户增加了一个字段
custom_prompt。用户通过特定的命令（如/setrole 你是一个幽默的脱口秀演员）来设置自己的专属身份。当这个字段不为空时，它会覆盖预设身份，成为该用户所有对话的系统提示词。 - 快速切换：通过Telegram的
InlineKeyboardButton（内联键盘），我将预设身份做成了按钮菜单。用户点击一个按钮，机器人就会在后台更新该用户的当前会话身份（这是一个临时状态，存储在内存或Redis中更佳，本项目为简化使用数据库字段标记），接下来的对话就会基于新身份进行。切换是即时生效的。
注意：系统提示词会占用token额度。一个复杂的提示词可能消耗上百个token。在计算上下文长度和
MAX_TOKEN时，需要把这部分基础消耗考虑进去。我的做法是在发送请求前，先将系统提示词的token数计算出来，从总配额中预留。
3.3 基于DALL·E 3的图片生成集成
文生图功能是一个亮点。我选择了OpenAI的DALL·E 3模型，因为它生成的图片质量高、对提示词理解能力强。
集成要点：
- 指令分离：在代码中，我通过判断用户消息是否以特定命令（如
/draw或画）开头，来路由到图片生成流程。这需要修改消息处理器的逻辑，将文本对话和图片生成请求分开处理。 - 参数可配置：DALL·E 3 API支持
size（图片尺寸，如1024x1024）、quality（质量，如standard或hd）、style（风格，如vivid或natural）等参数。我在config.yaml中提供了这些参数的默认配置，同时也允许用户通过指令参数覆盖（例如/draw 一只猫 风格:自然）。解析这些自然语言参数需要一些简单的字符串处理逻辑。 - 异步处理与进度反馈：图片生成比文本回复慢得多，可能需要10-20秒。在这期间，必须给用户反馈。我的流程是：收到指令后，先回复“正在创作，请稍候...”，然后在一个异步任务中调用DALL·E 3 API。生成成功后，使用
bot.send_photo方法将图片（从返回的URL下载或直接使用URL）发送给用户。如果失败，则更新先前的文本消息为错误提示。 - 成本与限制：DALL·E 3的调用成本显著高于文本对话，且OpenAI对生成内容有严格的安全策略。在代码中，必须做好异常捕获，对可能违反政策的内容生成请求，要能优雅地返回错误信息，并记录日志。
实操心得：图片生成非常消耗token和额度。强烈建议在用户系统中为图片生成单独设置一个频率限制或积分消耗规则，避免被滥用。例如，可以规定等级1的用户每天只能生成1张图，等级2的用户5张。
4. 从零开始的完整部署与配置指南
4.1 环境准备与依赖安装
假设你有一台运行Linux的服务器（如Ubuntu 22.04）或本地开发机。我们将从最干净的环境开始。
第一步：获取项目代码
# 使用git克隆项目仓库 git clone https://github.com/v-know/chatgpt-telegram-bot.git cd chatgpt-telegram-bot如果网络不畅，也可以直接在GitHub页面下载ZIP包并解压。
第二步：准备Python环境我强烈推荐使用venv创建虚拟环境，避免污染系统Python。
# 检查Python版本，需要3.9+ python3 --version # 创建虚拟环境 python3 -m venv venv # 激活虚拟环境 # 在Linux/macOS上： source venv/bin/activate # 在Windows上： # venv\Scripts\activate # 激活后，命令行提示符前通常会出现 (venv) 字样第三步：安装Python依赖项目根目录下的requirements.txt文件列出了所有必需的库。
# 确保在虚拟环境中，然后安装 pip install -r requirements.txt这个过程会安装核心的python-telegram-bot,openai,PyMySQL,PyYAML等库。如果遇到某个包安装慢，可以考虑临时使用国内镜像源，如pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple。
4.2 数据库配置与初始化
本项目使用MySQL 8作为数据库。使用Docker部署是最快捷的方式。
第一步：使用Docker Compose启动MySQL项目贴心地提供了db/docker-compose.yaml文件。
# 进入db目录，启动服务 cd db docker-compose up -d这个命令会在后台启动一个MySQL 8.0容器，并映射数据卷到本地./data目录，确保数据持久化。同时，它创建了一个名为telegram_bot的数据库，以及对应的用户和密码（这些信息在docker-compose.yaml中定义，通常是root/yourpassword和botuser/botpassword）。
第二步：初始化数据库结构回到项目根目录，使用database.sql文件来创建所有需要的表。
# 假设MySQL root密码是‘yourpassword’（请根据docker-compose.yaml中的设置修改） mysql -uroot -pyourpassword -h 127.0.0.1 telegram_bot < db/database.sql这条命令会创建users（用户表）、conversations（对话记录表）等核心表。你可以用mysql -uroot -p -h 127.0.0.1登录MySQL，执行USE telegram_bot; SHOW TABLES;来验证表是否创建成功。
重要安全提示：在生产环境中，绝对不要使用
-p后面直接跟密码的命令行方式，这会导致密码出现在历史记录中。更安全的方式是使用mysql -uroot -p，然后交互式输入密码，或者使用--defaults-extra-file指定配置文件。这里为了演示简洁才直接写出。
4.3 关键配置文件详解
config.yaml是机器人的大脑，所有行为都由它控制。请复制config.yaml.example并重命名为config.yaml，然后开始编辑。
# config.yaml 核心配置详解 BOT: TOKEN: "YOUR_BOT_TOKEN_HERE" # 【必填】从 @BotFather 那里获取的机器人令牌 DEVELOPER_CHAT_ID: YOUR_PERSONAL_CHAT_ID # 【必填】你的Telegram用户ID，用于接收错误报告 MYSQL: host: "127.0.0.1" # MySQL服务器地址，如果和机器人同机，就是127.0.0.1 port: 3306 user: "botuser" # 数据库用户名，对应docker-compose里的设置 password: "botpassword" # 数据库密码 database: "telegram_bot" # 频率限制配置：每 TIME_SPAN 分钟内，允许各等级用户发起的对话次数 TIME_SPAN: 30 # 时间窗口，单位：分钟 RATE_LIMIT: # 等级: 次数 1: 30 2: 100 3: 999 # 上下文数量：AI能记住的最近对话轮数（包含用户和AI的发言） CONTEXT_COUNT: 1: 5 2: 10 3: 20 # 单次回复最大token数：控制AI回答的长度 MAX_TOKEN: 1: 500 2: 1000 3: 2000 AI: TYPE: "openai" # 可选 "openai" 或 "azure" # 以下为OpenAI配置（当TYPE为openai时生效） OPENAI_API_KEY: "sk-..." # 你的OpenAI API Key MODEL: "gpt-3.5-turbo" # 默认模型，也可用 "gpt-4", "gpt-4-turbo-preview"等 # 以下为Azure OpenAI配置（当TYPE为azure时生效） BASE: "https://YOUR_RESOURCE_NAME.openai.azure.com/" # Azure端点 VERSION: "2024-02-15-preview" # API版本 DEPLOYMENT_NAME: "YOUR_DEPLOYMENT_NAME" # 部署名称 API_KEY: "YOUR_AZURE_API_KEY" # Azure API Key如何获取关键配置？
BOT.TOKEN：在Telegram中搜索@BotFather，发送/newbot指令，按提示操作，最后它会给你一个令牌，格式类似1234567890:ABCdefGHIjklMNOpqrsTUVwxyz。DEVELOPER_CHAT_ID：在Telegram中搜索@get_id_bot，向它发送任意消息，它会回复你的数字ID。AI.OPENAI_API_KEY：登录 OpenAI平台 ，创建新的API Key。- Azure OpenAI配置：如果你使用Azure，需要在Azure门户中创建“Azure OpenAI”资源，然后在“密钥和终结点”页面找到“终结点”（即
BASE）和“密钥”（即API_KEY）。在“Azure OpenAI Studio”中创建部署后，得到“部署名称”（即DEPLOYMENT_NAME）。VERSION可以参考Azure文档使用最新的稳定版API日期。
4.4 启动机器人
配置完成后，启动机器人就很简单了。
方式一：直接使用Python运行（适合开发调试）
# 确保在项目根目录，且虚拟环境已激活 python main.py为了查看运行日志，可以输出到文件：
python main.py 2>&1 | tee debug.log方式二：使用Docker运行（适合生产部署）首先，确保你的config.yaml已经配置好，并且放在当前目录。
# 从GitHub容器仓库拉取镜像并运行 docker run -d \ --name chatgpt-telegram-bot \ --restart unless-stopped \ -v $(pwd)/config.yaml:/app/config.yaml \ ghcr.io/v-know/chatgpt-telegram-bot:latest参数解释：
-d：后台运行。--restart unless-stopped：容器意外退出时自动重启，提高稳定性。-v ...：将本地的config.yaml挂载到容器内的/app/config.yaml，这样修改本地配置后，重启容器即可生效。
方式三：使用Docker Compose（最推荐，管理方便）项目根目录提供了docker-compose.yaml，它会把机器人容器和MySQL容器编排在一起。
# 修改根目录下的 docker-compose.yaml，确保其中的配置路径正确，然后启动 docker-compose up -d启动后，使用docker-compose logs -f可以实时查看日志，确保一切正常。
看到日志输出类似Application started successfully或没有报错持续运行，就说明机器人已经上线了。快去Telegram里找到你的机器人，发送/start开始体验吧！
5. 高级功能与个性化调优
5.1 实现用户使用自有API Key
这是一个非常实用的功能，让高级用户能够接入自己的OpenAI账户，从而不受主账号的频率和额度限制，也增加了机器人的灵活性。
实现思路：
- 数据库扩展：在
users表中添加一个新字段，例如openai_api_key，用于存储用户自行绑定的API Key（务必加密存储！）。 - 命令设计：添加一个命令，如
/bindkey sk-...。用户发送此命令后，机器人需要验证这个Key的有效性。一个简单的验证方法是使用这个Key调用一个极低消耗的API，如models.list。 - 密钥验证与安全存储：
- 验证：在后台异步发起一个测试请求。如果返回成功（HTTP 200），则证明Key有效。
- 存储：绝对不要明文存储。使用强加密算法（如AES-GCM或Fernet）对Key进行加密，然后将密文存入数据库。加密所需的密钥（
ENCRYPTION_KEY）应作为环境变量或配置项，与数据库分离。
- 请求路由逻辑：当处理用户请求时，先检查该用户的
openai_api_key字段是否为空且有效。- 如果用户有自己的Key，则使用该用户的Key和配置（可允许用户自定义模型等）发起AI请求。
- 如果没有，则回退到使用
config.yaml中配置的全局Key。
- 额度监控与提醒：对于使用自有Key的用户，可以提供一个
/myusage命令，通过调用OpenAI的用量接口，反馈当前Key的剩余额度，提升用户体验。
实操心得：
- 安全性是第一位的。加密存储是必须的。可以考虑使用像
cryptography这样的库。 - 验证Key时要做限流和超时，防止恶意用户输入无效Key导致机器人不停发起验证请求。
- 清晰的用户引导：在
/bindkey命令的回复中，详细说明如何获取Key、风险提示（Key如密码，请勿泄露给他人），以及如何解绑。
5.2 错误处理与日志监控优化
一个健壮的机器人必须能妥善处理各种异常，并让开发者能快速定位问题。
错误分类处理：
- OpenAI API错误：如额度不足(
insufficient_quota)、内容过滤(content_filter)、模型过载(model_overloaded)等。这些错误应该被捕获，并转换成对用户友好的提示，如“我的思考额度用完了，请联系管理员充值”或“您的问题触发了安全规则，请尝试换一种问法”。同时，将原始错误信息记录到日志并发送给DEVELOPER_CHAT_ID。 - 网络与超时错误：在请求AI或Telegram API时可能发生。代码中应实现重试机制（例如，最多重试2次，每次间隔递增）。对于流式响应，部分失败时尽可能保存已收到的内容。
- 用户输入错误：如自定义身份提示词过长（超过token限制）、图片生成指令格式错误等。应给出具体、可操作的错误提示，比如“您的角色描述太长了，请精简到100字以内”。
日志策略：
- 结构化日志：不要简单用
print。使用logging模块，配置不同的级别（DEBUG, INFO, WARNING, ERROR）。将日志同时输出到控制台和文件（如app.log）。 - 关键信息记录：每条日志应包含时间戳、日志级别、用户ID、Chat ID、以及具体的错误信息或事件描述。例如：
ERROR - User:123456 - Failed to call OpenAI API: Rate limit exceeded。 - 日志轮转：使用
RotatingFileHandler或TimedRotatingFileHandler防止日志文件无限增大。
开发者警报：通过python-telegram-bot的Application类可以设置一个全局的错误处理器（error_handler）。在这个处理器中，将所有未捕获的异常（Exception）详细信息，通过context.bot.send_message发送到DEVELOPER_CHAT_ID。这样，一旦生产环境出现未预料的崩溃，你能第一时间收到通知。
5.3 性能优化与扩展思路
当用户量增长后，以下几个优化点可以显著提升机器人性能和稳定性。
1. 引入缓存（如Redis）
- 上下文缓存：目前每次对话都从MySQL查询历史记录。对于活跃用户，可以将最近的对话上下文缓存在Redis中，设置一个合理的过期时间（如30分钟），能大幅降低数据库压力。
- 用户信息缓存：用户的等级、频率限制计数等信息也可以缓存，避免频繁查库。
- 实现：可以使用
redis-py库。在查询前先查Redis，没有则查数据库并写入Redis。
2. 数据库连接池使用PyMySQL或aiomysql（异步版本）时，配置连接池而不是每次操作都新建连接。这能有效减少连接建立和销毁的开销，提高并发处理能力。
3. 异步任务队列（用于耗时操作）对于图片生成、复杂的自定义Key验证等耗时较长的操作，可以将其放入异步任务队列（如Celery+Redis或RQ）。机器人主进程只负责接收用户请求并立即返回“任务已接收”的响应，然后由后台Worker执行耗时任务，完成后再通过Telegram API通知用户。这能彻底避免因个别慢请求阻塞整个机器人。
4. 水平扩展如果单台服务器不堪重负，可以考虑水平扩展。
- 无状态设计：确保机器人实例本身是无状态的，所有状态（用户数据、对话上下文）都存储在共享的数据库和Redis中。
- 负载均衡：可以运行多个机器人实例（使用同一个Bot Token），然后通过一个简单的负载均衡器（如Nginx的stream模块，或专门的TCP负载均衡器）将Telegram的Webhook请求分发到不同的实例。注意：Telegram的Webhook模式只允许设置一个URL，所以更常见的多实例方案是使用“长轮询”（Polling）模式，每个实例都独立地向Telegram服务器拉取消息。
python-telegram-bot的Application在Polling模式下可以很好地运行多个实例。
5. 监控与告警除了基本的日志，可以集成像Prometheus和Grafana这样的监控系统。暴露一些指标，如：每分钟消息量、各等级用户活跃度、API调用平均响应时间、错误率等。设置告警规则，当错误率突增或响应时间变慢时，及时通知开发者。
