2.1 技术系统与超系统

2.1 技术系统与超系统

本节摘要：技术系统是为交付功能而存在的物体集合，任何分析都必须先画清"系统—子系统—超系统"三层边界与贯穿其中的作用流。本节给出系统边界的画法、功能的三要素口径，以及"升降层级"这一 TRIZ 特色的解题腾挪手法的操作规则。

先立靶子：学完能干什么

阅读完本节，你应当能够：

1. 对一个产品画出三层结构图并标注作用流（物质、能量、信息）
2. 说明"系统由其功能定义，而非由其部件定义"这句话的操作含义
3. 执行矛盾升级与降载两种层级腾挪

一、从部件清单到功能定义

拆开一台电动螺丝刀，你会得到电机、减速箱、电池、外壳、开关。但如果问"这个系统是什么"，部件清单给不出答案——TRIZ 的口径是：系统是它的功能，部件只是功能的临时载体。电动螺丝刀的系统是"把电能转成受控扭矩施加于螺钉"这件事；外壳不存在，功能仍可由别的载体实现（第 6.4 节的剪裁正是利用这一点）。

这个口径不是文字游戏，它直接决定分析的边界画法。画边界要过三问：交付给谁（超系统中的作用对象）、核心功能是什么（一句话，动词+名词）、必需的输入输出流有哪些。以手持电动工具为例：

注意超系统一栏经常被画小。车间空气看似无关，实则是散热与声学介质；用户的手既是振动受害者（本章主线矛盾的一方），也是免费的传感与驱动资源。边界画小了，后面资源清点（2.4 节）直接缺货。

二、功能三要素：作用必须闭环

TRIZ 对"功能"采用最严格的主谓宾结构：载体（工具）对受体（对象）施加一个作用，改变或维持了受体的某个参数。三缺一就不算功能：没有受体的作用是空转，没有载体的作用是愿望，没有参数变化的作用是"存在但不干活"。功能分析（第 3.2 节展开成完整流程）就是把这棵主谓宾树画出来，再按作用的性质染色：有用（正常）、不足（有用但弱）、有害（不该有）、过剩（有用但过猛）。

染色结果往往是第一份"体检报告"。以打印机进纸机构为例：搓纸轮对纸"施加摩擦力送纸"是有用作用，但对纸"施加压力"在同一张表里是有害作用（卡纸、卷边）——同一对载体受体可以同时挂多条不同性质的作用，这正是矛盾的雏形。

三、层级腾挪：矛盾搬家

三层坐标的实操价值浓缩成两条手法。

升载（上交超系统）：矛盾在本层无解时，把它搬到更大的系统去化解。经典战例是降噪：单机降噪碰到"隔音材料增加重量与成本"的墙，把矛盾升到车间层——用主动噪声抵消（利用声波干涉，超系统级的物理效应）替代被动隔音，机器本身一件不减。再如自行车夜间可视问题，从"给车装灯"升到"路面照明+反光标识体系"，单车上很多约束自动消失。

降载（下放子系统）：系统级冲突下放到某个子系统去吸收。整机要薄，矛盾下放到电池（异形电芯贴合机身弧面）；整机要抗摔，矛盾下放到屏幕边缘微结构去导引冲击。操作要点是问一句："这个冲突能不能由某一个部件独自承担，而不拖累整机其他部分？"

# 层级腾挪决策小助手：按冲突涉及面与资源位置给出建议
def relocate(level_of_conflict, resources_outside_system, 
             conflict_covers_whole_product):
    if conflict_covers_whole_product and resources_outside_system:
        return "倾向升载：整机性冲突且超系统有现成资源"
    if not conflict_covers_whole_product:
        return "倾向降载：冲突未覆盖整机，找子系统吸收"
    return "先做功能分析再判：冲突载体不清晰"

print(relocate("系统级", True, True))   # 例：车间降噪
print(relocate("系统级", False, False)) # 例：手机做薄
​

输出：

倾向升载：整机性冲突且超系统有现成资源
先做功能分析再判：冲突载体不清晰
​

⚠️ 常见坑：把"系统边界"画成装配图边界（采购清单思维）。边界由功能与作用流决定：用户的手在超系统里，但它参与功能交付，分析与资源清点都必须包含它。

常见疑问

问：功能分析与系统边界画法，和系统工程里的需求分解有什么区别？ 需求分解自顶向下，从"整机要什么"拆到"零件承担什么"，隐含假设是现有架构合理；TRIZ 的功能分析自作用出发，从"谁对谁干了什么"重建网络，架构只是网络的一种快照——所以它能看见"白吃饭的部件"和"有害的作用"，这两样在需求分解的视角里天然不可见。问：三层之外还有第四层吗？ 有，工程上偶尔会谈"超超系统"（如产业链、基础设施），但 TRIZ 的操作粒度到超系统为止——再往上，资源与作用的分析会稀释成空谈，实践中把产业链问题建模成"多个超系统资源共享"更可操作。问：小团队画功能图要画到多细？ 经验法则是"画到矛盾所在地为止"：矛盾已清晰定位的那一层之下不必再拆，之上的每层都要在图上。这条法则能把建模工作量砍掉一半，也让图保持可读。

最后给一个判断边界的实用测试：把系统名换成它的功能句后，让不熟悉产品的人听——"这是一个把电能转成受控扭矩并施加于螺钉的系统"，听者如果追问"那螺钉为什么要受控"，说明功能句写到了根上；如果听者毫无疑问，说明写成了规格复述。功能句经得起外行追问，是系统定义到位的朴素标志，也是后续功能分析不跑偏的第一道保险。

本节要点回顾

• 要点一：系统由功能定义而非部件定义，这是剪裁等工具的理论前提。
• 要点二：功能=载体+作用+受体+参数变化，四要素缺一即非功能；同一对载体受体可并存多种性质的作用。
• 要点三：升载与降载是矛盾腾挪的两板斧，判据是冲突覆盖面与资源位置。
• 要点四：边界画小导致资源缺货，是新手功能分析最常见的返工原因。

定位完成，下一节正式给矛盾立法：39 参数的技术矛盾语法与"既要又要"的物理矛盾语法。