版權(quán)與內(nèi)容來源聲明本文為原創(chuàng)整理。文中涉及官方文檔、開源倉庫、論文與公開報道的內(nèi)容均在附表 A 中標(biāo)注來源引用官方原文保持原樣不作改寫。文中命令、版本號與界面截圖以本文成文時的實測/核驗結(jié)果為準(zhǔn)標(biāo)注「待驗證」的部分請以你本地環(huán)境實際輸出為判斷依據(jù)。本文不推薦任何不合規(guī)的軟件獲取方式也不對任何收益結(jié)果作承諾。轉(zhuǎn)載請注明出處。一、為什么這條線容易漏脫敏指的是在日志落盤、導(dǎo)出或外發(fā)之前把手機(jī)號、身份證號、銀行卡號這類字段替換成星號或占位符的動作。絕大多數(shù)團(tuán)隊做這件事的方式是一樣的寫一條正則把「看起來像手機(jī)號」的數(shù)字換掉收工。問題不在于大家不會寫正則。正則指的是用一串符號描述「什么樣的字符串算命中」的規(guī)則文本會寫re.sub的人很多。問題在于這條規(guī)則從來沒有被證偽過——它上線之后只跑正常樣本或者只在「格式整齊」的樣本上跑漏了也沒人知道因為脫敏漏了不會報錯。1.1 第一版腳本幾乎都長這樣下面三行是從主代理的本機(jī)實測腳本里原樣摘出來的屬于已經(jīng)跑過的寫法不是示意importre# 摘自 work/2026-10-22_脫敏實測.py這三條是實跑過的R1re.compile(r1[3-9]\d{9})# 只認(rèn)連續(xù) 11 位R2re.compile(r1[3-9]\d[- ]?\d{4}[- ]?\d{4})# 允許半角空格與短橫R3re.compile(r(?:\?86)?1[3-9]\d{9})# 允許 86 前綴1[3-9]的意思是「第一位是 1、第二位是 3 到 9」后面跟九個數(shù)字。這條規(guī)則在紙面上沒錯中國內(nèi)地手機(jī)號的號段確實落在這個范圍里。但它描述的是號碼本身不是號碼在日志里的樣子。1.2 漏的不是規(guī)則是寫法分支同一批手機(jī)號在真實日志里至少有四種寫法。我按這四種寫法各構(gòu)造了 5 條樣本一共 15 條逐個喂給上面三條規(guī)則。寫法各 5 條日志里的樣子用哪條規(guī)則原樣先歸一化連續(xù) 11 位用戶 13812345678 提交訂單R15/55/5帶半角分隔手機(jī) 159 0000 1111 待確認(rèn)R10/50/5帶半角分隔聯(lián)系 135 1111 2222R25/55/5全角或帶前綴手機(jī)R14/55/5這張表里有一行特別值得看「全角或帶前綴」這一類R1 原樣就能抓到 4/5。原因是這 5 條里只有 1 條真的用了全角數(shù)字另外 4 條是半角數(shù)字配中文標(biāo)點、括號、86或0086前綴R1 在字符串中間照樣能找到那 11 位。所以「原樣 4/5」這個數(shù)字會給人一個虛假的安心感——看起來只差一點點實際上差的是整整一個寫法類別。而「半角分隔」那一行是 0/5怎么調(diào)前綴、怎么加86都還是 0/5因為中間的空格和短橫不在規(guī)則的胃口里。規(guī)則寫得多花和覆蓋了哪些寫法是兩件不相關(guān)的事。判據(jù)一召回先看寫法覆蓋不看正則寫得多花。動手寫規(guī)則之前先把「這套日志里出現(xiàn)過幾種寫法」列成清單四種寫法就是四行樣本一行都不能省。1.3 本文的樣本與口徑必須先把口徑說清楚樣本是構(gòu)造樣本非真實業(yè)務(wù)日志僅用于對比規(guī)則寫法。6 類敏感字段各 5 條手機(jī)號連續(xù) 11 位、手機(jī)號帶半角分隔符、手機(jī)號全角或帶前綴、身份證 18 位、銀行卡 16–19 位、郵箱另有 6 條不該被動的正常字段訂單號、13 位毫秒時間戳、運單號、12 位批次號、13 位商品條碼、15 位流水號。跑測環(huán)境是 Python 3.13.14僅用標(biāo)準(zhǔn)庫re腳本與日志都在work/目錄下任何人可以復(fù)跑。所以下面所有分母都是 5所有數(shù)字都能回到日志里逐行對上。二、六類字段的寫法覆蓋實測先把完整的對照表放出來。每一格是「原樣匹配 → 先做全角轉(zhuǎn)半角再匹配」分母都是 5。規(guī)則手機(jī)號·連續(xù) 11 位手機(jī)號·帶分隔符手機(jī)號·全角或帶前綴身份證·18 位銀行卡·16~19 位郵箱R1 連續(xù) 11 位5/5 → 5/50/5 → 0/54/5 → 5/55/5 → 5/50/5 → 0/50/5 → 0/5R2 允許半角分隔5/5 → 5/55/5 → 5/54/5 → 5/55/5 → 5/50/5 → 0/50/5 → 0/5R3 帶 86 前綴5/5 → 5/50/5 → 0/54/5 → 5/55/5 → 5/50/5 → 0/50/5 → 0/5R4 身份證 18 位0/5 → 0/50/5 → 0/50/5 → 0/55/5 → 5/52/5 → 2/50/5 → 0/5R5 銀行卡 16~19 位0/5 → 0/50/5 → 0/50/5 → 0/55/5 → 5/53/5 → 3/50/5 → 0/5R6 郵箱0/5 → 0/50/5 → 0/50/5 → 0/50/5 → 0/50/5 → 0/55/5 → 5/52.1 手機(jī)號兩個召回臺階分別歸功于不同的動作召回指的是「該抓到的里面實際抓到了多少」。把三類手機(jī)號寫法合起來算 15 條R1 樸素規(guī)則原樣9/1560.0%先歸一化10/1566.7%。R2 允許半角分隔原樣14/1593.3%先歸一化15/15全部命中。兩個臺階要分開看。從 9 漲到 10 是歸一化帶來的漲的只有全角那 1 條從 10 漲到 15 是寫法覆蓋帶來的靠的是規(guī)則里多認(rèn)了[- ]?這兩處分隔符。很多人只做了前者寫了個translate或者只做了后者把規(guī)則寫長所以永遠(yuǎn)停在 10/15 或 14/15。標(biāo)題里說的「漏了一半」指的就是 9/15 這個起點15 條樣本樸素規(guī)則原樣只認(rèn)了 9 條剩下 6 條一條都不會報錯、一條都不會告警。2.2 身份證與銀行卡位數(shù)不是判據(jù)這張表里最別扭的兩行是 R4 和 R5。R4 是\d{17}[\dXx]在 5 條身份證樣本上5/5。這里有一個必須寫死的細(xì)節(jié)樣本里有一條的末位是小寫x只寫大寫X會漏掉它必須寫[Xx]。漏掉的結(jié)果不是報錯是那一條身份證原樣落進(jìn)了日志。R5 是\d{16,19}在 5 條銀行卡樣本上只命中3/56222 0212 3456 7890帶空格、6217-0000-1111-2222帶短橫的兩條全部漏掉。同時它把 5 條 18 位身份證全部吃了進(jìn)來5/5——因為 18 位純數(shù)字正好落在 16 到 19 位這個區(qū)間里。反過來的方向也一樣R4身份證規(guī)則在銀行卡那一列命中了 2/5說明這兩條規(guī)則在互相吃?！付嗌傥粩?shù)字」只能篩出一個候選集合不能判定字段類型。這是本文后面所有錨點討論的起點。2.3 郵箱這一條反而最穩(wěn)郵箱規(guī)則[\w.-][\w-]\.[\w.]在 5 條樣本上5/5本輪沒有參與任何一次誤判。原因不神秘它中間有一個。是一個幾乎不會出現(xiàn)在訂單號、時間戳、運單號里的字符等于規(guī)則自帶了一個錨點。這個對比很值錢——凡是自帶稀有分隔符的字段規(guī)則都容易寫對凡是「純數(shù)字」的字段規(guī)則都容易寫歪因為純數(shù)字的世界里沒有任何天然邊界。三、誤判清單什么被當(dāng)成了手機(jī)號誤判指的是不該動的字段被動了。6 條正常字段、6 條規(guī)則交叉跑下來一共產(chǎn)生11 次誤判。正常字段值被哪條規(guī)則誤判為什么會被吃13 位毫秒時間戳1759999999999R1 / R2 / R313 位里含一段以 1 開頭、第二位是 7 的 11 位運單號SF1381234567890R1 / R2 / R3字母后面那 13 位里含同樣形狀的 11 位15 位流水號159000011112222R1 / R2 / R315 位里含一段 1 開頭、第二位是 5 的 11 位18 位訂單號202610221234567890R4 / R518 位純數(shù)字正好滿足「17 位 1 位」與「16 到 19 位」12 位批次號202610220001無位數(shù)不夠 16也沒有 11 位以 1[3-9] 開頭的連續(xù)段13 位商品條碼6901234567892無位數(shù)不夠 16首位是 6 不是 13.1 13 位時間戳是重災(zāi)區(qū)1759999999999這條同時被三條手機(jī)號規(guī)則命中是這輪實測里最典型的失敗。它是 13 位毫秒時間戳——日志里最常見的字段之一幾乎每一行都有。為什么 11 位規(guī)則能吃 13 位因為正則默認(rèn)是子串搜索不是整串匹配。1[3-9]\d{9}只要求「存在這么一段」不要求「這段前后沒有別的數(shù)字」。時間戳的第 1 位是 1、第 2 位是 7剛好滿足1[3-9]后面再湊 9 個數(shù)字就命中了。規(guī)則本身完全沒錯錯在它沒有說「前后不許再挨著數(shù)字」。3.2 訂單號同時命中兩條長規(guī)則202610221234567890是 8 位日期加 10 位序列共 18 位。它同時滿足 R417 位 1 位和 R516 到 19 位也就是說身份證規(guī)則和銀行卡規(guī)則都會把它打成星號。這比手機(jī)號誤判更麻煩訂單號是排障時最主要的檢索鍵。把訂單號脫掉線上出問題時按訂單號搜日志會直接搜不到人只能按時間盲翻。3.3 誤刪比漏刪更難發(fā)現(xiàn)漏刪是「該掩的沒掩」誤刪是「不該掩的掩了」。這兩件事在監(jiān)控上的可見度完全不對稱漏刪日志內(nèi)容看起來正常沒有任何異常信號只有等審計或等出事才知道。誤刪日志內(nèi)容變短、字段變成星號但沒有人會為「日志里少了一個訂單號」告警。判據(jù)四誤刪比漏刪更該被盯住。漏刪沒有任何信號誤刪卻會悄悄讓日志失去排障能力而后者通常沒人報警。所以判斷一條規(guī)則好不好不能只看它抓到了多少敏感字段還要看它在正常字段上留了幾個洞。本案的 11 次誤判分布在 4 個正常字段上其中 3 個是排障必用的定位鍵時間戳、運單號、訂單號。四、歸一化與錨點兩個必做的動作4.1 歸一化必須在匹配之前歸一化指的是在比對之前先把不同寫法統(tǒng)一成一種形式——這里具體指全角數(shù)字轉(zhuǎn)半角數(shù)字。# 摘自 work/2026-10-22_脫敏實測.py這兩行是實跑過的FWstr.maketrans(,0123456789)texts.translate(FW)# 先歸一化再拿 text 去匹配這一步的收益在數(shù)字上很小R1 從 9/15 到 10/15R2 從 14/15 到 15/15都只多了 1 條。但它補(bǔ)的是整整一個類別而且這一類是「規(guī)則怎么寫都補(bǔ)不上」的。有個常見的誤解值得點出來有人覺得\d本來就能匹配全角數(shù)字所以不用歸一化。按 Python 官方文檔re模塊的說明\d在 Unicodestr模式下確實匹配任何 Unicode 十進(jìn)制數(shù)字包括全角數(shù)字。但問題出在規(guī)則的另一半——1[3-9]里的1和3-9都是 ASCII 字面量…這一行在第一個字符就斷了根本走不到后面的\d。所以把[3-9]換成\d救不了全角只有把文本先歸一化才行。順序也不能反判據(jù)二歸一化必須放在匹配之前。先匹配、后歸一化等于用錯誤的輸入做了一次判斷再補(bǔ)救已經(jīng)晚了。4.2 錨點給長數(shù)字規(guī)則加前后邊界錨點指的是在規(guī)則兩頭加上「前面必須是什么、后面必須是什么」的約束。對純數(shù)字字段來說最有用的一種錨點是否定型數(shù)字邊界前后不許緊挨著數(shù)字或分隔符。??代碼待驗證# 本文改進(jìn)寫法未在主代理的實測腳本里跑過PHONEre.compile(r(?![\d\-])# 前面不能是數(shù)字或短橫r(?:(?:\|00)?86[\- ]?)?# 可選國家碼86 / 0086r1[3-9]\d(?:[\- ]?\d{4}){2}# 3 位號段 兩組 4 位r(?![\d\-])# 后面不能是數(shù)字或短橫)按這個結(jié)構(gòu)前面那 11 次誤判里能被推掉的是三類13 位時間戳、15 位流水號、13 位運單號里的數(shù)字部分。機(jī)制是(?![\d\-])——時間戳那 11 位后面還跟著99邊界斷言不成立整條匹配失敗正則不會退而求其次去匹配一個短一點的子串。但18 位訂單號推不掉。它本身就是 18 位純數(shù)字前后都沒有別的數(shù)字任何「前后不挨數(shù)字」的斷言對它都是成立的。要區(qū)分它和身份證只能看它前面寫的是「訂單號」還是「身份證」——這就是下一節(jié)。另外提醒一個反向的坑加了(?![\d\-])之后008613812345678這種緊貼國家碼的寫法會被前面那個0擋住所以國家碼部分要顯式允許00前綴否則會新造一個漏點。這類「修一個漏點、長出另一個漏點」的情況只有靠用例回歸才攔得住。4.3 位數(shù)不夠必須看字段名前綴判據(jù)三長數(shù)字規(guī)則必須帶上下文錨點。把上面的結(jié)論壓成一句位數(shù)只能篩候選字段名才能定類型。同一個 18 位數(shù)字串出現(xiàn)在「訂單號 202610221234567890」里是業(yè)務(wù)主鍵出現(xiàn)在「身份證 110101199003071234」里是敏感個人信息。正則看到的兩個串長得一模一樣它沒有辦法自己判斷。能判斷的信息在字段名前綴上——也就是那個 18 位數(shù)字前面若干個字符里出現(xiàn)的「身份證」「證件號」「卡號」「賬號」這類詞。工程上的做法是關(guān)鍵詞窗口不是全行搜索而是要求敏感詞出現(xiàn)在匹配位置之前的一個有限窗口內(nèi)比如前 8 個字符。窗口不能開太大否則一行里同時有「身份證」和「訂單號」時又會串味窗口也不能不開否則就等于回到純位數(shù)判斷。這里要接受一個事實關(guān)鍵詞窗口是業(yè)務(wù)知識不是正則技巧。它依賴你對自家日志格式的了解換一個系統(tǒng)就得重寫。這也是為什么脫敏規(guī)則沒法直接從網(wǎng)上抄一份通用的。五、上線前的五個自檢用例自檢用例的價值不在于「證明規(guī)則能跑」而在于能證偽。一條用例如果怎么改規(guī)則都能過它就沒有存在意義。判據(jù)五規(guī)則要能被證偽。下面五個用例是從上面 11 次誤判里反推出來的每個都對準(zhǔn)一種具體的失敗模式。用例輸入片段構(gòu)造樣本期望結(jié)果對準(zhǔn)的失敗模式同行混排用戶 13812345678 下單 ts1759999999999手機(jī)號被掩時間戳原樣子串誤吃長數(shù)字寫法混排聯(lián)系 159 0000 1111備用兩條都被掩分隔符與全角各漏一類末位小寫證件號 11010119900307123x被掩[Xx]只寫了大寫長數(shù)字互吃訂單號 202610221234567890 卡號 6222021234567890訂單號原樣卡號被掩兩位數(shù)規(guī)則互相吃單號帶字母郵箱 zhangsanexample.com 運單號 SF1381234567890郵箱被掩運單號原樣字母前綴沒進(jìn)錨點??代碼待驗證# 用例斷言輸出里必須出現(xiàn) expected 里的每個片段順序不限CASES[(同行混排,用戶 13812345678 下單 ts1759999999999,[138****5678,1759999999999]),(寫法混排,聯(lián)系 159 0000 1111備用,[159****1111,138****5678]),(末位小寫,證件號 11010119900307123x,[110101********123x]),(長數(shù)字互吃,訂單號 202610221234567890 卡號 6222021234567890,[202610221234567890,6222********7890]),(單號帶字母,郵箱 zhangsanexample.com 運單號 SF1381234567890,[z***example.com,SF1381234567890]),]寫用例時有個細(xì)節(jié)容易漏期望值要寫「原樣保留」的那一半。只斷言「敏感字段被掩了」規(guī)則把整行都打成星號也能通過把「訂單號必須原樣出現(xiàn)」寫進(jìn)斷言誤刪才會變成紅燈。這份資料是什么一份按「先跑通再排查」順序整理的大模型學(xué)習(xí)路線圖里面有一節(jié)專門講工程側(cè)的數(shù)據(jù)處理與合規(guī)動作該怎么拆步驟。放在資料包里掃碼即可獲取六、一張可抄的規(guī)則表下面這份清單是本文的結(jié)論匯總。「實測量」一列寫的是主代理腳本在本機(jī)跑出來的結(jié)果「錨點改進(jìn)」一列是本文加的屬于改進(jìn)寫法沒有實跑。字段實測量分母 5 或 15錨點改進(jìn)要點手機(jī)號R2 歸一化后 15/15R2 原樣 14/15數(shù)字邊界 顯式國家碼 分隔符可選身份證5/5但只寫大寫X會漏末位小寫[\dXx] 關(guān)鍵詞窗口位數(shù)不足以定類型銀行卡3/5帶空格/短橫全漏反向吃身份證 5/5允許分隔符 關(guān)鍵詞窗口 校驗位郵箱5/5本輪無誤判天然錨點保持簡單不要過度加約束時間戳被三條手機(jī)號規(guī)則誤吃不靠正則排除走豁免清單訂單號 / 運單號被 R4、R5 與 R1 誤吃只能靠字段名關(guān)鍵詞豁免需業(yè)務(wù)方給字段清單??代碼待驗證# 本文改進(jìn)寫法錨點 豁免未在主代理腳本中實跑需按自家日志格式調(diào)FWstr.maketrans(,0123456789)# 1) 豁免清單已知的正常長數(shù)字匹配前先掛號脫敏時跳過這些區(qū)間EXEMPTre.compile(r(?!\d)1[6-9]\d{11}(?!\d))# 13 位毫秒時間戳# 2) 四類字段長規(guī)則先跑短規(guī)則后跑避免 16~19 位吃掉 18 位身份證ID_CNre.compile(r(?![\dXx])\d{17}[\dXx](?![\dXx]))CARDre.compile(r(?![\d\-])\d{16,19}(?![\d\-]))PHONEre.compile(r(?![\d\-])(?:(?:\|00)?86[\- ]?)?1[3-9]\d(?:[\- ]?\d{4}){2}(?![\d\-]))EMAILre.compile(r[\w.-][\w-]\.[\w.])這份清單里有三處是「必須按你家的日志改」的抄的時候不要整段復(fù)制豁免清單里的時間戳位數(shù)、國家碼的寫法、以及銀行卡前后允許哪些分隔符。我這輪樣本里只有空格和短橫兩種分隔實際日志里可能還有括號、點號、斜杠。6.1 掩碼留多少留可定位的部分掩碼指的是用星號等字符替換敏感片段。留幾位是有講究的留得太少客服核對不了留得太多等于沒脫敏。字段建議保留掩碼后保留的理由手機(jī)號前 3 后 4138****5678前 3 位看號段后 4 位供本人核對身份證前 6 后 4110101********1234前 6 位是地區(qū)碼排障時常按地區(qū)篩銀行卡后 46222********7890后 4 位是用戶報卡時唯一會說的信息郵箱首字母 域名z***example.com域名能定位到企業(yè)客戶訂單號 / 時間戳全部保留原樣它們是排障主鍵脫了就沒法查6.2 順序與冪等執(zhí)行順序會直接影響結(jié)果\d{16,19}會吃掉 18 位身份證所以身份證規(guī)則必須在銀行卡規(guī)則之前跑或者在銀行卡規(guī)則里排除已經(jīng)被身份證規(guī)則占用的區(qū)間。冪等指的是同一段文本處理兩次結(jié)果和一次一樣。掩碼用*替換數(shù)字之后第二次跑時那些位置已經(jīng)不是數(shù)字了不會二次命中所以天然冪等。但如果某天有人把掩碼改成「保留位數(shù)、把數(shù)字換成 0」第二次跑就會因為位數(shù)沒變而再掩一次長度悄悄變短。這種改動必須在用例里回歸。七、收尾把脫敏當(dāng)接口契約7.1 契約要寫清三件事《中華人民共和國個人信息保護(hù)法》第五十一條第三項要求個人信息處理者「采取相應(yīng)的加密、去標(biāo)識化等安全技術(shù)措施」。去標(biāo)識化指的是讓信息在不借助額外信息的前提下無法指向特定個人。脫敏腳本就是這條要求最直接的落地點。但落到工程上脫敏不該被當(dāng)成一個腳本而該被當(dāng)成一份接口契約。契約至少要寫清三件事輸入寫法清單這套日志里手機(jī)號有幾種寫法、身份證會不會帶小寫 x、卡號會不會分組。這份清單要由寫日志的人確認(rèn)不是脫敏的人猜。輸出掩碼格式每個字段保留幾位、用什么字符掩。這決定了排障的人還能不能干活。豁免字段清單哪些長數(shù)字是正常字段絕不能動。這份清單是誤判的唯一解藥。7.2 規(guī)則要有版本號也要有回歸最后一條判據(jù)規(guī)則文件要帶版本號日志落盤處要記下用的是哪一版。理由是誤判的形態(tài)會變。今天被誤吃的是 13 位時間戳明天業(yè)務(wù)加了一個 19 位的內(nèi)部單號同樣會被\d{16,19}吃掉。如果日志里沒有版本信息出問題時你無法判斷「這條日志里的訂單號為什么變成星號」是新規(guī)則造成的還是三個月前就有的老問題。回歸的方式很簡單把第 5 章那五個用例做成每次改規(guī)則都跑的檢查再加一條「正常字段不得被掩」的斷言。用例不需要多需要的是每次都會跑。這份資料是什么在線可查的大模型知識庫里面有 Agent Skills 與工程化落地的專題目錄適合用來對照本文這種「一條規(guī)則怎么變成可回歸的接口」的寫法。放在資料包里掃碼即可獲取附表 A本文引用事實與出處對照表事實出處本文位置全部命中與誤判數(shù)字9/15、10/15、14/15、15/15、11 次誤判、5/5、3/5本機(jī)實測work/2026-10-22_脫敏實測.py日志work/2026-10-22_脫敏實測.logPython 3.13.14僅標(biāo)準(zhǔn)庫 re第 2、3 章手機(jī)號 15 條樣本按「連續(xù) / 帶分隔符 / 全角或帶前綴」三類各 5 條同上腳本的 SAMPLES 字典1.2、2.1R1 原樣 9/1560.0%歸一化后 10/1566.7%同上日志「手機(jī)號召回」段2.1R2 原樣 14/1593.3%歸一化后 15/15同上日志「手機(jī)號召回」段2.1、4.16 條正常字段共 11 次誤判批次號與商品條碼未被誤判同上日志「正常字段誤判」段第 3 章身份證規(guī)則 5/5末位小寫 x 需[\dXx]才命中同上日志「其他關(guān)鍵點」段2.2銀行卡規(guī)則 3/5且吃掉 5 條 18 位身份證同上日志「其他關(guān)鍵點」段2.2郵箱規(guī)則 5/5本輪無誤判同上日志命中矩陣2.3\d在 Unicodestr模式下匹配任何 Unicode 十進(jìn)制數(shù)字含全角Python 3 文檔 re 模塊Python Software Foundationhttps://docs.python.org/3/library/re.html4.1\b為詞邊界「詞」在 Unicode 模式下指 Unicode 字母數(shù)字加下劃線同上附表 B第五十一條第三項采取相應(yīng)的加密、去標(biāo)識化等安全技術(shù)措施《中華人民共和國個人信息保護(hù)法》全文中央網(wǎng)絡(luò)安全和信息化委員會辦公室 2021-08-20 發(fā)布https://www.cac.gov.cn/2021-08/20/c_1631050028355286.htm7.1錨點版正則、豁免清單、關(guān)鍵詞窗口為本文改進(jìn)寫法未在本機(jī)腳本中實跑本文作者改寫對應(yīng)代碼塊上方已標(biāo)注待驗證提示4.2、6.1附表 B術(shù)語速查表術(shù)語一句話解釋在本文哪里用到脫敏把敏感字段替換、遮蔽后再落盤或外發(fā)的動作第 1 章開頭正則用一串符號描述「什么樣的字符串算命中」的規(guī)則文本1.1召回該抓到的里面實際抓到了多少2.1誤判不該動的正常字段被動過了第 3 章歸一化比對之前先把不同寫法統(tǒng)一成一種形式這里指全角轉(zhuǎn)半角4.1錨點在規(guī)則兩頭加「前后必須是什么」的約束4.2負(fù)向斷言錨點的一種寫法要求「前后不能是什么」如(?!\d)4.2關(guān)鍵詞窗口要求敏感詞出現(xiàn)在匹配位置前方有限字符數(shù)內(nèi)的約束4.3豁免清單已知的正常長數(shù)字匹配前先掛號脫敏時跳過6.1掩碼用星號等字符替換敏感片段的做法6.1冪等同一段文本處理兩次結(jié)果和一次一樣6.2去標(biāo)識化讓信息在不借助額外信息的前提下無法指向特定個人7.1寫在最后這篇用到的資料寫這篇文章時把相關(guān)的官方文檔和源碼又翻了一遍順手也整理了幾份配套的東西大模型學(xué)習(xí)路線圖從零基礎(chǔ)到能自己動手做 Agent按階段說明每一步該學(xué)什么、哪些可以先跳過《LangChain LangGraph MCP 智能體開發(fā)實戰(zhàn)》視頻課7 個模塊從私有化部署、EmbeddingRAG 到 MCPAgent 全流程AI 大模型知識庫在線可查Agent Skills 從入門到落地、Claude Skills 完全指南等專題按目錄瀏覽即可640 套 AI 大模型行業(yè)報告 經(jīng)典 PDF 書籍看行業(yè)落地案例和別人怎么做的時候用得上大模型零基礎(chǔ)到精通教學(xué)視頻跟著敲一遍比只讀文檔快得多資料是我自己整理的放在下面這個碼上掃碼即可獲取添加時備注「AI」優(yōu)先通過。資料按「先路線、再動手、最后查漏」的順序整理好了建議先看學(xué)習(xí)路線那一份照著它挑一條適合自己當(dāng)前基礎(chǔ)的路徑再往下看。