AI 编程中的隐私与安全：哪些信息不要提交

✍创作者：全栈弄潮儿
🏡 个人主页：全栈弄潮儿的个人主页
🏙️ 个人社区，欢迎你的加入：全栈开发社区
📙 专栏地址：AI 编程提效实战

AI 可以帮助我们分析报错、阅读代码和排查问题。

但在把内容发给 AI 之前，一定要先问自己一个问题：

这段内容如果公开了，会不会影响用户、公司或系统安全？

很多数据泄露并不是因为攻击，而是因为开发者为了让 AI 更好地分析，把完整日志、配置文件或业务代码直接复制了出去。

这篇文章不讨论复杂的安全理论，只讲开发中最容易遇到的几类数据，以及如何安全地使用 AI。

一、这 3 类信息不要直接提交

1. 密钥、Token 和账号信息

下面这些内容不应该直接提交给 AI：

• 数据库密码。
• 云服务 Access Key 和 Secret Key。
• 第三方 API Key。
• JWT、Cookie 和 Session。
• SSH 私钥和证书私钥。
• 生产环境的连接地址。
• 管理员账号和密码。

例如，下面这段配置就不能直接复制：

DATABASE_URL=mysql://admin:RealPassword@prod-db.example.com:3306/order PAYMENT_API_KEY=sk_live_xxxxxxxxxxxxxxxxx JWT_SECRET=real-secret-value

即使只是让 AI 帮你排查连接问题，也没有必要暴露真实密码和密钥。

可以替换成下面这样：

DATABASE_URL=mysql://user:<DB_PASSWORD>@<DB_HOST>:3306/<DB_NAME> PAYMENT_API_KEY=<PAYMENT_API_KEY> JWT_SECRET=<JWT_SECRET>

AI 通常只需要知道配置的格式、字段关系和报错信息，不需要知道真实的密钥值。

2. 用户和客户数据

真实用户数据同样不能随意提交，包括：

• 姓名、手机号、邮箱和身份证号。
• 地址、银行卡号和订单信息。
• 医疗、财务和身份认证信息。
• 用户上传的图片、文件和聊天记录。
• 包含个人信息的完整数据库导出文件。
• 带有 Cookie 或 Authorization 请求头的网络日志。

例如，不要把下面的真实接口日志直接发给 AI：

{"userId":"u_10086","phone":"13800138000","email":"zhangsan@example.com","authorization":"Bearer eyJhbGciOiJIUzI1NiIs..."}

可以改成虚构数据：

{"userId":"user_demo_001","phone":"138****0000","email":"user@example.test","authorization":"Bearer <ACCESS_TOKEN>"}

如果问题与用户具体身份无关，最好直接删除这些字段。

3. 未经授权的公司代码

公司代码不只是几个函数，还可能包含很多业务信息：

• 核心业务规则。
• 内部接口地址。
• 数据库表结构。
• 未公开的产品方案。
• 客户名单和供应商信息。
• 内部账号权限设计。
• 尚未发布的功能代码。

特别是下面几种情况，需要先确认公司规定：

• 把整个项目目录上传给 AI 工具分析。
• 把生产环境代码粘贴到个人账号中。
• 使用代码补全工具时开启整个仓库索引。
• 将内部接口文档复制到公共对话中。

不同 AI 工具的存储、训练和企业隐私策略并不完全相同，不能默认“不会保存”或“不会被使用”。使用前应查看组织规定和工具当前的隐私设置。

二、为什么打码还不一定安全

简单把一个手机号替换成星号，有时仍然可能泄露隐私。

例如下面这段内容虽然没有姓名，但仍然包含完整的订单、地址和时间信息：

用户在 2026 年 8 月 20 日 18:32 下单，收货地址为某市某区某街道 18 号， 订单金额 38,000 元，购买的是某客户专属设备。

这些信息组合起来，可能仍然可以定位具体客户。

脱敏时要注意以下几点：

• 删除解决问题不需要的字段。
• 将真实时间改成相对时间或虚构时间。
• 将真实地址改成城市级别或测试地址。
• 将真实金额替换成相近的测试金额。
• 将用户 ID、订单号替换成无关联的占位符。
• 不要只修改展示内容，却保留请求头中的 Token。

脱敏的目标不是让数据“看起来不像真实数据”，而是让数据失去识别具体对象的能力，同时保留排查问题所需的结构。

三、一个安全的报错提问方式

假设线上接口返回了 500 错误。

不建议这样提问：

这是线上完整日志，帮我看看为什么报错： [粘贴完整日志]

更安全的方式是先处理日志，再补充必要背景：

请帮我分析一个 Node.js + Express 接口的 500 错误。 接口用途：创建订单 运行环境：Node.js 20，MySQL 8 复现条件：提交包含商品列表的订单时出现错误 预期结果：返回订单编号 实际结果：服务返回 500 脱敏后的错误日志： [粘贴去除密钥、Token、手机号和地址后的日志] 相关代码： [只粘贴报错函数和必要的上下文] 请先分析可能原因，再给出排查顺序。 如果信息不足，请说明还需要哪些信息，不要猜测真实配置。

这类提问通常已经足够 AI 分析问题，不需要上传整个项目和完整数据库。

四、提交前的 4 步检查法

第一步：先判断数据类型

把准备发送的内容分成三类：

拿不准时，按敏感信息处理。

第二步：只保留必要内容

排查一个函数的问题，通常只需要：

• 函数代码。
• 相关类型定义。
• 最小化的输入数据。
• 完整错误信息中的关键部分。
• 运行环境和复现步骤。

不要为了“上下文完整”而提交整个仓库。

第三步：搜索常见敏感字段

提交前可以先在本地搜索：

rg-n-i"password|secret|token|api[-_]?key|authorization|cookie|private[-_]?key"./待提交内容

如果是 Git 仓库，也可以检查本次修改：

gitdiff--checkgitdiff--statgitdiff

看到密码、Token、Cookie 或内部域名时，先停止提交，确认是否需要删除。

第四步：检查工具和账号设置

使用 AI 工具前，至少确认：

• 当前登录的是个人账号还是公司账号。
• 当前对话是否会被保存。
• 是否开启了代码或数据用于改进模型的选项。
• 团队是否允许使用该工具处理源代码。
• 编辑器插件是否会读取整个项目。
• 是否可以使用企业版的隐私和数据控制功能。

工具提供“隐私设置”，不代表可以提交任何数据。公司的安全制度和数据合规要求优先级更高。

五、如果不小心提交了密钥怎么办

如果真实密钥已经发给了不应该接收它的工具或账号，不要只删除聊天记录。

应立即进行以下处理：

1. 立即禁用或轮换密钥。
2. 检查相关账号的访问日志。
3. 确认是否产生异常调用或费用。
4. 从代码、日志和提交记录中删除旧密钥。
5. 按公司流程报告安全事件。
6. 使用新密钥重新配置服务。

重点是“失效和轮换”，而不是“把内容删掉”。已经暴露的密钥不能继续使用。

六、可以直接使用的安全 Prompt

下面这段 Prompt 适合在提交代码前使用：

请先检查下面内容中是否包含敏感信息。 检查范围： 1. 密码、Token、Cookie、API Key 和私钥 2. 手机号、邮箱、身份证号和地址 3. 生产环境域名、数据库地址和内部服务信息 4. 未公开的公司业务信息 要求： - 不要复述任何敏感值。 - 只指出敏感信息的类型和所在位置。 - 给出删除或替换建议。 - 如果内容已经安全，再继续分析代码问题。 待检查内容： [粘贴已经初步脱敏的内容]

需要注意，这个 Prompt 只是额外检查，不能代替提交前的本地脱敏。

七、一份实用的安全清单

发送代码或日志给 AI 之前，可以快速确认：

• 没有密码、Token、Cookie 和私钥。
• 没有真实用户的身份和联系方式。
• 没有生产数据库连接信息。
• 没有未经授权的公司核心代码。
• 已删除与当前问题无关的内容。
• 已确认当前 AI 工具和账号符合团队规定。
• 已使用虚构数据验证提问是否足够。
• 如果密钥曾经暴露，已经完成轮换。

总结

AI 编程可以提高开发效率，但效率不能建立在泄露数据的基础上。

最需要保护的内容主要有三类：

• 密钥、Token 和账号信息。
• 用户和客户数据。
• 未经授权的公司代码和内部资料。

使用 AI 前，建议养成一个固定习惯：

先分类，删掉不必要的信息；再脱敏，替换必须保留的字段；最后确认工具和账号是否合规。

真正安全的提问，不是把所有内容都交给 AI，而是用最少的信息提供足够的上下文。

下一篇文章将介绍：

《AI 生成的代码为什么会“看着对，其实错”》

✍坚持原创，求关注，点赞，收藏