简介：这份PPT课件面向产品设计、工程创新与TRIZ初学者，系统讲解发明问题解决理论中的功能分析与系统裁剪方法，帮助读者把用户需求抽象为功能、识别有用功能与有害功能，并据此寻找结构优化和降本增效的切入点。压缩包仅含1个PPTX文件，约7.9MB，内容以章节化幻灯片组织，便于按主题浏览和课堂演示。已有955人学习，说明其在创新方法入门与工程案例分析中具有一定参考价值。课件从功能分析概述展开，覆盖功能定义、功能分类、功能整理、功能系统分析方法、基于组件的功能评估与系统裁剪，并结合技术系统、组件、超系统和目标等概念，给出功能定义原则、本质表达、图形化表达及功能模型思路，适合用于产品规划、原理设计、问题诊断和流程优化等场景的自主学习与教学引用。

1. 功能分析在TRIZ体系中的坐标：先看地图再拆模块

很多人学创新 TRIZ 时，第一反应是去背四十条发明原理或者矛盾矩阵，结果翻到功能分析这一章就卡住——概念一堆，动词表一长串，裁剪规则看起来像拼积木。其实把地图摊开就三件事：功能怎么定义、功能怎么分类整理、系统怎么剪裁。功能分析干的就是把产品从“实物”翻译成“功能语言”，先抽象描述，再分类整理，最后系统化建模，落到剪裁时才有依据。整份内容围绕功能定义、功能分类、功能整理、功能系统分析方法、基于组件的功能评估、系统裁剪六个模块展开。适合正在系统学 TRIZ 的人对照检查逻辑链，也适合备考复习时快速拉一遍主线——遇到“这个动词算不算功能”这种纠结，直接查第二、三章就有答案。

2. 功能定义：四原则与本质表达法

功能定义是整个功能分析的入口。这一步写歪了，后面分类整理和裁剪全部跟着歪，所以值得花最多时间打磨。TRIZ 对功能的定义很克制：某组件（功能载体）改变或保持另一组件（功能对象）某个参数的行为或作用。一句话里有三个要素——载体、动作、对象，缺一个就不完整。

2.1 功能=动词+对象：为什么必须是“V+O”结构

功能描述要求用动宾词组，功能=工作+对象，也就是动词加名词的结构。比如“电线传输电流”，“传输”是动作，“电流”是对象；“灯泡提供光源”，“提供”是动作，“光源”是对象。

这个约束不是文字游戏。用V+O描述之后，组件本身的名字被剥离了，剩下纯功能，后续才可能讨论“这个功能能不能换一种载体来实现”。如果写成“电线的功能是导电”，表面看没错，但“导电”是功能执行的结果，不是功能本身——结果描述会把实现方式焊死在原组件上，后面想做裁剪就没有腾挪空间。这也是很多人看功能分析觉得“像在玩文字”的原因：真正做过一遍整理的人会发现，定义写对了，后面识别冗余和有害功能的难度直接降一半。

梳理下来会发现一条暗线：功能定义做得越抽象，后续系统裁剪的选择面越宽。抽象度不够，裁掉某个组件后功能就无路可走。

2.2 本质表达与直觉表达：最容易栽的一步

功能定义最大的陷阱是把“功能执行的结果”当成功能。这里有一组对照表，是复习时最值得背的内容：

直觉表达描述的是结果，本质表达描述的是组件对对象参数做了什么。两者在含义上不是“哪个更高级”的区别，而是功能分析能不能继续往下走的分水岭——结果描述没法参与分类，也没法判断有用还是有害。

提示：判断是否写成了直觉表达，可以反问一句“这个功能发生之后，对象的哪个参数变了”。答不出参数，大概率还是结果描述。

2.3 四条红线：否定动词、对象限定与抽象度

功能定义的原则里，有四条最容易在实操中被违反：

1. 必须用动宾词组，功能=工作+对象。一个功能受体至少要有一个参数受到影响并发生改变。
2. 禁止用“不”替代否定动词。不能说“陶瓷不能传导电流”，要说“陶瓷阻碍电流”；不能说“河堤缺口不能阻止河水”，要说“河堤缺口引导河水”。用否定词会把功能定义变成对功能的否定，等于没定义。
3. 功能对象必须是组件，不能是组件的参数。并且要针对特定条件下的具体技术系统来陈述，不能泛泛而谈。
4. 尽量用抽象词语表达，避免专业术语。专业术语自带实现路径，抽象词才能留出替换空间。

第 3 条在实际整理中最容易漏。比如写“散热器降低CPU温度”，这里的“CPU”是组件，没问题；但如果写成“散热器降低CPU温度值”，对象就变成了参数，功能定义就失焦了。参数只能出现在描述功能作用结果的句子里，不能拿来当功能对象名词。

2.4 功能动词速查：先查表再定稿

本质表达法依赖一套常用功能动词。与其硬想，不如先翻动词表找到最接近的动词，再微调：

吸收 分解 加热 阻止 聚集 沉淀 支撑 加工 装配 破坏 告知 保护 弯曲 检测 连接 移除 拆解 干燥 定位 旋转 相变 嵌插 混合 分离 清洁 浸蚀 移动 振动 凝结 蒸发 定向 固定 冷却 析取 擦亮 传递 腐蚀 煮沸 防护 ……

这张表真正的作用是当“功能定义卡壳时的词典”：比如某装置把热量从A组件传到B组件，动词候选有“传递”“移动”“导向”，选哪个取决于你想强调作用方向还是作用方式，选完后再检查对象是否准确、是否混进了直觉描述。动词的颗粒度直接决定后续功能分类的颗粒度，这一步偷懒，后面整理时必然返工。

3. 功能分类与功能整理：有用有害、三维体系与功能模型

功能定义写完之后，不能堆在那里，必须分类整理。分类解决的是“这个功能值不值得留”，整理解决的是“这些功能之间是什么关系”。两块合在一起，才能把一堆功能条目变成一张功能模型。

3.1 有用功能与有害功能：分类的第一刀

按功能发挥的具体作用来分，功能分为有用功能和有害功能：

分类的意义在裁剪阶段才会显现：有用功能要保留并优化，有害功能是裁剪的第一批候选目标。但要注意，有害功能不一定来自坏组件——同一个组件可能同时产生有用功能和有害功能（比如某加热组件同时提升了相邻组件的温度），分类时要分开记录，不能合并成一条。

注意：功能分类没有绝对的“对错”，只有颗粒度差异。如果分类之后发现某个功能既像有用又像有害，那说明功能定义那句话本身写得不够具体，需要回头修正第2章的定义句。

3.2 功能分类的三种维度：作用、等级与性能水平

除了有用/有害这一刀，功能还可以从三个维度继续切：

• 功能作用分类：按作用性质归类，区分主要功能和辅助功能，帮助识别系统存在的理由。
• 功能等级分类：按功能在系统中的地位划分，哪些是基本功能，哪些是附加功能。
• 性能水平分类：按功能完成的质量划分，判断冗余和欠缺。

三个维度的关系类似“先分性质，再分层次，最后分好坏”，顺序不能乱。先做作用分类，再做等级分类，最后用性能水平标注——如果一上来就评判性能，很容易把辅助功能误标为多余功能，裁剪时就会误伤。梳理下来会发现，很多“系统太复杂”的问题，根子不在组件多，而在三种分类维度没有拉开层次，全挤在一个平面里判断。

3.3 功能整理：组件层次分析、相互作用分析与功能模型

功能整理是把分类后的功能条目串成关系图，主要做三件事：

1. 组件层次分析：明确系统、超系统、目标三层的边界。技术系统由相互联系的组件和组件间相互作用组成；组件是组成技术系统或超系统的一部分、由物质或场组成的物体；超系统是将已经分析过的技术系统作为组件的系统，或不属于系统本身但与系统及其组件有一定相关性的系统；目标是技术系统的作用对象。
2. 相互作用分析：判断哪两个组件之间存在功能关系，以及方向。
3. 功能等级分析与性能水平分析：标注每个功能在系统中的层级和完成质量。

三件事做完，就可以建立功能模型了。功能模型不是流程图，而是把组件和功能分离开来考虑：每个功能条目画成“载体→动作→对象”的箭头关系，组件框只出现一次，功能箭头从载体指向对象。这和传统的那种“组件A连着组件B”的框图不同——框图表达的是结构连接，功能模型表达的是功能作用，两者在裁剪时起的作用完全不同。最容易混淆的就是把结构连接当成功能作用，看到一个组件连着两个组件就认为它有两项功能。

3.4 功能等级与性能水平：把“多余”提前标出来

等级分析和性能分析常常被当成“锦上添花”的步骤跳过，其实它们是裁剪前最有价值的一层过滤器。功能等级回答“这个功能在系统里排第几层”，性能水平回答“它达到预期没有”。

整理技巧可以这样操作：先给每个功能条目打两个标签——等级标签（基本/辅助）和性能标签（达标/不足/过剩）。打完之后，性能过剩且等级为辅助的功能条目，就是系统裁剪里最安全的删除对象。反过来说，如果某个功能等级是基本但性能不足，那不是裁剪问题，是优化问题，方向完全不同。很多人裁剪后系统功能断裂，根因就在这里——把性能不足的基本功能当成多余功能裁掉了。

4. 功能系统分析与系统裁剪：从模型到创新

功能系统分析是“把模型建对”，系统裁剪是“把模型剪好”。前者是后者的输入，后者是前者的出口。这一章把两个模块串起来讲，因为实际操作中它们本来就是一条链。

4.1 组建功能系统的起点：组件层次与边界判定

系统分析的起点是画边界。技术系统、超系统、目标三层必须分清：

• 技术系统：相互联系的组件和相互作用组成的整体，以实现某种功能。
• 组件：组成技术系统或超系统的一部分，由物质或场组成的物体。
• 超系统：把已分析的技术系统作为组件的更大系统，或与系统及其组件有一定相关性的系统。
• 目标：技术系统的作用对象。

边界判定的常见错误是把超系统组件强行拉进系统内。比如某消费电子产品的散热模块，使用者手持的姿势属于超系统，如果把“手持”当成系统组件来处理，功能分析会多出一大堆和系统无关的功能条目。正确的做法是：只把参与功能作用的组件拉进模型，超系统只作为外部约束条件记录，不画进功能箭头里。

4.2 相互作用分析与功能模型图：箭头里藏着功能类别

建立功能模型时，用矩形框表示组件、箭头表示功能，箭头从功能载体指向功能对象。功能模型的三个要点：

1. 组件与功能分离，分别考虑。我们要的不是组件A，而是组件A提供的功能。
2. 箭头必须标注动作（动词），不能只画一条光杆线。
3. 按前面建立的分类体系标注功能性质（有用/有害）。

功能模型图的价值在于，它能把“组件之间的结构关系”转化成“功能作用关系”，从而暴露出那些结构上看起来正常、功能上却有问题的位置。比如某小型加热装置的承载结构，结构图上看两个组件紧密相连，功能模型里却出现一条“振动”→传热组件的箭头——结构上没毛病，功能上是一条有害作用。这种发现只能靠功能模型，靠结构图看不出来。

4.3 系统裁剪的六种基本策略

系统裁剪不是“拆零件”，而是“剪功能”——把某个组件承担的功能转移到其他组件上，或者直接删除功能。归纳起来有六种策略：

六种策略没有固定优先级，但有一个通用检查顺序：先判断功能性质，再判断功能对象，最后判断功能载体。顺序错了，就会出现“一刀剪下去系统性能反而变差”的翻车现场。

4.4 裁剪后的功能再分配与组件评估

裁剪的动作是删除组件，裁剪的本质是功能再分配。剪裁掉一个组件之后，它原本承担的有用功能必须由其他组件继承，否则系统功能链断裂。所以每次裁剪后要立即做两件事：

1. 检查被裁组件承担的所有功能条目，标注每条功能的去向（被谁承接或彻底消亡）。
2. 对承接组件做基于组件的功能评估，判断它的性能余量是否足以承担新增功能。

这个评估步骤容易被省略，但它是裁剪后是否要二次裁剪的决策依据。某图像处理Demo的制冷模块裁剪后，把散热功能转移到了壳体上，但壳体的热传导参数没有重新评估，结果系统能跑但温升超标——功能模型上那条箭头画出来了，参数没跟上，等于模型和实物脱节。系统裁剪的完整闭环是“裁剪—再分配—再评估”，少一步都算没做完。

5. 易错点：功能分析里最容易翻车的五处

功能分析的概念不多，但概念之间的边界很细，实际操作时错的位置非常集中。梳理下来，反复踩的坑就这五个。

5.1 易错点一：把结果当功能

易漏点：直觉表达和本质表达的区分。为什么漏：日常语言习惯就是用结果描述功能，“吹干头发”“照亮房间”说出来毫无违和感，很容易直接写进功能定义。怎么补：每写完一条功能定义，强制追问“对象的哪个参数变了”，答不出来就重写。电吹风机的功能不是吹干头发，是蒸发水分；电风扇的功能不是凉爽身体，是移动空气。

5.2 易错点二：拿参数当功能对象

易漏点：功能对象必须是组件，不能是参数。为什么漏：参数和组件在中文表达里经常连在一起，比如“降低温度”和“降低水温”看起来结构一样，但前者对象是参数，后者对象是组件加水（不严谨但方向对）。怎么补：写完功能定义后，把对象名词单独拎出来问“它是一个物理组件吗”。不是组件就改，改为对组件的作用，参数变化放到动作描述里体现。

5.3 易错点三：用否定词敷衍

易漏点：禁止用“不”替代否定动词。为什么漏：否定句在日常表达里太顺口，“不能传导”“不能阻止”写起来毫不费力。怎么补：把“不能+动词”的结构反向替换成“阻碍/引导/隔离”等肯定式动词。陶瓷的功能定义是“阻碍电流”，不是“不能传导电流”；河堤缺口的功能定义是“引导河水”，不是“不能阻止河水”。这一步不只是文字替换，用否定词会让功能分类失去依据——一个“不能做什么”的条目既不能归入有用也不能归入有害。

5.4 易错点四：裁剪时把基本功能误删

易漏点：裁剪对象应该是性能过剩的辅助功能，不是性能不足的基本功能。为什么漏：裁剪时注意力集中在“组件数量少了多少”，忽略了功能等级标签。怎么补：裁剪前先确认功能等级和性能标签，只对“辅助+性能过剩”的功能条目做删除或替换，对“基本+性能不足”的条目改走优化路线。裁剪清单上每个被删除的组件后面必须追一条功能去向，去向为空且功能等级为基本的，直接打回重审。

5.5 易错点五：混淆系统边界与超系统

易漏点：超系统组件不能当系统组件画进功能模型。为什么漏：超系统和系统在结构上有关联，画图时顺手就画进去了。怎么补：建模前先把组件清单分成“系统内”和“超系统”两列，功能箭头只在系统内组件之间画。超系统只作为约束条件记录在备注里，比如使用环境、外部接口条件，不参与功能链。系统边界一旦画错，后面的组件层次分析和裁剪都会跟着错。

6. 查漏补缺：一份可运行的复习清单

复习功能分析不需要重读全部材料，按下面这张清单过一遍就能定位知识漏洞。逐项打勾，打不上的对应回第几章找答案。

这张表最实用的地方是第 4 行和第 7 行。功能分类漏标三维维度，当时看不出问题，裁剪时才发现找不到筛选依据；裁剪去向不记录，系统跑起来功能断了才发现。这两处反复踩过，血泪经验就一条：功能分析的每一步都要留下可回查的记录，不能只凭脑子记。

复习时还有一个更省力的做法——把功能动词表和本质表达对照表打印出来贴在桌边，每写一条功能定义就扫一眼，看动词在不在表里、对象是不是组件。这个习惯看起来笨，但用了之后定义返工率明显下降。从那以后我每次做功能分析都强制先过一遍对照表再看模型图，宁可定义阶段慢一点，也不让错误往后传。希望这份清单帮到你，复习时少走几步弯路。

本文还有配套的精品资源，点击获取