Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →技术调研方法论，通过系统性调研和对比分析，为技术选型提供数据支持
.claude/skills/echovic-architect-tech-research/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-06 | ✗→✓ | ▲ Improved | 103% | 0% |
| case-01 | ✗→✓ | ▲ Improved | 13% | 0% |
| case-02 | ✗→✓ | ▲ Improved | -1% | 0% |
| case-03 | ✗→✓ | ▲ Improved | 0% | 0% |
| case-04 | ✗→✓ | ▲ Improved | 104% | 0% |
在进行架构设计和技术选型前，必须先进行系统性的技术调研，了解：
基于PRD的技术需求，明确需要调研的技术领域：
调研背景模板：
markdown### 1.1 调研背景 **需求概述**：[基于 PRD 的技术需求总结] **关键技术挑战**： - [挑战 1]：[具体描述] - [挑战 2]：[具体描述] - [挑战 3]：[具体描述] **调研目标**： - [ ] 前端框架选型 - [ ] 后端框架选型 - [ ] 数据库选型 - [ ] 缓存方案选型 - [ ] 部署方案选型
通用搜索模式：
"{技术领域} + 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"对于重要的技术方案，使用 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 数、最近更新时间、维护状态和主要贡献者")对每个技术方案，从以下维度进行评估：
| 维度 | 评估内容 | |------|----------| | 功能完整性 | 是否满足项目需求 | | 性能 | 响应时间、吞吐量、资源消耗 | | 生态系统 | 社区活跃度、插件丰富度、文档质量 | | 学习曲线 | 团队学习成本、上手难度 | | 成熟度 | 版本稳定性、生产案例、维护状态 | | 扩展性 | 是否易于扩展和定制 | | 兼容性 | 与其他技术的集成难度 | | 成本 | 开发成本、运维成本、授权成本 |
前端框架对比：
| 方案 | 优点 | 缺点 | 适用场景 | 推荐度 | |------|------|------|----------|--------| | Next.js | SSR/SSG、SEO友好、全栈能力 | 学习曲线陡、打包体积大 | 内容型网站、SEO要求高 | ⭐⭐⭐⭐⭐ | | Vite + React | 开发体验好、构建快 | 需要自己配置路由等 | SPA、快速原型 | ⭐⭐⭐⭐ | | Remix | 数据加载优雅、Web标准 | 生态较新、案例较少 | 数据密集型应用 | ⭐⭐⭐ |
后端框架对比：
| 方案 | 优点 | 缺点 | 适用场景 | 推荐度 | |------|------|------|----------|--------| | Express | 成熟、生态丰富、灵活 | 性能一般、缺少约定 | 通用后端、快速开发 | ⭐⭐⭐⭐ | | Fastify | 性能高、插件系统好 | 生态较Express小 | 性能要求高的API | ⭐⭐⭐⭐ | | Hono | 极致性能、边缘计算 | 生态较新 | Serverless、边缘函数 | ⭐⭐⭐ |
数据库对比：
| 方案 | 类型 | 优点 | 缺点 | 适用场景 | |------|------|------|------|----------| | PostgreSQL | 关系型 | 功能强大、扩展性好、JSON支持 | 运维复杂度高 | 复杂查询、事务、JSONB | | MySQL | 关系型 | 简单、普及、性能好 | 功能较PostgreSQL少 | 通用场景、读多写少 | | MongoDB | 文档型 | 灵活、易扩展、开发快 | 事务支持弱、数据一致性 | 非结构化数据、快速迭代 | | SQLite | 嵌入式 | 零配置、单文件、轻量 | 并发限制、功能有限 | 小型应用、原型、嵌入式 |
对于可能复用的开源项目，进行系统性评估：
| 开源项目 | 功能 | Star 数 | 最近更新 | 维护状态 | 是否采用 | 理由 | |----------|------|---------|----------|----------|----------|------| | 项目名] | 功能描述] | 数量] | 日期] | 活跃/停滞 | 是/否 | 理由] |
评估标准：
基于调研结果，给出明确的技术选型建议：
| 层级 | 推荐方案 | 选择理由 | 备选方案 | |------|----------|----------|----------| | 前端 | 方案] | 理由] | 备选] | | 后端 | 方案] | 理由] | 备选] | | 数据库 | 方案] | 理由] | 备选] | | 缓存 | 方案] | 理由] | 备选] | | 部署 | 方案] | 理由] | 备选] |
选择理由应包含：
完成技术调研后，应输出以下内容（通常作为架构文档的第1章）：
markdown## 1. 技术调研 ### 1.1 调研背景 **需求概述**：[基于 PRD 的技术需求总结] **关键技术挑战**： - [挑战 1] - [挑战 2] - [挑战 3] ### 1.2 技术方案调研 #### 前端框架对比 | 方案 | 优点 | 缺点 | 适用场景 | 推荐度 | |------|------|------|----------|--------| | [方案1] | ... | ... | ... | ... | | [方案2] | ... | ... | ... | ... | #### 后端框架对比 [同上] #### 数据库对比 [同上] ### 1.3 开源方案评估 | 开源项目 | 功能 | Star 数 | 维护状态 | 是否采用 | |----------|------|---------|----------|----------| | [项目1] | ... | ... | ... | ... | ### 1.4 调研结论 | 层级 | 推荐方案 | 选择理由 | 备选方案 | |------|----------|----------|----------| | 前端 | [方案] | [理由] | [备选] | | 后端 | [方案] | [理由] | [备选] | | 数据库 | [方案] | [理由] | [备选] |
❌ 不调研就选型：直接给出技术方案，没有调研过程 ❌ 只看优点：只列优点不列缺点，缺乏客观性 ❌ 追新求异：盲目选择最新技术，忽略成熟度和风险 ❌ 忽略现状：不检测项目现有技术栈，推荐不兼容的方案 ❌ 缺少备选：只给一个方案，没有Plan B
不要过度调研，调研的目的是支持决策，不是写论文。
Other measured skills in the registry, with their headline benchmark lift.