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

开源ChatGPT前端部署指南：从零搭建私有AI对话界面

news 2026/5/15 9:19:44

1. 项目概述：一个开源社区的“ChatGPT”镜像站

最近在GitHub上闲逛，发现了一个挺有意思的项目，叫“zerobyw/ChatGPT”。乍一看标题，你可能会以为这是OpenAI官方泄露的代码，或者某个大神复刻的模型。但点进去仔细研究后，你会发现它其实是一个基于Web技术栈构建的、功能高度仿真的ChatGPT网页应用前端项目。说白了，这就是一个可以让你自己部署、拥有类似ChatGPT官方网页版交互体验的“镜像站”或“套壳”应用。

这个项目的核心价值在于，它解决了普通用户和开发者与大型语言模型（LLM）交互时的一个常见痛点：界面与功能的自主可控。官方ChatGPT的界面固然优秀，但功能相对固定，且受限于服务条款和访问策略。而“zerobyw/ChatGPT”项目提供了一个开源的、可高度自定义的替代前端。你可以把它部署在自己的服务器上，然后通过配置，让它后端对接任何兼容OpenAI API格式的LLM服务，无论是官方的GPT系列、开源的Llama/Mistral，还是国内的各种大模型平台。这样一来，你就拥有了一个外观和操作逻辑与ChatGPT几乎一致，但数据流向、模型选择完全由自己掌控的对话界面。

它非常适合以下几类人：

个人开发者与技术爱好者：想拥有一个私人的、美观的AI对话前端，用于学习、测试或日常使用。
企业内部团队：需要为内部部署的大模型（如通过API服务调用的私有化模型）提供一个统一、友好且可控的用户界面，避免直接暴露复杂的API调用细节。
有特定定制化需求的用户：比如需要修改UI主题、增加特定功能（如对话导出格式、快捷指令）、或集成到现有工作流中。

这个项目本身不包含任何AI模型，它只是一个“壳”。但这个“壳”做得相当精致和完整，从对话列表管理、Markdown渲染、代码高亮、到流式响应（打字机效果）、对话历史持久化等核心体验都一一复现，甚至在某些细节上还有所增强。接下来，我们就深入拆解这个项目的设计思路、技术实现以及如何将它真正用起来。

1.1 核心需求与设计哲学

为什么我们需要一个开源的ChatGPT前端？直接使用官方网页版或者调用API不就行了吗？这个项目的出现，背后对应着几个明确的、未被官方产品完全满足的需求：

界面与体验的“所有权”：官方产品的界面和功能迭代不由用户控制。开源前端允许用户永久停留在某个喜欢的版本，或者根据自己的喜好调整布局、颜色、交互细节。例如，你可能希望侧边栏更宽，或者为不同的对话类型添加自定义标签，这些在开源项目中都可以通过修改代码实现。
数据隐私与部署自主：对于敏感场景，用户可能希望对话数据完全停留在自己的服务器或内网环境中。部署自己的前端，配合自托管的反向代理或本地模型API，可以实现从界面到数据的全链路控制，满足更高的隐私和安全合规要求。
后端模型的“无感切换”与统一入口：当前LLM生态百花齐放，不同模型、不同服务商的API各有优劣。一个设计良好的开源前端可以配置多个后端API源，用户可以在同一个熟悉的界面里，轻松切换使用GPT-4、Claude或者国产大模型，而无需分别登录不同的网站或记住不同的调用方式。这相当于为你所有的大模型服务提供了一个统一的控制台。
功能扩展与集成：官方界面的功能是通用的。而开源项目允许开发者集成额外功能，比如：
- 知识库/文件上传增强：不仅支持简单的文本输入，还可以集成RAG（检索增强生成）流程，上传PDF、Word文档，让模型基于你的私有资料回答问题。
- 工作流自动化：将常用的提示词（Prompt）封装成可一键调用的“技能”或“机器人”。
- 与第三方工具联动：例如，将对话内容自动同步到Notion、生成思维导图，或者触发自动化脚本。

“zerobyw/ChatGPT”项目的设计哲学，正是围绕上述需求展开的。它力求在视觉和交互上高度还原官方体验，降低用户的学习和迁移成本，同时保持代码结构的清晰和可扩展性，为后续的定制化开发留足空间。它的目标不是做一个功能大杂烩，而是先做一个稳定、美观、复刻度高的“基准版”，让社区可以在此基础上自由生长。

2. 技术栈与架构深度解析

要理解和部署这个项目，首先得摸清它的技术家底。这是一个典型的现代前端项目，技术选型反映了当前Web开发的主流趋势。

2.1 前端技术栈剖析

项目主要采用以下技术构建：

React + TypeScript：这是项目的核心框架。React用于构建用户界面组件，其组件化思想非常适合ChatGPT这种动态交互复杂的应用。TypeScript的引入则极大地提升了代码的健壮性和可维护性，在定义API响应结构、状态类型时尤其有用，能避免很多低级错误。
Tailwind CSS：一个实用优先的CSS框架。它让项目的UI开发速度极快，并且保持了高度的自定义灵活性。你看到的那些与官方ChatGPT神似的间距、颜色、圆角效果，很多都是通过Tailwind的类名实现的。这也意味着如果你要换主题，修改起来会相对集中和方便。
状态管理：对于这类单页应用，状态管理是关键。项目很可能使用了React内置的Context API或更轻量级的状态库（如Zustand、Jotai）来管理全局状态，例如用户配置、当前会话、消息列表等。复杂的状态同步（如WebSocket连接状态、流式响应拼接）是这里的难点之一。
构建工具 Vite：取代了传统的Webpack，Vite提供了极快的冷启动和模块热更新（HMR）体验，让开发过程更加流畅。这对于需要频繁调整UI和逻辑的前端项目来说，是个巨大的效率提升。

注意：技术栈的选择意味着项目的学习成本和定制门槛。如果你是一个有React和TypeScript经验的开发者，那么阅读和修改这个项目的代码会非常顺手。如果你是纯后端或运维人员，可能更需要关注如何配置和部署，而非深度定制。

2.2 核心功能模块拆解

从用户视角看，ChatGPT网页版有几个核心模块，这个开源项目都进行了实现：

会话管理模块：
- 功能：创建、重命名、删除对话会话，会话列表的持久化存储（通常用浏览器的IndexedDB或LocalStorage，服务端部署时可连接数据库）。
- 实现关键：如何高效地组织和管理大量会话的元数据（标题、创建时间、模型类型等），并提供流畅的增删改查体验。
消息交互与渲染模块：
- 功能：用户输入框、消息列表的展示、Markdown格式的渲染、代码块的高亮（通常集成highlight.js或Prism.js）、数学公式渲染（集成KaTeX）。
- 实现关键：流式响应（Server-Sent Events或WebSocket）的接收与实时渲染，实现“打字机”效果。这里需要精细控制数据流的接收、缓存和逐字显示的逻辑，保证即使在网络波动时也能有良好的体验。
API通信模块：
- 功能：封装与后端AI服务（兼容OpenAI API格式）的通信。包括构造请求头（携带API Key）、发送消息数组、处理流式或非流式响应、错误处理等。
- 实现关键：良好的抽象设计。这个模块应该与UI逻辑解耦，方便替换后端服务地址、API版本以及适配不同服务商的细微差异（例如，有些国内服务商可能需要在请求路径或字段名上做调整）。
配置与设置模块：
- 功能：让用户能够设置API端点、API Key、选择模型、调整温度（Temperature）和最大生成长度等参数。
- 实现关键：配置的安全存储与界面友好性。API Key等敏感信息在前端如何处理是一个安全问题，通常不建议硬编码在源码中，而是通过运行时环境变量或部署时的配置注入。

2.3 项目架构设计亮点

这个项目的架构设计上，有几个值得称道的地方，也是很多类似项目忽略的：

清晰的关注点分离：UI组件、业务逻辑（状态管理）、数据通信（API调用）被尽可能地分离。这使得代码更容易测试和维护。例如，你可以单独为API通信模块写单元测试，而不需要启动整个React应用。
对“流式响应”的优雅处理：这是仿ChatGPT体验的核心。项目需要处理来自服务器的数据流，并平滑地更新UI。一个好的实现会考虑如何缓冲数据、如何避免渲染阻塞、如何在中断后恢复，以及如何优雅地显示网络错误。这部分代码是项目技术含量的体现。
可访问性（A11y）考虑：虽然是一个开源项目，但好的前端会考虑到键盘导航、屏幕阅读器支持等可访问性细节。这不仅是道德责任，也能让应用更健壮。
国际化（i18n）准备：代码结构是否支持多语言？文本内容是否被抽取到独立的语言文件中？这对于一个旨在被广泛使用的开源项目来说很重要。

3. 从零开始的完整部署与配置实战

理论说得再多，不如动手部署一遍。下面我将以最常见的部署方式——使用Docker，来演示如何将“zerobyw/ChatGPT”项目变成一个可以访问的在线服务。假设你有一台云服务器（如腾讯云、阿里云的轻量应用服务器），系统为Ubuntu 22.04。

3.1 基础环境准备

首先，确保你的服务器已经安装了必要的软件：

# 更新系统包列表 sudo apt update && sudo apt upgrade -y # 安装 Docker（如果尚未安装） # 以下为官方推荐安装方式，具体请参考Docker官方文档 sudo apt install -y apt-transport-https ca-certificates curl software-properties-common curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io # 安装 Docker Compose（如果项目提供了docker-compose.yml） sudo curl -L "https://github.com/docker/compose/releases/download/v2.23.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose sudo chmod +x /usr/local/bin/docker-compose # 验证安装 docker --version docker-compose --version

3.2 获取与配置项目代码

通常，开源项目会提供几种部署方式。我们假设项目提供了Docker镜像。

# 1. 创建一个工作目录 mkdir -p ~/chatgpt-web && cd ~/chatgpt-web # 2. 克隆项目代码（如果项目提供通过源码构建） # git clone https://github.com/zerobyw/ChatGPT.git . # 但更常见的是，我们直接使用作者构建好的镜像，或者自己构建。 # 3. 创建配置文件。这是最关键的一步！ # 项目一般会有一个环境变量配置文件示例，例如 `.env.example` # 我们需要复制它并修改为自己的配置。 # 假设我们从项目仓库找到配置说明，手动创建 .env 文件 cat > .env << 'EOF' # 前端服务运行的端口 PORT=3000 # 后端API的地址。这是核心配置！ # 例1：指向OpenAI官方API（需科学上网环境） OPENAI_API_BASE_URL=https://api.openai.com/v1 # 例2：指向一个反向代理服务（解决网络问题） # OPENAI_API_BASE_URL=https://your-proxy.com/v1 # 例3：指向本地部署的Ollama（一个本地运行模型的开源工具） # OPENAI_API_BASE_URL=http://host.docker.internal:11434/v1 # 默认使用的模型，如 gpt-3.5-turbo, gpt-4, llama2 等 OPENAI_API_MODEL=gpt-3.5-turbo # API Key。如果使用需要密钥的服务，在此填写。 # 警告：如果部署在公网，务必通过其他更安全的方式管理密钥，而不是硬编码在.env！ # OPENAI_API_KEY=sk-your-api-key-here # 是否开启代码高亮、流式响应等特性 ENABLE_CODE_HIGHLIGHT=true ENABLE_STREAMING=true # 网站标题等自定义信息 SITE_TITLE=我的AI助手 EOF

重要配置解析：

OPENAI_API_BASE_URL：这是项目的灵魂。它决定了你的前端将把请求发送到哪里。你可以填：
- 官方地址（https://api.openai.com/v1）：需要你的服务器能直接访问。
- 第三方代理地址：用于解决网络访问问题。
- 本地模型服务地址：例如使用Ollama在本地运行Llama 3模型，那么地址可能是http://localhost:11434/v1（注意Docker容器内访问宿主机的问题，后面会讲）。
OPENAI_API_KEY：如果使用OpenAI官方或需要认证的代理服务，则需要填写。强烈不建议在公网部署时直接将密钥写在.env文件并提交到代码库。更安全的做法是使用Docker的-e参数运行时注入，或使用云服务提供的密钥管理服务。
OPENAI_API_MODEL：需要和后端服务提供的模型名称对应。如果后端是Ollama，这里就填llama3或qwen:7b等。

3.3 使用Docker Compose一键部署

如果项目提供了docker-compose.yml文件，部署将变得非常简单。我们创建一个：

cat > docker-compose.yml << 'EOF' version: '3.8' services: chatgpt-web: # 使用项目官方镜像，请根据项目README替换为实际镜像名 image: ghcr.io/zerobyw/chatgpt-web:latest container_name: chatgpt-web restart: unless-stopped ports: - "3000:3000" # 将容器内3000端口映射到宿主机3000端口 environment: # 直接通过environment传递环境变量，比.env文件更灵活 - PORT=3000 - OPENAI_API_BASE_URL=${OPENAI_API_BASE_URL:-https://api.openai.com/v1} - OPENAI_API_MODEL=${OPENAI_API_MODEL:-gpt-3.5-turbo} # 密钥建议通过运行时传入，而非写死在compose文件里 - OPENAI_API_KEY=${OPENAI_API_KEY} - SITE_TITLE=${SITE_TITLE:-My ChatGPT} # 如果需要持久化对话历史（如果前端支持且配置了数据库），可以挂载卷 # volumes: # - ./data:/app/data networks: - chatgpt-net networks: chatgpt-net: driver: bridge EOF

然后，启动服务：

# 在包含docker-compose.yml和.env的目录下执行 docker-compose up -d

-d参数表示后台运行。使用docker-compose logs -f chatgpt-web可以查看实时日志，检查是否有错误。

3.4 配置反向代理与HTTPS（可选但推荐）

直接通过IP:3000访问不够优雅且不安全。我们使用Nginx作为反向代理，并配置HTTPS。

安装Nginx：
```
sudo apt install -y nginx
```

配置Nginx站点：创建配置文件/etc/nginx/sites-available/chatgpt：

server { listen 80; server_name your-domain.com; # 替换为你的域名或服务器IP location / { proxy_pass http://localhost:3000; # 指向Docker容器映射的端口 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_cache_bypass $http_upgrade; # 如果应用支持WebSocket，以下两行很重要 proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Port $server_port; } }

启用站点并测试：

sudo ln -s /etc/nginx/sites-available/chatgpt /etc/nginx/sites-enabled/ sudo nginx -t # 测试配置语法 sudo systemctl reload nginx # 重载配置

申请SSL证书（使用Certbot）：
```
sudo apt install -y certbot python3-certbot-nginx sudo certbot --nginx -d your-domain.com
```
按照提示操作，Certbot会自动修改Nginx配置，启用HTTPS并设置自动续期。

完成以上步骤后，你就可以通过https://your-domain.com安全地访问你自己部署的ChatGPT前端了。

4. 高级配置：对接不同后端模型

部署好前端只是第一步，让它“活”起来的关键是配置正确的后端。下面介绍几种常见的后端配置方案。

4.1 方案一：对接OpenAI官方API（或兼容代理）

这是最直接的方案。你只需要一个有效的OpenAI API Key。

.env配置：

OPENAI_API_BASE_URL=https://api.openai.com/v1 OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx OPENAI_API_MODEL=gpt-4-turbo-preview

注意事项：
- 网络问题：你的服务器必须能稳定访问api.openai.com。如果服务器在国内，这通常是个问题。此时，OPENAI_API_BASE_URL可以填一个可靠的、支持OpenAI API协议的第三方代理服务地址。
- 费用与速率限制：直接使用官方API会产生费用，并且有每分钟请求次数（RPM）和每分钟令牌数（TPM）的限制。在个人使用或小规模内部使用时要留意。

4.2 方案二：对接本地模型（以Ollama为例）

Ollama让你能在本地电脑或服务器上运行如Llama 3、Mistral、Qwen等开源大模型，并提供类OpenAI的API接口。

在宿主机上安装并运行Ollama：

# 安装Ollama curl -fsSL https://ollama.com/install.sh | sh # 拉取并运行一个模型，例如Llama 3 8B ollama run llama3

Ollama默认会在11434端口启动一个API服务，API格式兼容OpenAI。

配置前端连接Ollama：这里有个关键点：Docker容器内的应用如何访问宿主机上的服务？
- 方法A：使用特殊主机名。在Docker Compose中，可以将OPENAI_API_BASE_URL设置为http://host.docker.internal:11434/v1。这个host.docker.internal是Docker为容器访问宿主机提供的主机名（在Linux上可能需要额外配置）。
- 方法B：使用宿主机网络模式。在docker-compose.yml中，将服务的网络模式改为host：
```
services: chatgpt-web: image: ... network_mode: "host" # 使用宿主机网络 # 注意：ports映射不再需要，因为直接使用主机端口 environment: - OPENAI_API_BASE_URL=http://localhost:11434/v1 # 现在localhost就是宿主机
```
- 方法C：将Ollama也容器化，并与前端容器放在同一个Docker网络中，通过服务名访问。这是更优雅的Docker化方案。
Ollama的API兼容性：Ollama的/v1/chat/completions端点与OpenAI高度兼容，但并非100%。前端项目可能需要做一些适配，比如调整请求或响应体的某些字段名。通常成熟的开源前端会提供配置项来处理这些差异。

4.3 方案三：对接国内大模型平台

许多国内云服务商（如百度文心、阿里通义、智谱GLM、月之暗面Kimi）也提供了兼容OpenAI API格式的接口。

配置示例（以阿里云灵积为例）：

OPENAI_API_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1 OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx # 阿里云的API Key OPENAI_API_MODEL=qwen-max # 模型名称需根据平台文档填写

关键步骤：
1. 在对应平台申请API Key。
2. 仔细阅读其API文档，确认其“兼容模式”的端点URL、请求头要求（有的平台除了Authorization: Bearer <key>，可能还需要额外的头信息）。
3. 在前端项目的代码中，有时需要根据平台要求微调API请求的构造方式。这可能涉及到修改前端的源代码或寻找项目是否已提供相关配置钩子。

5. 安全加固、优化与故障排查

将应用部署到公网，安全性和稳定性不容忽视。

5.1 安全配置要点

API Key保护：
- 绝不硬编码：不要将API Key写入前端源码或公开的Docker镜像。
- 使用环境变量：通过Docker的-e、.env文件（确保不被提交到Git）或云平台的密钥管理服务来传递。
- 设置额度限制：在OpenAI等平台后台，为使用的API Key设置用量限制和预算告警，防止因漏洞或滥用导致巨额账单。
访问控制：
- 基础认证：在Nginx层面添加HTTP Basic Authentication，为你的服务设置一个用户名和密码。
```
location / { auth_basic "Restricted Area"; auth_basic_user_file /etc/nginx/.htpasswd; # 使用htpasswd命令创建此文件 ... # 其他proxy配置 }
```
- IP白名单：如果仅限内网或特定IP访问，在Nginx或服务器防火墙（如ufw）中设置白名单规则。
- 使用第三方身份验证：对于更复杂的需求，可以考虑集成OAuth2.0（如GitHub登录、Google登录）。
HTTPS强制：确保Nginx配置了SSL并强制将所有HTTP请求重定向到HTTPS。
容器安全：
- 使用非root用户运行容器内的进程（如果Dockerfile支持）。
- 定期更新基础镜像，修复安全漏洞。

5.2 性能与使用优化

前端优化：
- 开启压缩：确保Nginx启用了gzip压缩，减小传输体积。
- 浏览器缓存：为静态资源（JS、CSS、图片）配置合适的缓存头，提升重复访问速度。
对话历史管理：
- 如果项目将历史记录存储在浏览器本地（LocalStorage），需告知用户清理浏览器数据会导致历史丢失。可以考虑开发后端存储功能，将历史存入数据库。
- 对于长期使用，历史数据会增长。前端或后端应提供历史会话的归档或清理机制。
网络优化：
- 如果后端API在海外，前端服务器也在海外，国内用户访问前端可能慢。此时可以考虑：
  - 将前端服务部署在国内服务器，后端仍指向海外API（需解决前端服务器访问API的网络问题）。
  - 使用全球加速的CDN服务来分发前端静态资源。

5.3 常见问题与排查实录

即使按照步骤操作，也可能会遇到问题。这里记录几个我踩过的坑和解决方法：

问题1：前端页面能打开，但发送消息后一直“正在思考”或报错“Network Error”。

排查思路：
1. 检查后端API地址和Key：这是最常见的问题。首先打开浏览器的开发者工具（F12），切换到“网络(Network)”标签页，发送一条消息，查看发出的请求。
2. 查看请求详情：
  - 请求URL：是否正确拼接成了你配置的BASE_URL/chat/completions？
  - 请求头：是否包含了Authorization: Bearer your-api-key？Key是否正确？
  - 响应状态：如果是4xx（如401、403），是认证问题；如果是5xx，是服务器错误；如果是CORS错误，会看到跨域报错。
3. 检查服务器网络：登录到部署前端的服务器，用curl命令测试是否能访问后端API地址。
```
curl -X POST https://api.openai.com/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer YOUR_KEY" \ -d '{"model": "gpt-3.5-turbo", "messages": [{"role": "user", "content": "Hello"}]}'
```
4. 检查Docker容器日志：docker-compose logs -f chatgpt-web，看前端服务本身是否有报错。

问题2：使用Ollama等本地模型时，前端提示“模型不存在”或超时。

排查思路：
1. 确认Ollama服务已启动且模型已加载：在宿主机运行ollama list查看模型，运行curl http://localhost:11434/api/tags测试API是否正常。
2. 解决容器网络连通性问题：
  - 如果使用host.docker.internal，在Linux上默认可能不支持。可以改为使用宿主机在Docker网桥中的IP（通常是172.17.0.1）。在容器内尝试ping 172.17.0.1。
  - 最稳妥的方法是使用network_mode: “host”，或者将Ollama也容器化并与前端容器置于同一自定义网络。
3. 确认API路径和模型名：Ollama的模型名就是拉取时用的名字，如llama3，区分大小写。API路径通常是/v1/chat/completions。

问题3：流式响应不工作，消息是一次性显示出来的。

排查思路：
1. 检查前端配置：环境变量ENABLE_STREAMING是否设置为true。
2. 检查后端支持：确保你使用的后端API支持流式响应（SSE）。OpenAI官方API支持，但有些代理或本地模型可能默认关闭或支持不完整。查看后端服务的文档。
3. 检查网络代理：如果前端和后端之间有任何反向代理（包括Nginx），需要确保代理正确传递了SSE相关的头信息（如Cache-Control: no-cache,Connection: keep-alive,Content-Type: text/event-stream）。参考前面Nginx配置中关于WebSocket和代理的额外头设置。

问题4：部署后，刷新页面对话历史丢失。

原因与解决：默认配置下，历史可能只保存在浏览器内存或LocalStorage中，刷新页面或关闭浏览器标签页即丢失。
- 短期方案：告知用户这是预期行为，或者寻找项目设置中是否有“自动保存到本地存储”的选项并开启。
- 长期方案：如果项目支持，配置一个后端数据库（如SQLite、PostgreSQL）来持久化存储用户会话和消息。这通常需要修改后端代码（如果本项目是纯前端，则需要额外部署一个配套的后端服务）。

通过以上从项目解析、环境搭建、部署实战到问题排查的完整流程，你应该已经能够将“zerobyw/ChatGPT”这个开源项目转化为一个完全受你控制的、功能强大的AI对话前端。它的价值不仅在于复刻了一个界面，更在于提供了一个可编程、可集成、可扩展的AI交互入口。你可以在此基础上，深入前端代码，定制主题、添加插件、集成内部工具，真正让它成为你数字工作流中的一个得力助手。

查看全文

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