技能介绍

问题出在哪里

当你把 CSV、SQL 结果、API 响应或命令输出交给模型时，只要里面出现姓名、电话、邮箱、地址，原始 PII 就已经进入上下文了。事后才想"刚才那段是不是该脱敏"已经没有意义——看过一次就留在那里了。而如果一律改成 SELECT COUNT(*) 这类聚合，又会丢掉你真正需要的逐行处理逻辑。

它是怎么工作的

llm-privacy 把脱敏做成一条可逆流水线：mask → 用 token 干活 → restore。

读取前先 mask：数据先过 masker，你看到的只有 ⟦PII_…⟧ 占位符。同一个真实值永远映射到同一个 token，可以照常分组、计数、join、比较。
token 是不透明标识符：不去猜背后是什么，不因为被 mask 就说值缺失，更不改动拼写——还原靠精确匹配。
用户看到之前 restore：把带 token 的草稿写进文件或管道，过一遍 restore 再呈现。还原后的文件含真实 PII，交给用户即可，但不要再读回上下文。
映射存在本地 vault：默认 $LLM_PRIVACY_VAULT，否则 ~/.llm-privacy/vault.json（创建权限 0600），从不进入上下文。

三类识别方式

内置通用实体：邮箱、IBAN、国际 +CC 电话、IPv4/IPv6、MAC、美国 SSN、ETH/BTC 地址；信用卡需显式开启 --entities incl. credit_card 且通过 Luhn。
按地区开启：--locales 覆盖 48 国的本地电话与国民 ID，带校验位的（PESEL、CPF、TCKN、Aadhaar、DNI 等）会先做校验，避免等长随机数被误伤。
结构化字段与来源标签：CSV/JSON 用 --fields name,customer,street 整列、整键递归脱敏；自由文本的人名地址没有可靠正则，需要自己包标签，例如 SQL 里的 chr(57344) || 'NAME:' || customer_name || chr(57345)，Python 侧用 tag("NAME", value)，各语言脚本都支持。

故意不脱敏的部分

订单号、物流号、UUID、哈希、日期、价格保持原样——宁可保守，也不破坏业务标识符的可用性。

边界与注意点

输出可能含 PII 就先 mask，不要"先读一下再决定"。
尽量在源头做聚合（COUNT / SUM），只有必须流动的行级 PII 才过 masker。
token 没法回填到后续命令：要么在源头过滤，要么走 restore → exec → mask，让真实值只出现在本地 shell。
vault 是敏感文件：不打印、不提交，任务结束清空；一次任务用一个 vault。
不要 cat / diff 还原后的文件，那等于把真实值拉回上下文。验证还原要靠盲测：grep -c 'PII_' final_answer.md 必须输出 0。