先把任务分成三层

一个清晰的 Codex 任务，至少要分清目标、范围和限制。目标说明想得到什么结果，范围说明允许读取或修改哪些文件，限制说明哪些操作不能执行。缺少其中一项，模型就可能把任务扩大。

中转服务提供模型调用，任务边界仍然需要由用户明确设定。

• 目标：解决什么问题，最终需要什么结果。
• 范围：指定目录、文件、模块或命令。
• 限制：只读、不要删除、不要修改其他文件等。

第一步：根据任务选择模型

打开灵能API页面，查看当前模型 ID、上下文能力、输入输出价格和可用状态。短问答、代码阅读和项目级分析不一定需要同一模型。

模型选择时不要只看价格。对于代码任务，还要观察它是否能正确理解入口、依赖和修改边界。可以用同一份小样例比较两个模型，再决定哪张卡设为默认。

官网入口：https://www.lnsns.com/。实际模型和价格以当天页面为准。

• 短任务：速度和稳定性优先。
• 代码阅读：上下文理解优先。
• 长任务：上下文容量、输出质量和稳定性优先。

️ 第二步：在 CC Switch 中为任务角色建立卡片

不要每次在同一张卡片里临时替换模型。可以分别建立“灵能API-Codex-快速任务”“灵能API-Codex-项目阅读”和“灵能API-Codex-实验线路”，按任务切换。

复制卡片后重新核对 *ase **L、Model ID 和 API Key。配置名称只影响识别，真正影响请求的是字段内容和当前启用状态。

实验卡片测试完成后，不要立即覆盖主线路。先保留一段时间作为对照，确认响应稳定、用量可控，再决定是否替换默认模型。

✍️ 第三步：把上下文范围写进任务

请只阅读 src/**in.ts 和 src/config.ts。
说明入口、依赖和潜在风险。
不要修改文件，不要读取 node_modules，不要执行命令。

指定文件和排除目录，可以减少无关输入，也让输出更容易检查。项目很大时，先让 Codex 建立小范围地图，再逐步扩大范围。

**步：先计划，后修改

修改任务建议拆成四轮：阅读、分析、计划、执行。阅读阶段只看文件，分析阶段说明问题，计划阶段列出文件和步骤，执行阶段才允许写入。每轮结束后确认结果，再继续下一轮。

• 阅读：确认模型是否理解当前代码。
• 分析：确认问题范围和根因。
• 计划：确认文件、风险和测试方式。
• 执行：只修改已经确认的范围。

✅ 第五步：用小任务验证提示词和线路

切换卡片后关闭旧进程，重新启动 Codex。先在空目录发送只读任务，再进入项目读取一个文件。这样可以分开验证线路是否生效和任务描述是否清晰。

如果短任务正常、长任务异常，优先缩小上下文和输出；如果短任务也失败，检查地址、令牌、模型和网络。

任务跑偏时如何收回范围

如果上下文已经混乱，结束当前会话并从项目地图重新开始，通常比在错误上下文里不断补充解释更快。

• 让 Codex 停止修改，先总结当前已经完成的内容。
• 重新指定允许读取和修改的文件。
• 要求输出下一步计划，不立即执行。
• 检查 Git diff，再决定是否继续。

高效使用检查表

把这套方法固定下来，模型切换和项目任务都会更容易控制。

• 模型与任务类型匹配。
• CC Switch 卡片名称和用途清晰。
• 任务包含目标、范围和限制。
• 长任务设置了阶段检查点，不让一次请求承担所有工作。
• 长任务分成阅读、分析、计划、执行。
• 修改前检查版本控制状态。
• API Key 不进入提示词、截图和仓库。