thinking-triz

TRIZ

解决技术设计中的矛盾，不要折中取中间值。明确矛盾，将对立状态分离，并改造系统，让两种优势兼得。

适用场景

• 架构、API 或系统参数朝相反方向拉扯（稳定与演进、新鲜与缓存、严格与无摩擦）。
• 你正准备接受某种权衡，因为“鱼与熊掌不可兼得”。
• 每个候选方案都存在相同的结构性弱点——矛盾在于需求，而不是选项列表。

不适用场景

• 在给定约束下，一个选项显然更好 → 直接选择；不要凭空制造矛盾。
• 通过低成本测量就能判断哪一方真正重要 → 先测量，而不是虚构分离方案。
• 已有标准模式可以解决问题（cache-aside、CQRS、feature flags、versioning）→ 直接应用该模式。
• 非技术人员或组织之间的冲突 → 不在适用范围内；分离的目标是系统参数。
• 同一参数不存在对立状态，只是普通的优先级排序或资源分配。

流程

1. 按模板明确矛盾。 写出：“我们需要 [PARAMETER] 为 [STATE_1]，以获得 [BENEFIT_1]，但又需要它为 [STATE_2]，以获得 [BENEFIT_2]。”如果不符合这个形式，就停止，改用其他方法。
2. 说明理想最终结果（IFR）。 描述如何以最少的新机制同时保留两种优势，且不永久牺牲中间状态。
3. 先尝试分离，再进行创新。 按顺序测试：时间（不同时间点）、空间（不同组件／层）、条件（上下文、负载、风险）、尺度（接口与实现、整体与元素）。保留第一个能兼得两种优势且没有隐藏妥协的分离方案。
4. 如果分离失败，再应用创新性改造。 优先选择资源消耗少的做法：分段、预先行动、反转（推／拉）、中介、复制／副本、动态化（标记／配置）、引入另一个维度（元数据／版本控制／事件）。只筛选与已明确的参数矛盾相对应的原理。
5. 优先复用现有资源。 添加服务或存储之前，先检查已有的数据、流量、标头、调度器和副作用，看看是否能用来实现分离。
6. 确定具体方案后停止。 明确设计变更、每种状态所在的位置，以及如何保留两种优势。当方案已实现无妥协设计，或经审慎分析确认只剩受限的权衡时，就停止；此时应明确记录剩余权衡，而不是强行表演 TRIZ。

输出

输出一份 TRIZ 解决方案：

• contradiction：参数 / state_1+benefit_1 / state_2+benefit_2
• ideal_final_result：不作永久妥协，同时保留两种优势
• separation_tried：时间 | 空间 | 条件 | 尺度 → 各自的结果
• inventive_move：如果仅靠分离无法解决，说明所用原理或模式（否则填 none）
• resources_reused：利用的现有能力
• resolution：具体设计决策及每种状态所在的位置
• residual_tradeoff：无，或诚实说明剩余的妥协

验证

• **模板门槛：**如果无法按要求的形式描述矛盾，就不要应用 TRIZ。
• **无妥协检查：**如果只是在权衡曲线上取中间值，且没有采用分离或创新性改造，则属于应用失败。
• **先分离：**未尝试时间／空间／条件／尺度分离就直接应用原理，属于流程不完整。
• **避免过度应用：**如果测量或标准模式就能确定设计方案，应跳过 TRIZ。
• **停止：**明确一个矛盾 → 完成分离／创新性分析 → 给出具体方案；不要把不断套用原理当作装饰。