← 实地笔记 · 11 分钟阅读

查询 AI 公司的 ATS API，寻找真实的前沿部署工程师职位

前沿部署工程师的招聘需求现在到处都是，而且很多并不像表面看起来那样。我厌倦了猜测，所以不再阅读职位聚合网站，而是开始直接查询这些公司自己的招聘追踪系统。

大多数招聘该职位的公司使用 Ashby 或 Greenhouse，两者都提供公开的职位发布 API，无需身份验证，也没有速率限制的困扰：

https://api.ashbyhq.com/posting-api/job-board/<org>
https://boards-api.greenhouse.io/v1/boards/<org>/jobs?content=true

它会返回三个通过爬取无法可靠获得的字段：

isListed

，它告诉你该职位是真正在招，而不仅仅是被搜索引擎收录；

publishedAt

，即真实的发布日期；以及完整的职位描述文本，这样你就可以精确引用职位要求，而不是转述一个片段。

以下所有数据均于 2026-08-03 抓取，并于 2026-08-04 重新核实。招聘网站每天都在变化，所以请重新运行查询，而不是相信这些数字。在我观察期间，该数据集中有一个招聘板在二十四小时内新增了十四个职位。

那个显而易见的规则行不通

我首先尝试的是最直观的方法。代表数十个第三方发布职位的聚合网站应该有一个巨大的招聘板，职位名称多样性极高，而真正的雇主应该有一个小而集中的招聘板。于是：标记大型招聘板。

这条规则是错的，而且错在关键的方向上。

Harvey 是一家真实公司，它的招聘板比我怀疑的那个更大，职位名称多样性却更低。OpenAI 的规模几乎是两者的两倍。规模只能告诉你一家公司融了多少钱，它不能告诉你一个职位是否真实，职位名称多样性比例也不能。

真正有效的规则

信号不是重复。而是某个其含义本身禁止重复的职位名称的重复。

统计职位名称以"Founding"一词开头的招聘需求。

看第四列。这组数据中每一个单一雇主的招聘板，其不同的创始职位名称都在零到三个之间。只有一个招聘板有五十二个，其中包括十九个完全相同、名为"Founding Engineer"的职位，十四个名为"Founding Engineer ($3M pre-seed)"的职位，以及九个名为"Founding Engineer, SF Hackerhouse (Visa sponsored; $3M pre-seed)"的职位。

一家公司只会创立一次，所以它只有少数几个不同的创始职位。而聚合器会汇集许多公司的创始职位，因此其不同创始头衔的数量会无限增长。五十二对上限三，这不是我调出来的阈值；这是一个中间空无一物的鸿沟。

这条规则有效的原因是语义层面的，而非统计层面的。创始工程师（founding engineer）按定义就是第一个，你不可能有十九个。相比之下，Sierra 在八个不同城市发布八个名为"Software Engineer, Agent"的招聘需求，这完全正常，而一个天真的重复检测器却会将其标记出来。

这条规则是我尝试的第三条，前两条仍保留在这篇文章中

我已经有两个版本的规则被我表格中提到的公司证伪了。以下两条仍然成立，因为一个可以验证的过滤器比一个只能信任的过滤器更有价值。

版本一：统计创始招聘需求的数量。 我曾声称一家真实的雇主最多只有两个。Dryft 在五个职位的招聘板上出现了三个，Avallon 在三个职位的招聘板上出现了三个。

这两者正是种子期公司的典型样子。三个不同的创始职位很正常，甚至可以说是公司真实且处于早期阶段的最强信号。

版本二：真实的雇主不会重复同一个创始头衔。 这条规则一直成立，直到我读了 Glean 的招聘板——它用的是 Greenhouse 而不是 Ashby：

三个相同的头衔，一家真实的公司，而且正是这篇文章讨论的那个职位。这只是一次搜索发布在三个都市区，和 Sierra 在八个城市发布八个"Software Engineer, Agent"招聘需求一样平常。重复本身从来不是信号，而且我在基于重复构建规则之前，就已经把 Sierra 作为对照组发布来证明这一点了。

在两者检验下都成立的是不同创始头衔的数量。Glean 有一个。Dryft 和 Avallon 各有三个。而聚合器有五十二个。

这些在单个职位发布上都看不出来。我描述的这个招聘板上有十一个前沿部署工程师（Forward Deployed Engineer）的招聘需求，其中一个头衔是"Founding Forward Deployed Engineer"，读起来和真实的一模一样。

API 还免费提供的另外两样东西

isListed

能捕获那些已经停止招聘但仍被索引的职位。

我之前从搜索结果中收藏的三个创始 FDE 职位，在核查时已从实际招聘页面上消失了。这些公司仍然存在，招聘页面也还在，分别有 2 个、4 个和 9 个职位。只是职位需求关闭了，而搜索结果没有更新。仅凭搜索页面求职的人，会去申请三个已关闭的职位。

publishedAt

告诉你一个职位发布已上线多久。这不等于该职位空缺了多久。

在那些小到只属于单一雇主的招聘页面上，每个在招的前沿部署工程师职位及其发布日期，测量于 2026-08-03：

我最初把这一列顶部的数字解读为招聘失败。但结合其余数据来看，这种解读站不住脚。Baseten 的“前沿部署工程师”职位发布于 2024-03-28，两年多后仍在一个有 64 个职位的页面上挂着。OpenAI 则有针对东京、巴黎、慕尼黑、都柏林和政府业务的前沿部署工程师职位，全部发布于 2025 年 9 月的三周之内。这两家公司并不是从 2024 年起就一直招不满一个职位。那些是常青职位，挂着以收集主动投递。

所以发布时长是一个值得追问的问题，而不是一个定论。一个长期在招的职位可能意味着门槛很高、薪酬不对，或者没人负责招聘。它同样可能意味着这个职位本来就打算一直不关闭，或者已经招到人却挂在同一个职位需求下重新发布。这个字段只记录了职位的发布时长，对招聘结果只字未提。值得在初次通话中问清楚，但绝不要想当然。

至于另一端的规模：仅 OpenAI 一家，就在一个有 736 个职位的页面上挂着 37 个前沿部署工程师类型的职位。

一个花了我十分钟的方法笔记

我第一次抓取时，全部 21 个招聘页面都返回了 HTTP 403，其中包括我 60 秒前还手动查询成功的三个页面。如果所有组织——包括已知正常的那些——都统一失败，那问题出在你的客户端，而不是服务器。Ashby 屏蔽了 Python 默认的 urllib user agent。用 curl 可以正常访问，给 urllib 设置一个真实的 user agent 也可以。

一般化的经验：当某个检查对所有对象同时失败时，先用一个已知正常的对照样本走完全相同的路径，再下任何结论。如果对照样本也失败，那你测出的是你自己的工具的问题。

相关，而且花了我十多分钟：Anthropic 和 Glean 在那些 slug 下没有 Ashby 招聘板。这意味着是未验证，而不是不存在。两者都在 Greenhouse 上，而 Glean 的招聘板正是让我第二版规则失效的那一个，所以我之前归为“无法读取”的那家公司，反而是整个集合中信息量最大的一个招聘板。把查询失败记录为负面结果，和把 403 读成招聘板已关闭，是同一种错误。

我实际会怎么用这些信息

我持续运行着这个方法的一个窄化版本。我维护在 /jobs 的招聘板每十二小时用同样的职位发布 API 重建一次，覆盖十三家公司，其中 Ashby 的行按

isListed

过滤，所以一个关闭的职位会在下次刷新时消失。这只覆盖了下面的第 3 步，别无其他：它只是这个方法中某一部分的输出，并不能替代你在我未跟踪的公司上自己完整地跑一遍。

在申请任何自称创始或首个的职位之前：

• 从 ATS API 拉取该公司的招聘板，统计职位总数。
• 统计以"Founding"开头的去重后职位名称数量。零到三个是普通公司。几十个则意味着这个招聘板是别人创始团队的目录。无论是创始职位的原始数量还是某个职位的重复出现，都不是信号：一家种子期公司可以有三个不同的创始职位，而一家真正的公司也可以在三个城市发布同一个创始职位。
• 检查具体职位的 isListed，而不是信任把你带到那里的搜索结果。
• 阅读 publishedAt。如果它很旧，在第一次对话中询问该职位的搜索情况。
• 从 API 读取完整的职位描述文本，而不是聚合器的摘要——后者经常在要求部分中间被截断。

局限

负面一侧已得到充分验证。正面一侧只有一个招聘板。 我现在检查了属于同一家雇主的 41 个招聘板，横跨 Ashby、Greenhouse 和 Lever，每一个的去重创始职位数量都在零到三之间。这个集合包括我未跟踪且此前没有观点的公司（Notion、Linear、Vercel、Replit、Modal、LangChain、Fireworks、Mercor、Anthropic、Scale AI），外加几家风投机构的招聘板——结果发现它们只是普通的小型内部招聘板，而非投资组合聚合器。

相对于这 41 个，规则另一侧我只有一个招聘板。这才是真正的弱点，我宁愿自己说出来，也不愿让你发现。仅凭一个正面例子验证的过滤器，在有人打破它之前，只是对那个例子的描述。

我去找第二个反例聚合器，失败了两次，而第二次失败更有价值。我的第一反应是，最明显的反例应该是一家专门把工程师派驻到其他公司内部的企业，于是我在四个 ATS API 上探查了六家这样的公司：Andela（18 个职位）、Turing（27）、Toptal（25）、Braintrust（24）、Oyster（20）和 A-Team（3）。每一家都没有任何不同的创始头衔，因为人才市场平台只在自己的招聘板上发布自己的内部招聘。Turing 的招聘板上写着 Chief of Staff、Executive Assistant to the CEO、Community Manager。Toptal 的写着 Director of Service Desk 和 Enterprise SDR。所以判别标准并不是“人力派遣公司对产品公司”，商业模式并不能预测结果。这条规则真正衡量的是，一个招聘板是否在替第三方发布职位需求，而 Turing 是最清晰的例证：它同时挂着三个独立的 Forward Deployed 职位需求，得分却仍然是零，因为规则统计的是创始头衔而不是 FDE 头衔。与此同时，投资组合和人才联盟的招聘板大多根本不在 Ashby 或 Greenhouse 上，而是运行在 Getro、Consider 等没有可比公开 API 的平台上。这条规则想要捕捉的那一类招聘板，对规则所依赖的方法来说基本上是不可见的。 如果你能找到另一个，我很想听听。第八家 Glean，我最初记录为不可读，因为它的 Ashby slug 没有返回任何内容。那其实只说明了我试的是哪个 API：Glean 在 Greenhouse 上，它的招聘板读取正常，而正是它击破了规则的第二个版本。“不可读”这个结论只针对你指向目标的那个工具。它只覆盖 Ashby、Greenhouse 和 Lever，所以使用 Workable、SmartRecruiters 或自建招聘板的公司完全不在其范围内。这条规则只是一个廉价的第一道过滤器，而不是结论，这里的一切都可以通过重新运行顶部的两个 URL 来验证。

常见问题

如何检查一个职位发布是否仍然开放？

Query the company's ATS posting API directly and read the isListed field. Ashby exposes https://api.ashbyhq.com/posting-api/job-board/<org> and Greenhouse exposes https://boards-api.greenhouse.io/v1/boards/<org>/jobs?content=true, both without authentication. Search engines keep indexing reqs after they close, so a result on a search page is not evidence the role is live.

如何判断一个招聘板是否属于真正的雇主？

统计同一个完全相同的 Founding 头衔在招聘板上重复出现的次数。在 2026-08-03 和 2026-08-04 检查的 16 个单一雇主招聘板上，没有任何创始头衔重复超过一次，而有一个招聘板把 Founding Engineer 重复了 19 次。创始职位的原始数量不能作为检验标准：Dryft 和 Avallon 各自带有三个不同的创始职位，且都是真实的公司。招聘板规模也不行：Harvey 有 362 个职位，头衔多样性却低于那个未通过此测试的招聘板。

前沿部署工程师职位已经开放多久了？

ATS 职位发布 API 中的 publishedAt 字段给出了真实的发布日期。在 2026-08-03 仍在招聘的初创公司 FDE 职位中，发布时间从 12 天到 367 天不等。一个开放已久的初创职位值得在首次通话中询问，因为这可能意味着招聘门槛很高、薪酬定价有误，或者该招聘无人负责。