deep-research验证型调研：多Agent并行、Tier 1-4信源交叉验证、可追溯，产出决策备忘录。 适用：要做决策的调研（该选A还是B、X靠不靠谱、帮我验证）、技术评估、方案对比、行业可行性。 不适用：了解来龙去脉/叙事型报告→narrative-research。 触发词：深度调研、帮我调研、evaluate、该选哪个、靠不靠谱、对比一下、competitive analysis。
Independent GitHub snapshot · Automated classification · Original documentation governs
本工作流全程 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）再退回宿主自带的搜索工具。
| 层级 | 类型 | 使用方式 |
|---|---|---|
| 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 |
Mode A：Internal（共享上下文驱动的决策备忘录） — 读者是自己或共享上下文的协作者。不复述共同常识；重点展开会改变结论的未知点、最可能被反对的点。
Mode B：External（零预设上下文的可发布论证） — 读者不是已知对象。必须显式回答 why this matters；关键定义和限定条件写在页面上。
先问三个问题再选 mode：(1) 读者是否已知且共享厚重上下文？(2) 主要价值是帮对方更快判断还是让对方理解并相信？(3) 拿掉私有背景后报告能否独立成立？
Mode B 动笔前多问一句：这个话题对目标读者是 现在相关 / 未来相关 / 大概率不相关？"当下不相关"本身是一个合法论点——如果诚实答案是"不是现在"，论点就应该这么写，而不是堆砌一堆看似紧迫的案例去暗示短期利害。
输出: tmp/<session_slug>/scratchpad.md，含 claim extraction 表格：
| Claim | 来源 (Tier) | 验证通道 | 验证状态 |
|-------|-------------|----------|----------|
| "zero-config" | Tier 1 官方 | GitHub issues 搜 setup pain | 待验证 |
仅当调研对象是一篇论文或一组论文时执行；产品、公司、行业话题跳过本阶段。
列 prior-work 对照表：
| Prior work | 做了什么 | 没做什么 | 本文声称的增量 |
|---|---|---|---|
| ... | ... | ... | ... |
对每个 prior work 做外部核实：查它自己的论文/repo/评测确认真实覆盖范围，不能只读本文 related work 一节的转述。
基于核实结果判断增量大小：本文相对已核实的 prior work 边界，实际新增的是什么、有多大。
定位档位（默认 C）：领域背景 30-40% + 本文 60-70%；读者对领域越陌生，越往 A 方向（更高领域背景占比）偏移。
三个常见错误模式：
按证据功能设计维度（不只是按主题）：
维度之间必须有 ≥50% 的 overlap，让不同 agent 有机会发现矛盾。
启动 3-5 个 sub-agent，每个 prompt 中明确：
Tavily 参数: CLI 默认即为 --max-results 6 --search-depth advanced --answer off，无需显式传参；sub-agent prompt 里带上「搜索一律用 tavily-skill CLI --output 落盘」
从整合结果里挑 5-10 个承载核心论点的来源：直接支撑主论点的、看似矛盾的、带关键数字的、可信度存疑的。
~/.claude/skills/tavily-skill/.venv/bin/tavily-skill extract "<URL>" --output ./tmp/<session_slug>/extract/<slug>.json
tmp/<session_slug>/fact_check.md，每条给 verdict（一致 / 部分偏差 / hallucination）+ 原文摘录。硬规则：永远不用一个 sub-agent 的总结去验证另一个 sub-agent 的总结——都要落到原文。核心来源被证伪 → 阻塞写作，回 Phase 2 针对性重新调研，不得带着已知造假的支撑点继续写。
有明确论点（thesis-bearing）的调研才跑红队环节；纯事实汇总类调研可跳过红队，直接做 reader mode 决定。
tmp/<session_slug>/brainstorm_brief.md：论点、已验证事实、不确定 claim、反例、目标读者、约束条件。Reader Mode 决定：写进 scratchpad：mode、目标读者、哪些前提可默认共享、哪些必须显化。
动笔前穿透检查：
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
同一课题的后续调研不重跑全流程、不重写全文：
tmp/<session_slug>/：读旧 scratchpad 和 claim 表，明确上轮「未验证 / 仅 vendor source」的遗留点必须保留 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 误用为"可以不解释" | 共同常识跳过，读者不熟悉的要展开 |