这份清单按「泄露后果」排序，不按数据类型排序。判断标准只有一条：粘进去之后，你能不能承受它出现在别人的日志里。
绝对不要
| 材料 | 为什么 | 替代做法 |
|---|---|---|
| API key、令牌、Cookie、私钥 | 等于把账户交出去。粘一次就可能永久留在某处日志 | 用占位符替换成 |
| 身份证号、护照号、银行卡 | 法定敏感个人信息，一旦外发难以追回 | 脱敏到只剩格式：18位数字改为XXXXXXXXXXXXXXXX |
| 客户名单、真实姓名+联系方式 | 同时命中个人信息与商业机密 | 造结构相同的假数据 |
| 未公开的财务数据、合同原文 | 商业机密，且可能涉及披露义务 | 抽掉数字，只保留结构问「这种条款的风险在哪」 |
| 生产环境数据库连接串 | 含主机、库名、口令三样 | 改成db://user:pass@host/db的占位形式 |
需要先想一下
- 内部代码：如果仓库是私有的、且你没权限外发，先问能不能只贴报错和函数签名。
- 医疗与健康信息：即使脱敏，小样本也可能被反推。
- 第三方的聊天记录：对方没同意，你也不该替他决定。
- 还没公开的产品计划：比代码更容易被忽略。
一个实用习惯
粘贴之前先做一次替换：把识别性字段换成同名占位符（<客户名>、<订单号>），保持结构不变。这样模型的回答质量几乎不受影响，而你把风险降到了零。
别指望「它会忘掉」。会话可能被留存，网关可能记日志，这不是你能控制的部分。可控的只有粘之前那一步。
已经粘了怎么办
1. 立刻作废涉及的凭据（key、令牌） 2. 评估影响范围：这个材料能被用来做什么 3. 需要时告知相关负责人，别等被发现