AIGoCode 最小请求成功后：给业务脚本留一份回归检查基线

把第一次成功请求留成可复查的起点

AIGoCode 的问候语请求已经能收到回复，接着把它放进业务脚本，加入文件读取、历史消息和界面展示，结果却不对了。此时最有用的对照，是那份仍能单独运行的最小请求。

本文给出一套手动回归检查方法：在同一协议、同一运行环境中，区分“原始样例”和“业务版本”，逐步寻找首次出现差异的位置。这是组织排查的建议，不是 AIGoCode 提供的自动测试功能，也不代表本文执行过真实模型调用。

先固定一条协议的样例

官方第一次请求分别提供 OpenAI Compatible、Claude Messages 和 Gemini generateContent 的最小请求。先选业务准备使用的那一种，保留对应的地址、认证方式、请求结构和响应示例。

例如 OpenAI Compatible 的原文示例使用 /v1/chat/completions，请求体包含 model 和 messages；Claude Messages 示例使用 /v1/messages，同时给出 max_tokens；Gemini 示例使用 contents。这些差异意味着，回归时不能一边换协议，一边修改输入，还把结果当成同一条请求的前后对照。

模型名沿用你已核实可用的配置。文档中的示例名称只作为样例理解，不据此推断当前账号对所有模型都有权限。

为原始样例留一张脱敏记录

建议保留一份只含占位符的样例代码，真实 Key 继续按官方说明保存在本地环境变量中。另记一张对照表，避免把“上次好像能用”当作可复查记录。

这张表是自己的排查笔记，不是平台日志字段说明。不要记录完整认证头；Gemini 示例地址通过查询参数传 Key，复制请求 URL 时也要先去掉密钥值。输入和返回内容涉及业务资料时同样需要脱敏。

分三次把业务逻辑接回来

第一步只替换一条简短输入。保持接口、认证、模型和其余参数不变，确认请求能否得到可识别的响应。若这一步已经失败，先核对实际序列化后的结构，不要继续堆入整份文件或历史对话。具体输入字段可以对照本站的请求体修改指南。

第二步加入业务取数，但仍使用简短内容。让脚本从实际的输入位置取到文本，再把这段文本交给原来的请求逻辑。这一步的目标是比较“手写字符串”和“业务代码取得的字符串”，而不是检验大输入容量。

第三步恢复响应处理和界面展示。先在本地检查脱敏后的响应结构，再检查从中取出的文字，最后看界面拿到的值。官方 OpenAI Compatible 说明明确指出 choices[0].message.content 是回复内容；其他协议应对照各自样例，不能沿用这个路径。解析细节可继续看三种响应结构怎么读。

每完成一步留一条结果。若本轮同时更换依赖、修改模型、改输入和换解析方法，即使最终恢复，也很难知道是哪项起了作用。

失败时回跑基线，再解释差异

如果业务版本失败，先在相同环境下单独运行保留的最小样例。两种结果对应不同的下一步：

• 最小样例也失败：记录这次的状态码和错误信息，先排查两者共有的配置或外部条件。不能仅凭此断言是服务端故障。
• 最小样例成功、业务版本失败：对照最近一次改动，检查实际请求内容与解析过程。它提示值得缩小差异，但尚不能证明唯一根因。
• 两者都有响应、只有界面空白：把收到响应、提取文字、显示文字三个阶段分别检查。

不要为了验证基线而无限重发。出现错误后，先按实际错误选择方向；若报错与并发有关，反复并行运行两份脚本只会增加排查变量。

结束条件是业务版本通过自己的检查

问候语能成功，只说明那次最小调用得到结果。业务版本还需要检查真实取数路径、响应解析和展示结果。完成后，把本轮确认有效的改动合回业务代码，继续保留不含凭据的基线样例，供下次升级依赖或搬迁环境时使用。

如果问题发生在 Claude Code 或 Codex 等另一款工具中，应回到该工具验证；本站已有API 成功但工具仍连接失败的核对流程。不要用脚本的成功替代目标工具的接入验收。