先找出文字在哪一步丢了
接口已经返回 JSON，聊天界面却是空白；或者代码读取回复时得到 undefined。排查 AIGoCode API 回复解析时，先把一次调用分成三段看：收到响应、从响应中取出文字、把文字交给界面。只看最后的空白页面，无法区分是哪一段出了问题。
本文针对 AIGoCode 第一次请求中的普通 JSON 响应样例，帮助你核对文字字段和应用自己的解析逻辑。流式数据和工具调用结果需要各自的处理规则，不在这张字段对照表的范围内。
一、先确认拿到的是成功响应
能转换成 JSON，只说明响应体可以被解析。先记录 HTTP 状态码，再检查响应体是否包含错误信息。官方错误码说明也采用这个排查顺序。
首次请求文档中的 Claude Messages 和 Gemini Node.js 示例，会检查 response.ok，失败时抛出响应体里的信息。你的应用也应保留明确的失败分支，避免让错误对象继续进入“提取模型回复”的逻辑，最后变成没有解释的空白气泡。
这一步只需要回答：本次请求返回了什么状态，拿到的是哪一类对象。如果仍在报接口错误，先按错误信息处理；成功响应结构已经确认后，再检查下面的文字路径。
二、按实际接口核对文字路径
AIGoCode 文档分别展示了 OpenAI Compatible、Claude Messages 和 Gemini generateContent 的成功响应。下表中的路径对应这些文档样例，不代表任何一次响应都一定有第一个候选、第一块内容或非空文字。
| 本次调用的接口 | 官方样例中的文字位置 | 先检查什么 |
|---|---|---|
| OpenAI Compatible 聊天请求 | choices[0].message.content | 是否有 choices 数组，以及其中的 message |
| Claude Messages | content[0].text，样例中的该块为 type: text | 顶层 content 是否为数组，块的类型和文字字段是什么 |
| Gemini generateContent | candidates[0].content.parts[0].text | 是否有 candidates，选中候选后再检查它的 content.parts |
具体字段可以对照首次请求文档的成功响应。例如，Claude 样例的顶层 content 是内容块数组；Gemini 样例则先进入 candidates，再进入某个候选的 content.parts。把读取 choices[0].message.content 的代码原样用到这两个样例上，就找不到同一路径。
这里的 content 虽然名字相同，所处位置和数据类型却不同。看到这个字段名时，继续核对它属于哪个对象、里面是字符串还是数组，不要仅凭同名就共用一段取值逻辑。
修改解析器时，建议明确传入本次所用的协议，让每个分支检查自己需要的结构。不要用连续尝试多个路径的方式掩盖协议不匹配：最后即使取到了某个值，也未必能解释应用究竟收到什么。
三、区分字段缺失、没有文字和界面没显示
下面是一张用于应用排查的判断表。它描述的是你在程序里应该区分的状态，不是 AIGoCode 新增的接口返回码。
| 你实际观察到的结果 | 可以定位到哪一步 | 下一步检查 |
|---|---|---|
| 返回的是错误响应 | 还没进入正常回复读取 | 保留状态码和脱敏后的错误信息，按错误文档处理 |
| 已识别协议，但预期的数组或对象不存在 | 解析器与实际响应结构不匹配 | 对照原始 JSON 的字段层级，确认有没有多读或少读一层 |
| 对应数组存在，但没有找到预期文字字段 | 目前不能提取出这类文字 | 查看数组内容及字段类型，保留“未找到文字”的状态，不直接断定模型故障 |
| 已得到非空字符串，界面仍为空 | 文字已经通过解析这一步 | 继续检查返回给页面的字段、状态赋值和渲染条件 |
对 Claude 样例，可以先检查内容块类型，再读取其中的文字；对 Gemini 样例，可以先选择要处理的候选，再检查其 parts。如果你的应用只展示普通文字，就把它支持的内容类型写清楚，遇到不支持的结构时给出明确提示。不要把所有缺失字段都默认替换成空字符串，因为这会让结构错误与正常展示混在一起。
也不要直接把“样例中第一个元素有文字”变成长期规则。数组是否为空、目标字段是否存在、字段是否为字符串，都应在读取前确认；需要怎样处理多个元素，则由实际响应和应用要展示的内容决定。
四、用固定样本验证解析，再回到真实调用
与其一边修改解析器、一边反复发送新请求，可以先准备几份本地响应样本，让同一份数据经过修改前后的处理逻辑。
建议至少覆盖四种情形：
- 三种文档成功样例各一份，用于确认协议分支和文字路径。文档中的占位值需要换成合法 JSON 值，文字可换成不含个人信息的测试句。
- 一份应用能识别的错误响应，确认它进入失败提示，而不是成功回复区域。
- 一份人为构造的缺少目标字段或空数组的样本，确认解析器会报告状态，不因直接读取下标而中断。
- 一份能提取出固定测试文字的样本，继续送到界面，确认显示内容和解析结果一致。
第三项是给自己程序做的边界测试，不表示平台一定会返回这种结构。样本检查通过后，再用你实际选择的接口做一次最小调用，验证当前请求、解析分支和界面能够衔接起来。
排查记录可以保留接口类型、脱敏后的路径、HTTP 状态码、顶层字段名、数组长度，以及是否提取到文字。不需要把真实 API Key、完整认证头或用户对话贴进日志；地址里如果带有 key 参数，也应一并遮蔽。
什么时候转去检查工具接入
这篇文章解决的是“应用怎样从响应中拿到并显示文字”。如果你的直接 API 请求已能输出回复，但 Claude Code 或 Codex 仍连接失败，继续看API 测试成功，Claude Code / Codex 仍连接失败？按四步核对接入。那篇文章检查的是工具配置、密钥分组和接入状态。
完成本轮排查时，留下三项结果即可：实际使用的接口、从响应中提取出的测试文字，以及界面最终显示的内容。三项对应起来，才算验证了这段回复处理逻辑。