ChatGPT 只回复 Got it 怎么办：从入口、请求到账号逐项排查

打开对话窗口，输入任何问题，得到的永远是同一句 "Got it! How can I assist you today?"。换模型、重开对话、刷新页面都不管用，唯独自己建的自定义 GPT 还能正常回答。这种「模型像被换成了一个只会打招呼的机器人」的现象，看起来玄乎，实际排查路径相当固定：先确认入口，再确认请求，最后才轮到账号。

下面按可能性从高到低排列，每一步都给出可验证的动作，而不是猜测。

先分清三种截然不同的故障面

同一句「Got it」，可能来自三个完全不同的层次：

• 入口层：你打开的并不是官方站点，而是镜像站、聚合站或套壳页面，后端只用了一个很小的模型，或者干脆把请求截断后再转发。
• 请求层：真正发给模型的 messages 里，用户消息是空的、被覆盖了，或者格式不符合接口要求，模型只收到一句系统提示，于是礼貌地回一句「收到，有什么可以帮您」。
• 账号/会话层：网页端这条会话被路由到了能力受限的后端，或者被自定义指令、记忆内容带偏。

「只有自定义 GPT 正常」这个细节很关键：自定义 GPT 走的是另一套配置路径，指令和参数都独立，如果它正常而默认对话不正常，说明问题大概率出在默认会话的请求构造或账号状态上，而不是整个服务不可用。

第一步：确认你打开的是不是官方入口

这是最容易被忽略、也最容易被骗的一环。搜索「ChatGPT」时排在前面的结果里，长期混着大量非官方页面。它们的典型特征：

• 域名与官方域名有明显差异，靠拼写相似或加前后缀混淆；
• 打开就要求你输入账号密码，甚至要求输入 API Key；
• 页面上没有官方的状态页入口、没有正常的订阅管理页面；
• 切换模型的下拉框只是个装饰，选什么都回一样的内容。

排查动作：核对地址栏域名，检查证书颁发对象，从官方公告或官方帮助中心反查入口地址，而不要从搜索结果直接点进去。

风险提示：不要在来路不明的页面里输入账号密码或 API Key，这类页面记录凭证和对话内容是常态。如果你的账号已在可疑页面登录过，尽快在官方渠道修改密码、撤销可疑会话与 API Key。

另外要说明一点：某些说法建议通过「换区」「买号」「共享号」来绕开限制，这类做法不要碰。共享账号意味着别人能看到你的全部对话，买卖账号违反服务条款，随时可能被收回；账号一旦被判定异常，损失的远不止订阅费。合规做法只有一个——用自己的账号走官方支持渠道。

第二步：怀疑请求里根本没有用户消息

如果是自建客户端、脚本或第三方工具在调用，这是最高频的原因。模型只看到一条「你是 ChatGPT」的设定，没看到任何用户输入，自然只回一句确认语。常见写法错误包括：

• messages 数组最后一条是 assistant 而不是 user；
• 把上一轮的空回复一起带上，覆盖掉了本轮问题；
• content 用了数组结构，但字段名或类型写错，服务端解析成空字符串；
• 多轮拼接时把系统提示反复追加成用户消息；
• 用了中转服务，中转层把请求体改写后丢掉了用户内容。

最小验证请求（把模型名替换成你自己在用的那个）：

curl https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "<你的模型名>",
    "messages": [{"role": "user", "content": "1+1 等于几"}]
  }'

如果这条命令能正常回答，说明问题在你自己的客户端代码或中转层，而不在账号。接着做两件事：

1. 在发请求前打印完整的请求体，确认 messages 里确实有一条非空的 user 内容；
2. 把客户端发出的原始请求与上面手写的请求逐字段对比，重点看 messages、content 类型、是否有多余的 system 覆盖。

顺带提醒：第三方中转站为了省成本，可能把请求转发给更便宜的模型，或者对长上下文做截断。如果你无法查看中转层的实际请求，就别在上面投入太多时间，直接换回官方接口做对照测试。

第三步：清掉自定义指令与记忆

网页端有两处内容会在你不知情时被注入每次对话：自定义指令（Custom Instructions）和记忆。它们本来是提升体验的功能，但写错了会直接毁掉回答。例如指令里写了「每次回答前先确认已收到问题」「先复述我的需求再作答」，模型就可能只输出一句确认语；记忆里残留的旧项目背景，也可能让它误判当前对话已经结束。

操作清单：

• 清空自定义指令的两个输入框，保存；
• 关闭记忆功能，或在设置里删除已有的记忆条目；
• 新建一个全新对话（不要在旧会话里继续）；
• 发一条极短的问题做对照，例如「1+1 等于几」。

如果清空后恢复正常，就说明是指令污染，回头一条条加回去，找出触发的那句即可。

第四步：浏览器与会话层面的干扰

如果入口确认是官方、请求也确认正常，接下来排除本地因素：

• 用无痕窗口打开，禁用全部扩展再试；翻译类、提示词注入类、侧边栏类扩展都可能改写页面上的输入内容；
• 清理该站点的 Cookie 与本地存储后重新登录；
• 换一个网络环境做对照（例如手机热点），观察是否只在特定网络下复现；
• 换官方移动端或桌面端 App 做对照，如果 App 正常而浏览器异常，问题基本锁定在浏览器侧。

有些用户观察到网页端会随着使用情况变化出现回答变敷衍、拒答增多、模板化回复的现象，并把它称为「被降级」。这类说法目前只能算经验总结，具体机制没有公开说明，不建议当成定论。能确认的只有现象本身，因此处理方式应该是：先用同一账号在官方 App 和官方网页做交叉验证，如果两端表现一致，再通过官方帮助中心或支持渠道反馈，附上时间、模型、复现步骤和截图。

一套可以直接照着走的排查顺序

什么时候值得换一个运行环境

绝大多数情况下，这句「Got it」跟你的电脑性能、网络带宽没有关系，换设备、换机器都解决不了账号侧的问题。只有一类场景例外：你需要长时间挂着命令行 AI 工具或常驻任务，本机不能长期开机、出口网络不稳定导致会话频繁中断，这时把任务放到一台长期在线的远程机器上跑，会比反复重连省心。像整机放在新加坡机房的独享远程 Mac 这类按月租用的方案，可以作为一个可选项来评估——但要清楚它只解决「机器和网络是否稳定在线」，不解决入口真伪和账号状态。

小结

先别急着归因于「模型变笨」。按入口真伪、请求完整性、指令污染、账号会话这个顺序排查，大部分情况在前三步就能定位。自定义 GPT 正常而默认对话异常，是一个很有价值的线索：它说明服务本身没挂，问题出在默认会话的构造或账号状态上。最后提醒一句，涉及账号的一切操作都走官方渠道；共享账号、买卖账号、绕开地区限制这类做法带来的凭证泄露和封号风险，远高于省下的那点成本。具体功能与政策以官方最新说明为准。