- name
- technical-research
- description
- |
技术领域深度调研
对任意技术领域进行结构化、可复现的深度调研，产出四个维度的专业报告和一份精华总结。
适用场景
- 技术选型前的全面调研
- 新领域快速入门
- 竞品/方案横向对比
- 团队内部技术分享素材准备
用法
调研 {技术领域}示例：调研 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 篇）
选择策略（按优先级）：
- 影响力优先：被引次数高、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+） | 适用场景 | 成本量级 |
|---|
每个方案的优缺点至少各列 3 条，避免泛泛而谈。
3. 技术细节对比
| 维度 | 方案A | 方案B | 方案C | 方案D | 方案E |
|---|---|---|---|---|---|
| 性能 | |||||
| 易用性 | |||||
| 生态成熟度 | |||||
| 社区活跃度 | |||||
| 学习曲线 |
4. 选型建议
| 场景 | 推荐方案 | 核心理由 | 预估月成本 |
|---|---|---|---|
| 小型项目/原型验证 | |||
| 中型生产环境 | |||
| 大型分布式系统 |
选型建议应当基于当年最新的技术趋势和生态状况。
精华整合
目标
将三份维度报告浓缩为可快速传播的精华内容。精华整合依赖前三个维度的输出。
输出规范
1. The One 公式
用一个"悖论式等式"概括该领域的核心本质：
$$ \ ext{领域} = \underbrace{\ ext{核心组件1}}_{\ ext{功能}} + \underbrace{\ ext{核心组件2}}_{\ ext{功能}} - \underbrace{\ ext{核心损耗}}_{\ ext{说明}} $$
这个公式的目的是帮助读者用一个心智模型记住整个领域。
2. 一句话解释
用费曼技巧写一句话，让非技术背景的人也能理解该领域是做什么的。
3. 核心架构图
输入 → [层1] → [层2] → [层3] → 输出
↓ ↓ ↓
指标1 指标2 指标34. 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 | 类型：知识流程版*