从零把 AI 工作台跑成生产系统：我踩过的 8 个真实的坑 #WorkBuddy#

实操心得。上篇《无人值守的日常》讲了怎么用 WorkBuddy 自动任务搭"数字员工"，这篇只讲踩坑——每一个都是真实发生、花了时间排查的，附解法。

坑 1：浏览器配置目录的"幽灵锁"

无头浏览器跑自动化时，如果上次进程被强杀，配置目录会残留 SingletonLock 锁文件，指向一个早已不存在的进程——之后每次启动都直接失败，报错还看不懂。解法：启动前检测锁文件内容里的进程是否存活，不存活就删。这个自愈函数让我们的失败率直接归零。

坑 2："永远成功"的心跳是最大的谎言

早期所有任务的结束心跳都写死"成功"——直到某天登录态失效，系统连续多天"正常"。教训：心跳必须按执行结果分支生成（成功/失败/需人工三种标签），汇报层按标签做不同处理。看似多写十行代码，实际是整个系统可信度的地基。

坑 3：镜像构建在下载大文件时必断

10 月 28 日下午，我在 CI 里构建含浏览器内核的自定义镜像，官方源下载 120MB 的 Chromium 在两分钟处连挂三次。排查下来不是网络问题，是官方下载源对高频请求限速。换国内镜像源、把大下载拆成独立分层缓存住之后，构建成功率从"看运气"变成了稳定通过。

坑 4：改了代码忘了同步元数据

脚本有完整性校验（按清单比对哈希），某次改完脚本忘了更新清单，云端自举直接拒绝执行——校验机制把我的失误拦下来了。这反而是这次最欣慰的坑：防呆设计真正防住了开发者本人。

坑 5：定时时段要按恢复逻辑设计

有个说法流传很广："保活放在正式任务前几分钟，防止临门失效"。我一开始也这么排，后来实测发现登录态是滚动续期的——正式任务自己访问页面就会续期，前面加保活纯属心理安慰。保活真正的价值是失败补位，所以时段应该按"每场任务失败后最近的补位窗口"来倒推。那天我把两个时段挪了位置，第二天早上就验证了补位确实生效。

坑 6：免费额度的计量单位不是"次数"

云构建按"核数×时长"计费。8 核跑 1 分钟比 1 核跑 8 分钟贵 8 倍，而网络瓶颈型任务根本用不满 CPU。把节点降到 1 核 + 环境做成缓存镜像后，单次成本降为原来的 1/30。

坑 7：界面弹窗是自动化的隐形杀手

新产品上线功能公告、引导弹窗，都会挡住自动化脚本的点击。解法：每次关键点击前先处理可见弹窗（按按钮文本定位），并把"面板没出现就重试"写成循环——界面的偶发状态比想象中多。

坑 8：双账号共用的基础设施要"路径隔离"

两个账号的状态、心跳、明细文件如果同名存储，一次误写就互相污染。所有文件路径按账号硬编码隔离，再做一轮代码级 grep 自查"有没有引用对方的路径"。

结语

写完发现这 8 个坑没一个算得上"高级难题"，全是工程细节——但 10 月这两周我的排查时间，基本都花在它们身上。生产系统和 Demo 的差距就在这里。如果你也在做类似的事，欢迎评论区交流，少走一个是一个。