长任务最容易失败的不是模型，而是上下文失控

大型项目任务通常包含多个阶段：理解目录、定位入口、分析依赖、设计方案、修改代码、运行测试和总结结果。如果一次性把所有阶段塞进一个请求，输入上下文会迅速膨胀，输出也可能偏离目标。更稳妥的方式是让 Codex 每完成一个阶段就留下明确检查点。

中转线路的作用是提供稳定的模型调用入口，但任务拆分和项目边界仍然需要由使用者控制。

• 阶段一：只读项目结构和关键入口。
• 阶段二：确认问题范围和修改边界。
• 阶段三：提出方案，不立即写入。
• 阶段四：分批修改并运行局部测试。
• 阶段五：汇总变更、测试结果和剩余风险。

第一步：为长任务挑选合适的模型线路

进入灵能API公开页面或控制台，查看当前模型列表、上下文能力、输入输出价格和 Model ID。长任务不要只看单价，还要看模型能否稳定处理较长上下文，以及输出是否容易重复和跑题。

官网入口：https://www.lnsns.com/。模型与价格可能更新，实际配置以当天页面为准。

• 短任务：速度和基础稳定性优先。
• 长上下文：关注上下文容量和读取完整度。
• 代码修改：关注计划执行能力和输出准确度。

第二步：长任务使用单独令牌和配置卡

长任务可能持续较久、产生更多输入输出，因此建议为它创建独立令牌和配置卡。这样可以区分日常短问答与项目级消耗，也便于长任务异常时单独暂停。

不要在长任务运行中临时替换主线路字段。需要测试新模型时，复制卡片建立实验线路，保留当前任务的稳定配置。

• 令牌名称：Codex-LongTask-Project。
• 备注：项目分析、分步修改、局部测试。
• 安全规则：完整令牌只保存在本地私密位置。

️ 第三步：在 CC Switch 建立长任务卡片

打开 CC Switch 的 Codex 配置区域，新增或复制一张渠道卡片。名称建议同时包含服务、任务类型和模型角色，例如“灵能API-Codex-长任务分析”。名称清晰后，切换线路时不容易误选短任务配置。

创建后逐项确认协议、*ase **L、Model ID 和 API Key。复制卡片只减少录入工作，不代表模型和令牌已经适合长任务。

• 配置名称：灵能API-Codex-长任务分析。
• *ase **L：填写到当前服务要求的版本路径。
• Model ID：从当天模型列表复制。

✍️ **步：填写参数并控制输入边界

长任务配置仍然遵循地址、模型、密钥的顺序。*ase **L 通常填写到 /v1，不要把完整接口路径继续拼进去。Model ID 要与当前列表一致，API Key 使用长任务专用令牌。

服务名称：灵能API-Codex-长任务分析
*ase **L：https://www.lnsns.com/v1
Model ID：以当前模型列表为准
API Key：长任务专用令牌

长任务不等于把所有文件都发给模型。先确定入口目录、目标文件和排除目录。日志、构建产物、依赖目录和重复生成文件通常不需要进入上下文。减少无关输入，既能提高准确度，也能降低消耗和超时概率。

第五步：先让 Codex 建立项目地图

启动长任务前，先让 Codex 只读项目结构。任务可以限制为：列出指定目录、说明入口文件、指出主要依赖和潜在风险，不修改任何文件。这样可以先确认模型看到的项目范围是否正确。

cd D:\work\your-project
git status
codex

如果项目很大，可以先只读取 src、配置文件和测试入口。等项目地图建立后，再让 Codex 根据地图定位某个功能。不要一开始就要求它同时理解前端、后端、部署和数据库。

• 确认当前目录正确。
• 确认版本控制工作区状态。
• 确认读取范围没有包含敏感文件。

第六步：用检查点拆分修改任务

每个阶段都应该有一个可以检查的结果。比如完成分析后，让 Codex 输出问题范围和待修改文件；完成计划后，让它列出风险和测试方式；完成修改后，让它说明具体变更和测试结果。

检查点 1：问题范围和目标文件
检查点 2：修改方案和风险
检查点 3：已修改文件和差异摘要
检查点 4：测试命令和结果
检查点 5：剩余问题和回退方式

如果某一步结果不符合预期，立即回到上一个检查点，不要让错误继续积累到后面的修改阶段。长任务的稳定性，很大程度上来自这些人为设置的暂停点。

✅ 第七步：用轻量测试确认长任务线路

保存并启用长任务卡片后，关闭旧 Codex 和 PowerShell，再打开新终端。先在空目录完成一个只读任务，再进入项目。界面上的测试成功不能替代新进程验证。

mkdir codex-long-task-check
cd codex-long-task-check
codex

短任务成功后，再在项目中读取少量文件。如果短任务稳定而项目任务超时，先减少上下文和输出长度；如果短任务也失败，回到地址、令牌和网络检查。

⏱️ 长任务超时与上下文过大的处理方式

如果短请求也出现 401、403、404 或连接失败，应先处理配置和服务问题；如果只有长任务失败，优先调整任务规模和上下文。

• 一次只读取指定目录，不扫描整个仓库。
• 把长日志先压缩成错误摘要，再定位代码。
• 让模型先输出计划，不直接生成大量代码。
• 把大型改动拆成多个小提交或小步骤。
• 减少历史对话和重复粘贴的上下文。

长任务常见错误定位

记录错误码、卡片名称、任务阶段和时间，不记录完整 API Key。排错时一次只改变一个变量。

• 401：检查长任务卡片使用的专用令牌。
• 403：检查额度、分组和模型权限。
• 404：检查 *ase **L 是否重复 /v1。
• model not found：重新复制当前 Model ID。
• 长任务超时：缩小读取范围和输出长度。
• 切换不生效：关闭旧进程后重新启动。

长期维护：给长任务保留恢复路径

长任务运行时间较长，更需要主线路和恢复线路。主线路用于日常项目，实验线路用于新模型，恢复线路保留已知可用参数。出现异常时，先保存当前项目状态，再切回恢复线路做小任务验证。

需要查看当前模型、令牌和服务信息时，通过可点击的灵能API官网入口进入：https://www.lnsns.com/。实际页面信息优先于旧截图。

• 长任务使用独立配置卡和令牌。
• 每个阶段都有可检查的输出。
• 修改前确认 Git 或其他版本控制状态。
• 完整 Key 不进入截图、仓库和日志。

最终清单：长任务开始前检查八项

按检查点推进，长任务就能从一次不可控的连续对话，变成一组可以观察、暂停和回退的开发步骤。

• 当前工作目录是目标项目。
• 配置卡名称明确，长任务线路已启用。
• *ase **L 和 Model ID 来自当前服务信息。
• 长任务令牌与日常线路分开。
• 已排除依赖目录、构建产物和敏感文件。
• 任务已经拆分并设置检查点。
• 空目录和短任务测试通过。
• 项目有版本控制和恢复方式。