用途：当需要在技术、框架或工具之间做选择，例如“该用哪个框架”“比较 X 与 Y”“是否应从 X 迁移”时使用。不适用于决策无关紧要、技术已被强制指定，或属于紧急生产故障的场景。
主要能力：先厘清真正要决定的问题和真实需求，避免先选技术再定义问题；列出 2–4 个现实候选；从主准则中选 6–8 项并分配权重（合计 100%）；对每个候选按 1–5 分打分并给一行理由；评估生态健康（GitHub 活跃度、npm/PyPI 采用、社区强度、企业支持与趋势）；测算 5 年 TCO，含计算、存储、带宽、许可、工程时间（搭建与持续维护）与运维开销，工程时间通常是初创公司最大成本；若是迁移，评估工作量、风险、时间线并建议分阶段（strangler fig 模式）。最终给出明确赢家、理由与置信度，不用“看情况”而不追问。
使用方式：需结合产品类型、团队技能、现有技术栈、阶段、规模与预算等背景，并追问要解决的问题、不可妥协的要求、团队对各选项的经验、时间压力与增长预期。输出按决策背景、候选、评估准则、评分矩阵、生态健康、TCO、安全合规、推荐、迁移路径等分段。
适用场景：前后端框架或库比较、云厂商选型、技术迁移规划、含隐藏成本的 TCO 计算、构建与购买决策、开源库可行性评估。
限制：信息不足时不应硬做决策；置信度低于 50% 建议先做概念验证。需警惕简历驱动开发、炒作周期陷阱、过早优化、沉没成本、忽视团队技能与方案先行等反模式。具体价格、平台与实施细节以实际情况为准。