先说结论：密钥泄漏不是"小心点"能解决的问题。要在 AI 干活前就把拦截器装好。删 commit 救不了你，轮换才救得了。我一开始也以为这是安全意识问题。后来看到数据，改主意了。【一、AI 让你写得快，也让你漏得快】GitGuardian《State of Secrets Sprawl 2026》几个数字：- 2025 年公开 GitHub 新增 2865 万条硬编码密钥，同比 +34%，增幅创年度纪录- AI 辅助提交的密钥泄漏率 3.2%（Claude Code 辅助提交），人工基线 1.5%，翻倍- AI 服务相关密钥泄漏 +81%，一年 127.5 万条；DeepSeek 的 API key 漏了 11.3 万条GitHub 官方博客（2026-10-07）：2026 Q2 共 5.74 亿次 push，0.47% 携带已检测到的密钥。每 200 次 push 就有一次带着密钥出门。【二、真实事故】一个创业者的 AI 编码 app，前端代码里写了 Stripe secret key，攻击者给 175 个客户各扣了 500 美元，合计 $87,500。有人让 AI 写 JWT，AI 把 signing secret 写成字符串字面量，拿到就能伪造任意用户 token。有人把 API key 同时漏在公开 repo 和前端 bundle 里，一夜烧光余额。前端 bundle 是重灾区：100 个 AI 构建的 SaaS 里 34% 能从前端 JS 直接抠出 API key。【三、为什么 AI 特别会漏】一是训练数据里全是硬编码，模型按最熟悉的模式生成；二是你把含密钥的代码喂给了它，它照抄还扩散；三是前端 bundle 天生暴露，编译后打开 DevTools 就能看。边界：Claude Code 的 permissions.deny 建议是对的，但它挡"AI 读你的密钥"，挡不住"AI 写一个硬编码密钥"。【四、三道拦截器 + 一道前端检查】拦截器 01 提示词纪律：项目根目录建 .cursorrules / CLAUDE.md，写死"禁止硬编码密钥、一律环境变量读取、禁止在注释日志里写密钥值"。Claude Code 再补 permissions.deny 排除 .env。坑 1：.cursorrules 本身不会被 CI 执行。拦截器 02 提交前本地扫描：brew install gitleaks然后把 gitleaks protect --verbose --redact --staged 挂到 pre-commit（.git/hooks/pre-commit 或 pre-commit 框架 v8.16.1）。单 Go 二进制，一次 commit 增加不到一秒。备选 detect-secrets / trufflehog。拦截器 03 push 平台拦截：GitHub 开 push protection，密钥进 push 直接被拒，绕过要填理由且不消除 alert。GitHub 10-13 更新了检测模型：接受率 +11.5%，扫描耗时 -86%。前端 bundle 检查：grep -rE “sk-[A-Za-z0-9]{20,}|AKIA[0-9A-Z]{16}|service_role” dist/ .next/。搜出东西说明密钥被打包进客户端了。【五、漏了怎么办：先轮换，再清理】1. 立即去服务商后台撤销/轮换密钥——救命的步骤2. 再处理历史：git filter-repo 清历史 + 强制推送3. 检查服务商账单/日志坑 2：删 commit ≠ 删密钥。2022 年确认有效的密钥到 2026 年 1 月仍有 64%+ 有效。密钥进过公开仓库，就当它已经公开。坑 3：扫描只做一次 = 没做。【反方说两句】扫描器不是银弹，只认已知模式；小项目别过度工程，玩具项目一把 gitleaks 就够；根因还是提示词纪律，前置是让 AI 不写硬编码（个人经验，供参考）。密钥进了 git，就不是密钥了，是公开情报。互动问题：你有没有遇到过"AI 把密钥写进代码"的情况？最后是扫描器抓到的，还是账单先告诉你的？
先说结论：密钥泄漏不是"小心点"能解决的问题。要在 AI 干活前就把拦截器装好。删 commit 救不了你，轮换才救得了。我一开始也以为这是安全意识问题。后来看到数据，改主意了。【一、AI 让你写得快，也让你漏得快】GitGuardian《State of Secrets Sprawl 2026》几个数字：- 2025 年公开 GitHub 新增 2865 万条硬编码密钥，同比 +34%，增幅创年度纪录- AI 辅助提交的密钥泄漏率 3.2%（Claude Code 辅助提交），人工基线 1.5%，翻倍- AI 服务相关密钥泄漏 +81%，一年 127.5 万条；DeepSeek 的 API key 漏了 11.3 万条GitHub 官方博客（2026-10-07）：2026 Q2 共 5.74 亿次 push，0.47% 携带已检测到的密钥。每 200 次 push 就有一次带着密钥出门。【二、真实事故】一个创业者的 AI 编码 app，前端代码里写了 Stripe secret key，攻击者给 175 个客户各扣了 500 美元，合计 $87,500。有人让 AI 写 JWT，AI 把 signing secret 写成字符串字面量，拿到就能伪造任意用户 token。有人把 API key 同时漏在公开 repo 和前端 bundle 里，一夜烧光余额。前端 bundle 是重灾区：100 个 AI 构建的 SaaS 里 34% 能从前端 JS 直接抠出 API key。【三、为什么 AI 特别会漏】一是训练数据里全是硬编码，模型按最熟悉的模式生成；二是你把含密钥的代码喂给了它，它照抄还扩散；三是前端 bundle 天生暴露，编译后打开 DevTools 就能看。边界：Claude Code 的 permissions.deny 建议是对的，但它挡"AI 读你的密钥"，挡不住"AI 写一个硬编码密钥"。【四、三道拦截器 + 一道前端检查】拦截器 01 提示词纪律：项目根目录建 .cursorrules / CLAUDE.md，写死"禁止硬编码密钥、一律环境变量读取、禁止在注释日志里写密钥值"。Claude Code 再补 permissions.deny 排除 .env。坑 1：.cursorrules 本身不会被 CI 执行。拦截器 02 提交前本地扫描：brew install gitleaks然后把 gitleaks protect --verbose --redact --staged 挂到 pre-commit（.git/hooks/pre-commit 或 pre-commit 框架 v8.16.1）。单 Go 二进制，一次 commit 增加不到一秒。备选 detect-secrets / trufflehog。拦截器 03 push 平台拦截：GitHub 开 push protection，密钥进 push 直接被拒，绕过要填理由且不消除 alert。GitHub 10-13 更新了检测模型：接受率 +11.5%，扫描耗时 -86%。前端 bundle 检查：grep -rE “sk-[A-Za-z0-9]{20,}|AKIA[0-9A-Z]{16}|service_role” dist/ .next/。搜出东西说明密钥被打包进客户端了。【五、漏了怎么办：先轮换，再清理】1. 立即去服务商后台撤销/轮换密钥——救命的步骤2. 再处理历史：git filter-repo 清历史 + 强制推送3. 检查服务商账单/日志坑 2：删 commit ≠ 删密钥。2022 年确认有效的密钥到 2026 年 1 月仍有 64%+ 有效。密钥进过公开仓库，就当它已经公开。坑 3：扫描只做一次 = 没做。【反方说两句】扫描器不是银弹，只认已知模式；小项目别过度工程，玩具项目一把 gitleaks 就够；根因还是提示词纪律，前置是让 AI 不写硬编码（个人经验，供参考）。密钥进了 git，就不是密钥了，是公开情报。互动问题：你有没有遇到过"AI 把密钥写进代码"的情况？最后是扫描器抓到的，还是账单先告诉你的？