1. 项目概述用AI为你的通知栏“清道”如果你是一名Android用户每天被各种应用推送的广告、营销、垃圾信息轰炸到不胜其烦那么你肯定想过要是能有个智能管家自动识别并帮我屏蔽掉这些恼人的通知就好了。手动设置规则太麻烦而且广告文案千变万化传统的关键词过滤根本防不胜防。这正是我当初开发NITM-GPTNotification-in-the-middle GPT的初衷——一个利用GPT-3/4大语言模型的理解能力在通知到达你眼前之前就帮你判断并自动隐藏垃圾信息的Android应用。简单来说NITM-GPT扮演了一个“中间人”的角色。它通过Android系统的无障碍服务权限实时监听所有应用发出的通知。每当有新通知时它不会直接展示给你而是先将通知的标题和内容文本发送给OpenAI的API。由AI模型来判断这条通知是“有用信息”还是“广告/垃圾信息”。如果被判定为后者应用会自动将其静默处理隐藏或标记只有那些被AI认定为重要的通知才会正常显示。这相当于给你的手机通知系统加装了一个基于自然语言理解的智能防火墙。这个项目完全开源基于Flutter构建核心逻辑用Dart和Java用于原生层服务保活实现。它不是为了替代系统通知中心而是作为一个增强层尤其适合那些对通知质量有要求、又厌倦了手动管理的进阶用户。接下来我会详细拆解这个项目的设计思路、实现细节、踩过的坑以及如何让它更稳定地运行在你的设备上。2. 核心设计思路与架构解析2.1 为什么选择“AI中间人”方案在动手之前我评估过几种常见的通知过滤方案。传统方案主要有两种一是基于应用包名的黑白名单这太粗暴会误伤很多应用内的有用通知二是基于正则表达式或关键词匹配但广告文案花样百出“限时优惠”、“点击查看”、“恭喜您”这类关键词既可能出现在广告里也可能出现在同事或家人的消息中误判率很高且规则维护成本巨大。而大语言模型如GPT-3.5/4的核心优势在于语义理解。它不仅能识别关键词更能理解一段文本的意图和上下文。例如一条通知写着“您的包裹已到达菜鸟驿站取件码123”另一条写着“恭喜您获得一张满100减10优惠券点击领取”。人类能轻易分辨前者是物流信息后者是广告。GPT模型经过海量文本训练同样可以做到类似的判断准确率远高于规则引擎。因此“AI中间人”架构应运而生。它的工作流非常清晰捕获通过NotificationListenerService捕获系统产生的每一条通知。提取提取通知的关键元数据应用包名、标题、内容文本、时间戳等。询问将标题和内容组合成一段提示词Prompt调用OpenAI API进行判断。决策与执行根据AI返回的结果是/否为广告决定是放行通知还是调用系统API将其取消cancel。这个架构的巧妙之处在于它将复杂的模式识别问题转化为了一个AI擅长的文本分类问题极大地提升了过滤的智能度和适应性。2.2 技术栈选型与考量项目的技术选型紧紧围绕“跨平台”、“高性能后台服务”和“快速开发”这三个核心需求展开。Flutter Dart (UI 核心逻辑)作为主要开发框架。Flutter的跨平台特性虽然在本项目中主要服务于Android但其高效的渲染和丰富的Material You组件库能快速构建出美观且符合现代设计规范的用户界面。Dart语言的异步流Stream特性非常适合处理源源不断的通知事件。Java/Kotlin (Android原生层)这是保证应用“永生”的关键。Flutter本身不适合实现需要常驻后台、且被系统杀死后能自动重启的强力服务。因此我们必须依赖Android原生开发。使用Java编写一个ForegroundService前台服务并搭配WorkManager或AlarmManager进行定时唤醒和状态检查确保监听服务在任何情况下都能持续运行。这部分通过Flutter的Platform Channel与Dart层进行通信。OpenAI API (GPT-3.5-turbo)选择GPT-3.5-turbo而非更贵的GPT-4是在成本、速度和精度之间取得的平衡。对于通知文本分类这种相对简单的任务3.5-turbo模型已经绰绰有余且API调用成本更低、响应更快。我们通过HTTP客户端直接与OpenAI的ChatCompletion端点交互。本地数据库 (Hive/SQLite)用于存储用户配置如API Key、自定义规则、过滤历史记录。考虑到需要存储的数据结构并不复杂且需要快速读写我选择了Hive它是一个轻量级、基于键值的NoSQL数据库用Dart编写与Flutter集成度极高性能出色。整个应用的架构可以看作一个“夹心层”Flutter UI层提供交互界面Dart业务逻辑层负责流程控制和AI通信Android原生服务层负责底层通知监听和进程保活。三层之间通过MethodChannel和EventChannel紧密协作。注意隐私与成本权衡这是本项目最需要用户理解的一点。为了实现AI过滤通知文本必须被发送到OpenAI的服务器。尽管OpenAI有严格的数据使用政策但这意味着你的部分通知内容会离开本地设备。因此在“自定义规则”中设置忽略敏感应用如微信、Telegram、银行App等是强制性的最佳实践。切勿让所有通知都经过AI过滤。3. 核心模块实现与实操要点3.1 Android原生层通知监听与服务保活这是应用的基石也是最容易出问题的部分。Android系统为了省电对后台服务的限制越来越严格。我们的目标是实现一个“杀不死”的通知监听服务。1. 实现NotificationListenerService这是一个Android系统提供的特殊Service专门用于监听通知。我们需要在AndroidManifest.xml中声明并请求BIND_NOTIFICATION_LISTENER_SERVICE权限。用户必须在系统设置中手动授权这是无法绕过的步骤。service android:name.NotificationListener android:permissionandroid.permission.BIND_NOTIFICATION_LISTENER_SERVICE android:exportedtrue intent-filter action android:nameandroid.service.notification.NotificationListenerService / /intent-filter /service在NotificationListener类中重写onNotificationPosted方法。当有新通知时这个方法会被调用我们可以获取到StatusBarNotification对象从中提取出所有需要的信息。2. 实现前台服务ForegroundService仅仅有ListenerService还不够它可能被系统回收。我们需要将其与一个前台服务绑定。前台服务会在状态栏显示一个持续的通知告诉用户NITM-GPT正在运行这能显著降低被系统杀死的概率。// 在服务的onCreate或onStartCommand中 Notification notification buildPersistentNotification(); // 构建一个常驻通知 startForeground(NOTIFICATION_ID, notification);3. 应对系统休眠与进程杀死即使有前台服务在深度休眠或用户手动强制停止后服务仍可能被终止。这里需要组合拳使用WorkManager设置周期性任务每隔一段时间如30分钟检查一次监听服务是否在运行如果不在则尝试重启它。监听系统广播注册BOOT_COMPLETED开机启动、USER_PRESENT用户解锁等广播在特定事件发生时重启服务。禁用电池优化引导用户前往系统设置为NITM-GPT应用禁用电池优化忽略电池限制。不同厂商的路径差异很大如小米的“神隐模式”、华为的“启动管理”这是用户反馈服务掉线最常见的原因需要在应用内提供详细的引导图。实操心得保活是一场“军备竞赛”。没有一劳永逸的方案。我的策略是“多管齐下优雅降级”。优先保证前台服务稳定其次利用系统合法机制定时检查。绝对要避免使用那些会被应用商店判定为恶意行为的“黑科技”保活手段。同时在UI上清晰告知用户服务状态运行中/已停止并提供一键重启的入口把控制权交给用户。3.2 Flutter层AI判决引擎与流程控制Dart层负责核心的业务逻辑组装数据、调用AI、做出决策。1. 构建高效的PromptPrompt的设计直接决定AI判断的准确率和API成本。经过多次测试我固定使用以下模板请你判断以下内容是否是一条广告、营销推广或垃圾信息。只回答“是”或“否”。 标题[通知标题] 内容[通知内容]这个Prompt非常简洁明确了任务判断广告、限定了输出格式是/否并将标题和内容结构化地提供。经过测试GPT-3.5-turbo对此类指令遵循得很好响应速度也快。更复杂的Prompt如要求给出理由只会增加Token消耗和延迟对核心功能无益。2. 调用OpenAI API使用http或dio包发起网络请求。这里的关键是错误处理和重试机制。Futurebool isNotificationSpam(String title, String content) async { final prompt _buildPrompt(title, content); final messages [{role: user, content: prompt}]; try { final response await _openAIClient.post( https://api.openai.com/v1/chat/completions, body: jsonEncode({ model: gpt-3.5-turbo, messages: messages, max_tokens: 10, // 限制输出长度节省成本 temperature: 0.1, // 低随机性确保结果稳定 }), ); final result jsonDecode(response.body); final answer result[choices][0][message][content].trim().toLowerCase(); return answer 是 || answer.contains(yes); // 处理中英文回复 } catch (e) { // 网络超时、API限额、服务器错误等 _logError(e); // 重要失败时默认放行通知避免因网络问题屏蔽所有信息 return false; } }3. 决策与执行收到AI的“是/否”判决后Dart层通过MethodChannel调用原生层的方法执行具体的操作。若为广告是调用原生方法cancelNotification(String packageName, int id)将这条通知从系统状态栏移除。若为非广告否不做任何操作让通知正常显示。同时无论判决结果如何都将该条通知的记录时间、应用、标题、判决结果存入本地数据库Hive方便用户在应用内查看过滤历史这也是后续优化模型规则的依据。3.3 自定义规则系统给用户一把“手动扳手”完全依赖AI是不现实的也是危险的。自定义规则系统是平衡智能与可控性的关键。忽略列表Ignore List用户可以添加应用包名到此列表。对于列表中的应用NITM-GPT将完全放行其所有通知不经过AI判断。这是处理隐私敏感应用如通讯软件、邮箱、银行和重要工作应用的唯一正确方式。我强烈建议用户首次安装后立即将微信、支付宝等应用加入忽略列表。关键词规则作为AI的补充用户可以设置一些确定性的关键词如“赌场”、“代开发票”只要通知中包含这些词无需经过AI直接屏蔽。这可以用于处理那些明确违规、且AI可能因政策原因不敢明确判定的内容。白名单模式一个高级功能是“仅允许列表”。与忽略列表相反只有列表中的应用通知会经过AI过滤其他应用全部放行。这适合那些只希望针对少数几个“广告重灾区”应用如某些新闻客户端、游戏进行过滤的用户。这个规则系统的优先级是关键词规则 忽略列表/白名单 AI判断。它确保了用户拥有最终控制权。4. 性能优化、成本控制与隐私安全4.1 减少API调用与成本控制频繁调用OpenAI API是主要成本来源。我们必须精打细算去重与频率限制同一应用在短时间内发出的相同或相似内容的通知只发送一次AI请求。例如某个新闻App在1分钟内推送了10条标题都是“热点新闻”的通知我们只判断第一条后续的可以直接应用相同结果或暂时缓存。利用通知分组GroupAndroid系统支持通知分组。对于分组通知可以尝试只分析其摘要或最新的一条而不是组内每一条都分析。设置每日/每月限额在应用内提供设置选项允许用户设定每日最大AI判断次数如200次/天。达到限额后自动切换到仅使用自定义规则模式或完全放行。模型选择坚持使用gpt-3.5-turbo它是目前性价比最高的模型。只有当用户明确需要且愿意承担成本时才提供切换至GPT-4的选项。4.2 隐私安全加固隐私问题是此类应用的“生命线”。除了强制用户忽略敏感应用外我们在设计和代码层面也做了以下工作数据最小化仅向API发送通知的标题和文本内容。绝不发送包名、图标、用户身份信息、设备信息等任何元数据。在Dart层发送前会对文本进行简单的清理移除可能意外包含的个人信息片段如类似手机号、邮箱的正则匹配但这只是辅助。本地化处理所有用户配置、过滤历史都加密存储在本地设备上。AI判断的结果是/否也只在本地使用不会上传到任何其他服务器。网络传输安全所有与OpenAI API的通信均使用HTTPS加密。应用的网络权限仅用于连接api.openai.com这一个域名。开源透明项目完全开源任何人都可以审查代码确认没有数据收集或后门行为。这是建立信任最有效的方式。4.3 提升响应速度与用户体验AI请求带来的延迟是不可避免的但可以优化异步非阻塞AI判断必须是异步操作绝不能阻塞主线程或通知接收线程。收到通知后立即返回在后台线程中进行网络请求和判断。用户可能会先看到通知闪现然后很快消失这是正常现象。缓存策略对常见应用、常见广告语模式建立本地缓存。如果一条通知的文本与缓存中的某条“广告”样本高度相似可以直接判定无需请求API。这个缓存可以根据用户的历史判决结果进行学习和更新。连接池与超时设置使用HTTP客户端连接池并为API请求设置合理的连接超时和读取超时如3秒。超时后立即失败放行通知避免用户因网络延迟而长时间看不到重要信息。5. 常见问题排查与实战调试记录在实际开发和用户反馈中我遇到了形形色色的问题。这里整理一份“避坑指南”。5.1 服务无法常驻或被系统杀死现象应用运行一段时间后过滤功能失效通知不再被拦截。排查步骤进入NITM-GPT应用检查首页状态是否显示“服务运行中”。如果显示“服务已停止”点击“重启服务”。如果重启后很快又停止进入手机“设置”-“应用管理”-找到NITM-GPT-“电池”或“耗电详情”。关键操作将电池优化策略设置为“不允许”或“无限制”。不同手机品牌该设置名称和路径差异极大小米MIUI设置 - 省电与电池 - 右上角齿轮设置 - 应用智能省电 - 找到NITM-GPT - 选择“无限制”。华为EMUI/HarmonyOS设置 - 电池 - 应用启动管理 - 找到NITM-GPT - 关闭“自动管理”并手动打开“允许自启动”、“允许关联启动”、“允许后台活动”。三星One UI设置 - 应用程序 - 找到NITM-GPT - 电池 - 优化电池使用量 - 所有应用程序列表中找到NITM-GPT - 关闭优化。如果以上步骤无效检查是否被手机管家类的清理工具加入了“清理白名单”或“受保护应用”列表。根本原因国产定制系统AOKP普遍存在激进的后台管理策略以提升续航。我们的前台服务和监听服务需要争取到“免死金牌”。5.2 AI过滤不准确或误判现象有用的通知被屏蔽或者广告通知漏过。解决方案利用历史记录进入应用的“历史”页面查看被误判的通知。长按该记录可以选择“加入忽略列表针对该应用”或“报告误判”。报告功能会将这条通知的文本和你的反馈是/否广告匿名记录下来用于未来优化本地缓存或Prompt但不会上传给OpenAI。优化自定义规则对于总是误判的某个应用比如“钉钉”的工作通知偶尔被当成营销信息最好的办法是直接将“钉钉”加入忽略列表。AI不是万能的对于边界模糊的信息人的判断更可靠。调整Prompt高级对于普遍性问题可以在下一版本中优化全局Prompt。例如如果发现AI对包含“更新”、“升级”字样的通知过于敏感可以将Prompt改为“...忽略关于应用正常功能更新、系统安全更新的通知。”接受不完美目前的技术水平追求100%准确率是不现实的。我们的目标是屏蔽掉80%以上显而易见的垃圾信息同时通过忽略列表确保100%不遗漏重要信息。这个平衡点需要用户根据自己的容忍度来调整。5.3 API密钥错误或额度耗尽现象所有通知都不再被过滤历史记录显示AI判断失败。排查检查设置中的OpenAI API Key是否正确填写是否有多余空格。登录OpenAI平台检查API余额是否充足以及用量是否超过速率限制RPM/TPM。检查网络连接是否无法访问OpenAI API某些网络环境可能需要特殊配置。应对策略应用应设计为“故障开放”Fail-Open原则。即当AI服务不可用时自动降级为仅使用自定义规则模式或完全放行所有通知确保不影响手机核心的通知功能。5.4 通知监听权限被系统收回现象突然某天功能失效检查发现应用内显示“未授予通知监听权限”。原因系统更新、安全软件清理、或者用户误操作可能导致权限被重置。解决在应用内检测到权限丢失时主动弹窗引导用户跳转到系统设置页面重新授权。这个跳转的Intent是固定的可以稳定实现。开发这样一个深度集成系统功能的应用就是不断与不同厂商的系统特性、用户的使用习惯以及AI的能力边界进行磨合的过程。每一个稳定运行的背后都是对无数个细节的反复调试和优化。