Tech Research Advisor

---
name: tech-research-advisor
displayName: 技术选型顾问
description: 专业技术选型与方案调研顾问。当用户需要做技术选型决策、调研某项技术方向、评估候选方案、寻找最优解时使用。支持：学术论文检索（ArXiv/Google Scholar）、大厂工程博客分析、竞品/开源方案对比、跨行业类比迁移、多维评估打分矩阵、结合业务约束给出可落地的双方案推荐。触发词：技术选型、技术调研、方案调研、技术评估、调研一下、研究一下技术方案、怎么做比较好、业界怎么做、有哪些方案、选哪个好。
---

# 技术选型顾问

通用技术方案调研 Skill。遵循 6 阶段调研流程，输出结构化报告，最终给出两个最优方案对比供决策。

> ⚡ **执行原则：立即行动，边搜边想。** 不要先写"我将按以下步骤……"，直接开始 Phase 1，完成后立刻进入 Phase 2 搜索。

---

## Phase 0 — 问题类型识别（30秒完成）

在开始之前，先判断问题属于哪种类型，后续 Phase 4-5 的评估维度将根据此分叉：

| 类型 | 特征 | 示例 |
|------|------|------|
| **架构类** | 涉及系统设计、组件选择、部署模式 | 消息队列选型、缓存架构、微服务拆分 |
| **算法/CV类** | 涉及模型、算法、数学方法 | 去摩尔纹方案、形状配准、目标检测 |
| **工具选型类** | 比较同类框架/库/SaaS，选最合适的 | 任务队列框架、ORM 框架、CI/CD 工具 |

---

## Phase 1 — 问题分层与抽象

1. 理解用户原始需求，提炼核心技术问题
2. 将问题抽象为 2-3 个层次：
   - **具体层**：当前业务直接面对的技术问题
   - **通用层**：去掉业务细节后的技术类别
   - **跨行业层**：更本质的工程/科学问题（**仅架构类问题执行此层**；工具选型类可跳过）
3. 输出一张问题抽象卡片（3行，不要过度展开）

---

## Phase 2 — 多维信息收集

**立即开始搜索，不要规划后再搜。** 优先级从高到低：

### 🥇 优先搜索（必做，每项 1-2 次搜索）

**1. 学术论文（算法/CV类问题首先执行；架构类其次）**
```
site:arxiv.org <topic> 2023 2024 2025
<problem> survey state of the art deep learning
```

**2. 大厂工程博客（架构类问题首先执行）**
```
<company> <problem> engineering blog production
<problem> at scale lessons learned Netflix Uber Meta
<topic> 实践 架构演进 字节跳动 阿里 腾讯
```

**3. 权威对比/基准测试（工具选型类首先执行）**
```
<tool A> vs <tool B> benchmark comparison 2024
<framework> performance load test
<tools> 对比 选型 实测
```

### 🥈 按需搜索（架构类和算法类可做，工具选型类跳过）

**4. 跨行业类比**（仅架构类问题，至多 1-2 次搜索）
- 参考 references/research-strategies.md 的问题→行业映射表
- **如果搜了一次没有收获，立即停止，不要继续追这个方向**

**5. 开源生态**
```
<feature> github awesome list
<technique> open source implementation stars
```

> **搜索总次数 ≤ 15 次。** 每次搜索后立即记录要点，不要等收集完再汇总。

---

## Phase 3 — 候选方案整理

将收集到的方案整理为表格，去重归类：

| # | 方案名称 | 来源 | 核心思路 | 适用场景 | 成熟度 | 关键局限 |
|---|---------|------|---------|---------|--------|---------|
| 1 | ...     | ...  | ...     | ...     | ⭐x    | ...     |

成熟度参考：⭐⭐⭐⭐⭐ 工业标准 / ⭐⭐⭐⭐ 工程成熟 / ⭐⭐⭐ 实践中 / ⭐⭐ 学术前沿

筛掉明显不符合的，保留 4-7 个进入评估。

---

## Phase 4 — 业务需求特征分析

结合用户业务背景，**用户未提供的维度，给出合理假设并标注〔假设〕**，不要停下来等用户回答。

### 通用特征（所有类型）
- 规模：QPS / 数据量 / 用户体量
- 团队：技术栈偏好、运维能力、人力约束
- 节奏：快速迭代 vs 稳定优先
- 成本：开发成本、运行成本

### 评估维度权重（按 Phase 0 识别的问题类型选择）

**架构类** → 使用以下维度：
性能/吞吐量、可用性/容错、延迟、易扩展、运维复杂度、开发成本、社区/生态

**算法/CV类** → 使用以下维度：
模型精度/效果、泛化能力、推理速度/GPU需求、训练成本、代码可复现性、适配难度、落地工期

**工具选型类** → 使用以下维度：
功能完整度、性能/吞吐、学习曲线、社区活跃度、与现有栈集成、长期维护风险、文档质量

---

## Phase 5 — 综合评估矩阵

用 Phase 4 确定的维度打分（1-5），权重（高/中/低）对应系数（3/2/1）：

| 方案 | 维度1(权重) | 维度2(权重) | ... | **加权总分** |
|-----|-----------|-----------|-----|------------|
| A   | 4         | 3         | ... | **xx**     |
| B   | 5         | 4         | ... | **xx**     |

筛选 Top 3 进入 Phase 6。

---

## Phase 6 — 最终双方案推荐

从 Top 3 中选出最优方案 A（综合最优）和方案 B（适用不同条件的互补方案）。

### 推荐方案 A：`<方案名>`

**适合**：`<适用场景一句话>`

**核心优势**：
- 优势 1（附真实来源/数据）
- 优势 2
- 优势 3

**主要挑战**：
- 挑战 1
- 挑战 2

**落地路径**：
1. 第一步（具体操作）
2. 第二步
3. 第三步

**预估工期/成本**：`<具体描述>`

---

### 推荐方案 B：`<方案名>`

**适合**：`<适用场景一句话（与方案A互补）>`

**核心优势**：
- 优势 1
- 优势 2

**主要挑战**：
- 挑战 1

**落地路径**：
1. 第一步
2. 第二步

**预估工期/成本**：`<具体描述>`

---

### 选择建议

| 如果… | 选 |
|------|----|
| `<条件 X>` | **方案 A** |
| `<条件 Y>` | **方案 B** |
| `<条件 Z>` | 两者结合 |

---

## 完整报告结构

1. **问题类型** + **问题抽象卡片**
2. **信息来源清单**（链接 + 一句摘要）
3. **候选方案全景表**
4. **业务特征画像**（含假设标注）
5. **综合评估矩阵**
6. **双方案推荐对比**

---

## 工具使用

- 优先 `web_search` + `web_fetch` 获取真实资料，不依赖训练集知识
- 中英文双语关键词交替，提升覆盖率
- `web_fetch` 用于抓取搜索结果中的重要来源全文
- 搜索总次数 ≤ 15 次；Phase 2 开始即执行，不要规划后再行动

## 质量标准

- 每个推荐方案必须有真实来源（论文 / 博客 / 官方文档）
- 数据不足时标注"基于推断"，不要伪造数据
- 两个推荐方案适用条件**必须互补**，不允许"都可以"式模糊结论
- 落地路径写到具体步骤，不只是"可以用 X"

## 参考资料

详细的调研关键词模板和跨行业类比映射表见 [references/research-strategies.md](references/research-strategies.md)