做这个小东西的起因很具体：在给自己查 2027 年 J-1 的资格，发现中文世界关于「打工度假 / 海外实习签证」的信息有一个系统性问题——
把只对中国台湾、中国香港护照开放的项目，写成「中国公民可申请」。加拿大 IEC 、英国 YMS 、爱尔兰 WHA 、日本 WH 、韩国 H-1 都属于双边互惠协议，中国大陆护照不在名单内。这类错误在攻略、中介软文、AI 生成内容里反复出现。
于是我把它当成一个数据工程问题来做，而不是又一个攻略站。
是什么
开源数据集 + 一个双语静态站。41 个项目、21 个国家和地区、136 条来源，其中中国大陆护照可申 34 个、不可申 7 个（不可申的也明确收录，作为排除记录）。
站： https://eddieye1004.github.io/overseas-program-dataset/
库： https://github.com/eddieye1004/overseas-program-dataset
怎么做的
1) schema 先行。每个项目一个 JSON ，字段定义在 data/schema.json ，护照资格是第一等公民（ passport_types 决定 90% 的结论）。
2) 来源分级 + CI 强制。每条来源标 primary/secondary ，并按域名分 A/B/C/D 四级：A 是移民局/使领馆/官方法规库，D 是百科、自媒体、商业博客。D 级出现即 CI 失败，全部来源都不到 A/B 级也失败。二手来源不能单独支撑硬性资格判定。
3) 保鲜靠台账而不是靠人记。每条记录带 last_verified 。scripts/track.py 按项目性质分档：窗口写死到具体日期的 90 天复核、其余 180 天，剩余不足 25% 提前标「即将到期」。
产物两份：tracking.json 给程序读，FRESHNESS.md 给人读。CI 每周一跑 --check ，超期即退出码 1 把构建打红；另有一个脚本把同一份台账同步成一张 issue （固定标题 + 固定标签，先搜后改，不刷屏），让「红了」这件事真的有人看到。
4) 配额四态化（刚做完的一轮）。原来是「整数或 null 」，而 null 同时兼指「无名额上限 / 官方设限额但未公布 / 还没查」三种，读的人分不出来——他根本不知道自己看到的那一格是「没有上限」还是「没查」。
现在改成一个必填的状态字段，四态：有具体配额 / 无配额 / 官方未公布数字 / 待核实。凡断言前三态都必须指向本项目已有的一条 primary 来源，指不出来就只能写「待核实」。当前分布 4 / 34 / 1 / 2 。
两条「待核实」我没有硬凑数字——一个是奥地利红白红卡高资质档，NAG 有联邦最高限额制度，但这一档是否在限额之内、当年数字多少，官网几个页面都查不到；一个是德国机会卡，法条只授权联邦政府可限量、本身不设数字，配套条例经查不存在。这两条就挂在待办清单里，不写成「无配额」。
现在的状态
validate 严格模式 0 错 0 警； 135 个 Python 测试； e2e 212 条断言；前端 tsc/smoke/build 全绿。
窗口日历也做成了硬分区：41 个项目里 3 个能给出官方已公布的日期、2 个只敢按往年规律推断、36 个无从判断——这 36 个里有 32 个本身就是滚动受理、没有固定窗口，其余可查的已逐个核查并在条目里写明卡点。推断与「无从判断」两块在页面上永不出现具体日期。
没有 star 数可以报，也没有用户量可以报——就是我自己在用的一个库。
想求什么反馈
1) 数据纠错入口刚上线（结构化 issue 表单，必填官方来源），最想要的是**挑错**：哪条资格写错了、哪条链接死了、哪个数字过期了。附上官方页面链接就行。
表单： https://github.com/eddieye1004/overseas-program-dataset/issues/new?template=data-correction.yml
2) 来源分级的标准是否合理——特别是「高校官方部门算 C 级、只能作旁证」这条，我拿不准是不是过于严格。
3) 如果你在做同类项目，想听你怎么解决「保鲜」这件事。
不做的事也写清楚：不代办、不做中介导流、不提供「你该申哪个」的建议。这是信息汇编，判断留给你自己。
把只对中国台湾、中国香港护照开放的项目，写成「中国公民可申请」。加拿大 IEC 、英国 YMS 、爱尔兰 WHA 、日本 WH 、韩国 H-1 都属于双边互惠协议，中国大陆护照不在名单内。这类错误在攻略、中介软文、AI 生成内容里反复出现。
于是我把它当成一个数据工程问题来做，而不是又一个攻略站。
是什么
开源数据集 + 一个双语静态站。41 个项目、21 个国家和地区、136 条来源，其中中国大陆护照可申 34 个、不可申 7 个（不可申的也明确收录，作为排除记录）。
站： https://eddieye1004.github.io/overseas-program-dataset/
库： https://github.com/eddieye1004/overseas-program-dataset
怎么做的
1) schema 先行。每个项目一个 JSON ，字段定义在 data/schema.json ，护照资格是第一等公民（ passport_types 决定 90% 的结论）。
2) 来源分级 + CI 强制。每条来源标 primary/secondary ，并按域名分 A/B/C/D 四级：A 是移民局/使领馆/官方法规库，D 是百科、自媒体、商业博客。D 级出现即 CI 失败，全部来源都不到 A/B 级也失败。二手来源不能单独支撑硬性资格判定。
3) 保鲜靠台账而不是靠人记。每条记录带 last_verified 。scripts/track.py 按项目性质分档：窗口写死到具体日期的 90 天复核、其余 180 天，剩余不足 25% 提前标「即将到期」。
产物两份：tracking.json 给程序读，FRESHNESS.md 给人读。CI 每周一跑 --check ，超期即退出码 1 把构建打红；另有一个脚本把同一份台账同步成一张 issue （固定标题 + 固定标签，先搜后改，不刷屏），让「红了」这件事真的有人看到。
4) 配额四态化（刚做完的一轮）。原来是「整数或 null 」，而 null 同时兼指「无名额上限 / 官方设限额但未公布 / 还没查」三种，读的人分不出来——他根本不知道自己看到的那一格是「没有上限」还是「没查」。
现在改成一个必填的状态字段，四态：有具体配额 / 无配额 / 官方未公布数字 / 待核实。凡断言前三态都必须指向本项目已有的一条 primary 来源，指不出来就只能写「待核实」。当前分布 4 / 34 / 1 / 2 。
两条「待核实」我没有硬凑数字——一个是奥地利红白红卡高资质档，NAG 有联邦最高限额制度，但这一档是否在限额之内、当年数字多少，官网几个页面都查不到；一个是德国机会卡，法条只授权联邦政府可限量、本身不设数字，配套条例经查不存在。这两条就挂在待办清单里，不写成「无配额」。
现在的状态
validate 严格模式 0 错 0 警； 135 个 Python 测试； e2e 212 条断言；前端 tsc/smoke/build 全绿。
窗口日历也做成了硬分区：41 个项目里 3 个能给出官方已公布的日期、2 个只敢按往年规律推断、36 个无从判断——这 36 个里有 32 个本身就是滚动受理、没有固定窗口，其余可查的已逐个核查并在条目里写明卡点。推断与「无从判断」两块在页面上永不出现具体日期。
没有 star 数可以报，也没有用户量可以报——就是我自己在用的一个库。
想求什么反馈
1) 数据纠错入口刚上线（结构化 issue 表单，必填官方来源），最想要的是**挑错**：哪条资格写错了、哪条链接死了、哪个数字过期了。附上官方页面链接就行。
表单： https://github.com/eddieye1004/overseas-program-dataset/issues/new?template=data-correction.yml
2) 来源分级的标准是否合理——特别是「高校官方部门算 C 级、只能作旁证」这条，我拿不准是不是过于严格。
3) 如果你在做同类项目，想听你怎么解决「保鲜」这件事。
不做的事也写清楚：不代办、不做中介导流、不提供「你该申哪个」的建议。这是信息汇编，判断留给你自己。
Select Language