脚本可以看价格、算单价、提醒变化，最多创建未支付订单。真正付款这一步，仍由人工完成。
otokapi-deal-monitor
优惠监控脚本很容易越写越远。
一开始只是想知道有没有新套餐、有没有降价、哪个套餐更划算。写着写着，手就会自然伸向下一步：既然已经发现低价，能不能替我锁住机会？如果再往前，就是付款。
这一步必须停住，而且要停在代码路径上。
otokapi-deal-monitor 这个公开发布目录里，最值得记录的是它把付款动作挡在门外。脚本可以替人看见变化，可以做计算，可以提醒，最多把机会停在未支付状态；但到了付款这一步，不应交给脚本。
节省几分钟，不值得让脚本碰钱；省掉一次手动确认，也不能算收益。
先定义什么叫“划算”
价格监控不能只看价格本身。
一个套餐总价低，不代表单位价值低；一个套餐看上去贵，也可能只是周期更长、额度更多。长期盯优惠时，最容易被“便宜”两个字带偏。
所以更值得关注的是它能不能把价格、额度、有效期放到同一套口径里比较。它不需要一个很复杂的模型，只需要把总价和有效单价分开。前者决定钱包的瞬时压力，后者决定这次机会是否真的值得看一眼。
这个指标写出来以后，告警才有依据。否则脚本只是把页面刷新得更勤快，把主观冲动推送得更及时。
第一次运行只建基线
监控脚本最容易一启动就乱报。
如果本地没有历史状态，脚本第一次看到的所有东西，严格来说都可以算“新”。但这不是真变化，只是第一次看见。
第一轮应该只做基线：记录当前有哪些选项、价格处在什么位置、哪些指标可以作为后续比较的参照。等下一轮再判断：
- 新套餐出现。
- 已有套餐价格下降。
- 有效单价低于阈值。
这个设计很朴素，但很关键。没有基线，监控就会把“第一次看见”误报成“刚刚变化”；没有沉默的第一轮，后面所有提醒都会带一点噪声。
告警要去重，锁定也要去重
价格监控如果循环跑，去重比想象中重要。
同一个套餐、同一个价格，如果每轮都提醒一次，很快就没人看了。提醒一旦变成背景噪音，监控就失去了意义。
更麻烦的是锁定动作。提醒重复只是烦人，锁定重复就开始制造状态负担：多出来的未支付记录、难以解释的历史、以及后续人工判断时的混乱。
所以状态最好分开存：
- 这个价格提醒过没有。
- 这个价格锁定过没有。
- 价格变了以后，是否应该重新提醒。
- 锁定失败后，是否允许下一轮重试。
这些状态如果混在一起，脚本会走向几个坏结果：要么沉默，要么刷屏，要么重复制造待处理事项。自动化最怕的不是少做一步，而是把一件需要人判断的事做成一串难清理的副作用。
数据来源要分层，别迷信页面
这类脚本常见的难点是数据来源不稳定。
理想情况当然是读取结构化数据。它更容易测试，也更容易把“看见了什么”和“为什么告警”说清楚。页面自动化则更像兜底手段：它能帮人补上变化，但也把脚本带到了按钮、登录态和支付入口旁边。
所以这类脚本应该有分层意识：
- 优先使用稳定、可解释的数据来源。
- 数据来源变化时，只把浏览器当作观察和兜底工具。
- 页面层只能读取必要信息，不能把购买流程一起接管。
这样分层的原因，是脚本离下单按钮太近就有风险。脚本越接近页面操作，就越容易把“读取信息”滑成“模拟用户”。一旦到了这一步，安全门就必须更硬。
浏览器自动化必须更保守
一旦用了浏览器，风险会明显变大。
页面上有按钮，有登录态，有弹窗，也可能有支付入口。脚本如果只想着“怎样顺利完成流程”，很容易越界。写浏览器流程时，应该先列出禁止点击的控件，再写能点击什么。
付款类控件就属于这种必须排除的动作。
它看起来像一个小细节，其实是安全阀。浏览器自动化不是人，不能靠临场判断，也不能靠“应该不会走到那里”的侥幸。危险动作要在代码路径上被排除，而不是在事后解释里被原谅。
未支付订单不是付款
自动锁定机会和自动付款不是一回事。
这个脚本最需要说清楚的一点，是未支付订单的定位。它不是购买完成，也不该被文案包装成“已经帮你买好了”。它只是把机会短暂放到一个等待人工确认的位置。
更合适的理解是把它看成三层：
提醒：低风险，只告诉人未支付订单：中风险，可以锁机会，但不转钱付款：高风险，必须人工确认很多自动化事故不是因为脚本能力不够，而是因为这三层被混成了“自动化”。只要触碰付款，默认就应该停下来。未支付订单可以作为人工确认前的一步，不能变成自动付款的前奏。
专用浏览器 profile 更干净
如果脚本需要浏览器登录态，最好别用日常浏览器 profile。
专用 profile 的好处很直接：
- Cookie 和登录态影响更小。
- 截图、缓存和状态文件更容易清理。
- 出问题时不会污染日常浏览器。
- 迁移或删除时更清楚。
这也是个人自动化里常见的取舍。为了省一次登录，把脚本接到日常 profile 上，看起来方便，实际上把风险摊进了更多生活场景。专用 profile 麻烦一点，但影响面更小，长期更稳。
通知只是提示，不是授权
脚本可以通知到本地助手或消息工具，但通知不能等价于授权。
一条通知应该告诉人：
- 发现了什么变化。
- 指标是多少。
- 是否已经创建未支付订单。
- 是否需要人工处理。
它不该暗示“已经帮你完成购买”，更不该把未支付状态写成完成态。涉及钱的动作，文案要克制。状态越明确，越不容易让人误解；说明越清楚，越不容易在下一次迭代里被顺手抹掉。
最后保留的做法
这个脚本最终只需要提前发现那些可能被错过的变化。
指标计算、基线记录、告警去重、数据兜底、未支付锁定，这些都可以自动化。付款不该自动化。
更合理的分工是：脚本负责盯变化，人负责做决定。
它不会显得特别“智能”，也不追求把流程走到最后一步。但它更适合长期放在自己的机器上跑。宁愿它少做一步，也不让它在付款附近替人做决定。
继续读