tech-research

Name: tech-research
Author: echoVic

554stars48forks

How to install tech-research?

echovic/boss-skill/tech-research

$npx -y skills add echoVic/boss-skill --skill tech-research

Installs into the current project.

Summary

技术调研方法论，通过系统性调研和对比分析，为技术选型提供数据支持

Files · 1

View on GitHub

SKILL.md

1	# 技术调研方法论
2
3	## 适用场景
4
5	在进行架构设计和技术选型前，必须先进行系统性的技术调研，了解：
6	- 业界成熟的技术方案
7	- 各方案的优缺点和适用场景
8	- 开源项目的可复用性
9	- 潜在的技术风险
10
11	## 调研流程
12
13	### 1. 明确调研目标
14
15	基于PRD的技术需求，明确需要调研的技术领域：
16
17	调研背景模板：
18
19	```markdown
20	### 1.1 调研背景
21
22	需求概述：[基于 PRD 的技术需求总结]
23
24	关键技术挑战：
25	- [挑战 1]：[具体描述]
26	- [挑战 2]：[具体描述]
27	- [挑战 3]：[具体描述]
28
29	调研目标：
30	- [ ] 前端框架选型
31	- [ ] 后端框架选型
32	- [ ] 数据库选型
33	- [ ] 缓存方案选型
34	- [ ] 部署方案选型
35	```
36
37	### 2. 使用WebSearch进行调研
38
39	#### 搜索策略
40
41	通用搜索模式：
42	```
43	"{技术领域} + best practices + 2026"
44	"{框架名} vs {框架名} comparison 2026"
45	"{技术领域} + benchmark + 2026"
46	"best {技术领域} tools 2026"
47	```
48
49	具体示例：
50
51	前端框架调研：
52	```
53	"React vs Vue vs Angular comparison 2026"
54	"Next.js vs Remix vs Astro 2026"
55	"best React UI libraries 2026"
56	```
57
58	后端框架调研：
59	```
60	"Node.js frameworks comparison 2026"
61	"Express vs Fastify vs Hono benchmark"
62	"Python web frameworks 2026"
63	```
64
65	数据库调研：
66	```
67	"PostgreSQL vs MySQL vs MongoDB 2026"
68	"database for {use case} 2026"
69	"SQL vs NoSQL when to use"
70	```
71
72	ORM调研：
73	```
74	"Prisma vs TypeORM vs Drizzle comparison"
75	"best ORM for {language} 2026"
76	```
77
78	#### 搜索技巧
79
80	1. 包含年份：确保获取最新信息
81	2. 对比搜索：使用 "vs" 或 "comparison" 获取对比分析
82	3. 性能搜索：使用 "benchmark" 或 "performance" 获取性能数据
83	4. 实践搜索：使用 "best practices" 获取最佳实践
84	5. 问题搜索：使用 "pros and cons" 或 "disadvantages" 了解缺点
85
86	### 3. 使用WebFetch深入分析
87
88	对于重要的技术方案，使用 `WebFetch` 深入分析官方文档和技术文章：
89
90	官方文档：
91	```
92	WebFetch("https://nextjs.org/docs", "总结 Next.js 的核心特性、适用场景和最新版本的主要变化")
93	WebFetch("https://www.prisma.io/docs", "提取 Prisma 的核心功能、支持的数据库和性能特点")
94	```
95
96	技术对比文章：
97	```
98	WebFetch("[对比文章URL]", "提取各方案的优缺点对比、性能数据和推荐场景")
99	```
100
101	GitHub仓库：
102	```
103	WebFetch("https://github.com/{org}/{repo}", "提取 Star 数、最近更新时间、维护状态和主要贡献者")
104	```
105
106	### 4. 技术方案对比
107
108	#### 对比维度
109
110	对每个技术方案，从以下维度进行评估：
111
112	\| 维度 \| 评估内容 \|
113	\|------\|----------\|
114	\| 功能完整性 \| 是否满足项目需求 \|
115	\| 性能 \| 响应时间、吞吐量、资源消耗 \|
116	\| 生态系统 \| 社区活跃度、插件丰富度、文档质量 \|
117	\| 学习曲线 \| 团队学习成本、上手难度 \|
118	\| 成熟度 \| 版本稳定性、生产案例、维护状态 \|
119	\| 扩展性 \| 是否易于扩展和定制 \|
120	\| 兼容性 \| 与其他技术的集成难度 \|
121	\| 成本 \| 开发成本、运维成本、授权成本 \|
122
123	#### 对比表格模板
124
125	前端框架对比：
126
127	\| 方案 \| 优点 \| 缺点 \| 适用场景 \| 推荐度 \|
128	\|------\|------\|------\|----------\|--------\|
129	\| Next.js \| SSR/SSG、SEO友好、全栈能力 \| 学习曲线陡、打包体积大 \| 内容型网站、SEO要求高 \| ⭐⭐⭐⭐⭐ \|
130	\| Vite + React \| 开发体验好、构建快 \| 需要自己配置路由等 \| SPA、快速原型 \| ⭐⭐⭐⭐ \|
131	\| Remix \| 数据加载优雅、Web标准 \| 生态较新、案例较少 \| 数据密集型应用 \| ⭐⭐⭐ \|
132
133	后端框架对比：
134
135	\| 方案 \| 优点 \| 缺点 \| 适用场景 \| 推荐度 \|
136	\|------\|------\|------\|----------\|--------\|
137	\| Express \| 成熟、生态丰富、灵活 \| 性能一般、缺少约定 \| 通用后端、快速开发 \| ⭐⭐⭐⭐ \|
138	\| Fastify \| 性能高、插件系统好 \| 生态较Express小 \| 性能要求高的API \| ⭐⭐⭐⭐ \|
139	\| Hono \| 极致性能、边缘计算 \| 生态较新 \| Serverless、边缘函数 \| ⭐⭐⭐ \|
140
141	数据库对比：
142
143	\| 方案 \| 类型 \| 优点 \| 缺点 \| 适用场景 \|
144	\|------\|------\|------\|------\|----------\|
145	\| PostgreSQL \| 关系型 \| 功能强大、扩展性好、JSON支持 \| 运维复杂度高 \| 复杂查询、事务、JSONB \|
146	\| MySQL \| 关系型 \| 简单、普及、性能好 \| 功能较PostgreSQL少 \| 通用场景、读多写少 \|
147	\| MongoDB \| 文档型 \| 灵活、易扩展、开发快 \| 事务支持弱、数据一致性 \| 非结构化数据、快速迭代 \|
148	\| SQLite \| 嵌入式 \| 零配置、单文件、轻量 \| 并发限制、功能有限 \| 小型应用、原型、嵌入式 \|
149
150	### 5. 开源方案评估
151
152	对于可能复用的开源项目，进行系统性评估：
153
154	\| 开源项目 \| 功能 \| Star 数 \| 最近更新 \| 维护状态 \| 是否采用 \| 理由 \|
155	\|----------\|------\|---------\|----------\|----------\|----------\|------\|
156	\| [项目名] \| [功能描述] \| [数量] \| [日期] \| 活跃/停滞 \| 是/否 \| [理由] \|
157
158	评估标准：
159	- Star 数 > 1000：说明有一定用户基础
160	- 最近更新 < 6个月：说明项目活跃
161	- Issue响应及时：说明维护良好
162	- 文档完善：说明易于使用
163	- License友好：MIT/Apache 2.0 等宽松协议
164
165	### 6. 调研结论
166
167	基于调研结果，给出明确的技术选型建议：
168
169	\| 层级 \| 推荐方案 \| 选择理由 \| 备选方案 \|
170	\|------\|----------\|----------\|----------\|
171	\| 前端 \| [方案] \| [理由] \| [备选] \|
172	\| 后端 \| [方案] \| [理由] \| [备选] \|
173	\| 数据库 \| [方案] \| [理由] \| [备选] \|
174	\| 缓存 \| [方案] \| [理由] \| [备选] \|
175	\| 部署 \| [方案] \| [理由] \| [备选] \|
176
177	选择理由应包含：
178	- 为什么选择这个方案（优势）
179	- 为什么不选其他方案（劣势）
180	- 与项目需求的匹配度
181	- 团队能力的匹配度
182
183	## 输出要求
184
185	完成技术调研后，应输出以下内容（通常作为架构文档的第1章）：
186
187	```markdown
188	## 1. 技术调研
189
190	### 1.1 调研背景
191
192	需求概述：[基于 PRD 的技术需求总结]
193
194	关键技术挑战：
195	- [挑战 1]
196	- [挑战 2]
197	- [挑战 3]
198
199	### 1.2 技术方案调研
200
201	#### 前端框架对比
202
203	\| 方案 \| 优点 \| 缺点 \| 适用场景 \| 推荐度 \|
204	\|------\|------\|------\|----------\|--------\|
205	\| [方案1] \| ... \| ... \| ... \| ... \|
206	\| [方案2] \| ... \| ... \| ... \| ... \|
207
208	#### 后端框架对比
209
210	[同上]
211
212	#### 数据库对比
213
214	[同上]
215
216	### 1.3 开源方案评估
217
218	\| 开源项目 \| 功能 \| Star 数 \| 维护状态 \| 是否采用 \|
219	\|----------\|------\|---------\|----------\|----------\|
220	\| [项目1] \| ... \| ... \| ... \| ... \|
221
222	### 1.4 调研结论
223
224	\| 层级 \| 推荐方案 \| 选择理由 \| 备选方案 \|
225	\|------\|----------\|----------\|----------\|
226	\| 前端 \| [方案] \| [理由] \| [备选] \|
227	\| 后端 \| [方案] \| [理由] \| [备选] \|
228	\| 数据库 \| [方案] \| [理由] \| [备选] \|
229	```
230
231	## 关键原则
232
233	1. 真实调研：必须真实使用 WebSearch 和 WebFetch，不能凭空编造
234	2. 数据支撑：结论必须基于调研数据，不能主观臆断
235	3. 对比分析：至少对比3个方案，说明为什么选择A而不是B
236	4. 考虑现状：如果项目已有技术栈（通过 shared/tech-stack-detection 检测），优先考虑兼容性
237	5. 团队能力：考虑团队的技术背景和学习成本
238
239	## 常见误区
240
241	❌ 不调研就选型：直接给出技术方案，没有调研过程
242	❌ 只看优点：只列优点不列缺点，缺乏客观性
243	❌ 追新求异：盲目选择最新技术，忽略成熟度和风险
244	❌ 忽略现状：不检测项目现有技术栈，推荐不兼容的方案
245	❌ 缺少备选：只给一个方案，没有Plan B
246
247	## 调研时间建议
248
249	- 简单项目：30分钟 - 1小时
250	- 中型项目：1-2小时
251	- 复杂项目：2-4小时
252
253	不要过度调研，调研的目的是支持决策，不是写论文。

People who liked this also viewed

6 picks

Type

azure-kustoQuery and analyze data in Azure Data Explorer (Kusto/ADX) using KQL for log analytics, telemetry, and time series analysis. WHEN: KQL queries, Kusto database queries, Azure Data Explorer, ADX clustersSkillsJul 2026470k1.3k
lark-base飞书多维表格（Base）操作：建表、字段、记录、视图、统计、公式/lookup、表单、仪表盘、workflow、角色权限；遇到 Base/多维表格/bitable 或 /base/ 链接时使用。文件导入转 lark-drive，认证/授权转 lark-shared。SkillsJul 2026382k16k
lark-calendar飞书日历：管理日历日程和会议室。查看/搜索日程、创建/更新日程、管理参会人、查询忙闲和推荐时段、预定会议室。当用户需要查看日程安排、创建/修改会议、查询/预定会议室时使用。不负责：查询过去的视频会议记录（走 lark-vc）、待办任务（走 lark-task）。SkillsJul 2026380k16k
shadcnManages shadcn components and projects — adding, searching, fixing, debugging, styling, and composing UI, including chat interfaces. Provides project context, component docs, and usage examples. AppliSkillsJul 2026246k120k
xlsxUse this skill any time a spreadsheet file is the primary input or output. This means any task where the user wants to: open, read, edit, or fix an existing .xlsx, .xlsm, .xltx, .csv, or .tsv file (e.SkillsJul 2026139k163k
firebase-data-connectAgent Skills for FirebaseSkillsJul 2026108k387

tech-research

554stars48forks

View on GitHub

How to install tech-research?

echovic/boss-skill/tech-research

$npx -y skills add echoVic/boss-skill --skill tech-research

Installs into the current project.

Summary

技术调研方法论，通过系统性调研和对比分析，为技术选型提供数据支持

Files · 1

View on GitHub

SKILL.md

1	# 技术调研方法论
2
3	## 适用场景
4
5	在进行架构设计和技术选型前，必须先进行系统性的技术调研，了解：
6	- 业界成熟的技术方案
7	- 各方案的优缺点和适用场景
8	- 开源项目的可复用性
9	- 潜在的技术风险
10
11	## 调研流程
12
13	### 1. 明确调研目标
14
15	基于PRD的技术需求，明确需要调研的技术领域：
16
17	调研背景模板：
18
19	```markdown
20	### 1.1 调研背景
21
22	需求概述：[基于 PRD 的技术需求总结]
23
24	关键技术挑战：
25	- [挑战 1]：[具体描述]
26	- [挑战 2]：[具体描述]
27	- [挑战 3]：[具体描述]
28
29	调研目标：
30	- [ ] 前端框架选型
31	- [ ] 后端框架选型
32	- [ ] 数据库选型
33	- [ ] 缓存方案选型
34	- [ ] 部署方案选型
35	```
36
37	### 2. 使用WebSearch进行调研
38
39	#### 搜索策略
40
41	通用搜索模式：
42	```
43	"{技术领域} + best practices + 2026"
44	"{框架名} vs {框架名} comparison 2026"
45	"{技术领域} + benchmark + 2026"
46	"best {技术领域} tools 2026"
47	```
48
49	具体示例：
50
51	前端框架调研：
52	```
53	"React vs Vue vs Angular comparison 2026"
54	"Next.js vs Remix vs Astro 2026"
55	"best React UI libraries 2026"
56	```
57
58	后端框架调研：
59	```
60	"Node.js frameworks comparison 2026"
61	"Express vs Fastify vs Hono benchmark"
62	"Python web frameworks 2026"
63	```
64
65	数据库调研：
66	```
67	"PostgreSQL vs MySQL vs MongoDB 2026"
68	"database for {use case} 2026"
69	"SQL vs NoSQL when to use"
70	```
71
72	ORM调研：
73	```
74	"Prisma vs TypeORM vs Drizzle comparison"
75	"best ORM for {language} 2026"
76	```
77
78	#### 搜索技巧
79
80	1. 包含年份：确保获取最新信息
81	2. 对比搜索：使用 "vs" 或 "comparison" 获取对比分析
82	3. 性能搜索：使用 "benchmark" 或 "performance" 获取性能数据
83	4. 实践搜索：使用 "best practices" 获取最佳实践
84	5. 问题搜索：使用 "pros and cons" 或 "disadvantages" 了解缺点
85
86	### 3. 使用WebFetch深入分析
87
88	对于重要的技术方案，使用 `WebFetch` 深入分析官方文档和技术文章：
89
90	官方文档：
91	```
92	WebFetch("https://nextjs.org/docs", "总结 Next.js 的核心特性、适用场景和最新版本的主要变化")
93	WebFetch("https://www.prisma.io/docs", "提取 Prisma 的核心功能、支持的数据库和性能特点")
94	```
95
96	技术对比文章：
97	```
98	WebFetch("[对比文章URL]", "提取各方案的优缺点对比、性能数据和推荐场景")
99	```
100
101	GitHub仓库：
102	```
103	WebFetch("https://github.com/{org}/{repo}", "提取 Star 数、最近更新时间、维护状态和主要贡献者")
104	```
105
106	### 4. 技术方案对比
107
108	#### 对比维度
109
110	对每个技术方案，从以下维度进行评估：
111
112	\| 维度 \| 评估内容 \|
113	\|------\|----------\|
114	\| 功能完整性 \| 是否满足项目需求 \|
115	\| 性能 \| 响应时间、吞吐量、资源消耗 \|
116	\| 生态系统 \| 社区活跃度、插件丰富度、文档质量 \|
117	\| 学习曲线 \| 团队学习成本、上手难度 \|
118	\| 成熟度 \| 版本稳定性、生产案例、维护状态 \|
119	\| 扩展性 \| 是否易于扩展和定制 \|
120	\| 兼容性 \| 与其他技术的集成难度 \|
121	\| 成本 \| 开发成本、运维成本、授权成本 \|
122
123	#### 对比表格模板
124
125	前端框架对比：
126
127	\| 方案 \| 优点 \| 缺点 \| 适用场景 \| 推荐度 \|
128	\|------\|------\|------\|----------\|--------\|
129	\| Next.js \| SSR/SSG、SEO友好、全栈能力 \| 学习曲线陡、打包体积大 \| 内容型网站、SEO要求高 \| ⭐⭐⭐⭐⭐ \|
130	\| Vite + React \| 开发体验好、构建快 \| 需要自己配置路由等 \| SPA、快速原型 \| ⭐⭐⭐⭐ \|
131	\| Remix \| 数据加载优雅、Web标准 \| 生态较新、案例较少 \| 数据密集型应用 \| ⭐⭐⭐ \|
132
133	后端框架对比：
134
135	\| 方案 \| 优点 \| 缺点 \| 适用场景 \| 推荐度 \|
136	\|------\|------\|------\|----------\|--------\|
137	\| Express \| 成熟、生态丰富、灵活 \| 性能一般、缺少约定 \| 通用后端、快速开发 \| ⭐⭐⭐⭐ \|
138	\| Fastify \| 性能高、插件系统好 \| 生态较Express小 \| 性能要求高的API \| ⭐⭐⭐⭐ \|
139	\| Hono \| 极致性能、边缘计算 \| 生态较新 \| Serverless、边缘函数 \| ⭐⭐⭐ \|
140
141	数据库对比：
142
143	\| 方案 \| 类型 \| 优点 \| 缺点 \| 适用场景 \|
144	\|------\|------\|------\|------\|----------\|
145	\| PostgreSQL \| 关系型 \| 功能强大、扩展性好、JSON支持 \| 运维复杂度高 \| 复杂查询、事务、JSONB \|
146	\| MySQL \| 关系型 \| 简单、普及、性能好 \| 功能较PostgreSQL少 \| 通用场景、读多写少 \|
147	\| MongoDB \| 文档型 \| 灵活、易扩展、开发快 \| 事务支持弱、数据一致性 \| 非结构化数据、快速迭代 \|
148	\| SQLite \| 嵌入式 \| 零配置、单文件、轻量 \| 并发限制、功能有限 \| 小型应用、原型、嵌入式 \|
149
150	### 5. 开源方案评估
151
152	对于可能复用的开源项目，进行系统性评估：
153
154	\| 开源项目 \| 功能 \| Star 数 \| 最近更新 \| 维护状态 \| 是否采用 \| 理由 \|
155	\|----------\|------\|---------\|----------\|----------\|----------\|------\|
156	\| [项目名] \| [功能描述] \| [数量] \| [日期] \| 活跃/停滞 \| 是/否 \| [理由] \|
157
158	评估标准：
159	- Star 数 > 1000：说明有一定用户基础
160	- 最近更新 < 6个月：说明项目活跃
161	- Issue响应及时：说明维护良好
162	- 文档完善：说明易于使用
163	- License友好：MIT/Apache 2.0 等宽松协议
164
165	### 6. 调研结论
166
167	基于调研结果，给出明确的技术选型建议：
168
169	\| 层级 \| 推荐方案 \| 选择理由 \| 备选方案 \|
170	\|------\|----------\|----------\|----------\|
171	\| 前端 \| [方案] \| [理由] \| [备选] \|
172	\| 后端 \| [方案] \| [理由] \| [备选] \|
173	\| 数据库 \| [方案] \| [理由] \| [备选] \|
174	\| 缓存 \| [方案] \| [理由] \| [备选] \|
175	\| 部署 \| [方案] \| [理由] \| [备选] \|
176
177	选择理由应包含：
178	- 为什么选择这个方案（优势）
179	- 为什么不选其他方案（劣势）
180	- 与项目需求的匹配度
181	- 团队能力的匹配度
182
183	## 输出要求
184
185	完成技术调研后，应输出以下内容（通常作为架构文档的第1章）：
186
187	```markdown
188	## 1. 技术调研
189
190	### 1.1 调研背景
191
192	需求概述：[基于 PRD 的技术需求总结]
193
194	关键技术挑战：
195	- [挑战 1]
196	- [挑战 2]
197	- [挑战 3]
198
199	### 1.2 技术方案调研
200
201	#### 前端框架对比
202
203	\| 方案 \| 优点 \| 缺点 \| 适用场景 \| 推荐度 \|
204	\|------\|------\|------\|----------\|--------\|
205	\| [方案1] \| ... \| ... \| ... \| ... \|
206	\| [方案2] \| ... \| ... \| ... \| ... \|
207
208	#### 后端框架对比
209
210	[同上]
211
212	#### 数据库对比
213
214	[同上]
215
216	### 1.3 开源方案评估
217
218	\| 开源项目 \| 功能 \| Star 数 \| 维护状态 \| 是否采用 \|
219	\|----------\|------\|---------\|----------\|----------\|
220	\| [项目1] \| ... \| ... \| ... \| ... \|
221
222	### 1.4 调研结论
223
224	\| 层级 \| 推荐方案 \| 选择理由 \| 备选方案 \|
225	\|------\|----------\|----------\|----------\|
226	\| 前端 \| [方案] \| [理由] \| [备选] \|
227	\| 后端 \| [方案] \| [理由] \| [备选] \|
228	\| 数据库 \| [方案] \| [理由] \| [备选] \|
229	```
230
231	## 关键原则
232
233	1. 真实调研：必须真实使用 WebSearch 和 WebFetch，不能凭空编造
234	2. 数据支撑：结论必须基于调研数据，不能主观臆断
235	3. 对比分析：至少对比3个方案，说明为什么选择A而不是B
236	4. 考虑现状：如果项目已有技术栈（通过 shared/tech-stack-detection 检测），优先考虑兼容性
237	5. 团队能力：考虑团队的技术背景和学习成本
238
239	## 常见误区
240
241	❌ 不调研就选型：直接给出技术方案，没有调研过程
242	❌ 只看优点：只列优点不列缺点，缺乏客观性
243	❌ 追新求异：盲目选择最新技术，忽略成熟度和风险
244	❌ 忽略现状：不检测项目现有技术栈，推荐不兼容的方案
245	❌ 缺少备选：只给一个方案，没有Plan B
246
247	## 调研时间建议
248
249	- 简单项目：30分钟 - 1小时
250	- 中型项目：1-2小时
251	- 复杂项目：2-4小时
252
253	不要过度调研，调研的目的是支持决策，不是写论文。

People who liked this also viewed

6 picks

Type