英国工签系统把3万行代码逼疯：薪资阈值不是数字，是道数学题

2024年4月，英国内政部改了工签薪资规则。HR系统崩溃，ATS（申请人追踪系统）报错，合规工具集体失灵。不是因为政策变严，是因为程序员发现：这根本不是"大于等于3万英镑"能解决的。

一个做跨境招聘SaaS的朋友告诉我，他们团队花了两周重构验证逻辑。之前写死了一个数字，现在发现要同时查SOC代码（英国标准职业分类）、算时薪、判新人资格、区分医疗分支。他说这就像把计算器换成微积分——表面都是算数，底层完全两码事。

薪资阈值 = max(通用门槛, 职业基准价)

原文档给的核心公式看起来简单：取两个数里的较大值。但落地时每个变量都是坑。

通用门槛（general_threshold）2024年后是£38,700。职业基准价（SOC going rate）按6位SOC代码查表，不同职业差三倍。软件工程师可能是£45,000，市场专员可能是£26,200。

系统必须存整张SOC代码表，不能硬编码。 内政部每年4月更新，2024年一次性调整了上百个职业的基准价。朋友的公司去年没做版本控制，客户续签时发现规则变了，差点被告。

更麻烦的是"新人折扣"。满足条件的人，阈值降到职业基准价的70%，但保底£30,960。三个条件满足其一即可：26岁以下、首次申请工签、持学生签/毕业生签/青年流动计划签在英国。

这仨条件是"或"关系，不是"与"。产品经理画流程图时容易画成串联，开发写成if A and B and C，直接筛掉一半合格申请人。朋友团队review代码时发现这个bug，冷汗都下来了。

时薪校验：兼职陷阱

最隐蔽的规则藏在兼职场景。内政部不看你年薪除没除够52周，它要算时薪。

公式是： guaranteed_annual_pay ÷ (每周工时 × 52) ≥ SOC基准年薪 ÷ (37.5 × 52)

右边分母固定37.5小时，是英国全职标准。左边是你的实际工时。

一个每周干30小时、年薪£28,000的设计师，时薪£17.95。同SOC代码全职基准£35,000，折算时薪£17.95——刚好踩线。如果TA年薪£27,500，时薪£17.63，系统显示"年薪达标"，内政部直接拒签。

很多HR系统只校验年薪，因为 payroll 接口吐的就是年薪。要合规，得单独拆出"保证性年收入"字段，把奖金、股票、津贴全剔掉。

哪些算？基本工资、保证性津贴（伦敦权重、轮班津贴）。哪些不算？加班费、非保证性奖金、股票期权、报销。原文档列了清单，但不同客户的薪酬结构千奇百怪，有的把"保证性签约奖金"写进合同，有的口头承诺。系统没法自动判断，只能留人工复核入口。

医疗分支：另一套宇宙

Health and Care Worker签证走NHS Agenda for Change薪资带，不是SOC基准价表。逻辑要分叉：

if visa_route == 'health_and_care':
查NHS Band最低薪
else:
max(通用门槛, SOC基准价)

NHS薪资带每年4月更新，Band 5的点1点2点3价格不同。朋友团队给医疗客户做定制时，发现对方HR连自己的Band等级都搞不清——合同上写的和NHS系统里登记的不一致。最后只能两边数据都存，让用户自己选，系统做风险提示。

这个分支还影响SOC代码范围。Appendix Health and Care Visa列了允许的职业清单，不在清单上的医生护士也得走普通工签路线。系统要做白名单校验，不能光靠SOC代码前缀判断。

2026年变局：数据模型怎么留后路

原文档没写2026年具体数字，但留了技术伏笔。内政部明确阈值逻辑不变，变的是参数值。这意味着系统要设计成"规则引擎+配置表"，不能写死任何数字。

朋友现在的架构：SOC基准价、通用门槛、新人折扣比例、保底金额、NHS Band表，全进配置数据库，带生效日期字段。每次内政部发更新，运营后台改数，自动灰度到各环境。代码里只保留计算逻辑，不留任何魔法数字。

他还加了个骚操作：校验不通过时，系统不直接打叉，而是返回"差£X"或"时薪低£Y"。HR发给候选人时，对方知道往哪谈。这个细节让他们的客户续费率涨了15%——竞品只会弹"不符合要求"。

最后留个开放问题：你的系统里，还有多少"当年写死"的数字，正在等一个政策更新来引爆？