前言

这才是我真正意义上的第一个自己尝试自己玩所做的项目。之前的开发过程很杂碎，而且当时还没有自己的blog，于是就没有记录。今天开发了之前没做的、搁置了很久的内容。在这个过程中，我发现了一个事情——就像上司要和下属对接一样，在vibecoding的过程中，与ai对接也很重要。

本文将讲述我的部分开发心得，是随记所以也许没什么主旨。

正文

https://github.com/mattpocock/skills
如你所见，这是一个很厉害的项目，是一个大神把自己炼成skill的结果。我使用了其中的grill-me的内容，它可以让ai在了解我的需求之后 向我提出尖锐的问题，与我对接。
第一次使用的时候我真的感觉有点紧张，因为我真的感觉被一个严厉的前辈拷打了TwT

引用我们的对话。
*虽然这里对话的目的是完善另外一个项目（Chronos，我后续的文章会讲）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

我："我需要制作一个能记录项目投入时间的vsc插件 我称之为chronos。要达到的目标是完善其功能 让其可以显示待机时长、活跃时长、agent运行时长。"

codex："1. 定义先卡死：  
    你说的三个时长，精确定义是什么？  
    - `待机时长`：是“VS Code窗口打开但无键鼠输入”还是“系统级无输入”？  
    - `活跃时长`：是“有编辑行为”还是“窗口聚焦+有操作”？  
    - `agent运行时长`：是“发起到完成的墙钟时间”还是“真正执行中的时间（排队不算）”？

    2. 事件来源要落地：  
    你现在能稳定拿到哪些事件？分别来自哪里？  
    - VS Code API（window focus、文本编辑、命令执行）  
    - 终端事件  
    - 你自己扩展里对 agent 的调用链 hook  
    没有事件来源就不要谈统计精度。

    3. 状态机先设计，不然统计一定错：  
    请给出状态转移图（最少这几态）：`Idle / Active / AgentRunning`。  
    我要你回答：  
    - AgentRunning 是否覆盖 Active（互斥）？还是并行维度？  
    - 从 Active 到 Idle 的超时阈值多少秒？为什么？  
    - 锁屏、最小化、切工作区、睡眠唤醒怎么处理？

    4. 时间模型：  
    你打算用哪种计时策略？  
    - `tick累加`（每秒+1）还是`事件边界差值`（推荐）？  
    - 如何避免机器休眠后出现巨额脏时长？  
    - 时区和夏令时变化是否影响日汇总？

    5. 持久化与口径：  
    - 数据存哪里：`globalState`、本地文件、sqlite？  
    - 统计按“自然日”还是“会话”切分？  
    - 跨窗口/多工作区是否去重？  
    如果同时开两个窗口，你会不会把活跃时长重复记两份？

    6. UI目标别模糊：  
    你说“显示”，具体在哪显示？  
    - status bar（实时）  
    - webview/dashboard（明细）  
    - command palette（查询）  
    每个位置展示哪些字段、刷新频率多少？

    7. Agent运行时长的真问题：  
    你的 `agent` 指的是哪个体系？  
    - 仅 Chronos 内置调用  
    - 还是要覆盖外部插件/CLI agent  
    如果不是你自己发起的 agent，你凭什么拿到准确开始/结束信号？

    8. 验证方案必须可自动化：  
    给我最小可执行验证：  
    - 用假时钟/可控事件流回放  
    - 3个关键用例：持续活跃、长时间无操作、agent中途失败  
    - 断言输出精确到秒，允许误差范围是多少？

    9. 失败与回滚：  
    - 统计错了怎么修复历史数据？  
    - 插件升级后数据结构变更怎么迁移？  
    - 一旦采集逻辑异常，是否降级为“只显示不写入”？

    10. 现在给你硬约束：  
    请你先交一版“V1范围”回答，仅包含：  
    1) 单窗口  
    2) 本地统计  
    3) 三时长实时显示+当天累计  
    4) 不做跨设备同步  
    你按这个范围重写你的方案（不超过12行）。"

这一下解决了我之前所说“对自己的程序不熟悉”的问题。本来是我这个不懂程序的人“外行指导内行”，现在是ai反过来拷打我逼着我熟悉我的代码，这反而更让我有存在感了，写码更有动力了。还是蛮开心的。

在TradeEye的rss订阅开发过程中我也用到了这个办法。我通过这个方法与codex对接，不是单纯的一个指令“帮我实现什么功能”，而是按照一个格式：“已经做了什么-没有做什么-要改动什么-希望能达到什么目标”，这样我的返工就少了很多。
同时 我顺便解决了一个冗余：将dify的工作流直接集成进了项目。（我很喜欢奥卡姆剃刀的理论“如无必要勿增实体。”）当然，奥卡姆剃刀我在日后会展开谈谈——又给自己挖坑了。

结

很简短的一个心得。
是为结。
26/5/19深夜

序言

终于 在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清洗到复杂的工作流

当时第一版的工作流是这样的

现在的工作流是这样的

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

字典强匹配——守门员

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

关于交付

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

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

结

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

26/5/18凌晨