数据与研究 · SKILL.md

deep-research

deep-research

【数据与研究】深度调研技能：对任意命题进行系统性调研并输出专业研究报告。覆盖技术选型、行业分析、学术研究、竞品分析、概念探索等所有调研场景。核心方法论：快速扫描→假设驱动研究、内外数据结合（先摸清内部现状再对标外部水位）、反面证据强制搜索、数据来源三级分类、结论置信度分级、多层次报告输出。采用 Orchestrator-Subagent 架构（Lead+Sub-agent 并行深挖、压缩回传、Scaling Rules 预算控制），对齐 Anthropic 官方 Research 工程实践。包含信息交叉验证、专业图表生成（Diagram Bridge 统一图表体系）、数据来源分级标注、分析框架自动选择、报告组件驱动（不预设模板，按内容形态调用组件）、质量自检（6 步工作流）。触发词：调研、研究…

独立 GitHub 快照 · 自动分类 · 以原作者文档为准

3312362115 / claudeMIT

技能说明

GitHub

name: deep-research version: 1.8.0 last_updated: 2026-05-11 repository: https://github.com/312362115/claude changelog: skills/deep-research/CHANGELOG.md description: > 深度调研技能：对任意命题进行系统性调研并输出专业研究报告。覆盖技术选型、行业分析、学术研究、竞品分析、概念探索等所有调研场景。核心方法论：快速扫描→假设驱动研究、内外数据结合（先摸清内部现状再对标外部水位）、反面证据强制搜索、数据来源三级分类、结论置信度分级、多层次报告输出。采用 Orchestrator-Subagent 架构（Lead+Sub-agent 并行深挖、压缩回传、Scaling Rules 预算控制），对齐 Anthropic 官方 Research 工程实践。包含信息交叉验证、专业图表生成（Diagram Bridge 统一图表体系）、数据来源分级标注、分析框架自动选择、报告组件驱动（不预设模板，按内容形态调用组件）、质量自检（6 步工作流）。触发词：调研、研究、分析报告、对比分析、行业报告、技术选型、竞品分析、市场调研、深度研究、出一份报告、帮我调研一下、了解一下xxx、评估、诊断、健康度、差距分析。即使用户没有明确说"调研"，只要意图是"系统性地了解某个命题并形成结论"，都应触发此技能。

深度调研（Deep Research）

先摸清内部现状，再对标外部水位，找到差距，指导行动。产出有判断、有依据、经得起反面追问的专业研究报告。

核心理念：6 步是能力库，不是必走流程

下面分 6 步介绍调研能力：理解命题 → 多跳搜集 → 分析结论 → 图表生成 → 撰写报告 → 质量自检。

这 6 步是能力清单，按命题复杂度调用——不是每次都得全部走完。简单事实查询硬走 6 步是浪费；复杂研究跳过任何一步都会丢深度。

调研深度判断

收到调研需求后，先判断命题复杂度，决定走哪条路径：

命题类型	特征	调用的能力	报告形态
简单事实	单一明确问题（"Redis 7 新特性"、"某 API 用法"）	1.1 命题理解 → 2.6 直接搜索 → 简短答复	对话式答复，不出报告
对比类	两到三方案对比（"Redis vs Dragonfly"）	1.1 + 1.4-1.6（缩减版）→ 2 多跳（2-4 sub-agent）→ 3 分析 → 5 简报（核心结论 + 对比块 + 建议）	中等篇幅 MD，按内容形态选组件
复杂研究	需要建立全景认知（"AI Agent 赛道"）	完整 1-6 步	完整 MD/HTML，覆盖主要组件
超深度	跨产业链、多维度（"半导体国产替代")	完整 1-6 步 + 多轮迭代 + sub-sub-agent	长篇 HTML，覆盖全部组件 + 数据附录

决策树

调研需求来了
↓
命题是单一具体事实查询？（"X 是什么"、"如何配置 Y"）
  ├─ 是 → 走简单事实路径：Lead 自查官方源 → 直接答复（不进入"理解命题"流程）
  └─ 否 → 进入 1.1 命题理解
            ↓
            归类为对比类 / 复杂研究 / 超深度
            ↓
            按 Scaling Rules（2.3）配置预算
            ↓
            按需调用 1.4-6.4 各能力

核心原则：

简单事实查询禁止启动 Multi-Agent——下面 2.1 的 Orchestrator-Subagent 架构是"复杂研究"才用的
对比类调研可省略部分能力——比如假设驱动（1.6）、调查拓扑（2.5）、反面观点段按内容选用
复杂研究走完整 6 步——任何步骤跳过都会丢深度
报告结构由内容形态决定——见 5.2 的"内容形态 → 组件"速查，没有对应内容就不要硬上对应组件

第一步：理解命题，摸清现状

收到调研需求后，先花时间理解命题本质和内部现状，不要急着搜索。

1.1 命题解析

向用户确认以下信息（已知的跳过，模糊的追问）：

核心问题：这次调研要回答什么问题？
调研动机：为什么要调研这个？（决策依据 / 学习了解 / 立项评估）
期望深度：快速摸底还是深度研究？
关注维度：有没有特别关心的角度？（性能 / 成本 / 生态 / 趋势）
已有认知：用户对这个领域已经了解多少？（避免重复输出已知信息）
内部数据源：是否有相关的内部文档、代码库、BI 数据、历史报告可供参考？路径在哪？
评估基准：有没有已知的行业标准或内部目标可作为参照？

1.2 判断调研类型

根据命题自动归类，不同类型决定后续的报告结构和搜索策略：

类型	特征	示例
技术选型	多个方案对比，需要做选择	Redis vs Memcached、React vs Vue
行业分析	了解市场格局、玩家、趋势	AI Agent 赛道、低代码平台市场
概念研究	深入理解原理、机制、演进	RAG 技术原理、CRDT 一致性算法
性能评测	量化对比、benchmark 数据	数据库读写性能对比
竞品分析	产品功能、定位、差异化对比	Cursor vs Windsurf vs Claude Code
可行性探索	验证某个想法是否可行	用 WebRTC 做实时协作编辑

如果命题跨多个类型，以主要目的为准，兼顾次要维度。

评估不是独立类型。所有调研类型都内含评估逻辑——先理解内部现状，再对标外部水位，识别差距。用户说"评估一下 xxx"、"诊断"、"差距分析"时，根据具体命题匹配上述 6 种类型，评估视角在 1.4 现状摸底中统一处理。

加载信源矩阵（完成归类后执行，详见 references/sources/_router.md）：

闸门 1：具体查询 vs 命题调研
- 具体查询（"API 用法 / 命令参数 / bug 复现"）→ Lead 自查官方 docs，跳过 YAML 加载，不走 Multi-Agent
- 命题调研 → 进入闸门 2
闸门 2：关键词匹配
- 金融类（股票/财报/利率/央行/债券/加密/链上/宏观）→ 加载 references/sources/finance.yaml
- 学术类（论文/研究/综述/预印本）→ 加载 references/sources/academic.yaml
- 技术/AI/新兴产业 → 加载 references/sources/_source_heuristics.md
闸门 3：全域加载 references/sources/blacklist.yaml（最高优先级过滤）
搜索预算分配：有白名单时 70% 倾斜冷门权威 + 20% 开放搜索 + 10% 启发式发现；纯启发式时 60% P1 一手 + 30% P2 原厂/评测 + 10% P3 审核社区

Lead Agent 必须在派发 sub-agent 前，把加载的 YAML 内容注入 sub-agent prompt（见 2.1）。

1.3 确定视觉风格

根据调研类型自动选择图表风格主题，同一份报告内所有图表保持统一。具体的风格配置见 references/chart-styles.md，根据调研类型查阅对应章节。

1.4 现状摸底（所有调研类型必做）

在进行任何外部搜索之前，先理解「我们自己」的状态。这是所有调研的起点——不知道自己在哪，就无法判断外部信息的价值。

数据采集来源：

层级	来源	获取方式	可信度
内部数据	本地代码库、内部文档、BI 报表、监控数据	Read / Grep 读本地文件、用户提供	高（一手）
半公开数据	付费数据库、专家访谈纪要、行业社群	用户提供路径或授权访问	中-高
公开数据	行业报告、财报、新闻、开源数据	WebSearch / WebFetch / Playwright	需交叉验证

按调研类型的摸底重点：

调研类型	摸底重点	典型内部数据
技术选型	当前技术栈、性能瓶颈、团队技能分布	代码库、监控数据、内部 ADR
行业分析	公司在行业中的位置、已有业务数据	BI 报表、OKR 文档、财务数据
概念研究	团队对该概念的当前理解和应用程度	现有实现代码、内部技术分享
性能评测	当前性能基线、监控数据、历史 benchmark	APM 数据、压测报告、CI/CD 日志
竞品分析	自身产品现状、用户反馈、内部竞品跟踪	竞品跟踪文档、客户反馈记录
可行性探索	现有技术储备、团队能力、资源约束	代码库技术栈、团队 roster

执行方式：

有内部数据时：优先采集，作为后续外部对比的基线
用户提供路径时：直接 Read/Grep 读取
无内部数据时：记录为「内部数据缺失」，报告中标注「本报告基于公开数据，未纳入内部数据验证」

1.5 快速扫描（建立基本认知）

在形成假设之前，先做一轮轻量级外部搜索，对命题领域建立基本认知。目的不是收集证据，而是了解「这个领域目前是什么状况」，让后续假设有事实基础而非凭空猜测。

执行方式：

围绕命题设计 3-5 个不同角度的搜索词
只看搜索结果摘要和页面标题，不深入阅读全文
记录关键发现：主要玩家、核心争议点、领域现状、意外发现
耗时控制在 1-2 分钟，不展开深度搜索

产出：一段简短的扫描摘要（3-5 个要点），作为下一步形成假设的输入。

示例：

调研命题："是否应该从 Redis 迁移到 Dragonfly"

快速扫描发现：
- Dragonfly 定位为 Redis 的直接替代品，声称性能提升 25 倍
- 多个 benchmark 显示在多线程场景下确实显著优于 Redis
- 但社区讨论中有人指出生产环境稳定性存疑
- Redis 7.0 已引入多线程 IO，缩小了部分差距
- 迁移案例主要集中在中小规模部署

1.6 形成初始假设

基于内部现状（1.4）+ 快速扫描结果（1.5），形成 2-4 个可验证/可证伪的假设：

每个假设用「我认为 X，因为 Y」格式表述，其中 Y 必须引用扫描中发现的具体事实
将假设拆解为可搜索的验证点
后续深度搜索围绕验证/证伪这些假设展开，而非漫无目的收集

示例（承接上面的扫描结果）：

假设 1：Dragonfly 在多线程高并发场景下性能显著优于 Redis
  → 依据：扫描发现多个 benchmark 支持此结论
  → 验证点：独立 benchmark 数据、生产环境案例、Redis 7.0 多线程对比

假设 2：Dragonfly 生态成熟度不足，大规模生产环境迁移风险高
  → 依据：扫描发现迁移案例集中在中小规模，社区有稳定性质疑
  → 验证点：客户端兼容性、大规模部署案例、已知 bug 和限制

假设 3：我们当前的性能瓶颈不在 Redis 层
  → 依据：内部摸底发现 APM 数据显示主要延迟在应用层
  → 验证点：内部监控数据、链路分析、Redis 慢查询日志

与旧流程的区别：假设不再基于猜测，而是基于内部数据和初步扫描的事实。每个假设的「依据」必须指向 1.4 或 1.5 中发现的具体信息。

1.7 与用户对齐

将解析结果简要告知用户：

调研命题：xxx
调研类型：技术选型
报告风格：商务蓝灰
输出格式：Markdown / HTML
命题复杂度：对比类 / 复杂研究 / 超深度
执行预算：派发 N 个 sub-agent，每个 WebSearch ≤ X / WebFetch ≤ Y
预计 Token 消耗：约 Mx chat 基准
初始假设：
  1. xxx
  2. xxx
内部数据源：已读取 / 用户将提供 / 无
预计涵盖：A、B、C 几个维度

开始调研？

输出格式判断规则：

默认 Markdown：绝大多数场景
选择 HTML：用户提到"HTML"、"网页版"、"富文本"、"好看点的"、"交互式"、"嵌入图表"时

用户确认后进入下一步。如果是简单直接的调研需求（命题明确、无歧义），可以跳过对齐直接开始。

第二步：多跳信息搜集

这是调研的核心环节。采用 Orchestrator-Subagent 架构：Lead Agent 负责规划与整合，Sub-agent 独立并行深挖，避免单一 context 被原始材料撑爆导致细节丢失。架构参考 Anthropic 官方 Research 系统实践。

2.1 Multi-Agent 执行模型

Lead Agent（主 agent）
↓ 拆子问题 → 派发
Sub-agent A / B / C  并行（独立 context + 独立预算）
↓ 压缩回传
Lead 整合 → 触发规则命中？
↓ 命中 → 再 fork sub-agent
↓ 未命中 → synthesis 出报告

Lead Agent 职责：

基于 1.6 假设拆解子问题（每个子问题独立可回答）
按 Scaling Rules（2.3）决定 sub-agent 数量和预算
Spawn 前把调查计划写入 /tmp/research-plan-<timestamp>.md（防 context 截断丢失）
维护拓扑记录文件：每次 spawn 向 /tmp/research-topology-<timestamp>.json 追加条目，回传后补 budget_used / findings_count，Fork sub-sub 时记录 parent_id；线索被主动放弃也要记录（格式见 2.5）
注入信源矩阵：基于 1.2 加载的 YAML/heuristics，在 sub-agent prompt 中注入：
1. blacklist（hard 必避 + soft 降级 + patterns）
2. 对应领域白名单（finance/academic 的冷门权威列表）或 _source_heuristics.md 的规则 + 本命题所属子域推导示例
3. 搜索预算分配比例（有白名单 70/20/10，纯启发式 60/30/10）
4. 要求 sub-agent 回传 whitelist_hits / heuristic_hits / blacklist_avoided 字段（见 2.4）
只读 sub-agent 的压缩 JSON 回传，不读原始网页
按节点级触发规则（2.2）判断是否 fork 新 sub-agent
最终 synthesis 阶段整合所有 findings 产出报告，并基于拓扑文件生成 5.2"调查拓扑"段

Sub-agent 职责：

独立 context window，专注一个子问题
可自行并行调用多个搜索/抓取工具
在预算内查完，超预算强制收尾
回传结构化 JSON（格式见 2.4）
发现反直觉线索写入 surprises 字段供 Lead 判断是否深挖
长文档按 Filesystem Pattern 存 /tmp/，不塞进回传

硬性约束：

所有 sub-agent 必须使用 Agent 工具派发，指定 subagent_type: "general-purpose" + model: "sonnet"
Lead Agent 保持当前调用模型不变
Sub-agent 之间不直接通信，所有协作通过 Lead 协调

2.2 迭代式深挖与触发规则

废弃"固定 3 层广度优先"模型，改为按节点兴趣度动态深挖。

迭代上限：

Synthesis 轮次 ≤ 3 轮（Lead 汇总 → 看缺口 → 再派发）
单轮内 sub-agent 可递归 fork sub-sub-agent，递归深度 ≤ 3

单轮流程：

Round N
↓
Lead 读全部 findings → 识别信息缺口 / 触发点
↓
Spawn 新一批 sub-agent（可含 sub-sub-agent）
↓
收集压缩回传
↓
满足终止条件 → 结束；否则 Round N+1

节点级 Fork 触发规则（满足任一条件，Lead 必须派新 agent）：

触发条件	深挖方向
`confidence: low` 且 finding 关系核心结论	派专员找 T1 源补证
出现 `surprises`（反直觉线索）	单独派 agent 深挖该线索
不同 sub-agent 的 evidence 矛盾	派"裁判 agent"回溯权威一手源
某核心命题反面 findings 数 < 2	派反面证据专员（Devil's Advocate）
关键命题仅有 T2/T3 支撑、未找到 T1	派一手源专员

终止条件（满足任一即可结束）：

所有假设都有 T1 源或 2+ 独立 T2 源支撑
反面证据搜索已执行且无新发现
进入 Round 3 后仍无新信息

2.3 Scaling Rules（强制预算）

根据命题复杂度配置 sub-agent 数量和工具预算。超预算必须强制收尾，防止 runaway。

命题类型	示例	Sub-agent 数	WebSearch / sub-agent	WebFetch / sub-agent
简单事实	"Redis 7 新特性"	不开 Multi-Agent，Lead 自查	≤ 10	≤ 10
对比类	"Redis vs Dragonfly 性能"	2-4	≤ 8	≤ 12
复杂研究	"AI Agent 赛道格局"	5-10	≤ 10	≤ 15
超深度	"半导体产业链 + 国产替代"	10+ 按需迭代	≤ 12	≤ 20

Lead Agent 在派发前必须声明（写入 plan 文件，并在 1.7 对齐阶段展示给用户）：

命题复杂度评估：<类型>
计划派发：<N> 个 sub-agent
每个预算：WebSearch ≤ X / WebFetch ≤ Y
预计 Token 消耗：约 <M>x chat 基准

Token 成本红线：

Multi-Agent 架构消耗约 15x chat tokens（参考 Anthropic 工程数据）
简单事实查询禁止开 Multi-Agent，直接由 Lead 自查
如评估为复杂研究但用户明确要求"快速了解"，降级为对比类预算

2.4 Sub-agent 压缩回传协议（强制）

核心原则：Sub-agent 不得将原始网页内容回流给 Lead Agent。回传必须是结构化压缩摘要，避免 Lead context 被撑爆导致细节丢失。

标准回传 JSON：

{
  "topic": "本次调查的子问题",
  "findings": [
    {
      "claim": "一句话结论",
      "evidence": ["关键引文片段，每段 ≤100 字"],
      "urls": ["https://..."],
      "source_tier": "T1|T2|T3",
      "confidence": "high|mid|low",
      "date": "证据时间戳，如 2026-03"
    }
  ],
  "surprises": ["反直觉或意外发现，供 Lead 决定是否深挖"],
  "gaps": ["未能验证的点 / 需其他 agent 补充的信息"],
  "budget_used": { "search": N, "fetch": M },
  "whitelist_hits": N,
  "heuristic_hits": { "p1_official": 3, "p2_authoritative": 2, "p3_community": 1 },
  "blacklist_avoided": ["csdn.net", "guba.eastmoney.com"]
}

信源矩阵字段说明：

whitelist_hits：若本次加载了 finance.yaml / academic.yaml，命中了几个白名单源（质量指标）
heuristic_hits：若走启发式，按 P1/P2/P3 分类的命中源数（衡量 heuristics 有效性）
blacklist_avoided：识别并避开的黑名单域列表（证明过滤生效）

硬性禁止：

❌ 回传中包含原始 HTML 或 markdown 全文
❌ 未精简的搜索结果列表
❌ 单条引文超过 100 字
❌ 省略 source_tier 或 confidence 字段

Filesystem Pattern（处理大文档）：

场景	做法
长文档（财报 / 论文 / 长博客）需保全文	Sub-agent 存到 `/tmp/<subagent-id>-<topic>.md`，回传只记录路径
后续 agent 需核对原文	按 `urls` 或 `/tmp/` 路径按需回访，不塞进 Lead context
CitationAgent 做引用对齐	独立读取 `/tmp/` 文件做位置校对
报告完成后	清理 `/tmp/` 下本次调查产生的临时文件

Lead Agent Synthesis 阶段：

Context 中只有压缩 findings JSON，不含原文
需要核对原文时按 URL 或 /tmp/ 路径按需读取
避免一次性把所有 sub-agent 的原始内容塞进 context

2.5 调查拓扑记录协议（强制）

目的：让调研过程可观测——派发了几个 sub-agent、递归了几层、消耗了多少搜索/抓取、放弃了哪些线索，最终写入报告"调查拓扑"段（见 5.2）。

记录文件：/tmp/research-topology-<timestamp>.json（同次调研使用同一文件名，与 plan 文件共享 timestamp）。

条目结构：

{
  "session_id": "<timestamp>",
  "root_topic": "本次调研命题",
  "complexity_class": "simple|comparison|complex|super-deep",
  "agents": [
    {
      "agent_id": "sub-01",
      "parent_id": null,
      "round": 1,
      "topic": "子问题摘要",
      "spawn_reason": "初始拆解 | confidence_low | surprise_followup | contradiction | devils_advocate | missing_t1",
      "budget_plan": { "search": 10, "fetch": 15 },
      "budget_used": { "search": 8, "fetch": 11 },
      "findings_count": 4,
      "status": "completed|aborted|budget_exceeded"
    }
  ],
  "abandoned_leads": [
    { "topic": "放弃的线索", "reason": "反爬无法验证 | 时效性不足 | 预算触顶 | 其他" }
  ]
}

硬性约束：

Spawn 前追加 agents[] 条目（填 budget_plan + spawn_reason，budget_used 和 findings_count 留空）
回传后 Lead 更新该条目的 budget_used / findings_count / status
Fork sub-sub-agent 时必须填 parent_id 和 round，识别出递归层级
主动放弃的线索写入 abandoned_leads，不得静默丢弃
报告完成后，拓扑文件连同 /tmp/ 下其他本次调研产物一并清理（synthesis 结束后 Lead 负责）

简单事实查询：Lead 自查不开 Multi-Agent 时（见 2.3），仍需生成最小拓扑文件（agents 为空，记录自查的 budget_used），保证报告拓扑段统一。

2.6 搜索执行

使用 WebSearch 进行网络搜索，使用 WebFetch 获取具体页面内容
如果命题涉及本地项目，同时用 Grep/Read 检索本地代码库和文档
搜索关键词设计：每个搜索用不同角度的关键词，避免信息重复
- 例：调研 Redis → "Redis performance benchmark 2026"、"Redis vs alternatives comparison"、"Redis use cases limitations"
并行原则：
- 同一 sub-agent 内的多个工具调用尽量并行（单次消息多个 tool call）
- 不同 sub-agent 之间通过 Lead 并行 spawn 实现跨 agent 并行
- Sub-agent 搜索策略："start broad, then narrow"——先用短宽关键词扫全景，再聚焦深挖

2.7 页面抓取策略

很多高价值网站有反爬机制，WebFetch 可能拿不到内容。采用分层抓取策略：

第 1 层（默认）：WebFetch 直接请求
    │ 成功 → 使用
    │ 失败/内容为空/返回反爬页面 ↓
    │
第 2 层（降级）：Playwright 浏览器模拟
    │ 通过 Playwright MCP 工具模拟真实浏览器访问
    │ 成功 → 使用
    │ 失败 ↓
    │
第 3 层（替代）：换源搜索
    └── 放弃该 URL，搜索同一信息的其他来源

Playwright 浏览器抓取步骤（当 WebFetch 失败时）：

playwright__browser_navigate 访问目标 URL
playwright__browser_wait_for 等待页面加载完成（等待关键内容元素出现）
playwright__browser_snapshot 获取页面可访问性快照（结构化文本内容）
如果快照不够，用 playwright__browser_evaluate 执行 JS 提取特定内容
完成后 playwright__browser_close 关闭浏览器释放资源

常见需要 Playwright 的高价值站点（非完整列表，遇到新的反爬站点时自动识别并切换）：

站点类型	示例	原因
技术文档	部分官方文档站	JS 渲染 SPA
论文平台	arXiv、Google Scholar	反爬+验证码
行业报告	各咨询公司报告页	严格反爬
社区论坛	Reddit、HN 部分页面	API 限制
新闻媒体	部分科技媒体	付费墙/反爬

抓取纪律：

同一域名连续请求间隔至少 2 秒，避免触发频率限制
优先抓取信息密度高的页面（官方文档、技术博客正文），跳过信息稀疏的页面（列表页、导航页）
如果一个站点连续 2 次抓取失败，放弃该站点，从其他来源获取同类信息
Playwright 浏览器用完即关，不保持长连接

2.8 信息记录与来源分级

搜索过程中，对每条关键信息记录：

事实内容：具体是什么
来源：URL 或文档路径
来源层级（决定引用权重）：

层级	来源类型	可信度	引用标记
一手来源	官方财报、论文原文、官方文档、实测数据、内部系统数据	高	[T1]
二手来源	媒体报道、技术博客、分析师报告、行业白皮书	中	[T2]
三手来源	社区讨论、AI 生成摘要、转引、未署名文章	低，需交叉验证	[T3]

数据属性（决定可比性）：

属性	说明
数据范围	地域、时间段、包含/排除条件
数据年份	所有数据标注来源年份
统计口径	收入确认方式、用户定义、市场边界等

来源分级规则：

核心结论必须基于至少 1 个一手来源或 2 个独立二手来源
仅有三手来源支撑的数据，标注「未经独立验证」
跨来源对比前，先检查数据口径是否一致（地域/时间/定义）
不同来源的同一指标出现显著差异时，优先采信一手来源，并在报告中标注分歧

2.9 信息验证原则

多源交叉：关键结论至少 2 个独立来源佐证
时效性：优先采用近 1-2 年的数据，标注信息的时间
去伪存真：发现信息冲突时，列出不同说法，注明分歧，优先采信一手来源 [T1]
标注不确定性：仅单一来源的信息标注"据 xxx 称"；无法验证的数据标注"未经独立验证"
假设对照：每轮 synthesis 后回顾初始假设（见 1.6），标记哪些假设已获得支撑/被削弱/证据不足

第三步：分析与结论形成

搜集完信息后，进行系统性分析，形成有判断力的结论。

3.1 信息整理

对搜集的信息去重、分类
识别共识点（多数来源一致）和争议点（来源之间有分歧）
提取关键数据点，准备用于图表展示

3.2 分析框架选择

根据调研类型和行业背景，从框架库中选择合适的分析方法。框架路由表见 references/frameworks/_index.md，各领域详细框架见 references/frameworks/<领域>.md。

此处只列选择逻辑：

选择流程：

确定调研类型 → 查通用框架推荐（frameworks/_index.md 路由表 + frameworks/general.md）
判断行业背景 → 叠加特化框架（互联网 → frameworks/internet-*.md，金融 → frameworks/finance-*.md）
判断分析视角 → 调整产出重点（券商视角重估值、咨询视角重策略、VC 视角重增长）

不确定时默认：通用底座框架（PESTEL + 竞争格局 + 价值链）+ 咨询视角

3.3 形成判断

调研报告的价值在于有判断，不只是罗列信息。

假设回顾：

逐一回顾初始假设，标注验证结果：
- ✅ 已验证（列出支撑证据及来源层级）
- ❌ 已证伪（列出反面证据）
- ⚠️ 证据不足（说明缺什么信息）
假设验证结果直接构成报告核心结论的骨架

结论要求：

对每个核心问题给出明确结论
结论必须有数据或事实支撑，标注来源层级
每个核心结论标注置信度（高/中/低），评估规则：
- 高置信度：2+ 个独立 T1 来源支撑，或 3+ 个独立 T2 来源一致，且无有力反面证据
- 中置信度：1 个 T1 或 2 个 T2 支撑，但存在部分反面证据或数据冲突
- 低置信度：仅 T2/T3 来源，或来源间存在显著分歧，或数据时效性存疑
存在不确定性时，说明条件和假设
给出可操作的建议或下一步方向

反面观点：

每个核心结论都考虑「如果反过来呢？」
列出已收集到的反面证据和反面观点
对反面观点给出回应（接受 / 反驳 / 承认不确定性）

第四步：图表生成

报告中的图表是专业性的重要体现。根据内容需要自动选择合适的图表类型，不限制数量。

报告配图不带标题：图表标题由报告正文的章节标题承担，图表本身的 title 设为空字符串。避免标题重复。

统一使用 Diagram Skill 的固化脚本（bridge.py 和 capture.py），无需安装额外依赖。

禁止手动调用 Playwright MCP 工具截图（browser_navigate、browser_take_screenshot、browser_run_code 等）。所有图表截图统一通过 bridge.py / capture.py 完成，它们内部已封装 HTTP 服务启动、ELKjs 异步等待、Retina 2x 输出等逻辑。

4.1 图表类型选择

统计图表（bridge.py 生成，JSON 配置 → PNG）：

图表	适用场景	bridge type
柱状图	离散项对比（性能、功能评分、市场份额）	`bar`
折线图	趋势变化（时间序列、版本演进）	`line`
饼图/环形图	占比构成（市场份额、成本结构）	`pie`
雷达图	多维度综合评估（产品能力雷达图）	`radar`
热力图	矩阵型数据（功能支持矩阵、相关性）	`heatmap`
散点图/气泡图	分布关系（性价比分布、性能-成本关系）	`scatter`
漏斗图	转化漏斗（用户转化、销售漏斗）	`funnel`
瀑布图	累计增减（利润变动、成本分解）	`waterfall`
矩形树图	数据占比/层级面积（市场份额、成本结构）	`treemap`
柱线混合图	柱状+折线叠加（收入趋势+增长率）	`combo`

结构图表（需要时由 Claude 直接编写 HTML + capture.py 截图，参考 Diagram skill 模板）：

图表	适用场景
流程图	工作流程、决策流程、数据流
架构图	系统架构、技术栈、模块关系
泳道图	多角色协作流程、跨系统交互
时序图	调用链路、消息传递序列
ER 图	数据库表结构、实体关系
类图	面向对象设计、接口关系
状态图	状态机、生命周期流转
思维导图	知识结构、主题发散
甘特图	项目排期、里程碑
决策树	选型决策、条件分支
网络图	网络拓扑、节点连接
组织结构图	团队架构、汇报关系
时间线	发展历程、版本演进
数据流图	数据管道、ETL 流程
C4 图	系统上下文、容器、组件视图
桑基图	流量路径、资源分配
旅程图	用户体验旅程、触点分析
Kanban	项目管理看板、任务状态
Git Graph	Git 分支工作流、合并策略

4.2 统计图表生成（bridge.py）

调用方式：

# ── Markdown 模式（默认）──
# 方式 1：JSON 文件输入
echo '<JSON配置>' > /tmp/chart-config.json
python ~/.claude/skills/diagram/scripts/bridge.py -c /tmp/chart-config.json -o docs/research/assets/<文件名>.png

# 方式 2：管道输入
echo '<JSON配置>' | python ~/.claude/skills/diagram/scripts/bridge.py -o docs/research/assets/<文件名>.png

# ── HTML 模式 ──
# 输出自包含 HTML 片段，后续直接嵌入报告
python ~/.claude/skills/diagram/scripts/bridge.py -c /tmp/chart-config.json -o /tmp/<文件名>.html -f html

JSON 配置格式：

{
  "type": "bar",
  "title": "图表标题",
  "subtitle": "副标题（可选）",
  "data": { ... }
}

各图表类型的 data 结构：

type	data 结构
`bar`	`{ "categories": [...], "series": [{"name": "名称", "values": [...]}] }`
`line`	`{ "categories": [...], "series": [{"name": "名称", "values": [...]}] }`
`pie`	`{ "items": [{"name": "名称", "value": 数值}] }`
`radar`	`{ "labels": [...], "series": [{"name": "名称", "values": [...]}] }`
`heatmap`	`{ "xLabels": [...], "yLabels": [...], "data": [[x索引, y索引, 值], ...] }`
`scatter`	`{ "xLabel": "X轴", "yLabel": "Y轴", "series": [{"name": "名称", "data": [[x, y], ...]}] }`
`funnel`	`{ "stages": [{"name": "名称", "value": 数值}] }`
`waterfall`	`{ "items": [{"name": "名称", "value": 数值, "type": "start\|increase\|decrease\|total"}] }`
`treemap`	`{ "items": [{"name": "名称", "value": 数值, "children": [...]}] }`
`combo`	`{ "categories": [...], "bars": [{"name": "名称", "values": [...]}], "lines": [{"name": "名称", "values": [...]}] }`

scatter 支持气泡图：data 中传 [[x, y, size], ...]，size 越大气泡越大。

4.3 结构图表生成（capture.py）

需要流程图、架构图等结构图时，直接编写 HTML 文件，然后用 capture.py 截图/导出：

# ── Markdown 模式（默认）──
python ~/.claude/skills/diagram/scripts/capture.py <HTML文件路径> docs/research/assets/<文件名>.png

# ── HTML 模式 ──
# 输出自包含 HTML，或直接使用手写的 HTML 源文件
python ~/.claude/skills/diagram/scripts/capture.py <HTML文件路径> /tmp/<文件名>.html -f html

HTML 编写参考 ~/.claude/skills/diagram/templates/html/ 下的模板和 lib/base.css 样式。

4.4 图表输出规范

Markdown 模式：

输出保存到 docs/research/assets/ 目录
文件名格式：<报告名>-<图表描述>.png，例如 redis-benchmark-bar.png
默认 2x Retina 输出，确保清晰度
禁止 Read PNG 文件：生成后只通过 ls -la 确认文件存在和大小，不要用 Read 工具查看 PNG，避免图片加载到会话上下文触发多图尺寸限制

HTML 模式：

图表暂存 /tmp/ 目录，后续直接读取 HTML 内容嵌入报告
不生成 PNG，不需要 assets 目录
用 Read 工具读取生成的 HTML 文件，提取 <body> 内的 SVG/图表内容嵌入报告

通用：

图表必须包含：标题、坐标轴标签（统计图）、图例（多系列时）

4.5 图表嵌入

Markdown 模式：用相对路径引用 PNG：

![Redis vs Memcached 读写性能对比](assets/redis-benchmark-bar.png)

HTML 模式：直接嵌入图表 HTML 片段，用 .chart-container 包裹：

<div class="chart-container">
  <div class="chart-inner">
    <!-- 此处粘贴 bridge.py -f html 输出的 SVG 或图表 HTML -->
  </div>
  <p class="chart-caption">图表说明文字</p>
</div>

每张图表紧跟在相关分析文字之后，配简要说明文字解读图表要点。

4.6 轻量图示：terminal / flow 代码块

报告中不是所有"流程/命令"都值得调 bridge.py / capture.py。以下两类直接写成 Markdown 代码块，preview-md / HTML 报告会自动渲染为带样式的图示：

```flow：方法论流程、决策树、阶段串联（≤ 10 个节点）
- 适用：调研方法论示意、筛选流程、评估决策路径
- 复杂多分叉流程仍调 bridge.py 画真正的流程图
```terminal：调研中执行的关键命令、CLI 输出示例
- 适用：附录的复现步骤、benchmark 命令、数据抓取脚本展示
- 单条命令仍用普通 ```bash

完整语法和示例见 preview-md SKILL.md "扩展语法"章节。

选型决策：

需要图示？
↓
数据可量化？→ bridge.py（柱状/折线/饼图等）
↓
结构复杂或多角色？→ capture.py（流程/时序/架构图）
↓
轻量流程/命令展示 → ```flow / ```terminal 代码块

第五步：撰写报告

5.1 报告输出位置

Markdown 模式（默认）：

docs/research/
├── YYYY-MM-DD-<命题关键词>.md    ← 报告正文
└── assets/
    ├── <报告名>-<图表1>.png
    ├── <报告名>-<图表2>.png
    └── ...

HTML 模式：

docs/research/
└── YYYY-MM-DD-<命题关键词>.html  ← 自包含 HTML 报告（图表内嵌，无 assets）

5.2 报告组成：组件驱动，不预设模板

报告结构由内容形态决定——先看手上有什么内容，再调对应组件，自然组合成文。不预设"必备章节"，不按调研类型套模板。

组件库：references/report-blocks.md 是调研报告的组件库（一句话结论 / Executive Summary / 现状基线 / 假设验证表 / 反面观点 / 置信度标注 / 对比表 / 评分雷达 / 场景化推荐 / 调查拓扑 / 来源分级等）。通用组件（表格 / 卡片 / Timeline / Callout / Chart）复用 writing skill 的 references/components.md，本 skill 不重复。

内容形态 → 组件速查

你手上有什么内容	调哪个组件
一句话能说清的核心判断	一句话结论（report-blocks A1）
3-5 条要点决策者得先看到	Executive Summary（A2）
调研投入数据需要被看见	报告头元信息（A3）+ 调查拓扑表（E1）
内部数据 + 外部基准对比	现状基线段（B1）；无内部数据用 B2 一行 callout
走完了 1.6 假设流程	假设验证表（C1）
收到了真实反方证据	反面观点与回应（C2）
结论置信度有差异	结论 + 置信度标注（C3）
多方案多维度对比	对比表（D1）+ 评分雷达（D2，≥3 维度时）
结论不应一刀切	场景化推荐表（D3）
跨来源数据有口径差异	口径说明 callout（E2）
引用了多个来源	来源分级参考资料（F1）+ 行内标注（F2）
大段数据 / 趋势	Chart-Container + bridge.py
多角色流程 / 架构关系	Chart-Container + capture.py
多发展阶段	Timeline（writing skill）
关键数字独立强调	Metric-Card（writing skill）

组合原则

内容 → 组件 → 组合         ✅ 内容驱动
调研类型 → 模板 → 填空    ❌ 模板驱动

最小集：任何出报告的场景至少包含"一句话结论 + 参考资料"，其余按内容叠加
没内容就不要用对应组件：没有反面证据就不要"反面观点"段；没有内部数据就不要"现状基线"段（用 B2 一行说明即可）；没有多个候选就不要"对比表"
组件克制：单份报告不堆叠 ≥10 种组件，否则变成"组件展示馆"
顺序由内容逻辑决定：通常的逻辑链是"读者先看结论 → 看依据 → 看反驳 → 看建议 → 验证过程"——但按命题自然调整，不强制
复杂度参考（不是规则）：
- 简单事实查询：不出报告，直接对话答复
- 对比类：一句话结论 + 关键发现 + 对比块 + 场景化推荐 + 参考资料；假设验证 / 反面观点 / 调查拓扑按内容选用
- 复杂研究 / 超深度：通常覆盖到 A1/A2/A3/B1/C1/C2/C3/E1/F1 + 正文用通用组件组装

历史范式（仅作为灵感参考）

references/templates/_common.md 收录了少量历史常见的章节顺序示例——只作为"别人通常怎么组合"的参考，不作为必备清单。直接看 report-blocks.md 选组件即可，不需要先选模板。

5.3 HTML 模式报告撰写

当输出格式为 HTML 时，参照 references/html-report-template.html 模板直接编写 HTML 报告。

写作流程：

Read 模板：读取 references/html-report-template.html，复制完整 HTML 结构（含 CSS + JS）
填充报告头：替换 {{REPORT_TITLE}} 等占位符
编写 Executive Summary：填入 .exec-summary 区域
编写正文：在 <article> 标签内用 <h2>/<h3> 组织章节（目录 JS 自动提取）
嵌入图表：将 bridge.py/capture.py 生成的 HTML 图表内容读取后，用 .chart-container 包裹嵌入
填写参考资料：在 .references 区域按 T1/T2/T3 分组

可用的富文本组件（模板注释中有完整示例）：

组件	类名	适用场景
图表容器	`.chart-container`	嵌入 SVG/HTML 图表
卡片网格	`.card-grid` + `.card`	方案速览、关键发现并列展示
评分条	`.score-bar`	多维度量化评估（如性能/生态/成本）
对比块	`.vs-block` + `.vs-col`	方案 A vs B 双栏对比
时间轴	`.timeline` + `.tl-item`	路线图、技术演进
行内徽章	`.badge`	表格/标题中的状态标签
提示框	`.callout`	关键发现、警告、提示
来源徽章	`.tier-badge`	数据来源层级标注

引用标注（HTML 模式）：

数据描述<sup><a href="#ref-1">1</a></sup><span class="tier-badge tier-t1">T1</span>

输出要求：

单个 .html 文件，所有 CSS/JS 内联，浏览器直接打开
用 Write 工具一次性写入 docs/research/YYYY-MM-DD-<topic>.html
写入后用 open 命令在浏览器中打开供用户 review

5.4 引用标注（Markdown 模式）

正文中使用上标编号标注数据来源，指向末尾参考资料列表（不使用脚注，避免脚注和参考资料重复）：

Redis 在高并发场景下的 p99 延迟通常低于 2ms[1]，
而 Memcached 在相同条件下约为 1.5ms[2]。

末尾参考资料按来源层级分组，编号与正文对应：

## 参考资料

### 一手来源 [T1]
1. [Redis 官方 benchmark 文档](https://redis.io/docs/...) — p99 延迟数据

### 二手来源 [T2]
2. [InfoQ Redis vs Memcached 性能对比](https://www.infoq.cn/...) — 对比测试数据

引用原则：

关键数据点必须标注来源及层级 [T1]/[T2]/[T3]
观点性结论标注出处
多个来源佐证同一结论时，标注最权威的 1-2 个（优先一手来源）
只在末尾参考资料列表维护一份引用，正文用编号指向，不重复

5.5 写作要求

语言：默认中文，用户要求时切换为英文
措辞精确：避免"大概"、"好像"、"可能"等模糊用语，除非确实存在不确定性（此时需说明原因）
数据优先：能用数据说明的不用形容词，"快 3 倍"优于"显著更快"
结构清晰：善用表格、列表、对比矩阵呈现结构化信息
篇幅自适应：根据命题复杂度自然决定篇幅，不人为压缩也不注水

第六步：质量自检

报告写完后，自动执行以下 5 项检查。可自动修复的问题直接修复，需要判断的列出供用户决定。

6.1 检查维度

检查 1：内容覆盖（组件适配）

不再检查"必备章节是否齐全"，改为检查 1.1-1.6 中识别出的内容形态是否都有对应组件承载——避免"忘了写"，但不强求模板。

内容形态（在调研中是否存在）	应有的组件	检查方式
调研得出了核心判断	一句话结论（report-blocks A1）	报告首句存在结论性表述
决策者需要快速看到 3-5 个要点	Executive Summary（A2）	存在 ≤500 字 summary 段
命题完整走了 1.6 假设流程	假设验证表（C1）	表存在，1.6 列出的假设逐一出现
1.4 摸到了内部数据	现状基线段（B1）	段存在并区分内部/外部
1.4 无内部数据	缺失声明 callout（B2）	一行 callout 标注公开数据
搜集中找到了反方证据	反面观点与回应（C2）	段存在，每条配回应
多个结论且置信度不一	结论 + 置信度标注（C3）	每条结论带置信度 + 来源层级
走了 Multi-Agent	调查拓扑表（E1）	指标表 + sub-agent 分解，与拓扑文件对账
有引用来源	来源分级（F1）	按 T1/T2/T3 分组，每条带层级

处理方式：

内容形态存在但组件遗漏 → 终端提示，列出哪些内容没装进组件
没有对应内容形态 → 跳过检查，不要"为了齐全"补章节（例如调研中没有反方证据就不要写"反面观点"段，没有内部数据就不要写"现状基线"段）
自动可修复项：仅"结论后未标注置信度"、"来源未分级"——其他靠人补

检查 2：引用格式

逐条扫描参考资料章节，检查：

参考资料是否按「一手来源 [T1]」「二手来源 [T2]」「三手来源 [T3]」三级分组
每条引用是否有 [T1]/[T2]/[T3] 层级标记
每条引用格式是否为 [标题](URL) — 引用说明
正文中引用关键数据时是否标注了来源编号

处理方式：可自动修复。

缺少分组 → 按来源类型自动归类到 T1/T2/T3
缺少层级标记 → 根据来源类型自动补充
格式不符 → 自动调整为标准格式
修复后在终端展示修复摘要

检查 3：假设验证表

检查假设验证表的完整性：

报告中是否存在假设验证结果表格
1.6 中提出的每个初始假设是否都在表中出现
每行是否包含三列：假设内容 | 验证结果（✅/❌/⚠️）| 关键证据及来源层级

处理方式：

表存在但个别行缺少结果标记或来源标注 → 自动补充格式占位（如 ⚠️ 待补充），在终端提示
表不存在 → 在终端提示「缺少假设验证表」，询问用户是否根据全文内容生成

检查 4：核心结论来源支撑

逐条检查「核心结论」章节中的每个结论：

该结论引用的证据来源层级是什么？
是否满足：至少 1 个 T1 来源 或 至少 2 个独立 T2 来源
仅有 T3 来源支撑的结论标记为不达标

处理方式：不可自动修复。在终端逐条列出不达标结论及其当前来源情况，询问用户是否补充搜索。

检查 5：调查拓扑段完整性

核对报告的"调查拓扑"段与 /tmp/research-topology-<timestamp>.json 记录文件：

报告是否包含 ## 调查拓扑 段
指标表的"派发 Sub-agent 数 / 最深递归层级 / 总 search / 总 fetch"与拓扑文件聚合值一致
Sub-agent 分解表中每条 agent_id / parent_id / budget_used / status 字段与拓扑文件一致，不得遗漏
abandoned_leads 非空时，报告必须列出"放弃的线索"子节
报告头元信息中的"调研深度"数字与拓扑段聚合值一致