用途：把产品决策中的取舍讲清楚，让团队能够针对决策提出异议，而不是事后才发现。适用于范围与时间、质量与速度、灵活与简单、短期与长期、不同用户群之间的权衡。
主要能力：要求显式命名取舍，例如“我们选择 X，代价是 Y，因为 Z”；要求书面记录取舍，让团队知道牺牲了什么及原因；建议以“带后果的选项”而非已定决策呈现给相关方；强调当驱动取舍的上下文变化时重新审视。
常用维度：范围 vs 时间线（按时应交付更少，还是延后交付更多）、质量 vs 速度、灵活 vs 简单、短期 vs 长期、服务某一用户群 vs 另一用户群。需先判断真正紧张的维度。
评估框架：先定义优化目标；比较选项 A 与 B 的最坏情况；考虑可逆性，优先可逆决策，对不可逆决策更谨慎；估算选错的代价；不可脱离上下文评估。
沟通方式：用用户与业务影响表述，而非技术细节；给出选项的利弊与推荐；为所选取舍负责；不把取舍说成没有代价。
用法：输入 /trade-off-evaluation 将取舍约束应用于当前对话；或输入 /trade-off-evaluation <trade-off> 评估某个具体取舍。
反模式：假二分法、隐藏取舍、分析瘫痪、拒绝取舍的“全都要”、先凭直觉决定再事后编理由。
限制：资料未提供平台、收费、价格与效果等信息。