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