| 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+ 个）
2. 关键论文（12 篇）
选择策略（按优先级）：
- 影响力优先：被引次数高、GitHub 实现多、社区讨论热
- 时效性次之：近两年的最新研究
- 来源权威：顶级会议 > arXiv 顶会投稿 > arXiv 预印本
- ...
推荐比例：
- 经典高影响力论文（奠基性工作）：约 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. 技术细节对比
| 维度 | 方案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 是最终的一站式完整文件。
质量标准
- 数据新鲜度：情报维度的所有数据必须标注来源和日期，优先使用近两年的信息
- 内容完整性：每份报告生成后需验证字符数 > 100，确认包含有效内容
- 格式规范性：所有报告使用 Markdown 格式，表格对齐、代码块标注语言
- 总字数：全部产出合计约 6000 字以上
- 可操作性：选型建议需包含具体场景和成本估算，而非笼统的"各有优缺点"
版本：4.0 | 类型：知识流程版
