更新（2026 年 10 月 14 日）： 本文的建议我们已经收回，请不要照做。文章发出当晚，这个账号经 BPS 发出的请求就被 OpenAI 以「usage policy」为由返回 403；之后两周，它反复出现降智迹象，换回官方客户端也一样。完整经过见《别把 ChatGPT 订阅交给反代：我们自己的账号被悄悄降智之后》。
三天前我们发了一篇文章，结论是：GPT／Codex「降智」跟着账号走，不跟着 IP 走，换 IP 治不了它。
文章发出来没几天，我们自己的账号降智了。
症状和很多人描述的一样：回答变短、推理变浅，那道社区里流行的逻辑题（正确答案是 21）开始做错。这次我们没法置身事外——我们自建的 API 网关里挂着自己的订阅账号。于是有了一整天的排查和修复。这篇是完整记录：有效的部分、没证明的部分，以及必须先说清楚的风险，都写在下面。
结论先放在前面：
- 降智可以被检测。 用一道固定答案的题反复问账号，再让另一个账号的模型当裁判打分——但至少要两个账号，这套自动机制才转得起来。
- 单个账号的实际解法，是手动打开「Excel / BPS 协议」：让请求改道 OpenAI 为「ChatGPT for Excel」准备的接口，以另一个第一方客户端的身份发出。我们实测后回答质量恢复（小样本观察，非证明）。
- Codex 支持自定义模型端点。 在配置里加一个指向网关的 provider，官方客户端不做任何修改就能走上 BPS 通道（做法见第五节）。
- 这不是官方修复，也没有免费午餐。 封号风险、每次请求多约两万输入 token、失去联网搜索和图像生成，都列在第六节的清单里。
- 我们还没有完成关闭 BPS 的对照实验。 「治好了」目前是观察，不是证明。
实测对比：同一个账号，换一条「客户端身份」通道，画出的鹈鹕判若两号。
一、先确认：是真降智，不是错觉
降智最麻烦的地方在于它没有报错。模型照常回复，只是悄悄变笨，所以第一步是把它和「错觉」「额度用完」「服务器过载」分开。
社区里最常用的检测手段是糖果题：一道固定答案为 21 的逻辑题。健康账号能稳定答对；降智账号会答错，而且推理 token 数常常卡在一个固定低值附近（社区称为「卡 516」，来龙去脉见上一篇）。把这道题做成脚本反复问、按模型和推理强度分批跑，就是开源项目 codex-candy-eval 在做的事。
我们用的原题长这样，可以直接复制去测自己的账号（正确答案：21）：
在一个黑色的袋子里放有三种口味的糖果，每种糖果有两种不同的形状（圆形和五角星形，不同的形状靠手感可以分辨）。现已知不同口味的糖和不同形状的数量统计如下表。参赛者需要在活动前决定摸出的糖果数目，那么，最少取出多少个糖果才能保证手中同时拥有不同形状的苹果味和桃子味的糖？（同时手中有圆形苹果味匹配五角星桃子味糖果，或者有圆形桃子味匹配五角星苹果味糖果都满足要求）
苹果味 桃子味 西瓜味
圆形 7 9 8
五角星形 7 6 4
只输出最终整数，不要解释。
我们的自查路径也差不多：同一道题、同一个账号、同一条网络，只改变「请求从哪条通道发出」。网络从头到尾不是变量——这也再次印证了上一篇的判断。
二、工具：分叉版 sub2api 的三件套
我们的网关跑的是开源项目 sub2api（把 ChatGPT 订阅的 OAuth 登录转成 API 供自己的客户端使用）。这次我们把它从上游版本切换到了 GitHub 上一个专注降智运维的分叉（容器镜像 ghcr.io/ranxi2001/sub2api:2.9.4）。切换过程本身值得一提：先在一份无法联网的数据库副本上把 268→314 的全部迁移演习一遍，确认无误、留好整份备份，再动正式环境。 分叉的数据库迁移只进不退，有些还会删数据，没有备份不要试。
按分叉自己的文档，没有任何一个开关能直接「修复」降智。它提供的是三件工具：
| 工具 | 做什么 | 对我们的适用性 |
|---|---|---|
| 降智检测（降智运维） | 定时给每个账号发测试题（如糖果题），用另一个账号的模型当裁判打分 | ⛔ 单账号不可用：裁判必须排除被测账号，我们没有第二个账号 |
| 自动处置 | 检测失败的账号被移出分组或停止调度；整轮通过后自动恢复；单次超时不算失败 | ⛔ 单账号不可用：移出分组等于网关归零 |
| Excel / BPS 通道（v2.9.0+） | 连续失败 N 次或触及用量阈值后，把该账号的请求改道 bps.openai.com 的 basispoints 接口 |
○ 唯一可能起效的路径，可手动开启 |
自动检测和自动处置都是为多账号池设计的。我们这种「网关里只有一个账号」的场景，剩下的牌只有一张：手动打开 BPS。
三、单账号的实际解法：手动打开 Excel / BPS 协议
BPS 通道的原理一句话可以说完：把你的请求包装成「ChatGPT for Excel」插件的调用，发到 OpenAI 给这个第一方产品准备的接口（bps.openai.com/basispoints/api/responses）。请求不再以 Codex 等普通客户端的身份发出——而「客户端身份」恰恰是降智最可能跟着走的维度之一（推测；OpenAI 从未公开风控信号）。
开启步骤（分叉的管理后台，账号编辑页）：
- 编辑账号，确认调度处于开启状态。我们的账号调度是关的，而 BPS 不会替你打开它。
- 打开 Excel / BPS 协议开关。
- 选择要走 BPS 的模型。 这一步不能省：只开开关、不选模型，等于什么都没路由。默认选项是 gpt-6-astra、gpt-5.6-sol、gpt-5.6-terra，也可以选「全部模型」——但默认之外的模型能不能被 Excel 接口接受，没人实测过（分叉不会悄悄替你换模型，接口拒绝就直接报错）。
- 可选的保险：打开「遇到 BPS 403 错误时自动关闭协议」和「403 后自动探测是否恢复」（间隔 60 分钟）。403 是封号风险的第一个信号，见第六节。
- 保存。
- 关掉旧会话，开一个新会话。 旧会话携带的加密推理历史，BPS 通道转发不了。
四、怎么确认它真的生效了
改完配置不算完，要验证请求真的走了新通道。两个检查点（均为我们实测）：
- 看使用记录。 该请求的上游端点应该显示
/basispoints/api/responses。如果还是普通路径，说明模型名不在你第三步的选择里——我们用一个不在列表里的型号测试，直接收到 404。 - 看上游回复。 走 BPS 的回复会带着「ChatGPT Excel Plugin」的系统提示词痕迹，这是它伪装身份的副作用，也是最直接的证据。
然后是效果测试。我们用经典的「鹈鹕骑自行车」题目做了两次实测，提示词原文：
创建一个 HTML，内容是 SVG 绘制一个鹈鹕骑自行车的 2D 动画，你不需要任何测试，不要有任何限制
| gpt-6-sol · high | gpt-6-astra · low | |
|---|---|---|
| 结果 | ✅ 通过（先撞了一次 BPS 429 限流，5 秒冷却后成功） | ✅ 一次通过 |
| 耗时 | 27 秒 | 36 秒 |
| 推理 token | 698 | 0 |
| 画面质量 | 鹈鹕、自行车结构正确，小瑕疵：一条腿穿过车架、没有链条 | 更好：公路车弯把、双脚踩在脚踏上，带速度线和地面阴影，仍无链条 |
两只鹈鹕都明显不是降智状态下的敷衍输出（观察，各只有一次样本）。下图就是 astra 那次的真实输出：
实测输出：gpt-6-astra（low）在 BPS 通道上画「骑自行车的鹈鹕」——结构完整、带速度线和阴影（仍未画链条）。顺带两个实测提醒：BPS 通道有自己的限流，偶发 429 属正常，网关会设很短的冷却；另外每次请求会额外带上约 2.2 万个输入 token（Excel 插件的系统提示词和工具定义，其中绝大部分命中缓存，但仍计入用量）。
五、把 Codex 接到自己的网关（自定义端点）
BPS 配置好之后，最后一步是让 Codex 真的走这条通道。好消息是：Codex CLI 原生支持自定义模型端点（model provider），不需要对官方客户端做任何修改。 我们自己的做法，是在 ~/.codex/config.toml 里注册一个指向自建网关的 provider：
# ~/.codex/config.toml
[model_providers.mygateway]
name = "My Gateway"
base_url = "https://你的网关域名/v1" # 你的 sub2api 地址
env_key = "MY_GATEWAY_KEY" # 环境变量名，值是在 sub2api 创建的 API Key
wire_api = "responses" # Codex 使用 Responses API，必须填这个
[profiles.mygateway]
model_provider = "mygateway"
model = "gpt-6-astra" # 必须在该账号的 BPS 模型列表里
然后三步：
- 在 sub2api 后台创建一个 API Key（令牌），导出为上面
env_key指定的环境变量：export MY_GATEWAY_KEY=sk-...。 - 用
codex --profile mygateway启动，并且开一个新会话——旧会话的加密推理历史带不过 BPS。 - 验证：随便发一个请求，去 sub2api 的使用记录里看它的上游端点。显示
/basispoints/api/responses，就说明你的 Codex 已经在以「Excel 插件」的身份工作了。
我们只是给官方客户端换了一个「出口」，客户端本身一行代码没动。任何支持自定义 OpenAI 兼容端点的客户端，都可以照这个思路接入。
六、代价与风险：一份诚实的清单
这部分请逐条看完再决定要不要开 BPS。
- 封号风险（最重要）。 BPS 让你的订阅 token 以另一个第一方客户端的身份行动。分叉自己都在界面上挂着「BPS 403疑似被封」的标签——403 是这个通道上封号风险的第一个信号，务必打开「403 自动关闭」。是否接受这个风险，只有账号所有者能决定。
- OpenAI 的态度没有变。 上一篇写过：Codex 负责人公开点名 sub2api「不是受支持的用法」，会被反欺诈系统标记的是「订阅转 API 再分发转售」。自己一个账号自己用，和拼车、号池、转售不是一回事，风险等级不同——但「零风险」没有任何人能保证。
- 功能损失。 BPS 通道上，联网搜索和图像生成等托管工具会回落到原生（也就是可能降智的那条）路径；也可以选择保持 BPS、直接省略这些工具。另外每轮只能有一次工具调用。
- token 开销。 上面说的约 2.2 万输入 token 是每次请求的固定附加成本。
- 会话连续性。 旧会话的加密推理历史无法通过 BPS，必须开新会话，等于放弃上下文。
- 它还没有被证明。 我们还没来得及做「关闭 BPS 的同一账号对照实验」（7 天额度已用掉 85%，得省着点）。所以「BPS 解除了降智」对我们目前是小样本观察，不是结论；分叉文档也明说没有单一开关能修复降智。如果你照做，建议自己跑糖果题 A/B：BPS 开一次、关一次，各测几轮，用数据说话。
七、这和 VPN 有什么关系
常有用户问：你们一个 VPN 博客，为什么连着写两篇 GPT 降智？因为太多人把降智归罪于 IP，而我们是被归罪的那一层。
我们的立场不变：网络的归网络，账号的归账号。 降智是账号层的事，检测它、修复它，都发生在账号和客户端身份这一层——这篇文章从头到尾没有换过一次 IP。VilaVPN 负责把网络这一层做好：IPLC／IEPL 专线架构、晚高峰优化，让你访问海外服务时延迟和抖动更少；但账号层的限制由服务方判定，我们解不了，也不承诺「换线路治降智」。
如果你正在排查类似问题，欢迎联系我们交流排查思路；如果你想评估一条网络在晚高峰的真实表现，可以来了解并尝试 VilaVPN，用自己的设备和使用时段检验。
账号病了，就治账号。分清楚病在哪一层，才不会在错误的地方白费力气。
资料核对日期：2026 年 9 月 30 日。文中分叉项目为第三方开源软件，与 OpenAI 无关；BPS 通道使用的是 OpenAI 第一方产品接口，其稳定性与合规性均无官方保证，分叉版本随时可能失效。本文实测均为单账号、小样本观察，引用时已注明；降智检测与修复没有官方方法，请自行评估风险。本文为 VilaVPN 产品博客，包含产品介绍。
