2.2 技术矛盾与物理矛盾：创新的真正入口

2.2 技术矛盾与物理矛盾：创新的真正入口

本节摘要：矛盾建模把工程抱怨翻译为标准格式——技术矛盾（改善参数 A 恶化参数 B）与物理矛盾（同一对象需要相反属性）。本节给出两种矛盾的构造步骤、从技术矛盾下钻到物理矛盾的提问法、39 个工程参数的使用要领，以及一个矛盾表述的质检脚本。

一句抱怨的两次翻译

拿除尘器团队的原话："提精度压降就爆。"这句话要经过两次翻译才能被 SIM 工具消费。

第一次翻译，得到技术矛盾：因为（改善）过滤精度，（导致恶化）压降与能耗。格式固定：一个改善参数 + 一个恶化参数，且两个参数必须是可沿标尺度量的一般化工程量。这里"过滤精度"对应 39 参数体系里的"有害因素的数量"或按颗粒尺寸细化为"物质属性"，"压降"归入"能量消耗"或"压力"。

第二次翻译，下钻得到物理矛盾：问一个固定问题——"为了实现改善的那个参数，哪个对象必须具备什么属性？为了不恶化另一个参数，同一对象必须具备什么相反属性？"答案：滤材层必须致密（挡细颗粒），同时必须疏松（让气流低阻通过）。致密与疏松加在同一对象（滤材）同一情境（过滤工作态）上——物理矛盾成立。

两次翻译完成后，SIM 的问题重述全部完成。剩下的就是 3.2 节的矛盾矩阵吃技术矛盾、3.3 节的分离原理吃物理矛盾。翻译质量占最终方案质量的一大半，这不是夸张——矩阵查得再准，参数映射错了就全错。

39 个工程参数：一般化的意义

TRIZ 的 39 个工程参数（可动体重量、静止体重量、长度、面积、体积、速度、力、张力压强、形状、物质数量、有害因素数量……）是一套"通用货币"。任何行业的具体参数都要先换成这套货币，才能使用跨行业统计出来的矛盾矩阵。换算的技巧：

• 别追求唯一对应。一个具体参数往往可以映射为两三个通用参数，全列出来，多查几轮矩阵；
• "有害因素的数量"是使用频率最高的参数之一——污染、噪音、毛刺、误差，统统先归到它名下；
• 有恶化方向的参数（有害因素、能量消耗、装置复杂性）注意矩阵的行列方向，改善与恶化调换会得到不同的推荐原理。

矛盾的质检：三条规则一个脚本

构造出的矛盾表述要过三条质检：参数一般化（映射到通用参数）、因果闭合（改善与恶化之间有明确机理）、无折中残留（表述里不能暗含"找一个平衡点"的预期）。用脚本做结构化检查：

"""矛盾表述质检器：检查技术矛盾与物理矛盾的结构完整性。"""

def check_contradictions(tc: dict, pc: dict) -> list[str]:
    problems = []
    if not tc.get("improve") or not tc.get("worsen"):
        problems.append("技术矛盾缺改善方或恶化方")
    if tc.get("improve") == tc.get("worsen"):
        problems.append("改善与恶化是同一参数：这已是物理矛盾，别走矩阵路线")
    if not pc.get("object") or len(pc.get("properties", [])) != 2:
        problems.append("物理矛盾需指明对象与恰好两个相反属性")
    if "平衡" in tc.get("intent", "") or "折中" in tc.get("intent", ""):
        problems.append("表述含折中预期：违反 SIM 立场，请重述")
    return problems or ["通过：结构完整，可进入工具箱"]

tc_dust = {
    "improve": "有害因素的数量（细颗粒穿透）",
    "worsen": "能量消耗（压降）",
    "intent": "消除细颗粒穿透且不增加压降",
}
pc_dust = {
    "object": "滤材层",
    "properties": ["致密（工作态）", "疏松（清灰态）"],
}
print(check_contradictions(tc_dust, pc_dust))   # ['通过：结构完整，可进入工具箱']

tc_bad = {"improve": "速度", "worsen": "速度", "intent": "找平衡"}
print(check_contradictions(tc_bad, {}))
# ['技术矛盾缺改善方或恶化方'... '改善与恶化是同一参数：这已是物理矛盾，别走矩阵路线',
#  '物理矛盾需指明对象与恰好两个相反属性', '表述含折中预期：违反 SIM 立场，请重述']
​

第二条输出示范了最常见的建模事故：把同一个参数的两难当成技术矛盾送去查矩阵。矩阵对此无解——因为这不是 A 与 B 的跷跷板，而是同一个量的自相矛盾，它属于分离原理的辖区。

图 2-3 矛盾建模路线与工具分流

容易漏掉的第三种矛盾：管理矛盾

在组织场景里还存在第三类：管理矛盾——两个部门的合法目标互相冲突（采购要降本 vs 质量要加严）。SIM 对它的处理是下钻转译：追问这两个目标落到产品上各对应哪个工程参数，把它转成技术矛盾再求解。直接在管理层面"协调"，等于在最抽象的层面找折中，恰恰违反 SIM 立场。第 5 章组织推广时会用到这个转译技巧。

矛盾建构的进阶要点

多轮下钻。 一个技术矛盾可以下钻出多个物理矛盾候选，逐个检验哪个"更物理"。检验标准：属性冲突是否可以用自然语言对第三者说清楚而无需数据表。"致密 vs 疏松"说得清楚，是好物理矛盾；"模量 5 兆帕 vs 50 兆帕"是数据，不是属性冲突的表述。

反向矛盾也要记。 "降低压降导致精度恶化"与原表述方向相反，在矩阵里查询位置不同，推荐原理可能不同。建模时双向各记一条，求解时两边都查。

矛盾不是越多越好。 一个项目同时维护的矛盾记录建议不超过三条，其余先挂起。工具箱是深度优先的，广度撒网会稀释团队精力。

⚠️ 常见坑：为了让矩阵"能查"，强行把定性诉求（美观、手感）映射到 39 参数。参数表覆盖的是物理工程量，定性诉求应走功能导向搜索（3.6 节）而不是矛盾矩阵。

本节要点回顾

• 两次翻译：抱怨 → 技术矛盾 → 物理矛盾，翻译质量决定求解质量；
• 39 参数是通用货币，允许一对多映射，双向各查一轮矩阵；
• 同参数两难不是技术矛盾，质检脚本专门拦这条事故；
• 管理矛盾靠下钻转译成工程矛盾求解，不做管理层面折中；
• 一个项目并行维护的矛盾不超过三条，深度优先。

方向（IFR）与矛盾都已就位，2.3 节把 IFR 从一句口号扩写成有格式的导航文档。