记录一次工作台的清点（2026-04-18）

机器用久了，会攒下一堆只有自己知道的事

这台 Windows 上用久了，最大的问题不是缺工具，而是没人知道这些东西是怎么串起来的——包括我自己。哪天换个环境，或者隔两个月回头看，很多当时踩出来的结论早就忘了。

所以这天我没有写新功能，只是把散在各处的东西清点了一遍，落成一份"机器说明书"。下面这些，都是那次清点的结果。

两台 MySQL，长得像，但不是一回事

这是最危险的一条。

早期我连的是家用代理那台：100.64.0.2:3306，库叫 gant，主要表是 ed3000_web_data 和 edant_ed3000_web_data。后来工厂的活起来了，连的是另外一台：10.103.50.147。

两台的字段风格、库名习惯完全不同，但它们都叫"MySQL"，都在 3306 上。混用的代价是拿错数据还能跑通，直到报表对不上才被发现。

所以这条被单独拎出来写死：两套环境的 MySQL 不要混。写脚本之前先确认连的是哪一台，比事后排查便宜得多。

爬虫的三道坎

yiso.fun 这个站我盯了挺久，那天把踩过的坑记了下来：

• **限流码是 444**，恢复时间是 30 秒，不是通常以为的 60 秒。连续搜 6 次以上，就得等 5 秒以上再打。
• hot_trend 那个接口**解密成功率只有 39%**，也就是说大部分请求是拿不到干净数据的，得接受这个现实，做好兜底而不是指望它稳定。
• 登录态 token 存在 D:\cookie_yiso.txt 里的 satoken 字段。

这几条没写下来的话，下次重写爬虫至少要再花半天重新试出来。反爬这东西，调参数的过程比参数本身更值钱。

对付 Cloudflare 的 JS Challenge，我用的是 DrissionPage——它比纯 requests 省事，因为它直接把浏览器跑起来，让 CF 自己去验证。

从热榜到成稿，一共三步

知乎那条自动化链路也一并记了下来，因为它的结构其实挺清晰，就是三步：

1. fetch-hot.py —— 从 60s.viki.moe/v2/zhihu 拉热榜
2. generate-cover.py —— 用即梦 AI 生成封面图
3. publish-py.py —— 基于 playwright 的 Python 库，带着 zhihu-auth.json 去发布

这三步是串行且互相依赖的，任何一步挂了整条链就断。所以真正要维护的不是脚本本身，而是每两步之间的数据约定——热榜出来的字段名、封面图的落盘路径、发布时读的鉴权文件。这些约定变了，链就断。

顺带把即梦 AI 的凭据位置也记了：火山引擎的 AK/SK 放在 skills/jimeng-ai/火山_AccessKey.txt，环境变量名是 VOLCENGINE_AK / VOLCENGINE_SK。这种东西不记，下次就是满硬盘找密钥。

那些看起来无关紧要的路径

还有一些纯粹是环境类的，但少了它们脚本就跑不起来：

• Node.js 装在 .workbuddy/binaries/node/versions/20.18.0/，需要手动加进 PATH，不会自动生效
• Playwright 装在 C:\npm-global\node_modules\playwright
• Chromium 版本是 v145

看起来是琐事，但这类"环境事实"有个特点：它们不属于任何项目，却影响所有项目。放在项目笔记里会被漏掉，放在机器笔记里才找得到。

我给界面定的四条规矩

最后一类不是环境，是审美标准——我给自己做工业类界面时定下的四条原则：

• 所见即所在：屏幕上看到的，就是系统里真实发生的位置和状态，不要有隐藏层级
• 预防错误：能挡住的误操作在点下去之前就挡住，而不是事后弹个报错
• 顺应肌肉记忆：常用操作的位置固定下来，别每页都换个地方
• 状态可见：系统在跑什么、有没有卡住，要一眼看得出来

这四条后来反复被用到——包括后面做各种看板、Dashboard 的时候。它们不像技术参数那样有唯一解，但一旦定下来，就有了判断依据，不至于每次都在那儿凭感觉调颜色调间距。

最后

这次清点没有产出任何新代码，但我认为它是后面所有工作的地基。

技术活做久了会有个错觉：以为记性够用。其实不是记性不够，是东西太多了——多到没有任何一颗脑子能在需要的时候准确调出"那台 MySQL 的库名到底叫什么"。

把结论从脑子里搬出来，落到纸上，虽然听起来一点也不酷，但它是少数的、做完之后真的会一直省事的事。2026 年 4 月 18 日，我做的就是这个。