先划红线:公司代码能往哪送,什么绝对不能送
分清三类绝对不能外送的东西,并在提交前跑一次机械自检
前三道门问的是能不能,这一道问的是该不该。
它是四道门里唯一一道“通过了也可能出事”的门:服务连得上、账号也有钱,一切正常,然后你把一段配置文件贴进对话框——里面带着数据库连接串。那一刻没有任何报错,没有任何拦截,你甚至会觉得这次 AI 回答得挺好。
这一节不讲法条,讲三件具体的事:哪三类东西绝对不能外送、它们最常从哪个缝里漏出去,以及一条你在按回车之前就能跑完的机械自检。最后一件最重要——因为靠记性防不住这类事故,所有人都以为自己不会犯,直到日志里那行密钥被贴出去。
寄快递的时候,决定“能不能寄”的从来不是快递公司好不好,而是箱子里装的是什么。同一家公司,寄本书没问题,寄易燃品就是违规——这跟服务质量、价格、送得快不快毫无关系。
把代码交给 AI 也一样。“这家服务靠不靠谱”和“这份东西该不该寄出去”是两个独立的问题。 很多人只回答了前一个就开始装箱,而真正会出事的是后一个。
三类绝对不能外送的东西
第一类:密钥与凭证。 API key、数据库密码、私钥、访问令牌、连接串。一旦离开你的机器,你就必须假设它已经泄露,唯一的补救是作废并换新,而不是“应该没人看到吧”。
第二类:个人信息。 真实姓名、手机号、身份证号、住址、订单里的收货信息。测试数据里带着真实用户信息,是这类事故最常见的现场。
第三类:受组织或法规管辖的数据。 公司内部代码、客户交付物、未公开的业务数据。这一类不取决于你觉得敏不敏感,取决于你的组织和适用法规怎么规定——所以它必须去问,不能自己判断。
最容易漏的那条缝:你根本没打算发的东西
前面三类,只要意识到了,大多数人都不会主动去发。真正的事故几乎都发生在顺手的时候:
- 报错信息一整段粘过去——堆栈里带着连接串或令牌。
- 让 AI 读整个目录排查问题——
.env、config.local.*、私钥文件一起被读走。 - 贴一段“样例数据”——那其实是从生产库里导出来的真实订单。
共同点是:你发的是“上下文”,不是“秘密”,所以那一刻你脑子里根本没有“我在外送敏感信息”这件事。防这类事故只能靠机械检查,不能靠自觉。
组织侧:上手之前先问清三件事
如果你在公司里用,先把这三件事问明白,一次问完:
- 有没有明文制度规定 AI 编程工具的使用范围?(有的话,以制度为准,本课的一切建议都排在它后面)
- 允许哪些供应方?有没有已经过审的名单?
- 日志与留存:公司要不要求可审计?你用的工具留不留会话记录?
问清楚再开工,比出事后解释便宜太多。这三个问题的答案也会反过来改写你上一节的选路结论——如果公司只批了某一家,那三条路对你其实只剩一条。
🔧 动手做:提交前的机械自检(4 分钟)
靠记性防不住,所以把它变成一条命令。在你打算交给 AI 的项目目录里跑:
grep -rIinE "(api[_-]?key|secret|passwd|password|token|BEGIN [A-Z ]*PRIVATE KEY)" . \
--exclude-dir=.git --exclude-dir=node_modules | head -30
那个 -i 不能省。写这一节时我第一版漏了它,拿一行 API_KEY = "sk-realkey123456789" 去试——一条都没查出来,而且退出得干干净净,没有任何报错。真实项目里的密钥变量名十有八九是大写的,少一个字母,这条命令就从“检查”变成了“安慰”。
再看一眼哪些文件会被一起带走:
git status --porcelain --ignored | grep -E "\.env|\.pem|\.key|config\.local" | head
先验红再信它:临时造一行 API_KEY = "sk-realkey123456789" 存成一个文件,跑一次上面的命令,确认它真的把这行打出来了,再把这个文件删掉。查不出来就说明命令抄错了——别用一个没验过的检查给自己发通行证。
你会看到:验红通过之后,真实结果通常分两类。一类是无害的(变量名叫 apiKey 但值是占位符),另一类会让你后背一凉——真实的密钥、私钥文件、被 .gitignore 挡住但还躺在目录里的 .env。后者就是你本来要顺手发出去的东西。
为什么:这条命令不依赖你当时的状态。累的时候、赶进度的时候、觉得“就这一次”的时候,它给出的结果都一样。会累的是人,不会累的是脚本——这也是主课工程方法那一章反复讲的同一件事。
顺带一提:我们自己开源过一个做这类体检的小工具(叫 ShellWard,专门扫 AI 项目里的密钥硬编码与个人信息暴露)。这是我们自己的项目,所以在这里说明利益关系;上面那两条命令不依赖它,你用原生命令就能完成这件事。
我要向你描述一个报错,但内容里可能含有密钥、连接串或真实个人信息。请先做一件事:把我下面这段内容中所有疑似敏感的部分替换成【已脱敏】,并列出你替换了哪几处、分别属于哪一类(密钥/个人信息/内部地址),然后再开始分析问题。以下是内容:【粘贴你的报错或配置】
密钥一旦离开你的机器,唯一正确的动作是立刻作废并轮换,不是庆幸没人注意到。判断标准很硬:你无法证明它没被记录下来。
同样地,发现自己发了不该发的东西之后,删掉那条对话不等于对方的日志里也没有了。该轮换的轮换,该报备的报备——这一步做起来很难受,但它是唯一真正有效的一步。
第四道门问的是“该不该”,它是唯一一道通过了也可能出事的门。三类东西绝对不能外送:密钥与凭证、个人信息、受组织与法规管辖的数据。最容易漏的不是你打算发的,而是顺手带出去的——报错堆栈、整目录读取、来自生产库的“样例数据”。防法只有一条:把检查变成一条不依赖状态的命令,在按回车之前跑完。组织侧的三个问题要提前问清楚,它们可能直接改写你上一节的选路结论。红线划完了,下一模块开始碰工具——但第一节不是“怎么装”,而是装之前先看清你要装的到底是什么。
🔎 来源与核验· 4 条,点开核对
