如果你在团队里负责给内容平台加一个自动配图功能，大概率会经历这样一轮搜索：打开 Midjourney 官网找 API 文档，找不到；搜“Midjourney API”，蹦出来的全是第三方中转站，价格从几美元到几百美元不等，参数五花八门，也没人敢保证稳定性。这篇文章想解决的就是这个问题。我会先讲清楚为什么 Midjourney 没有官方开放的 API，再介绍一种可控、低成本的接入方式——通过 Discord 交互机制的封装，把 Midjourney 的图像生成能力包装成一个可供内部业务调用的 HTTP 服务，并给出每一步的代码骨架、参数映射和真实运行中会遇到的坑。这篇指南面向的不是想“一键接入”的产品经理，而是需要自己动手把能力落地到业务里的开发同学。你需要懂一些 HTTP、JSON、基本的消息队列概念，不一定需要多深，只要跟着走完一遍，就能搭出一个能用的 Midjourney 图像生成 API 封装服务。1. 先搞清楚市面上说的“Midjourney API”到底是什么1.1 官方形态：Midjourney 从诞生起就不是一个标准 Web 服务Midjourney 的产品形态非常特殊，它没有像 OpenAI 那样提供api.openai.com这种标准 REST 端点，也没有发布过正式的 API Key 体系。它主要跑在 Discord 里，靠用户往聊天窗口敲/imagine这样的斜杠命令来触发生成任务，然后 Midjourney 机器人会把进度消息和最终图片发回频道。所以你在很多教程里看到的“Midjourney API 调用”，本质上都不是官方提供的接口，而是别人把 Discord 上的人工操作自动化了。这个区分必须在一开始就建立，否则后面代码写再多也容易踩到不该踩的坑。1.2 三种常见的“API”方案，以及我为什么选了自建封装市面上号称“Midjourney API”的服务，我大概归成三类：方案类型实现原理稳定性成本风险官方 Discord 交互自动化用账号凭证模拟用户在 Discord 发送命令，再监听频道消息拿结果取决于账号状态和网络环境只需要 Midjourney 订阅费高频操作可能触发风控第三方中转 / 代理服务别人封装好了 Discord 交互，你直接调他暴露的 HTTP 接口看平台运营情况，经常有跑路或限流按张计费，通常比订阅费贵很多图片和 Prompt 都会经过第三方，数据有泄露风险官方未来可能逐步开放的 API 计划官方尚未大规模对外开放，目前没有面向个人开发者的自助接入未定未定未定我最终选择的是第一类，自建一个封装层。原因很直接：团队内部工具链需要的数据安全和可定制性，第三方中转提供不了。把 Prompt 发给陌生人平台这件事，在涉及品牌素材或用户数据时应尽量避免；另外按张付费的模式跑一个月，价格往往比一个 Midjourney 订阅账号高出好几倍。1.3 选型之前先认清的几个现实约束自建方案虽然可行，但有几个约束必须提前接受：第一，Discord 的接口设计和鉴权机制不是为开放 API 准备的，它没有“批量生成图片”这种接口，你只能在消息交互协议上做文章。第二，Midjourney 的生成耗时波动大，短则几十秒，长则几分钟，这决定了你不可能像调普通 HTTP API 那样阻塞等待。第三，自动化操作 Discord 这件事，严格来说是处于灰色地带的，账号有被限制使用的风险，所以你的设计必须从源头控制频率，不能把它当成无限并发的免费算力。把这些约束想清楚之后，再去看市面上动不动就吹“毫秒级响应”的所谓 API，你就明白那种东西为什么不可信了。2. 开工之前需要备齐的环境、账号与基础设施2.1 账号、频道与 Bot 权限要自建封装服务，你需要准备的东西不多，但每一样都很关键：一个可用的 Midjourney 订阅账号，这个账号必须绑定了 Discord 登录，且能正常使用/imagine命令。一个单独的 Discord 服务器，建议不要在你同事都在的大频道里做自动化测试，否则机器人的反馈消息会刷屏干扰别人。自己创建一个只有机器人和你个人账号的私有服务器，一切操作都在里面完成。一个 Midjourney 机器人账号可以被调用的环境。Discord 的机器人权限配置，简单来说就是保证消息能发出去、能读到 Midjourney 机器人的回复。实际操作中，最忌讳的是拿同事的账号去跑测试。我一开始就吃过这个亏。用别人的账号跑自动化，一旦触发风控，被限制的还不是你自己一个人的账号。2.2 调用凭证的获取与风险边界这一步是整个自建封装里最敏感、也最容易被教程含糊带过的地方。Discord 的自动化交互通常需要拿到登录凭证，常见的有两类思路：一是使用个人账号的用户令牌（User Token），二是使用应用机器人令牌（Bot Token）并申请对应的消息权限。用户令牌的获取方式在浏览器开发者工具里就能找到，但这东西相当于账号的钥匙。写进代码里、提交到 Git 仓库、放在明文配置文件里，都是极度危险的做法。我的习惯是放进环境变量或者专门的密钥管理服务里，并且只给极少数运维人员知道。另外需要坦诚地说一句：用 User Token 做自动化，是和 Discord 官方的服务条款相冲突的。这意味着账号存在被限制的风险。所以我在实际生产项目里给出的建议是：这个方案更适合内部工具、低频率调用，不要拿它去做商业模式上完全依赖的对外服务。如果你真的要做面向大量用户的商业产品，应该去联系官方或选择有明确授权的服务商，而不是自己赌账号寿命。2.3 服务器到 Discord 服务的连通性验证这一步很多人会忽略，但它往往决定了后面调试的顺利程度。Midjourney 的交互需要你的程序服务器能直接访问 Discord 的网关和 CDN 服务。部署在国内云服务器上时，经常遇到延迟高或者连接不稳定的问题。我踩过的坑是：本地开发环境一切正常，代码部署到某云厂商的轻量服务器后，任务发出去就石沉大海。查了半天发现是服务器与 Discord 服务之间的网络连接存在超时。所以在选型初期就应该确认好：你的服务器是否具备出网能力，到 Discord 相关域名的连通性是否稳定，延迟是否能接受。验证方法很简单，找一个能稳定运行的网络工具，从服务器上 ping 一下或直接尝试建立 WebSocket 连接。如果条件不满足，可能要使用海外节点部署这套服务，或者考虑从网络策略层面做调整。这里不展开讲具体工具，只要记住一句话：连通性这件事，必须在写代码之前验证，而不是写完代码之后才排查。2.4 为任务队列设计预留的数据库结构Midjourney 生成一张图可能要一两分钟，在这个时间里你的程序不能干等，否则并发一上来就卡死。所以从第一天开始就要按“异步任务”的方式设计数据表。我常用的表结构非常简单，就一张mj_task表，字段大致如下：字段名类型说明idvarchar业务方生成的唯一任务 IDprompttext原始 Prompt 文本statusvarcharpending / sending / processing / success / failedmessage_idvarcharDiscord 消息 ID，用于定位结果image_urltext最终图片 URLerror_reasontext失败原因created_atdatetime创建时间finished_atdatetime完成时间这张表就是整个封装服务的主心骨。后面要做重试、做回调、做统计，全部围绕它来展开。3. 核心调用链路：从发送 Prompt 到拿回成图 URL3.1 一次完整生成在 Midjourney 侧发生了什么当你手动在 Discord 输入/imagine a red fox in the snow并回车时，背后其实发生了这样一串事件：你的客户端向 Discord 发送一条交互指令（Interaction），目标对象是 Midjourney 机器人。Midjourney 机器人收到后，会在频道里发一条消息，内容是“正在处理，请稍候”，通常以斜体文本出现，例如*a red fox in the snow*。过了一会儿，它会把这条消息更新为图片网格（Grid），也就是四张图拼在一起，下面带两排按钮：U1-U4 是放大某一张，V1-V4 是基于某一张做变体。当你点击 U1 或 V1 之后，机器人再次把消息更新，最终输出单张高清图。所以整个自动化流程就是：替用户完成“发命令”这一步，然后监听 Midjourney 机器人发的消息，通过消息内容和附件的出现情况判断当前阶段，最终把高清图片的 URL 提取出来。3.2 发送交互命令的代码骨架我尝试过两种实现路线，一种是直接基于 Discord 的 WebSocket 网关来交互，另一种是利用第三方机器人库，本质也是帮你连接网关。两者原理一致，区别只在于封装程度。直接构造 HTTP 请求发送交互命令的骨架，可以用 Python 写得很短。这里演示核心逻辑，不代表完整可运行的生产代码：import requests def send_imagine_command(channel_id, prompt, auth_token): url = "https://discord.com/api/v9/interactions" payload = { "type": 2, "application_id": "你的Midjourney应用ID", "guild_id": "你的服务器ID", "channel_id": channel_id, "session_id": "随机生成的会话ID", "data": { "version": "接口协议版本号", "id": "斜杠命令的ID", "name": "imagine", "type": 1, "options": [ { "type": 3, "name": "prompt", "value": prompt } ], "application_command": { "id": "斜杠命令的ID", "name": "imagine", "type": 1 } } } headers = { "Authorization": auth_token, "Content-Type": "application/json" } response = requests.post(url, json=payload, headers=headers) return response.status_code这段代码里的session_id和application_id都要从实际环境中抓取。很多教程喜欢把这些参数全部写死，导致你换一个频道就报错。另一个更稳定的做法是使用成熟的 Discord 开发库，让库帮你处理网关连接、心跳维护和消息接收。生产环境建议用这个方向，因为你不可能永远通过手动抓包来维护协议字段。我自己实际生产代码里，就是基于discord.py自建了一个后台任务管理模块，专门负责发送交互指令和监听事件，比起手写 HTTP 骨架省心太多。3.3 常用参数如何映射到 Midjourney 命令参数Midjourney 的 Prompt 参数不是 JSON 字段，而是追加在文本末尾的--风格参数。这一步的映射是封装 API 时最容易被忽略的环节。很多人在自己的 HTTP 接口里设计了一个aspect_ratio字段，但忘了在拼 Prompt 时加上--ar 16:9，结果生成出来永远是默认的 1:1。我常用的参数映射表如下：自己的 API 参数Midjourney 命令参数示例prompt无a red foxaspect_ratio--ar--ar 16:9stylize--s--s 750chaos--c--c 50seed--seed--seed 12345tile--tile--tilequality--q--q 0.25no--no--no text, watermark拼接的时候注意，如果参数值本身包含空格，需要用引号包裹，例如--ar 16:9没问题，但某个自定义参数的值里有空格时就得小心处理。我遇到过最诡异的 Bug 是：Prompt 里包含换行符，直接拼进/imagine命令后，Discord 把换行后的内容当成新消息发送，导致命令残缺。正确做法是在拼接前把所有控制字符清理掉。3.4 如何在消息流里可靠判断“生成完成”整个自动化里最核心的难点就是判断“任务做到哪一步了”。Midjourney 机器人发送的消息内容是逐步变化的，阶段特征非常明显：初始消息：纯文本，通常是一个斜体的 Prompt 副本。网格图阶段：消息里出现一个图片附件，且有 4 张图拼在一起，下方出现 U/V 按钮组件。放大图阶段：点击 U 或 V 之后，消息被编辑升级为单张高清图。最终完成：附件 URL 稳定不再变化，按钮可能消失或变为重roll按钮。我的判断逻辑很简单：在消息更新事件里，如果识别到附件里的图片 URL 存在，且 URL 对应的文件名包含网格标识，说明这是中间阶段；如果附件是单独一张大图，说明任务已完成。这种方式不需要解析按钮的状态，比较稳定。演示一下简单的消息监听逻辑（伪代码）：async def on_message_update(before, after): if after.author.name != "Midjourney Bot": return attachments = after.attachments if len(attachments) == 0: # 只有文字，说明还在生成中 update_task_status(message_id, "processing") return image_url = attachments[0].url # 这里可以根据 URL 中是否包含 grid 关键词判断阶段 if "grid" in image_url: update_task_status(message_id, "grid_ready") else: # 单张高清图，认为完成 update_task_status_and_notify(message_id, "success", image_url)3.5 图片 URL 的提取、时效与转存Discord CDN 上的图片 URL 不是永久的。默认情况下，通过 CDN 拿到的链接可以参考带签名的时效参数，过期后访问会 403。这意味着你在业务里如果直接丢一个 Discord 链接给前端页面展示，过几个小时就挂了。所以我在封装服务的最后一步，一定会把最终图片下载下来，转存到自己的对象存储服务里，然后用自己存储的 URL 作为输出。这个步骤看起来多了一次下载和上传，但对生产系统来说是必须的。有一次我偷懒没做转存，测试时一切正常，第二天运营同学反馈说海报里的图片全部裂了，查了半天才发现是 Discord CDN 链接过期。4. 把服务跑稳定必须处理的真实问题4.1 任务排队与并发上限：为什么不能无脑加线程Midjourney 的账号是有并发限制的。免费用户和付费用户在排队机制上有差异，付费模式下，同时提交的任务过多，后面的任务会进入等待队列，甚至有的任务会被系统判定为异常而不予执行。我一开始犯过的错是：用线程池一口气发了 20 个任务，结果前几个成功，后面的全部失败或者长时间无响应。后来我重新设计了调度器，用一个单线程的队列调度器，每次只往 Discord 发送一个任务，等它完成或超时之后再发下一个。这样虽然吞吐量低了，但稳定性大幅上升。如果需要提高吞吐量，正确的做法是准备多个 Midjourney 账号，在调度器里做账号轮询，而不是在一个账号上无限叠加并发。每个账号维护自己的并发计数和限流状态。4.2 常见错误响应与对应的处理策略跑一段时间后，难免会遇到各种异常响应。我整理了几个高频错误和大家分享：现象可能原因处理方式消息发出后无任何回复网络问题或命令格式错误查询原始 Prompt 和拼接参数，主动重发一次消息有回复，但一直卡在斜体文本状态Midjourney 队列拥堵或账号被限增加超时时间，超时后标记为失败返回Invalid ParameterPrompt 里包含非法参数滤除非法参数，注意--no值的引号问题返回Blocked内容被安全策略拦截记录失败原因，不要尝试用变体词绕过Blocked这个问题我遇到了不止一次。Midjourney 对内容安全有比较明确的策略，某些 Prompt 被判定违规后，会直接拒绝生成，甚至触发临时限制。不要试图用拼写变体或谐音词去绕过它，因为一旦惹上风控，整个账号的服务都会受到影响，得不偿失。4.3 回调丢失与消息漏听的兜底方案在实际运行中，即使你的监听逻辑写得再严密，也难免遇到消息更新事件丢失的情况。比如程序在某个时刻断线重连，中间几条消息更新没被捕获。为了避免任务永久卡在“processing”状态，我在调度器里加了一个超时巡检线程：每 30 秒扫一次mj_task表，凡是状态为processing且超过设定时间没有更新的任务，主动向 Discord 重新拉取一次消息内容，如果拉到的新消息里已经包含图片 URL，就补录成功状态；如果拉不到，就标记失败并重试。这个兜底设计非常关键。没有它，你可能会发现线上有一堆任务永远没有结果，用户还一直以为在生成中。4.4 图片质量不稳定：Midjourney 的“语言直觉”问题自动化调用往往会暴露出一个很尴尬的问题：同一个 Prompt，手动跑和通过 API 跑，生成结果的质量分布是一样的——群体里总有几张是不太理想的。Midjourney 对自然语言的理解非常敏感，同样的描述，改动一个形容词可能结果就差很远。我从实践中总结出几条提高出图质量稳定性的经验：Prompt 要具体，不要给太多自由发挥空间。用 “a studio portrait of a woman in a blue dress, soft lighting, 85mm lens” 这样的描述，比 “beautiful woman” 稳定得多。把风格关键词放在前半段，把内容主体放在后半段，Midjourney 对 Prompt 早期部分的权重更高。尽量固定 seed。业务上如果需要保持前后两次生成风格接近，使用同一个--seed会给你更好的连贯性。对质量要求高的场景，不要只发一次任务拉倒。封装层可以支持“生成 2 张选 1 张”的策略，把成本翻倍，但产出可用率提高很多。4.5 账号被风控的预兆与日常维护最后聊一个比较微妙的话题。自动化调用 Discord 接口，本质是模拟用户操作，虽然低频情况下风险很低，但不是零风险。我观察到的一些风险信号包括：收到的验证码请求增多、发送命令后没有响应、账号被要求重新验证登录等。我目前的做法是：控制单账号每日调用量，保持一个接近真实用户的使用节奏；定期检查账号状态，手动登录一次；绝对不在短时间内对同一个 Prompt 做大量重复调用。这些说起来都是常识，但在工程压力面前很容易被忽略。5. 接入业务系统时的工程化建议5.1 用 job 表吃下所有异步状态前面提到的mj_task表，在接入业务系统时可以直接成为所有对外 API 的状态依据。业务方调用你的接口时，只需要传一个 Prompt 和参数，你返回一个job_id；业务方后续轮询/status接口时，你查询这张表返回当前状态。这种方式的好处是把复杂的 Discord 交互细节完全封装在内部，业务方不需要关心什么网格图、按钮组件、消息监听。从他们的角度看，这就是一次普通的异步任务提交。5.2 同步请求与异步回调该怎么选如果你的业务方是一个低并发的内部工具，同步阻塞式调用其实更简单：发完任务后循环查询表状态，直到成功或超时。这里唯一需要小心的就是超时时间。Midjourney 高峰期一个任务可能要 3 分钟以上，你的 HTTP 客户端超时时间要相应调大。如果是面向外部用户的公开服务，我建议采用“异步任务 + 回调通知”的模式。任务完成时，通过 Webhook 通知业务方，同时保留一个查询接口作为兜底。这套机制可以从零实现，也可以借鉴现成的任务队列框架来搭建，重点在回调签名校验和失败重试，这些细节考验的就是对生产系统的理解是否扎实。5.3 结果图片的持久化与自动清理图片转存到自己存储之后，还要考虑存储成本和生命周期。通常我的做法是对图片设置一个生命周期策略，例如保留 7 天，之后自动清除。生成图片这种东西，大部分业务场景下都是短期消费，没有永久保留的必要。另外，给图片文件命名时可以直接用job_id作为主文件名，这样排查问题时从日志到存储路径可以一路对过去。5.4 成本、配额与监控报警Midjourney 的订阅是按月付费，不同档位对应不同的 GPU 时长额度。自动化调用时，因为少了很多人工筛选的过程，额度消耗速度会比想象中快很多。我建议在封装层加一层额度统计：每次成功生成一张图，就自动累计一下当天的 GPU 时间估算值，超过阈值就自动暂停任务队列，等次日或人工介入后再恢复。监控方面，除了常规的请求成功率、平均生成时长，最值得关注的是任务在“processing”状态下的超时率。这个指标直接反映了账号健康度和队列拥堵情况。我会给这个指标单独配一个告警，因为在所有异常里它最难被人工感知。最后想分享的一点实操体会这一整套东西从零到跑通，最重要的不是代码技巧，而是心态上的预期管理。Midjourney 本身不是一台标准的“图像生成服务器”，你要理解并接受它的随机性和不确定性，然后在工程层面用任务表、超时重试、兜底巡检来消化这些不确定性。如果你现在准备动手做，我的建议是先别急着上队列、上并发、上回调。先用最简单的脚本，手动调一次/imagine，把消息监听打通，拿到一根可用的图片 URL 链接。整个过程可能只需要一个晚上。等这条通路验证没问题了，再逐步加上任务表、状态机、超时处理和对外接口，每一步都单独验证，而不是一把梭把所有功能堆上去。我在实际项目里就是用这个节奏做的：第一版只有 200 行代码，能跑通单任务；第二版加入任务表和队列，稳定运行了一周；第三版才加入并发控制和存储转发。每一次改动都建立在前一版的稳定基础上，踩坑时也更容易定位问题。希望这些经验能让你的 Midjourney 封装之路少走一些弯路。
如果你在团队里负责给内容平台加一个自动配图功能，大概率会经历这样一轮搜索：打开 Midjourney 官网找 API 文档，找不到；搜“Midjourney API”，蹦出来的全是第三方中转站，价格从几美元到几百美元不等，参数五花八门，也没人敢保证稳定性。这篇文章想解决的就是这个问题。我会先讲清楚为什么 Midjourney 没有官方开放的 API，再介绍一种可控、低成本的接入方式——通过 Discord 交互机制的封装，把 Midjourney 的图像生成能力包装成一个可供内部业务调用的 HTTP 服务，并给出每一步的代码骨架、参数映射和真实运行中会遇到的坑。这篇指南面向的不是想“一键接入”的产品经理，而是需要自己动手把能力落地到业务里的开发同学。你需要懂一些 HTTP、JSON、基本的消息队列概念，不一定需要多深，只要跟着走完一遍，就能搭出一个能用的 Midjourney 图像生成 API 封装服务。1. 先搞清楚市面上说的“Midjourney API”到底是什么1.1 官方形态：Midjourney 从诞生起就不是一个标准 Web 服务Midjourney 的产品形态非常特殊，它没有像 OpenAI 那样提供api.openai.com这种标准 REST 端点，也没有发布过正式的 API Key 体系。它主要跑在 Discord 里，靠用户往聊天窗口敲/imagine这样的斜杠命令来触发生成任务，然后 Midjourney 机器人会把进度消息和最终图片发回频道。所以你在很多教程里看到的“Midjourney API 调用”，本质上都不是官方提供的接口，而是别人把 Discord 上的人工操作自动化了。这个区分必须在一开始就建立，否则后面代码写再多也容易踩到不该踩的坑。1.2 三种常见的“API”方案，以及我为什么选了自建封装市面上号称“Midjourney API”的服务，我大概归成三类：方案类型实现原理稳定性成本风险官方 Discord 交互自动化用账号凭证模拟用户在 Discord 发送命令，再监听频道消息拿结果取决于账号状态和网络环境只需要 Midjourney 订阅费高频操作可能触发风控第三方中转 / 代理服务别人封装好了 Discord 交互，你直接调他暴露的 HTTP 接口看平台运营情况，经常有跑路或限流按张计费，通常比订阅费贵很多图片和 Prompt 都会经过第三方，数据有泄露风险官方未来可能逐步开放的 API 计划官方尚未大规模对外开放，目前没有面向个人开发者的自助接入未定未定未定我最终选择的是第一类，自建一个封装层。原因很直接：团队内部工具链需要的数据安全和可定制性，第三方中转提供不了。把 Prompt 发给陌生人平台这件事，在涉及品牌素材或用户数据时应尽量避免；另外按张付费的模式跑一个月，价格往往比一个 Midjourney 订阅账号高出好几倍。1.3 选型之前先认清的几个现实约束自建方案虽然可行，但有几个约束必须提前接受：第一，Discord 的接口设计和鉴权机制不是为开放 API 准备的，它没有“批量生成图片”这种接口，你只能在消息交互协议上做文章。第二，Midjourney 的生成耗时波动大，短则几十秒，长则几分钟，这决定了你不可能像调普通 HTTP API 那样阻塞等待。第三，自动化操作 Discord 这件事，严格来说是处于灰色地带的，账号有被限制使用的风险，所以你的设计必须从源头控制频率，不能把它当成无限并发的免费算力。把这些约束想清楚之后，再去看市面上动不动就吹“毫秒级响应”的所谓 API，你就明白那种东西为什么不可信了。2. 开工之前需要备齐的环境、账号与基础设施2.1 账号、频道与 Bot 权限要自建封装服务，你需要准备的东西不多，但每一样都很关键：一个可用的 Midjourney 订阅账号，这个账号必须绑定了 Discord 登录，且能正常使用/imagine命令。一个单独的 Discord 服务器，建议不要在你同事都在的大频道里做自动化测试，否则机器人的反馈消息会刷屏干扰别人。自己创建一个只有机器人和你个人账号的私有服务器，一切操作都在里面完成。一个 Midjourney 机器人账号可以被调用的环境。Discord 的机器人权限配置，简单来说就是保证消息能发出去、能读到 Midjourney 机器人的回复。实际操作中，最忌讳的是拿同事的账号去跑测试。我一开始就吃过这个亏。用别人的账号跑自动化，一旦触发风控，被限制的还不是你自己一个人的账号。2.2 调用凭证的获取与风险边界这一步是整个自建封装里最敏感、也最容易被教程含糊带过的地方。Discord 的自动化交互通常需要拿到登录凭证，常见的有两类思路：一是使用个人账号的用户令牌（User Token），二是使用应用机器人令牌（Bot Token）并申请对应的消息权限。用户令牌的获取方式在浏览器开发者工具里就能找到，但这东西相当于账号的钥匙。写进代码里、提交到 Git 仓库、放在明文配置文件里，都是极度危险的做法。我的习惯是放进环境变量或者专门的密钥管理服务里，并且只给极少数运维人员知道。另外需要坦诚地说一句：用 User Token 做自动化，是和 Discord 官方的服务条款相冲突的。这意味着账号存在被限制的风险。所以我在实际生产项目里给出的建议是：这个方案更适合内部工具、低频率调用，不要拿它去做商业模式上完全依赖的对外服务。如果你真的要做面向大量用户的商业产品，应该去联系官方或选择有明确授权的服务商，而不是自己赌账号寿命。2.3 服务器到 Discord 服务的连通性验证这一步很多人会忽略，但它往往决定了后面调试的顺利程度。Midjourney 的交互需要你的程序服务器能直接访问 Discord 的网关和 CDN 服务。部署在国内云服务器上时，经常遇到延迟高或者连接不稳定的问题。我踩过的坑是：本地开发环境一切正常，代码部署到某云厂商的轻量服务器后，任务发出去就石沉大海。查了半天发现是服务器与 Discord 服务之间的网络连接存在超时。所以在选型初期就应该确认好：你的服务器是否具备出网能力，到 Discord 相关域名的连通性是否稳定，延迟是否能接受。验证方法很简单，找一个能稳定运行的网络工具，从服务器上 ping 一下或直接尝试建立 WebSocket 连接。如果条件不满足，可能要使用海外节点部署这套服务，或者考虑从网络策略层面做调整。这里不展开讲具体工具，只要记住一句话：连通性这件事，必须在写代码之前验证，而不是写完代码之后才排查。2.4 为任务队列设计预留的数据库结构Midjourney 生成一张图可能要一两分钟，在这个时间里你的程序不能干等，否则并发一上来就卡死。所以从第一天开始就要按“异步任务”的方式设计数据表。我常用的表结构非常简单，就一张mj_task表，字段大致如下：字段名类型说明idvarchar业务方生成的唯一任务 IDprompttext原始 Prompt 文本statusvarcharpending / sending / processing / success / failedmessage_idvarcharDiscord 消息 ID，用于定位结果image_urltext最终图片 URLerror_reasontext失败原因created_atdatetime创建时间finished_atdatetime完成时间这张表就是整个封装服务的主心骨。后面要做重试、做回调、做统计，全部围绕它来展开。3. 核心调用链路：从发送 Prompt 到拿回成图 URL3.1 一次完整生成在 Midjourney 侧发生了什么当你手动在 Discord 输入/imagine a red fox in the snow并回车时，背后其实发生了这样一串事件：你的客户端向 Discord 发送一条交互指令（Interaction），目标对象是 Midjourney 机器人。Midjourney 机器人收到后，会在频道里发一条消息，内容是“正在处理，请稍候”，通常以斜体文本出现，例如*a red fox in the snow*。过了一会儿，它会把这条消息更新为图片网格（Grid），也就是四张图拼在一起，下面带两排按钮：U1-U4 是放大某一张，V1-V4 是基于某一张做变体。当你点击 U1 或 V1 之后，机器人再次把消息更新，最终输出单张高清图。所以整个自动化流程就是：替用户完成“发命令”这一步，然后监听 Midjourney 机器人发的消息，通过消息内容和附件的出现情况判断当前阶段，最终把高清图片的 URL 提取出来。3.2 发送交互命令的代码骨架我尝试过两种实现路线，一种是直接基于 Discord 的 WebSocket 网关来交互，另一种是利用第三方机器人库，本质也是帮你连接网关。两者原理一致，区别只在于封装程度。直接构造 HTTP 请求发送交互命令的骨架，可以用 Python 写得很短。这里演示核心逻辑，不代表完整可运行的生产代码：import requests def send_imagine_command(channel_id, prompt, auth_token): url = "https://discord.com/api/v9/interactions" payload = { "type": 2, "application_id": "你的Midjourney应用ID", "guild_id": "你的服务器ID", "channel_id": channel_id, "session_id": "随机生成的会话ID", "data": { "version": "接口协议版本号", "id": "斜杠命令的ID", "name": "imagine", "type": 1, "options": [ { "type": 3, "name": "prompt", "value": prompt } ], "application_command": { "id": "斜杠命令的ID", "name": "imagine", "type": 1 } } } headers = { "Authorization": auth_token, "Content-Type": "application/json" } response = requests.post(url, json=payload, headers=headers) return response.status_code这段代码里的session_id和application_id都要从实际环境中抓取。很多教程喜欢把这些参数全部写死，导致你换一个频道就报错。另一个更稳定的做法是使用成熟的 Discord 开发库，让库帮你处理网关连接、心跳维护和消息接收。生产环境建议用这个方向，因为你不可能永远通过手动抓包来维护协议字段。我自己实际生产代码里，就是基于discord.py自建了一个后台任务管理模块，专门负责发送交互指令和监听事件，比起手写 HTTP 骨架省心太多。3.3 常用参数如何映射到 Midjourney 命令参数Midjourney 的 Prompt 参数不是 JSON 字段，而是追加在文本末尾的--风格参数。这一步的映射是封装 API 时最容易被忽略的环节。很多人在自己的 HTTP 接口里设计了一个aspect_ratio字段，但忘了在拼 Prompt 时加上--ar 16:9，结果生成出来永远是默认的 1:1。我常用的参数映射表如下：自己的 API 参数Midjourney 命令参数示例prompt无a red foxaspect_ratio--ar--ar 16:9stylize--s--s 750chaos--c--c 50seed--seed--seed 12345tile--tile--tilequality--q--q 0.25no--no--no text, watermark拼接的时候注意，如果参数值本身包含空格，需要用引号包裹，例如--ar 16:9没问题，但某个自定义参数的值里有空格时就得小心处理。我遇到过最诡异的 Bug 是：Prompt 里包含换行符，直接拼进/imagine命令后，Discord 把换行后的内容当成新消息发送，导致命令残缺。正确做法是在拼接前把所有控制字符清理掉。3.4 如何在消息流里可靠判断“生成完成”整个自动化里最核心的难点就是判断“任务做到哪一步了”。Midjourney 机器人发送的消息内容是逐步变化的，阶段特征非常明显：初始消息：纯文本，通常是一个斜体的 Prompt 副本。网格图阶段：消息里出现一个图片附件，且有 4 张图拼在一起，下方出现 U/V 按钮组件。放大图阶段：点击 U 或 V 之后，消息被编辑升级为单张高清图。最终完成：附件 URL 稳定不再变化，按钮可能消失或变为重roll按钮。我的判断逻辑很简单：在消息更新事件里，如果识别到附件里的图片 URL 存在，且 URL 对应的文件名包含网格标识，说明这是中间阶段；如果附件是单独一张大图，说明任务已完成。这种方式不需要解析按钮的状态，比较稳定。演示一下简单的消息监听逻辑（伪代码）：async def on_message_update(before, after): if after.author.name != "Midjourney Bot": return attachments = after.attachments if len(attachments) == 0: # 只有文字，说明还在生成中 update_task_status(message_id, "processing") return image_url = attachments[0].url # 这里可以根据 URL 中是否包含 grid 关键词判断阶段 if "grid" in image_url: update_task_status(message_id, "grid_ready") else: # 单张高清图，认为完成 update_task_status_and_notify(message_id, "success", image_url)3.5 图片 URL 的提取、时效与转存Discord CDN 上的图片 URL 不是永久的。默认情况下，通过 CDN 拿到的链接可以参考带签名的时效参数，过期后访问会 403。这意味着你在业务里如果直接丢一个 Discord 链接给前端页面展示，过几个小时就挂了。所以我在封装服务的最后一步，一定会把最终图片下载下来，转存到自己的对象存储服务里，然后用自己存储的 URL 作为输出。这个步骤看起来多了一次下载和上传，但对生产系统来说是必须的。有一次我偷懒没做转存，测试时一切正常，第二天运营同学反馈说海报里的图片全部裂了，查了半天才发现是 Discord CDN 链接过期。4. 把服务跑稳定必须处理的真实问题4.1 任务排队与并发上限：为什么不能无脑加线程Midjourney 的账号是有并发限制的。免费用户和付费用户在排队机制上有差异，付费模式下，同时提交的任务过多，后面的任务会进入等待队列，甚至有的任务会被系统判定为异常而不予执行。我一开始犯过的错是：用线程池一口气发了 20 个任务，结果前几个成功，后面的全部失败或者长时间无响应。后来我重新设计了调度器，用一个单线程的队列调度器，每次只往 Discord 发送一个任务，等它完成或超时之后再发下一个。这样虽然吞吐量低了，但稳定性大幅上升。如果需要提高吞吐量，正确的做法是准备多个 Midjourney 账号，在调度器里做账号轮询，而不是在一个账号上无限叠加并发。每个账号维护自己的并发计数和限流状态。4.2 常见错误响应与对应的处理策略跑一段时间后，难免会遇到各种异常响应。我整理了几个高频错误和大家分享：现象可能原因处理方式消息发出后无任何回复网络问题或命令格式错误查询原始 Prompt 和拼接参数，主动重发一次消息有回复，但一直卡在斜体文本状态Midjourney 队列拥堵或账号被限增加超时时间，超时后标记为失败返回Invalid ParameterPrompt 里包含非法参数滤除非法参数，注意--no值的引号问题返回Blocked内容被安全策略拦截记录失败原因，不要尝试用变体词绕过Blocked这个问题我遇到了不止一次。Midjourney 对内容安全有比较明确的策略，某些 Prompt 被判定违规后，会直接拒绝生成，甚至触发临时限制。不要试图用拼写变体或谐音词去绕过它，因为一旦惹上风控，整个账号的服务都会受到影响，得不偿失。4.3 回调丢失与消息漏听的兜底方案在实际运行中，即使你的监听逻辑写得再严密，也难免遇到消息更新事件丢失的情况。比如程序在某个时刻断线重连，中间几条消息更新没被捕获。为了避免任务永久卡在“processing”状态，我在调度器里加了一个超时巡检线程：每 30 秒扫一次mj_task表，凡是状态为processing且超过设定时间没有更新的任务，主动向 Discord 重新拉取一次消息内容，如果拉到的新消息里已经包含图片 URL，就补录成功状态；如果拉不到，就标记失败并重试。这个兜底设计非常关键。没有它，你可能会发现线上有一堆任务永远没有结果，用户还一直以为在生成中。4.4 图片质量不稳定：Midjourney 的“语言直觉”问题自动化调用往往会暴露出一个很尴尬的问题：同一个 Prompt，手动跑和通过 API 跑，生成结果的质量分布是一样的——群体里总有几张是不太理想的。Midjourney 对自然语言的理解非常敏感，同样的描述，改动一个形容词可能结果就差很远。我从实践中总结出几条提高出图质量稳定性的经验：Prompt 要具体，不要给太多自由发挥空间。用 “a studio portrait of a woman in a blue dress, soft lighting, 85mm lens” 这样的描述，比 “beautiful woman” 稳定得多。把风格关键词放在前半段，把内容主体放在后半段，Midjourney 对 Prompt 早期部分的权重更高。尽量固定 seed。业务上如果需要保持前后两次生成风格接近，使用同一个--seed会给你更好的连贯性。对质量要求高的场景，不要只发一次任务拉倒。封装层可以支持“生成 2 张选 1 张”的策略，把成本翻倍，但产出可用率提高很多。4.5 账号被风控的预兆与日常维护最后聊一个比较微妙的话题。自动化调用 Discord 接口，本质是模拟用户操作，虽然低频情况下风险很低，但不是零风险。我观察到的一些风险信号包括：收到的验证码请求增多、发送命令后没有响应、账号被要求重新验证登录等。我目前的做法是：控制单账号每日调用量，保持一个接近真实用户的使用节奏；定期检查账号状态，手动登录一次；绝对不在短时间内对同一个 Prompt 做大量重复调用。这些说起来都是常识，但在工程压力面前很容易被忽略。5. 接入业务系统时的工程化建议5.1 用 job 表吃下所有异步状态前面提到的mj_task表，在接入业务系统时可以直接成为所有对外 API 的状态依据。业务方调用你的接口时，只需要传一个 Prompt 和参数，你返回一个job_id；业务方后续轮询/status接口时，你查询这张表返回当前状态。这种方式的好处是把复杂的 Discord 交互细节完全封装在内部，业务方不需要关心什么网格图、按钮组件、消息监听。从他们的角度看，这就是一次普通的异步任务提交。5.2 同步请求与异步回调该怎么选如果你的业务方是一个低并发的内部工具，同步阻塞式调用其实更简单：发完任务后循环查询表状态，直到成功或超时。这里唯一需要小心的就是超时时间。Midjourney 高峰期一个任务可能要 3 分钟以上，你的 HTTP 客户端超时时间要相应调大。如果是面向外部用户的公开服务，我建议采用“异步任务 + 回调通知”的模式。任务完成时，通过 Webhook 通知业务方，同时保留一个查询接口作为兜底。这套机制可以从零实现，也可以借鉴现成的任务队列框架来搭建，重点在回调签名校验和失败重试，这些细节考验的就是对生产系统的理解是否扎实。5.3 结果图片的持久化与自动清理图片转存到自己存储之后，还要考虑存储成本和生命周期。通常我的做法是对图片设置一个生命周期策略，例如保留 7 天，之后自动清除。生成图片这种东西，大部分业务场景下都是短期消费，没有永久保留的必要。另外，给图片文件命名时可以直接用job_id作为主文件名，这样排查问题时从日志到存储路径可以一路对过去。5.4 成本、配额与监控报警Midjourney 的订阅是按月付费，不同档位对应不同的 GPU 时长额度。自动化调用时，因为少了很多人工筛选的过程，额度消耗速度会比想象中快很多。我建议在封装层加一层额度统计：每次成功生成一张图，就自动累计一下当天的 GPU 时间估算值，超过阈值就自动暂停任务队列，等次日或人工介入后再恢复。监控方面，除了常规的请求成功率、平均生成时长，最值得关注的是任务在“processing”状态下的超时率。这个指标直接反映了账号健康度和队列拥堵情况。我会给这个指标单独配一个告警，因为在所有异常里它最难被人工感知。最后想分享的一点实操体会这一整套东西从零到跑通，最重要的不是代码技巧，而是心态上的预期管理。Midjourney 本身不是一台标准的“图像生成服务器”，你要理解并接受它的随机性和不确定性，然后在工程层面用任务表、超时重试、兜底巡检来消化这些不确定性。如果你现在准备动手做，我的建议是先别急着上队列、上并发、上回调。先用最简单的脚本，手动调一次/imagine，把消息监听打通，拿到一根可用的图片 URL 链接。整个过程可能只需要一个晚上。等这条通路验证没问题了，再逐步加上任务表、状态机、超时处理和对外接口，每一步都单独验证，而不是一把梭把所有功能堆上去。我在实际项目里就是用这个节奏做的：第一版只有 200 行代码，能跑通单任务；第二版加入任务表和队列，稳定运行了一周；第三版才加入并发控制和存储转发。每一次改动都建立在前一版的稳定基础上，踩坑时也更容易定位问题。希望这些经验能让你的 Midjourney 封装之路少走一些弯路。