没有不值得去解决的问题,也没有不值得去学习的技术!

BeWild ChatGPT Plus 3 个月套餐第 3 个月续订再次失败:取消套餐后修复成功,菲律宾比索计价与 Codex 权益观察

【图4:BeWild 修复页面要求先取消官方逾期套餐,再重新获取 Session】

作者:

在

AI 订阅服务实测与观察系列

插图 19:ChatGPT Plus

(1) 中国大陆如何订阅 ChatGPT Plus(2026):WildCard、OneKey、Dupay、Wise 与 BeWild 实测对比

图6:BeWild“我的订阅”页面已经显示 ChatGPT 当前到期时间为 8 月 25 日。

(2) BeWild 3 个月 ChatGPT Plus 自动续订实测:第二个月成功续费,需要手动操作吗?

图 1:WildAI 检测到 ChatGPT Plus 订阅可能失效

(3) BeWild(WildAI)ChatGPT Plus 订阅修复实测:重新上传 Session 后显示成功

图 1:完成两次修复操作后,WildAI 的“修复订阅”窗口仍然继续弹出

(4) BeWild(WildAI)“修复订阅”反复弹出:ChatGPT Plus 正常时无需继续点击

【图 1:网友通过微信询问 Bewild 是否仍能正常使用】

(5) Bewild AI 订阅异常记录:自动续费失败、新订阅未生效与退款处理

图 3 :报价表中同时列出了 ChatGPT Plus 成品号、ChatGPT Plus 代充,以及 Gemini、Cursor、Grok、Claude 等其他 AI 服务的价格。

(6) 一次 ChatGPT Plus 第三方代充报价记录:200 元/月,与我正在使用的 BeWild 对比

【图 11:等待同步以后,ChatGPT Plus 已恢复,并显示 9 月 26 日自动续订】

(7) BeWild ChatGPT Plus 3 个月订单第 3 次续订实测:自动扣款失败、退款后重新订阅成功

图 3:BeWild 的“我的订阅”显示 ChatGPT 已于 9 月 26 日到期

(8) BeWild ChatGPT Plus 3 个月订单第 2 个月续订失败实测:修复订阅成功,Plus 权益延迟同步

【图7:对方谈到为什么会注意到我的博客,并评价博客“比较纯粹”】

(9) 写了一个 AI 订阅服务实测系列后,两家服务商主动找到了我:关于外链、软文与真实记录

【图4:BeWild 修复页面要求先取消官方逾期套餐,再重新获取 Session】

(10) BeWild ChatGPT Plus 3 个月套餐第 3 个月续订再次失败:取消套餐后修复成功,菲律宾比索计价与 Codex 权益观察

2026 年 10 月 29 日,我通过 BeWild 购买的 ChatGPT Plus 三个月套餐,终于完成了第三个月的续订修复。

不过,这次仍然不是正常自动续订成功。

和上个月一样,我再次遇到了月度付款失败的问题。而且这一次修复流程还增加了一个步骤:必须先进入 ChatGPT 官方取消原来的 Plus 套餐,再返回 BeWild 提交修复。

这让我有些不理解。

我已经提前购买了三个月服务,为什么后续每个月的续订,还需要用户自己关注和处理?

更麻烦的是,当时我还有 Codex 任务在执行。我担心取消 Plus 以后,正在运行的任务可能受到影响,所以还专门联系了客服。

好在最后修复成功了。

除此之外,这次还有两个值得记录的发现。

第一,OpenAI 的新账单再次使用了 PHP 982.14,也就是菲律宾比索。我越来越倾向于认为,BeWild 选择这种地区计价方式,可能与平台降低采购成本、提高利润空间有关。

第二,取消并重新订阅 Plus 以后,Codex 的五小时和每周额度最初仍保留原来的剩余额度,但随后又同时恢复到 100%,连下一次重置时间也发生了变化。这让我开始怀疑,重新订阅可能触发了额度的重新分配,只是没有立即显示。

本文继续记录这次实际经历,也谈谈我对这些现象的理解。

一、同一份三个月订单,后两个月都出现续订失败

先回顾一下这份订单的背景。

2026 年 8 月 26 日,我通过BeWild购买了一份 ChatGPT Plus 三个月套餐。

订单金额是 US$62.99。

这是我重新购买的一份订单。

因为更早的一份三个月套餐,在最后一个月遇到了付款方式失效的问题,BeWild 最终对没有完成的服务进行了退款,我才重新购买。

新订单的第一个月倒是比较顺利。

8 月 26 日,OpenAI 成功生成了 US$20.00 的已支付账单,ChatGPT Plus 正常开通。

但是第二个月就出现了问题。

9 月 26 日的自动续订没有完成,直到 9 月 28 日,我才通过 BeWild 的“修复订阅”功能恢复服务。

当时新的 OpenAI 账单使用了 PHP 982.14,下一次到期时间也更新到 10 月 28 日。

完整经历可以参考上一篇文章:

BeWild ChatGPT Plus 3 个月订单第 2 个月续订失败实测:修复订阅成功,Plus 权益延迟同步

在上一篇文章中,我还专门提出了一个问题:

到了 10 月 28 日,第三个月能不能正常自动续订?

现在答案已经出来了。

第三个月再次续订失败。

二、10 月 28 日到期,BeWild 和 OpenAI 都显示异常

10 月 29 日,我首先进入 BeWild 的“我的订单”页面。

原来 8 月 26 日购买的三个月订单仍然存在,金额还是 US$62.99。

订单右侧也能够看到“修复订阅”按钮。

【图1:BeWild 原三个月订单仍然存在,可以通过“修复订阅”处理续订异常】
【图1:BeWild 原三个月订单仍然存在,可以通过“修复订阅”处理续订异常】

再打开“我的订阅”。

这里已经明确显示 ChatGPT Plus:

已逾期。

到期日期为:

2026 年 10 月 28 日。

【图2:BeWild 显示 ChatGPT Plus 已于 2026 年 10 月 28 日到期】
【图2:BeWild 显示 ChatGPT Plus 已于 2026 年 10 月 28 日到期】

接下来,我进入 ChatGPT 官方账单页面。

英文界面路径是:

Settings → Billing

在 Transaction history(交易记录)中,可以看到最新一笔账单:

  • 2026 年 10 月 28 日
  • ChatGPT Plus
  • PHP 982.14
  • Due(待支付)

而上一期 9 月 28 日的账单是 Paid(已支付)。

【图3:ChatGPT 官方账单显示 10 月 28 日 PHP 982.14 待支付】
【图3:ChatGPT 官方账单显示 10 月 28 日 PHP 982.14 待支付】

所以这次并不是 BeWild 页面单方面显示异常。

OpenAI 官方也明确记录了新一期付款没有完成。

不过,我还注意到一个比较有意思的情况。

虽然 10 月 28 日的续订已经失败,但到了 10 月 29 日,我的 ChatGPT 和 Codex 仍然可以正常使用。

这让我怀疑,账单到期和实际权限终止之间,可能并不是完全同步的。

这个问题后面再详细讨论。

三、这次“修复订阅”,必须先取消原来的 Plus 套餐

由于上个月已经成功修复过一次,我原本打算直接重复相同操作。

进入:

BeWild → 我的订单 → 修复订阅

但是这次弹出的提示却有所不同。

系统要求我:

先进入 ChatGPT,在官方设置中取消逾期套餐,确认取消生效以后重新获取 Session,再返回 BeWild 提交修复。

【图4:BeWild 修复页面要求先取消官方逾期套餐,再重新获取 Session】
【图4:BeWild 修复页面要求先取消官方逾期套餐,再重新获取 Session】

我最初不太理解为什么必须先取消。

毕竟,从用户角度来看,我已经提前支付了三个月的服务费。

如果 BeWild 用来续订的支付方式失败了,理论上应该由服务商处理付款问题,而不是要求用户自己取消原套餐。

当然,从技术角度推测,这样的流程可能是为了清理 OpenAI 原来的未支付订阅状态,方便重新建立付款关系。

但这只是我的推测,客服并没有明确解释后台的技术机制。

我更关心的其实是实际操作带来的麻烦。

特别是这次,我还有 Codex 任务正在执行。

四、联系客服:我担心取消 Plus 会中断 Codex 任务

我向 BeWild 客服提出了疑问。

为什么修复订阅之前,还必须先取消 ChatGPT 官方的套餐?

这个步骤能不能由系统自动完成?

客服给出的操作建议是,进入 ChatGPT 账单页面找到取消订阅的入口,先取消原来的订阅,等待账号恢复免费状态,再返回 BeWild 提交修复。

但我还有一个比较现实的问题:

如果现在取消 ChatGPT Plus,正在执行的 Codex 任务会不会因此中断?

因为我最近一直在使用 Codex 处理 Go Learning & Documentation Translations 项目的工程任务。

这些任务有时候执行时间比较长。

我不希望因为修复订阅,导致正在运行的开发任务被迫中止。

客服建议我:

可以先执行完,再点击修复。

【图5:BeWild 客服建议先完成当前 Codex 任务,再取消套餐进行修复】
【图5:BeWild 客服建议先完成当前 Codex 任务,再取消套餐进行修复】

我觉得这样比较稳妥。

因此,当时决定先继续使用 Codex,等当前工作结束或本轮额度接近耗尽,再处理 Plus 订阅。

这里也暴露出一个新的用户体验问题:

第三方代充服务的续订故障,已经开始影响我的开发工作安排。

如果只是偶尔点击一下“修复订阅”,倒还可以接受。

但现在还需要考虑什么时候取消套餐、是否影响 Codex、修复后权限什么时候恢复,就明显复杂多了。

五、ChatGPT 英文界面如何取消 Plus 套餐

等我准备好以后,重新进入 ChatGPT 官方的 Billing 页面。

在页面底部找到了:

Cancel plan

也就是取消套餐。

点击以后,ChatGPT 首先弹出一个推荐切换到 ChatGPT Go 的窗口。

我没有打算更换套餐,因此选择:

No thanks

继续取消 Plus。

随后进入最终确认页面。

窗口标题是:

Subscription Cancellation

其中有一段比较重要的说明。

意思是:

如果取消订阅,已经支付的 Plus 使用时间仍会保留;如果当前周期尚未付款,Plus 权益则可能立即结束。

【图6:ChatGPT 取消订阅确认窗口提示,未付款周期的 Plus 权益可能立即终止】
【图6:ChatGPT 取消订阅确认窗口提示,未付款周期的 Plus 权益可能立即终止】

这与我当时的情况比较吻合。

10 月 28 日的账单尚未支付,而上一期已经在 10 月 28 日到期。

因此我点击:

Cancel subscription

随后页面提示:

Your subscription has been canceled

也就是订阅已经取消成功。

【图7:ChatGPT 官方提示订阅已取消,原来的待支付账单暂时仍然存在】
【图7:ChatGPT 官方提示订阅已取消,原来的待支付账单暂时仍然存在】

需要说明的是,这次我没有为了测试而额外向 OpenAI 支付月费。

因为三个月套餐已经向 BeWild 付款。

如果这时再通过自己的付款方式向 OpenAI 支付,反而可能造成重复购买。

六、回到 BeWild,原订单完成修复

取消原来的官方订阅以后,我返回 BeWild。

重新获取 Session,并按照“修复订阅”页面的提示提交。

这里使用 Session,是 BeWild 提供的第三方代充流程的一部分。Session 可能包含有效的登录凭证,存在账号安全风险,因此本文只记录操作经过,不展示 Session 内容,也不把它作为通用的安全操作建议。

提交以后,原订单的状态变成:

处理中。

页面提示后台修复任务正在处理,需要稍后查看最新状态。

【图8:BeWild 的三个月原订单进入修复处理中】
【图8:BeWild 的三个月原订单进入修复处理中】

随后,我再次刷新“我的订阅”。

原来显示“已逾期”的 ChatGPT Plus,现在已经变成:

生效中。

到期日期也更新为:

2026 年 11 月 29 日。

【图9:BeWild 订阅恢复生效,到期时间延长至 2026 年 11 月 29 日】
【图9:BeWild 订阅恢复生效,到期时间延长至 2026 年 11 月 29 日】

至少从 BeWild 的订阅页面来看,第三个月已经修复成功了。

这次还有一个让我比较满意的地方。

仍然使用原来的三个月订单完成修复,没有要求我重新购买一份新套餐。

相比此前退款后重新购买的处理方式,这确实简单一些。

只是先取消官方订阅的操作,又增加了额外步骤。

七、OpenAI 账单也恢复成功,旧账单作废

为了确认修复结果,我继续检查 ChatGPT 官方账单。

这次终于看到了变化。

10 月 28 日原来的 PHP 982.14 待支付账单:

Due → Void

也就是由待支付变成已作废。

同时,10 月 29 日新增了一笔:

  • ChatGPT Plus
  • PHP 982.14
  • Paid(已支付)
【图10:10 月 29 日新增 PHP 982.14 已支付账单,10 月 28 日原账单变为 Void】
【图10:10 月 29 日新增 PHP 982.14 已支付账单,10 月 28 日原账单变为 Void】

现在把这份三个月订单的 OpenAI 账单整理一下:

日期金额最终状态
2026-08-26US$20.00Paid
2026-09-26US$20.00Void
2026-09-28PHP 982.14Paid
2026-10-28PHP 982.14Void
2026-10-29PHP 982.14Paid

这几笔账单说明:

第一期在 8 月 26 日正常支付。

第二期原定 9 月 26 日付款失败,在 9 月 28 日修复成功。

第三期原定 10 月 28 日付款失败,在 10 月 29 日修复成功。

所以从实际付款结果来看,三个月的月度订阅费用最终都完成了处理。

但是两个后续月份,都没有正常自动续订成功。

另外,最新账单页面顶部仍然保留着可能存在付款问题的提示。因此,我主要依据新账单 Paid、旧账单 Void,以及 BeWild 的“生效中”状态来确认修复结果,而不是认为所有系统界面已经立即完成同步。

八、为什么一直使用菲律宾比索?我更倾向于成本和利润方面的考虑

这次还有一个让我比较感兴趣的问题。

为什么 BeWild 多次使用 PHP 982.14 为 ChatGPT Plus 付款?

这里的 PHP 是菲律宾比索。

根据 OpenAI 官方的多币种计费说明,ChatGPT 订阅支持包括菲律宾比索在内的多种本地货币,而且不同地区可能采用本地化价格。

官方文档:

OpenAI:Multi-currency billing

我又查了一下各地区 ChatGPT Plus 的价格。

截至 2026 年 10 月 29 日,第三方价格数据库 AISub 给出的菲律宾网页端 ChatGPT Plus 参考价格是:

PHP 982.14/月

折合约:

US$15.34/月

而美国的标准价格为:

US$20/月。

也就是说,按照该数据库当时的汇率和计价口径,菲律宾的价格大约低了 23%。

参考来源:

AISub:菲律宾 ChatGPT Plus 地区价格

这个网站还把菲律宾列为其统计地区中 ChatGPT Plus 网页端参考价最低的地区。

当然,这只是第三方数据库的统计结果,不能直接理解为 OpenAI 官方认定菲律宾永远是全球最低价。

价格排名可能随汇率、当地税费和定价调整发生变化。

但至少有一点已经比较明确:

PHP 982.14 对应的菲律宾地区参考价,确实低于美国的 US$20 标准月费。

低价地区可能为代充平台提供利润空间

这也是我现在更倾向于的一种解释。

对于第三方代充平台来说,如果能够使用合法可用的地区价格,以更低成本购买相同的 ChatGPT Plus 服务,那么价格差异就可能成为其商业模式的一部分。

假设按照菲律宾当时约 US$15.34 的价格购买一个月 Plus。

而用户通过代充平台支付的实际平均月费约为 US$21。

两者之间就存在一定的价差。

当然,这只是收入与基础采购价之间的差额,还不是最终利润。

平台还需要承担支付手续费、汇率成本、售后服务、失败退款、支付渠道维护等费用。

但只要整体成本控制得当,地区价格差异就有可能带来更高的利润空间。

这比简单地认为“平台为什么不用 US$20,而使用 PHP 982.14”更容易理解。

我越来越倾向于认为:

选择较低价格的地区计价方式,很可能是第三方代充平台进行成本控制、提升利润空间的一种手段。

不过,这里仍然要区分事实和推测。

事实是,我已经多次在 OpenAI 账单中看到 PHP 982.14。

事实也是,菲律宾对应的地区参考价明显低于美国。

但 BeWild 是否专门为了扩大利润空间而选择菲律宾、实际使用什么付款渠道、需要承担多少交易成本,我都没有后台资料能够证实。

因此,目前只能将其视为一种具有商业合理性的解释,而不是已经确认的内部运营机制。

从我这份订单来看,平台可能有多大的价差?

我的三个月套餐实际支付了:

US$62.99

平均每个月约:

US$21.00

如果假设三个月全部按照 US$15.34 的参考价格采购:

3 × US$15.34 = US$46.02

与我支付的 US$62.99 相比,差额为:

US$16.97

但我的真实账单并不是三个月全部使用菲律宾比索。

第一期是 US$20.00。

后两期才使用 PHP 982.14。

如果仅按照公开参考汇率进行示意估算:

US$20.00 + US$15.34 + US$15.34 = US$50.68

和 US$62.99 相比,理论差额约为:

US$12.31

这个计算只能作为商业模式分析,不能认为就是 BeWild 从我这份订单获得的真实利润。

因为没有实际换汇结算记录,也没有手续费、税费及售后成本数据。

另外,这也提醒了我一件事。

代充平台使用较低的地区价格,并不意味着消费者就一定能享受到相同比例的折扣。

我实际支付的三个月费用是 US$62.99。

而按照 OpenAI 美国标准价格 US$20/月计算,三个月只需要 US$60,未计可能适用的税费。

所以我选择第三方代充,主要还是为了解决实际付款渠道的问题,并不是因为这份三个月套餐比官方美国标准价格便宜。

九、取消并重新订阅 Plus,Codex 额度为什么随后恢复了 100%?

这次修复还让我对 Codex 的订阅状态有了新的认识。

10 月 28 日,ChatGPT Plus 理论上已经进入新的计费周期。

但当天的自动扣款失败。

到了 10 月 29 日,我却仍然能够正常使用 ChatGPT Plus 和 Codex。

而且回想上个月的经历,我印象中也是在续订出现异常以后,账号仍有一段时间显示 Plus,并没有立刻变成 Free。

这说明至少在我的实际经历中:

账单付款失败、套餐状态显示异常和实际使用权益终止,并不一定发生在同一个时间点。

至于原因,我现在有几个猜测。

一种可能是付款失败以后,系统仍然保留了一段短暂的服务宽限期。

另一种可能是计费系统、ChatGPT 前端和 Codex 的权限状态存在同步延迟。

还有一种可能是当前已经建立的 Codex 会话,在一段时间内仍可以沿用已有的授权状态。

但这些机制都没有通过这次操作被单独验证。

我只能确认自己实际看到的现象,不能断言一定是哪一种原因。

重新订阅后,Codex 额度起初没有变化

10 月 29 日,第三个月的订阅修复成功后,我再次进入 Codex,执行 /status 查看额度。

当时使用的是 Codex v0.164.0,模型为 GPT-6.1-Sol(reasoning high),账号状态显示 Plus。

但五小时额度和每周额度并没有因为重新付款就立即回到 100%:

  • 五小时额度:剩余 23%,下一次重置时间为 10 月 29 日 19:43;
  • 每周额度:剩余 44%,下一次重置时间为 11 月 4 日 15:29。
【图11:修复订阅以后,Codex 仍然显示 Plus,五小时额度剩余 23%,每周额度剩余 44%】
【图11:修复订阅以后,Codex 仍然显示 Plus,五小时额度剩余 23%,每周额度剩余 44%】

从这张截图看,重新订阅成功以后,Codex 额度至少没有立即重置。我当时据此认为,Codex 的使用额度可能沿用原有周期,并不会随着 Plus 月度订阅付款直接重新计算。

但大约半小时后的第二次检查,改变了这个判断。

随后两个额度窗口同时恢复到 100%

还是 10 月 29 日,我再次执行同一条 /status 命令。Codex 账号仍然显示 Plus,但额度已经发生明显变化:

  • 五小时额度:从剩余 23% 变成剩余 100%;
  • 每周额度:从剩余 44% 变成剩余 100%。

不仅如此,两个额度窗口显示的下一次重置时间也都改变了。

项目第一次检查第二次检查
账号状态PlusPlus
五小时额度剩余 23%剩余 100%
五小时重置时间10 月 29 日 19:4310 月 29 日 23:57
每周额度剩余 44%剩余 100%
每周重置时间11 月 4 日 15:2911 月 5 日 18:57
【图12:再次执行 /status 后,Codex 五小时与每周额度同时恢复至 100%,下一次重置时间也发生变化】
【图12:再次执行 /status 后,Codex 五小时与每周额度同时恢复至 100%,下一次重置时间也发生变化】

这是本次修复过程中,我认为特别值得记录的一个现象。如果只看第一次截图,会得到“重新订阅没有重置额度”的结论;但结合第二次截图,实际情况是“没有立即重置,随后两个额度窗口同时恢复到了 100%”。

两个新的重置时间,似乎指向同一个起点

第二次截图中的五小时额度显示在 10 月 29 日 23:57 重置,而每周额度显示在 11 月 5 日 18:57 重置。

如果分别按照五小时和七天反推,这两个时间都会指向 10 月 29 日 18:57 左右。

也就是说,这次不太像单独的五小时自然窗口重置,因为每周额度也从 44% 变成 100%,而且两个窗口的下一次重置时间都一起变化了。

更符合截图现象的一种解释,是 Codex 在这个时间点附近重新建立了两个额度周期,或者系统将某次额度调整同步到了当前会话。这里的 18:57 是根据重置时间反推出来的,并不是后台日志确认的操作时间。

很可能与重新订阅有关,但还不能证明因果关系

考虑到当天我刚刚取消原来的 Plus 订阅,再通过 BeWild 修复、重新建立月度订阅,之后 Codex 额度就同时恢复到 100%,我现在更倾向于认为这次额度变化与重新订阅有关。

一种可能是,新订阅已经支付成功,但 Codex 的额度权益需要经过一段时间才重新分配或刷新,所以第一次检查仍显示旧额度,第二次检查才显示新的 100%。

不过,也不能排除 OpenAI 针对特定账号进行额度调整,或者额度显示本身发生了延迟更新。仅凭两张 /status 截图,无法确认触发重置的后台事件,也不能断定这是官方统一重置。

因此,这次经历最多只能说明:在我的账号上,重新订阅 Plus 之后不久,Codex 的五小时和每周额度确实一起恢复到了 100%,并且新的重置时间一致指向同一时间附近。它还不能作为“每次取消再订阅都能重置额度”的操作方法。

关于 Codex 额度和使用限制,可参考 OpenAI 官方说明:Using Codex with your ChatGPT plan。

那么,取消 Plus 是否会中断正在执行的 Codex 任务?

这次还有一个问题并没有得到直接验证:在取消订阅成功、重新修复尚未完成的那段时间里,正在执行的 Codex 任务是否一定能够继续运行?

我在 10 月 29 日发现,即使前一天的 Plus 付款失败,账号仍能继续使用 ChatGPT 和 Codex。这可能涉及付款宽限期、不同系统之间的权益同步延迟,或者现有会话的授权状态,但目前无法确定具体原因。

而这两张额度截图,都是在本次修复完成以后获取的。它们只能反映修复后的 Codex 状态,不能证明取消订阅期间正在执行的任务一定不会受到影响。

因此,今后如果还需要处理类似问题,我仍然会优先完成重要的 Codex 任务,再执行取消订阅和修复流程。只是这次的观察让我意识到,OpenAI 的账单状态、Plus 权益状态和 Codex 额度窗口,可能存在不同的更新节奏。

十、三个月订单完成以后,我对 BeWild 的评价

现在,这份 8 月 26 日购买的三个月订单,已经完成了三个付款周期。

从结果来看:

第一个月正常开通。

第二个月续订失败,经过修复恢复成功。

第三个月再次续订失败,经过取消套餐和重新修复后恢复成功。

因此,我不认为这是一份完全失败的订单。

毕竟,三个月对应的订阅服务最终都完成了付款处理。

而且后两次修复都没有要求我重新购买一份三个月套餐。

但与此同时,我也不能忽略它的可靠性问题。

因为这份订单后续两个月的自动续订,都出现了异常。

也就是说,购买三个月套餐以后,我实际上仍然需要每个月主动关注:

  • 是否到期;
  • 自动付款有没有成功;
  • BeWild 是否显示逾期;
  • OpenAI 账单是 Paid 还是 Due;
  • 需要不需要重新修复;
  • 修复以后权益有没有完全同步。

这样的用户体验,距离我理想中的三个月自动续订服务还有明显差距。

特别是这次,必须先取消 ChatGPT 官方订阅,才可以重新申请修复。

对于依赖 Codex 开发的用户来说,还需要专门考虑操作时间。

这不是单纯多点击几次按钮的问题,而是已经增加了用户的工作安排成本。

至于 PHP 982.14 的地区计价,我反而觉得是一个比较容易理解的商业选择。

如果利用不同地区的本地订阅价格,能够降低服务采购成本,那么第三方平台自然有动力选择成本更低的支付方式。

但无论平台如何控制采购成本,作为已经预付费用的用户,我最希望得到的仍然是稳定的订阅服务。

低价采购可能增加平台的利润空间,但不应该以用户频繁手动修复订阅作为代价。

十一、总结

这次经历已经有了明确结果。

2026 年 10 月 29 日,我通过 BeWild 完成了第三个月的 ChatGPT Plus 续订修复。

10 月 28 日原来的 PHP 982.14 待支付账单变成 Void。

10 月 29 日重新生成了 PHP 982.14 的 Paid 账单。

BeWild 显示 Plus 已恢复生效,到期日期更新为 11 月 29 日。

Codex 的 /status 则出现了先后不同的结果:修复后第一次检查仍显示五小时额度剩余 23%、每周额度剩余 44%;稍后再次检查时,两项额度同时恢复到 100%,下一次重置时间也随之改变。

对我来说,这次实测留下了三个值得记录的结论。

第一,BeWild 的“修复订阅”功能确实能够解决部分续订失败问题,但这份三个月订单连续两个月自动续订失败,说明服务的稳定性还有改善空间。

第二,菲律宾比索计价具有明显的地区价格优势。我认为第三方代充平台可能会基于成本和利润考虑选择这样的计价方式,但具体利润结构仍然需要更多证据。

第三,OpenAI 的订阅账单、Plus 权益和 Codex 额度并不一定同步变化。这次重新订阅后,Codex 两个额度窗口起初没有变化,随后却同时恢复到 100%。我怀疑这与重新订阅后的额度重新分配有关,但还不能排除其他系统调整或同步延迟。

这些发现并不能说明所有账号、所有订阅周期都会出现相同现象,但至少能够为以后遇到类似情况提供一个实际参考。

目前,这份三个月订单的第三期付款已经完成。

希望以后不需要再通过取消订阅、重新获取 Session、手动申请修复的方式,才能维持一份已经提前支付的服务。或者,我可能会尝试去寻找其他的订阅方案了!

写了一个 AI 订阅服务实测系列后,两家服务商主动找到了我:关于外链、软文与真实记录

关于作者 · 持续学习与技术实践

我是一名拥有 15 年以上开发经验的技术从业者,自 2013 年起持续运营个人技术博客,记录工作与个人项目中遇到的真实问题,以及解决问题过程中的探索、实践和思考。

除了技术写作,我也在持续开发和维护自己的独立项目,探索新技术和新工具在实际场景中的应用。我始终相信,没有不值得去解决的问题,也没有不值得去学习的技术。

如果这篇文章对你有所帮助,欢迎浏览博客中的其他文章,也欢迎交流技术经验与想法。

关于我  ·  GitHub  ·  邮件联系