competitor-analysis

竞争对手分析

分析用户的竞争对手。使用 Browserbase Search API 发现竞争对手，并采用 4 路「规划→研究→综合」模式进行信息补充，最终生成 HTML 报告，其中包含概览、每个竞争对手的深入分析、并排功能／定价矩阵，以及按时间顺序排列的提及动态。

必需项：BROWSERBASE_API_KEY 环境变量，以及已安装的 browse CLI（npm install -g browse）。

首次运行设置：首次运行时，系统会提示你批准 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:*)"

路径规则：在 Bash 中始终使用完整的字面路径，不能使用 ~ 或 $HOME。只解析一次主目录，并在所有地方使用该路径。构建子 Agent 提示词时，将 {SKILL_DIR} 替换为完整的字面路径。

输出目录：所有输出都放入 ~/Desktop/{company_slug}_competitors_{YYYY-MM-DD}/。此目录包含每个竞争对手各一个 .md 文件，以及生成的 HTML 视图和 CSV 文件。

重要 — 工具限制（适用于主 Agent 和所有子 Agent）：

• 所有网页搜索：使用 browse cloud search。绝不使用 WebSearch。
• 所有页面抓取：使用 browse cloud fetch --allow-redirects（默认返回 Markdown；如需原始 HTML，请添加 --format raw，然后通过 sed ... | tr -s ' \n' 提取文本）。绝不使用 WebFetch。响应上限为 1 MB——对于使用大量 JavaScript 的页面，请改用 browse get markdown（先运行 browse open <url> --remote）。
• 所有研究输出：子 Agent 使用 bash heredoc 将每个竞争对手分别写入 {OUTPUT_DIR}/{competitor-slug}.md。绝不使用 Write 工具或 python3 -c。文件格式请参阅 references/example-research.md。
• 报告编译：使用 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。
• 子 Agent 只能使用 Bash 工具。
• 主 Agent 绝不读取原始的发现结果 JSON 批次文件。

重要 — 尽量减少权限提示：

• 子 Agent 必须使用一次 Bash 调用，通过串联 heredoc 批量完成所有文件写入。
• 使用 && 链接，在单次 Bash 调用中批量完成所有搜索和所有页面抓取。

流程概览

请按顺序完成以下 8 个步骤。请勿跳过或调整顺序。

1. 用户公司调研 — 深入了解用户的公司，整理出 precise_category + category_include_keywords + exclusion_list
2. 深度模式 + 种子输入 — 选择深度，接受可选的种子竞争对手 URL
3. 发现（3 个并行波次） — 波次 A（替代方案）、波次 B（精确类别）、波次 C（通过解析“X vs Y”标题发现对比页面图谱）
4. 筛选关卡 — scripts/gate_candidates.mjs 获取每个候选网站的首页主视觉文案（通过 browse cloud fetch），并剔除类别不符的 URL
5. 与用户确认补充信息的范围 — 通过 AskUserQuestion 呈现 PASS / UNKNOWN / rejected-brand-matches。用户勾选真实匹配项，并补充发现过程中遗漏的对象。跳过此步骤会造成浪费，因为补充信息的成本很高（25 个子 Agent × 深度预算），且筛选关卡并不完美（大量 JS 的首页、Cloudflare 验证、语义变体标语）
6. 深度补充信息（deep/deeper 模式下，每个竞争对手配备 5 个子 Agent） — 营销、讨论、社交、新闻、技术——每个领域由独立子 Agent 负责写入 partials/；随后由 merge_partials.mjs 汇总。在 deep/deeper 模式下，步骤 5d 会在步骤 5c 的事实核查完成后，增加第 6 个 Battle Card 综合分析领域——基于引用证据，为每个竞争对手整理致命问题 / 异议应对 / 推介话术。
7. 截图 — 通过 browse CLI 使用 capture_screenshots.mjs，为每个竞争对手截取一张 1280×800 的首页主视觉截图
8. HTML 报告 — 概览 + 每个竞争对手的详情（含嵌入式主视觉截图和 Battle Card 卡片）+ 矩阵 + 提及内容视图

---

步骤 0：设置输出目录

OUTPUT_DIR=~/Desktop/{company_slug}_competitors_{YYYY-MM-DD}
mkdir -p "$OUTPUT_DIR"

将 {company_slug} 替换为用户公司的名称（小写，单词间用连字符连接），将 {YYYY-MM-DD} 替换为今天的日期。将 {OUTPUT_DIR} 作为完整的字面路径传递给每个子 Agent。

清理之前运行生成的发现批次文件：

rm -f /tmp/competitor_discovery_batch_*.json

重新运行必须从干净的 $OUTPUT_DIR 开始。 compile_report.mjs 会读取目录中的所有 {slug}.md，而 merge_partials.mjs 只会覆盖当前集合中的 slug——它不会删除新补充信息集合中已移除的 slug。由于目录按日期命名，同一天使用不同的竞争对手集合重新运行，会导致过时的竞争对手残留在概览、矩阵、CSV 和截图中。请使用新目录，或先清理之前的单个竞争对手文件：

rm -f "$OUTPUT_DIR"/*.md && rm -rf "$OUTPUT_DIR"/partials "$OUTPUT_DIR"/screenshots

第 1 步：用户公司调研

这一步为“竞争对手”的定义设定基准，并产出第 5b 步矩阵中 userCompany 行将使用的已核实数据。

规则：对用户的公司也要进行与竞争对手同等深度的 5 条线调研。切勿凭记忆填写 matrix.json 中的 userCompany，否则会向用户自己的团队提供虚假信息。在一次搜索 API 调研中（用户公司 Exa，2026-04-23），跳过这一步导致矩阵声称 Exa 有“已发布的正常运行时间 SLA”（实际上没有公开的数值 SLA，只有状态页面），并将其采用 MIT 许可证的 Python SDK 标记为 open-source: false（仓库是 github.com/exa-labs/exa-py，已确认 LICENSE 为 MIT）。这两个错误都会在“你在哪些方面领先”卡片中被呈现为虚构的竞争优势。

流程：

1. 询问用户的公司名称或 URL。

2. 检查是否已有公司资料，路径为 {SKILL_DIR}/profiles/{company-slug}.json。如果存在，则加载资料并向用户确认：“我有你在 {researched_at} 调研的资料。现在仍然准确吗？”——如果准确，则跳到第 2 步，但仍须运行下面的部分调研补充，以便矩阵综合分析能获得最新的功能证据。 资料格式与 company-research 共享（结构相同）。如果用户已在 company-research/profiles/ 下保存了资料，可以将其复制到此技能的 profiles 目录，无需重新调研。

3. 对用户的公司执行完整的 5 条线补充调研——与第 5 步中的竞争对手调研模式相同。针对每条线，启动一个仅使用 Bash 的子 Agent，将结果写入 {OUTPUT_DIR}/partials/{user-slug}.{lane}.md：

   • marketing — 标语、定位、定价档位、功能、集成、开源组件（SDK 仓库及许可证）、提供服务的区域、合规性（SOC 2 / HIPAA / 信任门户 URL）
   • technical — REST + 流式 API 支持（含文档 URL）、SDK 语言、MCP 服务 URL、神经检索与关键词检索模式、重排 / 摘要片段 / 实时爬取的具体情况、已发布的正常运行时间 SLA（实际百分比，不能是状态页面）、第三方检索质量基准测试
   • discussion、social、news — 快速模式下可选，深度+模式下建议执行 子问题参见 references/research-patterns.md → “Self-Research”。每项发现都必须引用 URL。

4. 对用户公司的部分调研结果也运行 merge_partials.mjs，生成 {OUTPUT_DIR}/{user-slug}.md，这是第 5b 步读取 userCompany 标记时使用的规范来源。

5. 综合生成公司资料：Company、Product、Existing Customers、Competitors（种子列表）、Use Cases、precise_category、category_include_keywords、exclusion_list。不要包含 ICP——此技能不需要它。

   • precise_category：用一句话描述类别。例如：“面向 Agent、支持神经检索和关键词检索的 AI 网络搜索 API”。避免使用“工具”／“平台”等模糊词。
   • category_include_keywords：列出 8-15 个短语，这些短语很可能出现在直接竞争对手的营销内容中（主视觉文案或标题）。包括语义变体。
   • exclusion_list：表示属于不同类别的短语——门控机制会用它排除错误的匹配项（例如 antidetect browser、scraping api、screenshot api、residential proxy）。 确切格式及 Exa 的完整示例参见 references/research-patterns.md → “Synthesis Output”。

6. 将公司资料和用户公司的 .md 文件提交给用户确认。确认前不得继续。

7. 保存已确认的公司资料，路径为 {SKILL_DIR}/profiles/{company-slug}.json。

第 2 步：深度模式 + 种子输入

通过 AskUserQuestion 使用复选框提出澄清问题：

• 已知竞品？ URL/名称的文本区域（可选——发现流程还会找到更多竞品）。
• 深度模式？
  • quick — 仅分析营销页面，竞品较多，每个约调用 2-3 次工具
  • deep — + 外部信号（提及、评价、新闻），每个约调用 5-8 次工具
  • deeper — + 公开基准测试 + 与用户公司的战略差异分析，每个约调用 10-15 次工具
• 目标数量？ 要研究的竞品大致数量（例如 10 / 20 / 50）。

这是唯一一次用户交互。此后静默执行，直到报告就绪。

模式	每个竞品的研究内容	最适合
quick	仅第 1 条路径（首页 + 定价）	快速扫描约 30-50 个竞品
deep	第 1+2 条路径	为约 15-25 个竞品收集外部信号
deeper	全部 4 条路径（+ 基准测试 + 战略差异分析）	全面了解约 5-15 个竞品

第 3 步：发现（3 个并行波次）

公式：每个波次查询数为 ceil(target_count / 20)。多发现约 3 倍，因为筛选环节会淘汰约 40-60%。

搜索 API 运行评估表明，这三个波次互为补充——跳过任何一个都会漏掉真正的竞品：

波次 A — 通用替代方案（范围广；聚合网站噪声较多，稍后过滤）

• "{user_company} 的替代方案"
• "{user_company} 竞品"

波次 B — 精确类别（使用档案中的 precise_category）

• 原样搜索 "{precise_category}"
• 使用最具辨识度的词语组合 2-3 个查询（例如 "面向 AI Agent 的网页搜索 API"、"面向 LLM 的检索 API"）

波次 C — 对比页面图谱（精确度最高）

• "{user_company} vs"
• "{seed1} vs"、"{seed2} vs"、"{seed3} vs"（种子来自档案的 competitors 列表）
• 搜索后，运行 scripts/extract_vs_names.mjs，从结果标题中解析 "X vs Y" 模式——此方法可独特地发现未以 URL 形式出现的竞品。

流程：

1. 在同一条消息中发起 3 个并行 browse cloud search Bash 调用（每个波次一个）——不要使用子 Agent。每个 Bash 调用都用 && 串联其 2-4 个查询。具体步骤见 references/workflow.md →“Discovery — parallel Bash, not subagents”。对于 6-12 次 browse cloud search 调用的工作量，子 Agent 开销过大。
2. 所有波次完成后：

   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
   

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。
4. 对于已解析出 domain 的 vs_names 条目，将其加入列表。对于尚未解析出域名的名称，可选择运行 browse cloud search "{name}" --num-results 3，并选取排名最高的根域名。
5. 与用户提供的种子 URL 合并。按主机名去重 → /tmp/competitor_candidates.txt

第 4 步：筛选（类别匹配过滤）

在补充信息、消耗工具调用之前，剔除那些营销内容表明其属于不同类别的候选对象。

cat /tmp/competitor_candidates.txt \
  | node {SKILL_DIR}/scripts/gate_candidates.mjs \
      --include "{profile.category_include_keywords joined with commas}" \
      --exclude "{profile.exclusion_list joined with commas}" \
      --concurrency 6 \
  > /tmp/competitor_gated.jsonl

grep '"status":"PASS"' /tmp/competitor_gated.jsonl \
  | node -e 'require("fs").readFileSync(0,"utf-8").split("\n").filter(Boolean).forEach(l => { try { console.log(JSON.parse(l).url); } catch {} })' \
  > /tmp/competitor_passed.txt

筛选环节通过 browse cloud fetch --allow-redirects --format raw 获取每个候选对象的首页，提取前 800 个字符的可见文本，并根据定位进行分类：若在 <title> 中出现排除项 → 拒绝；若在 <title> 中出现包含项 → 通过；标题混合 → 使用 hero200 进行决胜判断；否则继续后续判断。

在一次搜索 API 运行中进行评估，共 12 个混合候选对象：7/7 个真正的竞品通过，4/4 个类别不符的对象被拒绝，1 个已知的混合类别边界案例被拒绝。

步骤 4.5：与用户确认补充信息集合

此步骤为必需步骤。即使门控流程已运行，也不要跳过并直接开始补充信息。

补充信息的成本很高：5 个竞争对手 × 5 个分道子代理 = 25 个子代理，耗时约 10-15 分钟，约 300 次 browse cloud 调用。如果针对错误的对象集合运行，会白白浪费所有这些资源。门控流程也存在已知盲点：

• 以 JS 为主的主页（例如 Tavily、Firecrawl）——browse cloud fetch 返回的文本几乎为空，因此没有可供匹配的关键词 → REJECT 或 UNKNOWN
• Cloudflare 验证页面（例如 Perplexity）——标题会变成 “Just a moment...” → 没有类别信号
• 语义变体——“search foundation” / “retrieval backbone” 与以 “search API” 为中心的列表在词面上不匹配
• 域名歧义——brave.com（浏览器）与 api-dashboard.search.brave.com（实际的 API 产品）可能导致分类混淆

用户几乎总是比此技能掌握更多领域知识。请询问他们。

流程——主 Agent：

1. 读取 /tmp/competitor_gated.jsonl 并对记录分组：

   • PASS 组：所有 status=PASS 的记录。
   • UNKNOWN 组：status=UNKNOWN（获取失败——务必列出这些结果，因为它们是未被发现的遗漏项）。
   • 被拒绝的品牌组：从 REJECT 记录中选出前约 10 条，其标题提及知名品牌模式（例如包含用户提供的种子列表中的词元，或经常出现在 Wave C 的 “X vs Y” 图中）。

2. 向用户展示各组内容，每组使用一个表格，并列出 URL + 标题 + 原因（针对被拒绝项）。

3. 使用 AskUserQuestion，提供涵盖这三组所有候选项的复选框列表，以及一个可自由填写的“添加更多”字段。提示内容应明确：

   “以下是门控流程选出的候选项，以及一些无法确定的候选项。请勾选在你所在领域确属竞争对手的项，并粘贴任何我遗漏的 URL（以逗号分隔）。补充信息只会针对你勾选的对象运行。”

4. 将确认后的对象集合写入 /tmp/competitor_enrichment_set.txt（每行一个 URL）。这是步骤 5 的输入文件——不是 /tmp/competitor_passed.txt。

如果用户没有回复，或明确表示“直接运行”，则原样使用 /tmp/competitor_passed.txt 作为备选，但要在聊天中提醒用户，运行可能会将预算浪费在类别不符的候选项上。

Exa 测试，2026-04-24：门控流程自动通过了 101 个候选项中的 22 个，但遗漏了 Tavily（通用标题）、Jina AI（语义不匹配——“search foundation”）、Firecrawl（以 JS 为主导致获取失败）和 Perplexity（Cloudflare 验证）。这四个都是真正的直接竞争对手。此步骤可以发现它们。

步骤 5：深度补充信息

提供两种模式。提示词模板和波次管理请参阅 references/workflow.md。逐通道的方法请参阅 references/research-patterns.md。

快速模式——每批使用一个子代理

• 输入：/tmp/competitor_enrichment_set.txt（步骤 4.5 中由用户确认的对象集合），每个子代理约处理 8 个竞争对手。
• 一个子代理仅运行通道 A（营销表层分析）。每个竞争对手调用工具 2-3 次。
• 直接写入 {OUTPUT_DIR}/{slug}.md。

深度 / 更深模式 — 每个竞争对手启动 5 个子 Agent（并行分通道）

针对每个竞争对手，启动 5 个并行子 Agent，每个通道各 1 个：

• A. 营销（marketing）：定价、功能、定位、集成、客户、团队、融资、总部。负责规范的 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）：TechCrunch、Verge、VentureBeat、Forbes、Businesswire、Substack、博客评测。每条提及都必须注明日期。
• E. 技术与基准测试（technical）：GitHub 基准测试仓库/PR、性能文章。撰写基准测试和技术发现。

每个通道的预算：深度 = 5-8 次工具调用，更深 = 10-15 次。 在单条 Agent 工具消息中启动所有「竞争对手 × 通道」子 Agent。 10 个竞争对手 × 5 个通道 = 在一条消息中并行调用 50 个 Agent。不要按竞争对手或通道分批——实际耗时会与最慢的单个 Agent（约 3-5 分钟）持平。一次实测表明，分 5 轮、每轮 10 个调用需要 25 分钟，而真实并行只需 5 分钟；不要分批。

每个子 Agent 都会将部分结果写入 {OUTPUT_DIR}/partials/{slug}.{lane}.md。

重要：将用户的公司名称、产品和关键功能逐字传递给每个子 Agent 提示词，以便技术通道进行策略差异分析。将完整的字面 {OUTPUT_DIR} 路径传递给每个子 Agent。

合并部分结果 → 每个竞争对手的规范文件

所有竞争对手的所有子 Agent 完成后：

node {SKILL_DIR}/scripts/merge_partials.mjs {OUTPUT_DIR}

将每个竞争对手的 5 份部分结果合并为一个 {OUTPUT_DIR}/{slug}.md——去重后的提及（按日期降序排列）、去重后的基准测试、合并后的发现，以及来自营销通道的规范 frontmatter。

综合对比矩阵（写入 matrix.json）

子 Agent 会以散文形式撰写 key_features 和 integrations，而不是用竖线分隔的原子特征标签。因此，简单地按 | 拆分轴会导致每个竞争对手只有一个整体条目、彼此没有重合项——渲染出的矩阵只会显示毫无用处的对角线。

主 Agent 需要通过综合各竞争对手的信息，建立一套共享分类体系，并写入 {OUTPUT_DIR}/matrix.json。compile_report.mjs 会自动检测此文件，并据此渲染矩阵，而不是按竖线拆分。

流程——主 Agent：

1. 阅读所有 {slug}.md 文件，包括用户公司的文件 {user-slug}.md（在步骤 1 中生成）。在矩阵中，用户是竞争对手 #0——必须以同等严谨的标准对待。

2. 制定包含 12-20 项原子化特征的规范列表——每项都必须是竞争对手可以具备或不具备的判断项（例如“ M CP 服务”“SOC 2”“网站爬虫”“重排器”）。避免使用句子长度的特征。避免只由一家竞争对手具备的特征。

3. 制定包含 10-20 项集成的规范列表（框架、市场、SDK 语言）。

4. 对包括用户在内的每家公司，根据其 .md 文件中的补充资料，将每项分类条目标记为 true / false。**每个标记都必须能追溯到研究发现中的一条要点及其引用的 URL。**如果用户的文件写道“exa-py 采用 MIT 许可（github.com/exa-labs/exa-py）”，那么“开源”特征应为 true，并将该 URL 作为来源。如果没有提及，则设为 false。

5. 按以下结构将结果写入 {OUTPUT_DIR}/matrix.json：

   {
     "category": "AI search APIs",
     "features": [{ "name": "Web Search API", "description": "..." }, ...],
     "integrations": [{ "name": "LangChain" }, ...],
     "userCompany": {
       "name": "Exa",
       "winningSummary": "Exa's moats are its first-party neural index and the integrated Research API — no one else in the set ships a semantic/embeddings-native retrieval primitive alongside a multi-step agentic research endpoint. It's also the only provider with a crawler product bundled in, and ties with SerpAPI on breadth of SDK language coverage.",
       "losingSummary": "Exa trails competitors on operational transparency — SerpAPI, Serper, and Tavily all publish hourly throughput SLAs, and Exa lacks a dedicated news endpoint that SerpAPI, Serper, and You.com all ship. Image/visual search is also missing vs 4 of 5 competitors.",
       "features": { "Web Search API": true, "Site crawler": true, ... },
       "integrations": { "LangChain": true, ... }
     },
     "competitors": {
       "tavily": {
         "features": { "Web Search API": true, "Site crawler": true, ... },
         "integrations": { "LangChain": true, "Databricks Marketplace": true, ... }
       },
       "serpapi": { "features": {...}, "integrations": {...} }
     }
   }
   

   必须包含 userCompany。概览页会渲染两张卡片——“{user} 的优势领域”和“{user} 的劣势领域”。请根据自我研究档案（步骤 1）填充 userCompany.features 和 userCompany.integrations。缺少此字段时，这两张卡片不会渲染。

   写入顺序（分两轮——解决下方看似矛盾的顺序要求）。在此步骤（5b）中，为 userCompany 和所有竞争对手填写所有 features / integrations 单元格，并撰写初稿 winningSummary / losingSummary。这些初稿仅用于告知步骤 5c 的事实核查人员哪些说法影响重大（它会优先核查摘要中提及的单元格）。步骤 5c 根据已核实的证据调整单元格后，重写这两份摘要，确保文字只反映经过事实核查的单元格。上方的 JSON 结构展示的是事实核查完成后的最终对象。

   强烈建议填写 userCompany.winningSummary / losingSummary（分析师风格的文字，每篇 2-4 句）。填写后，卡片会以段落而非项目符号列表的形式呈现——读起来更像简报，而不是电子表格。如果缺少这些字段，卡片会回退为优势／劣势项目符号列表，并列出还具备这些项目的其他公司。

如果跳过此步骤，矩阵视图会回退到原始的竖线拆分轴（无法用于原子化比较），且不会显示战略摘要。请勿跳过。

核查矩阵 — 抽查高风险单元格（默认）

对于高风险单元格，不要只依赖分类检查。 这项检查基于文本进行 LLM 推断，可能会凭空捏造竞争壁垒。一次搜索 API 运行（2026-04-23）中就观察到：matrix.json 声称只有用户的公司通过了 SOC 2；核实后发现，其他竞争对手中有三家也通过了 SOC 2 Type II。

但核实每个单元格也是另一个极端。一个包含 7 家公司的 33 个维度矩阵有 231 个单元格。2026 年 4 月的搜索 API 运行在事实核查阶段调用工具超过 111 次后仍卡住，直到被中断——子代理一直在核查类别内普遍存在的基本条件（REST API、JSON 响应、Python SDK）。

默认采用抽查，而非全面核查。 只核实会显著改变战略叙述的单元格。

启动一个仅使用 Bash 的事实核查子代理，并设置硬性 25 次调用上限，且只针对以下高风险维度：

1. 核实每个 userCompany.features 和 userCompany.integrations 单元格（用户自己的竞争壁垒——这些内容会直接用于“你的优势”文案）。通常有 17 + 16 = 33 个单元格，但大多数都很明确（毕竟是你自己的产品）。重点核实：

   • winningSummary 中任何被称为竞争壁垒的内容
   • losingSummary 中任何被称为短板的内容
   • 合规认证（SOC 2、HIPAA、ISO 27001、GDPR）
   • 开源许可证声明（MIT / Apache 2.0 / AGPL——曾发现某竞争对手的 SDK 许可证信息有误）
   • 已公布的可用性 SLA（状态页 ≠ SLA）

2. 对于竞争对手，只核实会影响胜负总结的单元格：

   • 对于每项“优势”声明，核实用户拥有该项能力，并核实竞争对手不具备该能力。
   • 对于每项“短板”声明，核实被点名的竞争对手确实具备该能力。
   • 核实所有竞争对手的合规认证、许可证和 SLA（高可信度但经常出错）。

3. 不要核实：

   • 普遍具备的基本条件（REST API、JSON 响应、Python SDK、API 密钥认证）——每个搜索 API 都有这些。
   • 没有相关声明的 false 单元格（没有失去或赢得竞争壁垒）。
   • 未出现在胜负总结中的集成单元格。

You are a matrix spot-check subagent. Budget: 25 browse cloud calls TOTAL across all cells.
Stop and return what you have when you hit the budget — partial fact-check is
better than blocking the rest of the pipeline.

TOOL RULES: Bash ONLY. browse cloud search + browse cloud fetch. Count your calls; stop at 25.

PRIORITY ORDER (highest-stakes first — work down until budget):
1. Every cell that appears in userCompany.winningSummary or losingSummary
2. Compliance cells (SOC 2, HIPAA, ISO 27001) for user + every competitor
3. Open-source / self-hostable + license cells across all competitors
4. Pricing tier numbers ($X/mo, /hr) for user + competitors named in summaries
5. Funding / employee_estimate fields (only if cited in summaries)

Skip:
- Universal cells (REST API, JSON responses, Python SDK, API-key auth, etc.)
- `false` cells where no claim is being made
- Integration matrix cells unless they appear in summaries

For each cell verified:
- If `true` — find one source URL (docs, trust portal, GitHub LICENSE, etc).
- If `false` — one targeted browse cloud search. Flip ONLY on first-party evidence.

Output: matrix.json with `sources: { "Feature": "https://..." }` on the
verified cells (other cells stay as-is). Cells-changed log to
{OUTPUT_DIR}/matrix_fact_check.md with each flip + URL + quoted evidence.
Report back: "spot-check: N cells verified, M flipped, B/25 budget used".

全面核查模式（可选，耗时较长）：如果用户明确要求“全面事实核查”，或交付内容影响重大（董事会材料、新闻稿），则将调用上限设为 80 次，并核实所有非普遍单元格。默认采用抽查。

子代理完成后，重新读取 matrix.json，重新编译，并向用户呈现 matrix_fact_check.md 的差异。经过抽查的总结远比未经核查的可靠，而且只需 3-5 分钟即可完成，不会卡住整个流程。

步骤 5d：战斗卡片综合（仅限 deep/deeper 模式，在步骤 5c 之后）

依赖步骤 5c 中经过事实核查的 matrix.json。 这是销售赋能环节。针对每个竞争对手，启动一个仅使用 Bash 的综合子 Agent（不进行新的 browse cloud 调用），让它读取所有 5 个现有 partial 文件、用户合并后的 .md 文件以及经过事实核查的 matrix.json，并生成基于引证证据的逐个竞争对手的薄弱环节 / 异议应对 / 沟通话术。

提示词模板：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 章节。

此环节完成后，重新运行合并。 步骤 5 的合并是在战斗卡片 partial 文件生成前运行的，因此合并后的 {slug}.md 文件中尚未包含这些内容。重新运行：

node {SKILL_DIR}/scripts/merge_partials.mjs {OUTPUT_DIR}

这会将每个 {slug}.battle.md 合并到对应的 {slug}.md 中（merge_partials.mjs 已处理 battle 环节）。compile_report.mjs 会从 {slug}.md 中读取 ## Battle Card 章节，并将其渲染为每个竞争对手 HTML 页面中带品牌强调色的卡片。跳过这次重新合并，报告中就不会出现战斗卡片。

为什么此环节仅做综合——战斗卡片必须以已通过步骤 5c 核验的事实为依据。如果允许子 Agent 进行新的 browse cloud 搜索，就会重新引入事实核查步骤旨在避免的虚构护城河问题。子 Agent 的对抗性自检会明确拒绝无法追溯到输入 partial 条目或由 sources 支撑的矩阵单元格的说法。

并行方式：每个竞争对手启动 1 个子 Agent，并在一条 Agent-tool 消息中启动全部子 Agent（综合速度很快，每个子 Agent 约调用 Bash 3-5 次）。在 quick 模式下跳过此步骤——研究深度不足，无法为卡片提供可信依据。

步骤 6：截图

为每个竞争对手截取一张主页主视觉截图：

node {SKILL_DIR}/scripts/capture_screenshots.mjs {OUTPUT_DIR} --mode remote

使用 browse CLI（npm install -g browse）。--mode 标志用于选择浏览器会话：remote（默认）驱动 Browserbase 会话，最适合有保护措施或会检测机器人的主页，也是无法使用本地 Chrome 时的唯一选项；local 使用你设备上的 Chrome。脚本会在每条 browse 命令中传入相应的 --remote / --local 标志，因此无需单独设置环境配置。每个竞争对手会生成一张 PNG，保存到 {OUTPUT_DIR}/screenshots/{slug}-hero.png。步骤 7 中的编译步骤会自动将主视觉图片嵌入每个竞争对手的 HTML 页面。

耗时：每个竞争对手约 10-20 秒。5 个竞争对手约 60 秒。

步骤 7：HTML 报告

1. 生成所有视图和 CSV（在浏览器中打开总览）：

   node {SKILL_DIR}/scripts/compile_report.mjs {OUTPUT_DIR} --user-company "{user_company}" --open
   

   生成：

   • {OUTPUT_DIR}/index.html — 总览：竞争对手表格，包含宣传语、定价摘要、主要功能和战略差异
   • {OUTPUT_DIR}/competitors/{slug}.html — 单个竞争对手的深入分析（包含所有章节）
   • {OUTPUT_DIR}/matrix.html — 并排展示的功能 / 定价矩阵
   • {OUTPUT_DIR}/mentions.html — 按时间排序的信息流，包含来源类型标签和客户端筛选器
   • {OUTPUT_DIR}/results.csv — 扁平化电子表格

2. 在聊天中提供摘要：

## Competitor Analysis Complete

- **Competitors researched**: {count}
- **Depth mode**: {mode}
- **Mentions collected**: {total mentions} across {source types count} source types
- **Public benchmarks found**: {count}
- **Opened in browser**: ~/Desktop/{company_slug}_competitors_{date}/index.html

3. 在聊天中展示总览表格：

| Competitor | Positioning | Pricing | Key Features | Strategic Diff |
|------------|-------------|---------|--------------|----------------|
| Rival Co | AI-native web search API | $99/mo entry | semantic search, reranking, crawler | Similar retrieval; cheaper entry |

4. 指出最值得关注的 3-5 项发现——例如：“3 个竞争对手公布了基准测试；Rival Co 价格最低；Foo Inc 两周前推出了专用新闻搜索端点。”可主动提出深入分析某个特定竞争对手，或以不同深度重新运行。