从会议/活动讲者页面挖掘符合 ICP…

当你想从某个会议、活动或赞助商页面的讲者名单中找出值得 AE 联系的潜客时使用。

适用场景

解决思路

1. 准备环境：设置 BROWSERBASE_API_KEY 环境变量并安装 browse CLI（npm install -g browse）；API 调用用 browse cloud ...，JS 渲染较重的讲者页面用 browse open / browse get markdown。
2. 路径规则：所有 Bash 命令中一律使用完整字面路径，不要用 ~ 或 $HOME（会触发 shell expansion 审批提示）；先解析一次 home 目录然后到处复用；构造子代理提示时把 {SKILL_DIR} 替换为完整字面路径（通常为 /Users/jay/skills/skills/event-prospecting）。
3. 输出目录：所有输出写入 ~/Desktop/{event_slug}_prospects_{YYYY-MM-DD-HHMM}/；最终交付物是 index.html（按公司分组、按公司 ICP 排序），另有 companies.html 和 people.html（可筛选）作为备选视图，以及 results.csv 用于冷启动外呼导入。
4. 工具限制（主代理和所有子代理都适用）：所有网页搜索用 browse cloud search，绝不用 WebSearch；所有页面内容提取用 node {SKILL_DIR}/scripts/extract_page.mjs "<url>"（该脚本通过 browse cloud fetch --output 抓取，解析 title + meta 标签 + 可见正文，抓取失败或返回稀薄 JS 渲染内容时自动回退到 browse get markdown），绝不手写 browse cloud fetch | sed 管道，绝不用 WebFetch；所有研究输出由子代理用 bash heredoc 写入 {OUTPUT_DIR}/companies/{slug}.md 或 {OUTPUT_DIR}/people/{slug}.md（每公司或每人一个 markdown 文件），绝不用 Write 工具或 python3 -c；报告编译用 node {SKILL_DIR}/scripts/compile_report.mjs {OUTPUT_DIR} --open；子代理只能使用 Bash 工具，不允许其他工具；硬性工具调用上限：ICP 初筛 = 每公司 1 次调用，深度研究 = 每公司 5 次调用，人物补充 = 每人 4 次调用。
5. 反幻觉规则（主代理和所有子代理都适用）：绝不从网站的字体、框架、设计系统或排版推断 product_description、industry 或某人的 role_reason；绝不让用户自己的 ICP 泄漏进目标描述，不知道目标做什么就写 Unknown，不要往 ICP 上套；product_description 必须引用或转述 extract_page.mjs 输出中的具体短语，若 TITLE/META/OG/HEADINGS/BODY 都没有可识别的产品陈述，就写 Unknown — homepage content not accessible 并把 icp_fit_score 上限设为 3；某人的 hook 必须引用或转述 browse cloud search 结果中的具体发现（播客标题、博客标题、GitHub 仓库、演讲摘要），若近 6 个月无公开信号，则回退到活动上下文（其在本活动的演讲标题）。
6. 减少权限提示：子代理必须把所有文件写入合并到单次 Bash 调用中，用链式 heredoc 完成（一次 Bash 调用 = 一次权限提示）；把所有搜索和抓取用 && 链接合并到单次 Bash 调用中。
7. 按顺序执行 10 步流水线，不跳步不重排：0 设置（输出目录 + 清空旧状态）；1 加载 profile（读取 profiles/{user_slug}.json）；2 侦察（检测活动平台）；3 提取人物（people.jsonl）；4 按公司分组（seed_companies.txt）；5 ICP 初筛（快速公司级打分，每公司 1 次调用）；6 过滤（保留 icp_fit_score >= --icp-threshold 的公司）；7 深度研究（对 ICP 匹配公司做完整 Plan→Research→Synthesize）；8 补充讲者（询问用户：仅 ICP 匹配（默认）还是全部讲者）；9 编译报告（HTML + CSV，在浏览器打开）。
8. Step 0 设置输出目录：从用户给的 URL 推导输出目录，不要硬编码任何活动名；用 node -e 从 EVENT_URL 提取 hostname 去掉 www 后取第一段作为 EVENT_SLUG，用 date +%Y-%m-%d-%H%M 生成 TIMESTAMP，OUTPUT_DIR=/Users/jay/Desktop/${EVENT_SLUG}_prospects_${TIMESTAMP}，mkdir -p "$OUTPUT_DIR/companies" "$OUTPUT_DIR/people"；用完整字面 home 路径，绝不用 ~ 或 $HOME；把所有子代理提示中的 {OUTPUT_DIR} 替换为完整字面路径。
9. Step 1 加载用户 profile：profile 定义 ICP，ICP 初筛和深度研究都据此打分；从 {SKILL_DIR}/profiles/{user_slug}.json 加载（与所有 GTM 技能互通，形状同 company-research）；example.json 是模板不是真实 profile，绝不用；不要到 {SKILL_DIR}/profiles/ 之外找 profile；解析顺序：若用户用 --user-company <slug> 调用则用该 slug；否则列出 profiles/*.json 排除 example.json，若只有一个就用它（并告知用户），若有多个则用普通聊天询问用户选哪个；若一个都没有则大声失败并提示用户创建（复制 profiles/example.json 到 profiles/<your_slug>.json 并填写，或运行 company-research 技能自动生成）；profile 产出 company、product、icp_description、existing_customers，这些要原样嵌入下游每个子代理提示。
10. Step 2 侦察：运行 node {SKILL_DIR}/scripts/recon.mjs {EVENT_URL} {OUTPUT_DIR}，写入 {OUTPUT_DIR}/recon.json，含 platform、strategy，以及（对 Next.js）nextDataPaths；参考 references/event-platforms.md 的平台目录和检测优先级；预期结果：Stripe Sessions 类（Next.js）为 platform: "next-data" 1-3 个路径，Sessionize 为 platform: "sessionize"，Lu.ma / Eventbrite 为 platform: "luma" | "eventbrite"，其他为 platform: "custom" strategy: "markdown"（尽力回退）。
11. Step 3 提取人物：运行 node {SKILL_DIR}/scripts/extract_event.mjs {OUTPUT_DIR} --user-company {USER_SLUG}；读取 recon.json，分派到平台特定提取器，写入 people.jsonl（每行一个讲者）和 seed_companies.txt（去重公司）；--user-company 标志还会剔除主办方自己的员工（Stripe 主办的活动剔除 Stripe 员工）和用户自己公司的员工，这些不是潜客；用 wc -l 和 head -3 做合理性检查；若 people.jsonl 为空或少于约 10 行，说明侦察选错平台，参考 references/event-platforms.md 调整策略重跑。
12. Step 4 按公司分组：extract_event.mjs 已输出 seed_companies.txt（每行一个公司，去重排序）；本步是信息性的——在分派前用 wc -l 验证数量合理；预期约为讲者数的 0.4-0.6 倍（多数活动平均每公司约 2 个讲者，有些公司派 5+ 个，很多只派 1 个）。
13. Step 5 ICP 初筛：快速通道——每公司一次工具调用，不做深度研究；对 seed_companies.txt 中每个公司按用户 ICP 打分，写一个精简初筛存根到 companies/{slug}.md；icp_fit_score >= --icp-threshold（默认 6）的公司进入 Step 7 深度研究，其余保留为初筛存根；分派模式：把 seed_companies.txt 拆成约 10 个公司一批，在单条消息中一次性扇出 N 个子代理（多个 Agent 工具调用）；每个子代理运行 references/workflow.md → "ICP Triage" 段的提示；硬上限每公司 1 次工具调用（只对主页跑 extract_page.mjs），用 # browse call N/1 注释模式强制执行；用 node -e 构建批次文件（每行 "name|guessed_homepage|slug"，extract_event.mjs 只输出公司名不含 URL，所以 slugify 并猜测 https://{slug-without-spaces}.com 作为规范主页；若猜测 URL 404，初筛子代理允许写 product_description: "Unknown — homepage content not accessible" 并把分数上限设为 3，这是 workflow.md 中记录的 ICP Triage 提示规则 3 的回退；为发现真实 URL 而消耗一次真正的 browse cloud search 会突破每公司 1 次调用的硬上限）；用 split -l 10 拆批；用 ls | wc -l 数批次数 → 要分派的子代理数（每条消息最多 6 个，其余放第二波）；在单条消息中每个批次一个 Agent 调用，替换 {SKILL_DIR}、{OUTPUT_DIR}、{USER_COMPANY}、{USER_PRODUCT}、{ICP_DESCRIPTION}、{EVENT_NAME}（来自 recon.json .title）、{COMPANY_LIST}（批次文件内容）、{TOTAL}（本批次行数，代入 # browse call N/{TOTAL}）；所有子代理返回后验证 seed_companies.txt 中每个公司都有对应 companies/{slug}.md（ls companies/*.md | wc -l 应等于 wc -l seed_companies.txt）；清理批次文件 rm {OUTPUT_DIR}/_batch_triage_*。
14. Step 6 按 ICP 阈值过滤：读取每个 companies/*.md 的 frontmatter，保留 icp_fit_score >= 6（或 --icp-threshold 指定的值）的；把存活的公司 slug 写入 {OUTPUT_DIR}/icp_fits.txt（用 awk 提取 icp_fit_score 并比较）；预期为 seed_companies.txt 的 20-40%；若存活率 < 10%，阈值可能太高或 ICP 描述太窄——向用户发出警告。
15. Step 7 深度研究：只对 ICP 匹配公司做完整 Plan→Research→Synthesize；硬上限每公司 5 次工具调用（主页提取 + 2-3 次子问题搜索 + 1-2 次补充抓取）；子代理用更丰富的深度研究版本覆盖已有的 companies/{slug}.md 初筛存根（frontmatter triage_only: false）；分派模式：把 icp_fits.txt 拆成约 5 个公司一批（deep 模式默认），在单条消息中每批一个 Agent（每条消息最多 6 个）；每个 Agent 用 references/workflow.md → "Deep Research" 的提示，替换 {SKILL_DIR}、{OUTPUT_DIR}、{USER_COMPANY}、{USER_PRODUCT}、{ICP_DESCRIPTION}、{EVENT_NAME}（来自 recon.json .title）、{EVENT_CONTEXT}（track / topic，从活动主页人工推断）、{COMPANY_LIST}（批次文件内容，每行 slug|website）；用 while read 循环读每个初筛存根 frontmatter 构建 {company-slug|website} 对写入 _deep_targets.txt，用 split -l 5 拆批；所有子代理返回后验证深度研究文件存在且 triage_only: false（grep -l "triage_only: false" companies/*.md | wc -l 应等于 wc -l icp_fits.txt）。
16. Step 8 补充讲者：每人收集 LinkedIn URL、近期活动（播客 / 博客 / 演讲 / GitHub / X），写入 people/{slug}.md；硬上限每人 4 次工具调用，三条通道：1) browse cloud search "{name} {company} linkedin"（总是）；2) browse cloud search "{name} podcast OR talk OR blog 2026"（deep+）；3) browse cloud search "{name} github"（deeper）；4) browse cloud search "{name} site:x.com OR site:twitter.com"（deeper，尽力）；quick 模式跳过 Step 8，deep 模式用通道 1-2，deeper 模式用通道 1-4。
17. Step 8a 询问用户补充范围：分派前计算两个候选数量并让用户选择；默认仅 ICP 匹配（更快更便宜，多数用户想要），补充全部讲者是可选加入，因为成本随人数线性增长；用 wc -l 算 TOTAL，用 node -e 读 icp_fits.txt 和 companies/*.md 的 company_name 匹配 people.jsonl 算 ICP_FITS；按 {DEPTH} 设 LANES=2（deep）或 4（deeper）；用 AskUserQuestion 给出两个选项并量化成本（"ICP fits only" 推荐 / "All speakers"）；保存选择为 ENRICH_SCOPE=icp_fits 或 ENRICH_SCOPE=all；若用户选 "All speakers" 且 TOTAL × LANES > 600，打印警告并再问一次——那是 10+ 分钟、数百次工具调用的运行。
18. Step 8b 过滤和分批：按 ENRICH_SCOPE 构建 _people_to_enrich.jsonl（all 则直接 cp people.jsonl；否则用 node -e 读 icp_fits.txt 和 companies/*.md 的 company_name 匹配 people.jsonl 过滤）；用 split -l 5 拆成约 5 人一批；在单条消息中每批一个 Agent 调用（每条消息最多 6 个），用 references/workflow.md → "Person Enrichment" 的提示，包含 {SKILL_DIR}、{OUTPUT_DIR}、{DEPTH}（deep | deeper）、{USER_COMPANY}、{USER_PRODUCT}、{ICP_DESCRIPTION}、{EVENT_NAME}（来自 recon.json .title）、{LANES}（deep 为 2，deeper 为 4，代入 # browse call N/{LANES}）、{PEOPLE_BATCH}（_batch_people_aa 内容，每行是 people.jsonl 的 JSON 记录）；所有子代理返回后验证 people/*.md 存在（ls people/*.md | wc -l 应等于 wc -l _people_to_enrich.jsonl）。
19. Step 9 编译报告：运行 node {SKILL_DIR}/scripts/compile_report.mjs {OUTPUT_DIR} --open；生成 index.html（按公司分组、按公司 ICP 分数排序，在浏览器打开）、people.html（可筛选讲者列表，备选视图）、companies.html（ICP 排序的公司表含参会者）、results.csv（冷启动外呼就绪的电子表格）；然后在聊天中呈现摘要（总讲者数、唯一公司数、ICP 匹配数（score ≥ 阈值）、已补充讲者数、公司分数分布：强匹配 8-10 / 部分匹配 5-7 / 弱匹配 1-4、报告已在浏览器打开路径）；展示按公司 ICP 分数排序的前 5 个人物卡片 markdown 表格，然后提供选项：调整 --icp-threshold 并重跑 Step 6-9，或把 CSV 导出到 CRM。

适用边界 · 注意事项

• 需要先安装 browse CLI（npm install -g browse）并设置 BROWSERBASE_API_KEY 环境变量，缺少这些依赖时无法使用。
• 不适用于非会议/活动场景的潜客挖掘（例如没有讲者名单或赞助商/参展商页面的目标列表构建）。
• 当用户没有本地 ICP profile（profiles/{user_slug}.json）时会大声失败，需先创建 profile 或运行 company-research 技能生成。