GPT-4o 爆肝码神必杀技：额度用完还能继续白嫖？

最近为了赶年底的项目进度，作为重度依赖 AI 辅助编程的“赛博搬砖人”，我那个 Plus 账号的额度简直像喝水一样消失得无影无踪。看着那个每 5 小时刷新的限制，我都不敢跟 GPT 说人话了，生怕它多想一个 Token，我的钱包就跟着颤抖一波。

发现额度清零但仍能使用 Codex 的瞬间

但是，在一次次极限试探中，我似乎摸到了一点点“系统漏洞”的边缘。今天就来跟大伙分享一下这个可能是 BUG 也可能是 Feature 的“骚操作”。

奇怪的“白嫖”现象

事情是这样的，大家都知道用 VS Code 里的 Codex/GPT 插件辅助开发最舒服。前几天当我的 Plus 额度眼看就要见底，甚至在 CPA（控制面板）里显示已经归零的时候，我习惯性地把一大段需求揉碎了喂给它，心想大不了一报错我就去喝杯水。

结果你猜怎么着？它竟然吭哧吭哧把活儿干完了！

起初我以为是网络延迟导致的显示问题，或者是额度结算的滞后性。但经过好几次“死亡测试”，我发现了一个规律：当你输入的目标极其复杂、描述极其详细、Prompt 超长的时候，即便理论上额度已耗尽，系统似乎依然会放行请求，让它把代码跑完。

技术向瞎猜：为什么会这样？

虽然咱们没看过官方源码，但结合现有的技术栈和 AI 网关的通病，大概能猜出个一二。

这就好比你去吃自助餐，收银台的系统显示你名额没了，但你菜都已经夹到盘子里端走到桌边了。这时候厨师（模型服务端）已经接了单并开始烹饪了。对于后端服务来说，一旦复杂的 Prompt 上下文构建完成进入推理队列，直接中断请求的成本可能比让它跑完还要高（或者是为了保证用户体验的一种熔断机制失效）。

VS Code 插件环境下的长 Prompt 实际效果

特别是当你输入的任务描述非常长且具体时，这可能被判定为一个高权重的“任务流”，这种长上下文的处理链路在计费模块和执行模块之间或许存在一个极短的时间差，或者是针对大文本块的一种特殊放行策略。

极客实操：如何最大化利用这个“特性”？

既然发现了这个“玄学”，咱们怎么能放过它？不过为了防止账号风控，建议大家还是理智一点，把它当作一种额度耗尽时的“保命手段”，而不是无脑薅羊毛的工具。

1. 极致细化 Prompt（本来就是好习惯） 不要说“帮我写个登录功能”，要说“帮我写一个基于 JWT 的登录模块，包含异常处理、参数校验，并适配当前的数据库结构……”。 这样做有两个好处：一来提高了代码可用性，减少返工；二来，正如我们发现的，长任务描述更有可能在“空额度”状态下被放行。

2. 利用 VS Code 插件环境 这个“Bug”似乎在 IDE 插件端表现得尤为明显。相比网页端聊一句算一句的计费逻辑，插件端可能因为涉及多文件上下文引用，其计费握手机制会更复杂。所以，关键时刻把战斗场地留在 VS Code 里。

3. 不要频繁短查询 额度快没了的时候，千万别再问“这段代码对不对？”这种短问题了。攒着大的需求，一次性把剩余价值榨干。

写在最后

这个技巧我目前的测试环境是 VS Code 中的 Codex 插件（具体版本为 26.623.61825），不排除后续官方会随着更新把这个“口子”堵上。如果你也遇到了额度清零却依然能输出代码的情况，欢迎在评论区交流，说不定咱们能合力摸出更多大模型时代的“生存法则”。

毕竟，在 Token 涨价的今天，每一次额外的生成都是赚到了！