企业官网建设流程全解析

简介：这份PPT围绕TRIZ发明创新理论中的系统功能分析与剪裁展开，面向产品设计、工程创新学习者以及需要做系统问题诊断的技术人员，帮助其从功能视角拆解技术系统、识别有害与不足功能，并据此寻找简化结构、降低成本的改进方向。压缩包内仅1个pptx文件，约7.9MB，页面以理论要点配合图示案例组织，便于课堂讲解或自学翻阅。内容依次覆盖功能分析概述、功能定义、功能分类、功能整理、功能系统分析方法、基于组件的功能评估与系统裁剪七大板块，具体讲到动宾词组与本质表达的功能描述原则、有用功能与有害功能的判别、组件层次与相互作用分析、功能模型的箭头矩形框画法，以及替换、合并、删除组件的裁剪思路。已有955人学习，适合作为创新方法课程配套材料或工程实践中的分析模板。

1. 从"顾客买的不是电钻，而是墙上的洞"说起

装修时买一把电钻，你要的其实不是那把电钻，而是墙上那个能挂相框的洞。这个说法流传很广，但它点破的正是功能分析的全部起点：人真正付费的从来不是零件，而是零件干出来的那件事。在创新 TRIZ 这套方法体系里，功能分析干的就是把这条朴素直觉变成一张能画、能查、能改的图——先把系统拆成组件，再把组件之间的作用一条条写清楚，最后才轮到判断哪条作用该留、哪条该删。

听起来像常识，可真正动手写第一条功能定义时，多数人第一句话就失败了。写出来的是"电钻打孔""外壳保护"，看着都对，却既不能比较也不能改进。下面把这个概念一层层拆开。

2. 功能为什么是产品的本质：组件、超系统与目标的关系

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

一个保温杯，拆开来看是不锈钢内胆、真空夹层、旋盖、密封圈、外壳。这是结构，看得见摸得着，可以称重、可以测厚度。但一个人掏钱买它，买的是"六小时后拧开还能喝到一口热水"。这是功能，看不见摸不着，只能通过参数的保持或改变来间接确认。

系统科学里有一组常被引用的说法：功能是结构的抽象，结构是功能的具体；功能是系统存在的理由，是系统的外在表现；结构是系统功能的载体，是系统的客观存在。这三句话说得比较学术，换成大白话就是——结构回答"它由什么做成"，功能回答"它凭什么值得被做出来"。同一件事可以有很多种结构，保温可以靠真空层，也可以靠厚泡沫、靠相变材料、靠双层抽气玻璃。结构是可替换的，功能才是那个不能被替换的东西。

这个区分不是文字游戏，它直接决定了你能不能改。盯住结构的人，改进方式只有一种：把现有零件做得更好一点。盯住功能的人，改进空间是整个方案空间。工程史上一再出现的"外行解决了内行难题"，多半就是有人绕开了结构，直接冲着功能去。

这里还要说清一个顺序问题。产品的设计过程一般分成产品规划、产品原理设计、技术设计、施工设计四段，从规划走到原理设计是其中最关键的一步——原理一旦定下，后面基本是在填细节。而功能分析恰好卡在这一步上：它把"用户要什么"翻译成"系统该实现哪些作用"，再交给原理设计去挑实现方式。要是这一步糊弄过去，后面画再多图纸也只是在错误的路上跑得更快。

2.2 技术系统、组件、超系统、目标：四个词划出分析边界

功能分析不是对着一堆零件随便写句子，它先要圈定一个分析范围，这就涉及四个基本概念。

技术系统，指由相互联系的组件和组件之间的相互作用组成、以实现某种功能的对象。一台台灯就是技术系统：灯罩、灯泡、支架、开关、电源线，彼此有连接、有作用，合起来实现照明。

组件，指组成技术系统或超系统的一个部分，由物质或者场组成的一个物体。灯泡、开关、导线都是组件。

超系统，指把已经分析过的技术系统当作组件的那种系统，或者不属于系统本身但与系统及其组件有一定相关性的系统。台灯放在书桌上，书桌就是它的超系统；书桌所在的房间照明环境，也是超系统的一部分。

目标，指技术系统的作用对象。注意，目标不是"使用者"这么笼统的东西，而是被作用、被改变的那个具体对象——桌面上的书本、房间里的空气、人的眼睛。

这四个词的作用是划定边界，而边界划在哪里，结论会完全不同。同一个灯泡，放在"台灯系统"里它是组件，是执行功能的载体；放在"灯丝寿命分析"里，灯泡自己变成了技术系统，灯丝、玻壳、填充气体才是组件。所以做功能分析前必须先声明"我这次分析的是哪一层"，否则后面所有讨论都会产生分歧——一个人说的是灯泡，另一个人说的是台灯，谈一天也谈不拢。

实际工作里最容易出问题的是超系统。很多人分析到系统边界就停手，结果漏掉了两个大方向：一是系统对外部的作用（台灯把热量散到房间里，这是对超系统的影响），二是外部对系统的作用（房间温度、电压波动、灰尘，都会反过来影响台灯）。这两类关系不写进来，后面做裁剪时就会误判——你以为是系统内部某个零件多余，其实是超系统已经在替它承担功能。

2.3 为什么先有功能分析，才谈得上创新

功能分析的应用场景分两种，两条路的走法并不一样。

开发一个全新的技术系统时，做法是先确定系统要完成的主要功能，再把这个主要功能往下分解成子功能。比如要做一个样品前处理的模拟项目，主要功能是"分离目标成分"，往下拆就是"输送样品""施加离心力""截留固体""排出液体"——拆到这一步，每个子功能都可以单独去找实现方式，而不是一上来就画一个反应釜的草图。

改进一个已有技术系统时，做法反过来：先理清这个系统的主要功能和辅助功能各是什么，把系统读懂，再找出问题所在。这里的关键词是"读懂"。设备出毛病的时候，直觉反应是找到坏掉的那个零件换掉，但功能分析会先问一句：这个零件在这个系统里承担的是哪条功能？这条功能是主要的还是辅助的？如果一条辅助功能失效导致整机停摆，那说明的不是零件质量问题，而是系统的功能结构有缺陷——把关键功能挂在了一条脆弱的链条上。

跳过这一步直接改结构，就是在没有地图的情况下修路。某实验室做过一个样品前处理的模拟项目，最初三个月一直在换材料、换转速、换滤芯规格，参数调了几十轮，效果时好时坏，谁都说不清为什么。后来老老实实把功能模型画出来，才发现真正的瓶颈不在滤芯，而在于"输送样品"这条功能由一个特别不稳定的组件承担，它的波动被下游放大成了看起来毫无规律的故障。方向一改，问题两周就收敛了。这种玄学调参的教训，做过硬件的人大概都有切身体会。

3. 功能定义与功能分类：一条动宾公式和它背后的原则

3.1 通用描述法：X 更改或保持 Z 的参数 Y

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

把这个定义写成公式，就是一句话：

X 更改（或保持）Z 的参数 Y

其中 X 是功能载体，Z 是功能对象，Y 是功能对象被改变或保持的那个参数。三个位置都必须能填进具体的东西，这条功能才算立住。

举两个例子。灯泡的功能不是"照明"两个字就完了，完整说法是：灯泡（X）改变（动作）环境空气与物体表面（Z）的亮度（Y）。录音笔的功能是：录音笔（X）改变（动作）声波（Z）的记录状态（Y）。再看一个更朴素的：电线的功能是传输电流，拆开看是电线（X）改变（动作）电子（Z）的位置（Y）。

这个公式的价值在于它强制你补全三样东西。只写"传输电流"，你说不清传输的是什么、被影响的是什么；补上"电子位置改变"，你才能判断这个功能实现得好不好、有没有替代方式。很多人做功能分析做到一半卡住，就是因为写下来的全是"支撑""连接""固定"这类含糊动词，动词后面没有对象，对象后面没有参数，三样都缺，句子看着通顺，实际上什么也没说。

动宾词组描述是基本要求：功能 = 工作 + 对象（V+O）。电线的功能 = 传输电流，这是动词加对象。但真正合格的写法还要再往下追一层参数，因为"传输"和"传输得好不好"中间隔着一整个参数体系。

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 与零件 B（Z）的接触压力（Y）。裁剪时先问：这条功能必须吗？必须。系统内有人能兼管吗？有——零件 B 本身是磁性的，把零件 A 换成可磁吸材料，吸力直接提供了接触压力，弹簧机构整体消失。组件少了一组，故障点少了一处，成本也降了。这就是裁剪和"减配"的区别：减配是功能没了省了钱，裁剪是功能还在、成本降了。

风险也很实在。裁剪掉一个组件，等于把一条功能交给了别的承担者，而这个承担者往往原本有它自己的职责。兼管之后它会不会顾此失彼、在极限工况下失效，必须回头做一轮验证。裁剪方案里那些看起来最漂亮的，往往就是在这种边界条件下失败的。

4.4 开发新系统与改进旧系统，走的是两条路

把上面这些串起来看，功能分析在两个场景下的用法是不同的。

开发新技术系统时，是从上往下的：确定主要功能 → 分解为子功能 → 为每个子功能寻找实现原理 → 组合、评估、取舍。这条路的关键在分解的质量，子功能拆得合理，每个都能独立找到多种实现；拆得不好，某个子功能天然绑死了一种方案，整条路就走窄了。

改进已有技术系统时，是从下往上的：梳理组件 → 写功能定义 → 建立功能模型 → 找有害功能、不足功能、过度功能 → 用裁剪重构。这条路的关键在定义的准确性，一条功能写歪了，后面所有的判断都跟着歪。

两条路最后都会汇到同一张图上：一张干净的功能模型。区别只在于，新系统是从空白的图开始画，旧系统是从一张乱糟糟的图开始擦。

5. 易混概念辨析：功能、需求、参数、组件到底差在哪

5.1 功能与需求：一个在用户嘴里，一个在系统里

易混点：把"用户想要什么"直接当成功能写进模型。

为什么会混：两者在自然语言里几乎同义，"我需要一个能装热水的杯子"和"杯子保持水温"，听起来说的是同一件事。加上需求文档通常写在项目最前面，做功能分析时手边只有它，顺手抄过来太自然了。

怎么区分：需求描述的是使用者的期望，主语是人，形式是"我要……"；功能描述的是系统的行为，主语是组件，形式是"X 改变 Z 的参数 Y"。需求是功能的来源，但不能直接当功能用，中间必须过一次翻译。用户说"我希望它安静点"，这是需求；翻译成功能是"隔音层降低传递到外部的声压"，这才进入模型。翻译这一步省略掉，后果是整张功能模型的主语全是"用户"，而用户不在系统里，你没法裁剪他、没法替换他、也没法评估他的性能水平。

5.2 功能与参数：一个是动作，一个是被动作改变的东西

易混点：把参数当成功能对象，写出"提高温度""减小噪声""增加强度"这类条目。

为什么会混：参数太显眼了，做工程的人习惯用参数说话，指标、公差、阈值，全是参数。而且参数是可测量的，写出来心里踏实。

怎么区分：参数是功能作用的结果，不是功能本身。功能问的是"谁对谁做了什么"，参数问的是"做完之后变成了多少"。"加热器升高样品温度"是功能，"温度从 20℃ 升到 80℃"是参数指标。两者的关系是：一条功能定义里必然包含一个参数，但参数不能单独构成一条功能。检查办法很直接——看句子里有没有一个具体的组件作为宾语，没有就是写成了参数。

5.3 功能与功能载体：你需要的到底是能力还是那个零件

易混点：说"这个系统的功能是电机"，或者"这个零件的功能是它自己"。

为什么会混：日常语言里经常用品名代替用途，说"装个空调"，其实意思是"实现降温"。在脑子里这两者是自动合并的，写下来才发现根本不成句。

怎么区分：载体是执行者，功能是被执行的行为。功能分析的整个价值就在于把这两者拆开——原文那句"我们不需要组件 A，我们需要组件 A 的功能"，说的就是这个。拆开之后你才有裁剪的空间：既然要的是能力不是零件，那么这个零件就可以被换掉、被合并、被超系统接管。拆不开的人做不了裁剪，因为在他眼里删掉零件等于删掉功能，那是不能接受的。

5.4 功能分析与故障分析：一个找结构缺陷，一个找失效原因

易混点：设备出了问题，直接拉一张功能图开始逐条排查，把功能分析当故障树用。

为什么会混：两者的产出看起来很像，都是一张带箭头的图，都在追问"这里为什么不对"。而且功能模型确实能暴露问题，容易让人误以为它是万能的。

怎么区分：故障分析从现象出发，往原因追，目标是定位那一个失效点，方向是收敛的；功能分析从结构出发，往作用铺，目标是看清整个系统的功能分布，方向是发散的。功能分析能告诉你"这个系统里有一条有害功能一直在恶化参数"，但说不清它今天为什么突然恶化。真要查一次具体的失效，功能模型只能提供一张地图，具体的路径还得靠失效分析、测试和拆检。把地图当诊断书用，最后往往是把整机拆了也没找到原因。

5.5 系统裁剪与减配降本：省下的到底是不是浪费

易混点：把裁剪理解成"砍零件省钱"，方案评审时用成本下降幅度来衡量裁剪做得好不好。

为什么会混：裁剪的产出里确实包含"零件变少了""成本降低了"，这两件事在报表上是一回事，在工程上完全不是。

怎么区分：看功能还在不在。裁剪的定义性条件是"功能仍然被实现"，承担方式变了、组件消失了，但功能一条没少，甚至因为少了传递环节而实现得更好。减配是功能被删掉或降级，成本下降是代价换来的。分辨办法很简单：把裁剪前后的功能模型并排放，功能条目应当基本对齐；如果某条主要功能在新模型里找不到对应，那不是裁剪成功，是需求被偷偷砍掉了。这条判断标准在评审会上特别有用，因为成本数字永远比功能列表更容易说服人。

6. 什么时候该做功能分析，什么时候别做

这套方法并不万能，用了不合适的地方，投入的工时换不回相应的判断力。

适合用的场景，通常有三个特征：系统已经复杂到没人能完整说清它在干什么；问题反复出现但每次都换个地方冒头；或者改进方向很多、彼此冲突，需要一个共同的判断标准。这三种情况下，功能分析提供的是一张共用的地图，让讨论从"我觉得"变成"图上这条作用是谁对谁做的"。

不适合的场景也很明确：

还有一个现实约束值得说清楚：功能分析的成本主要在写定义那一步，几十条功能一条条拆载体、对象、参数，非常枯燥，而且第一版几乎必然写歪。指望一次成型的人多半会在第三天放弃。可行的做法是先粗后细，先按主要功能拉一条主干，跑通一遍裁剪思路，再回来补细节——很多细节补到最后会发现根本不需要。

我一个改不掉的习惯是：任何一次裁剪方案上会之前，强制把裁剪前后的功能模型并排打印出来，逐条对功能条目。有一回砍掉了一个紧固件，图上功能对得整整齐齐，评审过得很顺，装机后第三周开始出现间歇性异响——那条接触压力被另一个组件兼管了，但那个组件在低温下会轻微收缩，兼管能力刚好掉到临界点以下。图纸上看不出来的东西，功能模型也没义务替你看出来，它只保证你没漏掉该问的问题。从那以后，我每次做裁剪都强制在边界工况下再走一遍功能核对，也算是一点血泪经验。

真正难的不是画图，是愿意承认图上那条作用自己从来没想过。功能分析最大的作用，大概就是把这种"没想过"变成"写在纸上、赖不掉"。希望帮到你。

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