Tech Stack Evaluation
技术栈评估
- Comparing frontend/backend frameworks or libraries for new projects
- Evaluating cloud providers (AWS vs Azure vs GCP) for specific workloads
- Planning technology migrations with risk and effort assessment
- Calculating TCO including hidden costs; making build vs. buy decisions
- Assessing open-source library viability and ecosystem health
Do NOT use when: the decision is trivial (use team preference), the technology is already mandated, or this is an emergency production issue.
- 为新项目比较前端/后端框架或库
- 针对特定工作负载评估云服务商（AWS vs Azure vs GCP）
- 规划技术迁移并评估风险和工作量
- 计算包含隐性成本的 TCO；做出 build vs. buy 决策
- 评估开源库的可行性与生态健康度
如果决策很简单（采用团队偏好）、技术已经强制确定，或属于紧急生产问题，则不要使用。
From
: product type, team skills, tech stack, stage, scale, budget. Also ask:
- What problem are you solving? (push back on solution-first thinking)
- Non-negotiable requirements (performance, compliance, team familiarity)
- Team experience with each option and timeline pressure (tight deadlines favor familiar tools)
- Growth expectations that affect scalability requirements
从
获取：产品类型、团队技能、技术栈、阶段、规模、预算。此外还要询问：
- 你要解决什么问题？（对 solution-first thinking 予以质疑）
- 不可妥协的要求（性能、合规性、团队熟悉度）
- 团队对每个选项的经验以及时间压力（截止日期紧时，熟悉的工具更优）
- 影响可扩展性要求的增长预期
- Clarify the decision — What exactly is being decided and what are the real requirements? Push back if the user picks tech before defining the problem.
- Identify candidates — List 2-4 realistic options. Exclude clearly wrong choices early.
- Define weighted evaluation criteria — Select 6-8 criteria from the master list below. Assign weights based on the user's priorities (total = 100%).
- Score each candidate — Rate 1-5 on each criterion with one-line justification per score.
- Assess ecosystem health — Evaluate GitHub activity, npm/PyPI adoption, community strength, corporate backing, and trajectory (growing, stable, declining).
- Calculate TCO — Project 5-year total cost including compute, storage, bandwidth, licensing, engineering time (setup + ongoing), and operational overhead. Engineering time is usually the largest cost for startups.
- Analyze migration path — If migrating, estimate effort, risks, timeline, and recommend phased approach (strangler fig pattern).
- Deliver recommendation — Clear winner with rationale and confidence level. No "it depends" without a follow-up question to resolve the ambiguity.
- 明确决策 — 具体要决定什么，实际需求是什么？如果用户在定义问题前就选定技术，应予以质疑。
- 确定候选项 — 列出 2-4 个现实可行的选项。尽早排除明显错误的选择。
- 定义加权评估标准 — 从下方主清单中选择 6-8 项。根据用户的优先事项分配权重（总和 = 100%）。
- 为每个候选项评分 — 每项标准按 1-5 分评分，并为每个分数给出一句话理由。
- 评估生态健康度 — 评估 GitHub 活跃度、npm/PyPI 采用情况、社区实力、企业支持和发展轨迹（增长、稳定、衰退）。
- 计算 TCO — 预测 5 年总成本，包括计算、存储、带宽、许可、工程时间（设置 + 持续投入）和运营开销。对于初创公司，工程时间通常是最大成本。
- 分析迁移路径 — 如果要迁移，估算工作量、风险、时间线，并建议采用分阶段方式（strangler fig pattern）。
- 给出推荐 — 明确推荐项，并说明理由和置信度。不要在没有后续问题来消除歧义的情况下回答“视情况而定”。
Tech Stack Evaluation: [Decision Title]
Tech Stack Evaluation: [Decision Title]
Decision Context — what we are choosing and why it matters
Decision Context — what we are choosing and why it matters
Candidates — table: technology, version, license, one-liner
Candidates — table: technology, version, license, one-liner
Evaluation Criteria — table: criterion, weight, why it matters
Evaluation Criteria — table: criterion, weight, why it matters
Scoring Matrix — table: criterion (weight), scores per option, weighted total
Scoring Matrix — table: criterion (weight), scores per option, weighted total
Ecosystem Health — table: GitHub stars, weekly downloads, last release, open issues, major users
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
TCO Estimate — table: cost category by option over 12 months or 5 years
Security & Compliance — vulnerability history, compliance readiness (SOC 2, GDPR)
Security & Compliance — vulnerability history, compliance readiness (SOC 2, GDPR)
Recommendation — clear winner, rationale, confidence level, caveats
Recommendation — clear winner, rationale, confidence level, caveats
Migration Path (if applicable) — phased plan with timeline and rollback strategy
Migration Path (if applicable) — phased plan with timeline and rollback strategy
Frameworks & Best Practices
框架与最佳实践
Master Evaluation Criteria
主评估标准
Select 6-8 and assign weights (total = 100%):
- Performance — throughput, latency, resource efficiency for the specific workload
- Developer Experience — tooling, debugging, documentation quality, error messages
- Learning Curve / Team Familiarity — time to productivity for the current team
- Ecosystem & Libraries — packages, integrations, third-party support
- Maintenance & Longevity — release cadence, corporate backing, bus factor
- Hiring Pool — developer availability in your market and salary band
- Scalability — handle 10-100x growth without a rewrite
- Cost / Vendor Lock-in — TCO and switching cost if you need to move later
- Security & Compliance — vulnerability track record, compliance tooling readiness
选择 6-8 项并分配权重（总和 = 100%）：
- 性能 — 特定工作负载下的吞吐量、延迟、资源效率
- 开发者体验 — 工具链、调试、文档质量、错误信息
- 学习曲线/团队熟悉度 — 当前团队达到生产力所需的时间
- 生态与库 — 包、集成、第三方支持
- 维护与长期可持续性 — 发布节奏、企业支持、bus factor
- 招聘人才池 — 开发者在你所在市场的可用性和薪资区间
- 可扩展性 — 无需重写即可应对 10-100 倍增长
- 成本/供应商锁定 — TCO，以及以后需要迁移时的切换成本
- 安全与合规 — 漏洞记录、合规工具准备情况
Ecosystem Health Scoring
生态健康度评分
| Level | Criteria |
|---|
| Thriving | Regular releases (< 3 months), growing adoption, multiple corporate sponsors, active community |
| Stable | Regular releases (< 6 months), steady adoption, established community, no decline signs |
| At Risk | Infrequent releases (> 12 months), declining downloads, key maintainers leaving, few contributors |
| 等级 | 标准 |
|---|
| 蓬勃发展 | 定期发布（< 3 个月）、采用率增长、多个企业赞助方、活跃社区 |
| 稳定 | 定期发布（< 6 个月）、采用率稳定、成熟的社区、没有衰退迹象 |
| 有风险 | 发布不频繁（> 12 个月）、下载量下降、关键维护者离开、贡献者很少 |
TCO Calculation Framework
TCO 计算框架
Project over 12 months minimum (5 years for infrastructure decisions): compute, storage, bandwidth, licensing, engineering time (setup + ongoing maintenance x loaded cost), operational overhead (monitoring, on-call), and hidden costs (training, migration tooling, dual-running).
Engineering time is usually the largest cost for startups. A technology saving $200/month on hosting but costing 40 extra engineering hours to operate is a net loss.
至少预测 12 个月（基础设施决策预测 5 年）：计算、存储、带宽、许可、工程时间（设置 + 持续维护 × 完全负担成本）、运营开销（监控、on-call），以及隐性成本（培训、迁移工具、双轨运行）。
对于初创公司，工程时间通常是最大成本。 一项每月在托管上节省 $200、但需要额外 40 个工程小时来运维的技术，实际上是净亏损。
Migration Risk Assessment
迁移风险评估
| Risk Level | Criteria |
|---|
| Low | Additive change, no data migration, can run in parallel, < 2 weeks |
| Medium | Requires data migration or API changes, 2-8 weeks, can be phased |
| High | Core system replacement, > 8 weeks, requires downtime or big-bang cutover |
Use the strangler fig pattern: route new traffic to the new system, migrate old incrementally. Always maintain rollback capability. Set a concrete cut-off date -- half-migrated systems are the worst outcome.
| 风险等级 | 标准 |
|---|
| 低 | 增量式变更，无需数据迁移，可并行运行，< 2 周 |
| 中 | 需要数据迁移或 API 更改，2-8 周，可以分阶段进行 |
| 高 | 替换核心系统，> 8 周，需要停机或 big-bang cutover |
使用 strangler fig pattern：将新流量路由到新系统，逐步迁移旧系统。始终保持回滚能力。设定一个明确的截止日期 -- 半迁移系统是最糟糕的结果。
| Level | Score | Interpretation |
|---|
| High | 80-100% | Clear winner, strong data, wide margin |
| Medium | 50-79% | Trade-offs present, recommendation holds but with caveats |
| Low | < 50% | Close call, limited data, suggest a proof-of-concept before committing |
| 等级 | 分数 | 解读 |
|---|
| 高 | 80-100% | 胜出者明确，数据充分，优势显著 |
| 中 | 50-79% | 存在权衡，推荐结论成立，但有注意事项 |
| 低 | < 50% | 两者接近，数据有限，建议在投入前进行 proof-of-concept |
Common Decision Anti-Patterns
常见决策反模式
- Resume-Driven Development — choosing tech for resumes, not fit
- Hype Cycle Trap — adopting at peak hype before stability is proven
- Premature Optimization — distributed systems when a single Postgres handles the load
- Sunk Cost Fallacy — refusing to migrate because of prior investment
- Ignoring Team Skills / Solution-First Thinking — picking tech nobody knows, or selecting technology before defining the problem
- Resume-Driven Development — 为简历而选择技术，而不是考虑适配度
- Hype Cycle Trap — 在稳定性得到验证之前，于炒作高峰时采用
- Premature Optimization — 在单个 Postgres 足以承载负载时引入分布式系统
- Sunk Cost Fallacy — 因为过去的投入而拒绝迁移
- Ignoring Team Skills / Solution-First Thinking — 选择团队无人了解的技术，或在定义问题之前就选定技术
- — chain when the tech stack decision feeds into a broader system design
- — chain to configure CI/CD for the chosen technology
- — 当技术栈决策需要衔接更广泛的系统设计时，串联使用
- — 串联使用，为选定的技术配置 CI/CD
Example prompt: "Compare React vs Vue for a SaaS dashboard. Priorities: developer productivity (40%), ecosystem (30%), performance (30%)."
Good output snippet:
示例提示词： “比较 React 和 Vue，场景为 SaaS dashboard。优先级：开发者生产力（40%）、生态（30%）、性能（30%）。”
良好的输出片段：
Scoring Matrix
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.
**Example prompt:** "We're on Heroku at $2,400/mo. Should we migrate to AWS?"
**Good output snippet:**
| 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)
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.
| 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.