Hacker News 上每个月都有同一个固定节目Who Is Hiring。公司会在官方帖子下用评论形式发布招聘信息求职者则从几百上千条评论里手工筛选机会。HN Hiring 这个项目正是瞄准这个场景来的——它把 Who Is Hiring 帖子里无结构的评论加工成可以搜索和过滤的职位信息让你不用再在浏览器里一页页翻。这个工具看起来只是一个小功能但背后其实指向一个更普遍的问题当信息源足够大、足够乱时技术人的第一反应不该是忍受而是做一个工具把它整理干净。我对这类服务于开发者的“非官方周边工具”一直比较关注。它们通常不复杂技术栈也不会很新但往往能精准戳中一个真实痛点而且会暴露一类典型的工程问题数据从哪来、怎么解析、怎么保持更新、怎么处理失败。HN Hiring 恰好就是这样一个适合拆开看的项目。1. 为什么 Who Is Hiring 帖子让人又爱又恨1.1 月度招聘帖一个低技术含量的高价值信息源Hacker News 的 Who Is Hiring 帖子特殊在哪它不是招聘网站不是猎头服务只是一个按月发布的讨论帖。每个月的固定时间雇主以评论形式回复内容就是一段纯文本通常是这样一种结构公司名 | 职位 | 地点 | 远程 | 技术栈 | 联系方式有些评论写得完整有些只写一个公司名加链接还有的会直接在评论里复制一大段 JD。格式极度不统一但它有两个很明显的优点信息发布成本低公司愿意在这里发一手招聘信息。读者以技术人为主很多岗位就是冲着 Hacker News 社区氛围去的。换句话说这个帖子的信息价值很高。大量真实岗位会先出现在这里甚至比很多招聘平台更早。但它又不像招聘网站那样有结构化字段没有搜索框没有筛选器没有分页管理所有内容堆在一起。这形成了一个很有意思的错位数据质量不低数据体验很低。HN Hiring 这个项目解决的就是体验问题而不是数据质量问题。1.2 信息过载和结构缺失是最大的使用障碍我见过不少求职者打开 Who Is Hiring 帖子后的状态先划二十分钟然后开始怀疑是不是自己搜索方式不对。其实问题不在搜索方式而在信息结构。一个帖子下的评论可能超过一千条。每条评论代表一个职位但评论本身没有 schema没有标签系统没有固定模板。你想找远程、Python、欧洲时区的岗位只能靠眼睛扫然后在心里做排除。这个过程有几个消耗点每条评论都要完整读完才能判断是否相关。评论里的关键词可能和你搜的词不完全一致。重复公司可能出现多次你很难在脑内做合并去重。评论排序可能受发布时间和 HN 算法影响不等于职位质量排序。这些消耗叠加起来会让“找工作”变成“找信息”。HN Hiring 做的是把信息从大量噪声里剥离出来。1.3 开发者对这种问题的天然反应做一个工具技术人员遇到信息过载通常会有一种很自然的冲动写个脚本抓下来过滤一下。HN Hiring 不算什么惊天动地的创意它更像这种冲动的一个具体产物。从项目标题可以看到两个核心动作Search在招聘评论里找关键词。Filter按条件过滤结果。搜索解决“找不到”过滤解决“看不完”。两个动作合起来就把“翻帖子”变成了“查数据”。不是新问题也不是新解法但它提供了一个清晰的参照原来 Hacker News 这种非结构化信息也能用工程手段变成可用的职位信息流。2. HN Hiring 到底在解决什么问题2.1 从“翻评论”到“查数据库”如果只从表面看HN Hiring 就是一个搜索框加几个筛选条件。但如果我们把它的使用体验抽象一下会发现它本质上做了一个转换使用方式数据形态用户行为效率瓶颈直接翻 Who Is Hiring 帖子无结构评论流逐条阅读、脑内过滤注意力、记忆力使用 HN Hiring 这类工具半结构化职位数据搜索、筛选、排序搜索词表达能力、数据覆盖度理想中的智能招聘平台完整结构化数据条件组合、推荐匹配数据质量、更新频率HN Hiring 没有造出完美的结构化数据它只是把无结构评论变成了“可查询的半结构化数据”。这个步骤看起来简单实际价值很大因为“可查询”意味着你可以用关键词快速排除大量不相关信息。过去你想在 Who Is Hiring 里找 “remote” 相关岗位唯一的办法是 CtrlF但 CtrlF 只能帮你找到关键词不能帮你理解岗位。而搜索工具可以在关键词之外加入地点、技术栈、是否远程等条件结果更接近真实需求。2.2 搜索和过滤两个动作的本质搜索和过滤听起来是一回事但很多工具把它们混在一起。从工程角度两者有明确分工搜索解决语义匹配问题。用户输入一个词系统在文本里找相关记录。过滤解决结构化约束问题。用户规定一个条件比如只显示远程岗位系统用字段做精确匹配。一个成熟的职位搜索工具应该同时支持两种动作。先搜索出相关岗位再过滤掉不符合硬性条件的最后才能进入人工判断。HN Hiring 如果只做关键词搜索效果会差很多。Who Is Hiring 评论里常见的写法是Remote或ON-SITE或Hybrid这些词在工作内容里可能也会出现。只有把“是否远程”当成一个独立字段来处理过滤才有意义。这里也能看出一个设计取舍解析评论时是优先保证召回率还是优先保证精确率如果解析得太激进会把无关内容当作职位字段如果解析得太保守又会漏掉很多有效职位。大多数工具的初始版本都会倾向保守因为漏掉信息比错误信息更好修复。2.3 这类工具不是真正的 HR 系统但它比官方渠道更快我看过一些人讨论 HN Hiring 类工具时会吐槽它不够专业没有公司背景调查没有薪资范围没有内推渠道。这个吐槽没问题但放错了比较基准。HN Hiring 的对手不是 LinkedIn不是招聘平台也不是猎头服务而是 Hacker News 原生的 HTML 页面。它为用户提供的价值不是完整求职方案而是从原始信息源到求职者之间的一条快捷路径。你用它搜出十个看起来合适的职位然后自己再去公司官网、技术博客、GitHub 页面做进一步调研。它做得好的地方是帮你节省了“从一千条评论里找出十个目标职位”的时间。后面的判断本来就不该交给工具完成。3. 想复刻一个 HN Hiring你需要处理哪些技术细节如果你不是只想用这个工具而是想自己写一个类似的或者想给其他非结构化数据源做搜索那么下面这些技术细节会直接决定项目能不能落地。3.1 数据来源HN API 的基础结构和评论抓取Hacker News 对外提供了一套公开 API社区里也有第三方平台的搜索接口。常见做法是先找到某一期 Who Is Hiring 帖子的 item id然后递归获取该 id 下的所有子评论。这里有一个关键点HN 的评论是树形结构。顶级评论通常是一条招聘信息但有些公司会在自己的评论下回复补充信息比如邮箱、联系方式、JD 链接。如果你只抓顶级评论会丢掉后续补充内容如果全部递归抓取又需要处理大量缩进和嵌套。从工程经验看第一次做这种抓取时最容易踩的坑是没有处理分页或超时中途中断后没有断点续抓。重复抓取同一批评论没有做增量更新。把顶级评论和子评论混在一起导致解析异常。一个比较稳妥的做法是把原始评论数据先完整落库保留父子关系和作者信息再做二次解析。不要在抓取过程中同时做关键词过滤否则一旦发现过滤逻辑写错就要重新抓数据。示例结构可以是这样# 示例结构获取某条 HN 帖子下的评论 # 这里的重点是理解数据的嵌套结构而不是具体实现 def fetch_item(item_id): # 调用 HN API返回 item 数据 pass def walk_comments(root_id): # 递归获取子评论返回评论列表 pass comments walk_comments(35200000) for comment in comments: store_to_database(comment)3.2 解析非结构化评论的难点与取舍Who Is Hiring 的位置信息、远程政策和技能标签全靠评论作者自己写。这意味着没有统一格式。你可能会遇到用|分隔字段。用-或·分隔字段。公司名和职位写在同一行。远程信息写在最后面。啥模板都没有就一段散文。解析器的核心任务是从这些文本里抽出几个对用户最有价值的字段公司名、职位、地点、远程状态、技能标签、联系方式。不同字段的解析难度不一样字段解析难度常见陷阱公司名低容易把个人项目名当公司名职位中职位名称千奇百怪缩写多地点中有的是城市有的是国家有的是 Anywhere远程状态低容易漏掉 Remote OK误判 No Remote技能标签高不同人写技术栈的方式差异很大联系方式低邮箱格式容易识别但容易被故意混淆针对这种情况不要试图做一个万能解析器。更好的策略是先做规则解析把高置信度的字段抽出来剩下解析不了的评论直接保留原始文本让用户靠搜索关键词去匹配。解析逻辑宁可保守也不要激进的另一个原因是一旦你自动生成了错误字段用户会基于错误字段做决策。比如某条评论没有明确说可以远程但解析器把它标成了 Remote求职者投递后才发现不是这种体验比搜索不到更糟糕。3.3 索引、搜索和过滤的最小实现思路当数据已经存进数据库搜索和过滤就有很多种实现路径。最小实现可以不用搜索引擎。直接对评论正文做关键词匹配然后用数据库字段做过滤。对于一个月度帖子数据量不大这种方式完全可行。但当评论积累到多个月份或者用户想要更快的响应时就要考虑引入倒排索引。一个相对通用的做法是先用分词器把评论正文切成 token。去掉英文停用词。建立 token 到评论 id 的映射。搜索时先查 token再合并结果列表。如果不想引入复杂组件直接用数据库的LIKE查询也能跑但要注意大小写、时态、单复数问题。比如用户搜 remote评论写的是 Remotely匹配就会失败。这时候可以通过把文本统一转为小写再对关键词做词形还原或模糊匹配来缓解。过滤则相对简单主要依赖解析出来的字段。比如remote true location 欧洲 job_type Full-time这些条件组合起来就能形成一个比较实用的筛选器。搜索和过滤的关系可以理解为搜索决定候选集过滤决定最终集。3.4 从单次抓取到持续更新工程化要补什么如果你的目标只是自己用一次脚本跑完生成一个 HTML 文件就够了。但如果你想把这个工具给更多人用或者想长期维护工程化是绕不开的。我这里列一个从单次脚本到可维护服务的关键清单定时更新HN 每个月都有新帖子需要定时抓取新数据而不是手动跑脚本。增量存储对已经处理过的评论做去重避免重复入库。失败重试API 请求偶发失败需要有重试机制和日志。状态监控抓取任务是否失败、解析率是否下降、新增了多少数据这些都需要可以观测。用户输入校验搜索词和过滤条件要有默认值和上限防止恶意输入拖垮服务。数据源变更HN API 如果调整结构解析器也要跟着升级需要预留配置化空间。这些听起来很“工程”但对一个真正想长期运行的 HN Hiring 项目来说每一条都会在实际使用中遇到。我可以给一个判断标准项目做到什么程度算“完成了”单次抓取能出结果是脚本阶段。能自动更新是服务阶段。能更新、监控、处理异常才算是可维护产品。如果你只是学习做到第一步就够了。但如果你是想解决自己的求职问题至少要做到第二步因为 Who Is Hiring 的价值是按月持续出现的失去更新的工具很快会变成一堆过期数据。4. 使用这类招聘搜索工具的正确姿势4.1 先想清楚关键词再开始搜索很多人一打开搜索工具就直接输入 “remote”然后发现结果太多。这不是工具没用而是你还没有把需求翻译成查询条件。我建议你先在纸上列一轮问题我能接受远程吗是只要全远程还是也接受混合办公我可以在哪些国家或时区工作我熟悉的技术栈是什么必须精确匹配还是愿意学新栈我倾向什么规模的公司创业公司、中大型公司还是都可以我想找哪种职位类型全职、合同、兼职这些问题对应到搜索上就是关键词和过滤条件的组合。比如关键词: python, remote 过滤: 地点 欧洲, 全职先做一轮粗筛把结果数量控制在一百条以内再开始人工逐条阅读。不要一上来就追求精确到个位数因为非结构化数据必然有噪声留一点余地反而更容易找到没预料到的好机会。4.2 过滤条件组合比单关键词更有效单关键词搜索的问题在于它无法区分一个词的不同语境。比如搜索 python会同时匹配到“用 Python 做后端”“招 Python 工程师”“需要会 Python 的 DevOps”等不同描述。更好的方式是组合过滤条件用多个维度锁定目标。我看到比较有用的组合包括地点 远程技术栈 职位类型公司规模描述 工作方向联系人邮箱域名 公司官网链接如果你使用的工具不支持那么多过滤条件退一步的方式是在搜索结果里继续做二次关键词排除。比如先搜 remote再排除 “not remote”“no remote”“on-site” 等词。从使用者的角度看搜索工具只是帮你缩小范围最后的判断一定落在人身上。所以不要舍不得花时间读原文评论。原始评论里往往藏着过滤条件无法表达的信息比如团队氛围、项目阶段、面试流程偏好这些对决策同样重要。4.3 判断职位质量的几条线索当搜索结果聚焦以后下一个问题是如何从一堆条目里挑出真正值得投的职位HN Hiring 的岗位信息有限但还是有一些常见线索可以参考公司官网是否清晰如果公司连官网都像临时页面不确定性会高一些。帖子里是否写清楚职位职责和技能要求条目越具体通常说明团队对岗位越上心。是否提供联系邮箱或申请链接愿意给出明确入口的公司转化路径更短。技术栈是否符合你的成长方向不要只看当前匹配度也想想一年后你希望自己做了什么。公司创始人的 HN 历史这不是必查项但能帮你快速判断团队背景。这些线索不能保证职位质量但可以帮你减少踩坑概率。搜索工具能做的是把候选列表缩短它不会——也不应该——替你过滤掉所有风险。4.4 工具边界它不能替你判断公司与团队无论 HN Hiring 这类工具做得好不好它都有一个清晰边界它只能处理文本数据无法判断真实的公司状况。职位信息只是求职链条的第一环。后续你还要去看团队的技术博客、公司的融资情况、面试官在技术社区的声誉、产品的用户评价。这些信息比一条招聘评论复杂得多也更难被自动化。所以使用这类工具时要保持一个心态它是你的信息入口不是你的决策代理。你可以依赖它快速找到感兴趣的公司但不要依赖它告诉你“这家公司值得去”。5. 从“找工作工具”看技术人的信息处理习惯5.1 为什么很多工具都是一次性解决个人痛点HN Hiring 这类项目有一个典型特征它们最初往往是为了解决某个人的具体问题而存在的。作者在翻 Who Is Hiring 帖子时觉得低效于是花了几个晚上写了一个工具然后把它公开出来。这种“一次性解决个人痛点”的出发点决定了工具的很多特性功能不会很全只覆盖核心需求。界面不会很花哨能用就行。代码通常不是最佳实践但可运行。后续维护动力取决于作者是否还在求职或者是否愿意继续投入。我们不应该用商业产品标准去要求这类工具。它的价值恰恰在于用最低成本验证一个需求是否值得被解决。当有人回应“我也需要这个”时说明问题不是个例。5.2 技术人做工具容易忽略用户体验和维护成本如果一个工具只是给自己用确实可以不用考虑用户体验。但当你把它发布到 HN希望其他人也来用时情况就变了。我看到很多开发者自建工具最容易被吐槽的点不是功能缺失而是不知道怎么操作没有任何说明。搜索结果的加载状态不明确以为没反应。大量数据缺失却没有标注数据更新时间。报错信息直接暴露普通用户看不懂。没有处理空结果状态用户不知道是没数据还是没匹配。这些都是小事但恰恰决定了工具能不能被更多人接受。一个数据抓取再准确的工具如果使用门槛太高传播度也会受影响。从维护角度还有另一层成本。公开工具会吸引真实用户一旦有真实用户你就需要处理反馈、修复 bug、更新数据、应对突发流量。对一个本来只是想练练手的人来说这反而是最容易被低估的负担。5.3 适合长期使用和适合学习练手的不同判断你可以把 HN Hiring 当作一个独立产品来用也可以把它当作一个学习项目来研究。两者的侧重点完全不同目标重点建议路径解决求职问题数据准确、更新及时、结果可用优先用现成工具必要时自己写简单脚本学习数据抓取API 调用、评论解析、数据存储从单次抓取开始逐步加入增量更新学习搜索功能索引、分词、过滤逻辑先用 SQL 实现再尝试引入搜索引擎学习产品设计交互、空状态、用户反馈把最小功能上线观察真实用户使用行为我见过有人只是因为想学 API 调用就写了一个类似的招聘搜索脚本最后在求职时派上了用场。也有人完全不想折腾直接用别人做好的工具把时间省下来投简历。两种选择都没有问题关键是想清楚自己的目标。如果这是你第一次接触 Hacker News API我建议给自己设定一个很小范围只抓一个月的 Who Is Hiring 帖子解析出远程岗位打印成列表。这个目标足够小两三个小时就能跑通但能让你完整经历一次信息抓取、解析、过滤的过程。最后想说的话HN Hiring 的价值不在于它有多复杂的技术也不在于它能不能替代招聘平台。它真正让我感兴趣的是一个很朴素的行动逻辑当你发现一个信息源里藏着好东西但拿起来很费劲时不要只抱怨先想一个办法把它变得更顺手。技术人做工具最容易陷入一个误区总想做一个大而全的东西。但 HN Hiring 这样的小工具反而提醒我们很多场景下一个“能做一件事且做好”的工具就已经足够有价值。如果你也经常面对信息过载不妨想想自己的“Who Is Hiring 帖子”是什么。它可能是一个论坛一份邮件周报一个讨论群甚至一堆散落在浏览器书签里的文章。用工程思维把它们变成可搜索、可过滤的对象这个过程不一定复杂但一定会让你对信息本身的掌控感完全不一样。下一次当你打开一个满是信息噪声的页面也许可以不用继续划鼠标了。