---
title: "招聘帖里的双向握手"
date: "2026-09-02"
canonical: "https://raytally.com/ideas/2026-09-02-show-hn-hn-match-maker-matching-who-wants-to-be-hired-with/"
generator: "萤录 RayTally · dev-prompt-v4"
signal:
  query: "Show HN: HN Match Maker – Matching \"Who Wants to Be Hired?\" With \"Who's Hiring?\""
  observed_at: "2026-09-02T00:33:20.953Z"
sources: []
notice: "本任务书中的信号，是在所列时间点截取的有界观察（搜索关注、论坛分数或新品列表），不是市场验证、用户数量或持续需求证明。转述或据此行动时，必须保留这些时间边界与最强反方。"
---

[在 RayTally 阅读原始页面](https://raytally.com/ideas/2026-09-02-show-hn-hn-match-maker-matching-who-wants-to-be-hired-with/)

使用声明：以下信号只是带时间边界的公开观察，不是市场验证、用户数量或持续需求证明；转述或执行时必须保留时间边界与最强反方。

你是资深产品工程师。请把下面这条产品灵感做成一个可以本地运行的 MVP。

## 灵感

招聘帖里的双向握手
每月招聘帖发布后，把求职与岗位需求做成双向匿名选择，互相点头才交换联系方式。

## 产品概念

每月 Hacker News 招聘帖出现后，求职者和小团队招聘者都要在长串自由文本里找人，还得承受大量不合适的私信。产品先抓取参与者主动提交的帖子，把每份内容整理成匿名机会卡：技术方向、所在地或时区、薪资范围、工作形式和不可妥协条件。 求职者浏览岗位时，先看到岗位卡而非公司联系人；招聘方筛选人才时，同样只看到候选条件卡。任一方点选感兴趣，系统不会立刻暴露身份，只有另一方也愿意继续，才打开双方原帖与联系方式。 匹配成功后，产品生成一封短介绍信，写明双方在哪几项条件上对得上，例如 Rust、欧洲时区与远程合同。双方可以删改后再发送，避免“算法替我写了热情套话”的感觉。未互相选择的卡片到期自动隐藏，没人需要处理陌生冷信。 初版只服务当月 HN 的“谁在招聘”和“谁想被雇用”帖子，并允许用户手动修正解析结果。它不替招聘方自动淘汰人，不给求职者排位，更不把匿名卡卖给猎头；先把公开帖里的第一轮互相点头做顺。

## 为什么是现在（有事实支撑）

「Show HN: HN Match Maker – Matching "Who Wants to Be Hired?" With "Who's Hiring?"」的相关讨论正处于 Hacker News 首页第 20 位，热度约 33 分、14 条评论（9 月 2 日快照，数值为观测时点近似）。这让相关的使用场景此刻更集中。

## 来源背景

主题：Show HN: HN Match Maker – Matching "Who Wants to Be Hired?" With "Who's Hiring?"
触发的 Hacker News 原帖（英文原文）：Show HN: HN Match Maker – Matching "Who Wants to Be Hired?" With "Who's Hiring?"
抓取时热度：约 33 分、14 条评论（观测时点数值）

以上数据是抓取时刻的历史快照，分数与评论数会随时间漂移，只用于理解「为什么是现在」，不要写进产品文案当作精确的市场数字。

## 交付要求

- 开工前，先从上文的产品概念与最小切入点提炼 3–5 条可验证的完成标准并列出，交付时逐条对照说明。
- 先交付「最小切入点」描述的核心流程，让核心用户能走通；范围外的账号、支付、后台等通用系统，除非确有必要否则不做。
- 页面或接口里不要展示未经验证的市场数字。
- 关键文案保持克制、可验证；产品内若需要领域事实、安全指引类内容，从「来源清单」等权威来源取材改写并注明出处，不要凭通识编写。
- 若在已有项目里实现：先读 README、依赖与项目约定，遵循既有技术栈与风格，不重构无关代码。
- 若当前目录为空：选一套轻量技术栈，优先交付可运行原型。
- 完成后说明改了什么、如何运行、如何验证。
- 遇到真正会改变产品方向的歧义再提问，普通实现细节自行做工程判断。