architect-tech-research

# 技术调研方法论 ## 适用场景 在进行架构设计和技术选型前，必须先进行系统性的技术调研，了解： - 业界成熟的技术方案 - 各方案的优缺点和适用场景 - 开源项目的可复用性 - 潜在的技术风险 ## 调研流程 ### 1. 明确调研目标 基于PRD的技术需求，明确需要调研的技术领域： **调研背景模板**： ```markdown ### 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章）： ```markdown ## 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小时 不要过度调研，调研的目的是支持决策，不是写论文。