TRIZ功能分析与系统裁剪：从功能定义到组件评估的实战方法

简介面向产品设计、研发工程与创新方法学习者系统梳理TRIZ中功能分析与系统裁剪的核心方法帮助读者把用户需求转化为可分析的功能语言并识别系统中多余或有害功能。压缩包仅含1个pptx文件约7.9MB结构紧凑适合课程学习、企业内训或项目工作坊直接使用。内容按功能分析概述、功能定义、功能分类、功能整理、功能系统分析方法、基于组件的功能评估、系统裁剪七个模块展开重点讲清动宾词组定义功能、功能图形化表达、有用与有害功能区分、组件层次与相互作用分析、功能模型建立及裁剪优化思路。已有955人学习可作为理解TRIZ功能分析和改进技术系统的入门到进阶参考。1. 一份 2014 年的 TRIZ 课件值不值得翻从“顾客买的不是产品是功能”说起翻到一份 2014 年 12 月的 TRIZ 课件封面写着系统功能分析与裁剪很多人的第一反应是年份太老。但功能分析这套东西并不依赖版本更新——创新 TRIZ 里从功能定义、功能模型、组件评估一路走到系统裁剪的那条链十年过去判断标准没变变的只是你手上那台产品。它解决的是一类很具体的僵局评审会上有人说“这个结构多余”有人说“这个件不能删”谁也说服不了谁。这份材料把争论拉回可枚举的层面每个组件承担什么功能、功能作用在谁身上、参数往哪边走、删掉之后功能由谁接。它更适合两类人。一类是做产品改进、方案评审、专利点挖掘的工程师手里有一个已经跑起来但毛病不少的系统需要一套能照着填的表把问题摊开另一类是刚接触功能分析、看完概念仍然不知道第一条该写什么的人。整套材料的骨架是功能定义、功能分类、功能整理、功能系统分析、基于组件的功能评估、系统裁剪六段前后咬合跳着看容易断。2. 功能定义从“吹干头发”到“蒸发水分”五条硬约束怎么落功能定义看起来是最没技术含量的一步实际是整条链里返工率最高的一步。一份功能清单如果在定义阶段就把实现方式写进去了后面画功能模型时组件和功能会粘在一起裁剪阶段根本不敢动任何一个零件——因为你一删功能就跟着没了。这套材料在这一章花了很大篇幅讲“本质表达”讲的就是怎么把功能从具体结构里剥出来。2.1 直觉表达与本质表达的分界线材料里给了一组对照很值得抄在笔记本第一页技术系统直觉表达本质表达电吹风机吹干头发蒸发水分电风扇凉爽身体移动空气放大镜放大目标物改变光线白炽灯照亮房间发光挡风玻璃保护司机防止车外物体撞击二极管整流电流阻滞某极性电流左边一列读起来都通顺问题在于每一条都把方案写死了。“吹干头发”里藏着“吹”这个动作等于默认了必须有一个吹风的组件“照亮房间”里藏着“照”等于默认了必须有一个发光体朝着房间。右边一列只留下参数变化水分蒸发、空气移动、光线改变。功能一旦抽象到这个程度组件才有被替换、被合并、被删除的空间。这里有个容易被误读的点。本质表达不等于越抽象越好抽象到“处理信号”“传递能量”就失去了分析价值因为没法判断参数往哪个方向变。合格的粒度是能指出一个具体对象能指出对象身上的一个具体参数能判断这个参数是变好还是变坏。水分是对象蒸发是变化两者都在就够了。我一般会要求团队在写第一条功能时强制回答三个问句作用在哪个组件上、这个组件的哪个参数变了、变成什么样。三个问题答不全说明这条功能还没想清楚先别往表里填。2.2 五条硬约束逐条拆对象必须是组件、禁用否定动词材料列了五条功能定义原则逐条落地时会碰到不同的问题。第一条用动宾词组描述功能等于工作加对象。这条最基础但动词的选择有讲究。材料里附了一张常用功能动词表吸收、分解、加热、阻止、聚集、沉淀、支撑、装配、破坏、告知、保护、弯曲、检测、连接、移除、拆解、干燥、定位、旋转、相变、嵌插、混合、分离、清洁、移动、振动、凝结、蒸发、定向、固定、冷却、析取、擦亮、传递、腐蚀、煮沸、防护……用表里的动词功能描述会自然收敛一旦写出“优化”“提升”“改善”这类词基本可以判定这条功能废了因为它没有指向任何物理动作后面也没法判断参数方向。第二条功能受体至少要有一个参数受到影响并发生改变。材料的例子是“传输电流意味着电子位置的改变”。这条约束的作用是把玄学挡在门外说不清哪个参数变了这条功能就是拍脑袋写的。常见的参数有位置、速度、温度、压力、流量、电流、电压、频率、亮度、颜色、形状、体积、浓度、湿度、硬度、粗糙度、信息量。填表时建议单列一栏专门写参数名空着的一律退回重写。第三条禁止用“不”替代否定动词。“陶瓷不能传导电流”要写成“陶瓷阻碍电流”“河堤缺口不能阻止河水”要写成“河堤缺口引导河水”。这条看着像文字游戏实际影响后面的分类带“不”的句子把动作和方向混在一起你没法判断它是有用功能还是有害功能。“防止漏油”到底是好事还是坏事取决于你在讨论密封圈还是讨论故障件。改成“阻滞油”之后方向就清楚了。第四条功能对象必须是组件不能是组件参数并且要针对特定条件下的具体技术系统陈述。“提高温度”不合格因为温度是参数不是组件“加热水”合格水是组件。这条在画功能模型时惩罚最狠箭头必须从一个组件指向另一个组件对象写成参数箭头就无处可落。第五条尽量用抽象的词语表达避免专业术语。这条和第四条看起来矛盾其实分工不同对象要具体到组件动词要抽象到不绑定实现。写“扇叶搅动气流”就把方案写进去了写“移动空气”才是功能。提示五条约束里第一、第四条的返工成本最高。清单写到几十条再回头改对象等于整张功能模型重画。建议前十条功能逐条过审定型后再批量铺开。2.3 功能卡片字段设计与填写示例把五条约束固化成一张表比背原则有效。我一般用下面这套字段字段名直接对应约束填的时候哪一栏空着一眼就能看出来字段填写要求常见错误编号F01 起顺序编后期增删不重排按组件编号导致一改结构全乱载体执行动作的组件名写成“系统”“结构”这类虚指动作动词表里的词优化、提升、保证对象被作用的组件名写成参数如“温度”受影响参数单个参数名一次写三四个参数参数方向改善 / 恶化 / 不变写“有影响”功能等级基本 / 辅助 / 附加全部标成基本性能水平不足 / 正常 / 过度全填正常类型有用 / 有害按主观印象填拿一个虚构的照明 Demo 填六条能看清字段之间的关系编号载体动作对象参数方向等级性能类型F01灯珠发出光线亮度改善基本正常有用F02驱动电源转换电能电压改善基本正常有用F03散热片传导热量温度改善辅助不足有用F04外壳阻挡灰尘洁净度改善辅助正常有用F05灯珠加热外壳温度恶化附加过度有害F06外壳传递振动振幅恶化附加过度有害F05 和 F06 是这份清单的价值所在。大多数团队填到 F04 就停了剩下的全是“有用功能”画出来的模型干干净净裁剪时无从下手。有害功能不是瑕疵是裁剪的入口——后面第五章会反复用到这两条。填写顺序建议是先按组件逐个列一个组件写完后立刻回头检查对象是不是组件全部列完再做一次动词归一把“散热”“降温”“冷却”统一成一个词最后统一补参数方向和性能水平。三步分开做比一边想一边填快得多。3. 功能模型组件-箭头-组件的画法与层次、相互作用、等级三步分析文本清单再完整也看不出系统结构。功能模型的作用是把清单变成一张有向图让“谁作用于谁”变成肉眼可见的东西。这套材料在这一段的表达很克制只用矩形框和箭头两种图元不引入任何复杂记号好处是画完谁都能看懂坏处是没有现成的软件模板得手工画。3.1 图形化表达三要素载体、作用、对象规则只有三条矩形框代表组件箭头代表动作箭头从载体指向对象动词写在箭头上。功能等于动作加对象载体是箭头的起点对象是箭头的终点。材料里有一句话值得单独拎出来功能的图形化表达把组件与其功能分离分别进行考虑。我们不需要组件 A我们需要的是 A 的功能。这句话是整份课件的思想内核也是后面系统裁剪能成立的唯一理由。只要功能还绑在组件上删组件就等于删功能没人敢动功能一旦被画成独立的箭头箭头就可以改指向可以由别的组件接过去组件本身反而成了可替换项。画图时有几个实操约定能省掉后面大量扯皮。同一对组件之间可以有多条箭头每条对应一个不同参数比如灯珠到外壳既有“加热”也有“照射”别合并成一条。箭头方向严格按动作方向画不按物料流向画。动词写在箭头中段不要写在框里。组件框内只写组件名不写型号、不写数量。还有一条先画文本矩阵再画图。直接用画图工具起步十有八九会漏箭头。3.2 组件层次分析与相互作用分析的执行顺序材料把功能系统分析拆成组件层次分析、相互作用分析、功能等级分析、性能水平分析四步最后汇总成功能模型。顺序不能乱乱了就得返工。第一步定边界。写一句“本系统负责把电能转成可见光并维持可接受的结温”边界外的全部归超系统。层次划分按四层走层次定义照明 Demo 中的例子超系统把已分析系统作为组件的更大系统或与系统相关但不属于系统的部分环境空气、安装面、供电电网系统本次分析的对象整体灯具子系统系统内部的组件灯珠、驱动电源、散热片、外壳、灯罩目标系统作用的对象被照区域边界没定就列组件最典型的后果是把超系统组件当系统组件写进去裁剪时一刀砍掉结果发现那个件根本不在自己的设计权限内。第二步做相互作用矩阵。行是载体列是对象格子里填动作。这个矩阵的好处是强迫你遍历所有组合而不是凭印象画几条主要箭头。载体 \ 对象灯珠驱动电源散热片外壳灯罩被照区域灯珠——加热加热照射照射驱动电源供电—加热固定——散热片———传导——外壳支撑支撑固定—固定—灯罩———支撑—改变光线矩阵填完箭头数量基本就定了。空格多的行说明这个组件在系统里存在感低是裁剪候选整行几乎全空的组件先怀疑是不是超系统件混进来了。第三步把矩阵翻译成图。组件框按层次摆放超系统件放最外圈目标放最外侧箭头只画系统内的跨边界的用虚线单独标。图画完再回头数一遍箭头数量和矩阵非空格数对不上说明漏画了。3.3 功能等级与性能水平的量化标注功能等级分三级基本功能是系统存在的理由删掉系统就不成立辅助功能支撑基本功能附加功能是超出需求的额外作用。判别方法很土但有效——问一句“删掉这条功能系统还能完成它的主要任务吗”不能就是基本能但会变差是辅助完全不影响是附加。性能水平分三档不足、正常、过度。判断依据是参数实际值和需求区间的相对位置。散热片把结温压到 40 度而需求是 60 度以下这就是过度压不到 70 度就是不足。这两组标注在画图阶段看着像装饰到第四章打分时就是唯一的输入。实践中常见的毛病是全表标“基本 / 正常”等于没标。我通常要求基本功能不超过总功能数的三成超过三成说明边界定得太宽或者把辅助功能误判成了基本功能。注意性能水平要写实际测量值或估算区间不要写“良好”“较差”。没有数值就先空着标一个待测比填一个形容词有用。4. 功能分类与组件评估有用、有害、不足、过度怎么判分数怎么打功能清单和功能模型解决的是“有什么”分类和评估解决的是“哪条该留、哪个组件该动”。这一步做不实裁剪就会退化成拍脑袋砍零件砍完再补补完再砍。4.1 参数方向的判定改善、恶化、不变材料给的判定标准很干脆功能载体对功能对象的作用按照期望方向改变参数是有用功能不按期望方向改变甚至让参数恶化是有害功能。判定的锚点是“期望方向”不是“实际效果好坏”这一点经常被混淆。期望方向来自需求不来自现状。散热片把温度从 90 度压到 75 度功能是有用的只是性能不足如果它把温度压到 30 度导致启动困难功能仍然有用但性能过度。反过来灯珠加热外壳从照明需求看是恶化的属于有害功能但如果你在做的是某种加热装置同一条箭头就变成有用功能。同一张图需求变了分类跟着变所以需求句必须写在做分类之前。四类功能的处理方向不一样类型判定处理方向有用且正常参数按期望方向变落在需求区间内保留考虑降本有用但不足方向对幅度不够加强或换载体有用但过度方向对幅度超出需求削弱或降规格有害参数朝反方向变消除或转成有用“不足”和“过度”是两种最容易被漏掉的分类因为它们在文本清单里都写成“有用”。只有在性能水平那一栏填了具体值才看得出来。散热片不足要加面积过度要减面积处理方式完全相反混在一起就等于没分类。4.2 功能整理从散清单收敛成功能模型功能整理不是把清单排个版是删掉描述同一件事的重复项把散落的功能收敛成一张能用的模型。这套材料把功能整理和功能模型分开讲实际做的时候是交替进行的。收敛流程我一般按五步走。第一步去重同一个载体对同一个对象、同一个参数的多条记录合并成一条。第二步合并同参数不同载体作用于同一对象同一参数的功能放在一起看比如散热片和外壳都在给灯珠降温要判断是并联冗余还是重复设计。第三步标等级基本、辅助、附加一次标完不留空。第四步标性能能测的填数值不能测的填估算区间。第五步建模型按第三章的矩阵翻译成图。收敛过程中会出现一类典型冲突某条功能既像有用又像有害。灯珠加热外壳从结温角度看是有害的从冬季防结露角度看又是有用的。这种条目不要强行二选一拆成两条分别挂到不同需求下各自标方向和等级。拆开之后往往会发现其中一条的载体可以被裁掉另一条需要保留问题自然就解开了。整理完的功能模型应该满足三个条件每条箭头都有明确的对象和参数每个组件至少有一条入边或出边超系统件不出现在系统内部的箭头端点上。三条里有一条不满足回去补。4.3 基于组件的评估表五个维度给组件打分到这一步才开始给组件打分。材料里叫基于组件的功能评估落到底就是回答一个问题如果只能动一个组件动哪个收益最大、风险最小。我用的评分维度是五个承担的功能数量、有用功能占比、有害功能占比、性能偏离程度、可替代性。前四个从功能卡片直接数出来第五个靠判断——这个组件承担的功能能不能由系统内其他组件、超系统或者更廉价的资源接过去。1 到 5 分分越高越危险。组件功能数有用占比有害占比性能偏离可替代性结论灯珠30.670.3301核心不动驱动电源21.00002保留散热片21.00014重点改造外壳40.500.5014优先裁剪候选灯罩11.00005可合并外壳那一行是典型的裁剪候选承担四条功能一半是有害的可替代性还高。但它同时是结构件直接删会塌所以要走第五章的裁剪规则把功能拆开分别转移。功能卡片攒到几十条以后手工数容易出错。写个小脚本把 CSV 读进来算一遍比在 Excel 里拉透视表稳import csv from collections import defaultdict # 功能等级权重基本功能权重最高附加功能最轻 LEVEL_W {基本: 3, 辅助: 2, 附加: 1} # 性能偏离正常不计不足和过度都会推高改造需求 PERF_W {正常: 0, 不足: 1, 过度: 1} def load(path): with open(path, encodingutf-8-sig) as f: return list(csv.DictReader(f)) def score(rows): stat defaultdict(lambda: {n: 0, useful: 0, harm: 0, value: 0, perf: 0}) for r in rows: s stat[r[载体]] s[n] 1 if r[类型] 有用: s[useful] 1 s[value] LEVEL_W.get(r[等级], 1) # 按等级加权 else: s[harm] 1 s[value] - 2 # 有害功能直接扣分 s[perf] PERF_W.get(r[性能], 0) out [] for comp, s in stat.items(): keep s[value] # 保留价值越高越不该动 feas s[perf] 1.0 / s[n] # 裁剪可行性功能越少越好删 out.append((comp, s[n], s[useful], s[harm], round(keep, 2), round(feas, 2))) # 保留价值低、可行性高的排前面 return sorted(out, keylambda x: (x[4], -x[5])) if __name__ __main__: for row in score(load(function_cards.csv)): print(row)脚本逻辑很直白按载体聚合有用功能按等级加权累加有害功能每条扣两分得到保留价值性能偏离计数加上功能数的倒数得到裁剪可行性功能越少的组件越容易被整体删除所以 1/n 这一项在大功能数组件上会自然变小。排序键是保留价值升序、可行性降序输出的第一行就是最该动的组件。输入 CSV 的列名必须和功能卡片一致编号、载体、动作、对象、参数、类型、等级、性能。LEVEL_W和PERF_W两个字典是唯一需要按项目调的地方比如某类产品里辅助功能不可或缺就把辅助的权重从 2 提到 2.5。不想写代码的话用透视表按载体做计数和条件求和结果一样只是每次改数据要重拉一遍。5. 避坑与排查五条血泪记录每条都能让功能分析白做这一章不是理论是返工记录。功能分析这套方法本身不复杂翻车基本都翻在几个固定位置而且每种翻车在现场看起来都很像“正常推进”。5.1 五条踩坑记录第一条功能动词写成“提高”“优化”。现象是清单越写越长每条都通顺但画图时箭头不知道该画什么评审时也没人反驳——因为谁都不知道这条功能到底在说什么。原因在于动词没有指向物理动作参数自然落不了地。解决方式是强制从动词表里选词选不出来就说明这条功能还没想清楚先删掉等结构分析完再回填。我一般会在评审前做一次全文检索把“提高”“优化”“改善”“保证”“实现”全部标红逐条替换替换不了的直接移除。这一步能砍掉清单里两成的条目而且没人会觉得可惜。第二条功能对象写成参数。现象是“提高温度”“增加亮度”“降低噪声”这类条目大量出现画功能模型时箭头无处可指最后只能画成组件指向空气。原因是违反了对象必须是组件这条约束。解决方式是给每条功能补一个“对象”字段字段里必须是名词性组件写不出来就说明对象没识别出来。补字段的过程往往会暴露一个更深的问题有些功能其实没有明确对象是设计者的主观期望不是系统行为这类条目本来就该删。第三条用否定句描述功能。现象是清单里出现“防止漏油”“避免干涉”“不能变形”分类阶段卡住因为判断不了方向。原因是否定动词把动作和期望混在一句话里看不出载体到底做了什么。解决方式是把它翻译成肯定动作“防止漏油”改成“阻滞油”“避免干涉”改成“隔开两个运动件”“不能变形”改成“维持形状”。翻译完再判方向通常会发现原句里藏着的其实是有害功能比如“阻滞油”如果发生在不该密封的位置就是有害的。第四条系统边界没定就列组件。现象是清单里混进了供电电网、安装墙面、外部风道裁剪阶段一算发现最该删的三个件全都不在自己的设计权限内。原因是先列清单后定边界顺序反了。解决方式是在动手列组件之前先写一句系统职责一句话说不清的说明这次分析的范围太大拆成两个系统分别做。边界句写完后所有超系统件单独放一张表只标相互作用不进系统内部的箭头端点。这条规矩执行起来有点笨但能省掉后面整轮返工。第五条功能模型画完就锁进文件改结构时不回代。现象是方案改完、样机做出来发现某个关键功能没人执行或者多出一条谁都没预料到的有害功能。原因是功能模型被当成交付物而不是工作底稿。解决方式是把回代写进流程任何结构变更哪怕只换一个螺钉也要把功能模型重跑一遍逐条核对每条箭头的载体和对象是否还在。听着夸张实际跑一遍十分钟比样机返工便宜太多。5.2 十分钟自检清单分析做完、方案定稿之前照下表过一遍。每一项都是二选一不合格就回去改不要带着问题往下走。检查项合格标准不合格的典型表现系统边界一句话能说清系统职责职责句里出现两个以上并列目标组件清单每个组件都是物质或场不含参数清单里出现“温度”“压力”功能对象全部为组件名出现“提高亮度”这类动宾错位动词归一同一动作只用一种写法散热、降温、冷却混用否定句全文检索无“防止”“避免”“不能”分类阶段卡在方向判断功能等级基本功能占比不超过三成全表标基本性能水平有数值或估算区间全填“正常”有害功能至少识别出两条模型干净得不像真实系统超系统件不进系统内部箭头端点电网、墙面出现在图中央回代记录每次结构变更都有对应模型版本只有一份最终版模型第十项最容易被忽略也最值钱。功能模型的价值不在画完那一刻在于它能被反复重跑。一份从不更新的模型和一份没画过的模型区别只在于前者会让人误以为已经分析过了。6. 系统裁剪三种规则、一张打分表和裁剪后的回代验证裁剪是整条链的出口也是最容易做过头的一步。材料把裁剪放在最后讲顺序是对的功能没定义清楚、模型没画出来、组件没打过分裁剪就是 pure 拍脑袋。真正开始动刀时只需要守住三种规则。规则适用条件动作风险规则 A组件的有用功能能被系统内其他组件承担删除组件箭头改指向承接方性能不足规则 B组件只执行有害功能或有害功能远多于有用功能直接删除有害功能转化为其他形式规则 C组件功能可由超系统或更廉价资源承担替换不删除依赖外部条件规则 A 处理的是冗余件。第四章那张表里灯罩承担一条“改变光线”的功能可替代性 5 分系统里没有任何其他组件需要它支撑灯珠直接照射也能满足需求这就是典型的规则 A 对象——删掉灯罩把“改变光线”这条箭头改指向灯珠对被照区域前提是评估过配光是否还达标。规则 B 处理的是纯负担比如某个只为配重而存在的支架同时带来振动传递删掉它配重改由电池位置调整。规则 C 处理的是可以外包的功能散热片的部分散热能力由外壳表面承担属于这一类替换后要重新测结温。三种规则共用一张裁剪打分表字段只有四个组件、承担功能数、可替代性、裁剪风险。可替代性沿用第四章的 1 到 5 分裁剪风险按“删除后是否有功能无人承接”判高、中、低三档。分档规则是可替代性 4 分以上且裁剪风险低的进第一批可替代性 4 分以上但风险高的先做功能转移再做删除可替代性 3 分以下的本轮不动。动完刀必须回代三步缺一不可。第一步重画功能模型把删除的组件框去掉把改指向的箭头重新连好把新增的箭头补上。第二步逐条核对原模型里的每一条功能确认仍然有载体在执行或者确认这条功能已经不再需要——后者要有需求层面的依据不能靠“应该没事”。第三步列出裁剪引入的新有害功能这是最容易被跳过的一步。删掉散热片结温升高是新的有害功能删掉外壳灰尘进入是新的有害功能。这些新条目要重新走一遍分类和打分进入下一轮循环。我吃过一次亏一轮裁剪删掉三个件模型改完就交付了没人补新增有害功能那一栏。两个月后样机在小灰尘环境里出问题回头查模型发现“阻挡灰尘”那条箭头在删外壳的时候被一起删掉了谁都没注意。从那以后我每次裁剪收尾都强制走一遍三步回代尤其是第三步宁可多列五条假阳性也不留一条空档。这套流程笨但它能把“这个件到底能不能删”从会议室争论变成表上的一行结论。希望帮到你。本文还有配套的精品资源点击获取