ZongziLegder开发杂谈01丨我如何开始一个项目

序言

终于 在26/5/17日,虽然过程很艰难,但是我首次“交付”了我的石山项目。告一段落,于是重新编辑了我的blog,记录我的心路历程。

背景

折乙大人交给我一个任务:爬取微信信息,然后提取账单的信息并记账。

初步尝试 试错碰壁

当时群友提供了一个方案:UI Automation获取微信的主窗口句柄,然后遍历窗口树,定位到消息列表控件,最后提取文本内容。
但是我在此处碰壁了。尝试引入wxauto的插件,但是效果并不理想,这让我十分恼火。
但是我反思了一下以往的碰壁经历,在某个犄角旮旯卡住完全出不来的时候需要考虑一下换赛道。
于是我在群里寻求帮助。就在这时,转机出现了。

转变思路——win32 api

这个时候codeboy提供了新的思路:win32 api。
gemeni给我三种方案:后台消息拦截、剪贴板劫持、内存扫描。
第一种方案似乎走不通(具体怎么搞的我有点忘了 当时还没做blog),剪贴板劫持也因为微信不能ctrl+a全选消息而失败。
此时只剩下最后一条路:内存扫描。
说干就干,我尝试了对内存进行扫描的方法,获取了我存在内存里面的聊天记录。
刚开始它把我的所有消息都抓出来了,给我看傻了。我于是转而对格式进行限制,比如开头用“#记账”,希望能只抓到这些东西。

区分账单

但是一波未平一波又起。我要怎么解决可能存在的多条账单相同的情况呢?
我想到哈希值验证。因为不同时间发的账单哈希值是不一样的,所以也许能以这种办法解决。
事实证明我想错了,内存抓取的是碎片一样的信息,所以只能抓到写入的时间,这意味着相同的信息写入必然会被判定成同一条信息。
这可把我难住了。因为面向的是中年用户,所以我希望能尽可能的简化操作。我试着对每一条信息进行打标签,效果仍不佳。
最后只能苦一苦用户了TT我直接加入了记账规范(即开头是“#记账+yymmdd+序号”),这样就不会有问题了。

当然 在后面我修复了这个问题,直接改道为抓数据库,迎刃而解。这个我们后面说。

新的要求

折宝的新要求来了。他希望达到的效果是能完全自动化,能记录店铺名字、具体规格,同时又要能识别图片。
于是我说慢慢来,先把文字解决了。

对账单进行格式化

由于账单往往是很杂乱的,所以我想到了引入llm模型进行格式化。
但是这里又有两条路:一个是llm只处理文字格式,输出成json文件;另一个是把计算也交给llm。
考虑这是一个记账的项目,涉及钱的,llm模型又存在幻觉的情况,所以也许只让它处理文字的排版是没有替代脚本的情况下最好的方法————如果以后有办法,就把这一段替代成脚本
我于是开始着手。先把工作流搭建好,然后把原来的本地抓取改为在中间插入一个工作流。
即:
爬取消息————llm格式化————保留json格式————计算————输出
但是项目卡在此处出了问题。工作流跑不起来。
看了好久才发现,原来是工作流输出的格式不一样TT
最后改了五百遍工作流,终于把程序跑起来了TT
现在都是5/10的凌晨三点了,哭。
先睡觉。

转变思路

从内存爬取到数据库引入

我越来越觉得内存的爬取是一个失败的方案。内存里面抓取到的东西太碎片了,会对我后续的维护造成很大影响。
那么有没有更好的办法呢?有的,直接爬数据库。
我找到了wetrace——一个能解密微信本地数据库的东西。如此一来,就有了稳定的信息源,并且能针对性地绑定某某对话,这无疑是对uia优点的继承,同时也少了折腾。

从简单的llm清洗到复杂的工作流

当时第一版的工作流是这样的
第一版工作流
现在的工作流是这样的
26/5/17的工作流
完全不一样。
我原先以为就是爬取信息 然后llm简单清洗一下 最后进本地就好了,但是事实证明我我完全错了。这其实是一个严谨的环节——因为和钱有关系。
目前的流程是 消息在初步筛选后进入一个迭代的块,在里面llm会进行筛选、组装,最后将格式化的账单放行,并且在本地进账。
中间我曾考虑在dify里面直接丢掉没用的账单 但是这似乎会导致账单消息完全发不到本地。于是后面我转换思路,工作流只负责清洗,然后把所有账单消息放进本地,进行匹配进账。这是这个项目的我认为的核心思路,会在下文单开一个小节说明

字典强匹配——守门员

我让账单项目传回本地,然后匹配店名、品名和规格名,通过强匹配的办法进账,同时也确保了没进账的消息进入review sheet,方便核验。我感觉这是我在这个石山项目里面做的最聪明的想法——只要维护好这几个字典,那么就确保了账单的准确性。

关于交付

折乙大人指导了我很多,在这里再次感谢折乙大人。
在此处写下我印象很深的几个学到的点:

  • vibe coding不能完全代替思考 始终要对自己的项目保持了解
  • 不隐私的配置可以放进config里面,不要一股脑的丢尽.env里,配置太多会让用户头大
  • readme要写清楚。
  • 要有产品的思维,站着用户的角度思考,思考“用户用着怎么舒服”而不是“我程序编写怎么轻松”
  • 记得及时清理项目里面无用的碎片。

这篇文章记录了笨人的第一次项目经历。虽然是蠕动着制作的,而且做的东西也就是“勉强可以运行”,但是是一次宝贵的经历,吸取了很多经验教训。
希望能通过这篇文章,讲述我自己的初开发经历,抛砖引玉,给希望能启动自己项目的朋友们一些启发。
是为结。

26/5/18凌晨