1. 项目概述与核心价值最近在折腾AI应用集成发现了一个挺有意思的开源项目Dooy/chatgpt-web-midjourney-proxy。简单来说它就是一个“桥梁”或者说“代理服务器”能把一个标准的ChatGPT Web应用界面和Midjourney这类AI绘画服务给打通。这意味着你可以在一个类似ChatGPT的聊天窗口里直接发送绘画指令然后接收并展示Midjourney生成的图片实现“文生图”和“对话”的融合体验。这个项目的价值点非常明确。对于普通用户它降低了使用Midjourney这类专业绘画AI的门槛。你不用再去记Discord里的各种指令格式也不用在多个应用间来回切换在一个清爽的Web界面里就能完成从构思、对话到出图的全过程。对于开发者它提供了一个清晰的架构范例展示了如何将不同AI服务文本大模型和图像生成模型的API或通信协议进行整合封装成统一的后端服务并适配到前端界面中。无论是想快速搭建一个个人AI助手还是研究多模态AI应用的集成方案这个项目都是一个很好的起点。我自己在部署和深度使用这个项目的过程中踩了不少坑也总结出一些能让它跑得更稳、用起来更顺手的技巧。接下来我就从项目设计思路、核心组件拆解、一步步部署配置、到高级功能调优和问题排查把整个流程和心得详细分享出来。2. 整体架构与设计思路拆解2.1 核心设计理念协议转换与统一入口这个项目的核心设计理念我称之为“协议转换与统一入口”。它要解决的根本矛盾是用户希望在一个统一的、友好的界面ChatGPT Web里操作但背后的服务OpenAI ChatGPT API 和 Midjourney却使用着完全不同的通信协议和交互模式。ChatGPT API遵循标准的HTTP RESTful API或WebSocket协议请求和响应都是结构化的JSON数据内容以文本为主。Midjourney其核心服务运行在Discord平台上用户通过向Discord频道发送特定格式的文本消息如/imagine prompt: a cat来触发任务然后通过监听Discord频道的消息来获取图片生成结果。这是一个基于聊天室消息的、异步的、非标准API的交互过程。chatgpt-web-midjourney-proxy项目正是在这两者之间架起了一座桥。它的架构通常包含以下几个关键部分前端界面 (ChatGPT-Web)提供用户交互的入口。这是一个仿ChatGPT的Web应用用户在这里输入文本。项目需要改造这个前端使其不仅能发送文本对话请求还能识别出绘画意图例如以“/imagine”或“画一个”开头并将这类请求路由到不同的后端处理通道。后端代理服务 (Proxy Server)这是项目的“大脑”。它需要实现两个核心功能路由与协议适配接收来自前端的请求判断是普通对话还是绘画指令。如果是对话则按照OpenAI API的格式转发请求并返回结果。如果是绘画指令则需要将其转换成Midjourney能理解的格式通常是模拟Discord消息并通过某种方式如调用一个专门的Midjourney客户端库发送给Midjourney服务。异步任务与状态管理绘画生成是耗时的通常几十秒。代理服务需要管理这些异步任务创建任务ID、轮询或等待Midjourney的生成结果、将结果图片URL或Base64编码返回给前端并可能提供生成进度查询。Midjourney连接器 (MJ Client/Worker)这是与Discord/Midjourney服务直接通信的组件。它可能是一个无头浏览器puppeteer、一个Discord API客户端或者一个封装了相关SDK的独立服务。它的职责是登录Discord账号、加入指定频道、发送消息、监听消息并将图片结果抓取回来。注意由于Midjourney并未提供官方API所有第三方集成方案本质上都是通过自动化工具模拟用户操作存在违反Discord服务条款或账号被封禁的风险。本项目及类似方案通常仅供学习、研究或个人使用不建议用于生产或商业环境。2.2 技术栈选型考量从项目代码通常为Node.js Vue来看技术选型是经过权衡的后端 (Node.js)非常适合做代理和IO密集型应用。其事件驱动、非阻塞I/O模型能很好地处理大量并发连接和异步任务如等待MJ生成。丰富的npm生态也提供了各种Discord客户端、HTTP代理中间件等工具。前端 (Vue.js)轻量、灵活构建类似ChatGPT的交互式单页应用SPA体验良好。易于实现消息流式接收、图片预览、历史记录管理等复杂交互。通信方式除了常规的HTTP请求为了实时接收绘画生成进度和结果很可能会用到WebSocket或Server-Sent Events (SSE)。这样前端可以保持长连接后端在任务状态更新时主动推送消息用户体验更流畅。这种选型保证了项目的开发效率和运行性能同时也对部署环境需要Node.js运行环境提出了明确要求。3. 核心组件与配置深度解析3.1 环境准备与关键依赖部署前需要准备好以下几个核心环境与账号服务器/运行环境一台可以运行Node.js的服务器或本地电脑。推荐使用Linux服务器如Ubuntu 20.04资源建议1核2G以上因为可能需要运行无头浏览器。OpenAI API Key用于处理文本对话部分。需要在OpenAI平台申请。Discord账号与服务器一个专用的Discord账号不建议使用主账号。创建一个自己的Discord服务器Server。在Discord开发者门户创建一个应用Application并获取其Bot Token。将你的Bot邀请到自己的服务器并授予它“读取消息”、“发送消息”、“附加文件”等权限。在Midjourney的官方服务器或个人服务器中通过/subscribe命令让Midjourney Bot也加入你的服务器。最终你的Bot和Midjourney Bot需要在同一个频道的可见范围内。Midjourney订阅一个有效的Midjourney订阅计划以确保绘画功能可用。3.2 配置文件详解连接一切的枢纽项目的核心配置通常集中在一个.env文件或config.js中。理解每个配置项至关重要。# 服务端配置 SERVER_PORT3002 # 代理服务监听的端口 API_PREFIX/api # API路由前缀 # OpenAI 配置 OPENAI_API_KEYsk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx # 你的OpenAI API Key OPENAI_API_BASE_URLhttps://api.openai.com/v1 # 可改为代理地址如果必要 OPENAI_MODELgpt-3.5-turbo # 默认使用的对话模型 # Midjourney 配置核心难点 DISCORD_BOT_TOKENMTEwxxxxxxxxxxxxxxxxxxxxxxxx # 你的Discord Bot Token DISCORD_SERVER_ID110xxxxxxxxxxxxxxxxxxx # 你的Discord 服务器ID DISCORD_CHANNEL_ID110xxxxxxxxxxxxxxxxxxx # 你指定的频道ID用于发送和接收MJ消息 MIDJOURNEY_BOT_NAMEMidjourney Bot # MJ Bot在频道中显示的名字用于过滤消息 MIDJOURNEY_CDN_PROXY # 可选用于代理下载MJ生成的图片解决国内访问慢的问题 # 任务与队列配置 TASK_QUEUE_MAX10 # 同时处理的最大绘画任务数防止拥堵 TASK_TIMEOUT300000 # 单个绘画任务超时时间毫秒如5分钟配置心得DISCORD_CHANNEL_ID最好找一个新建的、只有你的Bot和MJ Bot的文本频道避免被其他人的消息干扰。MIDJOURNEY_BOT_NAME可能因地区设置不同而变如中文环境下可能是“Midjourney Bot”务必去频道里确认一下MJ Bot实际显示的用户名。TASK_QUEUE_MAX不要设置太大尤其是账号订阅等级不高时Midjourney有并发限制队列过长会导致任务失败或等待时间极长。3.3 Midjourney 客户端连接机制剖析这是项目中最复杂、最容易出问题的部分。常见的连接方式有Discord.js 用户账号不推荐直接用Discord.js库以用户账号登录。这种方式极容易被Discord风控导致账号被封。Discord.js Bot账号推荐使用我们申请的Bot Token登录。Bot是Discord官方允许的自动化形式相对安全。但Bot的权限需要仔细配置并且它不能直接“使用”Midjourney的服务它只能“观察”和“转发”。你需要让Midjourney Bot也在这个频道里然后你的Bot监听频道消息当看到Midjourney Bot发出的消息包含图片时就认为是任务完成了。无头浏览器方案使用Puppeteer或Playwright控制一个浏览器自动登录Discord Web端并操作。这种方式模拟真人但非常笨重、耗资源且Cookie容易失效维护成本高。本项目通常采用第2种方案Bot方案。其工作流程如下你的Bot我们称之为Proxy-Bot登录并监听指定频道。用户在前端发送/imagine a beautiful sunset。后端服务让Proxy-Bot在频道里发送完全相同的消息/imagine a beautiful sunset。Midjourney Bot以下简称MJ-Bot看到指令开始工作并先回复一条“Waiting to start...”之类的消息。Proxy-Bot持续监听频道当它检测到一条来自MJ-Bot、并且内容包含图片附件或UpScale等按钮的新消息时就抓取这张图片的URL回传给后端服务再推送给前端用户。实操难点与技巧消息过滤代码中必须精确过滤消息。不仅要看作者是MJ-Bot还要结合消息内容是否包含“**”提示词内容、消息类型、是否有附件等综合判断避免抓错图。任务ID映射如何确定频道里新出现的图片对应的是哪个用户的哪个任务一种常见做法是在发送的提示词中加入一个唯一的UUID例如/imagine a beautiful sunset --task-id abc123。然后监听消息时通过解析提示词内容来匹配任务ID。注意Midjourney Bot可能会修改或省略部分参数需要测试确认。按钮交互Upscale, Vary如果要支持图片的“放大”、“变体”等高级操作你的Proxy-Bot还需要能模拟点击MJ消息附带的按钮。这需要Discord.js收集按钮的custom_id并发送相应的交互请求。实现起来更复杂但能极大提升用户体验。4. 完整部署与实操流程假设我们在一台全新的Ubuntu 22.04服务器上部署。4.1 基础环境搭建# 1. 更新系统并安装基础工具 sudo apt update sudo apt upgrade -y sudo apt install -y curl wget git vim # 2. 安装 Node.js 和 npm (使用 NodeSource 安装较新版本) curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash - sudo apt install -y nodejs node -v # 检查版本应为 v18.x npm -v # 3. 安装 PM2 进程管理工具用于守护进程 sudo npm install -g pm2 # 4. 克隆项目代码 git clone https://github.com/Dooy/chatgpt-web-midjourney-proxy.git cd chatgpt-web-midjourney-proxy # 5. 安装项目依赖分别进入前端和后端目录 cd server npm install cd ../web npm install4.2 后端服务配置与启动# 进入后端目录 cd server # 复制环境变量示例文件并编辑 cp .env.example .env vim .env # 或使用其他编辑器 # 在 .env 文件中填入前面章节准备好的配置 # OPENAI_API_KEY, DISCORD_BOT_TOKEN, DISCORD_SERVER_ID, DISCORD_CHANNEL_ID 等 # 使用 PM2 启动后端服务并设置日志和进程名 pm2 start npm --name mj-proxy-server -- run start # 或者如果 package.json 中 script 是 server # pm2 start npm --name mj-proxy-server -- run server # 设置开机自启 pm2 save pm2 startup # 查看日志检查是否启动成功有无报错特别是Discord登录错误 pm2 logs mj-proxy-server关键检查点查看日志确认Logged in as [你的Bot名字]!表示Discord Bot登录成功。检查是否有权限错误如无法读取频道需要回到Discord开发者门户检查Bot的权限设置。可以临时在代码中增加日志输出监听到的频道消息验证Bot是否在正常工作。4.3 前端应用构建与部署# 进入前端目录 cd web # 编辑前端配置通常需要指定后端API的地址 # 文件可能是 .env.production 或 vite.config.js 等具体看项目结构 # 例如修改 VITE_APP_API_BASE_URL 为你的后端服务地址http://你的服务器IP:3002/api # 构建生产环境静态文件 npm run build # 构建完成后会生成一个 dist 目录。你需要将这些文件部署到Web服务器。 # 这里以使用 Nginx 为例 # 安装 Nginx sudo apt install -y nginx # 创建Nginx站点配置 sudo vim /etc/nginx/sites-available/mj-proxy # 配置文件内容示例server { listen 80; server_name your-domain.com; # 或你的服务器IPlocation / { root /path/to/chatgpt-web-midjourney-proxy/web/dist; # 前端dist目录的绝对路径 index index.html; try_files $uri $uri/ /index.html; # 支持Vue Router的history模式 } # 可选将API请求代理到后端Node服务 location /api/ { proxy_pass http://localhost:3002; # 后端服务地址和端口 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }}# 保存并退出 # 启用站点配置 sudo ln -s /etc/nginx/sites-available/mj-proxy /etc/nginx/sites-enabled/ # 测试Nginx配置并重载 sudo nginx -t sudo systemctl reload nginx现在你应该可以通过浏览器访问你的服务器IP或域名看到ChatGPT风格的界面了。5. 高级功能与优化实践5.1 实现流式输出与实时进度基础的实现是等图片完全生成后再一次性返回。更优的体验是模拟Midjourney在Discord里的生成过程先返回“已接收任务”然后推送“正在生成…”最后推送图片。这需要后端和前端配合后端在接收到绘画请求后立即通过WebSocket或SSE向前端返回一个task_id和初始状态如“pending”。然后在Discord监听逻辑中当捕获到MJ Bot的“Waiting to start”、“Processing...”等状态消息时就通过task_id找到对应的WebSocket连接推送状态更新。最后当图片生成完毕推送最终结果。前端需要建立WebSocket连接或监听SSE流。根据收到的不同状态类型更新聊天界面中的对应消息块。例如在用户发送的提示词下方动态显示一个“绘画中…”的指示器并可能更新进度百分比。5.2 图片存储与CDN加速默认情况下前端直接显示从Discord CDN获取的图片URL。但这有几个问题1Discord链接可能有时效性2国内访问可能很慢3无法做图片管理。优化方案后端代理下载在后端服务中当抓到图片URL后立即用axios或node-fetch将其下载到服务器的内存或临时文件中。转存与链接替换方案A本地/服务器存储将图片保存到服务器磁盘如uploads/目录并提供一个新的静态文件服务地址如/files/xxx.jpg。然后把这个新地址返回给前端。你需要管理这些文件防止磁盘被撑满。方案B对象存储将图片上传至云服务商的对象存储如AWS S3、阿里云OSS、腾讯云COS。这是生产环境推荐的做法扩展性好自带CDN。后端需要集成相应的SDK。方案C图床上传到SM.MS、Imgur等公共图床。简单但稳定性依赖第三方。配置CDN如果使用方案B可以利用云服务商提供的CDN加速图片访问。如果使用方案A也可以在前面套一层Nginx并配置缓存规则。示例代码片段后端下载并上传到OSS// 伪代码需安装 ali-oss SDK const OSS require(ali-oss); const client new OSS({ /* 你的配置 */ }); async function processAndUploadImage(discordImageUrl, taskId) { // 1. 从Discord下载图片 const response await axios.get(discordImageUrl, { responseType: arraybuffer }); const imageBuffer Buffer.from(response.data); // 2. 生成唯一文件名 const filename mj_${taskId}_${Date.now()}.png; // 3. 上传到OSS const result await client.put(filename, imageBuffer); // 4. 返回新的可公开访问的URL return result.url; }然后在返回给前端的数据中使用这个新的OSS URL。5.3 权限控制与多用户支持开源版本通常为单用户设计。如果你想分享给朋友或小团队使用需要增加基础权限。API密钥认证为每个用户生成一个唯一的API Key。前端在请求头中携带Authorization: Bearer user_api_key。后端验证该Key的有效性并可以关联用户身份进行次数限制、记录日志等。会话管理实现简单的登录注册或对接第三方登录使用JWTJSON Web Token管理用户会话。数据隔离将任务队列、历史记录按用户ID进行隔离确保用户只能看到和操作自己的内容。速率限制使用express-rate-limit等中间件对API接口进行限流防止滥用。6. 常见问题排查与实战技巧6.1 部署与连接问题排查表问题现象可能原因排查步骤与解决方案前端无法访问Nginx配置错误端口未开放1.sudo systemctl status nginx检查Nginx状态。2.curl http://localhost测试本地。3. 检查服务器安全组/防火墙是否开放80/443端口。前端能打开但发送消息报错“连接失败”前端配置的后端API地址错误或后端服务未启动1. 检查前端构建时配置的VITE_APP_API_BASE_URL。2.pm2 list查看后端进程是否运行。3.curl http://localhost:3002/api/health(假设有健康检查接口) 测试后端API。Discord Bot 登录失败Bot Token错误、权限不足、服务器ID/频道ID错误1. 核对.env中的DISCORD_BOT_TOKEN、DISCORD_SERVER_ID、DISCORD_CHANNEL_ID。2. 去Discord开发者门户重置Token并重新复制。3. 确保Bot已被邀请到服务器并拥有所需权限尤其是“读取消息历史”、“发送消息”、“嵌入链接”、“附加文件”。4.开启Discord开发者模式在Discord界面中右键点击服务器和频道可以复制ID。Bot已登录但收不到Midjourney消息Bot和MJ Bot不在同一频道频道权限问题消息监听逻辑有bug1. 确认你使用的DISCORD_CHANNEL_ID频道里既有你的Bot也有Midjourney Bot。2. 手动在频道里用账号发条消息看Bot日志能否打印出来。如果能说明监听正常。3. 手动用账号发送/imagine a cat观察MJ Bot是否响应。如果不响应说明MJ Bot没在这个频道或者你的Discord账号没有MJ订阅。4. 检查代码中过滤MJ消息的逻辑如MIDJOURNEY_BOT_NAME是否准确。能发送绘画指令但永远收不到图片任务ID匹配失败图片生成超时MJ任务失败未处理1. 查看后端日志确认Bot是否监听到了MJ Bot发出的带图片的消息。2. 检查任务匹配逻辑。在发送的提示词中加入一个明显标识如--debug-123然后在监听代码里打印所有MJ消息的内容看是否能找到这个标识。3. 增加任务超时TASK_TIMEOUT的日志看是否因为网络慢导致超时。4. Midjourney服务本身可能不稳定手动在Discord测试。图片加载非常慢或失败Discord CDN被墙或网络不佳图片链接过期1. 在服务器上curl一下图片URL看能否下载。2. 实施5.2 节的图片存储与CDN加速方案将图片抓取并存储到本地或国内可访问的对象存储。6.2 稳定性与维护心得日志是关键给代码的关键步骤登录成功、收到消息、发送消息、任务开始/结束都加上详细的日志。使用winston或pino等日志库按日期和级别分割文件方便日后排查。进程守护一定要用PM2。它能在进程崩溃后自动重启还能管理日志。定期检查pm2 logs和pm2 monit。处理Midjourney的变化Midjourney的Bot消息格式、按钮样式可能会更新。你的解析逻辑可能需要随之调整。关注项目GitHub的Issue和更新或者自己定期手动测试一下核心功能。资源监控如果使用无头浏览器方案内存和CPU占用会很高。即使是纯Bot方案在并发任务多时也要注意。设置合理的队列长度TASK_QUEUE_MAX并在服务器上配置监控告警。备用方案不要完全依赖一个Discord账号和一个频道。可以准备多个Bot Token和多个频道在代码中实现简单的故障切换提高系统的可用性。6.3 安全注意事项环境变量保密.env文件包含所有敏感信息绝对不能提交到Git。确保.gitignore文件包含了它。在生产服务器上也要妥善保管这个文件。API调用限额OpenAI API是有费用的。在前端或后端对用户进行调用次数和频率的限制避免因恶意刷接口或程序bug导致巨额账单。输入过滤对用户从前端输入的提示词进行基本的过滤防止注入攻击或滥用。虽然MJ Bot本身可能也有过滤但多一层防护总是好的。网络隔离如果部署在公网确保只有必要的端口如80, 443, 后端服务端口对外开放。数据库等服务不要暴露在公网。部署并成功运行这样一个项目带来的成就感不仅仅是技术上的。你获得了一个高度定制化的、集对话与绘画于一体的个人AI工作台。你可以根据自己的喜好修改前端UI可以增加更多的AI服务如语音合成、文生视频等甚至可以基于这个代理架构开发出更复杂的AI工作流自动化工具。整个过程中最深的体会是在AI应用层“集成”和“用户体验设计”的价值有时候并不亚于模型本身。把一个复杂的技术流程封装成简单直观的交互这本身就是一种创造。