工作地点分类混乱，同一城市在两个入口的岗位数对不上

Job Market Monitor 会把各公司官网上的岗位地点整理出来，用户可以按地点筛选岗位，也可以在“城市分布”页看每个城市有多少岗位。官网上的地点写法五花八门，“深圳”“深圳市”“广东省深圳市南山区”“Shenzhen”都有，所以项目里一直有一套把地点清理成统一名称的代码。

某天我打开地点筛选，觉得这里的问题很大，让助手去仔细检查真实数据，把毛病都挑出来，再想想怎么重新设计。

同一个北京，两个数

助手先读代码，发现地点相关的规则其实有好几套：下拉框的筛选、城市统计、岗位详情里显示的地点标签，各自把原始文字重新解释了一遍。它们都是靠清理字符串加几份小名单来猜地点属于哪一类，彼此并不完全一致。

随后它拿生产环境里当前展示的 6.9 万多个岗位、2,952 条来源地点和 897 个地点选项逐项对照。最直接的证据是同一个城市在两个入口的结果不一样：

助手在生产接口上把这两个数都复现了。整体算下来，有 475 个岗位在“地点筛选”和“城市统计”里的归属不一致，其中 470 个完全没有进入任何城市统计。

一份问题清单

其余的问题大致可以分成几类。

• 层级混在一起。 省、市、县和“全国”这类范围没有统一的上下级关系。选“广东”不等于找广东各城市的岗位，“无锡市-宜兴市”被拆成了“无锡”和“宜兴”两个并列的地点。
• 分类错误。 “香港（中国香港）”被放进海外城市，关联 155 个岗位，国内的“香港”选项只能找到 1 个。China、beijing、guangdong 这类英文写法也出现在海外城市里。“新加坡共和国”和“旧金山”掉进了“其他地点”，维也纳、奥斯陆被当成了国家。
• 切割错误。 “广东省（如肇庆、东莞）”被拆成“(如肇庆”和“东莞)”两个选项，“全国多省区”变成了一个“区”，“热门城市/上海”拆出一个“热门城”。
• 同一个地点的多种名字没合并。 Los Angeles 和“洛杉矶”、São Paulo 和“圣保罗”是各自独立的两项。
• 名字变了，旧岗位跟不上。 某个公司的共享地点表已经把“湖北省”改成了“湖北”，而旧岗位版本里存的仍是“湖北省”。

一个典型的“深圳”

一家公司的岗位写着“深圳市-光明新区”，涉及 15 个岗位。系统把它切成了“深圳市-光明”，既不属于深圳，也没有进入城市统计，用户筛选深圳时，这些岗位就找不到。

先分清是官网的问题，还是我们的问题

助手没有把所有问题都算到分类规则头上，它把保存下来的原始响应和官网详情页逐个对照，发现有一部分错误来自采集解析：

• 某家电厂商的官网确实列出了几十个国家和地区，但我们的拆分规则按逗号切开，把“维尔京群岛，美属”拆成了“维尔京群岛”和“美属”两项。
• 某电脑厂商的岗位明确写着天津、北京、深圳，解析后却多出重复项和拼接出来的无意义地点，原因是页面里的地点字段被重复读入了。
• 某物流公司有一条地点在保存的原始响应里就是乱码，这不是我们的错，也不能猜它是哪座城市。
• “广东省（如肇庆、东莞）”是官网原文，意思是举例，不能擅自理解成只在这两座城市招聘。

所以重设计不能只整理下拉框，采集解析、地点归一和统计口径需要一起改。

官网怎么写就怎么存，另外记一个标准地点

我没看懂助手第一次给的方案，让它换个好理解的说法，并且回答三个问题：够不够优雅，能不能根治，以后出现新地点怎么办。它的解释是：

官网怎么写，我们照原样保存；系统另外给它确定一个标准地点。整个网站都按这个标准地点筛选和统计。

具体来说是这样的。系统内部有一份带层级的地点目录，每个地点有稳定的编号、标准名称和别名，并且知道自己的上级。

中国
└─ 广东省
   └─ 深圳市
      ├─ 南山区
      ├─ 宝安区
      └─ 光明区

“深圳”“深圳市”“Shenzhen”都指向同一个编号，“广东-深圳市-南山区”指向南山区，同时它也知道这个区属于深圳和广东。选深圳就能找到深圳各区的岗位，选广东就能找到广东各城市的岗位，而岗位详情里仍然展示官网的原话。

采集时按可靠程度依次识别：官网给了行政编码就按编码；给了国家、省份、城市等独立字段就直接用；只有一段文字时，再结合地点目录解析。实在无法确定的，保留原文，交给管理员确认，不创建假的城市，也不删除岗位。

有几条规则是我特别认可的：

• 官网只写“广东省”，就只知道它在广东，不会推测它在深圳，也不会把它算进广东的每座城市。
• “全国”“全球”“远程”不是城市，要单独处理。“泰国-远程”表示允许在泰国远程工作，不能当成全球远程。
• 城市统计统一按地级市比较，宜兴的岗位算进无锡，昆山算进苏州，详情里仍保留宜兴、昆山。同一个岗位在同一个城市只计一次。

以后出现新地点怎么办

这是我问得最多的一点，助手把几种情况分开来回答：

管理员确认过一次之后，已有的相关岗位和以后同类的写法都能复用这个结果。有歧义的别名只限定在对应的来源或地区内，不全局套用。

助手还明确列出了不打算做的几件事：每次采集都调用地图接口查地址、让大模型决定地点归属、为地点识别单独部署一个服务、收录全世界所有街道和建筑。当前规模下这些只会增加费用和维护负担，国家、省、市、区县这几级已经够用了。

它也不回避“根治”这两个字的边界。能根治的是结构性的错误，比如同一个城市在不同入口结果不同，新写法随便变成海外城市。不能根治的是官网本身的信息质量，乱码和含糊的地址仍会出现，只是变成可识别、可追踪、修一次全站生效的小范围例外。

上线

地点目录随代码离线提供，查询时不调用任何外部接口，日常用户请求也不解析文字，只读取已经建好的地点关联。上线的步骤大致如下：

1. 在隔离的恢复库里先重建一遍，确认不会改动原始岗位、历史观测和画像。
2. 生产上重建地点归属，耗时约 4 分半，新增索引数据约 21 MB，期间网站仍可访问。
3. 16 张历史和事实表逐行核对摘要，全部一致。
4. 补采受解析问题影响的两个渠道，重新生成受影响岗位的画像，其余岗位不用重抓。

补采之后有 111 个岗位的地点字段被补齐，旧版本也保留着。画像重新生成了 118 份，没有失败。

验证的几个数很有说服力：331 个城市的统计与岗位索引逐项一致；搜索“昆山”能找到苏州，苏州的统计和点进去的列表都是 403 个岗位；“宜兴”能找到无锡的 99 个岗位；江苏省范围 1,919 个岗位。

地点选择器也跟着重排

地点数据整理好以后，我又对选择器提了意见，主要有几条：

• “国内”下面竟然有“中国（全部）”和“北京”“安徽省”并列，同一级里应该是同类。想全选的话，用一个按钮就行。
• “国内”“国际”不应该和“工作范围”并列。
• “其他地点”里有很多明显能归到国内或国际的，还出现了好几个“吉林”。真正无法分类的统一叫“其他地点”，不要再往下设多级选项。

最后的做法是把选择器改成可以逐级展开的目录，默认收起，展开后再选省份和城市，搜索时直接列出匹配项和它的上级路径。国家、省份的整体选择变成目录旁边的“全选”按钮，不再混在下级地点里。“国内”和“国际”归入地理目录，“工作范围”单独放在一边。75 个原文选项合并成一个“其他地点”，以后无法识别的地点也会自动归进去。吉林省和吉林市同名的归属问题也一并修了。

中间还有一个小细节，按名称排序会把“整个国家”夹在城市中间，所以国家和省份的整体范围被固定在各自目录的顶部。

这次验证的边界

以上的核对针对的是当天生产里的地点数据。目录里没有的新行政区划、官网新增的写法，仍然需要管理员在后台确认一次。官网本身出错的数据，系统只会如实保留，而不会替它纠正。