tech-stack-eval

技术栈评估

适用场景

• 为新项目比较前端／后端框架或库
• 针对特定工作负载评估云服务提供商（AWS、Azure 或 GCP）
• 制定技术迁移计划，并评估风险与投入
• 计算包含隐性成本在内的 TCO；决定自建还是购买
• 评估开源库的可行性和生态系统健康状况

不要在以下情况使用：决策很简单（遵循团队偏好即可）、技术已被强制指定，或遇到紧急生产问题。

所需上下文

从 startup-context 获取：产品类型、团队技能、技术栈、阶段、规模和预算。还要询问：

• 要解决什么问题？（对于先选解决方案再找问题的思路，应提出质疑）
• 不可妥协的要求（性能、合规性、团队熟悉程度）
• 团队对各个选项的经验以及时间压力（期限紧迫时，熟悉的工具更有优势）
• 会影响可扩展性要求的增长预期

工作流

1. 明确决策 — 具体要做什么决定？真正的需求是什么？如果用户在定义问题前就选好了技术，应提出质疑。
2. 确定候选项 — 列出 2-4 个实际可行的选项。尽早排除明显不合适的选择。
3. 制定加权评估标准 — 从下方主标准列表中选出 6-8 项。根据用户的优先事项分配权重（总计 = 100%）。
4. 为各候选项打分 — 按每项标准评 1-5 分，并为每个分数提供一行理由。
5. 评估生态系统健康状况 — 评估 GitHub 活跃度、npm/PyPI 采用情况、社区实力、企业支持以及发展趋势（增长、稳定或衰退）。
6. 计算 TCO — 预测 5 年总成本，包括计算、存储、带宽、许可、工程时间（设置 + 持续投入）和运维开销。对初创公司来说，工程时间通常是最大的成本。
7. 分析迁移路径 — 如果涉及迁移，估算投入、风险和时间，并推荐分阶段方案（绞杀者无花果模式）。
8. 给出建议 — 明确胜出选项、理由和置信度。不要只说“视情况而定”，应提出后续问题来消除歧义。

输出格式

# Tech Stack Evaluation: [Decision Title]

## Decision Context — what we are choosing and why it matters
## Candidates — table: technology, version, license, one-liner
## Evaluation Criteria — table: criterion, weight, why it matters
## Scoring Matrix — table: criterion (weight), scores per option, weighted total
## Ecosystem Health — table: GitHub stars, weekly downloads, last release, open issues, major users
## TCO Estimate — table: cost category by option over 12 months or 5 years
## Security & Compliance — vulnerability history, compliance readiness (SOC 2, GDPR)
## Recommendation — clear winner, rationale, confidence level, caveats
## Migration Path (if applicable) — phased plan with timeline and rollback strategy

框架与最佳实践

主评估标准

选出 6-8 项并分配权重（总计 = 100%）：

• 性能 — 针对特定工作负载的吞吐量、延迟和资源效率
• 开发者体验 — 工具、调试、文档质量和错误消息
• 学习曲线／团队熟悉程度 — 当前团队达到高效产出的时间
• 生态系统与库 — 软件包、集成和第三方支持
• 维护与生命周期 — 发布频率、企业支持和关键人员依赖风险
• 招聘人才池 — 所在市场和薪资范围内开发者的可获得性
• 可扩展性 — 无需重写即可应对 10-100 倍的增长
• 成本／供应商锁定 — TCO 以及日后迁移所需的切换成本
• 安全与合规 — 漏洞记录和合规工具的成熟度

生态系统健康状况评分

级别	标准
蓬勃发展	定期发布（< 3 个月），采用率持续增长，有多个企业赞助方，社区活跃
稳定	定期发布（< 6 个月），采用率稳定，社区成熟，没有衰退迹象
存在风险	发布不频繁（> 12 个月），下载量下降，关键维护者离开，贡献者寥寥

TCO 计算框架

至少预测 12 个月（基础设施决策则预测 5 年）：计算、存储、带宽、许可、工程时间（设置 + 持续维护时间 x 综合人工成本）、运维开销（监控、值班）和隐性成本（培训、迁移工具、双轨运行）。

对初创公司来说，工程时间通常是最大的成本。 某项技术每月节省 200 美元托管费用，但运行它需要额外投入 40 小时工程时间，最终反而得不偿失。

迁移风险评估

风险级别	标准
低	增量变更，无需迁移数据，可以并行运行，耗时少于 2 周
中	需要迁移数据或更改 API，耗时 2-8 周，可以分阶段进行
高	替换核心系统，耗时超过 8 周，需要停机或一次性切换

采用绞杀者无花果模式：将新流量路由到新系统，逐步迁移旧系统。始终保留回滚能力。设定明确的截止日期——迁移一半的系统是最糟糕的结果。

置信度级别

级别	分数	解读
高	80-100%	明确胜出，数据有力，优势明显
中	50-79%	存在权衡，但建议仍然成立，只是附带条件
低	< 50%	难分高下，数据有限，建议先进行概念验证再做决定

常见决策反模式

• 简历驱动开发 — 为了简历选择技术，而非考虑是否合适
• 炒作周期陷阱 — 在热度顶峰、稳定性尚未得到验证时采用
• 过早优化 — 明明一台 Postgres 就能处理负载，却采用分布式系统
• 沉没成本谬误 — 因为之前的投入而拒绝迁移
• 忽视团队技能 / 解决方案优先思维 — 选择团队无人熟悉的技术，或在定义问题之前就选定技术

相关技能

• architecture-design — 当技术栈决策会影响更广泛的系统设计时，串联此技能
• cicd-setup — 串联此技能，为选定的技术配置 CI/CD

示例

示例提示词：“比较 React 和 Vue，用于 SaaS 仪表盘。优先级：开发效率（40%）、生态系统（30%）、性能（30%）。”

良好输出片段：

## Scoring Matrix
| Criterion (weight)       | React | Vue  |
|--------------------------|-------|------|
| Developer Productivity (40%) | 4/5   | 4/5  |
| Ecosystem (30%)          | 5/5   | 4/5  |
| Performance (30%)        | 4/5   | 5/5  |
| **Weighted Total**       | **4.3** | **4.3** |

Confidence: Medium (55%). Scores are nearly identical. Recommendation: React,
but only because your team has 2 years of React experience (not captured in
the matrix). If the team were greenfield, Vue's developer experience gives it
a slight edge. This is close enough to warrant team preference as the tiebreaker.

示例提示词：“我们使用 Heroku，每月费用为 $2,400。应该迁移到 AWS 吗？”

良好输出片段：

## TCO Estimate (12 months)
| Category             | Heroku    | AWS               |
|----------------------|-----------|-------------------|
| Compute              | $1,200/mo | $480/mo (ECS)     |
| Database             | $800/mo   | $350/mo (RDS)     |
| Add-ons              | $400/mo   | $120/mo           |
| Engineering (setup)  | $0        | $12,000 one-time  |
| Engineering (ongoing)| 2 hrs/mo  | 8 hrs/mo          |
| **Annual Total**     | **$28,800** | **$18,000**     |

Break-even at month 14. At Series A with a team of 6, wait until Heroku hits
$4,000/mo — engineering hours are better spent on product right now.