用途
TRIZ 用于在不做中点妥协的前提下解决技术设计矛盾。它的核心做法是：命名冲突、分离对立状态，并改造系统，使两种收益同时成立。
何时使用
- 架构、API 或系统参数朝相反方向拉扯（稳定与演进、新鲜与缓存、严格与无摩擦）。
- 你即将因为“不能两者兼得”而接受一个权衡。
- 每个候选方案都带有相同的结构性弱点——冲突在需求中，而不在选项列表中。
何时不使用
- 在既定约束下某个选项明显更好 → 直接选它，不要人为制造矛盾。
- 一次低成本测量就能看出哪一侧真正重要 → 去测量，而不是发明分离。
- 已有标准模式能解决（cache-aside、CQRS、功能开关、版本化）→ 直接套用该模式。
- 非技术的人员或组织冲突 → 超出范围；分离针对的是系统参数。
- 没有同一参数对立状态的普通优先级排序或资源分配。
步骤
- 用模板形式命名矛盾。写出：“我们需要 [参数] 在 [收益1] 时是 [状态1]，但在 [收益2] 时是 [状态2]。”如果这个形式写不出来，就停止——改用其他方法。
- 陈述理想最终结果（IFR）。描述在最小新增机制、且不做永久中点牺牲的情况下同时持有两种收益。
- 先尝试分离，再考虑发明。按顺序测试：时间（不同时刻）、空间（不同组件/层）、条件（上下文、负载、风险）、尺度（接口与实现、聚合与元素）。保留第一个能在无隐藏妥协下带来两种收益的分离。
- 如果分离失败，应用发明性变换。优先选择轻资源动作：分割、预先作用、反转（推/拉）、中介、复制/复用、动态化（开关/配置）、另一维度（元数据/版本化/事件）。只扫描与所命名参数冲突对应的原理。
- 优先复用现有资源。在新增服务或存储之前，检查已经存在的数据、流量、请求头、调度器和副作用，看它们能否承载这种分离。
- 锁定一个具体解决方案并停止。明确设计变更、每个状态所在的位置，以及两种收益如何被保留。当无妥协设计被陈述出来时停止；或者当诚实分析表明只剩受限权衡时停止——此时明确记录残余权衡，而不是强行表演 TRIZ。
输出
输出一个 TRIZ 解决方案：
- contradiction：参数 / 状态1+收益1 / 状态2+收益2
- ideal_final_result：两种收益且无永久妥协
- separation_tried：时间 | 空间 | 条件 | 尺度 → 各自结果
- inventive_move：若仅靠分离不足，所使用的原理或模式（或 none）
- resources_reused：所利用的现有能力
- resolution：具体设计决策以及每个状态成立的位置
- residual_tradeoff：none，或诚实说明的剩余妥协
验证
- 模板门槛：如果矛盾无法写成要求的形式，不要应用 TRIZ。
- 无妥协检查：在权衡曲线上取纯中点、而没有分离或发明性动作，属于失败应用。
- 分离优先：未尝试时间/空间/条件/尺度分离就使用原理，是不完整的。
- 过度应用防护：如果测量或标准模式已能确定设计，跳过 TRIZ。
- 停止：一个命名矛盾 → 分离/发明一轮 → 具体解决方案；不要把原理循环当作装饰。