| name | compare |
| description | 当用户在纠结选哪个技术、对比框架、选数据库、选部署方案时使用 -- 对比不同技术方案的优劣,帮你做出选择 |
技术选型
帮用户在多个技术方案中做出最适合的选择。
步骤
0. 前置检查:是否该现在选型?
如果用户还没有可运行的原型,先提醒:
你目前有可运行的版本吗?如果还没有,建议先用最简单的方案把核心功能跑通,遇到瓶颈再做选型。过早优化是最常见的时间黑洞。
如果用户确认需要现在决定(比如架构选型无法推迟),继续下一步。
1. 确定选型问题
如果用户已经提了,直接分析。否则问:
你在纠结什么选择?比如:
- React vs Vue vs Svelte
- PostgreSQL vs MySQL vs MongoDB
- Vercel vs Railway vs 自建服务器
也可以描述你要解决的问题,我帮你列出候选方案。
2. 了解背景
几个问题帮我给出更准确的建议:
- 项目规模?(个人项目 / 团队 / 企业)
- 你对这些技术的经验如何?
- 有什么硬性要求?(比如必须免费、必须支持中文)
- 哪个维度对你最重要?(开发速度 / 性能 / 长期维护 / 成本)
3. 对比分析
用表格对比候选方案,包含「决策权重」和「迁移成本」:
| 维度 | 权重 | 方案 A | 方案 B | 方案 C |
|-------------|-------|--------|--------|--------|
| 学习成本 | 高/中/低 | ... | ... | ... |
| 生态/社区 | 高/中/低 | ... | ... | ... |
| 性能 | 高/中/低 | ... | ... | ... |
| 费用 | 高/中/低 | ... | ... | ... |
| 迁移成本 | -- | 换掉要多久? | 换掉要多久? | 换掉要多久? |
权重根据用户第 2 步的回答填写。迁移成本必须包含:数据迁移难度、API 兼容性、团队学习成本。
4. 给出推荐 + 决策记录
推荐用 xxx。原因:(2-3 个关键理由)
决策记录(可粘贴到 CLAUDE.md 的决策日志中):
选择 xxx 而不是 yyy -- 原因:...;否决 yyy 因为 ...
想用这个方案开始吗?我可以帮你搭建。
如果用户同意,引导到 /starter 或对应的技能。
遇到问题
- 所有方案看起来差不多? 说明这个选择不关键。选迁移成本最低的那个,把时间花在核心功能上。
- 需求可能变? 选生态最大、迁移成本最低的方案,给自己留退路。不要为当前不确定的需求过度设计。
- 对比了很久还是不敢决定? 设一个时间上限(比如 30 分钟)。超时就选默认最流行的方案,先动手写代码。