提示词里带敏感信息怎么处理

很多人是在复制一段真实客户资料、一份带手机号的表格、一段内部报错日志去问模型时卡住的：发出去怕出事，删了又怕模型答不准。这篇不讲大道理，只给一套从「先判断这条内容能不能发」到「发之前怎么替换、发之后怎么留痕」的可执行顺序，以及什么情况下这套做法并不适用。

很多人是在复制一段真实客户资料、一份带手机号的表格、一段内部报错日志去问模型时卡住的：发出去怕出事，删了又怕模型答不准。这种纠结很正常，通常不是知识不够，而是缺一个能照着走的处理顺序。下面讲的就是从「这条内容能不能发」到「发之前怎么替换、发之后怎么留痕」的一套动作。

先明确一点：脱敏不是把敏感信息全抹成星号就完事。抹得太狠，模型看不懂字段类型，回答质量明显下降；抹得不够，等于把原始数据递了出去。你要做的是在「模型能理解的结构」和「真实对象不可还原」之间找平衡。每个小节后面都会给判断标准和核对的入口。

发之前先做个三档判断

拿到一段要发给模型的内容，先别急着改，先分档。分档的依据不是字段名，而是「能不能唯一指认到某个人或某个内部系统」。一个孤零零的手机号，和一个带姓名、带公司、带订单号的手机号，风险级别完全不同，因为后者能拼出完整画像。三档分别是：可原样发、需替换后发、根本不该外发。

• 判断依据是可还原性，不是字段名称：同样的字段，多一个关联字段风险就跳一档
• 拿不准时按更高一档处理，多做一步替换的成本，远低于事后追溯的成本
• 分档结论要写下来，同一批内容下次再发就不用重新纠结，口径也统一
• 这一档判断和你本地保管调用凭据的原则是一套思路，可以在站内安全与合规入口配套看

该替换的字段，按这个清单过一遍

分档之后，第二档和第三档的内容就要过字段清单。清单不用背，照着扫一遍就行，重点是别漏。漏一个关联字段，前面所有替换都可能白做，因为剩下的字段能把人重新拼出来。

身份类

姓名、身份证号、工号、账号 ID、邮箱、手机号、住址、车牌

业务类

订单号、合同号、内部项目代号、客户名、未公开的财务数字

技术类

真实域名与内网 IP、数据库连接串、接口地址、带签名的 URL、日志里的令牌

1. 先替换唯一标识手机号、身份证号、订单号这类能直接定位的字段先处理掉，处理完读一遍确认没有残留
2. 再替换可关联字段姓名、公司名、项目代号这些单独看不敏感，但和唯一标识拼起来就成画像，一起换掉
3. 最后做还原性自检把替换后的内容贴给同事看，问他能不能猜出真实对象是谁，能猜出来就说明还没换干净

技术类字段最容易被忽略，因为它们在日志里常常长得不像敏感信息，比如一个带签名的 URL，本身就是一把临时钥匙。替换顺序按「先唯一标识、再可关联字段、最后自检」走，比想到哪改到哪更不容易漏。

替换不能瞎换：保持结构，改掉含义

替换的目标是让模型仍然理解上下文，同时让真实对象不可还原。很多人习惯把敏感处一律写成「XXX」，这其实是一刀切：模型看不到字段长度、格式和类型，就给不出贴合场景的答案。更稳的做法是同类同格式替换。

• 同一对象在整个提示词里用同一个代称，否则模型会把一个人当成两个人，答案直接跑偏
• 替换值要一比一记在本地对照表里，别放在提示词里，更别发出去
• 带单位的数字要连单位一起换，只换数字容易让模型按错误量级推理
• 替换完自检一句：把这段提示词贴给同事看，他能猜出真实对象是谁吗

这里有个容易踩的坑：多轮对话里第一轮已经发过的敏感内容，会留在上下文里被带进后续每一轮。你后来改口、要求模型忘掉，都改变不了它已经收到过的事实。所以替换动作要在第一轮就做完。

脱敏手段怎么选：手工替换、脚本批处理和工具

内容量不同，合适的手段也不同。单条提示词手工替换最稳，因为你能逐句判断；批量文本或表格就必须上脚本，靠人眼扫一定漏。规则类脱敏最难处理的就是漏网字段，所以脚本跑完一定要人工抽查。

表格类数据可以借助本地处理的方式，全程在本地完成、不上传，处理逻辑看得见。具体支持哪些字段、怎么批量替换，到站内对应工具页看当时的说明，别照抄别人截图里的做法。

如果所在行业对数据出境、个人信息处理有更严的口径，通用脱敏做法不一定够用。这种情况下先把内部规定拿出来对一遍，别直接套网上的模板。

结构上动手术：把敏感信息挪出提示词

前面几节讲的是「发之前怎么改」。更彻底的一步是改结构：让敏感信息从一开始就不进入提示词。能不发就不发，比替换得更干净还省事。

1. 能用变量就别写死真实值留在本地代码或配置里，提示词里只出现占位符，运行时在本地拼装
2. 能用检索就别整段贴需要模型参考的资料按需取片段，而不是把整份文档一次性塞进上下文
3. 分两次问先问方法和模板，在本地把结果套进真实数据，很多场景根本不需要把原始数据发出去

• 任务本质是「要方法」而不是「要处理这份真实数据」时，优先用占位符版本问
• 需要模型反复迭代同一份内容时，尽量让迭代发生在脱敏后的版本上
• 多轮对话开始前就定好哪些内容永不进入上下文，比中途补救有效
• 把这套结构固化成团队模板，新同事照填就行，不用每次重新判断

这里要看清楚不适用的场景：如果任务本身就是让模型算准某组真实数字、比对真实记录，那替换值只会得出错误结论。这种情况不是「改提示词」能解决的，应该换本地跑或私有化部署，见最后一节。

发去哪也很关键：官方接口、中转站、第三方工具

同一段脱敏后的内容，走不同渠道，可追溯性和留存策略不一样。选渠道之前，先确认对方的数据条款：输入会不会被留存、能不能关闭用于训练、能不能申请删除。这些问题的答案，决定了你能发什么等级的内容。

走中转渠道时，别只看它支不支持某个模型，先看站内对这个渠道的说明和判断口径。相关入口在站内的中转站目录和安全与合规页，选之前花几分钟翻一下，比出事之后再问划算。

如果几个渠道都判断不了，最省心的选择是不发。换成自己搭的本地或私有部署方案，代价是麻烦一点、维护成本高一点，收益是数据边界完全清楚，不用猜对方怎么处理你的输入。

已经发出去了：留痕与自查

万一原始敏感数据已经发出去了，第一反应别是删记录。删掉之后你就没法判断影响范围了，事后追责和通知相关方全都要靠这些记录。正确顺序是先记时间线，再留证据，最后才决定怎么处置。

1. 先记时间线什么时候、通过哪个渠道、发了什么等级的内容，越早记越准，拖一天细节就模糊
2. 保存提示词原文与对照表这两样决定你能不能还原出到底哪些真实数据出了控制范围
3. 确认渠道与内容等级先确认走的是哪条链路，再回到第一档判断口径，确认这批内容的实际等级
4. 再决定是否通知相关方确认原始数据确实出了你的控制范围之后，按内部流程走，别自己先对外说

自查顺序固定为：先确认渠道，再确认内容等级，最后才决定要不要通知。顺序反过来容易出现两种错误，要么小题大做，要么漏掉真正的暴露面。

这套做法什么时候不适用

前面讲的是通用处理顺序，但有几类场景它并不适用，硬套反而添乱。写清楚这些边界，比给你一个「万能脱敏流程」更实在。

• 依法必须外发或已经获得明确授权的场景，脱敏可能让流程不合规，按内部规定走
• 任务本身要求精确计算、比对真实数据时，替换值会得出错误结论，应改用本地跑或私有化部署
• 监管或审计明确要求保留原始数据的场合，脱敏只是外围措施，替代不了审批和备案
• 内容本身就是公开信息、且无法关联到具体对象时，过度替换只会降低回答质量

判断自己属于哪一类，最简单的办法是问一句：这个任务的产出，依赖于「真实值」还是「真实值的结构」？依赖结构，替换就够了；依赖真实值，就别硬发，换部署方式。

敏感信息处理的核心不是「删干净」，而是「让真实对象不可还原，同时让模型还能干活」