记录一次五个项目的盘点（2026-06-04）

手上的东西一多，就需要有人替你说清"你现在在忙什么"

那天做了一次盘点。原因不复杂：项目加到了五个，彼此的目录、端口、数据库、口径都不一样，脑子里那本账开始记不牢了。

五个项目

① 工厂仪表盘（Flask）

跑在内网，看板在 10.103.54.6:8765，数据来自 10.103.50.147 上的 MySQL，另外还接了一路视频流（10.103.65.30:8080）。核心表是 work_load_0521，10 秒采样一次。

② 工时报表系统（Streamlit）

这个更贴近"发工资"这件事。一共 16 张表：表 1 到表 15 是工时子表，字段统一 18 列（班组、姓名、员工编号、各类工时、薪酬发放工时的口径都在里面）；表 16 是人员打卡记录汇总，读的是 MySQL 的 peo_working_time。

本地库是 localhost:3306，root 无密码只读。

③ yiso.fun 爬虫 —— 用 DrissionPage 写的那套。

④ 知乎热点自动化 —— 前面刚被平台拦了一次的那条链。

⑤ Hexo 博客 —— 就是这个站，图床走 demohapi.4everbucket.com。

盘点项目，最容易漏的其实不是"有哪些项目"，而是那些只有业务侧才知道的数字。那天我单独把两条拎出来了：

一是 FIXED_WORKTIME：SCBX 算 2 人 × 8 小时，其余工位算 1 人 × 8 小时。

这条看着像个小配置，但它决定了所有"人时"口径。因为 SCBX 是上层布线，工序性质决定了它实际就是两个人在干。如果按"一个工位一个人"去算，那个工位的产出会凭空高出一倍。这种口径没有任何技术手段能自动推出来，只能问、只能记。

二是工时报表的两条校验规则：

这两条的本质是交叉验证：报上来的工时，和机器记的打卡，两本账要对得上。对不上的人不一定要罚，但必须被看见——这才是标红的意义。

盘点过程中还顺手处理了一件更底层的事：记忆的归属。

当时的环境里其实有两套记忆：一套是 WorkBuddy 自己的（C:\Users\Administrator\.workbuddy\memory\<uid>_memory.md），一套是 OpenViking。它们各管各的，格式也不一样。

WorkBuddy 那边是带版本号的，当前写到了 v36，结构是：

文件旁边留了 .bak 备份。中间还有个历史遗留——一个叫 memery/ 的目录，是早期拼错了 memory 留下的，一直没删。

那天定下一条规矩：不要直接去覆盖 WorkBuddy 的 memory。 只读、归纳，然后落到 OpenViking 里当长期参考。

理由是这样：WorkBuddy 的 memory 是它自己的状态账本，被外部改掉之后，它自己的上下文就乱了。 记忆这东西跟数据库不一样——不是"写进去更全"就一定更好。谁的地盘谁做主，各写各的，需要的时候再对一遍，反而更稳。

顺带也搞清楚了 WorkBuddy 是怎么接外部能力的：走一个 connector-proxy（http://127.0.0.1:57663/mcp），对外聚合像腾讯文档这类服务。

那次盘点的产出，说白了就是一份档案。但它的价值在后面几个月一直显现。

因为项目的复杂度从来不在单个项目里，而在它们之间——同一个 MySQL 上跑着工厂和工时两套数据，同一个爬虫框架被复用在两个站上，同一套配色被用在了三块界面上。这些交叉关系，只有摊开看的时候才看得见。

那天还有个更软的收获：把"你偏好什么"也写下来了——中文交流、简洁但有深度、喜欢结构化的表格、深色工业风配莫兰迪加品牌红 #D50030、喜欢先给框架再补细节、习惯用截图来反馈迭代。

这些看起来跟技术无关，但它们其实是最省时间的一类记录。技术问题每次都能重新查，而一个人的偏好如果每次都要重新猜，那才是真的浪费。