企业官网建设流程全解析

1. 先聊聊Codex报错这件事

如果你这段时间在用Codex做日常开发，大概率遇到过这么一行提示：Selected model is at capacity. Please try a different model.屏幕一灰，对话断掉，刚刚排到一半的思路全被打乱。

先说这个提示是什么。Codex是当下不少人依赖的AI编程助手，核心价值是能直接在你本地仓库上下文里理解代码、改代码、跑命令、提交变更。但它背后的模型推理服务是按容量调度的，高峰期请求太多，超过队列承载上限，服务端就会直接返回at capacity，意思很直白：当前这个模型实例已经满载，暂时接不了新活了，让你换个模型试试。

这个问题的本质不是你的代码有问题，也不是你的网络有问题，而是服务端资源调度紧张。理解了这一点，很多无效操作就能避开：反复刷新、疯狂重试、换节点部署，大概率是白费劲。

这篇内容我主要想跟同样是开发者的朋友聊聊，我在这段时间里摸索出的一套缓解思路。不保证100%根治，但能明显降低碰到这个报错的频率，也让真碰上的时候不至于卡死在那儿等。里面涉及排队策略、高峰期规避、模型切换、本地缓存复用、任务分解这几类手段，都是实际用过的，不是拍脑袋。

适合谁看？天天用Codex写需求、改Bug、做重构的人，尤其是你的工作节奏恰恰跟全球高峰期撞车的。新手也不用被后面那些偏底层的解释吓到，我会把原理讲得比较口语化，实操部分一步步说清楚。

2. 拆解这个报错的触发逻辑

2.1 “容量满了”背后是哪一层满了

先说结论：绝大多数情况下，不是你的额度超了，也不是网络断连，而是你选的那个模型所对应的推理集群，在同一时间点涌入了太多请求。

可以把Codex的模型服务想象成一个餐馆。厨房里锅就那么多，厨师也就那么多。一到饭点，每桌都在点菜，后厨处理不过来的时候，新来的客人就得排队，排不了的就只好说“今天不接客了，你换家店”。at capacity就是这块“不接客”的牌子。

具体到实现层面，OpenAI的模型服务是按区域、按模型规格做容量隔离的。比如最强的那个模型，因为推理资源开销大，可用的计算实例相对有限，一旦某几个时区的开发者同时涌入，实例队列被打满，就触发拒绝。弱一些的模型实例多、单价便宜，反倒没那么容易挤爆。

2.2 为什么时好时坏，跟你的工作时区有关

你有没有发现，这个报错往往集中在某个时段反复出现，另一些时段几乎碰不到？这不是心理作用，是真实存在的潮汐效应。

海外的活跃高峰对照北京时间大概是两个窗口：早上八点到十一点，对应美西傍晚；晚上八点到凌晨一点，对应美东上午到中午。这两个窗口里，欧美开发者全员上线，全球请求量直接拉满，你在这个时间段打开Codex，碰到at capacity的概率明显高。

反过来说，如果我的工作习惯是凌晨两三点写代码，那段时间请求量低，整个体验会顺畅得多，几乎不出现什么排队问题。所以你完全可以把错误信息当作一个“服务器繁忙指数”来看。

2.3 报错出来之后，自动恢复要多久

很多时候你等一会儿再点重试，会发现又能用了。这个“等一会儿”并不是玄学，而是服务端在快速调度空闲资源补位，把积压的队列消化掉。

根据我实际观察，低峰期基本上一两分钟就能恢复；高峰期可能五分钟、十分钟都未必能恢复，尤其当你选的恰好是最热门的那个模型。如果你的团队正在赶进度，这种不确定性非常伤节奏——所以核心思路不是“等它恢复”，而是“主动绕开”。

3. 分层次的缓解方案，我自己试下来很管用

这个问题的解法不是一个开关就能解决的，需要组合拳。我按照从“事前规避”到“事中应对”再到“事后兜底”的顺序展开，每一层覆盖不同的使用场景。

3.1 事前规避：调整工作时间与模型偏好设置

最笨但最有效的办法就是错峰。这一点很多人心里清楚但做不到，说到底还是项目排期太紧。我的建议是，不必完全昼夜颠倒，只要把代码生成类任务的密集操作挪到低峰窗口，就已经能改善很多。

比如白天尽量写设计文档、画架构草图、做代码评审，这些不依赖Codex；等到晚上安静了，再集中让它跑大规模重构、批量补测试、整理技术债。这相当于把推理资源需求从高峰期挪开，相当于人肉削峰填谷。

另外在模型选择上，不要把默认档位设成最贵的那个。Codex界面里通常可以在模型列表里切换不同配置。我实测下来，低一档的模型在高负载时承接能力更强，排队被拒的概率显著更小。除非你的任务确实需要顶级推理能力，否则大部分CRUD开发、Bug修复、单元测试编写，低一档完全够用。

注意：这个切换是会话级即时生效的。碰到at capacity时不一定要重开会话，直接在模型选择器里降到次级选项，原有上下文依然保留，继续对话即可。这一点很关键。

3.2 事中应对：切换模型、重试节奏和新会话策略

真碰上了报错，第一反应不要是猛点重试。那个Try again按钮在高峰期就是一张“排队票”，点多少次都不会改变你在队列中的位置，反而有可能因为你频繁创建请求，把负载搞得更高，进一步拖长恢复时间。

我的推荐做法是三步走：

1. 先切换模型档位。把当前模型从一个档位切到另一个档位，相当于绕过当前满载的实例，重新路由到相对空闲的资源池。我实测里这一步成功率高得惊人，经常是一切换就能立刻继续用。
2. 如果切换后依然报错，说明不同档位的容量都紧张，这时与其干等，不如开一个新会话，把刚才的上下文通过粘贴关键代码、补一段简短说明重新喂进去。老会话的连接可能挂在某个不健康的实例上，新会话会重新做负载均衡，经常会有惊喜。
3. 如果还不行，那就真的进入“排队时间”了。我自己的习惯是切走干点别的活，过五到十分钟再回来。这段时间千万别反复去点，纯属浪费精力。

顺便提一嘴，/compact这种上下文压缩指令在会话变得很臃肿时也很有用。会话上下文越长，每轮请求消耗的资源越高，服务端做容量调度时越容易把它判定为“高成本请求”，从而先被拒掉。所以保持会话精简，不仅省token，也能略微降低被拒概率。

3.3 本地增量缓存与离线准备

Codex最有用的一个特性是它直接跟本地仓库交互。这其实给了我们一个极大的缓冲空间：很多工作根本不需要在线实时生成，你完全可以让它一次生成大量结果，存到本地，后面离线使用。

我的做法是这样的：每天晚上把第二天的任务分成若干块，趁深夜低峰让Codex把每块任务的参考实现、测试用例、重构建议全生成出来，存成Markdown或者代码补丁文件。第二天白天，就算Codex完全不可用，我也能根据这些结果手动落地。

因为容量报错影响最大的场景是“交互式调试”——你对代码改来改去，每轮都要模型理解最新状态。这种模式一旦断掉，整个思考链就断了。而离线预生成的代码虽然可能不是最精确的，但它保证了基本产出不中断，至少白天还有东西可做。

工具层面，我还会配合本地代码搜索、编译、单测这套流程，把Codex的输出先验证一遍，有问题的集中记录下来，等它恢复了再批量处理。相当于把Codex当成一个“异步顾问”而不是“实时结对编程伙伴”，心态上会稳很多。

3.4 利用其他入口分摊压力

Codex并不止一个入口。命令行里的codex工具、桌面App、网页版、API，走的是不同的接入通道，背后虽然共用同一批模型资源，但调度优先级和限流策略并不完全一致。

我实测下来，有时候桌面App卡得要死，命令行里用codex exec跑同样的请求反而秒回。有可能是不同客户端的连接池、超时配置不一样，也可能是请求元数据有差异导致路由不同。所以我现在的习惯是：桌面App卡了，先打开终端用CLI试一下，很多场景下CLI更稳定，毕竟命令行工具的请求更加“轻量”，没有前端那些遥测和会话同步的开销。

如果你有API Key权限，也可以写一个简单的重试脚本，调用模型接口做自动化补全。脚本里加上退避重试逻辑——第一次失败等5秒，第二次等15秒，第三次等30秒，最多重试五次。这个策略比手动刷新稳得多。不过要注意，API的额度和速率限制跟Codex订阅是两套体系，别混着用，不然容易把自己整超限。

4. 详细走一遍我自己的标准应对流程

下面这套流程，是我踩了很多次坑之后沉淀下来的。每次碰到at capacity，我就照着这个顺序来，基本五到十分钟内能恢复工作能力。

4.1 第一步：识别当前处于高峰期还是偶发故障

我会先看一眼当前时间。如果是前面说的两个高峰窗口，默认它就是高峰期容量问题，不慌；如果是凌晨、下午这种冷门时段，可能要留意是不是账号额度、网络出口或者服务端故障导致的。

识别的手段很原始：在另一个页面随便发一个简单的请求，比如让它“写一个Python的快速排序”。如果连这种最简单请求都报错，说明服务端整体过载或者故障；如果这种简单请求秒回，只是你那个复杂会话被打回，说明是高成本长会话触发了资源限制，这时候精简上下文比切换模型更有效。

这个区分非常实用。很多人一报错就全网找答案，其实先自己测一个最小请求，就能把排查范围缩小一大半。

4.2 第二步：按优先级执行切换动作

确认是容量问题后，我执行的动作顺序是这样：

1. 模型档位切低一级。不换会话，不丢上下文。
2. 切新会话，粘贴关键背景信息，同时载入最近的仓库改动摘要。
3. 用CLI入口重试同样的请求。
4. 以上全不行，停止重试，转去做离线任务。

每一步之间间隔约一到两分钟，不是机械地等，而是处理一下手头能做的事。比如把刚才报错前写到一半的伪代码整理一下，或者把日志文件翻一翻。反正闲着也是闲着，时间没浪费。

4.3 第三步：给会话做“减脂”

如果新会话仍然偶尔报错，但没那么频繁了，接下来要考虑的是会话上下文瘦身。Codex的会话如果拖了几百轮，里面塞了一堆废弃方案、大量搜索日志、好几个版本的改动记录，每一轮请求的token用量会非常夸张，推理成本水涨船高，服务端更容易优先拒绝它。

我一般会开一个全新的会话，把当前任务的最终目标、已决定的实现方案、相关文件路径写清楚，直接开干。那些探索过程的讨论，不值得留着。你可以这样理解：老会话里全是“思考过程”，新会话里只需要“结论”，模型拿到干净上下文，输出质量反而更高。

4.4 第四步：必要时上个本地兜底方案

如果你被这个报错折腾得完全没脾气，而且短时间内确实有硬交付要赶，最终手段就是本地兜底。我的习惯是在本地维护一个小的代码片段库，把常用模式、惯例写法、复杂算法模板都预先存好，到了Codex抽风的时候，手写拼接也能推进。

这个做法听起来有点“开倒车”，但在关键时刻真的很救命。它保证你不至于因为一个外部依赖瘫痪导致整个项目停摆。而且说白了，Codex本质上是个提效工具，不是基础设施，真正的核心能力还是你对系统的理解。

5. 常见并发症与专项排查

除了at capacity本身，Codex还会连带冒出一些其他问题。这里挑几个我实际遇到过的说一下，帮你避免误判。

5.1 “会话恢复失败”不等于容量问题

有段时间我遇到的是Conversation recovery failed，看起来好像也是容量问题，但后来发现这是典型的本地状态损坏。Codex的会话记录存在本地，可能因为磁盘写满、进程被强杀、多个客户端同时打开同一会话导致索引错乱。

排查思路完全不同：不需要错峰，也不需要切模型。直接检查本地存储目录的剩余空间，关掉其他占用会话的客户端，必要时把那个会话的历史归档、重新加载。解决完这些之后，它很快就恢复了。

所以一个核心经验是：先看报错文案。capacity永远是服务端问题，recovery failed大概率是本地问题，方向搞错了全是无用功。

5.2 上下文过长导致的“假过载”

另一个容易混淆的场景是，会话超级长的时候，Codex有时候不报capacity，而是报一些语义模糊的Request failed或者直接超时。表面上看起来跟容量报错很像，但本质是单次请求的载荷太大了，处理时间超出模型服务端的响应窗口。

这种场景下，你调低模型档位反而更糟糕，因为低档模型的处理能力更弱、更慢，更容易超时。正确做法是立刻压缩上下文，删掉那些冗长的报错堆栈、废弃代码块，只留关键部分重试。跟前面说的会话“减脂”是一回事，但这里针对的是单条消息，不是整个会话。

5.3 账户用量看板的滞后误导

Codex的用量看板不是实时的。有时候显示额度充足，但实际因为突发流量被限流；有时候显示超额，其实已经恢复。我对这个看板的态度是：不用于实时诊断，只看日级别的趋势。遇到报错还是优先按照服务端负载来判断，别让看板数据带着走弯路。

6. 避坑总结与底层机制理解

绕了一圈，把核心要点收拢一下。

6.1 必须记住的几条实操纪律

• 高峰期永远不要死磕单条重试，切换档位远比狂点重试有效。
• 会话越短越好，背景信息给“结论”而不是“思考过程”，能显著降低被拒概率。
• CLI入口值得常备，很多GUI上的容量限制在CLI下宽松许多。
• compact大法好，上下文臃肿是隐藏的容量杀手。
• 离线预生成加手动落地，是应对长时间抽风的最佳兜底。

6.2 模型服务的容量分配逻辑，我的一点理解

从外部能观察到的机制大致是这样：模型服务商为了稳定性，会把资源池按模型规格切成多个独立队列。每个队列有自己的负载上限，达到上限之后，排队策略就开始介入，优先保证存量请求完成，新进的请求直接返回at capacity，引导流量到其他队列。

这套机制本身是理性的。它宁可拒绝一些新请求，也不愿让所有请求都失败。理解这套逻辑之后，你会明白几个推论：

• 冷门模型的队列空闲概率更高，所以降档切换有效。
• 高峰期每个队列都接近满载，所以再怎么切换也可能白搭，只能错峰。
• 反复点击重试会让你的请求反复进入队尾，而不是插队，所以除了制造更多负载，没有正面作用。

6.3 给团队的协作建议

如果你的团队都是重度Codex用户，建议排期时预留“缓冲时间”，不要把交付点卡在高峰期。另外，团队内部可以约定一个“报错暗号”，某个人碰到容量爆满，就在群里喊一声，其他人立刻知道当前是整体潮汐而不是个人网络问题，免得每个人都在重复试错。

这听起来有点小题大做，但用过的人都知道，这东西真的能把一整个下午耗掉。

我的体会是，Codex这样依赖远端推理资源的工具，容量问题很难根治，但通过调整使用习惯，完全可以把它的影响压到很低。最核心的判断标准永远只有一个：别让它阻塞你的核心产出路径。工具是用来辅助你写代码的，不是用来让你焦虑的。碰到报错就切换、就绕行、就离线推进，只要你的代码和逻辑在往前走，这个报错说到底就是个背景噪音。