把日志丢给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。如果你也在做类似工具，会把这个过滤器做成强制开启还是用户可选？