打開我們官網的實戰案例頁，你會發現一件同行不太做的事：每個案例都不是影片，而是完整的 AI 會話回放，旁邊還有一個 .zsession 檔案可以下載匯入。從第一句提問到最後一份報告，模型如何推理、呼叫了哪些工具、哪一步出錯、如何恢復——全程未刪減，10 個案例，無一例外。
這樣做的團隊並不多，原因也不難理解：AI 會話是最誠實的日誌，也是最容易洩密的日誌。 其中包含執行過的命令、工具傳回的原始輸出、環境變數的回顯、內網的拓撲、客戶的名稱——任何一項外洩，都可能造成一次真實的安全事件。所以業界的常態是：示範影片經過剪輯，截圖經過處理，會話本體不見天日。
我們做出了相反的選擇。支撐這個選擇的不是勇氣，而是一道在內容離開本機之前工作的資料脫敏引擎。本文說明三件事：它如何工作、我們在哪裡犯過錯，以及一個容易被忽視的事實——好的脫敏，並不是遮得越多越好。
一、「原樣」的是過程，遮住的是隱私
先把標題裡的「原樣」定義清楚：原樣的是工作過程，遮掉的是敏感欄位。 回放中的每一次推理、每一次工具呼叫、每一次失敗重試，都是真實發生的原貌；而授權序列號、金鑰、令牌這類資訊，在匯出的那一刻已被替換。
這一點可以直接驗證。打開智甲 EPP 自動巡檢案例的會話回放，定位到巡檢報告部分，可以看到這樣一行：
授權序列號：
****，過期時間：2026-06-24（剩餘 1 天）
報告末尾，AI 自己寫下了一句：「敏感資訊已脫敏：授權序列號已替換為 ****。」——脫敏動作本身，也保留在紀錄裡。這正是我們想要的狀態：遮掩是顯式的、可見的、可稽核的，而不是悄悄刪除內容。
二、脫敏的基礎能力
它在產品中的位置是 設置 → 資料脫敏，定位是一個外發場景的資料保護引擎：只在內容離開本機之前介入——匯出 HTML 回放、匯出 .zsession、AI 落盤 .md 文件，三個場景各有獨立開關。日常對話與本機分析，不做任何處理。
規則層提供四種類型：
- keyword——字面串全替換，樸素而可靠；
- regex——RE2 正則，替換模板支援捕獲組，可以實現「留頭遮尾」式的部分遮掩；
- ipv4_mask——結構化的 IPv4 遮掩，可指定遮掩第幾段（任意段，含中間段），而非整體遮掩；
- domain_mask——域名遮掩，保留末尾幾級標籤（預設只留 TLD），其餘替換為遮掩字元。
規則之上還有一組內置 secrets 預設，覆蓋高置信度、低誤報的常見憑證格式：AWS Access Key、GitHub PAT、Slack Token、Stripe Live Key、GCP API Key、OpenAI Key，以及整塊跨行的 PEM 私鑰。這些格式特徵明確（AKIA…、ghp_…、sk_live_…），誤報率低，啟用成本很小——即使把一把真實的 AWS 金鑰誤貼進會話，匯出時它也已被替換。
兩個設計決策值得說明：
命中必留痕。 每次觸發脫敏的匯出，都會給出一條提示：命中了多少條、命中了哪幾條規則（按規則 Label 列出）。這份檔案的每一處改動都有據可查——脫敏系統本身不能是黑箱：否則既無法確認它遮全了，也無法確認它沒有遮錯。
狀態始終明確。 總開關關閉時，所有場景一律放行原文。這個設計看似保守，實則必要——半開半閉的脫敏才是真正危險的狀態：使用者以為已遮掩，實際沒有。我們寧可讓使用者明確知道「當前沒有脫敏」，也不製造「開啟之後不知道哪裡少了內容」的錯覺。基於同樣的理由，write_md 落盤脫敏預設關閉：它會改變寫入內容，需要使用者明確啟用。
值得補充的是，「憑證不出門」的原則貫穿產品各處：MCP 配置的讀類工具（mcp.describe_server、mcp.export_config）傳回的 authToken 一律只顯示尾 4 位，環境變數值整體遮掩——無論是否匯出，憑證在對話流中已經處於遮掩態。
三、兩次缺陷，兩次修復
脫敏機制很難一次做對。我們的發布日誌裡記錄著兩次真實的缺陷修復：
第一次：程式碼區塊行首的 IP 未被遮掩。 會話匯出的是 JSON 結構，程式碼區塊內容帶著轉義。舊實作對轉義前的文字套用規則，程式碼區塊中行首位置的 IP 因此未被匹配。修復方式是改為對解碼後的 JSON 文字值套用規則——先還原為最終呈現的文字，再決定遮什麼。
第二次：嵌套 JSON 的深層欄位被遺漏。 工具呼叫的參數和結果中常常嵌套著另一層 JSON，舊實作只掃描頂層文字值，深層欄位成為盲區。修復方式是遞歸下鑽嵌套的 JSON 結構，將工具呼叫的參數與結果全部納入覆蓋。
兩個缺陷指向同一個教訓：脫敏引擎的對手不是「敏感字串」，而是資料的形態。轉義、嵌套、編碼——每一層形態變換，都可能成為敏感資訊躲過遮掩的通道。這兩條修復都原樣寫進了發布日誌與參考手冊——缺陷並不可怕，不留紀錄的修復才可怕。
四、脫敏不是越多越好
最後說那個容易被忽視的事實。仔細檢查我們公開的會話，會發現其中保留著不少內網 IP——這不是遺漏，是判斷。三個真實例子，全部可以在官網驗證：
IRC 殭屍網路流量分析的會話裡，受害主機 192.168.7.133、內網 DNS 192.168.7.2 原樣保留。因為它們是樣本 pcap 中的流量——受害主機與 C2 的通聯關係正是這個案例的證據鏈本身。將其遮掩，研判過程無法重現，會話回放也就失去了公開的意義。樣本中的 IOC 是研判對象，不是隱私。
EDR 行為告警鏈分析的會話裡有一串 10.0.19041.4522，形似內網 IP，實際是 Windows 的版本號。一條不加區分的 IPv4 正則會將它誤處理為 10.0.*.*，告警分析中的系統版本資訊隨之遺失。這正是 ipv4_mask 設計為「可指定遮掩哪一段」的原因——機制要精確，判斷要留給專業的人。
智甲 EPP 巡檢的會話裡，授權序列號被遮掩為 ****，而巡檢目標的 SSH 連線地址 192.168.80.152 保留——前者是憑證，洩露有真實代價；後者是示範環境中的巡檢對象，遮掩它，讀者將難以理解巡檢在對誰進行。
三個例子指向同一個結論：什麼必須遮、什麼必須留，是領域判斷，不是正則能替你做的決定。 遮多了毀證據，遮少了漏憑證——脫敏引擎提供的是精確執行判斷的機制，而判斷本身，來自對安全工作的理解。這也是我們始終堅持的觀點：安全場景的工具，更適合由安全團隊來打造。
五、閉源產品也需要透明
作為直接面向對抗的安全智慧體，我們選擇不公開檢測核心，而以「可驗證的發布」承擔透明的義務（見《為什麼選擇閉源》）。會話公開是同一個答案的另一半——
我們不公開原始碼，但公開行為。 AI 如何分析一個樣本、如何在唯讀分析區保持克制、如何出錯又如何自愈，全過程原樣可查、可下載、可匯入重現。原始碼透明證明的是「程式碼長什麼樣」，行為透明證明的是「它實際做了什麼」——對一個要進入你工作台的智慧體，後者往往更接近使用者真正關心的問題。
而這份行為透明能夠成立的前提，脫敏能力是基礎之一：因為出口處守得住，過程才敢全部公開。 你的會話本機保存，匯出時同一套規則為你工作——我們敢掛在官網上的，你也可以放心發給同事、交給客戶、寫進復盤報告。
透明與保密並不必然對立。分得清什麼該公開、什麼該守住，兩件事就能同時成立。
我們在 AVL Code 中等你，騎著驢，全程可回放、可脫敏。
AVL Code，AVL 安全引擎，與智慧隨行。安天瀾砥團隊出品。