收到 JSON 后，图片还没有自动保存到电脑
调用 AIGoCode 图片生成接口后，终端出现很长的 JSON，却没有弹出图片，先检查返回数据的形态。官方 OpenAI Compatible 文档 的图片示例返回 b64_json，并用 Node.js 把它写成 PNG 文件。对于这套示例，收到响应、解码图片、保存文件是三个需要分别确认的步骤。
本文围绕这个落盘任务展开：先核对请求，再找到图片数据，最后检查输出文件与实际尺寸。文中的模型和字段来自官方示例，不代表每个账号都能使用所有图片模型，也没有对你的账号进行实际调用测试。
第一步：确认发往图片接口，参数和输出格式相互对应
官方列出的完整图片请求地址是 POST https://api.aigocode.dev/v1/images/generations，请求头使用 Authorization: Bearer YOUR_API_KEY。文档要求使用支持第三方调用的 OpenAI / Codex 分组 API Key，并通过环境变量 AIGOCODE_API_KEY 传入示例。
检查旧脚本时，先找到实际发请求的那一行。如果仍指向 chat/completions，就还不是这份图片生成示例对应的调用路径。图片示例的请求参数可以按下面逐项对照：
| 字段 | 官方示例值 | 对照重点 |
|---|---|---|
model | gpt-image-2.5-flare | 复制完整模型 ID，再核对自己的可用范围 |
prompt | 白色背景上的一个蓝色圆形，极简图标。 | 首次接入可用这种简单画面检查数据处理流程 |
size | 1024x1024 | 这是请求值，保存后还要核对实际图片 |
n | 1 | 先按单张结果验证保存过程 |
quality | low | 这是示例设置，不据此推算价格或承诺效果 |
output_format | png | 本文后续按 PNG 文件处理 |
文档明确说明，当前 GPT 图片模型使用 output_format: "png"，返回图片的 b64_json，无需设置 response_format。排查时先对齐这一套已展示的参数，不要把另一份教程里的输出选项混进来。
第二步：检查 HTTP 状态，再从 data 里提取图片
官方 Node.js 图片示例使用内置 fetch。它先检查 response.ok，失败时读取错误文本；只有成功响应才调用 response.json()。这一步能把接口失败和后续图片保存问题分开。
解析成功后，示例从 result.data?.[0]?.b64_json 取得第一张图片的 Base64 字符串。如果这个字段不存在，示例抛出 No image returned，而不是继续写一个空文件。因此，终端能打印出 JSON，并不足以确认已经取得图片数据。
拿到数据后，示例通过 Buffer.from(imageBase64, "base64") 解码，再用 writeFile 保存为 aigocode-image.png。不要直接把整份 JSON 文本改成 .png 后缀；真正写入图片文件的是解码后的字节。
排查可以按三个检查点记录：HTTP 是否成功、b64_json 是否存在、写文件是否报错。若前两项都通过，下一步就检查文件写入路径和打开结果，不必立即重新发送生成请求。官方示例打印其余响应信息时，也把完整 Base64 替换成“已保存至 aigocode-image.png”，便于看清其他字段。
第三步：以实际输出尺寸安排后续裁切
不要在业务脚本中仅凭请求的 size 就认定输出尺寸。官方页面给出的示例请求为 1024x1024，响应中却展示 1254x1254，并明确说明当前服务可能调整输出尺寸，应以响应和图片实际尺寸为准。
这两个数是文档中的示例，不是固定换算关系。给文章封面、商品图或页面素材接入这一步时，建议先保存原始输出，再读取实际尺寸，最后根据目标版式决定是否缩放或裁切。这样才能区分“接口生成了什么”和“你的后处理改成了什么”。
同样，响应示例里的 BASE64_IMAGE_DATA、xx 和占位 ID 只是结构说明，不能当成真实图片或用量。核对消耗时，应查看自己的实际记录；相关思路见 一次任务的用量核对。
用这份检查单结束一次接入验证
一次保存流程完成后，逐项确认：请求走的是图片端点；返回成功且能找到 b64_json；写入的是解码字节；PNG 能打开；响应尺寸与文件实际尺寸已核对。若需要继续排错，保留错误文本和必要的响应字段，分享前去掉真实 API Key。
如果遇到的是文字 API 返回后界面空白，可以转看 三种文字响应结构的读取方法。图片输出应沿“图片字段—解码—文件—尺寸”这条路径逐步确认。