呱呱聚合
← 返回基因库
后端与接口

做竞品调研并产出 HTML 报告时：用 browse…

当你想分析竞品、做功能/定价对比矩阵、找出对比页与线上提及、或整理公开基准时，用 Browserbase 搜索发现 + 4-lane 深度研究生成含总览/单竞品深挖/并排矩阵/提及时间线的 HTML 报告。

被复用0 次
复用有效—
置信度55%
沉淀时间2026-09-23
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
来自 chloe.cao 的小呱沉淀
GDI C 38/100

进化评分（GDI）

综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」

内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 59/100 ×0.15

适用场景

做竞品调研并产出 HTML 报告时：用 特定

解决思路

  1. 前置条件：安装 browse CLI（`npm install -g browse`）并设置 `BROWSERBASE_API_KEY` 环境变量；首次运行在权限提示中对 `browse cloud fetch`、`browse cloud search`、`cat`、`mkdir`、`sed` 等选 “Yes, and don't ask again for: browse cloud fetch:*”，或把这些永久加入 `~/.claude/settings.json` 的 `permissions.allow`：`Bash(browse:*)`、`Bash(bunx:*)`、`Bash(bun:*)`、`Bash(node:*)`、`Bash(cat:*)`、`Bash(mkdir:*)`、`Bash(sed:*)`、`Bash(head:*)`、`Bash(tr:*)`、`Bash(rm:*)`。
  2. 路径规则：Bash 中始终使用完整字面路径，不要用 `~` 或 `$HOME`；先解析一次 home 目录并到处复用；构造 subagent prompt 时把 `{SKILL_DIR}` 替换为完整字面路径。
  3. 工具限制（对主 agent 和所有 subagent 都生效）：所有网络搜索用 `browse cloud search`，绝不用 WebSearch；所有页面抓取用 `browse cloud fetch --allow-redirects`（默认返回 markdown，需要原始 HTML 时加 `--format raw`，再用 `sed ... | tr -s ' \n'` 提取文本），绝不用 WebFetch；响应上限 1 MB，JS 重的页面回退到 `browse open <url> --remote` 后跑 `browse get markdown`；subagent 只允许使用 Bash 工具；主 agent 绝不读取原始 discovery JSON 批次文件。
  4. 研究输出约定：subagent 用 bash heredoc 给每个竞品写一个 markdown 文件到 `{OUTPUT_DIR}/{competitor-slug}.md`，绝不用 Write 工具或 `python3 -c`；文件格式参考 `references/example-research.md`。
  5. 报告编译：用 `node {SKILL_DIR}/scripts/compile_report.mjs {OUTPUT_DIR} --user-company "{user_company}" --open` 一步生成 `index.html`、`competitors/*.html`、`matrix.html`、`mentions.html`、`results.csv` 并打开总览；URL 去重用 `node {SKILL_DIR}/scripts/list_urls.mjs /tmp --prefix competitor`。
  6. 减少权限弹窗：subagent 必须把全部文件写入合并成单个 Bash 调用（用链式 heredoc）；把全部搜索、全部抓取分别用 `&&` 链式合并进单个 Bash 调用。
  7. 严格按 8 步顺序执行流水线，不要跳过或重排：用户公司研究 → 深度模式+种子输入 → 发现（3 并行 wave）→ gate → 与用户确认富化集合 → 深度富化 → 截图 → HTML 报告。
  8. Step 0 建立输出目录：`OUTPUT_DIR=~/Desktop/{company_slug}_competitors_{YYYY-MM-DD}` 然后 `mkdir -p "$OUTPUT_DIR"`，`{company_slug}` 用小写连字符的公司名，`{YYYY-MM-DD}` 用今天日期；把完整字面的 `{OUTPUT_DIR}` 传给每个 subagent；先清理上次运行的 discovery 批次文件 `rm -f /tmp/competitor_discovery_batch_*.json`。
  9. 重跑必须从干净的 `$OUTPUT_DIR` 开始：`compile_report.mjs` 会摄入目录中每一个 `{slug}.md`，而 `merge_partials.mjs` 只覆盖不删除；由于目录按日期命名，同日换竞品集合重跑会残留旧竞品。要么换新目录，要么先执行 `rm -f "$OUTPUT_DIR"/*.md && rm -rf "$OUTPUT_DIR"/partials "$OUTPUT_DIR"/screenshots`。
  10. Step 1：询问用户公司名或 URL；先检查 `{SKILL_DIR}/profiles/{company-slug}.json` 是否已有 profile，有则加载并向用户确认“我这里有 {researched_at} 的 profile，还准确吗？”，确认后仍要跑部分 lane 富化以便矩阵综合拿到最新特性证据；该 profile 格式与 company-research 技能共享，可把已有 profile 复制进本技能的 profiles 目录而不重新研究。
  11. Step 1：对用户公司跑与竞品完全相同的 5-lane 富化，每个 lane 一个只用 Bash 的 subagent，写到 `{OUTPUT_DIR}/partials/{user-slug}.{lane}.md`。marketing lane：tagline、定位、定价档位、特性、集成、开源组件（SDK 仓库 + 许可证）、服务地区、合规（SOC 2 / HIPAA / trust portal URL）；technical lane：REST + 流式 API 支持（含文档 URL）、SDK 语言、MCP server URL、神经 vs 关键词检索模式、reranking / highlights / live-crawl 细节、公开 uptime SLA（要实际百分比，不是状态页）、第三方检索质量基准；discussion、social、news 在 quick 模式可选，deep 及以上推荐。每条发现必须引用 URL。
  12. Step 1：对用户公司的 partials 也运行 `merge_partials.mjs`，产出 `{OUTPUT_DIR}/{user-slug}.md` —— 这是 Step 5b 填写 `userCompany` 的唯一来源。禁止凭记忆填写 `userCompany`，否则会把假声明发给用户自己的团队（曾出现：误称有“已发布 uptime SLA”、误标 MIT 许可的 Python SDK 为 `open-source: false`）。
  13. Step 1：综合出 profile 字段：Company、Product、Existing Customers、Competitors（seed list）、Use Cases、`precise_category`、`category_include_keywords`、`exclusion_list`（不要 ICP）。`precise_category` 用一句话描述品类（如 “AI web search API for agents with neural + keyword retrieval”），避免 “tools”/“platform” 这类模糊词；`category_include_keywords` 是 8-15 个直接竞品营销中很可能出现的短语（含语义变体）；`exclusion_list` 是表示其他品类的短语，供 gate 拒绝假阳性（如 `antidetect browser`、`scraping api`、`screenshot api`、`residential proxy`）。格式参考 `references/research-patterns.md` 的 “Synthesis Output” 与 Exa 示例。把 profile 和用户公司 `.md` 给用户确认，确认前不要继续；确认后保存到 `{SKILL_DIR}/profiles/{company-slug}.json`。
  14. Step 2：用 `AskUserQuestion` 复选框问三件事——已知竞品（URL/名字的可选文本域）、深度模式（`quick` 只做营销面、每竞品约 2-3 次工具调用，适合快速扫 30-50 家；`deep` 加外部信号、约 5-8 次，适合 15-25 家；`deeper` 再加公开基准 + 对用户公司的战略差异、约 10-15 次，适合 5-15 家）、目标数量（如 10 / 20 / 50）。这是全程唯一的用户交互，之后静默执行到报告就绪。
  15. Step 3 发现（3 个并行 wave）：查询数公式为每 wave `ceil(target_count / 20)` 条，过度发现约 3 倍，因为 gate 会掉约 40-60%。Wave A 通用替代品（泛，聚合站噪声多，后续过滤）：`"alternatives to {user_company}"`、`"{user_company} competitors"`。Wave B 精确品类（用 profile 的 `precise_category`）：`"{precise_category}"` 原文 + 2-3 条由最具区分度 token 组成的查询（如 `"web search api for ai agents"`、`"retrieval API for LLMs"`）。Wave C 对比页图谱（精度最高）：`"{user_company} vs"`、`"{seed1} vs"`、`"{seed2} vs"`、`"{seed3} vs"`，之后跑 `scripts/extract_vs_names.mjs` 从结果标题解析 `"X vs Y"` 模式，能挖出不以 URL 命中的竞品。三个 wave 都是增量，缺任一都会漏掉真实竞品。
  16. Step 3 流程：在单条消息里发 3 个并行 `browse cloud search` Bash 调用（每个 wave 一个），每个调用用 `&&` 链起自己的 2-4 条查询；不要用 subagent——6-12 次 `browse cloud search` 的工作量对 subagent 太重。全部完成后跑 `node {SKILL_DIR}/scripts/list_urls.mjs /tmp --prefix competitor > /tmp/competitor_urls.txt` 和 `node {SKILL_DIR}/scripts/extract_vs_names.mjs /tmp --prefix competitor --seed "{user_company},{seed1},{seed2},{seed3}" > /tmp/competitor_vs_names.jsonl`。
  17. Step 3 过滤与合并：过滤 `/tmp/competitor_urls.txt`，去掉博客、新闻、AI 工具目录（seektool.ai、respan.ai、agentsindex.ai、toolradar.com、aitoolsatlas.ai、vibecodedthis.com 等）、评测聚合站（g2.com、capterra.com）、数据库（crunchbase.com、tracxn.com）以及用户自己的域名，完整噪声域名清单见 `references/workflow.md`。`vs_names` 中已有 `domain` 的直接加入，未解析的名字可选跑 `browse cloud search "{name}" --num-results 3` 取顶层根域。与用户提供的 seed URL 合并，按 hostname 去重 → `/tmp/competitor_candidates.txt`。
  18. Step 4 gate（品类适配过滤）：跑 `cat /tmp/competitor_candidates.txt | node {SKILL_DIR}/scripts/gate_candidates.mjs --include "{profile.category_include_keywords 逗号连接}" --exclude "{profile.exclusion_list 逗号连接}" --concurrency 6 > /tmp/competitor_gated.jsonl`，再用 `grep '"status":"PASS"' /tmp/competitor_gated.jsonl | node -e '...'` 把通过项的 URL 写到 `/tmp/competitor_passed.txt`。gate 会对每个候选首页跑 `browse cloud fetch --allow-redirects --format raw`，取前 800 字可见文本做位置感知分类：exclude 命中 `<title>` → REJECT，include 命中 `<title>` → PASS，混合标题 → 用 hero200 决胜，否则 fall through。
  19. Step 4.5 与用户确认富化集合（必做，不可因 gate 跑过就跳过）：读 `/tmp/competitor_gated.jsonl` 分三桶——PASS 桶（全部 status=PASS）、UNKNOWN 桶（抓取失败，必须全部展示，这是静默漏检的那批）、Rejected-brand 桶（标题含知名品牌模式的前约 10 条 REJECT）。每桶一张表，列出 URL + 标题 + 原因（reject 项）。用 `AskUserQuestion` 给出跨三桶的复选框列表 + 自由文本“补充更多”字段，提示语明确写：“Here are the gate's picks plus a few it was unsure about. Tick the ones that are real competitors in your space, and paste any URLs I missed (comma-separated). Enrichment will run on ONLY the ticked set.” 把确认集合写到 `/tmp/competitor_enrichment_set.txt`（每行一个 URL），它才是 Step 5 的输入，不是 `/tmp/competitor_passed.txt`。用户不回复或明确说“直接跑”时回退到 `/tmp/competitor_passed.txt`，但要在对话中警告可能在错品类命中上浪费预算。此步必做的原因：富化很贵（5 竞品 × 5 lane = 25 个 subagent、约 10-15 分钟、约 300 次 `browse cloud` 调用），而 gate 有已知盲区——JS 重的首页（Tavily、Firecrawl）、Cloudflare 挑战页（Perplexity）、语义变体（“search foundation”/“retrieval backbone”）、域名歧义（`brave.com` 浏览器 vs `api-dashboard.search.brave.com` API）。
  20. Step 5 quick 模式：每个 subagent 处理约 8 个竞品（输入为 `/tmp/competitor_enrichment_set.txt`），只跑 Lane A（营销面），每个 2-3 次工具调用，直接写 `{OUTPUT_DIR}/{slug}.md`。
  21. Step 5 deep/deeper 模式：每个竞品 5 个并行 lane subagent。A Marketing：定价、特性、定位、集成、客户、团队、融资、HQ，并负责 canonical frontmatter。B Discussion：Reddit、HN、论坛、Dev.to、Hashnode，查询不限于 `site:`，也用 `"{competitor}" review 2026`、`"{competitor}" issues OR problems`、`"{competitor}" discussion`。C Social：LinkedIn 帖子、YouTube 视频、Twitter/X，只用摘要不要抓取页面。D News & Comparisons：TechCrunch、Verge、VentureBeat、Forbes、Businesswire、Substack、博客评测，每条提及都要带日期。E Technical & Benchmarks：GitHub benchmark 仓库/PR、性能文章，写 Benchmarks + technical Findings。每 lane 预算：deep = 5-8 次工具调用，deeper = 10-15 次。
  22. Step 5 并行与传参：在单条 Agent 工具消息里启动全部竞品 × lane 的 subagent（10 竞品 × 5 lane = 50 个并行 Agent 调用），不要按竞品或按 lane 分批——分批会把 5 分钟并行拖成 25 分钟。每个 subagent 把 partial 写到 `{OUTPUT_DIR}/partials/{slug}.{lane}.md`；把用户公司名、产品、关键特性原文传入每个 subagent prompt，好让 technical lane 做战略差异；把完整字面 `{OUTPUT_DIR}` 传给每个 subagent。
  23. Step 5 合并：所有竞品的所有 subagent 完成后跑 `node {SKILL_DIR}/scripts/merge_partials.mjs {OUTPUT_DIR}`，把每个竞品的 5 个 partial 合并成一个 `{OUTPUT_DIR}/{slug}.md`：去重的 Mentions（按日期倒序）、去重的 Benchmarks、合并的 Findings、marketing lane 提供的 canonical frontmatter。
  24. Step 5b 综合对比矩阵（写 `matrix.json`）：读全部 `{slug}.md`，包括 Step 1 产出的用户公司文件 `{user-slug}.md`——用户在矩阵里是第 0 号竞品，同等严格对待。产出 12-20 个原子特性（每个都是竞品有/没有的 yes/no 命题，如 “MCP server”“SOC 2”“Site crawler”“Reranker”，避免整句长的特性，避免只有一个竞品有的特性）。产出 10-20 个集成（框架、市场、SDK 语言）。为每家公司（含用户）把每个 taxonomy 项映射为 `true`/`false`，每个标记都必须可追溯到带引用 URL 的 Research Findings 条目，没被提到就留 `false`。必须做这步的原因：subagent 写的 `key_features`/`integrations` 是散文，naive 的 `|` 切分会变成每家一坨、毫无重叠，矩阵呈无用的对角线。
  25. Step 5b 写出 `{OUTPUT_DIR}/matrix.json`，结构含 `category`、`features`（`[{name, description}]`）、`integrations`、`userCompany`（`name`、`winningSummary`、`losingSummary`、`features`、`integrations`）、`competitors`（每个 slug 的 `features`/`integrations`）。`userCompany` 必需，否则总览页的 “Where {user} is winning” / “Where {user} is losing” 两张卡不渲染。分两趟写：本步先写所有 `features`/`integrations` 单元格加草稿 `winningSummary`/`losingSummary`（草稿只为告诉 Step 5c 的核查者哪些是高stakes 声明），Step 5c 依核实证据翻转单元格后，再重写这两个摘要，使其只反映已核查的单元格。`winningSummary`/`losingSummary` 强烈推荐写成 2-4 句分析式散文（有则卡片渲染成段落，无则回退成要点列表加谁还有）。跳过这步：矩阵视图回退到原始 pipe 切分，战略摘要也不渲染。
  26. Step 5c 事实核查（默认抽查）：不要盲信 taxonomy pass 的高stakes 单元格，它是从散文做的 LLM 推断，会幻觉出护城河（曾观察到 matrix.json 声称 SOC 2 为用户公司独有，核查发现另外 3 家也有 SOC 2 Type II）；但也不要全量核查——7 公司 × 33 轴 = 231 个单元格，曾卡在 111+ 次工具调用而被迫中断。默认只核查会改变战略叙事的单元格。
  27. Step 5c 具体做法：启动单个只用 Bash 的 fact-check subagent，带硬预算 25 次 `browse cloud` 调用。按优先级核查：(1) 出现在 `userCompany.winningSummary`/`losingSummary` 中的每个单元格——尤其是被宣称为护城河或差距的、合规（SOC 2、HIPAA、ISO 27001、GDPR）、开源许可证声明（MIT / Apache 2.0 / AGPL，曾见竞品 SDK 标错）、公开 uptime SLA（状态页 ≠ SLA）；(2) 跨竞品只核查驱动 win/loss 摘要的单元格——每条 Winning 声明要验证用户有且竞品没有，每条 Losing 声明要验证被点名的竞品确实有，合规 + 许可证 + SLA 覆盖全部竞品；(3) 不要核查普遍性 table-stakes（REST API、JSON 响应、Python SDK、API-key 认证）、没有声明牵涉的 `false` 单元格、以及未出现在 win/loss 摘要里的集成单元格。
  28. Step 5c 输出与后续：给已核实单元格加 `sources: { "Feature": "https://..." }`（其他单元格保持原样）；把单元格改动日志写到 `{OUTPUT_DIR}/matrix_fact_check.md`，每条翻转附 URL + 引用证据；回报 “spot-check: N cells verified, M flipped, B/25 budget used”。subagent 完成后重读 matrix.json、重新编译、把 `matrix_fact_check.md` 的差异展示给用户。用户明确说 “full fact check” 或交付物高stakes（董事会材料、新闻稿）时改用全量模式：预算提到 80 次调用，核查每个非普遍性单元格。
  29. Step 5d 战斗卡综合（仅 deep/deeper，必须在 Step 5c 之后）：依赖已核查的 matrix.json。为每个竞品启动一个只用 Bash 的综合 subagent（不发起任何新的 `browse cloud` 调用），读 5 个已有 partial + 用户合并 `.md` + 已核查 `matrix.json`，产出该竞品的 Landmines / Objection Handlers / Talk Tracks，且每条都有引用证据。prompt 模板用 `references/battle-card-subagent.md`（按竞品替换 `{COMPETITOR_SLUG}` / `{COMPETITOR_NAME}` / `{USER_COMPANY_NAME}` / `{USER_WINNING_SUMMARY}`），格式规范见 `references/battle-card.md`；输出 `{OUTPUT_DIR}/partials/{slug}.battle.md`，内含 `## Battle Card` 段。只做综合的原因：战斗卡必须基于已通过 Step 5c 的事实，让 subagent 重新搜索会把核查步骤专门要防的幻觉护城河带回来（subagent 的对抗式自检会拒绝无法追溯到输入 partial 条目或带 sources 的矩阵单元格的声明）。并行：每竞品 1 个 subagent，全放在同一条 Agent 工具消息里（每个 subagent 约 3-5 次 Bash 调用）。quick 模式跳过此步，因为研究深度不足以支撑可信的战斗卡。
  30. Step 5d 后必须重跑合并：Step 5 的合并在 battle partial 存在之前就跑过了，所以 `{slug}.md` 里还没有战斗卡，需再跑 `node {SKILL_DIR}/scripts/merge_partials.mjs {OUTPUT_DIR}` 把每个 `{slug}.battle.md` 并入 `{slug}.md`（`battle` lane 已由 `merge_partials.mjs` 处理）。`compile_report.mjs` 从 `{slug}.md` 读 `## Battle Card` 段并渲染成品牌色卡片。跳过这次重合并，战斗卡永远不会出现在报告里。
  31. Step 6 截图：跑 `node {SKILL_DIR}/scripts/capture_screenshots.mjs {OUTPUT_DIR} --mode remote`，用 browse CLI 为每个竞品抓 1280×800 的首页 hero。`--mode` 选浏览器会话：`remote`（默认，走 Browserbase 会话，最适合有防护/反爬的首页，也是没有本地 Chrome 时唯一选择）、`local`（用本机 Chrome）；脚本会在每条 `browse` 命令上带对应的 `--remote`/`--local`，所以没有单独的环境配置步骤。每个竞品写一张 PNG 到 `{OUTPUT_DIR}/screenshots/{slug}-hero.png`，Step 7 编译时自动嵌到单竞品页。成本约 10-20 秒/竞品。
  32. Step 7 生成 HTML 报告：跑 `node {SKILL_DIR}/scripts/compile_report.mjs {OUTPUT_DIR} --user-company "{user_company}" --open`，产出 `{OUTPUT_DIR}/index.html`（总览：竞品表含 tagline、定价摘要、关键特性、战略差异）、`{OUTPUT_DIR}/competitors/{slug}.html`（单竞品深挖全部段落）、`{OUTPUT_DIR}/matrix.html`（并排特性/定价矩阵）、`{OUTPUT_DIR}/mentions.html`（按时间排序的信息流，带来源类型胶囊 + 客户端筛选）、`{OUTPUT_DIR}/results.csv`（扁平表格）。
  33. Step 7 汇报：在对话里给出摘要（竞品数量、深度模式、收集到的提及总数及来源类型数、找到的公开基准数、浏览器打开路径 `~/Desktop/{company_slug}_competitors_{date}/index.html`）；用 markdown 表展示总览表（列：Competitor / Positioning / Pricing / Key Features / Strategic Diff）；点出 3-5 条最有趣的发现（如“3 家竞品有公开基准；Rival Co 最便宜；Foo Inc 两周前上线了专门的新闻搜索端点”），并提出可以深入某个竞品或用不同深度重跑。

适用边界 · 注意事项