Codex 中转站代码**教程：灵能API CC Switch 分阶段检查、测试与修复
让 Codex 参与代码**，重点不是让它一次性扫描整个仓库，而是建立一套可复核的**流程。先固定线路，再限定范围，接着区分发现问题、修改代码和运行测试三个阶段，才能减少误改和遗漏。本文以灵能API与 CC Switch 为基础，整理一套适合日常开发的**方法。
代码**先明确‘看什么’
代码**的质量取决于目标是否清楚。一次**最好只聚焦一类风险，例如鉴权、异常处理、数据库访问或测试覆盖。把安全、性能、格式和业务逻辑全部混在一句话里，往往会得到一份很长但难以执行的清单。
把**拆成几个小任务，Codex 的输出更容易被人工复核，也方便将问题分配给不同成员。
- 范围：指定目录、文件或提交。
- 目标：明确要查的风险类型。
- 证据：要求引用文件和行号。
- 动作：先报告，后决定是否修改。
第一步：为**任务固定线路
进入灵能API服务入口，确认当前模型和接口参数，再为代码**创建一张专用配置卡。**任务需要稳定的上下文处理和一致的输出格式，测试期间不要频繁切换模型。
灵能API入口：https://www.lnsns.com/。真实 Key 不放进**提示词、仓库和输出记录。
- Model ID：使用当前可用的精确标识。
- *ase **L：按照当前接口说明填写。
- API Key：使用**任务专用或权限受控的令牌。
️ 第二步：在 CC Switch 中建立**卡片
卡片名称建议包含项目和**目标，例如‘we*-auth-security-review’。如果团队有只读**和可修改开发两种权限，应该分别建立卡片，避免在同一个环境里误执行写入命令。
三类卡片可以使用相同的模型，也可以按权限和任务特点区分，但名称和状态必须清晰。
- 只读**卡：用于分析和报告。
- 开发修复卡：在确认问题后使用。
- 测试验证卡：用于运行局部测试。
第三步：先限定**范围
进入项目后，让 Codex 先确认工作目录和 Git 状态。然后指定需要**的文件，不要默认扫描 node_modules、构建产物、缓存和日志目录。范围越明确，输出越容易核对。
Get-Location
git status --short
Get-ChildItem src -File -Recurse | Select-O*ject FullName- **提交：优先使用 git diff 或指定 commit。
- **模块：列出明确目录和入口文件。
- **规则：写明忽略目录和生成文件。
**步：只读阶段先输出问题清单
第一轮不要要求 Codex 直接修改。先让它输出问题、风险等级、证据位置、影响范围和建议验证方式。没有证据的判断不能直接进入修复阶段。
请只读** src/auth。
关注鉴权绕过、敏感信息日志和异常处理。
不要修改文件。
每个问题给出文件、行号、风险、证据和建议测试。
如果没有足够证据，请标记为待确认。输出结果先由人工筛选，区分真实缺陷、低风险建议和误报。不要把所有建议都当作必须修改的错误。
第五步：把确认的问题变成小修复
确认问题后，一次只修复一个主题，并提前说明允许修改的文件。对于鉴权或数据访问类问题，先让 Codex 解释拟议变更，再决定是否执行。
只修复已确认的鉴权问题。
允许修改 src/auth 和对应测试文件。
不要重构无关代码，不要更新依赖。
完成后展示 diff，并说明每处修改的原因。- 先展示 diff，再决定是否保留。
- 不接受与当前问题无关的顺手重构。
- 修改前确认工作区已有变更不会被覆盖。
第六步：测试必须和问题对应
修复后不要只运行一个‘全量测试’命令就结束。先运行直接覆盖问题的局部测试，再运行类型检查或构建，最后根据项目情况执行更完整的回归。每层失败时先停下来分析，不要连续改代码碰运气。
npm test -- auth
npm run lint
npm run *uild
git diff --check如果项目不是 Node.js，以项目现有脚本和文档为准，核心原则是测试顺序和问题之间要有对应关系。
- 局部测试：证明目标行为已经覆盖。
- 静态检查：发现类型、格式或明显错误。
- 构建验证：确认修改没有破坏产物。
第七步：形成可复核的**记录
一份好记录不需要复制整段对话，只需保留**范围、使用的配置卡、发现的问题、已接受或驳回的建议、实际修改和测试结果。敏感代码和完整令牌不应该进入共享记录。
记录的目的不是证明工具做了多少工作，而是让下一位维护者能快速判断这次**覆盖了什么。
- 范围：文件、提交或模块。
- 结论：问题等级和证据位置。
- 动作：修改文件和变更摘要。
- 验证：测试命令和结果。
代码**中的常见失误
当输出变得过长或结论互相矛盾时，回到只读、小范围和单主题的最小任务。
- 一上来扫描整个仓库，输出过多且难以筛选。
- 没有证据位置就接受高风险结论。
- **和修改在同一条指令中完成。
- 修改时顺便升级依赖或重构无关模块。
- 只跑全量测试，不运行直接对应的局部测试。
- 把带有项目秘密的完整对话保存到公共位置。
✅ 代码**验收清单
通过灵能API接入 Codex 后，把**拆成‘发现、确认、修复、验证、记录’五个阶段，工具才能真正融入日常工程流程。
- **目标和范围已经写清楚。
- CC Switch 使用了**用途的配置卡。
- 第一轮只读并要求提供证据位置。
- 人工确认后才进入修复阶段。
- 修复限制在允许的文件和主题内。
- 测试命令与问题直接对应。
- **记录没有暴露 API Key 和项目敏感信息。