我在公司写代码遇到 bug 想发给 ChatGPT 问问会不会泄密啊

我在一家做企业管理软件的公司干了快两年了,平时写代码遇到问题都是自己查文档或者问同事。最近发现用 AI 问问题确实快很多,但我们入职的时候签过保密协议。 昨天有个数据库查询的 bug 搞了一下午没解决,特别想把那段代码复制给 DeepSeek 问问,但又怕万一代码里带着公司业务逻辑或者客户信息算不算泄密。我看到有的同事好像在用,也不知道他们是怎么处理的。 协议上写的是不能泄露公司技术资料和客户信息,但没说具体到什么程度。就普通的业务代码发给 AI 工具算违反吗?还是说只要不带...

Viewed 0

我在一家做企业管理软件的公司干了快两年了,平时写代码遇到问题都是自己查文档或者问同事。最近发现用 AI 问问题确实快很多,但我们入职的时候签过保密协议。

昨天有个数据库查询的 bug 搞了一下午没解决,特别想把那段代码复制给 DeepSeek 问问,但又怕万一代码里带着公司业务逻辑或者客户信息算不算泄密。我看到有的同事好像在用,也不知道他们是怎么处理的。

协议上写的是不能泄露公司技术资料和客户信息,但没说具体到什么程度。就普通的业务代码发给 AI 工具算违反吗?还是说只要不带客户数据就行?我也不好意思直接问领导,感觉问了显得自己心虚。

2 Answers

原则上可以把代码片段发给 ChatGPT/DeepSeek 问问题,但前提是先脱敏、只给最小必要片段,并且不包含客户真实数据、核心业务机密或内网架构信息。对你说的“数据库查询 bug”,如果只是通用 SQL/框架用法,按下文方法脱敏后风险较低;一旦能反推出你们系统设计、客户身份或独家逻辑,就可能触碰保密协议的边界。保守做法是先脱敏再问,或优先用公司提供的企业/私有化模型。

能不能把公司业务代码发给 ChatGPT,会不会泄密

  • 风险机制
    • 在线对话通常会在服务端留存并用于模型优化或安全审计,厂商虽有合规承诺,但对外部工具而言,你与其之间并无公司级保密关系,存在工程师可见性、日志留存、模型训练再利用等潜在风险。可参考各平台隐私/使用条款说明,例如微信生态产品与第三方服务的数据处理原则见 weixin.qq.com 的隐私相关页面。
  • 场景差异
    • 个人免费/付费账号 vs 企业版/私有化:企业版或私有部署通常提供“不用于训练”“数据留存可控”的承诺和技术措施,个人账号则不一定,有更高的外泄面。
    • 国内 vs 境外服务:跨境传输与监管要求不同,涉客户数据和商密时更敏感,需遵循公司与监管要求,可参考国家网信办口径 cac.gov.cn
    • 代码类型:通用开源框架用法/语法错误通常可脱敏后咨询;能反映商业机密或客户身份的信息应避免外传。

哪些代码不能直接发给 AI 工具

围绕“技术资料和客户信息”,以下三类高风险,建议不外发:

  1. 客户真实数据:公司名、手机号、邮箱、订单号、合同编号、金额、可识别特征的测试数据。
  2. 核心/独家业务逻辑:计费或风控规则、权限/密钥策略、尚未公开的算法与架构设计。
  3. 内网与安全信息:内网域名/IP、数据库/服务真实标识、API 鉴权方式、密钥/令牌、拓扑与监控告警细节。

对照判断:通用的增删改查、主流框架配置、开源库调用本身不构成独家机密,脱敏后再问通常风险较低。

安全做法 vs 不安全做法

场景 不安全做法 更安全做法
SQL 查询 bug 贴含真实表/字段/客户值的语句 将表/字段名通用化,并用占位符:orders/user_id,值改为 ? 或 mock 值
业务报错定位 贴完整计费/风控函数与规则 只贴出错的那几行通用逻辑,参数改为 a/b/c,补充文字描述
配置问题 截图含内网 IP、库名、域名 用 192.168.x.x、mydb、example.com 替代,仅粘贴报错栈
前端页面 贴含客户 Logo、菜单与公司名 只给组件渲染逻辑,文案用 Item1/Item2,占位图替代

发给 ChatGPT/DeepSeek 前的最低风险流程

  1. 最小化片段:仅保留能复现错误的5–20行;上下文用1–2句文字说明。
  2. 通用化命名:表/字段/服务名改为 orders/users/service-a;删去能指向特定客户或模块的命名。
  3. 清除数据与密钥:真实ID/手机号/金额/令牌一律占位符(//)。
  4. 改写敏感注释:删除或改写指向银行/甲方/项目代号的注释与 TODO。
  5. 分离错误信息:优先贴报错堆栈与最小调用栈,不贴架构图与全量配置。
  6. 选择更稳渠道:若公司有企业版/私有化大模型,优先使用;没有时尽量用本地/离线代码扫描与静态分析工具联动,或在 IDE 内用不出网插件。

哪些问题脱敏后可以直接问,哪些不该问

  • 适合脱敏后咨询
    • 开源框架用法与报错(Spring/Vue/Django 等)
    • 语言语法/并发/性能优化的通用范式
    • 通用数据库/索引/SQL 写法与优化
    • Git/Docker/Nginx/MySQL 等工具链通用配置
  • 不适合外传的内容
    • 尚未发布的产品功能实现细节与差异化算法
    • 客户专属定制逻辑、SLA/计费/风控规则
    • 内网拓扑、真实域名/IP、鉴权与密钥策略

同事在用 AI,不代表合规

同事可能只问了纯技术问题,或在用公司采购的企业版,也可能存在违规未被发现。稳妥做法:

  • 在团队层面建立“可外发/需脱敏/禁止外发”的代码分级清单与示例库。
  • 用“提升效率、统一规范”的口径,向技术负责人或信息安全/法务询问“是否有外部 AI 使用指引”,这属于正常合规沟通而非“心虚”。
  • 若公司尚无规范,可建议落地最小化片段、脱敏清单、工具白名单、审计留痕与审批流程。监管口径与数据合规可参考 cac.gov.cn 与工信部 miit.gov.cn 的公开信息。

如果必须用外部工具,进一步降低风险的做法

  • 账户与设置:优先选择提供“关闭训练/不用于改进模型”的设置的产品;使用工作专用账号,避免与个人数据混用。
  • 提问方式:多用“问题描述+报错堆栈+伪代码/最小复现”的组合,减少贴真实业务代码。
  • 本地先验:先用本地 linter、静态分析、单测与最小复现仓库缩小范围,再把与业务无关的片段交给模型。
  • 留痕与复用:把脱敏后的最小复现与提问话术沉淀为团队模板,形成统一口径。

外部工具的隐私与数据处理以各平台政策为准,提交前请结合公司制度与监管要求自查;平台政策可在相应官网的隐私/用户协议页面查看,例如微信生态平台入口 weixin.qq.com

我觉得这个问题你想得太复杂了。关键不在代码本身是不是"普通的",而在于你能不能把敏感信息剔除干净。如果你复制给 AI 的代码里有表名、字段名、业务逻辑这些涉及公司架构的东西,那就得谨慎。但如果只是一段通用的算法问题或框架用法报错,其实问题不大。

我的建议是:先把代码里公司特定的信息都换成"example_table""user_id"这种通用说法,只保留技术问题的核心部分再问。或者干脆问同事,反正你们都在一个技术栈上。实在不好意思问领导,可以找你们技术负责人或 HR 了解一下公司对这块的实际态度,很多公司其实默认允许用 AI 工具,只要不涉及客户数据。不用过度担心,但也别抱着"反正别人都在用"就直接复制整段代码。

Related