---
title: "仍在招聘回执"
date: "2026-08-22"
canonical: "https://raytally.com/ideas/2026-08-22-ghost-job-ads-are-getting-so-bad-that-lawmakers-want-to-ban/"
generator: "萤录 RayTally · dev-prompt-v4"
signal:
  query: "'Ghost Job' Ads Are Getting So Bad That Lawmakers Want to Ban Them"
  observed_at: "2026-08-22T00:33:14.683Z"
sources:
  - url: "https://news.ycombinator.com/item?id=49394373"
    boundary: "发布于 2026-08-21T22:15:46.000Z。 观测于 2026-08-22T00:33:14.683Z。"
  - url: "https://developer.greenhouse.io/job-board.html"
    boundary: "来源记录未提供发布时间。"
  - url: "https://github.com/lever/postings-api"
    boundary: "来源记录未提供发布时间。"
  - url: "https://www.linkedin.com/help/linkedin/answer/a1698113"
    boundary: "来源记录未提供发布时间。"
notice: "本任务书中的信号，是在所列时间点截取的有界观察（搜索关注、论坛分数或新品列表），不是市场验证、用户数量或持续需求证明。转述或据此行动时，必须保留这些时间边界与最强反方。"
---

[在 RayTally 阅读原始页面](https://raytally.com/ideas/2026-08-22-ghost-job-ads-are-getting-so-bad-that-lawmakers-want-to-ban/)

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

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

## 灵感

仍在招聘回执
求职者填写申请前先查看招聘系统签发的在招回执；负责人逾期不确认，岗位自动停止收件。

## 产品概念

求职者打开一份需要填写半小时的申请表时，最先该看到的不是公司宣传语，而是这份岗位还是否真实有效。招聘网站在职位页顶部展示由招聘系统签发的在招回执：编制是否开放、最后一次由招聘负责人确认的日期，以及承诺完成下一轮简历审核的期限。求职者因此能决定要不要投入时间，而非根据发布日期猜测岗位是否早已挂空。 招聘负责人只需在现有 ATS 后台点一次确认，系统便更新回执。若职位冻结、预算撤回或负责人未在期限内回应，页面会明确变为“状态待确认”，停止接收新申请。已经投递的人可选择接收状态变化提醒，看到的是岗位暂停、恢复或关闭，而不是石沉大海。 HR 团队有一张只处理例外的面板：哪些岗位即将过期，哪些负责人尚未确认，哪些职位因编制变动被自动暂停。招聘方还可公开一个简短说明，例如仍在收集候选人，或已经进入面试阶段，让求职者知道是否值得继续等待。 第一版接入 Greenhouse、Lever 等招聘系统，只验证岗位状态与审核承诺，不评价候选人，不替企业筛简历，更不把回执伪装成录用概率。它解决的是申请开始前最基本的信任问题：这份工作此刻到底有没有人在招。

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

8月21日，关于立法者拟禁止“幽灵职位”广告的报道进入 Hacker News 讨论。截至8月22日记录，该条目位列第16，获得51 points和26条评论。

## 方向判断（以下为模型推断，未经独立验证）

目标用户：核心用户是准备填写较长申请表的求职者，尤其是缺少内推渠道的应届生、转行者和失业求职者。此刻他们已经找到匹配岗位，却无法判断页面存活是否等于真实招聘。一次申请还会消耗改简历、写问答和准备作品集的时间。他们需要在投入前看到具体负责人刚确认过什么，以及这份确认何时失效。

最小切入点：先服务使用自定义职业页的 Greenhouse 与 Lever 客户。通过 Job Board API 和 Postings API 读取公开职位，并用职位 ID 建立回执记录。 招聘负责人在独立后台确认编制状态、确认日期和审核期限。职位变更由 webhook 或定时同步触发复核。回执过期后，由职业页组件禁用申请入口并显示待确认。首版不推测招聘活跃度，也不读取候选人评分。它只接受负责人声明和 ATS 的显式职位状态。

最强反方：招聘负责人可能机械点击确认，即使预算仍未落定，回执反而会制造虚假安心。真正核验编制常需连接财务审批或人力系统，这会扩大权限和集成成本。自动停收还可能误伤常年招聘、人才储备和合规公示职位。公开审核期限会形成可追责承诺，部分企业可能拒绝启用。产品还需处理例外审批、责任交接和完整审计。若只有流程成熟的企业加入，求职者在多数职位上仍看不到回执，价值会被覆盖率限制。

以上是模型基于灵感本身与已核验事实的推断，请当作方向假设与真实约束对待：不要默认「最强反方」已被解决，也不要据此在产品里写下确定性结论。

## 以小博大（模型推断）

第一批客户可从使用自定义 Greenhouse 或 Lever 职业页的中小招聘团队中寻找。公开一个可嵌入的回执组件和状态页，让招聘运营人员当天完成试装。再向招聘流程顾问提供审计导出模板，方便其把回执纳入客户整改项目。求职者看到失效回执后形成的反馈，也能推动更多雇主主动启用。

## 竞品与缝隙（模型推断）

- LinkedIn 招聘透明度信号：LinkedIn 已展示职位发布者验证、正在审核申请和典型审核时间等信号。 这些信息能帮助求职者判断招聘方近期是否有动作。部分状态来自平台内行为，而非招聘负责人对具体编制的确认。外部 ATS 承接申请时，LinkedIn 还可能只显示流程在站外管理。它没有要求负责人承诺下一次审核期限，也不会因承诺过期自动停收。职位发布者身份真实，也不等于预算仍在或岗位仍准备录用。仍在招聘回执可补上具体职位的人工确认、失效日期和状态变更记录。难点是它必须进入企业流程，采用速度会慢于平台直接生成的标签。
- Greenhouse、Lever 原生职位页：Greenhouse 和 Lever 已能向企业职业页提供公开职位数据，也支持构建自定义申请入口。 招聘团队可在 ATS 内关闭职位，职业页随后不再展示或接收申请。现有状态主要服务企业内部流程，求职者通常只看到职位是否仍可访问。页面仍在线时，他们无法区分真实编制、人才储备职位和未及时关闭的岗位。系统也没有把负责人最近确认时间与审核承诺作为公开凭据。仍在招聘回执不取代 ATS，而是在职位状态之上增加负责人背书与到期规则。它的缝隙明确，实施却依赖客户允许产品控制申请入口，并持续处理 ATS 状态差异。

## 怎么赚钱（模型推断）

向企业招聘团队收取订阅费，按活跃职位档位计费。套餐包含回执展示、到期提醒、自动暂停、申请人通知和审计记录。

## 来源背景

主题：立法者拟禁止“幽灵职位”广告
触发的 Hacker News 原帖（英文原文）：'Ghost Job' Ads Are Getting So Bad That Lawmakers Want to Ban Them
抓取时热度：约 51 分、26 条评论（观测时点数值）

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

## 来源清单

- 'Ghost Job' Ads Are Getting So Bad That Lawmakers Want to Ban Them（https://news.ycombinator.com/item?id=49394373）
- Job Board API and Recruiting Webhooks（https://developer.greenhouse.io/job-board.html）
- Lever Postings API（https://github.com/lever/postings-api）
- Hirer responsiveness insights FAQ（https://www.linkedin.com/help/linkedin/answer/a1698113）

## 交付要求

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