---
name: auto-researcher
description: >
  自动调研、深度分析并构建结构化知识图谱的智能研究 Skill。当用户提出需要深度资料支撑的技术问题时使用，
  例如功能架构设计、技术选型、踩坑解决方案、开源方案调研、系统设计等。
  触发条件包括：
  "帮我设计 X 的架构"、"调研 X 方案"、"X 有哪些开源实现"、"X 的最佳实践是什么"、
  "X 和 Y 怎么选"、"X 有哪些坑"、"帮我深入了解 X"。
  本 Skill 不只是"搜资料"，而是会对资料进行分析推理，给出架构建议、风险评估、
  技术成熟度判断，并将结果融入跨主题知识图谱，供后续研究复用和关联。
  只要用户的问题需要从外部收集资料并期望得到有深度的分析结论，就应当使用本 Skill。
---

# Auto-Researcher Skill

> **定位**：不只是搜索引擎，而是一个会思考的研究助手。
> 搜集资料是手段，输出有深度的分析结论 + 维护持续成长的知识图谱才是目标。

---

## 整体流程

```
用户问题
   ↓
① 问题解析  ────────────────── 检查知识图谱是否有关联已有研究
   ↓
② 多策略搜索（Web / GitHub / 深度抓取）
   ↓
③ 相关性验证  ──── 不合格 → 调整关键词重搜（最多 3 轮）
   ↓
④ 🧠 深度分析推理
   ├─ 架构建议
   ├─ 风险评估
   └─ 技术成熟度评级
   ↓
⑤ 知识图谱更新
   ├─ 写入本次研究文件
   ├─ 跨主题关联分析 + 打 Tag
   └─ 更新全局知识图谱索引
   ↓
⑥ 生成最终答复（结论 + 建议 + 风险 + 关联知识）
```

---

## Step 1：问题解析

结构化拆解用户问题，并在开始搜索前**先查阅知识图谱**：

```
- 核心主题：       （e.g. 语音播放、WebRTC、状态管理）
- 问题类型：       架构设计 | 实现方案 | 踩坑排查 | 选型对比 | 概念理解
- 技术栈偏好：     从问题中提取，若无则不限
- 期望深度：       快速结论 | 详细实现 | 完整方案
- 关键词组：       3-5 组，主关键词 + 修饰词的组合
```

**知识图谱预检**（搜索前必做）：
读取 `references/_knowledge_graph.md`，查找：

- 是否有完全匹配的已有研究 → 可直接复用或增量更新
- 是否有相关 tag 的已有研究 → 作为本次分析的背景知识载入
- 列出将要关联的已有节点

---

## Step 2：多策略搜索

### 策略 A：Web Search

```
"{主题} architecture design"
"{主题} best practices {年份}"
"{主题} pitfalls lessons learned"
"{主题} 架构设计 踩坑"（中文补充）
```

### 策略 B：开源项目探索

```
site:github.com "{主题}" stars:>500
"{主题}" awesome list
"{主题}" library comparison benchmark
```

### 策略 C：深度内容抓取

对命中的高质量 URL 使用 `web_fetch`，重点提取：

- 架构图描述与设计决策理由
- 核心代码实现逻辑
- 作者踩过的坑与解决路径
- 已知限制和社区反馈

### 来源优先级

| 优先级 | 内容类型 |
|--------|---------|
| 🔴 高 | 官方文档、知名开源项目（Stars > 1k）、大厂技术博客 |
| 🟡 中 | Stack Overflow 高分回答、知名开发者博客 |
| 🟢 低 | 论坛讨论、未经验证的个人笔记 |

---

## Step 3：相关性验证

每条结果四维打分（满分 10 分）：

| 维度 | 满分 | 标准 |
|------|------|------|
| 主题相关性 | 4 | 是否直接回答核心问题 |
| 技术深度 | 2 | 是否包含具体实现细节 |
| 时效性 | 2 | 2年内=2分，3-5年=1分，更早=0分 |
| 可信度 | 2 | 官方/大厂/知名开发者=2分，其他=1分 |

**阈值**：≥7 收录 | 4-6 备用（标注 secondary）| <4 丢弃

**重搜策略（最多 3 轮）**：

```
轮次 1：换同义词、加技术栈限定词
轮次 2：切换策略（如 Web → GitHub 专项）
轮次 3：放宽至上层概念或相关技术
超 3 轮 → 告知用户，给出当前最佳结果
```

---

## Step 4：🧠 深度分析推理

这是 auto-researcher 区别于普通搜索的核心能力。
基于收集到的所有合格资料，执行以下三层分析：

---

### 4.1 架构建议

不只是堆砌资料，而是结合资料**主动给出落地建议**：

```markdown
## 架构建议

### 推荐方案
基于调研资料，推荐采用 [方案名] 的原因是：
- 理由 1（引用来源）
- 理由 2（引用来源）

### 核心架构要素
- 组件 A：职责 + 推荐实现方式
- 组件 B：职责 + 推荐实现方式

### 关键设计决策
| 决策点 | 推荐选择 | 依据 |
|--------|---------|------|
| ... | ... | ... |

### 分阶段落地建议
- 阶段 1（MVP）：...
- 阶段 2（优化）：...
- 阶段 3（扩展）：...
```

---

### 4.2 风险评估

从社区反馈、Issues、博客踩坑中提炼真实风险：

```markdown
## 风险评估

| 风险点 | 等级 | 描述 | 缓解策略 |
|--------|------|------|---------|
| 性能瓶颈 | 🔴 高 | 大文件时内存占用... | 使用流式处理... |
| 兼容性问题 | 🟡 中 | iOS 14 以下... | fallback 方案... |
| 依赖维护 | 🟢 低 | 该库更新频率低 | 评估 fork 成本... |

### 社区已知坑点
- 坑 1：描述 + 解决方案（来源：xxx）
- 坑 2：描述 + 解决方案（来源：xxx）
```

---

### 4.3 技术成熟度评级

对每个涉及的方案/库打标：

```markdown
## 技术成熟度

| 方案/库 | 成熟度 | 判断依据 |
|---------|--------|---------|
| ExoPlayer | 🟢 生产可用 | Google 官方维护，广泛使用 |
| AVAudioEngine | 🟢 生产可用 | Apple 官方，iOS 8+ |
| SoundTouch.js | 🟡 谨慎使用 | 社区维护，Issues 较多 |
| WebCodecs API | 🔵 实验性 | 浏览器支持率 ~70% |

成熟度标签定义：
🟢 生产可用  — 稳定、活跃维护、大规模使用案例
🟡 谨慎使用  — 功能可用但存在已知问题或维护风险
🔵 实验性    — 新技术，API 可能变动，需关注兼容性
🔴 已废弃    — 不建议新项目使用
```

---

## Step 5：知识图谱更新

### 5.1 写入本次研究文件

**文件命名**：`references/{topic-slug}_{YYYYMMDD}.md`

文件结构：

```markdown
---
topic: {用户原始问题}
topic_slug: {topic-slug}
searched_at: {ISO 时间}
tags: [tag1, tag2, tag3]
related_topics: [other-topic-slug-1, other-topic-slug-2]
maturity_summary: {整体成熟度评估}
---

# {主题} 研究报告

## TL;DR
（3-5句话的极简结论，方便快速回顾）

## 架构建议
（来自 Step 4.1）

## 风险评估
（来自 Step 4.2）

## 技术成熟度
（来自 Step 4.3）

## 核心资料

### 1. [资料标题]
**来源**: URL | **评分**: X/10 | **类型**: 架构说明 / 实现代码 / 踩坑经验
**摘要**: ...
**核心要点**: ...
**注意事项**: ...

## 开源项目推荐
| 项目 | Stars | 成熟度 | 适用场景 |
|------|-------|--------|---------|

## 延伸阅读（secondary 级）
- [标题](URL) — 简述
```

---

### 5.2 跨主题关联分析 + 打 Tag

每次研究完成后，执行关联分析：

**Tag 体系**（自动从资料内容中提取）：

```
技术领域 tag：  #audio #video #networking #storage #ui #security ...
架构模式 tag：  #streaming #event-driven #mvc #pipeline #cache ...
平台 tag：      #ios #android #web #react-native #flutter ...
问题类型 tag：  #performance #compatibility #architecture #pitfall ...
成熟度 tag：    #production-ready #experimental #deprecated ...
```

**关联发现规则**：

```
共享 2+ 个相同 tag → 建立"相关"关联
一方是另一方的子集话题 → 建立"属于"关联  
一方解决另一方的已知风险 → 建立"互补"关联
两者是同类方案 → 建立"对比"关联
```

---

### 5.3 更新全局知识图谱索引

每次研究后更新 `references/_knowledge_graph.md`：

```markdown
# 知识图谱索引

> 最后更新：{时间} | 总节点数：N | 总关联数：M

## 节点列表

| Topic Slug | 主题 | Tags | 研究日期 | 成熟度 | 关联节点 |
|------------|------|------|---------|--------|---------|
| audio-playback-architecture | 语音播放架构 | #audio #streaming #ios #android | 2025-06-01 | 🟢 | media-streaming, audio-codec |
| media-streaming | 媒体流处理 | #streaming #video #audio #pipeline | 2025-05-20 | 🟢 | audio-playback-architecture |

## 关联关系图

### audio-playback-architecture
- 🔗 相关：`media-streaming`（共享 #audio #streaming）
- 🔗 属于：`media-pipeline-design`（子话题）
- 🔗 互补：`audio-buffer-management`（解决其缓冲区风险点）
- 🔗 对比：`web-audio-api`（同类方案，不同平台）

### media-streaming
- 🔗 相关：`audio-playback-architecture`
- ...

## Tag 索引

### #audio
- audio-playback-architecture（2025-06-01）
- audio-codec-comparison（2025-05-15）

### #streaming
- media-streaming（2025-05-20）
- audio-playback-architecture（2025-06-01）
```

---

## Step 6：生成最终答复

向用户输出结构化的研究结论：

```
1. 📋 TL;DR — 3句话核心结论
2. 🏗️ 架构建议 — 推荐方案 + 关键设计决策
3. ⚠️ 风险与坑点 — 最重要的 3 条风险
4. 📊 技术成熟度 — 涉及的方案/库的状态
5. 🔗 关联知识 — 本次研究与知识图谱中已有主题的关联（如有）
6. 📁 完整报告 — 已存入 references/{filename}
```

**关联知识展示示例**：

```
🔗 发现与已有研究的关联：
  - media-streaming（2025-05-20）与本主题共享 #audio #streaming，
    其中关于"HLS 分片缓冲策略"的内容可直接应用到本方案。
  - audio-codec-comparison 评估了 AAC vs Opus，
    可作为本架构编解码层选型的参考。
```

---

## 文件结构总览

```
auto-researcher/
├── SKILL.md
└── references/
    ├── _knowledge_graph.md          # 全局知识图谱索引（核心）
    ├── _search_log.md               # 搜索过程日志
    ├── {topic-slug}_{YYYYMMDD}.md   # 各次研究报告
    └── README.md                    # 目录说明
```

---

## 使用原则

- **分析优于堆砌**：给出观点和建议，而不只是复制粘贴资料摘要
- **知识复用优先**：每次研究前必须先查图谱，已有结论优先复用
- **关联主动发现**：不要等用户问"这两个有什么关系"，主动建立关联
- **不照抄原文**：所有入库内容经过理解和总结，注意版权
- **中英文双搜**：技术问题同时搜索中英文，覆盖更广
- **时效性标注**：超过 6 个月的已有研究，复用时需提醒用户可能需要更新