刷 DEV 刷到一篇帖子，标题大意是"再也不会忘记参加 Stern Grove 的抽奖了"。Stern Grove 是旧金山那个露天音乐节，票靠抽。这期的选手不是个 repo，是篇实战记录。
她要干的事很简单：每周一上午十点开新一轮抽奖，忘一次当周就错过。于是写了个脚本，cron 卡在旧金山时间周一早上十点，Playwright 把表单一填，跑完发个通知。低频、轻量、够用就好。
值钱的不是脚本，是动手前那一步——agent 没有靠猜，先打开浏览器控制台，把页面上 window.tixologiWidget.concerts 的真实数据结构扒出来，确认事件 ID、名称、日期格式，然后才开始写代码。
写过抓取脚本的人都懂这步为什么不常见。模型对网页的理解是想象出来的。你给它一个 URL，它会脑补一个理想 DOM——干净的 class 名、整齐的嵌套、一个不存在于真实世界里的页面。看一眼运行时真实数据再动手，是能让脚本一遍跑过的小事，但很少有人把它当回事写出来。评论区有个叫 Nazar Boyko 的也正好说到这点，说这个做法应该应用到所有抓取项目里。看到不止我觉得这步值钱，放心了。
翻车还是翻了。第一次真实运行，GitHub Actions 的镜像从 22.04 换成 24.04，libasound2 成了 libasound2t64，Chromium 依赖缺一堆，她手动对齐装完才修好。写 CI 的人应该都认得这种——代码没问题，环境漂了。
只看最终代码，你只会看到"她装了个 t64 包就修好了"，看不到她怎么会想到去控制台扒那一眼。这层过程信息比最终 diff 值钱。她后来在评论里说，这套自动化已经帮她中了四场里有两场中了票。不是稳赢，但每周一的"记得去抽"从此不用占脑子。
脚本抄不抄，看你的手气。"先扒真实数据再动手"这步，抄走基本白赚。