为了偷懒，我先替电脑干了不少活
做 EH 最早的动力，其实就是想偷懒。
浏览器里有太多重复操作：看页面、找内容、点控件、切页面。我想让电脑替我做这些事。最开始也没想那么远，只盯着一个站点，希望先把它跑通。
结果，光是决定“让模型看，还是让代码看”，我就走了不少弯路。
最早选的是模型。
我先给自己做了一整套 YOLO 标注工具，设计标注规则，再一条条手工标注。最上头的三天，一共只睡了 12 个小时，攒出了大约 2300 条基础训练语料。
现在回头看，投入很认真，经验确实没有。
那批语料基本来自固定的浏览器分辨率和缩放比例。训练结果看着不错，真正放到页面里，问题就来了：我手工标注时的偏差，也被模型认真学了进去。
大元素还能凑合，小元素的框经常偏得离谱。一个看起来不大的误差，落到按钮上，就可能决定这一下到底点中了什么。
接下来整整三个月，我都在跟这些框的抖动较劲。
加几何先验，试 GNN 纠偏，做形态学膨胀；重新标注，重新训练，再补不同缩放、不同浏览器分辨率下的数据。
每次都觉得离解决问题近了一点，换个页面状态，又有新的偏差。
本来是想让电脑替我干活，结果先给自己找了一份全职标注工作。
直到后来，我遇到了 DOM 。那段时间，Gemini 3 Pro 也刚发布不久。
对当时的我来说，DOM 像一位迟到的老师：浏览器已经知道一些事情，我却还在让模型从像素里重新猜一遍。
它进入系统后，最先改变的是标注。
原来要靠手一点点画齐的框，开始能由代码按照统一规则生成。手工标注的不一致少了，围绕标注修修补补的工作也轻了很多。
可训练出来的模型，依然会抖。
我继续加大模型、提高输入分辨率，页面里的偏差还是没彻底消失。问题逐渐变了：我到底还要在这条路上补多久，才能得到自己想要的稳定结果？
于是，原型开始转向。
我开始把自己对页面的判断拆开，一条条写成代码：哪些是内容，哪些是控件，什么情况下可以行动，什么情况下应该停下来。
原来存在于我脑子里的主观判断，逐渐变成了可以反复执行、可以检查的规则。
这个过程很慢，但第一次让我看到了另一种可能。我不必一直追着模型输出的框修偏差，也可以先把自己理解页面的过程讲清楚，再让代码去执行。
单站终于跑起来了。
它可以在页面里导航、点击控件、切换页面，完成我最早设想的那部分操作。我给它划定的使用边界也很明确：围绕用户可见页面，在用户授权和站点允许的范围内交互，不依靠轮换 IP 绕过限制，也不访问隐藏接口。
不过，那时离“通用”还很远。
一个站点，大约需要一份 200KB 的 JSON 配置。把这个站调顺，它就能工作；换一个站，又得继续适配和维护。
一个站可以靠耐心磨出来。第二个、第三个，再往后，维护量就开始提醒我：这条路不能一直这么走。
我需要重新想清楚，哪些东西真的可以跨站复用，哪些只是被我写进配置里的站点经验。
为此，我又花了大约一个月分析、整理和尝试。
第二个站通了，第三个站通了，第四个站也通了。
但站点改版、外部环境变化、Shadow DOM ，以及不同页面的组织方式，仍然会不断把新问题推到面前。以前熟悉的自动化做法，有时能帮忙，有时也会让我习惯性地再加一条规则。
大约两个月后，第一个能够跨站复用的引擎总算成形。到 2026 年除夕前后，我觉得自己终于交出了第一份答卷。
它仍然需要站点配置，但当时的我已经相当满意，甚至有点觉得“网页这件事差不多了”。
于是，我转头去研究另一个更大的坑：尝试用单目摄像头，在不依赖预建地图的情况下，做三维物理世界的具身认知。
直到四月，我重新拾起 EH ，开始做系统性测试，才发现早先的满意还需要更多证据。
这次，我挑了六个有代表性的站点：小红书、B 站、淘宝、Pinterest 、Reddit 和 TikTok ，开始检查换一批内容、换一个入口之后，它还能不能维持相近的表现。
那批早期测试一共跑了 21 次：B 站六次，其余五站各三次。变化包括关键词、板块、页面入口或随机种子。
我关注的一项指标是采集吞吐量，也就是每分钟新增多少去重内容。再用 CV ，也就是变异系数，观察同一站点几次运行之间的相对波动。
站点运行次数测试变化平均采集吞吐量CVPinterest3看板、首页信息流、随机种子78.90 条 Pin ／分钟1.42%B 站6露营穿搭、美食、键盘，各跑两次50.9 张内容卡／分钟2.70%TikTok3三个不同随机种子5.70 个视频／分钟3.10%小红书3火井、露营穿搭、美食40.0 张内容卡／分钟5.83%淘宝3猫粮、蓝牙耳机、笔记本电脑28.03 张商品卡／分钟7.85%Reddit3popular 、EarthPorn 、Art 三个板块15.63 条帖子／分钟8.34%CV 越小，表示几次运行的采集速度越接近。这六个站点的结果落在 1.42% 到 8.34% 之间。
这些数字让我看到，在当时的配置和测试条件下，换内容之后，采集速度没有大起大落。
不过，每站只有三到六次运行，这是小样本观察。CV 衡量的是吞吐波动，不能当成识别准确率或任务成功率。各站采集对象不同，表里的吞吐量也不宜直接横向排名。
我也没有忘记最早那个坑：只在固定分辨率下表现不错，一换窗口就露馅。
所以又拿 TikTok 的视频切换路径，做了五组窗口和缩放条件测试，覆盖普通笔记本窗口、较窄窗口、125% 浏览器缩放，以及 2K 、4K 显示条件。
下面的尺寸是网页实际可视区域，DPR 是设备像素比。
测试条件可视区域（ CSS 像素）DPR组内视频源记录切换成功耗时笔记本基准窗口1470 × 7462.030 ／ 3029 ／ 295.4 分钟浏览器缩放 125%1176 × 6082.530 ／ 3029 ／ 295.5 分钟较窄窗口1024 × 6732.030 ／ 3029 ／ 295.4 分钟4K 显示器原生模式3840 × 20431.030 ／ 3029 ／ 295.9 分钟2K 显示器原生模式2560 × 12331.030 ／ 3029 ／ 295.6 分钟合计五组条件三种 DPR150 ／ 150145 ／ 145—每组从首个视频开始记录，再切换 29 次。因此，五组合计记录了 150 个视频源，145 次切换全部成功，没有卡住。
对被模型框抖动折磨过三个月的人来说，这个结果很让人安心。
但测试也把边界摆了出来。
它主要验证了这条视频切换路径，并没有证明六个站点的所有操作都能适配所有分辨率。小红书在窄窗口下切换布局时，早期依赖固定区域的配置仍然会遇到问题。
这两组数据，都属于 2026 年 4 月、仍然使用站点配置的早期引擎实验。
它们让我对“通用”有了更具体的认识。
同一套框架能在几个站点运行，是一次进展。换内容、换窗口后仍然稳定，是下一步。至于减少站点配置、降低维护负担，还需要继续往前走。
最开始，我只是想少做一点重复劳动。
走到这里才发现，为了让电脑少依赖我，我先得把自己习以为常的判断，一点点讲清楚。
而下一阶段的折腾，便从那份 200KB 的站点配置开始
⚠️内容来自互联网，如有侵权请点击反馈！侵权投诉 |
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜
