为什么代码任务要先**再修改

代码项目中的一个问题，往往涉及入口、依赖、配置、测试和运行环境。直接让 Codex 修改，可能会让它只看到表面报错，却忽略真正的调用链。先**可以确认问题范围，也能让你知道模型实际读取了哪些文件。

• 阅读：确认入口、依赖和相关文件。
• **：指出风险、重复逻辑和潜在回归。
• 方案：列出准备修改的文件和步骤。
• 执行：只修改已经确认的范围。
• 测试：运行局部测试并说明结果。

第一步：选择适合代码**的模型

进入灵能API页面或控制台，查看当前模型列表、Model ID、输入输出价格和上下文信息。代码**通常会带入文件内容和历史上下文，因此要关注模型的代码理解能力和长内容稳定性。

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

• 单文件**：优先速度和基础理解能力。
• 跨文件分析：优先上下文容量和依赖理解。
• 复杂修改：优先稳定性和测试配合能力。

第二步：为项目**建立独立令牌

代码**可能会持续多轮，并消耗较多输入上下文。建议为项目**建立独立令牌，名称写清设备和项目用途。这样可以区分日常问答、项目**和实验调用，也便于异常时单独停用。

• 令牌名称：Codex-Review-Project。
• 完整 Key：只保存在本地私密位置。
• 共享截图：只展示字段位置，不展示真实密钥。

️ 第三步：在 CC Switch 中建立**线路

打开 CC Switch 的 Codex 配置页面，创建“灵能API-Codex-代码**”配置卡。不要直接覆盖日常主线路，**卡片可以单独指定模型和令牌。

创建后检查协议、*ase **L、Model ID 和 API Key。*ase **L 通常填写到 /v1，Model ID 从当前模型列表复制。复制已有配置卡后仍要逐项核对。

✍️ **步：先让 Codex 只读**

请只阅读 src/service.ts。
列出入口、外部依赖、异常处理和潜在风险。
不要修改文件，不要执行命令，不要读取其他目录。

第一轮**的目标不是立即得到修改代码，而是确认 Codex 是否理解了文件职责。若它读取了不应读取的文件，先缩小范围，不要继续下一阶段。

**结果可以要求固定格式：问题位置、问题类型、影响范围、建议优先级和是否需要测试。结构化输出更容易人工复核。

第五步：让模型先写修改方案

确认**结果后，再让 Codex 给出修改方案。方案至少要说明准备修改哪些文件、为什么修改、可能影响什么、准备运行哪些测试。方案阶段仍然不要直接写入。

请基于刚才的**结果给出修改方案。
只允许涉及 src/service.ts 和对应测试文件。
先列步骤、风险和验证命令，不要修改文件。

• 文件范围是否准确。
• 方案是否解决了**中的根因。
• 是否包含兼容性和回归风险。
• 测试命令是否能在当前项目中执行。

✅ 第六步：修改前检查版本控制状态

确认方案后，先检查项目当前状态。确保已有改动不会被混入本次任务，必要时先提交或建立临时分支。

cd D:\work\your-project
git status
git diff --stat

然后让 Codex 只执行已确认的文件修改。修改完成后先查看 diff，不要马上让它继续扩大范围。

第七步：先测试，再决定是否继续

切换配置后关闭旧的 Codex 和 PowerShell，重新启动新进程。进入项目前，可以在空目录做一条只读任务确认线路；进入项目后，优先运行与本次修改直接相关的局部测试。

npm test -- --runIn*and
# 或使用项目已有的局部测试命令

测试失败时，先让 Codex 解释失败原因和涉及文件，不要立即允许它大范围修复。一个好的验收结果应包含修改文件、测试命令、测试结果和剩余风险。

代码**中常见的线路问题

排错时保留卡片名、错误码和任务阶段，不记录完整 API Key 和项目敏感内容。

• 401：**卡片的令牌无效或没有启用正确线路。
• 403：检查额度、模型权限和令牌分组。
• 404：检查 *ase **L 是否重复 /v1。
• model not found：重新复制当前 Model ID。
• 回答突然变短：检查上下文范围和模型卡片是否切换。
• 修改范围扩大：重新指定允许修改的文件并结束当前计划。

代码**验收清单

把**、方案、修改和测试分开，Codex 才更容易成为可检查的协作工具，而不是一次性黑盒修改器。

• 模型和项目任务规模匹配。
• **线路使用独立配置卡。
• 第一轮只读，第二轮给方案，第三轮才修改。
• 修改前检查 Git 状态和 diff。
• 修改后运行局部测试并查看结果。
• API Key 没有出现在提示词、截图和仓库。