把工单或聊天记录外发出去前，规则脱敏能遮住什么、遮不住什么

贴出去的不是一份文本，是多份以后收不回来的副本

很多人把「脱敏」理解成界面上的礼貌：把完整号码换成星星，看起来专业一些。真正的问题发生在粘贴之后。工单系统会存正文，聊天服务会存消息，错误监控会抓堆栈，会话回放会记输入框，外包队列还会再导出一份。你在自己屏幕上改掉几个字，改变不了已经写进这些系统的副本。晚一步再去「清理工单」，只能改当前这一份；历史检索、邮件通知和下游分析往往还留着原文。

OWASP 日志速查表把这件事写成开发约束，而不是文案建议。它列出通常不该直接写入日志、而应删除、掩码、清洗、哈希或加密的内容：敏感个人数据与部分可识别信息（例如健康信息、政府身份标识）、认证口令、访问令牌、加密密钥和其他主密钥、银行账户或支付卡持卡人数据。工单和群聊在公司里经常扮演「非正式日志」：检索方便、权限比生产库松、保留时间更长。把用户原话整段贴进去，等于主动制造一份 OWASP 不建议留下的记录。

HTTPS 只保护传输过程中的窃听。它不擦掉你已经交给下一个系统的明文。上一篇写过：地址栏里的查询串会进历史、Referer 和访问日志。正文里的号码是同一类暴露，只是载体从 URL 换成了段落。外发前要处理的，不是「这个工单系统安不安全」，而是「这一段里有没有不该离开当前标签页的字段」。

规则认的是形状和校验位，不是这段话在说什么

规则脱敏的工作方式很窄。它用正则找候选串，再用校验函数丢掉明显不像的命中，最后按优先级处理重叠。它不知道「张三」是人名，也不知道「明天送到中关村」是地址。它只知道：这一串 11 位数字是不是大陆手机号形态，这一串 18 位是不是过了公民身份号码校验，这一串 16 位是不是过了银行卡常用的 Luhn 校验。

这和「模型读懂了工单再改写」不是一条路。大模型外发前再扫一遍 PII，本身又把原文送给了另一个处理方；网关侧脱敏也是把文本送去识别服务。规则扫描可以完全留在当前标签页：输入不离开浏览器，结果是掩码后的副本。代价是覆盖面取决于名单。名单外的证件、自造密钥前缀、被空格拆开的数字，都会漏。

校验位用来降低误伤，不是用来证明「这就是真实身份」。大陆 18 位公民身份号码按 GB 11643-1999 / ISO 7064 MOD 11-2 计算第 18 位：前 17 位分别乘以加权因子 7、9、10、5、8、4、2、1、6、3、7、9、10、5、8、4、2，求和后对 11 取余，再对照校验字符表 10X98765432；余数为 2 时第 18 位是 X，代表 10。通过校验只说明「这串字符像一个合法号码」，不说明公安库里有这个人。银行卡一侧常用 ISO/IEC 7812 的 Luhn 算法：从右往左隔位乘 2，大于 9 则减 9，总和能被 10 整除才收下。一串随便敲的 16 位数字，多数过不了 Luhn，规则就不该把它当成卡号。

六类字段分别认什么，遮完长什么样

能被稳定认出来的，通常是「有公开格式、还能加一层校验」的字段。下面按常见外发文本里的出现顺序写，掩码形状以「保留少量首尾、中间换星号」的智能掩码为例；需要把可见数字也抹掉时，应改用完全掩码。

电话规则要同时照顾「连续 11 位」和「带空格、括号、短横」的写法。大陆号用 1[3-9] 开头的 11 位数字是公开的号段形态，不是某个运营商的内部表。国际号按 E.164 的常见外观来抓：以 + 开头、后面 7 到 15 位数字。数字太短或夹在更长数字中间，应被丢掉，否则订单号、快递单也会被当成手机。

证件号里，大陆 18 位除了校验位，还要求地址码非 0 开头、出生年在 19 或 20 世纪、月份和日期落在合法范围。美国社会安全号若写成 AAA-GG-SSSS，官方排除过若干无效区号：000、666、以 9 开头；分组不能是 00，序号不能是 0000。英国国民保险号是两个字母、六位数字、再加 A–D，并排除 BG、GB 等前缀。这些规则提高的是「像证件」的把握，不是「此人存在」的证明。

卡号一侧，支付行业把「屏幕上最多露出多少位」和「存储时如何截断」分成两件事。PCI 安全标准委员会在 8 位 BIN 说明里重申：展示主账号时，各品牌普遍接受的上限仍是前六后四；具体岗位若只需要后四位核对，就只应看到后四位。工单外发不是收单系统，默认只留后四位更稳妥。这不构成 PCI 认证声明，只说明：把 16 位完整贴进聊天，已经超过展示侧的常见上限。

邮箱掩码若只挡本地部分、留下完整域名，接收方仍能看出「这是哪家公司的人」。密钥规则依赖公开前缀：GitHub 经典个人访问令牌用 ghp_ 加 36 位，细粒度令牌用 github_pat_；AWS IAM 访问密钥标识常见 AKIA 加 16 位；Stripe 直播密钥用 sk_live_。前缀存在，是为了让 SDK 和扫描器认出来——这也是规则能挡住它们的原因。没有稳定前缀的自造 token、被拆成「g h p 下划线……」的字符串，规则会当普通文本放过。

IP 用点分十进制的合法范围（每段 0–255）来抓，避免把版本号 1.2.3 收进来。演示和金丝雀应使用文档保留段，不要写生产地址。RFC 5737 留出 192.0.2.0/24、198.51.100.0/24 和 203.0.113.0/24，明确不应出现在公网路由里。邮箱演示用 example.com，依据是 RFC 2606 的保留域名，不是某家真实公司。

证件号和卡号会抢同一串数字

18 位公民身份号码全是数字（末位也可能是 X）。若有人把末位是数字的身份证当成「一长串卡号」送给银行卡规则，Luhn 偶尔也会算对。两类规则叠在同一段文字上时，必须先定优先级，否则同一串会被遮两次，或被遮成错误的形状。

一种稳妥排法是：证件号优先于密钥，密钥优先于电话，电话优先于邮箱，邮箱优先于银行卡，银行卡优先于 IP。理由很具体。先认证件，避免 18 位身份号被 Luhn 收成卡号；密钥前缀比「像电话的数字」更特殊；邮箱里的数字不应再被电话规则切一刀；IP 最宽，放最后以免吃掉版本号或订单里的点分数字。重叠时只保留优先级更高、或更长的那一次命中。

你在页面上关掉「证件号」、只开「银行卡」时，行为应反过来：允许把那串数字按卡号处理。这是调试规则时的预期，不是默认外发策略。默认应六类全开，再人工看漏网的姓名和地址。

星星不等于匿名，也不等于去标识化已经完成

《中华人民共和国个人信息保护法》第四条把个人信息写成「与已识别或者可识别的自然人有关的各种信息」，并写明不包括匿名化处理后的信息。第七十三条把两个词分开：去标识化，是处理之后在不借助额外信息的情况下无法识别特定自然人；匿名化，是无法识别且不能复原。第五十一条把加密、去标识化列为处理者应当采取的安全技术措施之一。法条没有把「中间换成星号」写成已经合规。

智能掩码故意留下可核对的尾巴：手机后四位、卡号后四位、邮箱域名、密钥前缀。工单里若同时还有姓名、地址或内部客户编号，后四位足够把人从「可识别」推回「已识别」。这最多接近去标识化的方向，达不到匿名化。完全掩码把命中段落换成等长星号，少了一条拼接线索，但仍留下长度、位置和周围句子。句子本身可能写着「请回拨机主」或「身份证复印件见附件」。

因此，「跑过规则」不能写成「这段可以进公共知识库」或「已经满足某项认证」。工具页也不声称 GDPR 或等保。正确的句子是：已知形状的字段被换成了掩码；未知形状的字段没有被动；是否还能识别出具体的人，要结合上下文由你判断。

规则认不出的，往往才是外发事故里的那一句

把漏报写成清单，比把命中写成功能更有用。第一类是没有稳定数字形态的直接标识：中文姓名、住址、工作单位、病历描述、孩子的学校。规则没有一份「全国姓名表」可查，开了姓名识别的云服务也常把普通词误判成姓名。第二类是被改写的敏感值：「一三八零零一三八零零零」、全角数字、中间插入「的」或零宽字符、用截图而不是文本。正则看的是当前码点序列，不是人读出来的号码。

第三类是没有公开前缀的秘密。数据库连接串、JWT 三段式、自造的 token=、微信或内部系统的会话 cookie，都不在 ghp_ / AKIA 那张短名单上。第四类是附件和富文本：Word 页眉、表格隐藏列、邮件签名里的手机、PDF 里的图层。规则只扫你粘贴进输入框的纯文本。第五类是语义层面的机密：未公开的合同金额、漏洞细节、客户投诉原话。它们不是 PII 形态，但外发同样会造成伤害。

还有一类「命中了但遮错了」。订单号、快递单、会议室分机有时会长得像电话；文档版本 10.20.30.40 长得像 IPv4。校验和边界（前后不是数字）能挡掉一部分，挡不掉全部。所以结果区必须同时给出「命中了哪些类型、各几次」，而不是只给一段已经打星的文字。你要核对的是类型对不对，不是星星够不够多。

当场核对：金丝雀进输入框，再搜 Network

口号写「本地脱敏、不上传」无法自证。能当场看到的是四件事：哪些类型被点名，掩码形状对不对，故意漏掉的句子还在不在，以及原文有没有作为业务数据出站。

先准备一段不含真实身份的金丝雀。电话用 13800138000（广告和文档里常见的虚构形态，不要改成你自己的号）。邮箱用 canary@example.com。IP 用 203.0.113.10。卡号用 4111111111111111。密钥用一段带公开前缀、其余全是可丢弃字符的假令牌，例如 ghp_ 后面跟你自己编的 36 位，用完即当失效。证件号不要用任何人的真实号码；若要验证校验逻辑，用明显不可能的出生日期（例如 1900 年 1 月 1 日）自行算出第 18 位，并在段落里标明「虚构」。

把金丝雀嵌进一句正常工单：「用户 canary@example.com 称无法登录，回拨 13800138000，来源 IP 203.0.113.10，测试卡 4111111111111111，令牌 ghp_……。收件地址写在北京市海淀区中关村大街。」跑完之后，邮箱、电话、IP、卡号和令牌应出现在命中统计里，并按上表变成掩码；「北京市海淀区中关村大街」应原样保留——这不是故障，这是规则边界。若地址也被遮了，说明你用的不是纯规则，或规则被扩得过宽，需要另看误伤。

再打开开发者工具的 Network，勾选 Preserve log，用金丝雀里的独特字符串搜索，例如 13800138000、canary@example.com 或假令牌全文。XHR / Fetch 的请求行、查询串和请求体都不该出现它们；访问统计的 query 与 body 同样不该出现。静态脚本文件名里出现「privacy」「redact」是预期。原文作为业务字段出站，才算失败。

1. 用虚构电话、example.com 邮箱、RFC 5737 地址、测试卡号和带前缀的假令牌拼一段工单，并故意留一句中文地址。
2. 跑完对照命中类型：五类数字/账号应被点名，地址应仍在结果里。
3. 用金丝雀原文搜索 Network；任一业务请求命中即说明输入离开了标签页。

这套步骤证明的范围很窄：这一次操作里，已知形状被换成掩码，地址类句子没被动，原文没有作为已观察到的 HTTP 字段离开当前标签页。它不证明扩展程序没有读输入框，也不证明换一段真实工单不会漏报。换浏览器或改规则开关之后，值得再跑一遍金丝雀。

用打开即用的脱敏页把边界练熟

若你希望用一个把类型开关和命中统计写在页面上的工具来练习，可以从 MakePwd 的隐私清洗切入数据脱敏。打开即可使用，无需注册，也没有账号。扫描和掩码发生在当前标签页；按产品说明，原文不作为请求发出，也不会写入 analytics。可勾选的类型就是上面六类：电话、证件号、银行卡、邮箱、API Key、IP。默认智能掩码，可改完全掩码。单次文本上限是 512 KB。页面明确写了：不能识别所有证件格式，不能证明文本已符合某项合规要求，重要外发必须人工复核。

练习时只用金丝雀。跑完同时看三处：命中类型计数、结果文本里的地址有没有被误伤、Network 里有没有原文。计数回答「认对了没有」；地址回答「规则边界在哪」；Network 回答「有没有上传」。三处都过，才能向同事解释：我遮的是这些类型，我知道地址还在，我搜过金丝雀没有出站。

链接形态的追踪参数是另一件事。工单里若还贴了带 utm_source 或 fbclid 的完整 URL，应先按键名剥离查询串，再处理正文里的号码。步骤见把带 UTM 的完整链接贴进聊天，会把哪些追踪信息一起发出去。若脱敏之后仍是一段必须原样送达的机密，用阅后即焚一次性发送，密钥留在 URL 的 # 片段；整份文件则用文件加密盒在本机做成 .lock / .enc（单文件不超过 5 GB）再走网盘或邮件。这些步骤都不要求登录。

常见问题

星号掩码之后，这段文字还算个人信息吗？

通常还算。个人信息保护法把匿名化定义为无法识别且不能复原；去标识化则是不借助额外信息时难以识别。保留后四位的手机号、带域名的邮箱，配合工单上下文仍可能被拼回。规则脱敏最多接近去标识化，不能写成已经匿名。

规则脱敏能替代人工审核吗？

不能。规则认的是模式和校验位，不是语义。姓名、地址、口述数字、截图和改写过的密钥都可能漏过。重要外发仍要自己通读结果。工具页也不声称 GDPR 或等保认证。

脱敏会不会把原文上传？

按产品说明，扫描和掩码发生在当前标签页，原文不作为请求发出，也不写入 analytics。可用虚构金丝雀在 Network 里搜索原文核对。这只证明这一次观察到的请求，不证明扩展程序没有读输入框。

整段还没脱敏完的机密该怎么发？

散落的手机号、证件号用规则掩码；整段口令、未公开材料和必须原样送达的密钥，用阅后即焚一次性发送，密钥留在 URL 的 # 片段。整份文件用文件加密盒在本机做成 .lock 或 .enc 再走网盘或邮件。

下次外发前记住的三件事

第一，粘贴即复制。工单、聊天、监控和导出各留一份，事后改当前页收不回已经发出去的原文。第二，规则只挡有格式、能校验的字段；姓名、地址、口述数字和自造密钥要人看，掩码留下的尾巴加上下文仍可能识别到人。第三，核对看三处：命中类型、故意留下的句子、用金丝雀搜索 Network。

若你还要继续追问「完整链接里的查询串该不该一起外发」，请读把带 UTM 的完整链接贴进聊天，会把哪些追踪信息一起发出去。若要核对明文有没有作为业务数据离开标签页，请读浏览器里做加密，怎么当场核对明文没有离开本机。本文只把「规则脱敏对工单正文能做什么、不能写成什么」收成可以写进结论的范围。