compare

name	compare
description	当用户在纠结选哪个技术、对比框架、选数据库、选部署方案时使用 -- 对比不同技术方案的优劣，帮你做出选择

技术选型

帮用户在多个技术方案中做出最适合的选择。

步骤

0. 前置检查：是否该现在选型？

如果用户还没有可运行的原型，先提醒：

你目前有可运行的版本吗？如果还没有，建议先用最简单的方案把核心功能跑通，遇到瓶颈再做选型。过早优化是最常见的时间黑洞。

如果用户确认需要现在决定（比如架构选型无法推迟），继续下一步。

1. 确定选型问题

如果用户已经提了，直接分析。否则问：

你在纠结什么选择？比如：

• React vs Vue vs Svelte
• PostgreSQL vs MySQL vs MongoDB
• Vercel vs Railway vs 自建服务器 也可以描述你要解决的问题，我帮你列出候选方案。

2. 了解背景

几个问题帮我给出更准确的建议：

1. 项目规模？（个人项目 / 团队 / 企业）
2. 你对这些技术的经验如何？
3. 有什么硬性要求？（比如必须免费、必须支持中文）
4. 哪个维度对你最重要？（开发速度 / 性能 / 长期维护 / 成本）

3. 对比分析

用表格对比候选方案，包含「决策权重」和「迁移成本」：

| 维度         | 权重  | 方案 A | 方案 B | 方案 C |
|-------------|-------|--------|--------|--------|
| 学习成本     | 高/中/低 | ...  | ...    | ...    |
| 生态/社区    | 高/中/低 | ...  | ...    | ...    |
| 性能         | 高/中/低 | ...  | ...    | ...    |
| 费用         | 高/中/低 | ...  | ...    | ...    |
| 迁移成本     | --    | 换掉要多久？ | 换掉要多久？ | 换掉要多久？ |

权重根据用户第 2 步的回答填写。迁移成本必须包含：数据迁移难度、API 兼容性、团队学习成本。

4. 给出推荐 + 决策记录

推荐用 xxx。原因：（2-3 个关键理由）

决策记录（可粘贴到 CLAUDE.md 的决策日志中）： 选择 xxx 而不是 yyy -- 原因：...；否决 yyy 因为 ...

想用这个方案开始吗？我可以帮你搭建。

如果用户同意，引导到 /starter 或对应的技能。

遇到问题

• 所有方案看起来差不多？ 说明这个选择不关键。选迁移成本最低的那个，把时间花在核心功能上。
• 需求可能变？ 选生态最大、迁移成本最低的方案，给自己留退路。不要为当前不确定的需求过度设计。
• 对比了很久还是不敢决定？ 设一个时间上限（比如 30 分钟）。超时就选默认最流行的方案，先动手写代码。