选择图片协议
本页介绍已确认的 OpenAI 兼容图片路径。某些模型使用 原生多模态协议，不能把两套字段混用。以下模型 ID 和文件路径都需替换为客户自己的值。
文本生成图片
POST /v1/images/generations，JSON 请求；鉴权使用 Bearer。
{
"model": "YOUR_IMAGE_MODEL_ID",
"prompt": "一只小猫坐在窗边，柔和的自然光",
"size": "1024x1024",
"n": 1,
"response_format": "b64_json"
}
curl --fail-with-body 'https://api.nailongapi.cc/v1/images/generations' \
-H "Authorization: Bearer ${NAILONG_API_KEY}" \
-H 'Content-Type: application/json' \
--data-binary @image-request.json
将上面的 JSON 保存为 image-request.json，并在确认模型支持参数后执行。执行会创建真实生成请求并可能收费。
| 字段 | 说明 |
|---|---|
model |
当前 Key 有权限的精确图片模型 ID |
prompt |
图片提示词 |
size |
当前模型接受的像素尺寸或枚举；不要仅凭名称推断 |
n |
生成数量，受模型限制与计费约束 |
response_format |
按当前协议选择；不能假定所有模型接受或遵从此字段 |
解析结果
常见结果为 data 数组，每项含 b64_json 或 url。以下是结构示意，Base64 并非有效图片：
{
"data": [
{"b64_json": "BASE64_IMAGE_BYTES"}
]
}
读取实际返回：有 Base64 时解码为真实字节；有 URL 时根据该 URL 的访问要求下载。不要因为请求了 response_format=url 就只解析 URL。未知结构应报出脱敏后的协议错误，不把空结果当成成功。
参考图片与编辑
历史确认的兼容入口为 POST /v1/images/edits/（含尾斜线），使用 multipart/form-data。让 HTTP 库生成 boundary，不能把 JSON 请求直接改个路径冒充文件上传。
curl --fail-with-body 'https://api.nailongapi.cc/v1/images/edits/' \
-H "Authorization: Bearer ${NAILONG_API_KEY}" \
-F 'model=YOUR_IMAGE_MODEL_ID' \
-F 'prompt=保留第一张主体，参考第二张的构图' \
-F 'n=1' \
-F 'size=1024x1024' \
-F 'image[]=@reference-1.png' \
-F 'image[]=@reference-2.png'
该示例展示重复 image[] 文件字段，不代表任意模型支持两张参考图。单图、多图、蒙版和可选参数，均需按当前模型确认。执行同样可能收费。
比例与 4K
比例应从软件界面一直传到最终 API 字段，而不只是写进提示词或修改 UI 标签。
| 图片目标 | 特定兼容层历史采用的像素映射 |
|---|---|
| 4K / 1:1 | 4096x4096 |
| 4K / 9:16 | 2304x4096 |
| 4K / 16:9 | 4096x2304 |
这些是已核查兼容层的映射示例，不是所有图片模型的能力承诺。模型若只接受固定尺寸，按其枚举；不支持时明确提示，不静默降级成方图或低分辨率。视频不能套用这张表。
验证真实输出
HTTP 200 仅说明请求返回，不能证明图片数量、比例或原生分辨率正确。下载原始结果后用可靠图片解码器核对：格式、文件完整性、实际宽高、数量；不要用缩略图判断，不通过后期放大冒充原生 4K。