AI 编程怎么防代码泄露：从零到跑通的 3 道闸

先给结论：防代码泄露靠的是三道闸叠加，不是某一个开关——上下文闸门决定哪些内容会被读走，通道闸门决定这些内容去哪，出口闸门决定最终提交出去的是什么。只关遥测或者只信厂商承诺，都挡不住一次误操作。

担心代码泄露的人通常卡在两个极端：要么因为合规要求完全禁用 AI 编程工具，要么什么都不管直接用。实际上多数团队的真实需求是"能用，但别把仓库里的密钥和客户信息带出去"，这个需求是可以被工程化满足的。

本文给出三道闸的具体搭法、每一步可验证的检查点，以及三类最常见的失败，并说清这套方案的适用边界。示例用命令行与配置文件演示，不绑定某一家工具，思路在各家 AI 编程工具上都通用。

先看结论

• 第一道闸（上下文）：用工具自带的忽略文件排除敏感目录，只把必要的片段喂给模型。
• 第二道闸（通道）：涉密项目走本地模型或明确零留存的企业版，不要走默认公共接口。
• 第三道闸（出口）：提交前用钩子扫一遍 diff，密钥、内网域名、客户名一律拦下。

钩子机制的完整说明见 Git 教程。

一、最小场景与预期行为

把任务定死：一个含数据库密码与内网域名的项目，要用 AI 编程工具辅助改代码，要求 .env、证书目录、客户名单文件不进入模型上下文，且提交前能自动拦住误带的密钥。

输入是项目目录加两份配置文件。预期行为是：工具索引完成后，在它的上下文里搜不到 .env 的内容；提交时若 diff 里出现密钥特征，钩子直接失败并给出提示。

project/
├── .env                 # 数据库密码，禁止进上下文
├── certs/               # 证书目录，禁止进上下文
├── data/customers.csv   # 客户名单，禁止进上下文
└── src/

判断这件事有没有做到，不看工具界面显示什么，看两处证据：一处是索引完成后能否在上下文中检索到敏感文件的内容，另一处是提交钩子是否真的拦住过一次。

二、三道闸门的完整搭法

2.1 第一道闸：只喂必要的上下文

多数 AI 编程工具都有独立的忽略文件，名字类似 .cursorignore、.codeiumignore，语义接近 .gitignore 但不是同一个文件。这一点最常被忽略：以为 .gitignore 里写了就万事大吉，实际上工具读的是自己的那份配置。

# .cursorignore
.env
.env.*
certs/
data/
*.pem
*.key

这份配置做的是：排除环境变量文件、证书目录、数据目录，以及所有私钥文件。写完后需要重启一次索引，让工具重新扫描目录——多数工具不会实时响应忽略文件的变化。

第二个动作是喂上下文时改用显式引用：需要改哪个文件就引用哪个文件，不要图省事选"整个仓库"。显式的代价是多点几下，收益是上下文里永远只有你在改的那一块。

第三个动作是脱敏：示例代码里的真实域名、客户名、密钥在提问前先换成占位符。这一步没有工具能代劳，只能靠习惯。

2.2 第二道闸：选对模型通道

通道分三档，按项目敏感度选：

本地模型的搭法：

ollama pull qwen2.5-coder:7b
ollama serve

这两条做的是拉取一个本地编码模型并启动本地服务。之后在编辑器插件里把模型地址指向 http://localhost:11434，请求就完全不出本机。

代价要说清楚：本地小模型的补全质量明显弱于云端大模型，复杂重构任务会吃力。常见做法是按任务分流——涉密仓库用本地模型，公开项目用云端模型。

2.3 第三道闸：提交前的出口检查

前两道闸都可能失手，出口检查是最后一道兜底。用 git 的 pre-commit 钩子扫 diff：

#!/bin/sh
# .git/hooks/pre-commit
if git diff --cached | grep -nE '(sk-[A-Za-z0-9]{20,}|password\s*=\s*["'"'"'][^"'"'"']{6,})'; then
  echo "提交被拦截：diff 中疑似包含密钥，请移除后再提交。"
  exit 1
fi
exit 0

这段做的是：在提交前取出暂存区的 diff，用正则匹配两类高危特征（形如 sk- 的令牌、明文 password 赋值），命中就退出非零让提交失败。

预期结果（未在本机执行，依据 git 钩子在非零退出时终止提交的既定行为）是：命中特征时提交被拦下并打印提示，未命中时正常提交。

正则不必一步到位，先覆盖本项目真实出现的密钥形态就够了。比工具更重要的是"每次提交都会跑"这件事本身。

2.4 四个必须提前确认的点

• 适用边界：三道闸挡的是"误操作"，挡不住有意为之的复制粘贴。截图、剪贴板这类行为不在覆盖范围内，只能靠流程约束。
• 安全红线：第二道闸是唯一能决定数据去向的环节，涉密项目不要在这一档上妥协。
• 性能代价：本地小模型的补全质量弱于云端大模型，复杂重构会明显吃力，按任务分流比一刀切更划算。
• 失败处理：忽略文件写错、钩子正则过宽都会失手，所以要留验证动作，不要假设配好就自动生效。

三、用最小示例跑一遍

验证第一道闸有没有生效，用一个可复现的小实验：

1. 在项目根目录建一个 secret-canary.txt，内容写一句唯一的标记串
2. 把它加进忽略文件，重启工具索引
3. 在对话里问："项目里有没有包含 canary 这个词的文件？"
4. 预期：工具回答找不到，或明确列出被忽略的文件名

这段做的是放一个"金丝雀"文件验证忽略规则。文件本身无害，但如果工具能说出标记串的内容，说明忽略配置没生效，需要检查文件名匹配是否写对。

第三道闸的验证更简单：故意在代码里写一行 const password = "test123456"，执行 git commit，预期是被拦下。

四、常见失败与验证清单

4.1 以为关掉遥测就够了

遥测和代码上下文是两件事。遥测关掉只影响使用行为统计，代码是否上传由索引与请求逻辑决定。判断依据是抓包或看本地代理日志，而不是看设置里那个开关。

4.2 .gitignore 与工具的忽略文件搞混

两者文件名不同、读取方不同。.gitignore 只影响 git，工具的忽略文件才影响上下文。两份都要写，内容可以保持一致。

4.3 截图和剪贴板绕过所有闸门

把代码截图发给在线模型，或者复制到网页对话框里，前面三道闸全部失效。这类行为属于流程问题，只能靠团队约定与培训解决，技术上拦不住。

4.4 验证清单

• 检查：确认忽略文件存在，且包含 .env、证书、数据目录
• 运行：重启工具索引，用 canary 文件验证搜索不到
• 运行：故意提交一行明文密码，确认钩子拦截
• 预期：两处验证都符合预期
• 失败：canary 被检索到 → 忽略文件名写错或未重启索引
• 修复：核对文件名与通配符，重启索引后重试
• 验证：换一个目录再放一次 canary，确认规则覆盖子目录

上面这些步骤做的是验证忽略规则、验证提交钩子、复测子目录覆盖。预期结果（未在本机执行）是两处都拦住；若 canary 被找到，先查文件名再查索引重启。

总结

防代码泄露是三道闸的叠加：上下文闸门控制被读走的范围，通道闸门控制数据去向，出口闸门兜住最终产物。任何单独一道都不够，但三道一起足以覆盖绝大多数工程场景。

三条要点带走：

• .gitignore 不等于工具的忽略文件，两份都要写；
• 涉密项目走本地模型，代价是补全质量下降，可以按任务分流；
• 出口钩子用 diff 扫描，正则先覆盖本项目真实出现的密钥形态。

下一步建议把忽略文件与 pre-commit 钩子放进项目模板，新仓库一初始化就带上，避免靠人记住。钩子写法记不清时，翻 Git Magic 教程 最快。

常见问题

Q：关掉遥测是不是就不会上传代码了？

A：不是。遥测是使用行为统计，代码上传由索引与请求逻辑决定。要判断得看实际请求，不能只看开关。

Q：本地大模型能完全替代云端模型吗？

A：质量上有差距，复杂重构会吃力。常见做法是按任务分流，涉密仓库用本地，公开项目用云端。

Q：忽略文件写了为什么还是能搜到？

A：先查文件名是否写错（比如 .cursorignore 与 .gitignore 搞混），再查是否重启了索引。多数工具不会实时响应配置变化。

Q：pre-commit 钩子会不会误拦正常提交？

A：会，正则太宽时容易误报。先从本项目真实出现过的密钥形态写起，逐步补充，比一上来写通用正则更实用。

Q：截图问模型算不算泄露？

A：算。截图与剪贴板会绕过所有技术闸门，属于流程问题，只能靠团队约定约束。

延伸学习

想把这套防护补完整，可以按这个顺序来：

1. 想系统学一遍 AI 编程工具的用法，可以跟一遍 AI 编程技能教程；
2. 读一篇相关笔记 Git 提交后怎么撤销，把提交环节的补救办法看清；
3. 再收一份 git 常用命令，把日常会用到的命令归拢到一起。