| name | deep-research |
| description | 验证型调研：多Agent并行、Tier 1-4信源交叉验证、可追溯，产出决策备忘录。
适用：要做决策的调研（该选A还是B、X靠不靠谱、帮我验证）、技术评估、方案对比、行业可行性。
不适用：了解来龙去脉/叙事型报告→narrative-research。
触发词：深度调研、帮我调研、evaluate、该选哪个、靠不靠谱、对比一下、competitive analysis。
|
| version | 3.1.0 |
深度调研工作流
搜索工具（Claude Code 环境强制）
本工作流全程 10-30+ 次搜索。在 Claude Code 里，主控和所有 sub-agent 一律用 tavily-skill CLI（file 模式，结果落盘不进上下文），不要用 Tavily MCP，也不要用裸 WebSearch——那是 CLAUDE.md → Web Search Routing 点名的 token 泄漏反模式：
~/.claude/skills/tavily-skill/.venv/bin/tavily-skill search "query" --output ./tmp/tavily/<slug>.json
非 Claude Code 环境（无此 CLI）再退回宿主自带的搜索工具。
核心原则
- 激励感知验证: 信息价值取决于来源的激励结构。厂商叙事有用但不能自证。每个主要 claim 都必须追溯到与发布方激励无关的独立证据。
- 交叉验证: 多个 sub-agent 覆盖有重叠的主题，用分歧和矛盾暴露盲区。
- 可追溯性: 所有引用保留 URL，关键引用保留原文摘录，不依赖总结。
- 逐步聚焦: 先扫描全貌，提取 claim，再分维度深入验证。
- 单一主交付 + 可复用工件: 最终报告一份，关键中间工件存入 session 目录。
- 共享 research spine，分叉 reader mode: 搜索、验证、工件留存共享；成稿前按读者决定 internal / external mode。
信息源层级
| 层级 | 类型 | 使用方式 |
|---|
| Tier 1 | 厂商官方文档、blog、case study | 提取 claim，不做验证依据 |
| Tier 2 | Press coverage、sponsored review | 辅助理解市场叙事，不作为独立证据 |
| Tier 3 | 独立开发者 blog、HN/Reddit、Stack Overflow | 作为验证信号，注意社区偏差 |
| Tier 4 | GitHub issues、migration stories、production post-mortems、commit history | 最高可信度，行为证据而非态度表达 |
证据可信度递增：态度表达 < 使用场景描述 < 对比决策记录 < Migration stories < Production post-mortems < 代码/commit 级证据。优先收集后半部分。
Claim 类型 ↔ 证据类型匹配——来源可以很有名，但仍然是错误类型的证据：
| Claim 类型 | 对口证据类型 |
|---|
| 产品功能/特性 | 官方文档、源码 |
| 法规/合规 | 官方法律文本、监管机构发布 |
| 科学有效性 | 同行评审论文、meta 分析 |
| 市场趋势/规模 | 财报、监管披露文件 |
| 运营故障/可靠性 | Incident 报告、post-mortem |
两种 Reader Mode
Mode A：Internal（共享上下文驱动的决策备忘录） — 读者是自己或共享上下文的协作者。不复述共同常识；重点展开会改变结论的未知点、最可能被反对的点。
Mode B：External（零预设上下文的可发布论证） — 读者不是已知对象。必须显式回答 why this matters；关键定义和限定条件写在页面上。
先问三个问题再选 mode：(1) 读者是否已知且共享厚重上下文？(2) 主要价值是帮对方更快判断还是让对方理解并相信？(3) 拿掉私有背景后报告能否独立成立？
Mode B 动笔前多问一句：这个话题对目标读者是 现在相关 / 未来相关 / 大概率不相关？"当下不相关"本身是一个合法论点——如果诚实答案是"不是现在"，论点就应该这么写，而不是堆砌一堆看似紧迫的案例去暗示短期利害。
Phase 1: 初步扫描 + Claim 提取
- 用 Tavily 进行 2-3 次搜索，覆盖：
- 调研对象的基本描述（Tier 1 官方信息）
- 市场评价和媒体报道（Tier 2 市场叙事）
- 批评、争议、已知问题（Tier 3-4 信号）
- 总结 3-5 个需要深入调研的维度。
- Claim 提取：列出关键主张，对每个 claim 标注验证通道。
输出: tmp/<session_slug>/scratchpad.md，含 claim extraction 表格：
| Claim | 来源 (Tier) | 验证通道 | 验证状态 |
|-------|-------------|----------|----------|
| "zero-config" | Tier 1 官方 | GitHub issues 搜 setup pain | 待验证 |
Phase 1.5: Prior-Work 定位
仅当调研对象是一篇论文或一组论文时执行；产品、公司、行业话题跳过本阶段。
-
列 prior-work 对照表：
| Prior work | 做了什么 | 没做什么 | 本文声称的增量 |
|---|
| ... | ... | ... | ... |
-
对每个 prior work 做外部核实：查它自己的论文/repo/评测确认真实覆盖范围，不能只读本文 related work 一节的转述。
-
基于核实结果判断增量大小：本文相对已核实的 prior work 边界，实际新增的是什么、有多大。
-
定位档位（默认 C）：领域背景 30-40% + 本文 60-70%；读者对领域越陌生，越往 A 方向（更高领域背景占比）偏移。
三个常见错误模式：
- 把本文 related work 一节的框架当成事实——那是作者的叙事，不是核实结果
- 用本文"声称做到 X"衡量增量，而不是用实验结果衡量
- 100% 写本文、0% 领域背景，读者没有坐标判断这个增量是否重要
Phase 2: 分割与并行调研
按证据功能设计维度（不只是按主题）：
- 官方叙事（Tier 1-2）
- 独立使用体验（Tier 3）
- 失败与边界（Tier 3-4）
- 迁移行为（Tier 4）
维度之间必须有 ≥50% 的 overlap，让不同 agent 有机会发现矛盾。
启动 3-5 个 sub-agent，每个 prompt 中明确：
- 具体调研主题
- 本维度相关的 claim（要求在 Tier 3-4 源中验证）
- 优先返回行为证据，而非态度表达
- 必须返回 URL 和原文摘录
- 可以覆盖的其他相关维度（形成 overlap）
Tavily 参数: CLI 默认即为 --max-results 6 --search-depth advanced --answer off，无需显式传参；sub-agent prompt 里带上「搜索一律用 tavily-skill CLI --output 落盘」
Phase 3: 整合与交叉验证
- 对比各 sub-agent 结果：多个发现 → 可信度高；单一来源 → 标注；互相矛盾 → 特别标注
- 对每个 claim 核查验证状态：
- Tier 3-4 有独立证据 → 已验证
- 仅 Tier 1-2 → "仅 vendor source，未独立验证"
- Tier 3-4 与 Tier 1-2 矛盾 → 以 Tier 3-4 为准
- 如发现重大矛盾，可再启动 sub-agent 针对性验证。
Phase 3.3: 溯源与事实核查
从整合结果里挑 5-10 个承载核心论点的来源：直接支撑主论点的、看似矛盾的、带关键数字的、可信度存疑的。
- 用 tavily-skill CLI 重新抓取这些来源的原文（不是 sub-agent 的转述）：
~/.claude/skills/tavily-skill/.venv/bin/tavily-skill extract "<URL>" --output ./tmp/<session_slug>/extract/<slug>.json
- 逐条核对：转述有没有偏离原意、有没有丢限定词（"约"、"仅适用于"、"在某些条件下"）、URL 是否指向正确页面、数字精度是否和原文一致。
- 记录到
tmp/<session_slug>/fact_check.md，每条给 verdict（一致 / 部分偏差 / hallucination）+ 原文摘录。
硬规则：永远不用一个 sub-agent 的总结去验证另一个 sub-agent 的总结——都要落到原文。核心来源被证伪 → 阻塞写作，回 Phase 2 针对性重新调研，不得带着已知造假的支撑点继续写。
Phase 3.5: 红队论点 + 决定 Reader Mode
有明确论点（thesis-bearing）的调研才跑红队环节；纯事实汇总类调研可跳过红队，直接做 reader mode 决定。
- 写
tmp/<session_slug>/brainstorm_brief.md：论点、已验证事实、不确定 claim、反例、目标读者、约束条件。
- 启动角色化 sub-agent（evidence skeptic / target reader / decision maker），每个都回答同样四个问题：论点的最强表述是什么？最薄弱的前提是什么？有哪 3-5 项需要重新核查？什么证据会推翻这个论点？
- 汇总三方回答，提炼候选论点（可能不止一版）。
- 针对最薄弱前提，跑一轮范围收窄的 round 2——只攻击那个前提，不重新扫全局；新来源追加进来源索引。
Reader Mode 决定：写进 scratchpad：mode、目标读者、哪些前提可默认共享、哪些必须显化。
Phase 4: 撰写最终报告
动笔前穿透检查：
- 每个主要正面判断是否至少有一个 Tier 3+ 独立证据源？
- 找不到独立支撑的判断 → 显式标注"此点仅有 vendor source"
- 是否同时呈现了 vendor narrative 和 independent reality？
Internal mode 写作顺序: 结论 → 关键依据 → 未确认点 → 建议动作
External mode 写作顺序: Why it matters → 核心判断 → 背景与定义 → 分维度证据 → 边界与反例 → 决策意义
确定性引用校验（交付前必跑）：
python3 ~/.claude/skills/deep-research/scripts/verify_citations.py <报告.md> --sources tmp/
脚本在本 skill 的 scripts/ 目录下（Codex 环境把 ~/.claude 换成 ~/.codex）。它用 URL 签名（域名+路径前段）把报告里每条引用对到 tmp/ 落盘的搜索结果和笔记的 URL 池，抓虚构 URL、空链接/悬空引用、汇总与正文不一致、单一来源集中（>25%）。critical 必须修复后重跑，exit 0 才能交付；warning 逐条人工判断（同域不同文的要确认是不是同一篇）。
存储: contexts/survey_sessions/<topic>_survey_YYYYMMDD.md
续研（Round 2+）
同一课题的后续调研不重跑全流程、不重写全文：
- 复用
tmp/<session_slug>/：读旧 scratchpad 和 claim 表，明确上轮「未验证 / 仅 vendor source」的遗留点
- Claim 表增量扩展：新 claim 追加行，旧 claim 更新验证状态（含「已验证 → 被新证据推翻」）
- 只对新维度和新矛盾点启动 sub-agent，已验证结论不重复搜索
- 交付 delta memo 而非重写全文：变化了什么 / 新证据 / 对既有结论的影响 / 剩余不确定性
URL 留存规范
必须保留 URL：直接引用、数据来源、评价来源、官方信息。正文引用用 inline [来源](URL) 或如下格式，报告末尾加 ## 来源汇总 列出全部来源 URL——引用校验脚本按此结构检查。
**来源描述**（URL）
> 原文摘录
避免：无 URL 的引用（"有人评价说..."）、只总结不引用原文。
常见陷阱
| 陷阱 | 对策 |
|---|
| 只搜到正面信息 | 专门搜 "criticism", "negative review", "scam" |
| 为反而反（强行 contrarian） | 无真实主流叙事可反驳时，不得为反而反；改为交付一个决策相关的非显然洞察 |
| 信息来源单一 | 强制要求 sub-agent 找多个独立来源 |
| 过度总结丢失细节 | 保留原文摘录 |
| 维度划分太干净没有 overlap | 故意让边缘模糊 |
| Sub-agent 返回太浅 | prompt 中强调"深度"、"具体"、"原文" |
| 调研变成 vendor marketing 汇总 | Phase 1 提取 claim → Phase 2 分维度验证 → Phase 3 核查 → Phase 4 穿透检查 |
| internal 误用为"可以不解释" | 共同常识跳过，读者不熟悉的要展开 |
