死磕一个网页感知系统的来时路（二）

为了偷懒，我先替电脑干了不少活

做 EH 最早的动力，其实就是想偷懒。

浏览器里有太多重复操作：看页面、找内容、点控件、切页面。我想让电脑替我做这些事。最开始也没想那么远，只盯着一个站点，希望先把它跑通。

结果，光是决定“让模型看，还是让代码看”，我就走了不少弯路。

最早选的是模型。

我先给自己做了一整套 YOLO 标注工具，设计标注规则，再一条条手工标注。最上头的三天，一共只睡了 12 个小时，攒出了大约 2300 条基础训练语料。

现在回头看，投入很认真，经验确实没有。

那批语料基本来自固定的浏览器分辨率和缩放比例。训练结果看着不错，真正放到页面里，问题就来了：我手工标注时的偏差，也被模型认真学了进去。

大元素还能凑合，小元素的框经常偏得离谱。一个看起来不大的误差，落到按钮上，就可能决定这一下到底点中了什么。

接下来整整三个月，我都在跟这些框的抖动较劲。

加几何先验，试 GNN 纠偏，做形态学膨胀；重新标注，重新训练，再补不同缩放、不同浏览器分辨率下的数据。

每次都觉得离解决问题近了一点，换个页面状态，又有新的偏差。

本来是想让电脑替我干活，结果先给自己找了一份全职标注工作。

直到后来，我遇到了 DOM 。那段时间，Gemini 3 Pro 也刚发布不久。

对当时的我来说，DOM 像一位迟到的老师：浏览器已经知道一些事情，我却还在让模型从像素里重新猜一遍。

它进入系统后，最先改变的是标注。

原来要靠手一点点画齐的框，开始能由代码按照统一规则生成。手工标注的不一致少了，围绕标注修修补补的工作也轻了很多。

可训练出来的模型，依然会抖。

我继续加大模型、提高输入分辨率，页面里的偏差还是没彻底消失。问题逐渐变了：我到底还要在这条路上补多久，才能得到自己想要的稳定结果？

于是，原型开始转向。

我开始把自己对页面的判断拆开，一条条写成代码：哪些是内容，哪些是控件，什么情况下可以行动，什么情况下应该停下来。

原来存在于我脑子里的主观判断，逐渐变成了可以反复执行、可以检查的规则。

这个过程很慢，但第一次让我看到了另一种可能。我不必一直追着模型输出的框修偏差，也可以先把自己理解页面的过程讲清楚，再让代码去执行。

单站终于跑起来了。

它可以在页面里导航、点击控件、切换页面，完成我最早设想的那部分操作。我给它划定的使用边界也很明确：围绕用户可见页面，在用户授权和站点允许的范围内交互，不依靠轮换 IP 绕过限制，也不访问隐藏接口。

不过，那时离“通用”还很远。

一个站点，大约需要一份 200KB 的 JSON 配置。把这个站调顺，它就能工作；换一个站，又得继续适配和维护。

一个站可以靠耐心磨出来。第二个、第三个，再往后，维护量就开始提醒我：这条路不能一直这么走。

我需要重新想清楚，哪些东西真的可以跨站复用，哪些只是被我写进配置里的站点经验。

为此，我又花了大约一个月分析、整理和尝试。

第二个站通了，第三个站通了，第四个站也通了。

但站点改版、外部环境变化、Shadow DOM ，以及不同页面的组织方式，仍然会不断把新问题推到面前。以前熟悉的自动化做法，有时能帮忙，有时也会让我习惯性地再加一条规则。

大约两个月后，第一个能够跨站复用的引擎总算成形。到 2026 年除夕前后，我觉得自己终于交出了第一份答卷。

它仍然需要站点配置，但当时的我已经相当满意，甚至有点觉得“网页这件事差不多了”。

于是，我转头去研究另一个更大的坑：尝试用单目摄像头，在不依赖预建地图的情况下，做三维物理世界的具身认知。

直到四月，我重新拾起 EH ，开始做系统性测试，才发现早先的满意还需要更多证据。

这次，我挑了六个有代表性的站点：小红书、B 站、淘宝、Pinterest 、Reddit 和 TikTok ，开始检查换一批内容、换一个入口之后，它还能不能维持相近的表现。

那批早期测试一共跑了 21 次：B 站六次，其余五站各三次。变化包括关键词、板块、页面入口或随机种子。

我关注的一项指标是采集吞吐量，也就是每分钟新增多少去重内容。再用 CV ，也就是变异系数，观察同一站点几次运行之间的相对波动。

站点
运行次数
测试变化
平均采集吞吐量
CV

Pinterest
3
看板、首页信息流、随机种子
78.90 条 Pin ／分钟
1.42%

B 站
6
露营穿搭、美食、键盘，各跑两次
50.9 张内容卡／分钟
2.70%

TikTok
3
三个不同随机种子
5.70 个视频／分钟
3.10%

小红书
3
火井、露营穿搭、美食
40.0 张内容卡／分钟
5.83%

淘宝
3
猫粮、蓝牙耳机、笔记本电脑
28.03 张商品卡／分钟
7.85%

Reddit
3
popular 、EarthPorn 、Art 三个板块
15.63 条帖子／分钟
8.34%

CV 越小，表示几次运行的采集速度越接近。这六个站点的结果落在 1.42% 到 8.34% 之间。

这些数字让我看到，在当时的配置和测试条件下，换内容之后，采集速度没有大起大落。

不过，每站只有三到六次运行，这是小样本观察。CV 衡量的是吞吐波动，不能当成识别准确率或任务成功率。各站采集对象不同，表里的吞吐量也不宜直接横向排名。

我也没有忘记最早那个坑：只在固定分辨率下表现不错，一换窗口就露馅。

所以又拿 TikTok 的视频切换路径，做了五组窗口和缩放条件测试，覆盖普通笔记本窗口、较窄窗口、125% 浏览器缩放，以及 2K 、4K 显示条件。

下面的尺寸是网页实际可视区域，DPR 是设备像素比。

测试条件
可视区域（ CSS 像素）
DPR
组内视频源记录
切换成功
耗时

笔记本基准窗口
1470 746
2.0
30 ／ 30
29 ／ 29
5.4 分钟

浏览器缩放 125%
1176 608
2.5
30 ／ 30
29 ／ 29
5.5 分钟

较窄窗口
1024 673
2.0
30 ／ 30
29 ／ 29
5.4 分钟

4K 显示器原生模式
3840 2043
1.0
30 ／ 30
29 ／ 29
5.9 分钟

2K 显示器原生模式
2560 1233
1.0
30 ／ 30
29 ／ 29
5.6 分钟

合计
五组条件
三种 DPR
150 ／ 150
145 ／ 145
—

每组从首个视频开始记录，再切换 29 次。因此，五组合计记录了 150 个视频源，145 次切换全部成功，没有卡住。

对被模型框抖动折磨过三个月的人来说，这个结果很让人安心。

但测试也把边界摆了出来。

它主要验证了这条视频切换路径，并没有证明六个站点的所有操作都能适配所有分辨率。小红书在窄窗口下切换布局时，早期依赖固定区域的配置仍然会遇到问题。

这两组数据，都属于 2026 年 4 月、仍然使用站点配置的早期引擎实验。

它们让我对“通用”有了更具体的认识。

同一套框架能在几个站点运行，是一次进展。换内容、换窗口后仍然稳定，是下一步。至于减少站点配置、降低维护负担，还需要继续往前走。

最开始，我只是想少做一点重复劳动。

走到这里才发现，为了让电脑少依赖我，我先得把自己习以为常的判断，一点点讲清楚。

而下一阶段的折腾，便从那份 200KB 的站点配置开始。

主楼

发表回复