先分类，真的是对的吗？——一个物料系统设计者的思考
最近在备考时看到一句话：信息是数据的内涵，数据是信息的表达。 这句话虽然抽象，但是它解释了为什么工程师和程序员在讨论同一个东西时，永远说不明白。 工程师和程序员说的是两种语言 当工程师说"物料"的时候，他心里想的是一条信息——“我知道这是什么东西”。他看表格里的几个属性：材质、规格、图号，就能认出"这是一块钢板"。工程师不需要所有字段都填满，他凭几个关键信息就能判断。 但当程序员说"物料"的时候，他心里想的是数据库里的一条记录——有固定的字段结构，每个字段的类型和含义都是预先定义好的。 这两种理解都没有错，但它们指向的不是同一个东西。工程师关心的是"这是什么"，程序员关心的是"数据长什么样"。 问题在于：为什么工程师觉得自然的事（知道这是什么就行），程序员却总觉得"不够规范"？ 不是谁固执，而是长期的技术约束塑造了我们所有人的思维。在传统开发范式下，程序必须预先知道所有字段的类型和含义，才能运行。一个字段不确定，整个系统就没法写。所以我们会本能地把一切模糊的东西变成固定的结构——分类就是最自然的工具。 这不是谁的选择，是技术条件的选择。 我之所以会意识到这一点，是因为我们最近在建一个物料数据库。一位工程师负责设计分类树，建完之后，这位设计者觉得结构很清晰、很完美，但我看的时候觉得意义不大，而其他一些使用它的工程师也觉得不理想。 同一个分类系统，三种完全不同的感受。为什么？ 仔细想想，原因其实很简单： 设计者觉得完美，因为这个分类树符合他的组织习惯——他是按"文件夹"的逻辑来建的，东西该放哪一层的哪个抽屉，他心里很清楚。 我觉得没用，因为我平时管理电脑里的文件就不怎么依赖文件夹。我习惯用全局搜索软件，或者现在直接用 AI 来帮我找东西。不管文件放在哪个文件夹里，我搜关键词就能找到。分类树对我来说只是一个多余的浏览入口。 其他人觉得不理想，因为这个分类树不是按照他们的思路建的。他们有自己的分类习惯，但系统只有一种分法，自然觉得别扭。 两个推论 从这里可以得出两个结论。 第一，分类不是人类的刚需。 我和设计者对分类的态度截然不同，但我们都很好地管理着自己的数据和文件。分类树很大程度上是 Windows 文件夹文化培养出来的习惯——它教我们把东西放到不同的目录里。但这种习惯不是强制性的，也不是唯一的管理方式。很多人（像我一样）用搜索代替分类，照样能找到需要的东西。 第二，分类的不一致性是不可避免的。 人类天然就有不同的组织习惯。设计者喜欢文件夹式，我喜欢搜索式，其他人有各自的偏好。不可能存在一个让所有人都满意的分类结构。既然每个人的想法都不一致，那分类系统只有两种结局：要么是冗余的、复杂的，试图覆盖所有人的需求从而勉强稳定；要么是灵活的，但注定让大部分人觉得不顺手。 既然分类不是人类的真实需求，那为什么一提到物料库，所有人还是会理所当然地觉得"先分类"？ 当企业要建立物料库的时候，问题来了：我们管的东西五花八门，有螺栓、钢板、电机、阀门、软件、油漆……它们需要的信息完全不一样。 螺栓需要标准号和规格，钢板需要材质和厚度，电机需要功率和电压，软件需要授权码和版本号。 面对这些五花八门的对象，大家的第一反应都是"先分类，每类一套字段结构"。不是因为这个方案有多好，而是因为在传统的技术约束下，这是最容易实现的方案。 传统的系统必须是严格的、准确的，它需要预先定义好所有字段，每条记录都填满相同的结构。编写能处理维度不确定数据的系统非常困难——并非无法实现，比如购物网站的分面搜索就是一个例子——但开发成本和 UI 实现难度都很高。 所以当我们需要管理多种类型对象的系统时，分类是最自然的选择。每个类别一张表，表结构固定，字段统一。每个物料必须先分到一个类别，才能获得对应的数据结构。 分类之所以成为物料库的基础设施，不是因为人类觉得分类好用，而是因为系统需要统一的字段结构，而分类是实现统一结构的最简单方式。 这种技术约束持续了太久，久到大家都把它当成了理所当然——“系统本来就该这样设计”。但当我们回到工程师的视角，就会发现：工程师真正需要的从来不是填对分类，而是让系统帮他找到这是什么。 我们一直在用解决数据问题的方式，去处理一个信息问题。 如果我们先不去想数据库表怎么建，而是回到信息本身——要确认一个信息，到底需要多少数据？ 信息的识别，需要的数据维度天生不一致 举个例子：要区分一个人，如果他的名字很特殊，只需要知道名字就够了；但如果是一个很常见的名字，就还需要知道他在哪个部门、什么岗位。同样是要识别"这个人是谁"，需要的数据维度却完全不同。 物料的识别也是一样。一颗螺栓，如果它的图号是一个罕见的规格，光知道规格就够了；但如果它的规格只是"M8×25"，那就远远不够——还需要知道材质、强度等级、表面处理，甚至品牌。同样是要确认"它是什么"，因为数据值的不同，需要的字段数量就不同。 这就是信息的特点：同一类对象，因为数据值的独特程度不同，区分它需要的字段数量就不同。数据值足够独特的，少一点字段就够了；数据值很常见的，就需要更多字段来缩小范围。 还有另一个因素：对象的总数也会影响区分它需要的字段数量。在一个小部门里，叫"张伟"的可能只有一个，知道名字就够了；但放到全公司几千人里，重名概率大增，就必须加上部门、工号才能区分。信息还是那个信息，但区分它需要的数据量变了。 螺栓也一样。如果一家企业平时只用四五种标准螺栓，说"M8×25 8.8级"就够了，所有人都知道是哪一种。但如果涉及关键受力部位，比如压力容器、起重机吊臂、钢结构连接，光说"M8×25"就不够了，还得加上材质、强度等级、表面处理方式、螺纹精度等级才能区分。同样的规格，在不同的使用范围里，区分它需要的字段数量不同。 从这里可以得出一个和分类相似的推论。 数据的维度也是演进的，它随着系统面临的情况越来越复杂而不断增加。 一个螺栓，刚录入的时候可能只需要规格和材质；后来有人用在关键场合，加上强度等级和表面处理；再后来有人需要区分供应商，又加上品牌。系统每遇到一个新的区分维度，就会多一个字段。 这种演进在固定表结构的模式下注定是不稳定的——要么字段越来越多、越来越冗杂，试图覆盖所有可能的区分需求从而勉强稳定；要么字段太少，牺牲实际业务需求以换取结构稳定。 结果就是：有的记录空了一半，有的记录填了一堆用不上的信息。 人们为什么没有对这个冗余提出异议？因为软件开发的限制让人们习惯了这一点，Excel 的使用也让人们习惯了这一点。过去不是没有人注意到这个冗余，只是没有更好的办法。人脑自动过滤了不必要的信息，久而久之，大家都觉得"表里每一行都有相同数量的列"是天经地义的事。 如果我们抛开这些限制，回到需求本身——一个理想的系统应该长什么样？ 它应该能接受不定维度的数据。你告诉它什么，它就记下来；不需要填满所有字段，不需要预先定义结构。它还能理解这些信息——分辨哪些关键、哪些冗余，在查询时帮你找到你要的东西。 这种系统不是想象出来的，它是需求的本来面目。只是在过去的技术条件下，实现它的代价太大了。 LLM 让我们有机会换个角度 大语言模型出现之后，我们终于有能力去接近那个"需求的本来面目"了。 它不需要统一的字段结构。你给它一段描述，它能理解里面包含了什么信息；你给它不同维度的数据，它能自动分辨关键和冗余。更重要的是，它能理解不同表达方式背后的实际含义。 “材质"和"材料”、“DN50"和"口径50mm”——在传统系统看来是完全不同的字段，无法匹配；但 LLM 能认出它们说的是同一个东西。 这意味着我们不再需要预先统一所有字段的命名和结构。过去，系统要找到一条数据，字段名必须完全一致；现在，LLM 可以自动寻找语义上相似的数据，挖掘字段名的实际含义。系统不再只能做精确匹配，它开始"理解"了。 这正是 LLM 对程序设计思维转变的意义——过去我们认为"必须先统一结构才能管理"，是因为系统只会按字段名匹配数据。当系统能够理解语义本身，统一结构就不再是前提条件了。 这意味着我们可以回到问题的本质去重新设计系统——站在信息与数据的关系这个角度去思考，而不是被传统开发范式牵着走。 分类不会消失，但它应该退回到它真正的位置——辅助浏览，而不是管理数据的基础设施。