⚙️ 先定义你要优化的指标

性能优化不能只看‘回复快不快’。开发场景至少要同时观察首字响应时间、完整响应时间、失败重试次数、上下文大小和单次任务消耗。只调整一个参数，很容易把延迟转移成更高的失败率或成本。

先记录基线，再做调整。没有基线，就无法确认优化是否真的有效。

• 首字响应：判断线路是否及时开始处理。
• 完整响应：判断长任务是否受上下文和输出长度影响。
• 成功率：避免用无休止重试掩盖线路问题。
• 上下文量：识别重复读取和无关文件带来的额外请求。

第一步：选择适合任务的线路和模型

从灵能API服务入口确认当前可用模型和接口信息。代码**、快速问答、复杂重构和长文档分析的需求不同，不要把所有任务固定到同一模型上。先按工作类型划分，再建立对应的配置卡。

灵能API入口：https://www.lnsns.com/。先复制当前 Model ID，再在 CC Switch 中建立任务专用卡片。

• 小范围修改：优先短上下文和快速反馈。
• 复杂重构：优先稳定性和较强的分析能力。
• 批量检查：设置清晰范围，避免重复扫描整个仓库。

️ 第二步：为不同任务建立独立配置卡

不要在一张默认卡片里频繁改模型、超时和上下文参数。可以建立‘快速修复’‘深度**’‘长文档’三类卡片，每张卡片只解决一种工作目标，测试结果才有可比性。

• 卡片名称写明任务类型，不使用含义模糊的‘默认’。
• 一次只调整模型、超时或重试中的一个变量。
• 保留一张已知稳定的基线卡，不参与频繁试验。

第三步：控制上下文，而不是盲目增加提示词

上下文越长，不代表结果一定越好。大量无关文件、重复日志和历史对话会增加处理时间，也可能让真正重要的约束被稀释。让 Codex 先读取目录结构，再指定与任务直接相关的文件。

请先读取目录结构，不要修改文件。
只分析 src/auth 和 tests/auth。
忽略 node_modules、构建产物和日志目录。
先列出发现的问题，再提出修改计划。

• 先给目录范围，再给具体文件。
• 把约束写成可执行的排除项。
• 长任务拆成分析、修改、验证三个阶段。

**步：用小任务测出请求基线

建立基线时不要直接使用大型项目。准备一个内容固定、输出目标明确的小任务，例如让 Codex 解释一个函数、列出三个测试缺口或检查一份短配置。连续执行几次，记录开始时间、首字响应和总耗时。

任务：只读取 sample.ts，解释函数输入输出。
记录：配置卡、模型、开始时间、首字时间、结束时间、是否重试。

如果同一任务的耗时波动较大，不要立即判断模型变慢。先重复测试，并检查本地网络、**、系统负载和是否存在并发请求。

第五步：合理处理重试和并发

重试可以提高偶发错误下的成功率，但没有间隔的连续重试会放大限流和额度压力。开发工具中应区分可重试错误与不可重试错误：网络短暂失败可以退避，模型不存在和权限不足则应立即停止并检查配置。

并发任务也要按项目和令牌权限划分，避免多个终端共享一张临时卡片造成难以解释的波动。

• 连接中断：可以采用有限次数的间隔重试。
• 429 或限流：降低并发，增加退避时间。
• 401、403、404：先修配置，不要重复发送。
• 长任务失败：缩小范围后重新执行，不重复提交全部上下文。

第六步：验证参数调整有没有副作用

每次调整后，用同一组基线任务复测，并补一个真实但低风险的项目任务。只看响应速度不够，还要看回答是否遗漏约束、是否出现更多返工以及测试是否仍然通过。

New-Item -ItemType Directory codex-perfor**nce-check
Set-Location codex-perfor**nce-check
codex

• 记录调整前后的首字和完整响应时间。
• 检查输出是否仍覆盖任务约束。
• 确认失败率、重试次数和上下文量没有异常增加。

第七步：用任务拆分减少无效消耗

很多消耗并不是来自真正复杂的工作，而是重复读取、反复解释同一**和让模型在一次请求中完成过多步骤。把工作拆成几个**收的小阶段，既便于回滚，也能减少无效上下文。

每个阶段都留下简短结论，下一次请求只携带必要信息，不把整段历史记录全部重复发送。

• 阶段一：只读并确认范围。
• 阶段二：给出计划和风险点。
• 阶段三：执行局部修改。
• 阶段四：运行针对性测试。

性能异常的快速判断表

性能问题通常需要多项证据共同判断。先恢复到稳定基线，再用单变量实验确认原因。

• 所有项目都变慢：先看线路、网络和服务状态。
• 只有一个项目变慢：看上下文范围、脚本和并发。
• 首字快但总耗时长：检查输出长度和任务拆分。
• 偶发失败增多：看重试、限流和**稳定性。
• 速度提升但返工变多：检查模型选择和提示约束。

✅ 一套可持续的优化节奏

用灵能API与 CC Switch 做 Codex 接入时，稳定的性能来自持续记录和小步调整，而不是一次性堆叠更多参数。

• 每类任务至少保留一组固定基线。
• 配置卡按任务用途命名并记录变更。
• 上下文只包含当前任务真正需要的内容。
• 重试采用有限次数和退避策略。
• 每次调整都验证速度、质量和失败率。
• 复杂工作拆分为**收的小阶段。