每周二，199 个国家和地区

签证信息错一条，最后可能就是有人拿着错的材料站在口岸。

所以我不把「挂上了来源」当作这条数据已经做完。这个签证信息库有 199 个国家和地区条目。199 说的是覆盖范围，不是 199 个政府网站，不是 199 个独立来源，也不是每周二由人从头重读 199 条。

每周二，系统会自动跑完已经配置的监测集合：页面还能不能访问，链接有没有变化，返回的是正文还是拦截页，处理过的正文指纹有没有改变，上次的异常是否恢复，又有哪些新问题需要人看。

机器负责把异常找出来。

政策含义，机器不能替我判断。

最初的 55 个配置

7 月 26 日，我第一次让这套监测对真实页面运行。首批一共有 55 个页面配置。这里的 55 不是「55 个官方来源」，更不是 55 个国家。多个条目可能共用同一页面，一个条目也可能需要不止一个页面；有的页面确实属于官方机构，却没有直接承载那条数据声称的事实。

第一次运行给我的不是结论，而是一张待判清单：哪些请求成功，哪些失败，哪些页面看起来变了，哪些需要换浏览器或换一种访问方式再确认。人工复核还要多问一层：这个页面即使能打开，究竟能不能证明它旁边那条签证信息？

有些不能。

这比普通死链更麻烦。死链至少明着告诉你它打不开；一个能打开、看起来也很正式、却没有那条政策依据的页面，会给人一种虚假的安心。

于是系统必须同时记两件事：页面活不活，以及它是不是合适的证据。

服务 199 条覆盖数据的系统，周度监测集合可以小于 199，也会随着问题变化而调整。机器每周跑完已配置集合；人只处理新增、变化、到期抽检、拦截、疑似死链和政策判断。这样做不是少检查，而是把人的时间留给只有人能做的部分。

000、403、429、200，谁也不能直接下结论

最初我以为状态码是简单的一层。实际页面很快把这件事教复杂了。

000 不是 HTTP 状态码。它表示这次请求没有拿到 HTTP 回应，可能是在超时、连接或其他网络环节就失败了。真实抽检里出现过自动请求显示 000，但人用浏览器可以正常打开并读到正文。

403 只说明这次请求被拒绝，不等于网站已经死了。有些官方页面会挡自动请求，却仍向正常浏览器提供内容。

429 通常是请求过多，也可能来自安全检查。它仍然描述的是这一次请求遇到了什么，不能单凭这个数字判定页面失效。

反过来，200 也不保证拿到的是政策正文。服务器可以很礼貌地回一个 OK，里面却只有挑战页的空壳。

状态码是一次请求的观察结果，不是页面的生死证明，更不是政策结论。

因此，这套流程不会把 000、403 或 429 自动翻译成「死链」。模糊结果要进入人工复核；返回 200 的页面也要确认正文是否有效。克制不是为了让系统显得谨慎，而是因为这些数字确实没有资格替人做下一步决定。

第一个完整周二，跑红了

7 月 26 日是首次真实监测。8 月 4 日，完整流程第一次按照周二定时计划自动运行。这是两个不同的节点：前一个证明监测能处理真实页面，后一个证明周度流程会按时运行，并把需要处理的事情交出来。

8 月 4 日那次运行是红的。

流程没有坏。所有执行步骤已经完成，最后因为发现了需要处理的项目，按设计报红。红色本身就是报警方式。

结果里有 9 个内容变化。它们不等于 9 次签证政策更新，只表示 9 个页面处理后的正文与原基线不同。在人读过之前，原因可能是政策文字改了，也可能只是横幅、计数器、页面外壳重做，或者正文换了位置。

机器发现了 9 个变化。

当时一个政策结论也没有。

后续人工判读确实找到了不少噪声：横幅、计数器、页面装饰和正常改版。根据这些结果，我调整了正文处理方式，也重设了相应基线。机器没有做错；它的任务就是发现不同。如果它直接把「不同」写成「政策更新」，那才是系统越界。

十天，两条来源，两种结局

最有用的一次报警，来自某个西非国家的使馆网站。7 月 28 日，多次复核都无法访问。我没有立刻换源，先把它当作可能的临时维护，留在观察期里。

同批另一个官方来源后来自己恢复了。这说明等待不是拖延：政府网站会短暂故障，如果每次请求失败都马上换掉，反而可能把一个权威来源换成更弱的页面。

但那座使馆的网站没有恢复。8 月 4 日的周度流程再次报出异常，后续复测仍然不可达。从首次确认算起，已经超过十天。

这时我换到另一个符合要求的官方来源。下一次复跑，这个事件不再留下待处理项。

机器发现的是「同一个异常持续了多久」。决定观察期结束、核对新来源并关闭事件，仍然要靠人。

这也是为什么监测不能只记红或绿。第一次失败可能是访问路径、临时维护或拦截；同一个异常跨过一个周度周期，分量就不一样。但即使持续十天，天数也不会自动替我挑出新的证据页面，更不会证明新页面恰好承载了需要的事实。

自动化停在「理解」之前

变化检测很容易列出一长串差异。维护政策信息不是把差异收集起来就算完成。

自动流程可以说：

• 没有拿到 HTTP 回应；
• 这次请求被拒绝；
• 返回内容像挑战页；
• 正文指纹变了；
• 同一个异常跨周仍然存在；
• 换源以后，旧报警消失了。

它不能自行断言：

• 签证规则已经改变；
• 某项豁免已经结束；
• 这个官方页面最适合证明当前条目；
• 一段文字消失代表政策撤销，而不是搬了位置；
• 外部页面上的地理或政治分类应该原样进入数据。

这些都需要读上下文、判断来源是否对题，有时还要耐心等几天。

所以我把流程边界画在「理解」之前。每周二，机器跑完已经配置的集合，把没有变化的页面从视线里移开，把真正新增的疑点送到我面前；我再逐项判断数据要不要改。自动化不是为了把人拿掉，而是为了不让人把时间花在毫无变化的页面上，同时保证影响旅行者的结论仍由人负责。

每周安排一次怀疑

199 个国家和地区，是信息库的覆盖定义。周度监测集合，是另一层会继续变化的页面配置。把两者混成「每周重查 199 个官网」，句子会更响亮，系统却被说错了。

我做周二流程，不是为了让数据库每周给自己盖一个「最新」章。它的作用是固定留出一次机会，提醒我不要自动相信昨天的状态。

有时机器会发现一个网站已经十天打不开；有时只发现页面多了一个计数器；有时自动请求拿到 403，人却能读正文；有时拿到 200，里面什么政策信息也没有。它的价值不在于永远知道发生了什么。

它知道该让我去看哪里。

每周二，系统先怀疑已经配置的证据。至于数据是否真的要改，要等人把政策读明白。