AI 编程最容易出事故的地方，往往不是模型不会写代码，而是它读错了环境：本地能跑，预发接口错了；测试库能连，生产密钥也被写进了示例；让 AI “帮我改配置”，结果它顺手把所有环境改成同一套地址。
如果你已经在用 Cursor、Claude Code、Codex 维护真实项目，多环境配置就不能只靠口头提醒。它需要一套能被 AI 读取、能被人复核、能在上线前检查的流程。更多 AI 编程工具的长期使用方法，可以先看AI编程工具专题和老达AI实践专题。
先把环境分清楚，不要让 AI 猜
多环境配置的第一步，是把“环境”写成明确清单，而不是让 AI 从文件名里猜。至少要区分：
- local：本地开发环境，允许连接本机服务、沙盒账号和假数据。
- test：测试环境，主要用于自动化测试、接口联调和临时验证。
- staging：预发环境，尽量接近生产，但仍然不能使用生产密钥。
- production：生产环境，任何改动都需要更严格的审批、备份和回滚准备。
这一步建议写进项目规则文件，比如 AGENTS.md、CLAUDE.md 或 Cursor Rules。不要只写“不要动生产”，而要写清楚哪些文件属于示例、哪些变量只能从部署平台注入、哪些配置不能提交到仓库。此前写过的Cursor Rules、CLAUDE.md、AGENTS.md 同步清单，可以作为规则文件整理参考。
给 AI 的不是密钥，而是配置地图
很多人让 AI 改环境变量时，会把真实 .env 文件直接塞进上下文。这样做省事，但风险很高。更稳的做法是准备一份配置地图：
.env.example：只保留变量名、用途和示例格式，不写真实值。docs/config.md：说明变量来源、作用范围、默认值和是否必填。deploy/env-checklist.md：列出上线前需要核对的变量、负责人和验证方式。- 部署平台变量截图或导出清单：只保留变量名和状态，不暴露真实密钥。
给 AI 的任务说明可以这样写：
请只根据
.env.example和docs/config.md修改配置读取逻辑，不要创建真实密钥，不要把任何生产变量写入仓库。涉及生产环境的值，只保留变量名和注释，最终由部署平台注入。
这样 AI 仍然能理解项目结构，但不会拿到不该拿的内容。这个思路和AI编程安全检查清单是一致的：先控制输入范围，再让工具执行。
配置文件要分层，不要到处 if else
AI 很容易为了“快速修好”在业务代码里到处加判断：如果是生产环境就用 A，如果是本地环境就用 B。短期看能跑，长期会让配置散在各个模块里。
更好的结构是把配置集中到一层：
- 读取层：只负责读取环境变量和默认值。
- 校验层：检查必填变量、URL 格式、数字范围和布尔值。
- 导出层：把业务代码需要的配置对象导出，业务层不直接读
process.env。 - 测试层：用固定假值验证配置缺失、格式错误和环境切换。
如果项目已经有配置模块，就要求 AI 沿用现有入口，不要新建第二套配置系统。你可以把任务写得更具体：
请先搜索项目里现有的配置入口，只在同一个模块里补充新变量校验。不要在业务文件里直接读取环境变量。修改后补充一个配置缺失时的测试用例。
这类任务特别适合配合AI编程接口联调流程一起做，因为接口地址、鉴权方式、超时和重试配置都依赖环境变量。
每个环境都要有验收动作
多环境配置不是“代码能启动”就算完成。至少要为每个环境设计一个可执行的验收动作：
- local：能启动服务，能连接本地或沙盒依赖，不能误连生产库。
- test：自动化测试能跑完，缺少必填变量时能给出清晰错误。
- staging：核心接口能联通，回调地址、域名、支付或登录配置不串环境。
- production：上线前只核对变量存在和格式，不在本地打印真实密钥。
建议把验收动作写成命令或清单，让 AI 在改完后自己执行能执行的部分，人再复核高风险部分。例如：
npm run test:config：验证配置校验逻辑。npm run env:check：检查必填变量是否存在。npm run test:integration：在测试环境验证接口联通。- 上线检查表：人工确认生产变量由部署平台注入，没有写进仓库。
如果你还没有形成上线前门禁，可以参考AI编程上线检查清单，把环境变量核对加进去。
最该防的 5 个坑
让 AI 改多环境配置时，最常见的问题有 5 类：
- 把真实密钥写进示例文件：
.env.example只能写占位符和说明。 - 测试环境复用生产地址：尤其是数据库、支付、短信、邮件和 Webhook。
- 前端变量暴露后端密钥：浏览器可见变量不能放服务端密钥。
- 日志打印完整配置：启动日志可以打印变量名和是否存在，不要打印真实值。
- 回滚只回代码不回配置：配置变更也要有记录，不能只看 Git diff。
这些坑不复杂，但一旦线上出错，排查成本会很高。AI 编程工具越能自动改文件，越要把这类边界写成规则。
一套可复用的提示词
下面这段可以直接放进 Cursor、Claude Code 或 Codex 的任务说明里，根据项目名称替换即可：
请为当前项目梳理多环境配置。先读取现有配置入口、
.env.example、部署说明和测试命令；然后列出 local/test/staging/production 的变量差异。只允许修改配置读取、校验、示例文件和相关测试，不要写入真实密钥，不要改业务逻辑。完成后运行可用测试，并输出需要人工在部署平台核对的变量清单。
如果项目较大，可以要求 AI 先只做“配置地图”，不要马上改代码。等你确认变量边界之后，再让它进入修改阶段。
老达点评
AI 编程多环境配置的关键，不是记住每个工具的命令，而是把环境边界从“人脑经验”变成“项目可读取的规则”。Cursor、Claude Code、Codex 都很适合处理重复配置和测试补充，但前提是你给它的是变量地图、权限边界和验收清单，而不是一份混着真实密钥的 .env。
对个人站长、小团队和独立开发者来说，最现实的做法是先补齐 .env.example、配置说明和上线检查表。等这三件事稳定后，再让 AI 帮你逐步整理配置模块、补测试、减少线上环境事故。
