technical-research

name	technical-research
description	技术领域深度调研。对任意技术领域进行系统化调研，产出包含概念剖析、行业情报、方案对比、精华整合四个维度的完整报告，并最终整合为一份完整 md 文件。GitHub 数据通过 WebSearch/WebFetch 实时获取。适用于技术选型、领域入门、竞品分析等场景。当用户提到"调研"、"研究"、"了解"某技术领域，或需要对某技术进行全面分析时，使用此 Skill。

技术领域深度调研

对任意技术领域进行结构化、可复现的深度调研，产出四个维度的专业报告和一份精华总结。

适用场景

• 技术选型前的全面调研
• 新领域快速入门
• 竞品/方案横向对比
• 团队内部技术分享素材准备

用法

调研 {技术领域}

示例：调研 Agent Memory 机制、调研 RAG 技术、调研 向量数据库

---

调研框架

一次完整调研包含四个维度 + 最终整合，按依赖关系分为两个层级：

第一层（独立维度，可同时开展）:
  ├── 概念剖析  —— 技术原理和架构的深度理解
  ├── 行业情报  —— 最新开源项目、论文、博客的信息收集
  └── 方案对比  —— 多种实现方案的横向评估

第二层（依赖第一层的结果）:
  ├── 精华整合  —— 将三份报告浓缩为可传播的总结
  └── 最终整合  —— 将所有内容（三个维度 + 精华整合）合并为一份完整 md 文件

以下逐一定义每个维度的目标、方法和输出规范。

---

维度一：概念剖析

目标

建立对目标技术的深层理解——不仅知道"是什么"，还要理解"为什么这样设计"和"如何实现"。

输出规范

1. 定义澄清（约 200 字）

• 通行定义：该领域最被广泛接受的定义
• 常见误解：至少列出 3 个容易混淆的认知偏差
• 边界辨析：与相邻概念（易混淆技术）的核心区别

2. 核心架构

使用 ASCII 图呈现系统架构，标注各组件的职责和数据流向：

┌──────────────────────────────────────┐
│         {领域} 系统架构               │
├──────────────────────────────────────┤
│  输入 → [处理层] → [存储层] → [输出层] │
│           ↓          ↓                │
│        [辅助组件]  [监控组件]          │
└──────────────────────────────────────┘

每个组件附带一句话说明其功能。

3. 数学形式化（3-5 个公式）

用 LaTeX 公式描述核心机制，覆盖以下方面：

• 核心算法的数学定义
• 关键性能指标的计算方式
• 效率/成本的量化模型

公式应当反映技术本质，而非堆砌符号。每个公式附带一行自然语言解释。

4. 实现逻辑（Python 伪代码）

class CoreSystem:
    """核心类，体现该领域的关键抽象"""
    def __init__(self, config):
        self.component_a = ...  # 说明职责
        self.component_b = ...  # 说明职责

    def core_operation(self, input):
        """核心操作，体现关键算法逻辑"""
        intermediate = self.component_a.process(input)
        result = self.component_b.transform(intermediate)
        return result

伪代码应当体现架构思想，而非纠缠于实现细节。

5. 性能指标

指标	典型目标值	测量方式	说明
延迟	< X ms	端到端基准测试	...
吞吐	> Y req/s	负载测试	...
准确率	> Z%	标准评测集	...
...	...	...	...

6. 扩展性与安全性

• 水平扩展：如何通过增加节点提升容量
• 垂直扩展：单节点的优化上限
• 安全考量：该领域特有的安全风险和防护要点
• ...

---

维度二：行业情报

目标

收集该领域最新的开源项目、学术论文和技术博客，建立对当前生态的全景认知。

数据新鲜度要求

所有情报数据必须标注来源和日期。使用以下脚本模板进行实时信息采集：

GitHub 项目采集

必须使用 WebSearch/WebFetch 工具获取最新 GitHub 数据，不能依赖训练数据中的过时信息。

搜索策略（使用 WebSearch 执行以下查询）：

"{topic} github stars 2025 2026"
"best {topic} open source libraries github"
"awesome {topic} github"
"site:github.com {topic} stars"

对搜索结果中发现的重要项目，使用 WebFetch 访问其 GitHub 页面，获取以下实时数据：

• 当前 Stars 数量
• 最近提交日期
• 项目描述和核心功能
• 技术栈信息

筛选标准：

• 最近 6 个月有活跃提交
• Stars > 1000（优先）或 > 500（补充）
• 官方维护或知名团队维护

学术论文采集

必须使用 WebSearch/WebFetch 工具获取最新数据 搜索查询模板：

"site:arxiv.org {topic} {current_year-5} {current_year}"
"{topic} NeurIPS OR ICML OR ACL OR AAAI {current_year-5}"

技术博客采集

必须使用 WebSearch/WebFetch 工具获取最新数据 搜索查询模板：

"{topic} tutorial best practices {current_year}"
"{topic} medium.com OR dev.to {current_year-5} {current_year}"

输出规范

1. GitHub 热门项目（15+ 个）

项目	Stars	核心功能	技术栈	最后更新	链接

2. 关键论文（12 篇）

选择策略（按优先级）：

1. 影响力优先：被引次数高、GitHub 实现多、社区讨论热
2. 时效性次之：近两年的最新研究
3. 来源权威：顶级会议 > arXiv 顶会投稿 > arXiv 预印本
4. ...

推荐比例：

• 经典高影响力论文（奠基性工作）：约 40%
• 最新 SOTA 论文（前沿进展）：约 60%

论文	作者/机构	年份	会议/期刊	核心贡献	影响力指标	链接

3. 系统化技术博客（10 篇）

选择标准：

• 内容深度：系列文章、深度教程、架构解析（排除碎片化新闻）
• 作者权威：官方团队博客、知名专家、一线工程师实践
• 语言平衡：英文约 70%，中文约 30%

英文推荐来源：OpenAI Blog、Google AI Blog、Anthropic Blog、LangChain Blog、个人专家（Eugene Yan、Chip Huyen、Sebastian Raschka 等）

中文推荐来源：大厂技术博客（美团、阿里、字节等）、知乎专栏、机器之心、PaperWeekly ...

博客标题	作者/来源	语言	类型	核心内容	日期	链接

4. 技术演进时间线

按时间顺序列出该领域的关键里程碑事件，标注事件、发起方和影响。

---

维度三：方案对比

目标

对该领域的主流实现方案进行系统化横向对比，给出可操作的选型建议。

输出规范

1. 历史发展时间线

{年份} ─┬─ {技术/事件} → {对行业的影响}
{年份} ─┼─ {技术/事件} → {对行业的影响}
{年份} ─┼─ {技术/事件} → {对行业的影响}
{年份} ─┴─ 当前状态：{一句话总结}

2. N 种方案横向对比（5-7 种）

方案	原理	优点（3+）	缺点（3+）	适用场景	成本量级

每个方案的优缺点至少各列 3 条，避免泛泛而谈。

3. 技术细节对比

维度	方案A	方案B	方案C	方案D	方案E
性能
易用性
生态成熟度
社区活跃度
学习曲线

4. 选型建议

场景	推荐方案	核心理由	预估月成本
小型项目/原型验证
中型生产环境
大型分布式系统

选型建议应当基于当年最新的技术趋势和生态状况。

---

精华整合

目标

将三份维度报告浓缩为可快速传播的精华内容。精华整合依赖前三个维度的输出。

输出规范

1. The One 公式

用一个"悖论式等式"概括该领域的核心本质：

$$ \text{领域} = \underbrace{\text{核心组件1}}{\text{功能}} + \underbrace{\text{核心组件2}}{\text{功能}} - \underbrace{\text{核心损耗}}_{\text{说明}} $$

这个公式的目的是帮助读者用一个心智模型记住整个领域。

2. 一句话解释

用费曼技巧写一句话，让非技术背景的人也能理解该领域是做什么的。

3. 核心架构图

输入 → [层1] → [层2] → [层3] → 输出
        ↓       ↓       ↓
      指标1   指标2   指标3

4. STAR 总结

部分	内容要求	字数
Situation（背景+痛点）	行业现状和核心挑战	100-150 字
Task（核心问题）	技术要解决的关键问题和约束	80-120 字
Action（主流方案）	技术演进的关键阶段和核心突破	120-180 字
Result（效果+建议）	当前成果、现存局限、实操建议	80-120 字

5. 理解确认问题

提出 1 个能检验是否真正理解该领域的问题，并给出参考答案。

---

最终整合

目标

将所有内容（三个维度报告 + 精华整合）合并为一份完整的 Markdown 文件: ${topic}-research.md。不裁剪内容，完整保留所有部分。

整合规范

最终输出文件按以下结构组织：

# {topic} 深度调研报告

> 调研日期：{date}
> 调研主题：{topic}

---

## 第一部分：概念剖析

{完整的概念剖析报告内容，原样保留}

---

## 第二部分：行业情报

{完整的行业情报报告内容，原样保留}

---

## 第三部分：方案对比

{完整的方案对比报告内容，原样保留}

---

## 第四部分：精华整合

{完整的精华整合内容，包括 The One 公式、一句话解释、核心架构图、STAR 总结、理解确认问题}

注意事项：

• 不裁剪内容：四个部分的内容完整合并，不删减任何部分
• 各部分之间使用 --- 分隔线隔开
• 保持原始报告中的所有表格、代码块、图表

---

输出文件结构

research/{topic}/
├── 00-索引.md              # 文件导航和执行统计
├── 01-完整调研报告.md       # 全部维度报告合集
├── 02-The-All-in-One.md     # 精华整合
├── 03-STAR-总结.md          # STAR 方法论总结
├── {topic}-concept.md       # 概念剖析报告
├── {topic}-intel.md         # 行业情报报告
├── {topic}-analysis.md      # 方案对比报告
└── {topic}-research.md      # 【最终整合】包含全部四个部分的完整单文件

对每个文件检验是否存在是否符合整合规范，确保所有内容完整保留，如果内容缺失，需要及时提醒用户并要求重新生成。 research/{topic} 目录存放面向读者的最终产出 + 各维度的原始报告，便于后续引用和增量更新。{topic}-research.md 是最终的一站式完整文件。

---

质量标准

1. 数据新鲜度：情报维度的所有数据必须标注来源和日期，优先使用近两年的信息
2. 内容完整性：每份报告生成后需验证字符数 > 100，确认包含有效内容
3. 格式规范性：所有报告使用 Markdown 格式，表格对齐、代码块标注语言
4. 总字数：全部产出合计约 6000 字以上
5. 可操作性：选型建议需包含具体场景和成本估算，而非笼统的"各有优缺点"

---

版本：4.0 | 类型：知识流程版