正文

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

2026年5月8日深夜

前言

本文将追踪歌单分类项目开发的心路历程，展示我是如何将一个灵感具体落实成项目的。同时也会展示我在此过程中养成的习惯。

正文

原谅我再一次开了新坑。
本次项目的灵感是听歌的时候出现的。每当我在巨大的、将近三千首歌的歌单里面随机播放，却总是不如意，听不到想听的风格。我曾经试图去手动分类，听到哪首歌就将它放进某一小歌单中，但效率实在过低。在我接触了项目开发后，我重新审视这个问题：为什么我不写一个小脚本来分类呢？万一其他人需要呢？
我首先查了一下是否有人做过类似的项目。好吧在我撰写这篇blog的时候我貌似看到了一个类似的skill项目，但是在用户友好这一方面或许不如我？我这个项目只需要运行两个bat就好了（（看上去赛道很宽还没啥人。
然后我开始了我的设计。接下来我会以时间顺序叙述。

2026-06-02：标签墙交互定型

我最初的想法是：音乐平台既然有日推，就必定是根据用户的喜好来推荐的，那么就一定存在歌的标签，也就可以自己分类、设计自定义风格的歌单了。
于是我进一步了解了网易云音乐（因为我自己用的是网易云）的推送逻辑。网易云的逻辑是五个维度（语种等），然后还有细分多个类目。我觉得这个地方很不错，并且我吸收了“相似歌单”的办法，交叉验证。
在筛选方面，我第一时间想到的是标签墙，后来演变为类词云的办法（面向操作的可点击的筛选面板）。raw_tags 被单独拆成一块，因为原始标签噪声大，但它们往往最贴近用户想筛的语义。language、final_genre、final_subgenre、mood、scene、theme 被设计成独立维度。同一维度内多选使用 OR。不同维度之间使用 AND。初始状态不选任何标签，也不显示命中歌曲。命中歌曲默认全选，但结果表保留逐首取消。
后续我又加入了 raw_tags 的收紧规则：当 raw_tags 选到 3 个及以上时，不再让结果变成宽松 OR，而是要求歌曲至少命中多个已选原始标签。
但这个收紧仍然过于宽松，直到撰稿时我仍未解决这个难题。

2026-06-02：配置边界和 README 同步

这一天我继续把项目配置边界理顺。
上次的账单项目我吸取了教训，非敏感默认值迁移到 config.toml，只有敏感的cookie等内容我放在.env。Streamlit 自己的运行和界面默认值保留在 .streamlit/config.toml。

2026-06-03 到 2026-06-04：摸索

这段时间我主要研究了打包编译的可行性。考虑到后续的开发仍任重道远，打包为exe也许为时过早，所以我放弃了此想法。
同时这段时间网易云早期版本已经跑通，邀请了几个朋友测试，结果发现几个问题：npm指令在某些环境用不了，于是我加入了初始化bat作为救急。
一个重要约束：Windows 启动脚本要少做复杂嵌套命令，尽量把逻辑拆成清晰标签和普通参数。

2026-06-05：本地网易云 API 运行时稳定化

抓取歌单内歌的标签的时候，api经常断，但是又没有重新启动。
于是我收敛了启动路径：init_netease_api.bat 负责一次性准备本地 NeteaseCloudMusicApi 运行时。运行时安装到 .cache/netease_api_runtime。backend/run_netease_api.js 成为仓库自己的启动包装器。这个包装器加载第三方包里的 generateConfig.js 和 server.js，并关闭版本检查。
run_spectra.bat 负责日常启动，并能探测 18631 上是否已有健康 API。如果已有健康 API，就复用它，而不是再启动一个导致 EADDRINUSE。

2026-06-05：抓取断点持久化

我当时后台挂着抓取在打游戏，等我打完游戏回头一看：界面刷新了，我等了半天还得重新跑。我于是意识到了进度丢失的痛。
原始标签抓取以前主要依赖 st.session_state，页面刷新或进程重启后，队列、游标、部分抓取结果都可能丢失。
data/extract_checkpoint.json 保存队列、结果行、游标、总数、运行状态、暂停状态、完成状态、最后错误、当前歌单信息和 source signature；data/processed.json 继续作为最终归一化结果存储；恢复时要求 source signature 匹配，避免把旧歌单断点错套到新歌单。
这都使得大歌单抓取可以中断后恢复。

阶段性总结、延申

在项目的摸索中，我对写项目的理解进一步加深了。项目不是一朝一夕就完成的，而是在大框架打好后，一点一点和agent对接，反复磨合，不断迭代而产生的。
我越来越认为新时代程序员不是消失，而是会有更多广义程序员。作为驾驭agent的人，程序员无疑有更多相关知识，这一定是和代码朝夕相处的来的，是在计算机领域实践得到的，这是那些希望几句话就让ai做一个大项目的人无法企及的。一个项目肯定是不断在测试中进步的，在测试中，我们不断发现问题，不断查缺补漏，让项目趋近我们心中的样子。
日常生活也是如此。如果要掌握某项技能，就一定要耐下心思去练习，不要心浮气躁，沉得住气，不断发现自己的问题，不断迭代自己的本领，才能达到自我进步的目标。
无限进步。共勉。

26/06/09夜

前言

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