Image-2 2K/4K 跟随原图比例怎么用：auto、首张参考图和 100049

常见误解是：aspectRatio: "auto" 就等于“照搬原图比例”。事情没这么省事。关键在这里：Image-2 在 2K/4K 档读取的是首张参考图的宽高，随后再映射到最接近的高清比例。首图读不到，返回的也不是笼统的“生成失败”，而是外层错误码 100049。

截至 2026 年 7 月 18 日，本文依据图叮开放平台当前文档与能力合同核对。比例、高清权限等动态能力，仍应以 GET /capabilities 的实时返回为准，别把本文列出的当前集合写死成永久常量。下面逐个拆开几个容易混淆的判断。

问：auto 会原样保留参考图的任意比例吗？

误区： 原图是多宽多高，输出就保持完全相同的宽高比。

事实： 2K/4K 的 auto 做的是“读取后映射”，并不会复制任意比例。根据图叮开放平台官方文档，当前高清档列出 15 个具体 W:H 比例，例如 1:1、4:3、16:9、9:16 和 21:9。后端读到首张参考图的宽高后，会选距离最近的受支持档位。

图注：auto 只读取首张参考图，再映射到最接近的高清比例。

比如一张可读的 16:9 参考图，通常会映射到 16:9。如果原图是一个不在集合里的特殊长幅，auto 依然会落到最近的高清档，不会保留那条特殊比例。交付物要求精确画幅时，就别让后端猜，直接提交已由 GET /capabilities 返回的具体比例更稳。

如果你还没决定该用 2K 还是 4K，可以先看 GPT Image 2 的 2K / 4K 适用场景。先锁用途，再锁比例。顺序反了，排查时间很容易白花。

问：多张参考图会一起决定输出比例吗？

误区： referenceImages 里有几张图，系统会把它们的比例平均一下，或自动挑最重要的一张。

事实： 当前合同明确以第一张参考图为比例来源。第二张及后续图片仍可参与内容参考，但不会共同计算 auto 的画幅。这是接口语义，不是审美排序。

假设你要做一张横版商品场景图：第一张放 1:1 产品白底图，第二张才放 16:9 场景图。即使你的意图是跟随场景构图，auto 读取的比例锚点仍是第一张。这个例子只是接口顺序示意，不代表一次真实生成结果。

要避免歧义，做法有两种：把真正承担画幅锚点的图放在数组首位，或者直接传 16:9。

参考图本身的清晰度、曝光和主体完整度，也会影响后续使用价值。准备素材时，可顺手用 原图进入 AI 前的 6 项自测 检查一遍。不过要分清：素材质量差会影响生成质量，首图无法读取才会走到 100049。这不是同一个故障。

问：不传参考图也会报 100049 吗？

误区： 2K/4K 只要写了 auto，后端没有原图可跟随就一定报错。

事实： 当前开放平台合同规定，2K/4K 的纯文生图没有 referenceImages 时，auto 按 1:1 兜底，不会因为缺参考图返回 100049。这条分支要单独记住：

• 没传参考图：当前按 1:1 继续提交。
• 传了参考图且首图可读：按首图比例映射到最近高清档。
• 传了参考图但首图不可读：在扣费前返回 100049。

所以排障时，别只盯着 aspectRatio。先确认请求体里到底有没有 referenceImages，再查数组第一项。三种输入一旦混在一起，日志看再久也找不到根因。

问：出现 100049 就是比例参数写错了吗？

误区： 看到“跟随原图比例失败”，第一反应就是 auto 拼错了，或宽高比不在列表里。

事实： 100049 指向的是首张参考图不可读。官方文档给出的主要原因包括：图片 URL 无法访问、被安全策略拒绝、地址不是可接受的 HTTP(S) 资源，或响应内容根本不是图片。

它和具体比例值不受支持要分开。2K/4K 传了不在支持集合里的具体 W:H，对应的是 10075。

排查时保留完整外层响应，按下面顺序走：

1. 确认响应 code 确实是 100049，不要拿任务里的 errorCode 代替。
2. 取 referenceImages[0]，从服务端网络环境访问一次。
3. 检查最终响应状态、Content-Type 与字节内容，确认不是登录页、拦截页或 JSON 错误页。
4. 若 URL 无法稳定读取，换成服务端可访问的公网图片，或改传具体 W:H。

“从服务端访问”很重要。你自己的浏览器能打开，不等于图叮后端也能访问。浏览器可能带着登录 Cookie，也可能能走公司内网；开放 API 的服务端不会自动继承这些条件。

问：内网地址和 data URL 能用于跟随原图比例吗？

误区： 只要字符串里能表达一张图，后端就能读取宽高。

事实： 不要把接口设计建立在这个假设上。当前文档要求参考图是后端可访问的图片 URL，100049 的说明也把内网地址、非 HTTP(S) 地址与被安全策略拒绝列为典型失败路径。

更稳妥的输入应满足三点：

• URL 使用 http 或 https，且图叮后端可以直接访问。
• 不依赖浏览器 Cookie、内网 DNS 或本机文件路径。
• 响应本身是可读图片，不是重定向后的登录页或防盗链提示。

若你必须处理内网素材，先在自己的受控服务里完成合规上传，再把可访问 URL 交给 Image-2。API Key 也应只放在服务端，别为了省一步，把密钥和内网地址一起塞进浏览器代码。

开放平台控制台目前需要登录并通过访问门控，已创建的 Key 则通过 X-Api-Key 调用开放 API；明文 Key 只在创建时返回一次，应当场保存并妥善保管。

问：100049 原样重试几次会自己好吗？

误区： 这是生成服务偶发抖动，循环重试就行。

事实： 如果首图 URL、鉴权和响应内容都没变化，原样重试只会重复同一个输入错误。100049 在扣费前拦截，不消耗 Image-2 积分。这恰好说明，正确动作应是“修输入后再提交”，而不是指数退避式盲重试。

恢复动作可以压成两条：

• 还想跟随原图画幅：修好 referenceImages[0] 的可访问性，确认返回真实图片，再提交 auto。
• 交付比例已经确定：跳过自动映射，改传 GET /capabilities 当前返回的具体 W:H。

真正适合有限重试的是系统繁忙、并发冲突一类暂态错误。参数或素材不满足合同，重试次数再多，事实也不会改变。

问：怎样选择 auto 还是具体 W:H？

把判断收成一棵小树就够了。

图注：无参考图、首图可读和首图不可读要走不同分支。

要跟随首张原图的大致画幅，而且首图 URL 能被服务端稳定读取，选 auto。有多张参考图时，把承担画幅锚点的那张放第一位。要交付固定横版、竖版或方图，直接传 GET /capabilities 给出的具体比例。少一层映射，也少一类故障。

如果你关心的是图生图“像不像原图”，那属于内容约束问题，不是比例问题；可继续看 图生图相似度与改动空间怎么控制。比例只决定画布形状，不能替你锁住主体、文字或商品结构。

还剩一个常见误解：响应里的 TaskView.aspectRatio 回显的是你提交的原始值，不保证直接告诉你后台最终映射到哪一个高清档。要做可观测性，至少记录 quality、原始 aspectRatio、首图 URL 的脱敏标识、外层 code 与 message。

也别把整张请求体连同密钥写进日志。排障证据够用即可，凭证不该陪着错误栈到处跑。