3. 分类体系设计原则

分类体系不是把零部件“摆整齐”的目录树，而是决定后续检索效率、复用率、BOM 准确性和治理成本的基础设施。设计时最常犯的错误，是先把层级画得很深、很全，再回头发现没人愿意按它归类。因此本节从四个相互制约的设计要素展开：分类维度选择、层级深度控制、属性继承、分类编码规则。它们共同决定一个分类节点是否“可归类、可检索、可复用、可维护”。

一、分类维度选择：先确定“按什么分”

分类维度是分类节点的划分依据。Windchill 中常见的维度包括：功能用途、结构形式、材料、连接方式、驱动方式、安装方式、标准体系等。维度选择的核心原则是单一主维度优先：同一层级尽量只用一个维度切分，避免“功能+材料+规格”混在同一层，否则会出现“螺栓”既可按螺纹分、又可按头型分、还可按材料分的归类歧义。

以紧固件为例，推荐的主维度顺序为：大类（紧固件）→ 功能子类（螺栓/螺钉/螺母/垫圈）→ 结构形式（六角头/内六角/法兰面）→ 标准体系（GB/DIN/ISO）→ 规格族（M3~M12）。这里“功能”是第一主维度，“结构形式”是第二主维度，标准体系是第三主维度。每一层只回答一个问题，归类时不需要反复权衡。

维度选择还要考虑检索路径。如果工程师最常按“规格”找件，那么规格应尽量靠近叶子节点，而不是埋在深层；如果采购最常按“标准号”找件，标准体系就应成为独立可检索维度。维度不是越多越好，一般建议一个分类节点下不超过 3 个主维度，超过时应拆分为独立分类树或改用属性表达。

二、层级深度控制：4~6 层是工程甜点区

层级深度直接影响归类成本和检索效率。层级过浅（2~3 层），节点下零件数量爆炸，检索时仍需二次筛选；层级过深（7 层以上），归类时点击次数多、路径长，且容易出现“不知道放哪层”的犹豫。工程实践中，4~6 层通常是可维护的甜点区。

控制深度的常用方法有三种：一是把“可枚举的取值”下沉为属性，例如把“材料”从分类层级改为属性字段，避免为每种材料建一个节点；二是把“组合关系”交给 BOM 或变型表达，例如“带垫圈螺栓”不必单独建类，而由装配关系表达；三是设置“其他/未分类”兜底节点，但必须配套定期清理机制，否则兜底节点会变成垃圾场。

判断深度是否合理，可以用一个简单指标：叶子节点平均承载零件数。若某叶子节点下零件数长期超过 200，说明该分支还应再分；若某中间节点下只有 1~2 个叶子且零件极少，说明层级冗余，应合并。建议在分类体系上线前，用历史零件数据做一次分布统计，把“节点数—零件数”曲线拉平，而不是凭直觉拍层级。

三、属性继承：让分类节点“自带字段”

属性继承是 Windchill 分类体系区别于普通文件夹的核心能力。其机制是：在分类节点上定义属性（如材料、表面处理、标准号、规格、强度等级），子节点自动继承父节点属性，叶子节点再补充专有属性。这样归类时系统自动带出必填字段，减少人工录入，也保证同类零件字段一致。

设计属性继承时要注意三点：第一，继承属性应是“该类零件普遍需要”的字段，例如“螺纹规格”对螺栓普遍需要，但对垫圈不适用，就不应放在紧固件根节点；第二，区分“分类属性”与“业务属性”，分类属性用于检索和归类，业务属性（如供应商、价格）应放在物料主数据或采购视图，避免分类树被业务字段污染；第三，设置必填与选填，必填字段过多会拖慢归类速度，建议每个叶子节点必填字段控制在 5~8 个。

下面这张图展示了分类维度、层级深度、属性继承与编码规则四者之间的约束关系，以及它们如何共同作用于一个可用的分类节点。

四、分类编码规则设计：让节点可被机器识别

分类编码是分类节点的“身份证”。好的编码规则应满足四个条件：唯一性、可读性、可扩展性、与层级对应。常见做法是采用“段位式编码”，每一段对应一个层级，段与段之间用分隔符连接。例如 FST-BOL-HEX-GB5782：FST 表示紧固件大类，BOL 表示螺栓子类，HEX 表示六角头结构，GB5782 表示标准号。这样编码本身就能反映分类路径，便于人工识别和系统解析。

编码设计要避免两个极端：一是纯流水号（如 100001、100002），虽然唯一但不可读，无法从编码判断类别；二是把规格写进编码（如 FST-BOL-HEX-GB5782-M10-50），导致编码过长且规格变化时编码失效。规格、材料、长度等应作为属性字段，而不是编码段位。编码只表达“分类身份”，不表达“具体规格”。

段位长度建议统一，例如每段 3 位字母或数字，不足补零。若某层分类数量可能超过 999，应预留 4 位。编码一旦发布，不应随意变更；若分类调整，应通过“编码映射表”维护新旧对应关系，而不是直接改编码，否则会破坏历史数据的可追溯性。

五、四要素的协同与冲突处理

四个要素并非独立，而是相互制约。维度选得细，层级就容易深；层级压得浅，属性就要承担更多区分职责；属性字段多，归类录入成本就高；编码段位多，维护成本也高。实际设计中，常见的冲突是“检索需求”与“归类成本”之间的矛盾：工程师希望按规格直接检索，但规格作为属性字段时，检索需要依赖属性搜索而非分类浏览。

处理这类冲突的原则是：分类负责“是什么”，属性负责“什么样”。分类树回答“这是螺栓还是螺母”，属性回答“这个螺栓是 M10 还是 M12、是不锈钢还是碳钢”。检索时，用户先通过分类缩小范围，再用属性过滤精确命中。这样既控制了层级深度，又保留了检索精度。

最后需要强调，分类体系不是一次性设计完成的静态结构，而是需要持续治理的动态资产。建议每季度统计一次各叶子节点的零件增长量、属性完整率和编码重复率，对异常节点进行合并、拆分或属性调整。只有把设计原则和治理机制配套起来，分类体系才不会在半年后变成“没人用的目录树”。