开发日志
前言
某日，我的女朋友 @橘子 正在与我 @帆（ﾟOﾟ） 讨论雷达相关问题，她随口一提——“能不能把你的微信接一个AI接口？”妙蛙，我抱着试一试的想法在某著名同性交友平台上搜索了一下，发现了一个很有名的开源项目，有三万多个stars，可以一键将自己的wechat绑定上AI接口，我满心欢喜配置了一下，在linux主机上测试成功后，部署到了我的服务器上
但好景不长，由于他使用的是it-chat协议，本质上是利用网页端微信协议构造的第三方平台，会被微信封禁，随着关小黑屋的次数越来越多，账号被封的时间越来越长，这条路基本是行不通了，这条方案被彻底抛弃于2025年1月9日，当日腾讯重拳出击，通过一种奇妙的方法让所有尝试重新运行的代理程序光速下线，虽然经测试原在运行的程序不会受到影响，但也是早晚的事情了
这次探索不是终端而是开始，在封禁结束的宝贵间隙里，我大概每天有几个小时的时间收集女朋友的反馈，并且逐步确认了她的需求和整个程序的架构及原理，为之后自己开发打下了基础。此外，我又去寻找了一些开源项目，发现了很多利用手段的接入方法，除了it-chat协议之外，还有基于桌面端协议的接入方法，使用golang语言编写，这使得程序更像从真正的电脑端运行一样，但从issue中看出还是会有封禁风险，而此时我的账号正在3天的封禁期中……
真正的转机是我发现了一个wxauto库，这是python的一个开源第三方库，他基于GUI界面来抓取和推送微信消息，这意味这使用的是微信的官方客户端，只是通过OCR识别和模拟鼠标点击来构建接口，有了接口之后便可以利用他来做任何想干的事情，并且理论上来说这是不可能被封禁的，这无疑是一个巨大的突破，感谢python和OCR技术，感谢程序员和技术宅，我的想法终于有了落地的可能
V1.0
作为开发仅5个小时只有3个文件的第一代版本，他只包括了一些较为基础功能，有非常多可以完善的空间
V1.0.0
日期：2025年1月10日
描述：项目初版，接入GPT-4o模型，可以仅对特定人在特定群聊或对话窗口做出反馈，并添加了早晚安任务
功能：
- 发信人识别
- 历史消息记忆
- 对话本地记录
- 定时早晚安
反馈记录：
- 该版本首先运行在我自己的电脑上，由于需要使用GUI界面，会影响正常工作，且有息屏风险
- 由于电脑息屏，正常运行时间较短，早安信息没有按时发出
V1.0.1
日期：2025年1月11日
描述：部署到服务器上，小小修改了一些程序逻辑
功能：
- 稳定性提升
- 完善对话功能
- 完善记忆逻辑
反馈记录：
- 此次的版本可以较为稳定的托管运行，虽然也只坚持了一天的时间，于12日凌晨4点左右随着微信下线而中止，可能是因为检测到IP地址处于在服务器上（大概率）或是过于频繁的界面活动（小概率）
- 过于死板和频繁地在程序中强调人格和设定使得GPT表现不佳，下个版本将考虑修改提示词及提示逻辑
V1.0.2
日期：2025年1月12日
描述：添加历史记忆本地保存功能，异常中断后重载不再是梦想~，优化了初始化设定，更符合女朋友大人的预期
功能：
- 历史记忆本地保存
- 修改提示词
- 完善对话记录保存逻辑
- 完善提示词添加逻辑
反馈记录：
- 相比上版本对话显得不这么僵硬，获得了女朋友的好评，成就感UP↑
V1.1
日期：2025年1月14日
描述：完善History类，将记忆和对话日志分别保存到文件中，并且可以在程序中止后重载；探索了一些国产大模型的API，首先到达战场的是大名鼎鼎的Deepseek，但我在测试时发现了致命的问题——在你问他相同问题时，他的回复不会有任何变化：
User:你好
Assistant:你好！很高兴见到你，有什么我可以帮忙的吗？
User:你好
Assistant:你好！很高兴再次见到你。如果你有任何问题或需要帮助，随时告诉我哦！
User:你好
Assistant:你好！很高兴见到你，有什么我可以帮忙的吗？
User:你好
Assistant:你好！很高兴再次见到你。如果你有任何问题或需要帮助，随时告诉我哦！
……这对于对话来说有点致命，应该是官方所说命中缓存的原因，但是缓存应该也不可以这样命中吧
一刻也没有为刚充了10块钱就被pass的Deepseek而感到惋惜，紧接着赶向战场的是moonshot带来的kimi API，对于重复问题的回复，kimi显然好了太多
User:你好
Assistant:你好呀！很高兴为你服务，请问有什么可以帮你的呢？
User:你好
Assistant:你好呀，很高兴又见到你啦！有什么问题尽管来问吧。
User:你好
Assistant:嘿，你好呀！看来你很喜欢和我打招呼呢，有什么事儿想和我分享或者问我呀？
User:你好
Assistant:嘿，又见面啦！你这样热情地打招呼，我都快被你感染啦。有什么想和我说的，或者需要我帮忙解决的问题呢？
……而且kimi悄咪咪在我注册时送了我15块钱，所以只好先决定是他了。
不同模型的回答风格差距还是很大的，原先的提示词不再适用于kimi API，因此根据女朋友（姐姐大人）的反馈更新了提示词
功能：
添加多个国产模型接口
- 记忆保存与重载
- 重新整理代码结构
- 完善提示词与唤起方法
V1.1.1
日期：2025年1月18日
描述：我亲爱的女朋友最近提出了想要自定义闹铃的功能，目前暂时用特定提示词来触发，如日程：，闹钟：等等，触发后再调用API格式化日程信息，提示词为：
你是一个日程助手，你的任务是帮助用户管理日程，分辨出日程的个数和需求，并输出提醒词，提醒词的作用是在指定时间模拟用户说话，
将会输入给另一个AI assistant并输出具体提醒用户的话，需要体现出用户需求
内容以 JSON 的形式输出，输出的 JSON 需遵守以下的格式：'
{
"add_bool": <根据输入文本判断是否需要创建日程，布尔量>,
"time": <日程时间，格式为 YYYY-mm-dd HH:MM:SS，没有请填 null>,
"replay": <提醒词，没有请填 null>
}
示例输入：
一个小时之后可以提醒我去洗澡吗\n 当前时间：2025-01-18 13:00:00
示例输出：
{
"add_bool": true,
"time": "2025-01-18 14:00:00",
"replay": "之前让你提醒我去洗澡，现在时间到了，你应该怎么提醒我？"
}程序根据格式化信息设定日程，在指定时间再将提醒词输入给API，实现自定义闹铃/日程提醒的功能
理论上可以调用API对每句话都做一个分类，确定他是否包含日程信息，但这太过浪费了，可以训练一个简单的神经网络在本地进行分类业务，可以作为未来的一个方向（NLP启动！）
功能：
- 添加自定义日程功能
- 指定前缀+自然语言，可设定一次性日程提醒
25-1-28日记录：
由于deepseek最近的讨论度实在是太高了，我又重新想把deepseek接入进来，但我发现重复的问题还是不能解决，当用户输入的内容重复时，输出因为命中缓存将会出奇的一致，这是通过调整temperature参数无法改变的，我尝试了以下方法，但结果并没有改善：
- 在用户输入前添加当前时间戳，并在设定中强调时间戳是为了提醒时间流逝，在不同时间要做出不同回答
- 在用户输入前添加随机数，并在设定中强调随机数是为了防止出现重复回复
以上方法都没有起到作用，说明deepseek的缓存命中应当是一套相对独立的系统，并且在命中缓存后可能会直接插入之前的输出结果，并没有调用大模型本身，相似的问题我也在issue上看到了，我也去反馈了一下
除非出现一个合适的方法避免这个情况，暂时应该是不会使用deepseek的API