---
name: sn-dimension-research
description: "[sn-deep-research 子阶段] 按 plan.json 中的维度定义执行单维度多源搜索、证据筛选、交叉验证，输出 sub_reports/{dimension_id}.md。通常由 sn-deep-research 自动调用。"
---

# Dimension Research

产出一个维度的 `sub_reports/{dimension_id}.md`。它把 `plan.json` 中的一个维度研究扎实，并在子报告内保留精简证据记录；不负责规划维度、综合所有维度或写最终报告。

完成本 skill 必须落盘两个结果：`sub_reports/{dimension_id}.md`、更新该维度 `status` 后的 `plan.json`。只在对话中说明研究结果不算完成。

它的核心职责不是“跑一次搜索”，而是把一个维度需要的不同来源拼成可判断的证据面：先做广度发现，再做专项深挖，最后回到原始来源核验，决定哪些材料保留、哪些材料丢弃、哪些结论需要交叉确认、哪些空白必须显式保留。

## 行为边界

做：

- 读取一个 dimension 的 `key_questions`、`method`、`search_strategy`、`expected_output`。
- 按 `search_strategy` 选择合适的搜索 skill 或检索入口，多轮搜索并覆盖计划指定的来源类型。
- 判断来源可信度，优先追溯原始来源。
- 对关键事实做交叉验证，记录冲突和信息缺口。
- 判断是否满足 `search_strategy.sufficiency`。
- 写入带精简证据记录的维度子报告，并更新 `plan.json` 中该维度 `status`。

不做：

- 不修改研究目标和报告格式。
- 不重写整个 `plan.json`，除非当前维度缺少必要搜索策略。
- 不写中间综合文件或 `report.md`。
- 不把单次搜索结果直接改写成子报告。
- 不编造来源，不把未确认事实写成确定结论。

## 输入

- `{report_dir}/request.md`
- `{report_dir}/plan.json`
- 当前 dimension id
- 依赖维度的 `sub_reports/*.md`，如 `depends_on` 非空

## 搜索模型

把单维度研究理解成三层搜索模型：

1. **广度发现**：先用通用搜索快速摸清这个维度的来源地图，识别关键实体、术语、机构、时间点、争议点和候选来源类型。
2. **专项深挖**：对已经识别出的重点来源类型，调用相应专门搜索 skill 做更高召回、更高精度、更结构化的深挖。
3. **原始核验**：对关键事实、关键数字、关键时间点和高风险判断，优先回到原始来源确认。

通用搜索不是低配兜底，而是默认的广度发现层。专门搜索 skill 不是必须前置，而是对重点来源类型的深挖工具。最终可信度取决于来源本身，而不是搜索入口本身。

## 搜索技能分工

`sn-dimension-research` 是编排层，不需要自己囊括所有平台细节；它应根据 `source_types` 和当前维度性质，选择合适的搜索 skill 或原生浏览能力。

优先按下面方式路由：

- **学术论文、综述、百科、引用追溯**：使用 `sn-search-academic`
- **开源代码、技术问答、模型/数据集、工程社区**：使用 `sn-search-code`
- **中文社区讨论、中文视频平台、用户经验反馈**：使用 `sn-search-social-cn`
- **英文社区讨论、英文视频平台、英文舆情反馈**：使用 `sn-search-social-en`
- **官方网页、监管公告、公司披露、产品文档、新闻报道、机构页面**：使用通用网页检索与页面打开能力

如果一个维度同时需要多种来源，不要只选一个 skill；应按证据需要组合使用。

如果某类来源暂时**没有对应的专门搜索 skill**，不要因此跳过该来源类型；继续用通用搜索完成广度发现和基础覆盖。只有当该来源类型对当前维度非常关键、且通用搜索无法满足深挖需要时，才把它记为覆盖限制。

## 来源优先级

多源搜索不是“来源越多越好”，而是“证据层次要够”。优先级通常是：

1. 原始来源：官方文件、监管公告、论文原文、公司披露、产品文档、数据库原始记录
2. 高可信二级来源：权威机构报告、顶级媒体、行业组织、研究机构、系统综述
3. 补充来源：社区讨论、问答、社交平台、视频、博客

社区和社交来源主要用于：

- 发现真实使用反馈
- 暴露争议点
- 补充术语、案例、边缘问题
- 生成下一轮检索线索

不要让社区讨论替代原始来源。

通用搜索在这里主要承担：

- 发现候选来源
- 暴露争议点和下一轮搜索线索
- 帮你决定哪些来源类型值得进入专项深挖
- 快速补足跨来源视角

专门搜索 skill 在这里主要承担：

- 在某一来源类型内提高召回
- 提供更结构化的结果字段
- 支持更细的筛选、排序和引用追溯
- 减少在高价值来源中的漏检

## 执行流程

1. **读取任务**：从 `plan.json` 找到当前维度，确认 `key_questions`、`method`、`search_strategy`、`expected_output`。
2. **补齐搜索策略**：如果缺少 `search_strategy`，先为当前维度补写 `source_types`、`seed_queries`、`freshness_requirement`、`sufficiency`，再执行。
3. **广度发现**：先从 `seed_queries` 开始，用通用搜索和必要的初始入口摸清这个维度的来源地图；记录新实体、术语、机构、年份、争议点和候选来源类型。
4. **选择深挖方向**：判断哪些来源类型最可能回答 `key_questions`，再决定是否调用专门搜索 skill 深挖。
5. **专项深挖**：按 `source_types` 对重点来源类型做定向搜索；必要时组合学术、官方、新闻、社区、代码等多种来源。
6. **筛选证据**：保留能回答 `key_questions` 的材料；丢弃营销软文、二手转述、来源不明、内容过短或与维度无关的材料。
7. **原始核验**：关键事实优先找原始来源；高风险事实至少用两个独立来源确认。冲突无法解决时记录冲突和可能原因。
8. **判断充分性**：逐条检查 `search_strategy.sufficiency`。未满足时继续检索或明确记录信息缺口。
9. **整合判断**：把保留材料整理成“发现、冲突、限制、仍待回答的问题”，不要把搜索结果原样堆进子报告。
10. **落盘**：写入 `sub_reports/{dimension_id}.md`，并把该维度 `status` 更新为 `done`。
11. **确认**：读取上述两个文件，确认子报告非空且包含证据记录，`plan.json` 中该维度已标记 `done`。

## 搜索路由建议

可按维度类型快速选择入口：

| 维度类型 | 优先来源 | 推荐入口 |
|---|---|---|
| 学术 / 医学 / 方法论 | 先用通用搜索找论文线索，再进论文、综述、百科、引用链 | `sn-search-academic` |
| 技术实现 / 开源生态 / 模型工具 | 先发现关键项目和问题域，再进 GitHub、Stack Overflow、HuggingFace、HN | `sn-search-code` |
| 用户反馈 / 社区体验 / 中文舆情 | 先发现平台/话题，再进 B站、知乎、抖音 | `sn-search-social-cn` |
| 海外社区 / 英文舆情 / 视频解释 | 先发现关键词和社区，再进 Reddit、X、YouTube | `sn-search-social-en` |
| 政策 / 监管 / 公司 / 产品 / 新闻 | 先发现机构、法规、事件节点，再进官方网站、公告、公司页、新闻站 | 通用网页检索 |

若 `source_types` 里出现“官方文件 + 社区讨论”这类组合，至少覆盖一个高可信原始来源和一个补充来源，不要只停留在其中一侧。

如果某行对应的专门 skill 暂时不存在，就把“推荐入口”理解为“优先搜索方向”，继续以通用搜索完成发现与基础覆盖。

## 搜索充分性

最低要求：

- 每个 `key_questions` 都有材料支撑，或明确标注信息缺口。
- 至少执行两轮检索；第一轮以广度发现为主，后续轮次应基于上一轮发现扩展关键词或来源类型。
- 对比、趋势、政策、市场、公司、产品类维度至少覆盖两种来源类型。
- 重要维度应至少覆盖“广度发现 + 原始核验”两层；若存在高价值专门入口，优先再加一层专项深挖。
- 涉及最新信息时，必须核查最新可得资料并写明时间范围。
- 连续两轮没有产生新关键事实，才可视为信息趋于饱和。

如果由于缺少专门搜索 skill 导致某类来源无法做专项深挖，仍可继续研究，但只在下列情况把它视为显著限制：

- 该来源类型对当前维度是核心证据面
- 通用搜索已经明显无法继续提升发现质量
- 缺少这类深挖会显著影响结论强度

满足最低要求仍不代表结论确定；不确定性要写入子报告。

## 精简证据记录

把必要追溯信息压缩进子报告：

- `搜索覆盖情况`：说明广度发现用了什么入口、专项深挖用了哪些搜索 skill、原始核验回到了哪些来源类型。
- `搜索覆盖情况`：只写来源类型、轮次、关键扩展词和停止理由，不写完整查询流水。
- `证据记录`：用表格列出保留材料，每个关键材料一行；通常 5-12 行即可。
- `充分性判断`：说明已覆盖问题、未覆盖问题、交叉验证情况、信息缺口，以及是否仍有本应深挖但未能深挖的关键来源类型。

证据记录表格式：

```markdown
| 材料/来源 | 来源类型 | 关键支撑 | 覆盖问题 | 可信度/限制 |
|---|---|---|---|---|
```

## 子报告格式

写入 `{report_dir}/sub_reports/{dimension_id}.md`：

```markdown
# {dimension_id}. {维度名称}

## 本维度要回答的问题

## 搜索覆盖情况

说明覆盖了哪些来源类型、执行了哪些轮次、停止理由是什么。

## 证据记录

用精简表格列出本维度保留的关键材料，不写完整搜索流水。

## 关键发现

只写本维度内有材料支撑的发现。

## 分析

解释发现之间的关系、因果、差异、趋势或约束。

## 对终稿的贡献

说明本维度能为 report 提供什么判断依据、表格、风险点或结构材料。

## 不确定性与空白

说明信息缺口、冲突事实、口径限制、时效风险。

## 需要后续维度承接的问题
```

## 质量门槛

- 子报告中的每个关键发现都能追溯到本报告的证据记录。
- 每个 `key_questions` 在子报告中被回答、部分回答或标注无法回答。
- 不确定性和冲突不被抹平。
- `status=done` 只能在子报告已写入且包含证据记录后更新。
- 更新 `status=done` 后必须再次读取 `plan.json` 确认。
- 子报告不写终稿摘要，不跨越本维度范围。

## 常见失败

- 搜一次就写子报告。
- 把通用搜索当成纯兜底，而不是先做广度发现。
- 还没完成广度发现，就过早进入某一个专门入口。
- 明明已有专门搜索 skill，却只用单一通用搜索入口浅搜。
- 因为缺少专门搜索 skill，就直接放弃某类来源覆盖。
- 只用搜索结果摘要，不打开或核查原始来源。
- 把社区讨论当成主要证据，而不回到官方或原始来源。
- 只找支持某个方向的材料，忽略反例和冲突。
- 把缺口包装成结论。
- 写完整搜索流水，导致子报告臃肿。
- 写了子报告但没有更新并确认 `plan.json`。