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 架构建议

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

## 架构建议

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

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

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

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

---

4.2 风险评估

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

## 风险评估

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

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

---

4.3 技术成熟度评级

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

## 技术成熟度

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

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

---

Step 5：知识图谱更新

5.1 写入本次研究文件

文件命名：

references/{topic-slug}_{YYYYMMDD}.md

文件结构：

---
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

：

# 知识图谱索引

> 最后更新：{时间} | 总节点数：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 个月的已有研究，复用时需提醒用户可能需要更新