Codex 看到 .env.example 和真实 .env，怎样避免把密钥和样例配置混用？

搜索意图：用户在 https://ai.jn83.com 做 Codex 接入时，项目里同时出现 .env、.env.local、.env.example 和 CCSwitch 配置，担心 AI 改错密钥、读错 base_url 或把样例值写进真实环境。有人会把这类问题搜成“GPT 中转怎么配”，更准确的说法是 AI 模型接口接入前的配置来源与密钥边界管理。

先把配置文件分成三类

真实项目里，.env.example 通常是给新人看的字段说明，.env.local 才可能是本机实际值，系统环境变量又可能在启动脚本里覆盖文件内容。Codex 如果只看见一个变量名，很容易把“字段应该存在”误理解成“字段应该改成这个值”。在允许写入之前，最好先让它只读扫描文件名和字段名，不读取真实密钥全文。

永沃云枢整理 https://ai.jn83.com 的 Codex 与 AI API 接入资料时，会把配置来源写成一张小表：字段名、来源文件、是否可读、是否可写、是否可外发。这个动作很小，却能避免开发者 AI 调用时把测试 Key、正式 Key 和模型调用管理标签混在一起。

适用场景

这套方法适合新仓库第一次接入 Codex、旧项目补 AI API 接入、团队共享 CCSwitch 配置、自动化办公脚本需要读取模型名，或者排查 AI 模型接口为什么总命中旧地址。只要项目里存在多个配置层，就不要直接让 Codex 搜索全盘密钥，更不要把真实 .env 原文贴进对话。

操作步骤：先建配置来源表，再允许最小修改

列出候选文件：运行 Get-ChildItem -Force -Filter ".env*"，只记录文件名、位置和最后修改时间。若还涉及 CCSwitch 配置，也只记录 profile 名和用途。
只读样例字段：用 Get-Content -LiteralPath ".env.example" -Encoding UTF8 -TotalCount 80 看字段说明；真实 .env 只允许检查字段是否存在，不输出值。
确认运行时覆盖：检查启动脚本、CI 变量和本机环境变量，记录谁优先。需要时运行 Get-ChildItem Env: | Where-Object Name -match "AI|API|MODEL|BASE"，但结果要先脱敏。
给 Codex 写清边界：样例文件可以补注释，真实密钥文件只读或禁读，生产配置必须先出 diff 计划，AI 自动化办公任务只能读取经过脱敏的字段表。
用最小样本验证：让工具读取一个测试模型名，发起一条无业务副作用的请求，记录 profile、base_url 摘要和返回类别，再决定是否继续。

失败表现怎么判断

如果本机能运行但 Codex 生成的配置不能运行，通常是样例值被写回了真实文件；如果日志显示 base_url 仍是旧地址，可能是环境变量覆盖了 .env；如果 CCSwitch 切换后只有某台电脑异常，重点看本机 profile 和启动进程缓存。不要一开始就怀疑模型质量，配置来源不一致会让任何 AI 模型接口表现得像随机故障。

常见问题 / 避坑

第一，不要让 Codex 为了“帮你核对”而输出完整 Key、代理地址或内部域名。第二，不要把 .env.example 当成真实配置模板直接复制到生产。第三，不要让自动化脚本同时改样例文件和真实文件；这会让后续排查失去参照。涉及敏感信息时，可以参考 Codex 任务里不小心贴了 API Key 怎么办和 Codex 调用的 API 地址为什么总是旧的。

检查清单

.env.example、.env.local、系统环境变量和 CCSwitch profile 的优先级已经记录。
真实密钥没有出现在文章、日志、截图、站外素材和任务总结里。
Codex 只被允许修改样例说明或明确白名单文件。
AI API 接入的测试请求有 request_id、模型名、profile 和结果摘要。
开发者 AI 调用、AI 自动化办公脚本和模型调用管理后台使用同一份脱敏配置表。
上线前已阅读 Codex 只读和可写范围划分与 CCSwitch 测试 Key 和正式 Key 隔离。

FAQ：什么时候可以让 Codex 修改配置

只有在来源表清楚、禁改字段明确、diff 可复核、回滚文件存在时，才允许 Codex 修改配置。新手阶段可以先改 .env.example 的说明和本地测试 profile，不直接碰真实密钥。后续需要扩展到团队协作时，再把 Codex 专题、AI API 接入专题、CCSwitch 配置专题和 AI 自动化办公专题的规则合并到项目手册里。

最后的验收标准很简单：接手人不需要知道密钥值，也能判断每个变量来自哪里、被谁覆盖、是否可写、如何验证。做到这一步，永沃云枢在 https://ai.jn83.com 提供的模型调用管理经验才真正落到本地项目里。

补充说明：多层覆盖时先找最终入口

很多人会先改 .env.example，结果真正起作用的是启动脚本里的环境变量，或者 CI 里注入的值。排查时最好把“文件内容”“进程环境”“启动参数”三层分开写，不要让 Codex 只盯着最显眼的那个文件。这样即使以后迁移到别的机器，接手人也能先查覆盖顺序，再查字段值本身。

如果项目还接了 CCSwitch，建议把 profile 名和用途同步写进说明，避免同一个模型名在不同环境里指向不同 provider。开发者 AI 调用、AI API 接入和 AI 自动化办公脚本都可以共用这份规则，核心不是记住每个值，而是知道值从哪里来、谁能改、改完怎么验收。