三张卡、三次点击：我把周末约场馆做成了飞书机器人

目录

周六早上九点，手机弹出一条消息，是我自己写的机器人。

它说：明天有雨，室内还有八家能约，选一个？

我点了一下。三张卡的预约在同一分钟里完成了。

放在一年前，这件事要花掉我十分钟，以及一点点耐心。

一、痛点不是”约不到”，是”要约三次”

家里的三张权益卡，对应三个人。平台的规则是：一张卡一份权益，一次预约只能用一个持卡人。

于是每去一个地方，流程都要完整地乘以三：

打开小程序 → 选卡 → 选场馆 → 选日期 → 选票种 → 确认 → 再回到第一步。

三次点击，三次确认，三次可能失败。

更麻烦的是”选”这件事本身：

• 有的场馆进店要券，但预约页面上根本选不到那个票种；
• 有的场馆周末库存是分时段放的，早上看还有，中午就没了；
• 有的场馆要求提前一天，有的当天可约，截止时间从 16:00 到 23:59 不等；
• 不可退的场馆，点错一次就是真金白银。

平台没有”批量”这个概念。它默认你一次只服务一个人。

而我要解决的不是”能不能约”，是”能不能只做一次决定”。

二、先让机器学会”算”，再让它学会”点”

UI 自动化这条路先被排除了：小程序的页面树是空的，控件拿不到；OCR 点按又太脆，库存和票种一变就全错。

真正稳定的是它背后的接口。一次抓包之后我发现，登录态是一个账号级的长期 token，不需要微信、不需要手机、不需要浏览器。于是有了一个只依赖标准库的脚本：

• 拉三张卡、各自的权益包余量；
• 拉场馆清单，算出哪些是”免福点”的（不额外花钱）；
• 对候选场馆逐个查真实库存和票种；
• 按”离杭州近 → 票面价高 → 可退”排序；
• 三张卡依次下单，任意一张失败就换下一个可用权益包重试。

关键不是”自动化点击”，而是”把规则写进代码”：提前几天、几点截止、当天已约几项、这张卡是不是已经约过同一家。这些判断人每次都会漏一个，机器不会。

顺手考古：IIS 7.5 与 ASP.NET MVC 4

第一次看响应头的时候我愣了一下：

• server: Microsoft-IIS/7.5
• x-aspnet-version: 4.0.30319、x-aspnetmvc-version: 4.0
• Set-Cookie: ASP.NET_SessionId=...
• 日期字段是 /Date(1777305600000)/ 这种 ASP.NET 老格式

一个 2026 年还在卖权益卡的小程序，后端是 IIS 7.5 + ASP.NET MVC 4——差不多是 Windows Server 2008 R2 那一代的东西。也难怪接口偶尔 TLS 抖一下，脚本里得给它写四次重试。

三、把”选择”搬到飞书

脚本能跑，但每次开终端不现实。于是我把它接进了飞书：一个自建应用 + 长连接，不用公网回调地址，机器人主动连出去。

每周六 09:00，定时任务做三件事：

1. 查周日杭州的天气；
2. 晴天按常规排序，雨天只推室内（滑雪、博物馆、影院、蹦床、恒温乐园）；
3. 把最多三个候选做成一张卡片，每个候选一个「约这家」，外加一个「这周不约」。

点「约这家」，机器人在后台给三张卡各下一单，然后把同一张卡片原地更新成结果：谁成功、谁失败、失败原因是什么。

常用操作也做成了斜杠命令：

/plan [日期]     出选择卡片
/orders          待使用的预约，每单一个取消按钮
/cancel <订单Id>  单条取消
/cancel all      取消所有未来的预约
/cards           三张卡各剩几次
/help            说明

到这里，”三次点击”变成了”一次选择”。

四、踩过的四个坑

1. 一个飞书应用只能有一个长连接消费者。

机器上之前还跑着一个旧机器人，用的是同一个应用。结果我发的消息被它收走了，新机器人只收到一个表情事件。把旧服务停掉、禁用、清理之后才恢复正常。

2. 选错权益包，”有次数”也会失败。

同一个场馆可能同时挂在两个包里。我一开始按”选 N 最大”挑了大的那个，服务端却按付费档处理，返回”剩余次数不足”。改成按包从小到大逐个试，第一个失败就换下一个，问题消失。

3. JSON 少包了一层，卡片会”假成功”。

脚本把结果放在 booking 字段里，机器人读的是顶层。字段读空之后，一张什么信息都没有的卡片被渲染成了”已预约”。修完之后，卡片上才有日期、金额和逐人结果。

4. 进程不响应 SIGTERM，重启会卡 90 秒。

长连接库对 context 取消不敏感，systemd 只能等超时再 KILL。加了一个兜底：收到退出信号两秒后强制退出，重启从 90 秒变成 2 秒。

五、边界

这套东西只做三件事：查、排序、下单。它不绕过平台的库存和规则，也不替人做”去哪”的决定。

几条自己定的约束：

• 默认只约可退的场馆；不可退的只列出来提示，绝不自动下单；
• 同一家、同一天、同一张卡已有单就跳过，不重复约；
• 每张卡每天最多 6 项，到上限就停；
• 下单失败不重试到死，换包失败就报错，交给人判断；
• token 只存在本机，权限 0600，不进日志、不进聊天记录。

六、最后

自动化真正省下的不是钱，是”周末早上那十分钟”：不用再打开小程序、不用再对三次库存、不用再担心点错一张不可退的票。

机器负责把重复的动作折叠起来，人负责决定这个周末去哪里。

如果连”去哪里”也交给机器，那就不是自动化，是放弃。

文章作者：阿文

文章链接： https://www.awen.me/post/b7d2e4a1.html

版权声明：本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 阿文的博客！