企业官网建设流程全解析

简介：这份PPT课件面向创新方法学习者、产品设计人员与工程技术人员，围绕TRIZ“发明问题解决理论”中的系统功能分析与剪裁展开，帮助读者从功能视角理解技术系统、识别问题并寻找优化机会。内容覆盖功能分析概述、功能定义、功能分类与整理、功能系统分析方法、基于组件的功能评估以及系统裁剪，并结合动宾式功能描述、功能模型图形化表达、有用/有害功能判别等知识点，形成较完整的分析路径。压缩包仅含1个pptx文件，约7.9MB，便于集中学习与课堂演示。目前已有955人学习，适合用于创新方法入门、课程备课或工程问题分析参考，可据此梳理功能分解、组件关系与裁剪思路，提升方案改进的系统性。

1. 从"录音笔的功能是什么"说起：TRIZ 功能分析与剪裁在解决什么问题

如果有人问你，一支录音笔的功能是什么，多数人会说"录音"。再追问一句：它改变了什么东西的什么参数？答案就开始含糊了。TRIZ（发明问题解决理论）里的功能分析与剪裁，处理的正是这种含糊——它不先问"这个零件该怎么改"，而是先问"这个系统到底在替谁改变什么"。TRIZ 认为创新有规律可循，而功能分析就是那条规律的起点：把产品从物理形态里抽出来，只看它对外界做了什么。剪裁则更进一步，在看清功能之后，决定哪些组件可以拿掉、哪些功能可以转移。搞懂这一套，你看产品的方式会从"一堆零件"变成"一组作用"，改方案时也就不容易在原地打转。

2. 为什么先拆功能再动结构：功能分析到底在替工程师省什么

2.1 顾客掏钱买的不是零件，是功能

价值工程的实践者很早提出过一个判断：顾客买的不是产品本身，而是产品带来的功能。这句话听起来像口号，落到工程上却非常具体。一个人买录音笔，不是为了拥有外壳、电路板和麦克风，而是为了让"声音被保存下来"这件事发生。外壳、电路板、麦克风只是这件事的实现形式。

一旦接受这个视角，问题的提法就变了。原来问"这个外壳能不能换成更便宜的材料"，现在问"保存声音这件事，需要谁来承担、需不需要这么多组件来承担"。前一个问题只能在现有结构里打转，后一个问题才有机会把结构改掉。

这也是功能分析最容易被低估的价值：它把讨论从"零件好不好"拉到"功能有没有被更好地实现"。工程师之间吵架，常常是因为一个人盯着零件，另一个人盯着效果，双方说的根本不是一层的事。功能分析提供了一个共同的描述语言，让争论回到同一张桌子上。

2.2 功能是结构的抽象，结构是功能的具体

系统科学里有一组说法，值得抄在本子上：功能是结构的抽象，结构是功能的具体；功能是系统存在的理由，是系统的外在表现；结构是功能的载体，是系统的客观存在。

这三句话翻成大白话：你看到一个系统，看到的是结构；你使用一个系统，用的是功能。结构回答"它由什么组成"，功能回答"它为什么值得存在"。两者不是一回事，但也不是毫无关系——结构是功能赖以实现的东西，功能是结构存在的理由。

举个日常的例子。同一件事"把水烧开"，可以用电热丝通电发热，可以用燃气燃烧加热，也可以在高海拔地区靠降低气压让水在低温沸腾。三种结构的差别大到几乎不像同类产品，但功能描述是同一句：让水的温度升高到沸点。这句话不依赖任何一种结构，所以它能横跨三种方案。

功能分析干的活，就是生产这种"横跨方案"的描述。描述一旦成立，方案的空间就被打开了：原来只能比较两种电热结构，现在可以把燃气、气压这些完全不同的路子拉进来比。

2.3 开发新系统和改进老系统，是两条不同的路

功能分析在两个场景下的用法并不一样，混着用容易白忙。

开发一个新技术系统时，顺序是先确定系统要完成的主要功能，再把主要功能分解成子功能。比如要做一台能"把潮湿衣物变干"的设备，主要功能定下来，接着拆：需要让空气流动、需要加热空气、需要容纳衣物、需要排出湿气。拆到这一步，每个子功能再去找实现方式，方案才长出来。这时候功能分析是"从零搭骨架"。

改进一个已有技术系统时，顺序反过来：先理清系统当前的主要功能和辅助功能，把每个功能对应到具体组件上，再看哪些功能过剩、哪些功能缺失、哪些功能由好几个组件重复承担。这时候功能分析是"给现有系统做体检"。

两条路的共同点是都得先把功能说清楚，区别在于前者从功能往外找结构，后者从结构往里找功能。用错了方向，要么在还没定功能的时候就开始画零件图，要么在已有系统上重复发明一遍轮子。

2.4 它在设计流程里的位置，比很多人以为的更靠前

产品设计通常被切成几段：产品规划、产品原理设计、技术设计、施工设计。从产品规划到产品原理设计，是整条链上最关键的一跃——这一跃决定产品用什么原理去实现需求，后面的技术设计和施工设计基本是在填细节。

功能分析就卡在这一跃上。它上承产品规划给出的需求，下接原理设计要选的技术方案。需求是用户语言，比如"我想要录音更清楚"；原理是工程语言，比如"用指向性麦克风加降噪电路"。中间那一层翻译，就是功能：让特定方向的声音被更强地接收、让环境噪声被削弱。

少了这一层翻译，需求会直接砸到零件上，结果就是"用户说要清楚，那就换个更贵的麦克风"。这种反应不算错，但它跳过了"清楚"这件事还能怎么被拆解、怎么被别的原理实现。血泪经验通常都出在这一步：方案做完了才发现，需求本来可以用便宜得多的路子满足。

提示：功能分析不是画一张好看的图，它的产出是"可以拿来比方案的描述"。如果做完之后你手里的方案数量没变，那这一步大概率只是走了个形式。

3. 功能定义怎么写才算合格：动宾词组背后的五条硬规矩

3.1 通用句式：谁改变了谁的什么参数

TRIZ 对"组件的功能"给了一个很克制的定义：某组件（子系统、功能载体）改变或保持另一组件（子系统、功能对象）的某个参数的行为或作用。

拆开看是三个角色：功能载体、功能对象、被改变或保持的参数。图形化的写法是一句话——X 更改（或保持）Z 的参数 Y。X 是干活的那个，Z 是被作用那个，Y 是具体变化的东西。

这里有个容易被跳过的词："保持"。很多人下意识认为功能一定要带来变化，其实维持某个参数不变也是功能。保温杯的功能不是让水温升高，而是让水温不下降；支架的功能不是移动设备，而是让设备的位置保持不变。把"保持"漏掉，保温、固定、密封这一类功能就没法被描述，系统里一大块组件会显得"没干活"。

参数这个角色最容易被忽略，却也最能检验定义写得认不认真。"传输电流"光看动宾结构合格，但被改变的参数是什么？是电子的位置分布。"提供光源"呢？是光线的强度。参数说不出来，说明你还没想清楚这个功能到底在改变世界的哪一项。

3.2 直觉表达与本质表达：为什么"吹干头发"不算功能

初学者写功能，写出来的往往是结果，不是功能。TRIZ 把前者叫直觉表达，后者叫本质表达。原文给出的对照很能说明问题：

直觉表达的问题在于，它把功能和场景、和结果绑在了一起。"吹干头发"这句话里藏着头发、藏着人的感受，一旦对象换成"烘干受潮的零件"，同一个功能就被描述成了另一件事，方案之间的可比性就断了。

本质表达则只保留作用本身：蒸发水分。至于水分在头发上还是在零件上，不影响这句话成立。正因为不绑定场景，它才能把"加热蒸发""吹风带走""吸附转移"这些完全不同的实现方式放在一起比较。

打个比方，直觉表达像在说"这道菜让人吃了开心"，本质表达像在说"这道菜的咸度提高了"。前者是评价，后者是可操作的描述。做工程需要后者。

3.3 五条原则逐条拆：否定动词、组件参数、抽象词

原文给了功能定义的五条原则，每一条背后都对应一种常见的翻车方式。

第一条，用动宾词组描述，功能等于工作加对象。电线的功能写成"传输电流"，动词是传输，对象是电流。这条看着简单，但它强制你把"谁来干"和"干什么"分开，为后面把功能和组件剥离做准备。

第二条，功能受体至少要有一个参数受到影响、发生改变。这条是筛子：说不清哪个参数变了，这句话就不是功能描述，而是愿望。比如"提升用户体验"——哪个参数变了？说不出来，就不是功能。

第三条，禁止用"不"替代否定动词。不能说"陶瓷不能传导电流"，要说"陶瓷阻碍电流"；不能说"河堤缺口不能阻止河水"，要说"河堤缺口引导河水"。原因很实在：带"不"的描述只说明了某件事没发生，没说明实际发生了什么，后续没法分析、没法评估、也没法改进。改成肯定动词之后，"阻碍"和"引导"都成了可以被评价好坏的功能——阻碍电流对绝缘是好事，引导河水对防洪是坏事，判断才有落点。

第四条，功能对象必须是组件，不能是组件参数，而且要针对特定条件下的具体技术系统陈述。这条最常被违反。写"降低温度"的时候，温度是参数不是组件，正确的对象应该是"让某个部件降温"或者"让腔体内的空气降温"。对象搞错，功能模型画出来就是一串悬空的箭头，找不到落点。

第五条，尽量用抽象词语表达，避免专业术语。术语会偷偷把方案带进来。"用蜗轮蜗杆机构减速"里，"蜗轮蜗杆"已经是一个具体结构，它把别的减速方式排除在外了；换成"降低转速"，方案空间立刻打开。抽象不是含糊，抽象是为了在方案还没定的时候不提前锁死。

3.4 一张常用功能动词表，为什么值得背

原文列了一串本质表达常用的功能动词：吸收、分解、加热、阻止、聚集、沉淀、支撑、加工、装配、破坏、告知、保护、弯曲、检测、连接、移除、拆解、干燥、定位、旋转、相变、嵌插、混合、分离、清洁、浸蚀、移动、振动、凝结、蒸发、定向、固定、冷却、析取、擦亮、传递、腐蚀、煮沸、防护。

这串词的价值不在于背，而在于它是一份"描述词汇的收敛集"。当你写功能写成"优化""提升""处理""实现"的时候，说明还没想清楚；翻一遍这张表，通常能找到一个更准确的动词。写不出来往往不是词汇贫乏，是理解没到位。

图形化表达也是同一个道理。用矩形框表示组件，用箭头表示动作，箭头上写动词，就成了"X 对 Z 的作用"。它的妙处在于把组件和功能拆开看：我们不需要组件 A 本身，我们需要的是 A 提供的那个作用。这句话是剪裁的全部思想基础。

4. 有用功能与有害功能：分类不是贴标签，是决定先砍谁

4.1 按作用分：改"善"参数与恶化参数

功能分类的第一刀，是按发挥的具体作用切。有用功能指功能载体对功能对象的作用，按照期望的方向改变功能对象的参数，特点是改"善"参数；有害功能则是不按期望方向改变参数，特点是不仅没改善，甚至恶化参数。

这一刀看似简单，实际很狠，因为它逼你回答"期望方向是什么"。同样是加热，在一台烹饪设备里是改善参数，在一台精密仪器旁边就是恶化参数。所以有用和有害没有绝对标准，必须先定系统边界和期望。

还有一类常被漏掉的情况：一个组件同时产生有用功能和有害功能。比如电机驱动扇叶是驱动功能，同时产生振动和噪声，就是有害功能。分类的意义不是把组件判成好人坏人，而是让你看清"这个组件的收益和代价分别是什么"，从而判断能不能把收益留下、把代价去掉。

4.2 功能等级与性能水平：基本、辅助，以及不足与过度

除了按作用分，原文还提到按功能等级分类和按性能水平分类。按通俗的讲法，功能等级关注的是"这个功能在系统里有多要紧"：基本功能是系统存在的理由，缺了它系统就不是这个东西；辅助功能是让基本功能得以实现或更好实现的支撑，缺了它系统还能运转，但会变差或者不成立。

举例来说，一台录音设备的基本功能是记录声音，辅助功能可能是防抖、降噪、指示状态、保护内部元件。把辅助功能误当成基本功能，会导致在降本时不敢动；把基本功能误当成辅助功能，则可能一刀砍掉核心组件，这就是典型的翻车。

性能水平关注的则是"这个功能做得够不够"。通常分三档：不足、正常、过度。不足意味着功能没达到期望，需要加强；过度意味着功能超出需要、成本或副作用偏高。很多降本机会就藏在"过度"里——某个零件被设计得远超实际需要，仅仅因为当年就是这么设计的。同样的思路也适用于"不足"：某些看似无解的问题，其实只是某个功能长期欠着。

4.3 功能整理的四个动作，把散乱描述收成一张网

功能定义是逐个写的，写完之后是一地散件。功能整理要做的，是把这些散件组织起来。原文列出的动作包括组件层次分析、相互作用分析、功能等级分析和性能水平分析，最后建立功能模型。

组件层次分析解决"系统里有哪些层级"：目标系统、子系统、组件，以及把系统本身当成组件的超系统。层次不清，同一件东西会在不同位置重复出现两次。

相互作用分析解决"谁和谁真的在发生作用"：两个组件装在一起不等于有功能关系，必须有一方改变了另一方的参数才算。这一条能砍掉大量"图上连着线但实际没作用"的伪关系。

功能等级分析和性能水平分析解决"哪些关系要紧、哪些做得过头"，也就是上一节讲的内容。四步走完，功能模型才有信息量。

4.4 功能模型长什么样：用一段数据结构说清楚

功能模型不需要复杂工具，一张表就够了。下面这段用 Python 字典描述一条功能记录，字段对应前面讲过的分类维度：

# 一条功能记录：尽量只存描述，不存具体结构方案 function_record = { "carrier": "电机", # 功能载体：执行动作的组件 "action": "驱动", # 功能动词，用本质表达，避免专业术语 "target": "扇叶", # 功能对象：必须是组件，不能填参数 "parameter": "转速", # 被改变或保持的参数，缺失则这条记录不成立 "kind": "useful", # useful 有用功能 / harmful 有害功能 "level": "basic", # basic 基本功能 / auxiliary 辅助功能 "performance": "normal", # insufficient 不足 / normal 正常 / excessive 过度 }

参数说明与取舍逻辑：target和parameter分开存，是为了逼自己区分"组件"和"组件参数"——对象填成"温度"，这条记录就是错的；kind用来标记收益与代价，方便后面判断哪些关系值得保留；level决定降本时的优先级，基本功能相关组件不能随手删；performance是降本和优化的入口，取值过度的地方优先动刀。

当几十条这样的记录堆在一起，再用箭头把载体和对象连起来，就是一张功能模型图。图的读法很直接：箭头密集的组件是枢纽，只有出箭头没有入箭头的组件往往可以商量，既有有用功能又有有害功能输出的组件是重点改造对象。

5. 常见误区与易混概念：功能、结构、组件、超系统别搅成一锅

5.1 误区一：把"功能"当成"产品"或"结果"

易混点：说"这个产品的功能是录音"，或者"这个产品的功能是让用户满意"。

为什么会混：日常语言里，"功能"和"用途""卖点""效果"几乎是同一个词，谁也不会在日常对话里区分它们。加上产品说明书也常这么写，久而久之就默认了。

怎么区分：功能描述的必须是一个组件改变另一个组件的某个参数。产品是组件的集合，是结构层面的事；用户满意是结果层面的评价，不是功能。把"录音"往下压一层，压到"让磁介质或存储芯片上的电信号按声音波形改变"，这才是功能描述。压不下去，说明还没看懂这个系统。

5.2 误区二：把组件参数当成功能对象

易混点：写"降低温度""提高强度""减少噪声"。

为什么会混：参数变化最直观，工程师脑子里最先浮现的往往就是那个数字。而且这些句子读起来通顺，形式上也是动宾结构，很容易被放过。

怎么区分：问一句"谁的温度""谁的强度"。功能对象必须是组件——某块板、某个腔体、某段空气。参数是对象身上的属性，不能反过来当对象。对象缺位，功能模型里的箭头就无处落点，后面的组件评估也就无从谈起。这类错误在评审里出现频率极高，逐条对照"X 对 Z 的 Y"这个句式筛一遍，能筛掉大半。

5.3 误区三：把有害功能当成"没用的功能"

易混点：看到某个组件只产生振动、发热、噪声，就认定它是废件，可以删。

为什么会混："有害"和"无用"在中文里语感接近，都带着负面色彩。加上降本的压力，很容易把"有害"直接等同于"该删"。

怎么区分：有害功能是"不按期望方向改变参数"，它描述的是一种作用，不是组件的全部身份。同一个组件很可能一边输出有害功能，一边承担着必不可少的有用功能。正确做法是先把这个组件的所有功能列全，再看有害功能能不能被削弱或转移，而不是直接删组件。删完之后发现基本功能断了，这就是最典型的后悔药场景。

5.4 误区四：把剪裁理解成"删零件省钱"

易混点：认为系统裁剪就是砍组件、压成本，砍得越多越成功。

为什么会混：剪裁这个词本身带着"做减法"的暗示，而降本又是最常见的动机，两者一叠加，剪裁就被简化成了删。

怎么区分：剪裁的对象是组件，但保留的对象是功能。删掉一个组件之后，它原来的有用功能必须有着落——要么转移给系统里其他组件，要么交给超系统，要么让这个功能变得不再需要。三种处理方式都没有，就是砍功能，不是剪裁。判断标准也很简单：剪裁之后功能模型里的有用功能是不是还在。少了，就说明砍错了。

5.5 误区五：超系统与"外部环境"混为一谈

易混点：把系统外面的一切都叫超系统。

为什么会混："超"这个字自带"更大更外"的语感，而外部环境也确实在系统外面，两者边界在直觉上重合。

怎么区分：超系统是把已经分析过的技术系统作为组件的系统，或者不属于系统本身、但与系统及其组件有一定相关性的系统。关键词是"相关性"和"能被当成组件"。道路对汽车是超系统的一部分，因为路面直接参与实现"支撑与摩擦"这些功能；而几千公里外的天气，虽然也在系统外面，却谈不上相关性。划超系统的目的不是画大圈，而是找出那些能承接功能的角色——剪裁时把功能转移给超系统，靠的就是这一步。

6. 什么时候该做功能分析与剪裁，什么时候先别碰

这套方法不是万能钥匙，它的成本在于时间：把系统拆成组件、逐条写功能、画模型、做评估，一套走完少则半天多则几周。所以判断"该不该做"比"怎么做"更影响收益。

我自己的判断习惯是看两件事：一是我能不能一口气说清这个系统的主要功能是什么；二是我现在手里的方案是不是都长得差不多。第一条说不清，说明认知还没到位，做分析正好补课；第二条成立，说明方案空间被现有结构锁死了，也该做。反过来，如果需求还在改、边界还没定，硬做只会得到一张没人愿意看的图。

还有一个更细的边界：剪裁适合在功能模型已经稳定之后做，不适合和分析混在一起做。一边分析一边删组件，很容易把还没评估清楚的功能关系一起删掉，最后说不清到底是哪个改动起了作用。分开走，先看清楚，再动手，出问题时才查得回去。

从那以后我每次接到降本任务，都会先逼自己把功能模型画完再碰方案，哪怕只画半张，也比直接对着零件清单砍要踏实。希望帮到你。

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