在 B2B 销售和市场情报领域，大家最关注的通常是融资公告。
一家公司完成 A 轮融资，整个 SaaS 生态里的工具供应商仿佛同时收到了发邮件的许可。这个反应并不奇怪：融资说明公司有了资金、有了计划，接下来大概率会有一长串事情要做。
但融资并不能告诉你：钱具体会花在哪里。
要回答这个问题，你需要关注另一个信号：招聘。
当一家公司开始扩充北美销售团队、在欧洲招聘客户成功人员，或者组建一支新的工程团队时，它其实正在告诉你资源的优先级。融资只能说明有人中了彩票；招聘则更接近于告诉你，他们准备拿这笔钱买什么。
这篇文章会介绍如何用程序化的方式追踪招聘和裁员信号，同时避开那种第二天就被 LinkedIn 封掉的脆弱爬虫。更重要的是，我也会坦诚说明这类数据目前的边界，尤其是裁员数据。一个真正有用的情报系统，不应该只告诉你它看到了什么，也应该告诉你它还没有能力确认什么。
为什么不建议自己爬招聘网站？
如果你决定从零搭建这条管道，最自然的起点通常是写一个 Python 脚本，去抓取 LinkedIn、Indeed 或各地的招聘网站。
它可能能运行一段时间，然后熟悉的事情就会开始发生：
- IP 被封。 招聘网站投入了大量资源应对自动化访问，而它们通常不会因为你的
requests循环写得很漂亮就手下留情。 - HTML 结构变了。 CSS 选择器不再匹配，脚本要么直接报错，要么更糟：脚本还在运行，却已经悄悄抓不到有效数据。
- 数据需要大量解释。 你需要标准化职位名称、识别所属部门、从自由文本里判断地点、删除重复职位，还要搞清楚三个相似职位究竟代表三个岗位，还是同一个岗位被发布到了三个平台。
- 不同地区的覆盖不一致。 某个平台可能在德国覆盖很好，另一个平台在美国更强，某些本地市场则可能只有当地招聘网站才有价值。
真正麻烦的并不是把 HTML 下载下来，而是在不断变化的数据源之上，维护一层可靠的解释逻辑。
如果你想建立一条可重复使用的情报管道，结构化数据通常是更好的起点。你不需要一整页原始 HTML，只为了在某个角落找到“Sales Development Representative—Berlin”。你需要的是一条结构清晰的记录，例如：
某公司最近在德国新增了 5 个销售岗位，而且这些职位目前仍然有效。
这就是“爬虫”和“情报工作流”的区别。
两类值得关注的人力信号
建立情报管道时，最好把人力数据分成两类：招聘和裁员。它们有关联，但回答的是不同问题。
1. 招聘：行动信号
招聘数据是两者中更成熟、也更稳定的一类。
它告诉你公司正在把资源投向哪里。某个地区或部门突然出现一批职位，可能意味着公司正在进入新市场、投资某个产品、应对不断增长的客户，也可能是在修补当前缺失的能力。
当以下几个条件同时出现时，招聘信号尤其值得关注：
- 职位发布时间较新；
- 多个职位指向同一个方向；
- 招聘地点和公司的目标市场一致；
- 招聘部门与你的产品有关；
- 招聘动作紧跟融资、产品发布或其他战略变化之后。
一个孤立的职位，通常只是弱信号。一组相互指向同一方向的职位，就有意思多了。
2. 裁员：重组信号
裁员数据的情况不同。
有时它会出现在公开声明或监管文件中，有时由本地媒体报道，也有时只存在于一封没有流出公司的内部邮件里。
这让裁员更难持续、完整地追踪，也更难被准确解释。
但完全忽略裁员同样是一个错误。裁员不只是“坏消息”，它也可能意味着公司正在放弃某个市场、关闭一条业务线、合并某个地区，或者让一批经验丰富的人重新进入人才市场。
对于竞争对手来说，裁员可能意味着一个市场空缺；对于猎头来说，它可能意味着一批刚刚释放出来的人才；对于服务商来说，它可能说明某个团队正在改变方向，接下来会需要不同类型的支持。
这里有一个重要边界，我不想把它藏在营销话术后面：裁员覆盖目前仍然是一个正在形成的数据集。 它可以作为方向性信号，但不应该被当成每家公司、每次组织变化都能完整记录的权威数据库。
这也是为什么我会把招聘作为主要触发信号，把裁员作为辅助背景。两类数据都值得建设，但不能假装它们现在拥有相同的覆盖率和确定性。
关于数据集和 Pro 版本：先把边界说清楚
这也涉及产品本身，所以这里需要坦诚说明一下。
我们在 ParheliaWeb 做结构化招聘与裁员数据，是因为原始信息分散、不一致，而且很难以较低成本规模化使用。目前，招聘数据是相对成熟的部分；裁员数据正在持续完善，但覆盖范围和稳定性还不足以让我把它包装成一套完整的全球监控系统。
这个现实也直接影响了商业上的决定：在数据质量足以支撑之前，我有意没有开始对完整的 Pro 版本收费。
把“Pro”放到价格页上，增加几个额度，然后暗示覆盖已经很全面，并不困难。但这会是一个很糟糕的交换：短期可能带来收入，却不够诚实，也会让真正依赖这些数据的人承担不必要的风险。
所以，目前更准确的承诺应该是：
- 招聘信号是当前最主要的使用场景；
- 裁员信号可以补充背景，但覆盖仍在建设中；
- API 和接口结构可能会继续演进；
- 对重要事件采取行动前，用户仍然应该回到原始来源进行核验。
这不是为“在建设中的产品”找借口，而是在说明产品当前真正的边界。一个信号不必完美才有价值，但系统必须让用户知道它的不确定性在哪里。
搭建一个轻量级信号监控器
为了避免维护一套容易失效的爬虫集合，你可以使用结构化数据 API，例如我们正在 ParheliaWeb 建设的 API，来搭建一个小型监控脚本。
这个例子的目标很克制：输入一组目标公司域名，请求近期的人力事件，把结果匹配到你关心的公司，并在发现相关变化时打印提醒。
由于 API 仍在持续演进，具体接口和响应结构可能会调整，所以请把下面的代码理解成一种实现模式，而不是可以直接复制到生产环境的最终集成。这里真正重要的是：使用环境变量保存认证信息、处理结构化 JSON、匹配公司域名，以及明确处理数据覆盖不完整的情况。
import os
import requests
# 最佳实践：不要把 API 密钥直接写进代码。
API_KEY = os.environ.get("PARHELIA_API_KEY")
BASE_URL = "https://parheliaweb.com"
def check_company_signals(domain: str):
"""检查某个公司域名近期的人力信号。"""
if not API_KEY:
raise RuntimeError("未设置 PARHELIA_API_KEY")
headers = {"x-api-key": API_KEY}
print(f"正在检查：{domain}...")
# 融资可以反映意图。
# 招聘和裁员可以反映行动或组织重组。
# 具体接口取决于 API 版本和当前套餐。
response = requests.get(
f"{BASE_URL}/v1/layoffs",
headers=headers,
params={"max_age_days": 30, "lang": "en"},
timeout=15,
)
if response.status_code != 200:
print(f"获取 {domain} 的数据失败：{response.status_code}")
return
data = response.json()
results = data.get("results", [])
# 如果接口支持按域名过滤，优先使用服务端过滤。
# 否则，可以在本地对返回结果进行匹配。
company_events = [
event
for event in results
if event.get("company_domain") == domain
]
if not company_events:
print("没有找到匹配的人力事件。")
return
for event in company_events:
print(f"提醒：{event.get('company_name', domain)}")
print(f" 类型：{event.get('event_type', 'Unknown')}")
print(f" 日期：{event.get('announcement_date', 'Unknown')}")
print(f" 详情：{event.get('reason', 'Not provided')}")
print("-" * 40)
if __name__ == "__main__":
target_domains = ["stripe.com", "example-saas.com"]
for company_domain in target_domains:
check_company_signals(company_domain)
根据当前 API 的具体结构，你也可能需要请求通用的 /v1/hiring 接口、人力事件接口，或者支持按域名查询的接口。基本原则不变：
- 请求结构化数据；
- 统一公司的身份信息；
- 按域名或公司 ID 进行匹配；
- 检查事件类型、日期、部门、地点和置信度；
- 只有当事件足够相关、值得人工查看时，才触发提醒。
如果要用于生产环境，还需要考虑重试、日志、分页、限流、去重，以及记录某条提醒是否已经被人工审核。
五十行示例代码很有吸引力，但生产系统通常会在某个周五下午提醒你：它其实还需要另外九十五行代码。
不要自动化对话
脚本开始产生提醒之后，最容易出现的冲动，就是直接把它接到邮件发送器上。
这通常也是一条有价值的情报工作流，开始变成又一个群发垃圾邮件系统的地方。
信号的作用是提供上下文。如果自动化最后只发出一封“看到你们正在招聘销售，快来买我们的工具”的模板邮件，那你并没有真正使用情报，只是给传统群发增加了一个更聪明的触发器。
用代码找到变化。用人工判断这个变化是否重要。然后，自己写第一句话。
较弱的写法
Hi [Name], I see you are hiring. We help with hiring.
这封邮件 technically 和招聘信号有关，但几乎没有提供任何具体信息。它可以在任何一天发给任何国家的任何公司。
更好的写法
Hi [Name], I noticed you’re expanding your sales team in Germany. We help sales teams manage localized outreach without damaging their sending reputation. Since you’re building that market now, would a quick comparison be useful?
这封邮件同样需要建立在真实相关性的基础上，但至少能让对方看出：你确实看过他们正在做什么。
第一封邮件是给名字贴了标签的群发消息。第二封邮件，至少有机会成为一次对话的开始。
从提醒到行动：把多个信号放在一起看
当你把招聘和裁员信号与其他信息结合起来，它们的价值会更高。
例如：
- 一家公司刚刚完成融资，说明它可能有意图和预算；
- 它正在德国招聘销售代表，说明扩张方向比较具体；
- 它同时招聘当地的客户成功人员，说明它不只是想获得客户，也在考虑如何承接客户；
- 它的团队正在使用与你产品匹配的技术栈，说明实施可能比较现实；
- 员工正在公开讨论你的产品能够解决的问题，说明接触时机可能值得进一步研究。
单独一个信号，无法证明一家公司已经准备采购。多个信号放在一起，才能帮助你判断哪些公司值得投入研究，哪些公司应该暂时留在更大的候选池中。
这就是“收集事件”和“建立情报”的区别。
目标不是制造最多的提醒，而是得到一份更小、更清晰、下一步更明确的公司名单。
结语：数据不是答案，变化才是线索
不管是招聘还是裁员，数据的价值都不只在于数据本身，而在于它帮助你看见了什么变化。
裁员可能意味着资源重新分配，也可能意味着公司正在退出某个市场；招聘可能意味着业务扩张，也可能只是团队补缺。单独看一条信息，很容易误判。把它和融资、岗位、技术栈、社区讨论以及公司阶段放在一起看，才有机会还原真实的商业动作。
当你的同行还在盲目群发邮件、碰运气找客户时，你可以更具体地说：
“我注意到你们最近在招聘北美销售和客户成功岗位，似乎正在扩大当地市场。我们正好帮助类似团队处理线索分配和跟进效率问题。”
这封邮件不一定就会得到回复，但至少说明了一件事：你关注的是对方正在做什么，而不只是对方有没有预算。
好的销售情报，不是把所有新闻都收集起来，而是更早识别真正有意义的变化。
这也是我对当前产品建设的基本态度：先把能确认的信号做好，把不能确认的边界说清楚，再逐步扩大覆盖。对于出海团队来说，一条诚实的、不完美但可验证的数据，通常比一套看起来无所不知、实际无法核验的系统更有价值。
找信号，可以交给代码。理解上下文，需要认真研究。真正开始对话时，还是要像一个人。
🚀 人力数据只是信号的一部分
招聘告诉你公司在哪里扩张。融资轮次告诉你他们有多少预算去做下一步。 了解我们是如何构建 初创公司融资信号 API 的，它通过同样简单的 REST 接口提供经 AI 验证的融资数据。
有问题？
我是 Andy，创始人。我只是个喜欢为人解决问题的 IT 仔。如果您对数据、覆盖范围或 API 有任何疑问，随时给我发邮件。