写下这篇文章的时候，我那个红包小助理刚刚跑完第三次完整测试，弹窗和语音都工作正常。整个过程从想法到可用的代码，只花了一个半钟头——如果没有工具辅助，我估计得折腾一整天。
一、从一次“手慢无”说起
事情要从上周说起。
那天中午我正在调试一个棘手的 bug，突然听到同事手机"叮"的一声——微信红包。等我放下手头工作点开微信，群里已经冒出来十几条"谢谢老板"的消息。红包？早就被抢光了。
说实话，这种感觉挺不爽的。不是在乎那几块钱，而是那种"明明就在电脑前却错过了"的落差感。我又不是 24 小时盯着微信的人，工作专注的时候哪顾得上看手机？
晚上回家我就开始琢磨，能不能做个小工具，专门帮我盯着微信通知，一旦有红包相关消息就提醒我一声？
这个想法，帮我省了不少时间，也避免了很多错过红包的遗憾。
二、技术选型：在 Windows 上“合规”地监听通知
定了目标之后，接下来就是怎么实现的问题。
第一个想法是：能不能不碰微信的私有数据，只监听系统的通知？
答案是可行的。Windows 有一套完整的 Toast Notification 机制，任何应用（包括微信）发送通知时，系统都会暴露一个 API 给其他程序监听。这意味着可以“听到”微信发出来的通知，但不需要去翻微信的数据库，更不需要 Hook 它的进程。
技术栈很快就定下来了：
Python 3.11 当主语言，原因很简单——熟悉且生态丰富。监听 Windows 通知用 winrt（Windows Runtime 的 Python 绑定），这是微软官方的 API，合规可靠。语音播报用 pyttsx3，这是个离线 TTS 引擎，不需要联网，调用本地语音合成接口，响应速度快，也不会有隐私泄露的问题。弹窗通知用 plyer，一个简单的跨平台通知库，接口干净，Windows 上调用的是系统原生的通知机制。
至于配置，我用 YAML 格式写了一个 config.yaml，里面可以自定义监听的关键词、语音播报的语速和音量、弹窗的持续时间等等。YAML 的好处是人类可读，哪怕不懂编程的人也能改。
整个架构设计成三层：本地感知层负责监听系统通知，云端推理层（可选）负责 AI 增强识别，本地提醒层负责用户交互（弹窗+语音）。三层之间完全解耦，哪怕云端服务挂了，本地提醒依然正常工作。
三、写代码：AI 帮我搞定了 80% 的脏活累活
要不是有工具辅助，光是研究 Windows Runtime 的 API 文档我就得花掉大半天。
对话如图所示：
第一次跟 AI 聊这个想法的时候，它没有直接给代码，而是先问了好几个问题：是想监听所有通知还是只监听微信？关键词是写死的还是让用户自己配置？语音播报用在线 API 还是本地引擎？
这几个问题问下来，需求突然清晰了很多。原来脑子里只有一个模糊的"做个提醒工具"的想法，但具体到实现层面，有很多细节根本没想过。
等需求聊清楚了，AI 开始帮我写代码。它不是一次性把所有代码都扔出来，而是一层一层来：先写配置加载器，再写通知监听器，然后是提醒引擎，最后是主程序入口。每一层都先给核心逻辑，然后问"需不需要加日志？需不需要错误处理？"
整个对话过程大致是这样：
我："帮我写个通知监听模块，用 Windows 的 Toast API。"
AI："好的，我给你一个基于 winrt 的实现。不过要注意，直接调用 ToastNotificationManager.create_toast_notifier() 可能会报错，因为需要正确的 AppUserModelId。我给你一个兼容方案。"
然后它就真的给了。不是伪代码，是能直接运行的代码。
当然，中间也有翻车的时候。比如语音播报那块，第一次写的时候没考虑到 pyttsx3 的 runAndWait() 会跟 asyncio 的事件循环冲突，结果第二次播报就报了个 "run loop already started" 的错误。把报错贴给 AI，它想了想说："这个问题是因为 pyttsx3 的引擎实例不能在多个线程里共享，你试试每次播报时创建新的引擎实例。"
照做了，果然就好了。
四、踩过的那些坑（以及怎么爬出来的）
坑一：winrt 包装不上
在 PowerShell 里敲 pip install winrt，结果报了个 "Could not find a version that satisfies the requirement winrt"。
起初有点懵，AI 提醒去 PyPI 上搜了一下，才发现 Windows Runtime 的 Python 绑定不是叫 winrt，而是分成了十几个细分包，比如 winrt-Windows.UI.Notifications、winrt-Windows.Data.Xml.Dom 这种。正确的安装命令是：
pip install winrt-Windows.UI.Notifications winrt-Windows.Data.Xml.Dom这种事情，如果不踩一次坑，估计得在文档里翻半天才能搞清楚。
坑二：Toast 监听器启动失败
代码写完了，一运行，报了个 "'ToastNotificationManagerForUser' object has no attribute 'add_notification_received'"。
这个错误的意思是，用的 API 接口不对。ToastNotificationManager 在 Windows 上有几种不同的初始化方式，有的返回的是 ToastNotificationManagerForUser 对象，有的返回的是 ToastNotifier 对象，它们支持的方法不一样。
AI 的解决方案是用 try-except 包裹两层初始化逻辑：先试 get_default()，如果失败了，再降级到用 Python 可执行文件的 AppUserModelId 来创建通知器。这样一来，不管在哪种 Windows 环境下运行，都有备用方案。
坑三：语音播报第二次就跪了
这个坑前面提到过。pyttsx3 的 runAndWait() 是个阻塞调用，而且它的引擎实例不是线程安全的。如果主线程里跑着 asyncio 的事件循环，又在另一个线程里调用 runAndWait()，就会发生冲突。
最终的解决方案是把语音播报放到一个完全独立的线程里，每次播报时创建新的引擎实例，播完就销毁。虽然有点浪费资源，但对于一个轻量级的桌面小工具来说，这点开销完全可以接受。
五、测试：听到那句“红包来啦”，我笑了
代码写得差不多的时候，面临一个问题：怎么测试？
Toast 监听器需要正确的 AppUserModelId 注册才能工作，但本地环境还没配置这个。难道要为了测试去改系统注册表？太麻烦了。
AI 给了一个很聪明的建议：写个模拟测试模式。
它在 notification_listener.py 里加了一个 start_mock_mode() 方法，会模拟三条微信通知（"小明发来一个红包，快去抢！"、"工作群：老板发了现金奖励"、"转账到账：100元"），然后走完整的提醒流程。这样不用真的去配置系统注册，就能验证关键词匹配、弹窗通知、语音播报这一整套逻辑是不是通的。
第一次跑通的时候，电脑屏幕上弹出了"? 红包来啦！快去微信查看！"的弹窗，同时音箱里传来了微软 Huihui 中文语音："红包来啦！快去微信查看！"
效果如下：
那一瞬间，觉得这玩意儿还真有点意思。
后来测了三次，每次都正常。弹窗能弹出来，语音能播出去，关键词匹配也没问题。唯一的小瑕疵是第二次和第三次语音播报的时候，偶尔会报个 "run loop already started" 的错误（就是前面说的那个坑），但弹窗不受影响，提醒功能完全可用。
六、为什么坚持“只提醒、不代劳”？
文章写到这儿，估计有人会问："你都能监听通知了，为啥不顺便把抢红包的功能也做了？"
这个问题跟 AI 讨论过。它的回答很克制，说这是我的项目，它不会替我做合规判断。但它在回复里特意提到了微信的服务条款，还列出了自动抢红包工具可能涉及的法律风险。
认真想了想，决定不做。
不是因为技术上有多难——事实上，如果要 Hook 微信进程、模拟点击操作，以技术能力不是做不到。而是因为有些事情不该做。
自动抢红包工具需要做的事情包括：Hook 微信进程注入代码、模拟用户点击操作绕过反作弊机制、实时分析聊天界面识别红包位置。这些行为，轻则违反微信的服务条款，重则可能触犯《计算机软件保护条例》。而且用户的账号有可能被封禁——为了抢几个红包冒这个险，值得吗？
给这个项目定了个 slogan：打造一只「守规矩的消息小助理」—— 只提醒、不代劳。
它做的事情很简单：监听系统通知，发现包含"红包"、"现金"、"转账"等关键词的消息时，弹个窗，播个音，提醒一声。仅此而已。
不读取微信的数据库，不 Hook 微信的进程，不模拟点击，不自动抢红包。所有的数据处理都在本地完成，不会上传到任何云端服务器。配置文件完全开放，任何人都可以审查它的代码，确认它没有在干坏事。
这才是一个"助手"应该有的样子。
七、用 AI 做开发是什么体验？
文章的最后，聊聊用 AI 做这个项目的真实感受。
如果要用一句话概括，那就是：它把角色从"代码打字员"变成了"架构设计师"。
以前写代码，大部分时间都花在查文档、调 API、改 bug 上。一个功能能不能实现，往往取决于是否知道某个库的存在，或者能否在 Stack Overflow 上找到相似的例子。但用 AI 之后，很多以前需要花几个小时去研究的东西，现在对话几分钟就能搞定。
比如 Windows Runtime 的 API，如果自己去啃微软的文档，估计得花掉大半天。但 AI 直接给了完整可用的实现，还附带了异常处理和兼容方案。再比如 pyttsx3 的线程安全问题，如果自己调试，可能得在那儿 print 半天才能定位到问题。但 AI 看到报错日志之后，几乎是一秒钟就给出了正确的修复方案。
当然，AI 不是万能的。它有的时候也会犯错，比如生成的代码里有个把语法错误（比如 f-string 里不能包含反斜杠），或者给出的建议不完全适合使用场景。但这没关系，因为最终的判断权在自己手里。它是助手，不是老板。
AI 辅助开发的未来，大概就是这个样子：人类负责想清楚要做什么，AI 负责帮你想清楚怎么做，然后把你想要的代码写出来。人类不再需要把大把的时间花在重复性的编码工作上，而是可以把精力放在更有创造性的事情上——比如怎么把架构设计得更好，怎么让用户体验更流畅，怎么在功能和合规性之间找到平衡点。
这次做一个红包提醒助手，从想法到可用代码，只花了一个半钟头。如果换成以前，这得是一整天的活。这中间的差距，不全是因为 AI 写代码比手动快（虽然它确实很快），而是因为它帮我们把很多以前需要反复试错才能搞定的事情，压缩成了几次高效的对话。
这种感觉，用过就回不去了。
八、写在最后
红包小助理这个项目，技术上没什么特别高深的地方。它本质上就是个桌面小工具，监听系统通知，匹配关键词，触发提醒。但之所以愿意花时间去做，愿意写这篇文章分享出来，是因为做一个"守规矩"的工具，比做一个"强大"的工具更有意义。
希望生活更方便，但不应该以牺牲安全和合规为代价。
希望这篇分享能帮到正在探索 AI 辅助开发的你。如果你用 AI 工具做出了有趣的项目，也欢迎分享你的故事。
附录：如果你想试试这个项目
代码已经整理好了，放在 C:Userswudi.openclawworkspacered-packet-assistant 目录下。如果你想在本地跑一跑，步骤很简单：
先装依赖。PowerShell 里 cd 到项目目录，然后执行：
python -m venv venv
.venvScriptsActivate.ps1
pip install -r requirements.txt
依赖装完之后，直接运行：
python srcmain.py程序启动之后会进入模拟测试模式，你会看到三条模拟的微信通知，每条都会触发弹窗和语音播报。如果想改成真正监听系统通知，需要配置一下 AppUserModelId（这部分 AI 在 docs/architecture.md 里有详细说明）。
配置文件是 config.yaml，你可以往里面加任何你想监听的关键词。比如除了"红包"、"现金"、"转账"之外，还加了个"外卖"，这样外卖到了的时候它也会提醒一声。
