把日志丟給AI之前，先過一遍脫敏過濾器

開發者調試應用時，隨手復制粘貼日志給AI分析，這個習慣可能正在泄露用戶隱私。一位獨立開發者用8年前的MacBook Air做測試，發現Android日志里藏著遠比堆棧跟蹤更多的東西。

日志里到底漏了什么

真實生產環境的日志片段：

D/Network: Connecting to 192.168.1.105:8080
I/Auth: User token: eyJhbGciOiJIUzI1NiJ9...
D/User: Loading profile for user@example.com
I/Device: Serial: R58M123ABCD

IP地址、郵箱、設備序列號、認證令牌（Auth Token）——這些全在普通調試日志里。開發者可能意識不到，自己隨手發給Gemini或ChatGPT的logcat輸出，其實是一份完整的用戶畫像。

更麻煩的是免費層API的服務條款。Gemini的免費 tier 明確說明：提交數據可能用于模型訓練。你的用戶郵箱和內部IP地址，可能成為訓練語料的一部分。

一個Rust寫的過濾器

這位開發者在工具HiyokoLogcat里內置了四層正則過濾，每條日志出設備前先過一遍：

IP地址 → 替換為[IP]
郵箱格式 → 替換為[EMAIL]
Base64類長字符串（20位以上）→ 替換為[TOKEN]
電話號碼格式 → 替換為[PHONE]

代碼實現用了regex和once_cell做惰性初始化，避免每次編譯正則的開銷。8年前的MacBook Air跑起來沒壓力，說明性能損耗可以忽略。

過濾后的效果：

D/Network: Connecting to [IP]:8080
I/Auth: User token: [TOKEN]
D/User: Loading profile for [EMAIL]

堆棧跟蹤和錯誤上下文完整保留，診斷價值沒丟。敏感數據被攔截在設備端，根本到不了AI的輸入框。

寧可錯殺，不能漏放

Token正則有個副作用：它會誤傷。Base64編碼的字符串在日志里太常見了——圖片預覽、校驗和、隨機ID都會被 mask 掉。

開發者的判斷是：誤傷可接受。被 mask 的校驗和不影響AI診斷錯誤，但漏掉一個認證令牌就是安全事故。

這個取舍很務實。安全過濾器的黃金法則從來不是"精準識別"，而是"默認拒絕，人工放行"。

透明比技術更重要

即使做了脫敏，HiyokoLogcat還是在設置頁放了明確提示：

「免費Gemini API可能將提交數據用于模型訓練。日志在發送前會自動脫敏常見個人信息，但在處理敏感應用前請自行檢查日志內容。」

這句話的價值不亞于正則表達式本身。開發者工具的用戶也是開發者，他們理解決策背后的權衡，但前提是被告知。

生產環境日志進AI診斷工具，這個場景的信任鏈很長：終端用戶→應用開發者→調試工具開發者→AI服務商。每一環都可能成為泄露點，而脫敏過濾器只是其中一環。

為什么這件事值得較真

日志脫敏不是新話題，但LLM（大語言模型）的普及讓風險被放大了。以前的調試流程是開發者本地grep，現在是隨手粘貼給云端AI。數據流轉路徑變了，安全習慣沒跟上。

HiyokoLogcat的做法提供了一個最小可行方案：客戶端正則+用戶告知+開源可審計。不需要企業級DLP（數據防泄漏）系統，一個獨立開發者用200行Rust代碼就能堵住最明顯的口子。

這個案例的真正價值在于示范效應。它證明隱私保護可以和工具輕量化共存，而不是安全團隊的專屬領地。當更多開發者工具把脫敏做成默認行為而非可選項，行業基準才會上移。

工具已開源在GitHub，作者X賬號@hiyoyok。如果你也在做類似工具，會把這個過濾器做成強制開啟還是用戶可選？