用途
Hiring Radar 用于把目标账户的招聘信息当作购买信号来监控。它的定位是持续、每日运行的检测机制：监控已关注账户的职位发布，以及任意公司中匹配追踪查询的职位描述，识别出有 GTM 意义的招聘模式，并输出带日期的证据、逐条信号提醒和一份对账摘要。该技能明确只做检测、分类与提醒，绝不起草、排队或发送外联。
其基本判断是：招聘即可见的预算。今天正在组建的团队，意味着本季度正在做出的工具采购决策。
主要能力
两类独立扫描（不可混淆）
- 关注列表扫描：由已关注账户发布的职位，按公司过滤。
- 提及扫描：任意公司中匹配追踪查询的职位，查询可以是职位名称（如「data engineer」）、JD 中的技术（如「SharePoint」），或两者组合（如「administrator」+ 你的平台）。JD 中提到某关注公司，并不等于该公司自身的招聘信号。
GTM 相关性阈值（仅保留符合条件的模式）
- 招聘热潮：同一团队新增 3 个及以上职位，指向当下正在做出的工具决策。
- 买家画像招聘：针对你所销售对象的「first」或「Head of」级别招聘，意味着一位带着 90 天议程的新负责人。
- 自建与购买信号：JD 描述要自建你所销售的东西，意味着有预算、无人员、仍然开放。
- 采购委员会高管招聘：其第一个季度会决定什么留下。
- 竞品工具要求在 JD 中出现：替代情报。
- 你的产品要求在 JD 中出现：交给客户成功负责人的客户信号。
单条职位、仅含品类词的提及、长期挂出和重复发布的职位会被剔除。只有发布日期真实，模式才算成立。
解析与门控：解析代理发布职位背后的真实雇主，否则剔除；将提及扫描的结果门控到 ICP，非 ICP 在此作为日志条目终止，绝不升级为提醒。
去重与抑制台账：检查账户记忆中「Last hiring signal: YYYY-MM-DD（模式）」。同一模式在 30 天内不重复提醒，新的职位作为证据附加。活跃交易绝不以新信号再次提醒，而是标记为「活跃交易上的温热信号」交给交易负责人。每个处理或跳过的账户都写入台账备注及原因。
读取、记录与提醒：阅读存活的 JD，提取具名工具、团队规模线索、汇报线、痛点语言，将这些词连同来源扫描、类别、职位、发布日期和链接记录到账户记录中。然后向信号渠道发送每条信号一条消息，包含账户、带日期链接的模式、可能的后果负责人，以及一行含义说明。一个模式对应一条提醒，无论多少职位支撑它，且仅在发布日期 14 天内有效，更早的招聘是背景而非新闻。
运行摘要：每次运行以一条摘要收尾：拉取 X 条职位 → 分类 Y 个模式 → Z 条提醒 → 跳过及原因。若全部关注账户连续三次运行零职位，则视为索源故障而非市场沉默，需核实后才能上报。
使用方式
该技能为每日运行。设置状态：目前尚未为此组织配置。在安排计划前，需先配置账户关注列表（A 级每日、其余每周）、提及扫描查询（竞品与自有产品、关注的职位名称）、信号渠道，以及自有域名排除项。连接器的配置维护在 job-board-sourcing-and-actor-schemas.md 中。设置完成后应重写文档中的设置段落以描述当前配置。
运行流程分六步：拉取新职位（两类扫描）→ 仅保留 GTM 相关模式 → 解析与门控 → 去重与抑制台账 → 读取、记录、提醒 → 摘要。
适用场景
适用于需要以招聘活动作为购买信号参考的 GTM 场景，例如监控目标账户正在组建什么团队、发现新负责人上任、识别自建与购买的取舍、追踪竞品工具要求，或捕捉自有产品出现在 JD 中的客户信号。
限制
- 仅做检测、分类与提醒，绝不进行外联。
- 拉取 LinkedIn 职位必须仅通过原生集成，绝不使用第三方抓取器；其他招聘板各使用一个经过审核和试运行的 apify 抓取器。
- 单条职位、仅含品类词的提及、长期挂出与重复发布不构成信号。
- 提醒仅在发布日期 14 天内有效；同一模式 30 天内不重复提醒。
- 非 ICP 的提及发现不会升级为提醒。
- 未配置前无法按计划运行；当前该组织尚未完成配置。
优化
运行 3 至 6 周后，读取台账与摘要：每周信号数、14 天窗口内被行动的占比、无主净新账户上的占比。剔除无人行动的模式类别与查询，建议拓宽设置短语与来源。若提醒超出销售代表处理能力且净新占比高，可在第五步扩展一个「起草待审」分支，但雷达仍然绝不发送。