我以为又是平台日常风控，没当回事。两分钟后 B 号也叫了，再过一会儿 C 号也挂了。
那一瞬间我脑子有点空白。
打开日志一看——这三个账号挨着撞到了滑块。后台跑的是同一份浏览器目录，cookie、缓存、指纹全共享。一个被风控盯上，剩下的就跟着连坐。
平台不傻这事我之前也想过，但没料到会这么快。
那天晚上我把 browser_data 拆成了一个账号一份：browser_data/user_<账号ID>。
磁盘占用变多，启动慢了几秒，启动脚本也得改。但起码不会一爆全爆。
后来又踩了一个新坑。
Chromium 异常退出会留下一个 SingletonLock。一开始我看到锁就清掉重启，省事。
后来发现这种「看到就清」太鲁莽——容器换 hostname 之后旧锁还在、宿主机重启也会留锁、调试时手动 kill 也会留锁。这些里面可能还住着活进程。
判断条件被我改紧了：只清「当前宿主机 + PID 已死」或者「Docker 容器 hostname 漂移」这两种确定的情况。其他时候宁可走兜底逻辑，也不去乱删。
总之这事过了之后我就清楚一件事——只要「账号」在你的项目里是个独立单位，就别让它们在底层资源上彼此牵连。
省那一点磁盘，省了迟早要还。
]]>不是之前那版有 bug，是我突然想明白——越想让它「全自动」，它坏得越频繁。
之前那一版：自动识别滑块 → 自动滑动 → 失败重试 → 换姿势再试。能跑，但每次跑我心都悬着。
闲鱼那边一直在升级检测。今天能过的姿势，明天可能就被识破。你改一次它改一次，最后变成跟自己玩猫鼠游戏。
新的版本里思路简单了不少。
默认就是最朴素那一套，老老实实。撞上滑块就保留这个账号的浏览器画像、复用持久 profile、等下次自动恢复。真搞不定就发通知，等人介入。
这听起来像后退——「全自动」三个字不要了。
但跑一周之后告警量直接掉了一半多。
我不再跟平台拼智斗。「不撞」放第一位，「撞了能恢复」放第二位，「全程无感」反而排到最后。
后来翻 commit log 才发现，过去几个月我反复改的几乎都是同一个文件——滑块识别那一段。改一次失败一次，再改再失败。直到这一次完全换了思路才停下来。
很多自动化看着厉害，倒就倒在「想做太多」。
适当放手让人介入，这套东西反而活得久。
]]>匹配关键词、调个 API、Cookie 抓一下，几个晚上能跑起来。
后来这事做了好几个月。
最早出问题的是会话——我天真地以为每条消息独立处理就行。跑两天就崩：同一个买家半小时前问过、十分钟前又问、刚刚还在问，机器人每次都热情回他一遍，把人整懵了。我赶紧加上下文。
接着是商品。买家说「这个还有吗」，他指的”这个”是哪个 SKU？我得从聊天页面结构里反推——他点进来的是哪张卡片、截图发的是哪个商品。这一段我改了不下十次。
后来是 AI 接入。直接挂了个模型上去，token 用得快、回复又泛。把 AI 摆到关键词后面，立刻就好了。
再后来是反爬。Cookie 会过期、登录态会掉、滑块会找上门、账号会被风控暂停。我现在每加一个功能都得在心里掂量一下——这个会不会让风控更频繁？
最后是多账号。一开始所有账号共享一个浏览器目录，撞过一次「全员连坐」之后，老老实实拆成 user_<账号ID> 各管各的。
每解决一个问题，下一个就在背后排好队等你。
所谓「自动」从来不是少写代码的意思。是你提前替自己挡住了那些原本要发生的事。
]]>XianyuAutoAsync.py，VS Code 卡了一下才把文件渲染出来。光标拉到底部，行号停在 16436。
写第一版的时候这个文件大概 3000 行。慢慢加功能、慢慢补 bug、慢慢长成现在这样。每次改东西都得先 grep 一遍，确认这一处不会牵连别的地方。
最近梳理优化方向，我把它列在 P0 里。
但拆这种文件不能拍脑袋。
我现在想清楚一件事——先拆结构，不改逻辑。
具体说就是按域切：连接的进 ws_connection、消息分发进 message_dispatch、订单的进 order_flow、自动回复的进 auto_reply。每一块的代码原样搬过去，连缩进都不动。
只搬，不优化。
理由很简单：拆完之后还能跑得起来，是接下来一切优化的前提。如果你边拆边改，出了 bug 都分不清是「拆错了」还是「改错了」。
reply_server.py 也一样，13000 行，路由和业务混在一起。我打算先按 auth / cookies / orders / notifications / system 这五块拆出去。
数据层那个 9000 多行的 db_manager.py 是最后才动的——它牵的最深，先把上层稳住再说。
写到这我也清楚——这种拆分要花很长时间，不会一两天搞完。
但要是不开始，就永远在「等以后有空」里推。
]]>之前的逻辑很粗：关键词匹配不上就直接走 AI。
跑了一阵发现不对劲。买家问「多少钱」，AI 回的是「亲，您好哦，价格在商品详情里有标哦」。
人家想看一个数字，不是这种话。
我把顺序改了——
指定商品的回复 → 商品维度关键词 → 通用关键词 → 默认回复 → AI。
AI 摆到了最后。
不是它不好用，是它太会说。什么都答得很顺，什么都没解决。买家想知道「发不发顺丰」「能不能少 5 块」「还有没有库存」，这些每一条都有标准答案，关键词就够。
后来导关键词的方式也变简单。把店里最常问的那十几条手填进去，再用 Excel 批量补一批。十分钟的事，盖掉八成对话。
剩下两成才让 AI 上场——「这个能配 XX 用吗」「适合送女朋友吗」之类的开放问题，关键词写不全的，让模型来兜。
跑了几周比之前舒服多了。token 用量也掉下来七成左右。
也不是说 AI 没用，是它该出场的时机不太一样——你问它的时候它在，你没问它的时候它别抢着说。
]]>cookie 快过期了，触发一次接口、拿新的 cookie、写回去——几行代码。
跑了一段时间发现完全不是。
第一个意外是滑块。刷新接口本身就会触发风控验证。你以为在调一个 API，平台那边可能弹给你一个滑块。我得在刷新链路里嵌入完整的滑块识别，识别失败还要支持人工兜底。
第二个意外是有头模式白屏。我让 Playwright 启了带界面的浏览器去刷新，结果在 Docker 里显示一片白。后来发现是 xvfb 的虚拟显示和 Chromium 的渲染时序对不上。这一段调了三天。
第三个意外是会话回写。滑块过了之后，平台会发一个新的 session cookie 给你。我的代码一开始没接住——刷新成功了，但 cookie 没存对，下一次接口又被拒了。这种”成功的失败”最难调。
第四个意外是人脸验证。某次刷新触发了人脸——我项目里根本没准备这种情况。临时加了一个人脸通知模板，让 app 把验证链接推到我手机，人介入一下。
第五个意外是并发刷新。同一个账号多个地方触发刷新，可能同时去抢同一把锁。我加了 in-flight 预占机制，让后来的等前面的，避免重复触发风控。
写到现在我才接受一件事——
刷新一个 token 不是”调一次接口”。
是一整条会话恢复链路：会失败、会被识别、会被改写、会撞上意外。
这件事我大概会一直接着改。
]]>简单说就是给商品刷一下时间戳，让它出现在搜索前列。手动擦一个商品要点三下，店里二十个商品就要点六十下。
很自然的需求是——一键全擦。
我第一版写得很直白：拿到商品列表，循环调接口，二十个并发发出去。看起来漂亮。
跑了两次以后这个账号开始被限频。
平台不傻——二十个商品同时擦亮 + 同一个 IP + 同一个 cookie，这看上去就是机器在干。后来我加了串行 + 间隔，问题还在：每天都在同一时刻擦，规律都摆得明明白白。
最后这套东西改成了这样——
可以选每天一个时段（比如 10 点到 12 点），系统在这个时段里随机分布执行；每个商品之间有随机延迟，几分钟到十几分钟不等；遇到当下高峰还会自动让一让。
整体看起来更像一个人在没事的时候点一点。
代价是擦亮一轮要花一两个小时，不是几秒。
写完这段我才意识到——批量做事的真正难点几乎从来不是”批量”两个字。是怎么让批量看上去不像批量。
很多自动化项目第一版做得快，是因为它们做的是”机器干活”。第二版做得慢，是因为它们开始做”机器装人”。
]]>你真正需要的是三件事：
这就是这个起步方案背后的想法。
Hexo 对博客很合适，因为它本来就是围绕静态博客场景设计的。对个人站来说，这通常意味着更少的维护、更高的性能，以及更低的复杂度。
同时它也保留了主题、标签、分类和归档这些成熟能力，所以网站长大以后依然能保持清楚。
把这些示例文章替换成你的内容，改好站点信息，接上 GitHub 和 Cloudflare Pages，就已经是一套真正能持续发布的博客流程了。
]]>数据库听起来专业，后台系统看起来完整，全栈框架也像是更面向未来。
但大多数个人博客，一开始其实都不需要这些。
真正有价值的是文章本身。如果内容容易版本管理、容易备份、容易迁移，那么整个平台就会一直保持灵活。
把文章以 Markdown 文件的形式放在仓库里，是一种很朴素但很可靠的做法。它可读、可迁移，也不依赖某个特定系统。
通常来说，真正值得先加的能力会是这些：
这样做的好处是，网站始终保持可理解，同时又不丢掉未来的扩展空间。
如果一个新功能没有在这个月里明显改善写作、阅读或者发布体验，那它大概率可以再等等。
]]>把代码打个包传服务器，登上去解压，重启服务，看一眼日志，搞定。一开始一周一次还行；等到改 bug 多了一天发两次，这套手动流程就变得很烦。
后来我接了 GitHub Actions 自动 release。
push 到 main 触发流水线、读 static/version.txt、生成 update_files.json、创建 release。听起来很顺。
写起来才发现真正难的不是构建，是清单。
哪些文件该进热更包？哪些不该进？我第一版定规则的时候很乐观——所有 .py、.html、.js 都进。
跑了第二天就出事了。
global_config.yml 一起更新过去，覆盖了用户的本地配置。data/ 目录里的运行时数据也带了进去。node_modules 装进了热更包。问题一大堆，全是我没想清楚”哪些文件是开发态的、哪些是运行态的”。
现在这份排除清单我审了不下十遍：用户配置、运行时目录、Docker 文件、CI 文件、文档、数据库、日志、缓存、备份目录——一律不进热更。
后来还支持了 deleted_files 列表清理旧文件。这个能力又踩了一个坑——清理之前必须先备份原文件，不然万一要回滚，发现东西已经被删了。
干这件事让我相信一句话——
自动化的难点几乎从来不是”自动什么”。是想清楚”绝对不能自动什么”。
]]>对小博客来说，这样的节奏就已经够用：
最后这一点很重要。很多原本不错的文章，之所以迟迟发不出去，是因为它们想一次说太多事。
好的工具应该减少阻力，而不是制造仪式感。
静态内容、本地预览、清楚的页面结构，会让你把注意力留在表达上，而不是耗在基础设施上。
标题、摘要、标签这些看似细小的东西，其实会决定一年后的归档是否还好翻、好找、好维护。
]]>OpenAI 的 SDK 装好，API key 填上，调用包起来——半天搞定。
那天晚上我自我感觉良好。
直到第二周某个晚上，那家 API 突然不通。可能是被墙了，也可能是限流，反正客户端傻乎乎地超时然后报错，自动回复全停了。我躺在床上看着报警，心想糟了。
那一晚我把 AI 调用层抽出来了。
不是说切供应商有多难——难的是当时项目里到处都写死了”OpenAI 风格的请求”。模型名写死、URL 写死、请求格式也按它的来。要换一家就得动十几个文件。
后来重构成现在这个样子：基础地址、模型名、API key、请求格式全从配置走，前端有个表单可以加任意一个兼容 OpenAI 协议的供应商。本地测过 DeepSeek、智谱、Kimi、阿里通义，哪个不通就切哪个。
带来的好副作用是：客户也能接自己买的 token。
我后来想，对接外部服务这事，”能跑”和”能换”之间隔了一座山。第一版只关心能跑是合理的——但你迟早要把”能换”补上。
因为外部服务一定会某一天挂掉。
不是它不靠谱，是它本来就不该被绑死。
]]>理由很简单——我觉得这是个”管理后台”，又不是用户产品，谁会盯着看那么久。
事实证明我盯着看的时间比谁都长。
凌晨两点调代码，白屏一打开整个人都精神了。不是干活的精神，是被刺到的精神。两天后我决定先把暗色加上。
加完之后才发现这事远比想象的麻烦。
第一个坑是刷新闪白。浏览器从加载到 JS 跑起来之间，会先用默认主题渲染一遍——光这一下就能晃你眼睛。后来我加了内联样式做兜底，刷新前先用 visibility:hidden 把页面藏起来，等主题确定再露出来。
第二个坑是跟随系统。Mac 的深色切换不是瞬间生效，他有过渡动画，过渡期间 prefers-color-scheme 媒体查询会有一两秒的不稳定。这段时间监听到的事件可能是错的。
第三个坑是闲鱼官网。你管理后台再黑，跑业务还得回闲鱼网页看消息——那一边只有亮色，两窗口跳来跳去眼睛非常累。后来我顺手用油猴写了一份闲鱼聊天页面的暗色样式，一并塞进了项目仓库。
写完一回头我才意识到——
暗色模式不是装饰功能。
它是只要你晚上还干活，就一定会自己用上的功能。
]]>不夸张地说，从 fork 别人的代码到本地接进第一个账号，花了不到两天。那天晚上看着控制台第一条买家消息打印出来，我以为最难的部分已经过去了。
第三天，第一个滑块就找上门。
前两天写代码很快，是因为闲鱼那一套 API 调通就够了。但滑块这种东西不是”调通”能解决的——它会变。我那一周改了八次重试策略：等待时间、滑动曲线、滑块识别、失败回退……每次都觉得这次稳了，然后跑两小时就被打回原形。
后来我发现，问题不在重试上。问题在我太想”一次成功”。
把心态改成”撞了能优雅退回”之后，整套东西反而稳了——失败就保存现场、推个通知、等下一次机会。
那一周让我学了三件事。
第一，写一个能跑起来的版本不难。让它一直跑下去才难。
第二，闲鱼那边的反爬不是技术问题，是策略问题。你跟它”赛跑”永远跑不赢。
第三，很多看起来聪明的代码，其实只是给自己加戏。最朴素的等待和兜底，往往比花活儿管用。
跑到现在三个多月，我没在第三件事上犯过新错——那一周给我的教训太深了。
]]>