简介这份PPT围绕TRIZ发明创新理论中的系统功能分析与剪裁展开面向产品设计、工程创新学习者以及需要做系统问题诊断的技术人员帮助其从功能视角拆解技术系统、识别有害与不足功能并据此寻找简化结构、降低成本的改进方向。压缩包内仅1个pptx文件约7.9MB页面以理论要点配合图示案例组织便于课堂讲解或自学翻阅。内容依次覆盖功能分析概述、功能定义、功能分类、功能整理、功能系统分析方法、基于组件的功能评估与系统裁剪七大板块具体讲到动宾词组与本质表达的功能描述原则、有用功能与有害功能的判别、组件层次与相互作用分析、功能模型的箭头矩形框画法以及替换、合并、删除组件的裁剪思路。已有955人学习适合作为创新方法课程配套材料或工程实践中的分析模板。1. 从顾客买的不是电钻而是墙上的洞说起装修时买一把电钻你要的其实不是那把电钻而是墙上那个能挂相框的洞。这个说法流传很广但它点破的正是功能分析的全部起点人真正付费的从来不是零件而是零件干出来的那件事。在创新 TRIZ 这套方法体系里功能分析干的就是把这条朴素直觉变成一张能画、能查、能改的图——先把系统拆成组件再把组件之间的作用一条条写清楚最后才轮到判断哪条作用该留、哪条该删。听起来像常识可真正动手写第一条功能定义时多数人第一句话就失败了。写出来的是电钻打孔外壳保护看着都对却既不能比较也不能改进。下面把这个概念一层层拆开。2. 功能为什么是产品的本质组件、超系统与目标的关系2.1 结构是功能的具体功能是结构的抽象一个保温杯拆开来看是不锈钢内胆、真空夹层、旋盖、密封圈、外壳。这是结构看得见摸得着可以称重、可以测厚度。但一个人掏钱买它买的是六小时后拧开还能喝到一口热水。这是功能看不见摸不着只能通过参数的保持或改变来间接确认。系统科学里有一组常被引用的说法功能是结构的抽象结构是功能的具体功能是系统存在的理由是系统的外在表现结构是系统功能的载体是系统的客观存在。这三句话说得比较学术换成大白话就是——结构回答它由什么做成功能回答它凭什么值得被做出来。同一件事可以有很多种结构保温可以靠真空层也可以靠厚泡沫、靠相变材料、靠双层抽气玻璃。结构是可替换的功能才是那个不能被替换的东西。这个区分不是文字游戏它直接决定了你能不能改。盯住结构的人改进方式只有一种把现有零件做得更好一点。盯住功能的人改进空间是整个方案空间。工程史上一再出现的外行解决了内行难题多半就是有人绕开了结构直接冲着功能去。这里还要说清一个顺序问题。产品的设计过程一般分成产品规划、产品原理设计、技术设计、施工设计四段从规划走到原理设计是其中最关键的一步——原理一旦定下后面基本是在填细节。而功能分析恰好卡在这一步上它把用户要什么翻译成系统该实现哪些作用再交给原理设计去挑实现方式。要是这一步糊弄过去后面画再多图纸也只是在错误的路上跑得更快。2.2 技术系统、组件、超系统、目标四个词划出分析边界功能分析不是对着一堆零件随便写句子它先要圈定一个分析范围这就涉及四个基本概念。技术系统指由相互联系的组件和组件之间的相互作用组成、以实现某种功能的对象。一台台灯就是技术系统灯罩、灯泡、支架、开关、电源线彼此有连接、有作用合起来实现照明。组件指组成技术系统或超系统的一个部分由物质或者场组成的一个物体。灯泡、开关、导线都是组件。超系统指把已经分析过的技术系统当作组件的那种系统或者不属于系统本身但与系统及其组件有一定相关性的系统。台灯放在书桌上书桌就是它的超系统书桌所在的房间照明环境也是超系统的一部分。目标指技术系统的作用对象。注意目标不是使用者这么笼统的东西而是被作用、被改变的那个具体对象——桌面上的书本、房间里的空气、人的眼睛。这四个词的作用是划定边界而边界划在哪里结论会完全不同。同一个灯泡放在台灯系统里它是组件是执行功能的载体放在灯丝寿命分析里灯泡自己变成了技术系统灯丝、玻壳、填充气体才是组件。所以做功能分析前必须先声明我这次分析的是哪一层否则后面所有讨论都会产生分歧——一个人说的是灯泡另一个人说的是台灯谈一天也谈不拢。实际工作里最容易出问题的是超系统。很多人分析到系统边界就停手结果漏掉了两个大方向一是系统对外部的作用台灯把热量散到房间里这是对超系统的影响二是外部对系统的作用房间温度、电压波动、灰尘都会反过来影响台灯。这两类关系不写进来后面做裁剪时就会误判——你以为是系统内部某个零件多余其实是超系统已经在替它承担功能。2.3 为什么先有功能分析才谈得上创新功能分析的应用场景分两种两条路的走法并不一样。开发一个全新的技术系统时做法是先确定系统要完成的主要功能再把这个主要功能往下分解成子功能。比如要做一个样品前处理的模拟项目主要功能是分离目标成分往下拆就是输送样品施加离心力截留固体排出液体——拆到这一步每个子功能都可以单独去找实现方式而不是一上来就画一个反应釜的草图。改进一个已有技术系统时做法反过来先理清这个系统的主要功能和辅助功能各是什么把系统读懂再找出问题所在。这里的关键词是读懂。设备出毛病的时候直觉反应是找到坏掉的那个零件换掉但功能分析会先问一句这个零件在这个系统里承担的是哪条功能这条功能是主要的还是辅助的如果一条辅助功能失效导致整机停摆那说明的不是零件质量问题而是系统的功能结构有缺陷——把关键功能挂在了一条脆弱的链条上。跳过这一步直接改结构就是在没有地图的情况下修路。某实验室做过一个样品前处理的模拟项目最初三个月一直在换材料、换转速、换滤芯规格参数调了几十轮效果时好时坏谁都说不清为什么。后来老老实实把功能模型画出来才发现真正的瓶颈不在滤芯而在于输送样品这条功能由一个特别不稳定的组件承担它的波动被下游放大成了看起来毫无规律的故障。方向一改问题两周就收敛了。这种玄学调参的教训做过硬件的人大概都有切身体会。3. 功能定义与功能分类一条动宾公式和它背后的原则3.1 通用描述法X 更改或保持 Z 的参数 YTRIZ 对功能的定义相当克制功能是指某组件子系统、功能载体改变或保持另一组件子系统、功能对象的某个参数的行为或作用。把这个定义写成公式就是一句话X 更改或保持Z 的参数 Y其中 X 是功能载体Z 是功能对象Y 是功能对象被改变或保持的那个参数。三个位置都必须能填进具体的东西这条功能才算立住。举两个例子。灯泡的功能不是照明两个字就完了完整说法是灯泡X改变动作环境空气与物体表面Z的亮度Y。录音笔的功能是录音笔X改变动作声波Z的记录状态Y。再看一个更朴素的电线的功能是传输电流拆开看是电线X改变动作电子Z的位置Y。这个公式的价值在于它强制你补全三样东西。只写传输电流你说不清传输的是什么、被影响的是什么补上电子位置改变你才能判断这个功能实现得好不好、有没有替代方式。很多人做功能分析做到一半卡住就是因为写下来的全是支撑连接固定这类含糊动词动词后面没有对象对象后面没有参数三样都缺句子看着通顺实际上什么也没说。动宾词组描述是基本要求功能 工作 对象VO。电线的功能 传输电流这是动词加对象。但真正合格的写法还要再往下追一层参数因为传输和传输得好不好中间隔着一整个参数体系。3.2 本质表达与直觉表达电吹风到底是吹干头发还是蒸发水分功能定义里最容易出问题的一步是把结果写成了功能。原文把这两种写法区分得很清楚一种叫直觉表达描述的不是功能而是功能执行的结果另一种叫本质表达是 TRIZ 采用的方式。看几个对照技术系统直觉表达结果本质表达功能电吹风吹干头发蒸发水分电风扇凉爽身体移动空气放大镜放大目标物改变光线白炽灯照亮房间发光挡风玻璃保护司机防止车外物体撞击二极管整流电流阻滞某极性电流这张表值得多看两眼。左边一列的共同毛病是它们都混进了为什么和给谁用而这两样东西不该出现在功能定义里。吹干头发这个词里藏着使用场景头发、藏着结果干、甚至藏着一种方案假设用热风吹。一旦写死成吹干头发后面能想到的改进方向只剩下加热功率和风量。右边一列就松开了。说蒸发水分那么凡是能让水离开头发的办法都进入候选池加热、吹风、吸水材料、离心甩动、甚至超声雾化。功能定义越抽象方案空间越大功能定义越具体你就越容易被自己锁死。不过抽象也有边界。原则里明确写了尽量用抽象的词语表达避免使用专业术语这句话不能理解成越抽象越好。抽象到处理物质传递能量这种程度虽然绝对正确但没有任何指导意义。合适的粒度是抽象到能容纳多种实现方式具体到能判断成功与否。蒸发水分就在这个位置上——它不限死用什么手段但明确了考核对象是水的含量。原文还列了一批常用功能动词直接拿来用可以少走很多弯路吸收、分解、加热、阻止、聚集、沉淀、支撑、加工、装配、破坏、告知、保护、弯曲、检测、连接、移除、拆解、干燥、定位、旋转、相变、嵌插、混合、分离、清洁、浸蚀、移动、振动、凝结、蒸发、定向、固定、冷却、析取、擦亮、传递、腐蚀、煮沸、防护。这份清单的用法不是背下来而是写定义时对照一下如果自己写的动词不在这类词的范围内那多半是写成了结果或者写成了某家公司内部的工序名。3.3 五条原则把模糊的句子逼成可检验的条目功能定义有五条明确的原则每一条都对应一种高频错误。第一条用动宾词组描述功能 工作 对象。这条看似简单实际能筛掉大量XXX 机构XXX 装置式的名词化写法——名词写的是零件不是作用。第二条功能受体至少要有一个参数受到影响、发生改变。原文举的例子很到位传输电流意味着电子位置的改变。如果一条功能写出来你找不到任何一个参数发生变化那这条功能是空的。注意保持也算改变的一种特殊形式密封圈的功能是保持而不是改变内外压差参数没有变化恰恰就是它的作用。第三条禁止使用不替代否定动词。不能说陶瓷不能传导电流要说陶瓷阻碍电流不能说河堤缺口不能阻止河水要说河堤缺口引导河水。这条原则最容易被当成文字洁癖其实它有硬道理否定式描述不指向任何具体行为你没法针对不能传导去设计方案但可以针对阻碍去想办法——换材料、加厚度、改结构方向立刻出来了。第四条功能对象必须是组件不能是组件的参数而且要针对特定条件下的具体技术系统做陈述。这条是很多人失败的地方。写提高温度是不合格的因为温度是参数不是组件合格的写法是加热器改变样品的温度。同理改善外观不如涂层改变表面的粗糙度。第五条尽量用抽象的词语表达避免专业术语。原因前面已经说过术语里往往烧死了方案。这五条合起来其实构成了一个可以自动检查的规则集。写一版数据结构把每条功能拆成字段很多错误机器就能替你抓出来# 一条功能记录的最小字段集载体、动词、对象、参数、方向 func { carrier: 电吹风, # 功能载体 X谁在起作用 action: 蒸发, # 功能动词必须是可执行的动作 target: 水分, # 功能对象 Z必须是组件不能是参数 param: 液态占比, # 被改变的参数 Y direction: 降低, # 期望方向升高 / 降低 / 保持 } def check(f): issues [] # 原则三动词里出现否定词说明写成了不能……式表达 if any(w in f[action] for w in (不, 非, 无)): issues.append(动词含否定词请换成反义动词) # 原则四对象和参数重名说明把参数当成了对象 if f[target] f[param]: issues.append(对象与参数重复功能对象必须是组件) # 原则一/五动词过长往往写成了结果或内部术语 if len(f[action]) 4: issues.append(动词过长检查是否写成了结果描述) return issues or [通过] print(check(func)) # 输出[通过]这段脚本只做形式检查抓的是否定词、对象参数混淆、动词冗长这三类最表层的错误判断不了语义对不对——蒸发水分到底是不是这个系统真正干的事还得人来定。参数 direction 用三个枚举值而不用自由文本是为了逼着写的人明确参数往哪个方向变才算功能实现这一步含糊后面评估有用还是有害就没有依据。拿它去跑一遍团队写的功能清单通常会有一半条目被标红而且被标红的往往是那些谁都说不出所以然的条目。3.4 有用与有害功能分类的第一刀功能定义清楚之后紧接着要分类。最基础的一刀是按发挥的具体作用来分。有用功能指功能载体对功能对象的作用按照期望的方向改变功能对象的参数特点是改善参数。加热器升高样品温度、密封圈保持内外压差、支架维持灯罩高度都是有用功能。有害功能指功能载体对功能对象的作用不按照期望的方向改变参数特点是不改善甚至恶化参数。台灯点亮后灯罩发烫烤到旁边的手电机运转时的振动传到台面上让烧杯里的液面抖个不停——这些都是有害功能。这一刀的意义在于它把好和坏从评价变成了描述。日常讨论里说这个设计不好那是一句态度在功能模型里说灯罩对 nearby 物体施加了升温作用方向与期望相反那是一句可以拿去改的陈述。而且有害功能不一定是设计失误很多是主功能的必然副产物——只要灯亮就必然发热问题不在于能不能彻底消除而在于它作用到了谁身上、强度多大。按功能作用分类属于第一层往下还能按功能等级分、按性能水平分。这一层拆得越细后面做裁剪时越有依据因为这个功能值不值得留和这个功能实现得够不够好是两个完全不同的问题。4. 功能系统分析与系统裁剪把多余的组件请出去4.1 功能整理四件事把散落的句子组织起来写完几十条功能定义手上还只是一堆散句子。功能整理要做的是把它们组织成有结构的整体原文明列了四个动作。组件层次分析解决谁在谁里面。把系统按层拆下去直到拆到不再影响本次分析目标的粒度为止。拆得太粗问题藏在中层看不见拆得太细条目爆炸分析成本反而压垮收益。经验做法是拆到能独立采购或独立失效的那一层。相互作用分析解决谁碰到谁。这一层关注的是组件之间的接触、连接、传递关系很多时候问题的根源不在某个组件本身而在两个本该有作用、实际没作用或者作用方向反了的组件之间。功能等级分析解决哪条更要紧。把功能分成主要功能和辅助功能。主要功能是系统存在的理由辅助功能是让主要功能得以实现的条件。这个划分在改进已有系统时尤其重要因为它决定了资源往哪儿投。性能水平分析解决实现得够不够好。同一条功能有的系统实现得勉强及格有的实现得富余浪费。前者叫不足后者叫过度两种都不算健康——不足要补过度要削。四件事做完你会得到一张表每行一条功能每列是载体、对象、参数、方向、等级、水平。这张表就是后面所有判断的地基。4.2 功能模型把功能和组件分开看功能的图形化表达用的是箭头和矩形框矩形框代表组件名词箭头代表动作动词从功能载体指向功能对象箭头上标注具体动作。这套记法看着简陋但它实现了一件关键的事——把组件与其功能分离分别进行考虑。这个分离为什么重要打个比方你家里有一把螺丝刀你真正需要的不是这把螺丝刀而是拧动螺丝这个能力。如果眼睛始终盯着螺丝刀你的改进方向就只有把螺丝刀做得更好一旦把功能从工具上剥离出来看你会发现这个能力可以由电动工具给、可以由超系统里已有的设备给、甚至可以由结构设计的变化直接消灭掉——比如把螺丝改成卡扣这条功能就不需要了。功能模型就是把这种剥离画在纸上。画出来之后那些只有箭头没有来源的功能该做的事没人做、只有来源没有去向的功能做了但没作用到任何对象、以及箭头方向明显不对的功能有害功能会在图上一目了然。文字清单里它们能藏很久图上一眼就能看出来。画图时有个常见的技术性细节箭头的粗细和颜色通常用来标注功能等级和性能水平主要功能用粗线辅助功能用细线有害功能用特殊的线型。这套约定不是装饰它让你在扫一眼的时候就知道资源和风险集中在哪。4.3 系统裁剪删掉组件功能还得留住系统裁剪是整个方法里最反直觉的一步。它的目标不是删掉没用的零件而是——在保证功能仍然被实现的前提下去掉承担这条功能的组件。这话的区别很关键。删掉没用的零件是清理删掉有用的零件而功能还在是设计。裁剪的具体手法大致三类删除直接去掉组件让功能由系统内其他组件兼管、或由超系统提供、或干脆判定这条功能不必要合并把两个组件的功能压到一个组件上替换用另一种原理实现同一条功能原组件随之消失。判断一个组件能不能裁通常问四个问题。它承担的功能是必须的吗——如果这条功能本身就是有害的或者没人需要直接连功能带组件一起删。系统内还有别的组件能干这活吗——有的话就是兼管。超系统能提供吗——重力、大气压、环境温度、用户的手都是免费的功能提供方。可以用一种完全不同的原理实现吗——这是替换也是收益最大的一类。举个例子。某模拟项目里一台设备上装了一个专门的弹簧压紧机构作用是让两个零件保持贴合。按功能写出来是弹簧机构X保持动作零件 A 与零件 BZ的接触压力Y。裁剪时先问这条功能必须吗必须。系统内有人能兼管吗有——零件 B 本身是磁性的把零件 A 换成可磁吸材料吸力直接提供了接触压力弹簧机构整体消失。组件少了一组故障点少了一处成本也降了。这就是裁剪和减配的区别减配是功能没了省了钱裁剪是功能还在、成本降了。风险也很实在。裁剪掉一个组件等于把一条功能交给了别的承担者而这个承担者往往原本有它自己的职责。兼管之后它会不会顾此失彼、在极限工况下失效必须回头做一轮验证。裁剪方案里那些看起来最漂亮的往往就是在这种边界条件下失败的。4.4 开发新系统与改进旧系统走的是两条路把上面这些串起来看功能分析在两个场景下的用法是不同的。开发新技术系统时是从上往下的确定主要功能 → 分解为子功能 → 为每个子功能寻找实现原理 → 组合、评估、取舍。这条路的关键在分解的质量子功能拆得合理每个都能独立找到多种实现拆得不好某个子功能天然绑死了一种方案整条路就走窄了。改进已有技术系统时是从下往上的梳理组件 → 写功能定义 → 建立功能模型 → 找有害功能、不足功能、过度功能 → 用裁剪重构。这条路的关键在定义的准确性一条功能写歪了后面所有的判断都跟着歪。两条路最后都会汇到同一张图上一张干净的功能模型。区别只在于新系统是从空白的图开始画旧系统是从一张乱糟糟的图开始擦。5. 易混概念辨析功能、需求、参数、组件到底差在哪5.1 功能与需求一个在用户嘴里一个在系统里易混点把用户想要什么直接当成功能写进模型。为什么会混两者在自然语言里几乎同义我需要一个能装热水的杯子和杯子保持水温听起来说的是同一件事。加上需求文档通常写在项目最前面做功能分析时手边只有它顺手抄过来太自然了。怎么区分需求描述的是使用者的期望主语是人形式是我要……功能描述的是系统的行为主语是组件形式是X 改变 Z 的参数 Y。需求是功能的来源但不能直接当功能用中间必须过一次翻译。用户说我希望它安静点这是需求翻译成功能是隔音层降低传递到外部的声压这才进入模型。翻译这一步省略掉后果是整张功能模型的主语全是用户而用户不在系统里你没法裁剪他、没法替换他、也没法评估他的性能水平。5.2 功能与参数一个是动作一个是被动作改变的东西易混点把参数当成功能对象写出提高温度减小噪声增加强度这类条目。为什么会混参数太显眼了做工程的人习惯用参数说话指标、公差、阈值全是参数。而且参数是可测量的写出来心里踏实。怎么区分参数是功能作用的结果不是功能本身。功能问的是谁对谁做了什么参数问的是做完之后变成了多少。加热器升高样品温度是功能温度从 20℃ 升到 80℃是参数指标。两者的关系是一条功能定义里必然包含一个参数但参数不能单独构成一条功能。检查办法很直接——看句子里有没有一个具体的组件作为宾语没有就是写成了参数。5.3 功能与功能载体你需要的到底是能力还是那个零件易混点说这个系统的功能是电机或者这个零件的功能是它自己。为什么会混日常语言里经常用品名代替用途说装个空调其实意思是实现降温。在脑子里这两者是自动合并的写下来才发现根本不成句。怎么区分载体是执行者功能是被执行的行为。功能分析的整个价值就在于把这两者拆开——原文那句我们不需要组件 A我们需要组件 A 的功能说的就是这个。拆开之后你才有裁剪的空间既然要的是能力不是零件那么这个零件就可以被换掉、被合并、被超系统接管。拆不开的人做不了裁剪因为在他眼里删掉零件等于删掉功能那是不能接受的。5.4 功能分析与故障分析一个找结构缺陷一个找失效原因易混点设备出了问题直接拉一张功能图开始逐条排查把功能分析当故障树用。为什么会混两者的产出看起来很像都是一张带箭头的图都在追问这里为什么不对。而且功能模型确实能暴露问题容易让人误以为它是万能的。怎么区分故障分析从现象出发往原因追目标是定位那一个失效点方向是收敛的功能分析从结构出发往作用铺目标是看清整个系统的功能分布方向是发散的。功能分析能告诉你这个系统里有一条有害功能一直在恶化参数但说不清它今天为什么突然恶化。真要查一次具体的失效功能模型只能提供一张地图具体的路径还得靠失效分析、测试和拆检。把地图当诊断书用最后往往是把整机拆了也没找到原因。5.5 系统裁剪与减配降本省下的到底是不是浪费易混点把裁剪理解成砍零件省钱方案评审时用成本下降幅度来衡量裁剪做得好不好。为什么会混裁剪的产出里确实包含零件变少了成本降低了这两件事在报表上是一回事在工程上完全不是。怎么区分看功能还在不在。裁剪的定义性条件是功能仍然被实现承担方式变了、组件消失了但功能一条没少甚至因为少了传递环节而实现得更好。减配是功能被删掉或降级成本下降是代价换来的。分辨办法很简单把裁剪前后的功能模型并排放功能条目应当基本对齐如果某条主要功能在新模型里找不到对应那不是裁剪成功是需求被偷偷砍掉了。这条判断标准在评审会上特别有用因为成本数字永远比功能列表更容易说服人。6. 什么时候该做功能分析什么时候别做这套方法并不万能用了不合适的地方投入的工时换不回相应的判断力。适合用的场景通常有三个特征系统已经复杂到没人能完整说清它在干什么问题反复出现但每次都换个地方冒头或者改进方向很多、彼此冲突需要一个共同的判断标准。这三种情况下功能分析提供的是一张共用的地图让讨论从我觉得变成图上这条作用是谁对谁做的。不适合的场景也很明确场景是否适合原因单一零件的材料替换不适合功能没变结构也没变直接做材料试验更快系统刚立项、需求还没定不适合没有稳定的功能对象写出来的定义全是猜的多方案取舍、方向打架适合功能模型提供了统一的比较基准老设备反复出问题适合能暴露隐藏的有害功能和脆弱的辅助功能链纯软件的业务逻辑梳理谨慎组件边界模糊功能对象常常是人而不是对象成本压力下的重构适合裁剪能区分删功能和换实现还有一个现实约束值得说清楚功能分析的成本主要在写定义那一步几十条功能一条条拆载体、对象、参数非常枯燥而且第一版几乎必然写歪。指望一次成型的人多半会在第三天放弃。可行的做法是先粗后细先按主要功能拉一条主干跑通一遍裁剪思路再回来补细节——很多细节补到最后会发现根本不需要。我一个改不掉的习惯是任何一次裁剪方案上会之前强制把裁剪前后的功能模型并排打印出来逐条对功能条目。有一回砍掉了一个紧固件图上功能对得整整齐齐评审过得很顺装机后第三周开始出现间歇性异响——那条接触压力被另一个组件兼管了但那个组件在低温下会轻微收缩兼管能力刚好掉到临界点以下。图纸上看不出来的东西功能模型也没义务替你看出来它只保证你没漏掉该问的问题。从那以后我每次做裁剪都强制在边界工况下再走一遍功能核对也算是一点血泪经验。真正难的不是画图是愿意承认图上那条作用自己从来没想过。功能分析最大的作用大概就是把这种没想过变成写在纸上、赖不掉。希望帮到你。本文还有配套的精品资源点击获取