阿里云多模态图片生成！抛弃SDK手写Fetch请求，我终于搞懂了大模型调用底层

上周做 AI 人像换装需求直接卡崩，原本依赖 OpenAI 封装 SDK 快速开发，本地调试连续收到鉴权 401 报错，对着文档翻了一上午没找到问题根源。干脆删掉所有 SDK 依赖，用 Node 原生fetch手动拼接请求对接阿里云万相 wan2.7-image 模型，反倒借着排错把多模态图文生成、Prompt 多图入参的知识点彻底捋顺了。

先聊聊这次的落地需求，也是我手上这三张素材的由来。

需求很直白：保留第一张女生的五官样貌，给她换上第二张的黑色连衣裙，并且严格按照第三张骨架标记的坐姿生成成片。放在 AIGC 里，这就是典型从纯文本生成过渡到多模态图文混输 的场景，也是我笔记里text generation → image generation的实际落地案例。

说实话之前我对多模态一直一知半解，总觉得图生图就是丢一张参考图再加一句提示词就行，直到要一次性传入三张不同用途的参考图，才琢磨明白大模型接收多素材的运行逻辑。我拿生活化的例子捋了一遍：大模型好比影楼全能造型师，第一张人像图是固定出镜的模特（锁定长相、面部特征），第二张裙子图是选定的定制服装，第三张关键点图是摄影师规定好的摆拍姿势，最后的文字 Prompt 就是我跟造型师口述的成片要求，三份参考素材 + 一句指令，共同构成完整输入。

能直接跑通的最小 Demo 代码

折腾半天整理出可本地运行的代码，注释里顺带标了我踩坑的关键点，直接替换.env 里的密钥就能测试：

javascript

运行

javascript 复制代码

import dotenv from 'dotenv';
dotenv.config();

async function generateImage() {
    // 坑1：密钥千万不要随便塞到Content-Type请求头，我在这栽了半小时
    const OPENAI_API_KEY = process.env.OPENAI_API_KEY;
    const response = await fetch(
        // 坑2：阿里云通义万相专属接口地址，别错填成OpenAI官方域名
        'https://dashscope.aliyuncs.com/api/v1/services/aigc/multimodal-generation/generation',
        {
            method: 'POST', // AIGC接口基本全用POST，后面细说原因
            headers: {
                'Content-Type': 'application/json',
                'Authorization': `Bearer ${OPENAI_API_KEY}`, // 鉴权密钥固定放在这个字段
            },
            body: JSON.stringify({
                "model": "wan2.7-image",
                "input": {
                    "messages": [{
                        "role": "user",
                        "content": [
                            // 三张参考图+文字指令，嵌套在同一个content数组是规范写法
                            { "image": "https://help-static-aliyun-doc.aliyuncs.com/file-manage-files/zh-CN/20250925/thtclx/input1.png" },
                            { "image": "https://help-static-aliyun-doc.aliyuncs.com/file-manage-files/zh-CN/20250925/iclsnx/input2.png" },
                            { "image": "https://help-static-aliyun-doc.aliyuncs.com/file-manage-files/zh-CN/20250925/gborgw/input3.png" },
                            { "text": "图1中的女生穿着图2中的黑色裙子按图3的姿势坐下" }
                        ]
                    }]
                }
            })
        }
    )
    const data = await response.json();
    
    // 获取任务ID，方便后续异步轮询生成结果
    const requestId = data.request_id || '未知';
    console.log(`request_id: ${requestId}`);
    
    // 从返回体里提取生成图片链接
    let imageUrl = null;
    if (data.output && data.output.choices && data.output.choices.length > 0) {
        const choice = data.output.choices[0];
        if (choice.message && choice.message.content) {
            const content = choice.message.content;
            if (Array.isArray(content)) {
                const imageContent = content.find(item => item.image);
                if (imageContent && imageContent.image) {
                    const imageData = imageContent.image;
                    // 接口返回要么在线URL，要么base64编码图片，两种格式都做兼容
                    if (imageData.startsWith('http')) {
                        imageUrl = imageData;
                    } else if (imageData.startsWith('data:image')) {
                        imageUrl = imageData;
                    }
                }
            }
        }
    }
    
    console.log(`图片URL: ${imageUrl || '未找到'}`);
    return { requestId, imageUrl };
}

generateImage();

本地新建.env文件填入密钥，格式如下：

env 复制代码

OPENAI_API_KEY=sk-xxx

终端运行脚本后，控制台成功打印出生成图片的在线链接那一刻，悬着的心才算落地。

深挖一层：不管什么 SDK，本质全是封装 HTTP 请求

跑通 demo 后我突然好奇，平时我们用的 OpenAI 官方 SDK 到底干了什么？翻了一圈 SDK 源码后恍然大悟：市面上所有大模型封装 SDK，底层没有黑魔法，全是对fetch/axios这类网络请求的二次封装。

说白了对接大模型接口永远绕不开三件事，正好对应我手写 fetch 的三个配置项：

请求 URL：不同厂商大模型有专属接口域名，阿里云万相、OpenAI、文心一言全不通用，填错直接接口报错；
请求头 headers ：Content-Type固定application/json，鉴权密钥统一挂载在Authorization: Bearer xxx字段，用来校验调用权限；
请求体 body：业务参数全塞在这里，我们的参考图、Prompt 文本、模型名称都属于 body 内容。

顺带解惑了笔记里的疑问：为什么 AIGC 接口几乎清一色用 POST 而不是 GET？GET 的参数会拼接在 URL 链接里，一方面多张图片的资源链接过长极易超出 URL 长度限制，另一方面密钥暴露在链接上很容易被抓包窃取，POST 把数据藏在请求体里，安全和长度问题一次性解决。

踩过的两个致命大坑，错误写法贴出来避坑

这两个错误我实打实浪费近一小时排查，新手调用多模态接口大概率也会踩中

鉴权密钥存放位置错误 最开始随手把 API_KEY 写在了Content-Type里，接口反复返回 401 无权限。

javascript 复制代码

// 错误写法！千万别这么写
headers: {
    'Content-Type': `application/json;${OPENAI_API_KEY}`
}
// 正确写法：Authorization单独承载鉴权信息
headers: {
    'Content-Type': 'application/json',
    'Authorization': `Bearer ${OPENAI_API_KEY}`
}

多图 content 嵌套层级写错 初期我把三张 image 对象和 text 平级放在 message 外层，大模型完全识别不到参考图片，只会根据文字随机生成人物。规范要求：所有图片资源 + 文本提示词，必须全部嵌套在同一个 user 角色的 content 数组中。

除此之外还有个小乌龙：我曾用 OpenAI 的接口地址去调用万相的wan2.7-image模型，接口直接返回「模型不存在」，不同服务商的接口域名和模型命名体系完全割裂，不能混用。

收尾：这次折腾沉淀下来的三点收获

折腾完整套流程，抛开代码本身，有三个实打实的感悟：

看不懂第三方 SDK 的时候，抛弃封装、裸写原生网络请求是吃透底层最快的办法，拆解完请求结构，再回头看 SDK 源码一目了然；
多模态图生图的多参考图逻辑：每张参考图各司其职（控人脸 / 控服饰 / 控姿态），Prompt 做最终约束，入参格式严格遵循 content 数组嵌套规范；
所有大模型调用本质是远程 HTTP 通讯，鉴权、入参、域名是对接接口的三要素，掌握这三点，换任何厂商的 AIGC 接口都能快速上手。

另外客观说下这个方案的短板：单靠多张参考图 + Prompt 做换装，复杂褶皱服饰、高难度人体姿态很容易生成崩坏图，大批量商用换装场景不能只依赖 Prompt 参考图，需要针对性微调大模型权重。

如果你平时也在折腾 AI 图生图、多模态调用，踩过鉴权、传参相关的奇葩 bug，搞懂之后不妨在评论区聊聊，我也想瞅瞅大家遇到过哪些离谱报错。