正文

上了大学，感谢我的朋友们，教会了我很多。
我其实对金融不是很感兴趣，我喜欢ai，我想走ai方向。
但是我其实是文科生，政史地出身。
其实我上大学很迷茫，因为绩点也不高，别的貌似也没学会。
我希望通过blog的形式来记录我的进步，让我在未来的某一天回头能看到，我挥洒汗水的道路旁开满了鲜花。
blog的标题是“未寄出的信”，表示心里没有说完的话，也许它们就藏在我的字里行间。
未寄出的信，新的开始。在这些过去寄给未来的信件中，我握住当下的坐标，坚定向前。
是为序。

2026年5月8日深夜

前言

这才是我真正意义上的第一个自己尝试自己玩所做的项目。之前的开发过程很杂碎，而且当时还没有自己的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凌晨

背景

为了蹭同学大学活动的免费烤全羊写的。
但当时家里有事情要我赶回去，就没参加这个活动。

正文

在青蓝色的五点钟，我写下这段话。
抬头是直插云霄的飞机，往前是昏黄的灯光，身后是2025的回忆。我告别了陪伴我的人，来到了杭州，举起未曾举起的相机，摁下未曾摁下的快门。
三千快门，百二十日。我还有想做的事，想去的街，想见的人。
愿梦不止于梦，愿我能做我自己。
愿这青蓝色的夜色常伴我，与你我同在。

2025年12月29日

背景

和老同学聚会，散会后作。

正文

我驶离宴会的欢歌。
烟笼寒水。在疾驰而过的时代中，我侧身望去，光线投入我散光的眼睛，呈放射状。
那是记忆的种子。
我深吸一口后朋味的、草木灰烬所产生的幸福。
——或许这就是青春的味道。

2025年8月9日

正文

哦，你这
刹那的定格者
永恒的捕捉者
你
将自己封进
和你一样的
墨色。

刺得你睁不开眼的
阳光。你瞥见
迷茫的白鸽欢唱着橄榄
虔诚的信徒歌颂着上苍
你的笑是那快门的清脆
——因为是你
大家走在了一起。

可你，我的朋友
为什么
当玫瑰嫣红晕染开来
当海洋酒蓝缓缓褪去
当汹涌人潮逐渐远离
我却在这里发现你的身影
在另一片墨色之中
在角落的
垃圾桶。

《菲林》
2025.6.21凌晨

背景

看到冰岛黑沙滩，有感。
当时写在草稿本上，考完高考归档在便签的几首小诗。
26/05/08

正文

当赤红的潮涌褪去
当玄黑的淬铁崩塌
当海蓝的岩浆冻结
只留下暗灰的余炭

它
叹了口气
望向天空——那苍白的
绝望。
将自己掰碎
化作孤岛上的
黑沙滩。

2025年6月12日

正文

绿漾枝头
忧坠心口
可怜她
宁作柳絮随风漂流
不敢伸手挽他衣袖
​
​《柳》
2025.6.3

背景

其实是讽刺意味。
26/05/08

正文

黑夜
为她缀上
星辰
在
被黎明燃尽前。
可她
挥动翅膀
吐送欢歌
将羽毛挂上枝头，
于明亮的
白昼。

《鸽》
2025.6.2有感

背景

十八岁生日
26/05/08

正文

人生何处不青山。
到了我的十八岁。
爬九年的山，航九年的海，十八岁的花向着我绽放。
我曾迷茫，曾彷徨。我发现自己的呼声太小，没人听到；我发现自己被海浪席卷，在潮水中沉浮。
我曾受到伤害。伤痛让我怀疑自己，也一度落入低谷。
我曾封闭自己，害怕付出的真心没有回报。
我是个好面子的、自尊的、没头脑的、好妒忌的、孤僻的……
随你们怎么说。仍然有我爱的，仍然有爱我的。
我有三大追求:热烈地爱、痛快地恨，以及自由。
若为自由故，两者皆可抛。
很遗憾，现在的我什么也无法真正做到。但我正在努力。穆罕默德正在走向大山。
我的彷徨我的迷茫我的失落我的自私我的嫉妒我的忧郁，都是我自己。
我与我周旋久，宁做我。
人生何处不青山？
愿我的人生如旷野。
祝我十八岁生日快乐。

2025年4月24日