architect-tech-research

name	architect/tech-research
description	技术调研方法论，通过系统性调研和对比分析，为技术选型提供数据支持
version	1.0.0
agent	architect
type	methodology
user-invocable	false
agent-invocable	true
dependencies	["shared/tech-stack-detection"]
triggers	["开始架构设计前","需要技术选型时","评估新技术方案时"]

技术调研方法论

适用场景

在进行架构设计和技术选型前，必须先进行系统性的技术调研，了解：

• 业界成熟的技术方案
• 各方案的优缺点和适用场景
• 开源项目的可复用性
• 潜在的技术风险

调研流程

1. 明确调研目标

基于PRD的技术需求，明确需要调研的技术领域：

调研背景模板：

### 1.1 调研背景

**需求概述**：[基于 PRD 的技术需求总结]

**关键技术挑战**：
- [挑战 1]：[具体描述]
- [挑战 2]：[具体描述]
- [挑战 3]：[具体描述]

**调研目标**：
- [ ] 前端框架选型
- [ ] 后端框架选型
- [ ] 数据库选型
- [ ] 缓存方案选型
- [ ] 部署方案选型

2. 使用WebSearch进行调研

搜索策略

通用搜索模式：

"{技术领域} + best practices + 2026"
"{框架名} vs {框架名} comparison 2026"
"{技术领域} + benchmark + 2026"
"best {技术领域} tools 2026"

具体示例：

前端框架调研：

"React vs Vue vs Angular comparison 2026"
"Next.js vs Remix vs Astro 2026"
"best React UI libraries 2026"

后端框架调研：

"Node.js frameworks comparison 2026"
"Express vs Fastify vs Hono benchmark"
"Python web frameworks 2026"

数据库调研：

"PostgreSQL vs MySQL vs MongoDB 2026"
"database for {use case} 2026"
"SQL vs NoSQL when to use"

ORM调研：

"Prisma vs TypeORM vs Drizzle comparison"
"best ORM for {language} 2026"

搜索技巧

1. 包含年份：确保获取最新信息
2. 对比搜索：使用 "vs" 或 "comparison" 获取对比分析
3. 性能搜索：使用 "benchmark" 或 "performance" 获取性能数据
4. 实践搜索：使用 "best practices" 获取最佳实践
5. 问题搜索：使用 "pros and cons" 或 "disadvantages" 了解缺点

3. 使用WebFetch深入分析

对于重要的技术方案，使用 WebFetch 深入分析官方文档和技术文章：

官方文档：

WebFetch("https://nextjs.org/docs", "总结 Next.js 的核心特性、适用场景和最新版本的主要变化")
WebFetch("https://www.prisma.io/docs", "提取 Prisma 的核心功能、支持的数据库和性能特点")

技术对比文章：

WebFetch("[对比文章URL]", "提取各方案的优缺点对比、性能数据和推荐场景")

GitHub仓库：

WebFetch("https://github.com/{org}/{repo}", "提取 Star 数、最近更新时间、维护状态和主要贡献者")

4. 技术方案对比

对比维度

对每个技术方案，从以下维度进行评估：

维度	评估内容
功能完整性	是否满足项目需求
性能	响应时间、吞吐量、资源消耗
生态系统	社区活跃度、插件丰富度、文档质量
学习曲线	团队学习成本、上手难度
成熟度	版本稳定性、生产案例、维护状态
扩展性	是否易于扩展和定制
兼容性	与其他技术的集成难度
成本	开发成本、运维成本、授权成本

对比表格模板

前端框架对比：

方案	优点	缺点	适用场景	推荐度
Next.js	SSR/SSG、SEO友好、全栈能力	学习曲线陡、打包体积大	内容型网站、SEO要求高	⭐⭐⭐⭐⭐
Vite + React	开发体验好、构建快	需要自己配置路由等	SPA、快速原型	⭐⭐⭐⭐
Remix	数据加载优雅、Web标准	生态较新、案例较少	数据密集型应用	⭐⭐⭐

后端框架对比：

方案	优点	缺点	适用场景	推荐度
Express	成熟、生态丰富、灵活	性能一般、缺少约定	通用后端、快速开发	⭐⭐⭐⭐
Fastify	性能高、插件系统好	生态较Express小	性能要求高的API	⭐⭐⭐⭐
Hono	极致性能、边缘计算	生态较新	Serverless、边缘函数	⭐⭐⭐

数据库对比：

方案	类型	优点	缺点	适用场景
PostgreSQL	关系型	功能强大、扩展性好、JSON支持	运维复杂度高	复杂查询、事务、JSONB
MySQL	关系型	简单、普及、性能好	功能较PostgreSQL少	通用场景、读多写少
MongoDB	文档型	灵活、易扩展、开发快	事务支持弱、数据一致性	非结构化数据、快速迭代
SQLite	嵌入式	零配置、单文件、轻量	并发限制、功能有限	小型应用、原型、嵌入式

5. 开源方案评估

对于可能复用的开源项目，进行系统性评估：

开源项目	功能	Star 数	最近更新	维护状态	是否采用	理由
[项目名]	[功能描述]	[数量]	[日期]	活跃/停滞	是/否	[理由]

评估标准：

• Star 数 > 1000：说明有一定用户基础
• 最近更新 < 6个月：说明项目活跃
• Issue响应及时：说明维护良好
• 文档完善：说明易于使用
• License友好：MIT/Apache 2.0 等宽松协议

6. 调研结论

基于调研结果，给出明确的技术选型建议：

层级	推荐方案	选择理由	备选方案
前端	[方案]	[理由]	[备选]
后端	[方案]	[理由]	[备选]
数据库	[方案]	[理由]	[备选]
缓存	[方案]	[理由]	[备选]
部署	[方案]	[理由]	[备选]

选择理由应包含：

• 为什么选择这个方案（优势）
• 为什么不选其他方案（劣势）
• 与项目需求的匹配度
• 团队能力的匹配度

输出要求

完成技术调研后，应输出以下内容（通常作为架构文档的第1章）：

## 1. 技术调研

### 1.1 调研背景

**需求概述**：[基于 PRD 的技术需求总结]

**关键技术挑战**：
- [挑战 1]
- [挑战 2]
- [挑战 3]

### 1.2 技术方案调研

#### 前端框架对比

| 方案 | 优点 | 缺点 | 适用场景 | 推荐度 |
|------|------|------|----------|--------|
| [方案1] | ... | ... | ... | ... |
| [方案2] | ... | ... | ... | ... |

#### 后端框架对比

[同上]

#### 数据库对比

[同上]

### 1.3 开源方案评估

| 开源项目 | 功能 | Star 数 | 维护状态 | 是否采用 |
|----------|------|---------|----------|----------|
| [项目1] | ... | ... | ... | ... |

### 1.4 调研结论

| 层级 | 推荐方案 | 选择理由 | 备选方案 |
|------|----------|----------|----------|
| 前端 | [方案] | [理由] | [备选] |
| 后端 | [方案] | [理由] | [备选] |
| 数据库 | [方案] | [理由] | [备选] |

关键原则

1. 真实调研：必须真实使用 WebSearch 和 WebFetch，不能凭空编造
2. 数据支撑：结论必须基于调研数据，不能主观臆断
3. 对比分析：至少对比3个方案，说明为什么选择A而不是B
4. 考虑现状：如果项目已有技术栈（通过 shared/tech-stack-detection 检测），优先考虑兼容性
5. 团队能力：考虑团队的技术背景和学习成本

常见误区

❌ 不调研就选型：直接给出技术方案，没有调研过程 ❌ 只看优点：只列优点不列缺点，缺乏客观性 ❌ 追新求异：盲目选择最新技术，忽略成熟度和风险 ❌ 忽略现状：不检测项目现有技术栈，推荐不兼容的方案 ❌ 缺少备选：只给一个方案，没有Plan B

调研时间建议

• 简单项目：30分钟 - 1小时
• 中型项目：1-2小时
• 复杂项目：2-4小时

不要过度调研，调研的目的是支持决策，不是写论文。