两个设计需求看似互斥时：用 TRIZ…

当架构、API 或系统参数被相反方向拉扯、即将接受“不能两全”的折中，且冲突在需求本身时，用 TRIZ 分离对立状态或做发明式变换，同时保留两个收益。

适用场景

解决思路

1. 用模板命名矛盾：写下“我们需要 [PARAMETER] 在 [BENEFIT_1] 上为 [STATE_1]，但在 [BENEFIT_2] 上需要 [STATE_2]。”如果无法套入该形式，停止，改用其他方法。
2. 陈述理想最终结果（IFR）：描述同时保住两个收益，且只引入最少新机制、不永久牺牲中点/折中。
3. 先尝试分离，再发明：按顺序测试 time（不同时刻）、space（不同组件/层）、condition（上下文、负载、风险）、scale（接口 vs 实现、聚合 vs 元素）。保留第一个能在没有隐藏折中的情况下同时带来两个收益的分离。
4. 如果分离失败，应用发明式变换：优先资源轻的动作：segmentation、preliminary action、inversion（push/pull）、intermediary、copying/replication、dynamization（flags/config）、another dimension（metadata/versioning/events）。只扫描能映射到已命名参数冲突的原理。
5. 先复用现有资源：在新增服务或存储前，检查已有数据、流量、headers、schedulers、side effects 是否可以承载这种分离。
6. 锁定具体方案并停止：明确设计变更、每个状态存在于何处、两个收益如何保留。当无妥协设计已陈述，或诚实分析表明只剩受限折中时停止——此时明确记录残余折中，而不是强行 TRIZ 表演。
7. 输出 TRIZ 方案：`contradiction`: parameter / state_1+benefit_1 / state_2+benefit_2；`ideal_final_result`: 两个收益且无永久折中；`separation_tried`: time | space | condition | scale → 每个的结果；`inventive_move`: 若单靠分离不够则使用 principle 或 pattern（没有则 none）；`resources_reused`: 复用的现有能力；`resolution`: 具体设计决策及每个状态成立的位置；`residual_tradeoff`: none，或诚实保留的剩余妥协。
8. 验证：模板门禁：如果矛盾无法写成要求的形式，不要应用 TRIZ。
9. 验证：无妥协检查：只在权衡曲线上取纯中点、没有 separation 或 inventive move，是失败应用。
10. 验证：分离优先：没有尝试 time/space/condition/scale separation 就直接用 principles，是不完整的。
11. 验证：过度应用防护：如果 measurement 或 standard pattern 已能敲定设计，跳过 TRIZ。
12. 验证：停止：一个已命名矛盾 → separation/inventive 一轮 → 具体 resolution；不要把 principles 循环用作装饰。

适用边界 · 注意事项

• 一个选项在给定约束下已明显更好：直接选它，不要制造矛盾。
• 廉价测量能说明哪一侧真正重要，或标准模式（cache-aside、CQRS、feature flags、versioning）已能解决：直接测量或套用模式，不要发明分离。
• 非技术的人/组织冲突，或没有同一个参数对立状态的普通优先级/资源分配：超出范围，不要使用 TRIZ。