AI写代码为何总把环境配置写死

AI 编程助手为了让当前运行通过，可能顺手把 URL、存储桶名或连接字符串写进源码。问题往往要等到部署才暴露：代码没变，目标环境变了，程序却仍连着原来的资源。

作者给出的办法是：把随环境变化的值集中到一个配置入口，启动时检查，缺少必填项就报错。这篇没有性能测试或事故统计，但它把一个容易被「本地跑通」掩盖的问题讲清楚了，也给出了适合放进 AI 编程任务和代码审查的约束。

为什么 Agent 总想先填一个能用的值

硬编码是通往运行成功的短路。Agent 需要一个地址才能继续，任务又没有交代环境配置，直接填进去就能消除眼前的报错。作者还提出，训练数据里充满写死端点的示例；如果任务没有明确要求配置外置，Agent 就容易优先追求当前机器上的可运行性。

这里对 Agent 行为的解释属于作者观点，原文没有实验验证，也没有比较不同模型的发生率。

真正明确的是后果：生产环境可能连上开发数据库；主机名变更可能迫使团队重新构建；凭据提交后，轮换还要修改源码。它们最初都可能藏在一次成功运行背后。

当前运行通过，只能证明这个值适用于当前环境。

哪些值该搬出去，哪些常量可以留下

判断标准不是「源码里有没有字符串」，而是这个值会不会随环境或部署变化。

开发、预发布和生产使用不同的 URL、存储桶名或连接字符串，这些属于环境配置。固定分页大小、各环境都相同的已知常量，则可以继续放在代码里。把稳定常量也搬出去，只会让读代码的人多绕一层。

作者也区分了另一类问题：把某台机器的绝对路径提交进仓库，同样会破坏可移植性，但它和环境配置的边界不同。前者把机器条件带进了代码，后者处理的是各环境确实需要不同取值的参数。

因此，审查重点应该落在值的用途上。看到一个地址，要追问它是否绑定某次部署，而不是只检查它有没有被提取成常量。

一个配置入口，要同时管读取、校验和默认值

作者建议只设一个加载点：在单一模块读取环境变量，再向其他模块提供有类型的配置值，避免业务代码到处读取进程环境变量。

集中入口的价值不只是代码整齐。团队可以在一个地方列出全部环境依赖，检查必填项是否齐全，也能核对是否有变量绕过启动检查。读取散落各处时，缺失变量、废弃变量和秘密的引用位置都更难查。

校验应当发生在应用开始处理流量之前。必填变量既要存在，也要格式正确；校验失败时，给出清楚的错误信息并停止启动。

默认值尤其容易制造假象。非敏感、非关键配置可以有安全回退，但不能在缺少生产配置时，悄悄回退到真实的开发资源。程序继续运行了，数据却可能写错地方。

必填配置缺失时，报错比猜一个能用的值更可靠。

本地开发可以使用被 .gitignore 排除的 .env，并记录所需变量。生产环境则优先使用托管秘密存储，由平台注入。原文没有指定具体服务或校验库，也没有提供实现代码。

作者还用 Powerduck 举例：它通过 globals、collection、environment、local 作用域保存环境相关变量；缺少 base URL 时会询问，而不是自行猜测。这说明了请求配置中的同一条规则，但原文没有给出该产品的对照测试。

我的判断

我认同把「配置外置」写进任务要求，而不是等 Agent 自觉处理。它把模糊的工程习惯变成了可以检查的交付条件：是否存在统一入口，新增变量是否参与校验，差异里是否出现了绑定环境的字面量。

但集中读取并不自动带来正确配置。原文没有说明如何检查 URL 是否指向预期环境，也没有覆盖变量优先级、配置更新后的生效方式。这些仍需要团队补充规则。格式合法的地址，也可能是错误环境的地址。

与到处读取环境变量相比，统一入口更容易审查；与外置全部常量相比，只外置随部署变化的值更克制。不过，这些是工程经验，作者没有提供维护成本或故障率的对照数据。

前端团队还需要补上一条边界：进入浏览器代码的配置会暴露给用户，放进环境变量也不能让秘密变安全。此外，构建时替换的配置仍会进入产物；如果希望同一份前端产物部署多次，就需要另行设计运行时加载方式，原文没有展开这一点。

能拿来做什么

• 给 Agent 下任务时，明确要求环境相关值经过统一配置模块读取，必填项参与启动校验，并拒绝新增绑定具体环境的字面量。
• 在 Node 服务中梳理 URL、存储桶名和连接字符串，把必填配置的检查前移到启动阶段，避免请求到来后才发现缺失。
• 检查现有默认值，优先处理会连向真实开发资源的回退逻辑；缺失必填项时直接报错。
• 为本地开发记录所需变量，将 .env 加入 .gitignore；前端项目另外检查配置是否进入浏览器产物，避免把秘密交给客户端。