关于 account-sourcing
account-sourcing 使用招聘信息中的岗位与描述信号筛选和评分 B2B 目标公司,适用于需要从公开招聘数据寻找潜在客户的团队。它强调核验原文证据,并保留筛选原因和评分依据。
主要功能
- 01按岗位与描述关键词搜索招聘信息
- 02合并结果并按域名去重
- 03按行业、名称、职位和地域筛选
- 04依据招聘信号为公司评分分级
- 05提取并核验原文证据片段
- 06输出公司级 CSV 及运行统计
适用场景
- 01寻找招聘基础设施或 SRE 人员的公司
- 02定位提及技术债或系统现代化的企业
- 03在名单交付前人工核查招聘描述证据
MCP 相关
通过 Apify MCP 获取 ATS 职位信息;之后由 Python 3 筛选并评分。
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ victor-shulga/ outbound-engine-skills --skill account-sourcing安装后在 Claude Code 中输入/account-sourcing确认已加载。
附带文件scripts/filter_score.py
详细介绍
基于职位信号寻找目标客户
职位发布是 B2B 中成本最低、最真实的信号。公司发布“我们的应用是一个宏伟的单体架构”,就已经为此付出了成本,也不会收回这句话。
为什么用 ATS 聚合器,而不是 LinkedIn
LinkedIn 职位抓取只能获取职位名称。真正重要的是职位描述正文——公司会在这里说出自己的问题。使用一个能索引各类 ATS 平台(Greenhouse、Ashby、Lever、Workday 等)招聘网站并提供以下功能的聚合器:
- 在职位描述中进行全文搜索
- 按公司员工人数筛选
- 排除招聘代理机构的标记
在 Apify 上,可用的 Actor 是 fantastic-jobs/career-site-job-listing-api(每条职位约 $0.012)。Apify 之外的同类服务:TheirStack、PredictLeads。
查询设计
要用两个查询,而不是一个。
查询 A——职位信号。 只搜索职位名称:平台、基础设施、SRE、DevOps。扩大搜索范围,了解哪些公司正在为人才缺口招聘。
查询 B——语言信号。 搜索更广泛的工程职位名称,并且在 descriptionSearch 中搜索 legacy、monolith、technical debt、modernization、re-architect。范围较窄,但每条结果都是公司在描述自身问题。
查询 B 更有价值。两个查询都运行,合并结果后按域名去重。
始终设置:国家、员工人数范围、全职、排除招聘代理机构、包含公司详情。
导致一半信号流失的陷阱
“所有活跃职位”模式会按最新优先返回结果,并在达到上限时截断。请求 300 条,你得到的就只是最近一周的职位——永远看不到已开放 139 天的职位,而它是这批数据中最强的产能信号。
解决方法:缩小查询范围,直到结果总数低于上限。 这样就会返回完整的活跃职位积压,包括过期未关闭的职位。通常,缩窄职位名称列表并添加描述筛选就足以做到这一点。
筛选——预计会剔除三分之二
代理机构标记无法过滤掉实际污染结果的内容。需要明确的排除步骤:
- 按行业——IT 服务与咨询、国防、政府、高等教育、招聘、专业服务、非营利组织
- 按名称——维护一份不断更新的承包商和控股公司排除名单,把反复出现的对象加进去
- 按职位名称——包含 clearance、TS/SCI、polygraph 的任何职位
- 按地理位置——总部位于目标市场之外
- 按公司历史——成立不到 3 年的公司没有需要现代化的对象
此技能中的 scripts/filter_score.py 实现了这一步。编辑这些列表;它们因细分领域而异,也是最容易过时的部分。
每次运行后都要检查排除名单。 很容易过滤过度,漏掉只是被错误标记行业的真实产品公司。至少对比一次被剔除的行。
评分
采用加法计分,最高 135 分。始终报告分母。
40 base — cleared every filter
+25 problem language quoted in the posting body
+15 second engineering opening | +30 third and beyond
+20 posting open 60+ days | +10 open 30–59 days
+10 headcount inside the core band
+10 product in market 3+ years
等级:A ≥ 95 · B 75–94 · C < 75。
空白字段不代表平均分。 缺少成立日期的公司会在不知不觉中少得 10 分。这是正确的——未知情况不能视为正常——但要说明哪些行受到了分数上限限制,以免把数据不足导致的低分误认为匹配度低导致的低分。
发布前核实引文
对 legacy 使用正则会产生误报。某次运行中的真实示例:“building a legendary legacy”,以及营销前言中的“access should not be limited by legacy systems”。大约七分之一的引文都是噪声。
提取匹配位置附近的一个句子,限制在 260 个字符以内,并将其放入 proof_snippet 列。将名单交给数据补充流程前,必须有人亲自查看这一列。每个账户花 10 秒。
输出
CSV,每家公司一行:
rank · score · tier · company · domain · headcount · industry · founded · hq · open_roles · days_open · target_role · proof_snippet
同时报告:提取的原始行数、剔除的行数及原因、员工人数中位数、成立年份中位数、包含已核实引文的公司数量,以及总支出。
要求
| 集成 | 用途 | 必需? |
|---|---|---|
| Apify MCP | ATS 招聘网站上的职位信息 | 是 |
| Python 3 | 筛选和评分脚本 | 是 |
| BuiltWith / Wappalyzer | 技术栈信号,可选的第二轮筛选 | 否 |