领英退出中国这事儿，我第一反应不是感慨，是赶紧打开我的爬虫脚本看了一眼——还好，去年就停了。这平台早就是鸡肋了，但它的沉没，意味着我们这批靠信息差和流量吃饭的人，手里又少了一张牌。2016年那会儿，我还能用Python的requests库加BeautifulSoup，配合几个代理IP池，一晚上扒拉下来几千个精准的销售线索邮箱，那感觉，跟捡钱一样。现在呢？墙越来越高，API越锁越死，连最后这块看起来“正规”的职场自留地也没了。
说到自动化，我最近在折腾的这套东西，其实就是被逼出来的。去年砍掉团队，回归一个人干，最大的恐惧就是时间被琐碎流程切成碎片。客户晚上十一点下单，我难道要爬起来登录后台、生成授权码、再发邮件？这太蠢了。我得让机器替我值夜班。
我的核心需求就三点：客户在独立站用支付宝付完款，系统要自动捕获这个订单；然后根据产品类型，调用对应的算法生成一个唯一的授权码（比如绑定MAC地址或者时间戳的）；最后，自动把这个授权码和教程发到客户邮箱。听着简单对吧？但每个环节都能卡死你。支付回调的稳定性、授权码算法的防碰撞、邮件服务商的发送频率限制，全是坑。
我最早试过用Python全栈自己撸，Flask写个简单后端，配个Celery做异步任务队列。但问题来了，支付回调URL稍微有点风吹草动——比如服务器重启，或者支付宝接口升级——整个链子就断了，查日志查到头晕。而且维护这一套东西的时间成本，比我手动处理还要高，完全本末倒置。
后来我发现了n8n，当时还是相当早期的版本。它的思路很吸引我：用节点拖拽的方式把不同的API和服务连起来，每个节点执行一个具体动作，失败了会明确卡在那里，可视化日志一眼就能看到是“支付网关超时”还是“邮件发送被拒”。这本质上是一个图形化的、可持久化的脚本管理器。
我的实现流大概长这样：第一个Webhook节点，接收来自我网站支付插件的JSON回调，里面包含订单号、金额、用户邮箱。然后一个Function节点，我在这里用JavaScript写核心的授权码生成逻辑，比如 `const license = md5(orderId + userEmail + Date.now())`，再拼接上前缀。接着，一个条件节点判断产品类型，是个人版还是企业版，分流到不同的后续处理。最后，两个并行的动作：一个调用腾讯企业邮的API（SMTP太容易进垃圾箱了）发送邮件；另一个把订单信息和生成的授权码写入到Airtable的表格里，作为我的后台数据库。
这个流程跑通那天晚上，我特意没睡，盯着n8n的流程执行历史。看到第一个真实订单进来，绿色节点一个一个亮过去，最后“邮件已发送”的状态变成绿色，Airtable里多了一条记录。那一刻没有兴奋，只有一种深深的疲惫感——我花了三天时间搭建这个自动哨兵，只是为了换回以后每个晚上不被吵醒的可能。所谓的“效率提升”，在初期都是巨大的时间债务。
领英这座岛沉了，意味着靠公开数据捞鱼的野蛮时代，正在加速落幕。以后的门槛，不再是你会不会写爬虫绕过反爬，而是你能不能把复杂的、非标的人肉流程，抽象成稳定运行的自动化脚本。流量入口在消失，但流程的“熵”永远在那里，谁能用更低的能耗管理好这些熵，谁才能活到下一个阶段。我的身体已经扛不住凌晨三点的闹钟了，那就让机器去扛吧。
