build-list

说明

设置状态。 尚未为此组织配置。加载一次 Readme 子页面，以获取组织默认的列计划、数据源优先级顺序和激活默认值。（设置完成后，通过 swan-update-skill 重写此段落，以便后续运行能读取当前配置并跳过重新检查。）

---

心智模型——列阶梯

每次名单构建都是一张表。每列有四个属性：

1. 输入 — 读取哪些更早的列。
2. 成本层级 — 免费筛选 / 免费淘汰 / 低成本数据补充 / AI 调研 / 付费联系人数据。
3. 运行条件 — 由哪个上游布尔门控条件控制（几乎总是 icp_pass）。
4. 回退值 — 无法解析时写入什么。

你不会“搜索并想办法处理结果”。你要编写列计划、展示给用户，然后运行它。低成本筛选会淘汰最多的行；只有通过筛选的行才会进入高成本列。

---

步骤 0 — 明确需求，对模糊之处提出质疑

在调用任何工具之前，按目标对象 + 内容 + 原因 + 规模重述需求：

• 目标对象 — 哪个 ICP 细分领域 + 哪些角色。如果组织有多个细分领域，而用户尚未选择，请询问。
• 内容 — 哪些约束是硬性要求，哪些只是偏好。
• 原因 — 采用哪种拓客方式（冷启动批量触达、ABM、信号触发、活动跟进、竞品替换）。
• 规模 — 目标行数。

如果需求与组织保存的 ICP 细分领域相矛盾，要明确提出质疑。 如果组织向工程团队销售可观测性产品，而用户却说“帮我找一份俄亥俄州的牙医名单”，不要默默照办——请指出这一点，并询问这是有意尝试非 ICP 实验，还是误操作。

如果需求是“很多可能需要 X 的 SaaS 公司”——这不算明确的需求。请询问具体的细分领域、规模范围和信号。

---

步骤 1 — 先估算受众规模

在完整拉取数据之前，务必先使用 size: 1 运行规模估算调用，以低成本了解受众数量。使用 swan-fetch-businesses 并传入候选筛选条件和 size: 1；读取 total 字段。

• 如果受众少于 50 家公司——继续之前，先告知用户。细分市场通常需要放宽筛选条件，或改用完全不同的数据来源路径（Apify 目录、网络调研），而不是反复重试同一个查询。
• 如果受众超过 5,000 家公司——说明需求过于宽泛。拉取任何数据之前，先请用户收紧筛选条件。

先估算规模，可以避免调用 20 次工具后才发现细分市场根本没有受众。

---

步骤 2 — 编写列计划并展示给用户

开始数据采集之前，先起草列阶梯。使用此模板——填入与拓客方式相关的列，移除该方式不需要的列：

INPUT  (free preview)
  domain, name, employee_band, industry, geo, linkedin_url

FREE ELIMINATION  (0 credits — pure code/formula filters)
  ✗ dedupe_keep         — drop duplicate domains (normalize www, lowercase)
  ✗ in_geo              — hard-filter geo from the preview field
  ✗ in_size_band        — re-filter employee count to the user's exact threshold
  ✗ not_in_crm_active   — drop companies/contacts already in active sequences
  ✗ name_sniff_test     — cheap LLM scan on name+domain: "plausibly fits the brief?"
  → icp_pass = AND(all of the above)

CHEAP ENRICHMENT  (~1 credit each — only IF icp_pass)
  + enriched_headcount  — swan-enrich-company (precise headcount, not band)
  + enriched_hq_city    — confirm geo at city, not state level
  + enriched_tech_stack — if motion depends on technographic signal
  → icp_pass_strict = AND(icp_pass, enriched columns confirm)

AI RESEARCH COLUMNS  (LLM tokens — only IF icp_pass_strict)
  Each column = ONE delegated sub-agent answering ONE narrow question.
  + sells_dtc           — "Does {domain} sell direct-to-consumer? yes/no/unclear"
  + has_signal_X        — "Does {domain} show signal X? yes/no/unclear"
  → research_pass = AND(icp_pass_strict, sells_dtc=yes, ...)

TIER  (0 credits)
  + tier                — A/B/C/D from research_pass + signal strength
  → drop tier=D before any contact work

PEOPLE DISCOVERY  (free preview — only IF tier ∈ {A,B,C})
  + contact_rows        — swan-search-employees, filtered to persona(s)
  → people_pass = persona match + LinkedIn URL present

CONTACT ENRICHMENT  (paid — only IF tier ∈ {A,B} AND people_pass)
  + verified_email      — email waterfall: cheapest → next → coalesce → verify
  + phone               — A-tier only, only if cold-call motion exists

ACTIVATION  (only after explicit user approval of size + cost)
  → save as Swan list, tag with segment + source
  → A-tier: priority outreach (sequence or direct push)
  → B-tier: standard nurture
  → C-tier: low-touch / content

运行之前，先向用户展示此表。 明确确认列和 icp_pass 的定义。现在花 30 秒澄清，可以避免之后数小时的错误数据补充。

---

第 3 步 — 执行筛选流程

按列从上到下执行。候选池一旦超过约 50 行，就切换到 swan-execute-code——将预览结果导出到文件，按规范化后的域名合并，并将每一列作为一次代码处理步骤运行。不要在对话上下文中处理数百行数据。

避免最常见失败的服务调用规则：

• 对类似枚举的筛选值（行业、地点、规模区间），始终先调用 swan-autocomplete-business-filter，再调用 swan-fetch-businesses。猜测枚举值会导致无提示的 0 条结果或 422 错误。执行记录中，10000+ 与 10001+ 不匹配——先调用自动补全，并逐字复制返回值。
• 在多工具计划开始时，用 swan-load-tool-schemas 加载一次工具架构，并逐字复制枚举值。不要改述。
• 使用多个数据源以扩大覆盖范围：一个数据源约覆盖 TAM 的 60%，两个约覆盖 85%，三个约覆盖 92%。默认顺序：Swan 原生预览 → CRM 中已关闭且失败 / 已流失 / 不活跃的记录 → 只有前两个数据源存在明显缺口时才使用专业数据源（Apollo / Apify）。同一服务商使用不同筛选条件不算多个数据源。
• 先找公司，再找人员。 不要一开始就进行宽泛的人员搜索，例如“在 SaaS 公司任职的销售副总裁”。先建立公司集合，再查找这些特定公司的人员。

---

第 4 步 — 免费筛除最重要

获取数据后、进行任何付费调用前，先用代码执行免费筛除：

1. 按域名去重。 规范化域名（去掉 www. 并转为小写），然后删除重复项。
2. 严格重新筛选预览字段。 如果用户要求“20 名以上员工”，而预览显示的区间是“11-50”，该区间存在歧义——要么删除该记录，要么标记为需要通过数据增强确认。绝不要把宽泛的预览区间当作达到硬性门槛的证明。
3. 确保地理位置精确。 州不等于城市。如果用户要求旧金山，而预览返回的是州级匹配项，应将其标记为需要通过数据增强确认，不要计为符合条件。
4. 与 CRM 交叉核对。 删除已处于活跃序列或近期尚未关闭的商机中的记录——重复触达会损害邮件送达率。
5. 进行低成本 LLM 快速检查。 用一次简短的 LLM 检查名称和域名，判断“这一行是否可能符合要求？”零积分成本即可剔除明显的噪声记录（吉他商店、花店）。

这一步会剔除池中 60–80% 的记录。这是整个流程中节省积分最多的一步。 跳过此步骤，直接进行数据增强，是成本最高的失败模式。

---

第 5 步 — 将 AI 调研列作为委派的子 Agent

每个 AI 调研列都通过一次 swan-delegate-to-sub-agents 调用，针对单条记录回答一个范围明确的问题。不要把“是否为 DTC、是否在旧金山、是否销售电气产品”合并到一个提示词中——这应该是三列。

子 Agent 提示词模板：

Visit {domain}.
Answer ONE question: {specific_question}.
Look at: {specific_pages — homepage, /about, /shop, /products}.
Return one of: yes / no / unclear.
If the site is down or you cannot determine, return: unclear.
Do not guess. Do not infer from general language.

规则：

• 只对通过 icp_pass 的记录运行。绝不要委派调研整个候选池。
• 先用 10 条记录试运行。如果 80% 以上的结果是“不明确”，说明问题不对——扩大范围前先重写。
• 使用可行方案中成本最低的模型。将昂贵的推理留给真正需要判断的情况（ICP 匹配度、客户痛点推断）。
• 始终包含备用值（“不明确”），以免无法访问的页面导致整列报错。

---

第 6 步 — 分级，然后查找联系人

分级规则：

• A — 符合 ICP，且有活跃信号（融资、招聘、意向、新闻）。
• B — 符合 ICP，但没有活跃信号。
• C — 部分符合 ICP，值得持续培育。
• D — 不符合 ICP。立即删除。

在查找联系人之前先删除 D 级记录。然后运行 swan-search-employees（免费预览），按第 0 步选定的角色筛选。每种推广方式的联系人数量上限：

• 冷启动群发 / 单线程序列：每家公司 1 名联系人。
• ABM / 多线程：3–5 名，覆盖采购委员会中的不同角色。

---

第 7 步 — 对关键目标执行邮箱瀑布式匹配

仅针对 A/B 级联系人。按顺序执行瀑布式匹配：最便宜的服务商 → 下一家 → 合并结果 → 验证。

• 先使用 swan-enrich-email 调用最便宜的服务商；只有未命中时才回退到下一家。
• 超过 20 行时，通过 swan-execute-code + output/actions.json 批量处理。每批最多 50 个操作。
• 合并后再验证，切勿在合并过程中验证。剔除 invalid。将 catch_all 视为有风险——只有用户接受送达率下降时才纳入。
• 在激活前剔除基于角色的邮箱（info@、support@、hello@、admin@、contact@）。

仅针对 A 级联系人补充电话号码，且仅在存在冷呼叫策略时进行。

---

第 8 步 — 去重、显示成本并激活

• 在公司层级按标准化域名去重。
• 在个人层级按已验证邮箱去重；没有时再按 LinkedIn URL 去重。
• 与 CRM 交叉核对：剔除已在活跃序列中的联系人。
• 向用户显示：列表大小、级别分布、列完整度、预计积分成本。 等待用户明确批准。
• 获得批准后，将其保存为带有细分市场 + 来源标签的 Swan 列表。按组织的默认激活设置进行分流：
  • A 级 → 优先触达（构建序列或直接推送）。
  • B 级 → 标准培育。
  • C 级 → 低触达 / 内容。

只有在列表已保存或用户明确放弃后，这项技能才算完成。不要在尚未创建列表对象时以“要我继续吗？”结束。

---

通用规则

1. 没有 icp_pass = true，就不添加付费列。 每个付费补充数据列都必须有明确的运行条件布尔值。
2. 先确定规模，再开始搜寻。 第一次调用始终是 size: 1 的受众检查。
3. 先找公司，再找联系人。 切勿从宽泛的联系人搜索开始。
4. 先自动补全，再搜索。 执行抓取前，先验证类似枚举的筛选值。绝不猜测枚举值。
5. 先应用最便宜的筛选条件。 免费筛除列会在消耗任何积分前淘汰 60–80% 的对象池。
6. 每个 AI 列只回答一个问题。 每个委派的子 Agent 都只回答一个范围明确的问题。
7. 对任何新的 AI 列或数据补充服务商，先用 10 行进行试点，再扩大规模。
8. 运行前向用户展示列计划。 激活前显示规模 + 成本。
9. 如果需求与已保存的 ICP 相矛盾，就提出异议。 指出不匹配之处，不要默默照办。

---

反模式

• 用不同的筛选组合并行运行四次 swan-fetch-businesses，然后称之为“多来源”。同一服务商、不同筛选条件 = 一个来源。
• 对 companySize 等枚举值跳过 swan-autocomplete-business-filter。这会导致 422 错误，但错误不会明显显示。
• 将 11-50 的预览范围视为符合“员工人数超过 20 人”。返回预览结果后，必须重新应用硬性阈值，或通过数据补充进行确认。
• 用户要求按城市筛选时，却让州级匹配通过。
• 应用免费筛除条件前就对整个对象池进行数据补充。这是此技能中最大的积分浪费。
• 将“是否为 DTC AND 位于 SF AND 销售电气产品”合并成一个 AI 研究提示词。这应该是三列、三个子 Agent。
• 在没有保存列表时以“要我继续吗？”结束。只有在完成激活或用户放弃后，这项技能才算完成。
• 对与组织已保存的 ICP 细分市场相矛盾的需求，默默照办。

---

优秀实践的标准

• 在任何搜寻调用前，用户都能看到列计划和 icp_pass 布尔值的定义。
• 首先调用一次 swan-fetch-businesses，并使用 size: 1 确定受众规模。
• 在消耗任何积分前，免费筛除条件会淘汰 60–80% 的对象池。
• 每个付费列都有引用上游布尔值的运行条件。
• 每个 AI 研究列只回答一个问题；扩大规模前先用 10 行进行试点。
• 最终摘要显示规模、级别分布、列完整度和积分成本。用户明确批准。
• 最终存在一个 Swan 列表对象，带有细分市场 + 来源标签，并按默认激活设置进行分流。

---

此技能将扩展的细分子页面

由组织在实际执行各项营销行动时添加，不会一次性全部添加。

• LookalikeFromWon — 列出与已成交客户相似的对象。
• CompetitorCustomers — 某个指定竞争对手的疑似客户。
• EventAttendees — 将参会者名单转换为补充了信息的外联名单。
• JobPostingSignal — 正在招聘特定职位的公司。
• FundingSignal — 近期获得融资的公司。
• LocalBusinesses — 本地 / SMB 目标对象（类似 Maps 的信息搜集）。