如何让你的密钥远离 AI 生成的代码和 Git 提交

AI 编程智能体很快，但它们有一个盲点：它们会毫不犹豫地把 API 密钥粘贴进文件、把令牌打印到日志里，或者把你本想保留在本地的 .env 提交上去。每一个拥有终端访问权限的智能体——Claude Code、Cursor、Gemini CLI、Codex——同样能读取你的 shell 配置和项目文件，而这恰恰是凭据最容易藏身的地方。本指南将带你完成一套实用的分层方案，让你的密钥既不会进入 AI 生成的代码，也不会进入你的 Git 历史。

为什么在 AI 时代这件事更重要

密钥泄露是软件领域最常见、代价也最高昂的错误之一，而 AI 助手从两个方面抬高了风险。第一，它们生成代码的速度很快，因此一个硬编码的密钥可能在你察觉之前就已经散落进十几个文件里。第二，智能体会大量地摄取上下文——正如一篇密钥管理文章所言，你的 shell 配置应当引用密钥，而不是包含密钥，因为智能体能读取你的 dotfiles 所暴露的任何内容。解决之道并不是去不信任工具；而是要从一开始就确保根本没有明文密钥供它发现。

第 1 步：把密钥放在环境变量里，绝不放进代码

基本原则：任何 API 密钥、密码或令牌都绝不应以字面字符串的形式出现在源代码中。把它们放进项目根目录下的 .env 文件，并在运行时读取。

# .env  — never committed
ANTHROPIC_API_KEY=sk-ant-...
DATABASE_URL=postgres://...

// app.js — reads from the environment, no secret in the file
const apiKey = process.env.ANTHROPIC_API_KEY;

这样一来，你（以及你的 AI 智能体）所编辑的代码就只包含密钥的名称，而绝不会包含它的值。

第 2 步：确保 .env 永远不会被提交

在你写下第一个密钥之前，就先把它加入 .gitignore：

.env
.env.local
*.env

改为提交一个带空占位符的 .env.example，好让协作者知道需要设置哪些变量：

ANTHROPIC_API_KEY=
DATABASE_URL=

如果你已经把一个真实的 .env 提交了上去，那么仅仅在新的提交中删除它是不够的——它仍然存在于历史记录中。请立即轮换被暴露的密钥，并将其视为已泄露。

第 3 步：开启 GitHub 推送保护

GitHub 的推送保护会在你推送时扫描提交，一旦发现密钥就会阻止这次推送，从而在泄露抵达远程仓库之前将其拦下。它能识别来自 AWS、OpenAI、Stripe 等众多提供商的 200 多种密钥模式，而 2026 年的更新进一步扩充了默认拦截的模式。对公开仓库而言它是免费的——在你仓库的 Settings → Code security 中即可启用。把它想象成一条安全带，专为智能体（或你自己）失手的那一刻而准备。

第 4 步：别让智能体收割你的 shell 配置

拥有 shell 访问权限的智能体能读取 .zshrc、.bashrc 和 .zshenv。如果你为了图方便把密钥导出到了那里，智能体就能看到它们。请把机器级别的密钥排除在你的 dotfiles 之外——按需从密钥管理器或操作系统钥匙串加载它们，而不是在 shell 启动时导出明文。

第 5 步：限定范围并定期轮换

两个习惯能在确实发生泄露时把损失降到最低，OpenAI 的 API 密钥安全指南也呼应了这一建议：

• 最小权限： 给每个密钥所需的最窄范围，并为每个项目和环境使用各自独立的密钥，这样一处泄露就不会把一切都暴露出去。
• 定期轮换： 按计划轮换密钥，并在你怀疑发生暴露时立即轮换。一个被轮换过的密钥能把一次入侵化为一桩无关紧要的小事。

一份快速清单

在你放手让智能体在某个仓库里施展之前：

1. 密钥存放在 .env 中，通过 process.env 读取——绝不硬编码。
2. .env 已加入 .gitignore；仅提交 .env.example。
3. 远程仓库已启用推送保护。
4. shell dotfiles 中没有明文密钥。
5. 密钥范围被严格限定并按计划轮换。

这一切一旦设置好便不会拖慢你的节奏——而且它能让你把更多工作交给你的 AI 智能体，同时少了许多需要担心的事。