signal-research

Signal Research —— 将静态账户库转化为实时、有日期、有证据的信号列表

公司特征信息库能告诉你哪些账户符合条件，却无法告诉你何时联系。本技能填补这一空白：它基于你已有的信息库，逐个账户回答：“当前是否有有效触发信号？证据是什么？距今有多久？”

两种运行模式：

• 完整运行 —— 信息库从未做过信号研究。
• 增量运行 —— 信息库之前做过研究；重新扫描已失效和新出现的信号。大多数信息库约 45 天就会过时，但没人察觉，因为状态列一直显示“Hot”。

设置（每个会话一次）

动态解析安装目录——切勿硬编码：

1. 搜索 **/signal-research/SKILL.md
2. 该目录即为 SKILL_BASE；资源位于 {SKILL_BASE}/resources/...

按此顺序加载：

1. 如果工作区中存在 clients/<client>/icp.md 和 clients/<client>/signals.md，则加载它们——客户自己的信号层级、检测路径、地理位置来源表和开放数据陷阱始终优先于本技能中的任何通用内容。
2. {SKILL_BASE}/resources/signals-catalog.md —— 信号库：收录 60 项信号，涵盖账户事件与新闻、招聘、技术变更、个人层面的活动、项目流程和建设意向，以及垂直行业资料包和数据点系列（通用 D，以及各垂直行业的 DV / DA）。每项都包含检测路径、时效窗口和配对说明。如果客户还没有 signals.md，请使用此目录——应扩展目录，而不是临时编造信号。
3. 可选，已安装时使用： agency-signal-sourcer（位于 gtm-skills 仓库）提供更深入的逐信号工具表，其中包含积分成本、衰减窗口和热度层级 SLA。若未安装，使用本技能 resources/ 中的检测阶梯和目录也足以完成工作。

如果以上内容均不存在，请停止并说明情况。不要在此处编造信号列表。

硬性规则

1. 没有证据，就没有信号。 每个非空的 signal_type 都必须附带一个有效 URL 和日期。无法提供链接的信号，应记为 none 并注明原因。看似合理的推断是污染信息库最快的方式。
2. 记录检测日期，而不是运行日期。 signal_date = 事件发生的时间（发布日期、许可证签发日期、获奖日期）。signal_age_days = 运行日期 − signal_date。如果来源只写“3 周前发布”，则记录推算出的日期，并将 signal_date_precision = approx。
3. 优先使用成本最低的来源。 按 resources/detection-ladder.md 中的阶梯逐级查询。免费批量查询已能给出答案的账户，绝不要消耗付费积分。
4. 研究前先筛除。 先执行反向 ICP 和地理位置／规模筛选，只研究筛选后留下的账户。研究筛除掉的账户，是这项工作成本超出应有水平 3 倍的最常见原因。
5. 每家公司对应一行信号，联系人单独处理。 信号研究在账户层面进行。联系人扩展（每家公司 2–3 人）应在之后的列表步骤中完成。
6. 过期不等于不存在。 超出时效窗口的信号应降级为数据点（仍能为沟通提供信息），并将该账户加入重新扫描队列——不得悄然删除。
7. 保密。 绝不要将某个客户的账户名称、证据或列表带入另一个客户的产物中。

阶段 0 — 信息收集与基础标准化

只询问缺失的信息：

• 基础数据的路径／链接，以及它所属的客户端。
• 运行模式：完整运行或增量运行（如果基础数据已有 signal_date 值 → 建议增量运行）。
• 地理范围和任何批次上限（“仅 Tier A / NY / 前 200 条”）。

然后进行标准化，写入值而非公式：

• row_id、company_name_raw、company_name_clean、domain、country、geo_bucket、city、 industry — 规范化公司信息块。
• 按域名去重；域名缺失时，按清理后的名称 + 城市去重，并标记 match_method。
• 应用 filter_geo / filter_size / filter_anti_icp → filter_result，并为每条排除记录填写 exclusion_reason。报告漏斗：原始数据 → 去重后 → 范围内数据。

在开始检测前报告保留记录数；如果数量意味着实际成本，先征得确认。

阶段 1 — 信号计划（决定成本的环节）

选择 4–7 个信号，不得更多。对每个信号，在计划表中填写一行：

信号	层级	来源／途径	每 100 条的成本	时间窗口（天）	预期命中率

选择规则：

• 至少两个必须是可批量检测的信号 — 一次查询覆盖整个基础数据（开放数据 API、 招标信息源、新闻信息源、平台职位发布筛选）。这些信号承担主要检测任务。
• 最多两个可以是逐个账户手动检测的信号（招聘页面、网站新闻）。这些是成本较高的补充检测。
• 如果某个信号与此 ICP 的匹配度较低，就应将其删除，即使它很有名也不例外。在承包商／服务类垂直行业中，融资轮次几乎不会触发；招聘则对所有公司都会触发。
• 没有现实可行检测途径的信号不得列入计划。改为在报告的“想要但无法检测”部分注明。

运行前展示计划和预计成本。

阶段 2 — 检测，分三轮进行

完整机制、关联规则和来源类型陷阱：{SKILL_BASE}/resources/detection-ladder.md。

A 轮 — 批量来源（覆盖整个基础数据）。 每个来源进行一次查询，然后按名称／域名与基础数据关联。记录 match_method（domain、exact_name、fuzzy_name+city、manual）。 对基础数据中自身名称的模糊匹配是误报的主要来源 — 抽查 10 条。

B 轮 — 逐个账户的网络研究。 仅针对范围内且 A 轮未命中的账户。每个并行研究 Agent 批量处理 10–15 个账户；每个 Agent 必须严格返回以下内容：公司、信号类型、一行证据、URL、日期，或明确的 none。指示 Agent 将 none 视为正确且预期的答案，否则它们会为每一行都编造一个信号。

C 轮 — 平台筛选。 对剩余账户使用 Apollo / LinkedIn / Sales Nav / 意向工具，且仅限通过匹配度门槛的账户。请注意，根据 GDPR，人员级跟踪仅适用于美国 — 针对欧盟目标，请使用公司级识别。

每轮结束后记录产出：已扫描账户数、命中数、成本。如果在此规模的基础数据上，某轮的产出率低于约 5%，应如实报告，不要悄悄扩大规模后重复运行。

第 2b 阶段 — 在同一轮中采集数据点

某个信号只会出现在基数的 3–5% 中，而几乎所有账号都能找到数据点。两者应一并采集， 否则经济效益根本无法成立：B 轮已经抓取了账号的页面，之后再爬一次来收集事实， 就是为相同的数据付了两次钱。

两者并非同一回事，不能共用一列：

	信号	数据点
定义	有日期的事件	长期有效的事实
决定什么	何时撰写	写什么
覆盖率	基数的 3–5%	基数中的大多数
过期方式	有有效期，之后失效	不会过期——这正是数据点的意义
需要什么	URL 和日期	来源页面，无需日期

值得采集的类型，大致按其对信息内容的影响从高到低排列：账号内部具备的能力 · 他们提及的设备或工具 · 软件技术栈 · 规模（数量、大小、计数）· 服务过的知名客户或行业。行业组合最弱——每个网站都有，几乎无法提供个性化信息。

降低噪声的提取规则。 这些规则都是从实际运行中付费学来的：

• 只有数字旁边有相关词时，它才表示数量。 要求图中数字前后约 70 个字符内有领域动词或名词， 否则爬虫会一本正经地把“向西 20 英里”返回为项目规模。
• 提取匹配项周围的字符窗口（前后各约 150 个字符），而非整句。 按句子拆分会把导航菜单和 Cookie 横幅带进引文。
• 营销承诺不代表痛点。 宣传快速交付的页面是在宣称自身优势，并不能证明他们在交期方面遇到困难。 用这种方式检测“对时间安排的抱怨”行不通——应直接舍弃，而不是记录噪声。
• 数据点仍然需要来源 URL，即使没有日期也一样。没有它，发送前就无法核实开场白， 而 hook_source 会保持为空，导致该行无法通过。

队列 D——没有有效信号的账号——完全依赖这轮采集。如果跳过数据点采集， 队列 D 就没有开场白，营销活动也会悄无声息地变成群发邮件。

第 3 阶段 — 评分与热度分级

使用客户自己的公式，见 clients/<client>/signals.md。如果没有，则默认使用：

score = fit (High 60 / Med 35 / Low 10)
      + signal_tier (T1 40 / T2 25 / T3 10)
      + capability gap (+10 gap present or unknown / −10 they already do it in-house)

• 信号叠加： 第二个独立信号加 +10，第三个加 +5——绝不再增加一个完整等级。 同一事件产生的两个事实（关于某职位的招聘信息和相关新闻稿）只算一个信号。
• 时效性乘数： 在有效期前半段内 ×1.0，后半段 ×0.7，超过有效期 ×0.3。
• 按客户的阈值划分为 Hot / Warm / Cool / Drop，并为每个等级设定 SLA（Hot = 48 小时内联系，否则研究就白费了）。

第 4 阶段 — 新鲜度与重新扫描队列

为每个已评分账号写入 signal_expires_on = signal_date + window 和 rescan_due = min(expires_on, run_date + 30d)。

增量运行：

1. 重新加载上一轮输出，并将 signal_expires_on 与今天比较。
2. 已过期 → 将信号详情移入 datapoint_type / datapoint_detail，清空信号区块， 将 status 设为 burnt。
3. 仅对已失效和从未出现过信号的账号重新运行第 2 阶段。
4. 输出变更表：新出现的信号、已失效、再次出现的信号、仍然没有信号。该表才是增量运行的 实际交付内容——而不是再次输出整个文件。

阶段 5 — 输出

始终包含两项成果。

1. 增强后的列表（CSV，扁平格式，单个表头，值而非公式）。 保留所有输入列，并添加标准信号字段组：signal_type · signal_score · signal_route · signal_evidence_url · signal_date · signal_age_days · signal_summary · signal_2_type · signal_2_url · signal_3_type，以及 datapoint_type · datapoint_detail，还有本技能自带的 signal_expires_on · rescan_due · signal_date_precision · match_method · detected_by · detected_on。完整规范和值词汇表见： {SKILL_BASE}/resources/output-spec.md。将完整基础列表（包括剔除项，每项都附带原因）和工作切片作为两个文件提交，列保持一致。

2. 覆盖报告。 结构和措辞见：{SKILL_BASE}/resources/report-template.md。报告必须说明信号来源产出排名（各来源产生了多少条信号、成本如何）、未产生结果的信号及其保留／淘汰判定、仍无法检测到的内容及原因，以及重新扫描日期。只报告“找到 37 个高意向账户”的运行结果，会掩盖方法是否可重复。

如果工作区将客户端结果存储在 Notion 中，列表仍须是 CSV，报告则应整理成易读的页面——数据库转储加上看板链接并不算报告。

交接

下一个问题	技能
哪种信号 × ICP × 方案值得测试	hypo-generator (gtm-skills) / hypothesis-builder
哪种工具能检测信号 X，成本多少、何时失效	agency-signal-sourcer
基础列表太小／去哪里找更多账户	niche-data-finder、data-research、account-sourcing
将评分后的账户整理成包含联系人和文案位置的完整潜客列表	prospect-list-run
根据这些信号撰写序列	sequence-writer
每个账户的触达前简报	prospect-profiler

已经踩过的检测陷阱

• 职位招聘页面上团队成员的电子邮件签名会被误读为开放职位。
• “我们目前没有任何职位空缺”会漏过空页面筛选，被记录为页面没有结果，而不是明确的否定。
• 在线页面上挂着的旧招聘信息看起来像是最新的。应记录招聘信息的日期，而不是页面日期。
• 聚合网站会将已关闭的招聘信息副本保留数月。只在聚合网站上存在的招聘信息应视为已过期。
• 职位招聘页面不等于职位列表。大多数公司会跳转到外部招聘网站——应跟进链接，否则你会把有 5 个职位空缺的公司记录为“没有职位空缺”。
• /partners 或 /white-label 页面通常意味着需求恰恰相反：他们在销售这项服务。评分前先读清措辞的指向。某次运行中，所有找到的此类页面都属于竞争对手，而非潜在客户。
• 反向信号必须单独存放在自己的文件中，并对所有账户进行检查，包括已被排除的账户。如果一次运行只读取未排除的行，就不会重新检查已筛除的竞争对手，排除筛选会失效，竞争对手就会重新进入基础列表。
• 通过通用搜索查找新闻不适用于员工人数为 10–500 人的公司：一次对 168 个候选对象的检索，结果包括安全奖项、奖项页面、合同登记信息和社交媒体帖子，准确率不到三分之一。应使用专用信息源和门户。

实际运行中出现过的失败模式

• 信号来自无法购买的公司。 适配度筛选必须在检测之前运行，而不是之后。
• 某个地区整体未被覆盖，却无人察觉。 开放数据覆盖范围按城市划分，而非全国范围。应按 geo_bucket 报告覆盖情况；空桶也是发现结果，而不是留白。
• 日期字段不可信。 公共数据集可能包含格式混杂的文本日期、占位年份（9999、3030），以及从不更新的新鲜度元数据。在信任任何 max() 或降序排序之前，先用明确的近期值筛选并验证最新一行。
• 基础列表逐渐过时，却无人重新扫描。 如果没有安排增量扫描，两个月内评分列就会变成虚构数据。设置 rescan_due，并在报告中明确写出。