同一段业务输入，迁移时要检查四处代码
已有脚本通过 AIGoCode 的 Chat Completions 返回文字，现在希望改用 Responses，最容易漏掉的是请求体和响应处理。官方 OpenAI Compatible 文档 同时展示了这两个接口：前者使用 messages，后者使用 input，返回文字所在的结构也不同。
可以把这次改动分成四项：请求入口、输入封装、文字读取、用量记录。本文只对照官方展示的单轮文本 JSON 示例，帮助你迁移一个最小调用。它不验证流式输出、多轮状态保存或工具调用，也不意味着换到 Responses 就能获得更好的回答或更低的费用。
一、先确定改的是 SDK 方法还是完整 HTTP 地址
文档要求使用支持第三方调用的 OpenAI / Codex 分组 API Key。两个示例的 OpenAI SDK baseURL 都是 https://api.aigocode.dev/v1；直接发送 HTTP 请求时，完整端点分别为：
| 调用方式 | Chat Completions | Responses |
|---|---|---|
| 完整 HTTP 地址 | POST https://api.aigocode.dev/v1/chat/completions | POST https://api.aigocode.dev/v1/responses |
| Node.js SDK 方法 | client.chat.completions.create(...) | client.responses.create(...) |
SDK 的 baseURL | https://api.aigocode.dev/v1 | https://api.aigocode.dev/v1 |
若你使用 SDK，按文档改变调用方法，baseURL 继续填写上表中的根地址；不要把完整 /responses 端点填进 baseURL 来代替方法切换。若你自己发送 HTTP，则检查实际请求的完整地址和 POST 方法。两种写法都应与当前采用的文档示例一致。
官方示例通过环境变量 AIGOCODE_API_KEY 提供密钥，HTTP 请求头为 Authorization: Bearer YOUR_API_KEY。Node.js 文本示例需先安装 openai，保存为 .mjs 文件后运行。迁移期间建议保留原脚本副本，避免把 SDK 接口切换和业务逻辑改写混成一次难以定位的变更。
二、把最小输入改为 input，不原封不动搬 messages
官方 Chat Completions 示例把问候语放在 messages 数组中，消息包含 role: "user" 和 content。Responses 示例则把同一条问候语直接交给字符串字段 input。两份请求示例的 model 都是 gpt-6-astra。
先用相同的简短测试句对照这两种封装，暂时不加入自己的长提示词或其他可选参数。这样，如果迁移后没有拿到预期结构，可以先检查地址与基础请求体，而不是同时猜测多个新增参数是否适配。
这里展示的是单轮最小请求的改法，并不是把任何历史消息数组都机械转换成一个字符串的规则。如果业务依赖复杂上下文或额外能力，需要进一步查验相应文档及实际支持范围；仅凭这一页的最小示例，不能确认所有原参数都可以照搬。
三、为 Responses 建立对应的文字读取分支
Chat Completions 的示例文字位于 choices[0].message.content。Responses 的示例中，顶层 output 是数组，里面的消息项包含 content 数组，文字块的 type 为 output_text，具体内容在该块的 text 字段。
因此，若请求已经改为 Responses，而应用仍只读取 choices，原解析器就与这份示例结构对不上。检查时先打印脱敏后的字段结构，再沿 output、消息项、content、output_text 文字块逐层核对。不要只把“取不到旧字段”转换成空字符串，否则页面空白时很难发现接口分支用错。
建议在你自己的程序中明确标注使用的是哪种接口，并为相应结构建立处理分支。字段是否存在、数组是否为空、内容块是否有文字，都属于应用需要检查的条件。官方样例展示了一个消息和一段文字，不应被扩展成“所有返回永远只有第一项”的承诺。
如果当前业务仍使用 Claude 或 Gemini 的普通 JSON 示例，可以另看 三种文字响应结构怎么读。迁移到 Responses 时，应以本页列出的新结构核对解析器。
四、连同用量和时间字段一起检查
迁移可能在界面显示正常后仍留下统计遗漏。官方给出的两份响应样例，在下列字段上也有区别：
| 记录项 | Chat Completions 示例 | Responses 示例 |
|---|---|---|
顶层 object | chat.completion | response |
| 时间字段 | created | created_at |
| 输入 token 字段 | usage.prompt_tokens | usage.input_tokens |
| 输出 token 字段 | usage.completion_tokens | usage.output_tokens |
| 总 token 字段 | usage.total_tokens | usage.total_tokens |
若日志、监控或用量面板依赖旧字段名，也要检查相应映射。这个表只是字段对照，不能据此断言两种接口的计费完全相同。文档明确说明响应里的 ID、时间和用量使用占位符，xx 不是可用于计算费用的实际数值。
给迁移保留一份可复查的记录
先用合法的本地 JSON 样本核对解析和字段映射，文档占位符需要换成合法测试值。然后再用自己的账号执行最小请求，分别记录实际接口、输入封装、提取到的文字和用量字段是否存在；不要要求两次模型回复逐字相同来判断迁移成败。
可以沿用 最小请求回归基线 的记录方式，给旧版和新版脚本分别保留一份结果。确认这些环节接通后，再逐步恢复业务参数。这样发现异常时，能定位到具体改动，而不必同时重换密钥、模型和接口。