多年以前，我一直对于 “专家” 这一词有大量的困惑。到底怎样才是专家？怎样才算是技术专家？社交媒体上所谓的 “技术专家”，在某方面（如编程）上的实力一般，也算是专家吗？过去，我并没有细入的思考过这个问题，直到看到一个软件的元模型，以及一本名为《表象与本质》的书，才重新构建起一个专家的雏形 —— 感谢公司大佬之前推荐的 GEB。

在这里，便尝试性地做出第一次小结。作为第一次小结，它会存在一系列的不完善的地方，有待于后续进行完善。

所谓的专家嘛，就是在擅长的 “领域”（或者领域中的一个子领域）里，构建了具有范畴化（归类）的概念空间，并可以通过类比灵活地完善自己的概念库。简单来说，就是一个专家能有不同层次的抽象能力，还能以合理的方式（不同的层次）的语言和不同的人进行 “交流”（编程的对话）。

模型：对于现实的抽象

回到我们擅长的编程领域，尝试性地对周遭的空间做一个抽象。诸如于，对我们所处的位置进行建模，以将其作为数据进行存储。在不同的上下文里，这个位置是一个相当迷惑的。比如说，你正在和你的亲人聊天，ta 问你：你现在哪里？不同的人可能有不同的回答：

• 住在一起的家属，答案可能是：客厅。可能让你去拿个快递。
• 出差时：某某市。不需要详细的信息。
• 市内外出：xx 商城。

仅从交流的层面来说，这个问题就相当的令人头大。

对位置进行建模

而回到代码在，在不同的业务领域里，在对于这个位置建模时，这个位置可能是：

• 一个 GEO 坐标。它只包含：longitude、latitude 两个属性。软件想获取当前的位置，以推荐一些相关的广告信息。
• 一个房间内的位置。它可能是：卧室（次卧、主卧）、室厅、厨房等。软件在寻找匹配的智能（障）音箱，并及时响应你的请求。
• 一个建筑位内的位置。它可能是：地下一层、地下二层、一楼、地面等。软件在寻找合适的位置，以找到合适的人将快递放到你手里。
• 一个城市的某个位置。它可能是：xx 区 xx 街道 xx 小区等。软件在寻找你的准确位置，以便判断你是否在封控区内。
• 一个国家的某个省某个市。它可能是：中国福建省厦门市。软件需要大致的位置，以便计算合理的快递价格。

位置在不同的上下文、不同的人眼里，可能造成非常大的二义性。而以协作的方式构建出这个模型，则可以有效地减少这种二义性的发生（PS：这也就是为什么协作调模型会受到欢迎的原因）。如果只考虑通过 IP 上门查表的情况下，只需要类似于百度这样的 API 结果：

{  
    address: "CN|北京|北京|None|CHINANET|1|None",    #详细地址信息  
    content:    #结构信息  
    {  
        address: "北京市",    #简要地址信息  
        address_detail:    #结构化地址信息  
        {  
            city: "北京市",    #城市  
            city_code: 131,    #百度城市代码  
            province: "北京市",    #省份      
        },  
        point:    #当前城市中心点  
        {  
            x: "116.39564504",    #当前城市中心点经度
            y: "39.92998578"    #当前城市中心点纬度
        }  
    },  
    status: 0    #结果状态返回码  
}

所以，在掌握上述的分类的情况下，我们能算是地理位置方面的专家吗？

新的抽象概念：行政区与行政区划分

我觉得我不是，比如说，按专业（维基百科上，对于 行政区划 的定义来说）来说，省这一级应该算是一级行政区：所以，我们有 34 个省级行政区，包括23个省、5个自治区、4个直辖市、2个特别行政区。在中国的上下文下，我们相当于只概括了其中的一类类型，基于这种模型建模，会出现中国北京北京市的情形。

而，现在这样的位置模型放到俄罗斯联邦的情况下，它又有问题了，会出现俄罗斯 - 北高加索联邦管区- 车臣共和国，再往下才是行政区。如此类推，就当前来说，我们能掌握好地球上的主要行政划分。而像英国这种包括殖民地的国家，还有群岛 - 教区这样的概念。放到地球 🌍 这个上下文下，这个问题就更复杂了。

所以，在中文的维基百科上，这个层级就变成了：

• 一层行政区
• 二层行政区
• 三层行政区
• 四层行政区
• 五层行政区

然后，每个国家就可以获取自己有几级的位置，以及有对应的名称，完美。

然而，由于我们原先已经有一套系统了，为了更好的类比于原来的位置信息，API 可能返回相同的结果，但是解释就变成了如下的形式：

Country Name：
State/Province：
District/County：
City：

这个外国人写的模型又相当的令人头大，District/County 变得相当的诡异。所以，这就是考验一个专家能力的时候了。

在这时，省与 State 进行了类比，也都抽象都到一级行政区，对于我们这些普通人来说好理解多了 \~。从编程的角度来说，一层行政区这个名称相当的不好，鬼知道它对应的是啥。

抽象：用再简单的方式解决问题

抽象的有趣之处在于，当你有了更高一次的抽象时，解决问题的方式将变得非常简单 —— 但是，它是有成本的。

从抽象的过程来看，其实可以分为多种分类方式及其抽象，每个维度面向的是不同发展时期的。所以，它可能会有：

• 类比：省市区街道 → 行政区
• 分类：行政区类比 → 一二三级行政区
• 元模型：行政区类比/一二三级行政区 → 层级树

只是呢，从编码的角度来看，不同的抽象层次里，它的实施成本差异是巨大的，如提取一个元模型 —— 可以直接考虑按倍数计算。而类比呢，是其中成本最小的一种方式。

全集还是抽象模型？

在实施的时候，当我们构建一个位置模型时，会考虑构建一个位置的全集，这样实施成本是最低的 —— 因为位置相关的属性是有限的，短期内也不可能快速变化。并且，位置信息并不是系统的核心功能所在，并不需要建立过于复杂的元模型。而其它模型，可能是无限的，并且还会大量的无预期增长，比如各类的智能设备。诸如于在 OpenHAB 智能家家居系统，构建的 Location 层次是这样的：

Location:
 - Indoor
    - Building : Garage, House, SummerHouse
    - Floor    : Attic, Basement, GroundFloor, FirstFloor, SecondFloor, ThirdFloor
    - Room     : Bathroom, Bedroom, BoilerRoom, DiningRoom, Entry, FamilyRoom, GuestRoom, Kitchen, LaundryRoom, LivingRoom, Office
    - Corridor 
    - Apartment
 - OutDoor: Carport, Driveway, Garden, Patio, Porch, Terrace

穷举所有可能的家居位置信息，构建一个分类系统和分类机制，来一个新的 Location，可以划到一个合适的位置。所以，如果一个专家，它可以对它们进行抽象，分类，再进行元模型的提取。

在编程模型上，OpenHAB 则提供了一个概念的抽象：Things、Channels、Bindings、Items、Links，其中 Things 是整个系统的一个重要概念，即可以物理添加到系统中的实体。Things 并不一定需要是真实设备，还可以是互联网上的各类资源。从这个定义上来说，它对于可控制的资源进行了定义。而设备也是一种资源，HTTP API 也是一种资源。它相当于是对他们进行了抽象，这也就是 Things 的有意思之处：两个不相关的分类，在具备同一属性时，可以进行抽象。

所以，从编程上来说，提供全集还是抽象模型，取决于它的增长程度。

抽象行为

有了抽象的模型之后，再对模型的行为进行抽象，我们就能得到一个抽象的语言 —— 用来描述模型之间如何进行交互。我们便能得到一套行之有效的 DSL，诸如于 OpenHAB 中的 Rule DSL：

rule "Start wake up light on sunrise"
when
    Channel "astro:sun:home:rise#event" triggered
then
    switch(receivedEvent.getEvent()) {
        case "START": {
            Light.sendCommand(OFF)
        }
    }
end

当我们提升到这一层次来考虑问题时，那么问题就变得非常简单了。甚至于，我们可以结合各类智能（障）语言输入设备，来快速完整各类设备的添加。

元模型：一个类型系统

而在我们引入设备这一概念的时候，我们会发现：我们是在编写一个领域特定的类型系统。在这个类型系统里，我们为这些设备定义了：名称、属性：度量、状态、控制等。诸如于一个客厅的灯，我们在设计它的元模型时，它的名称是：灯。它包含的属性包含了：亮度，高度是一个 Int 类型，所以还需要在模型上存储对应的属性。一个简单的元数据便是（仅为示例）：

# Room
name: 灯
location: Indoor::Room::LivingRoom
category: Lightbulb
property: [{ name: 'light', type: Lighting, value: 38 }, { key: 'color', type: ColorItem, value: '#123456'}]

而对于 value 本身的处理，也就是一类的类型，它可以是：Color, Number, Int, Image, Location, DateTime, Switch等。而针对于 Switch 来说，它还归属于 OnOffType，包含了开关相关的状态（State），以及对应的控制命令（Comand）。而 State、Command 本身也是一种 Type。

简单来说，它对归类进行了归类：

• 一个客厅的灯是一种灯。
• 灯包含了开关的属性。
• 开关则包含开关状态和控制开关的属性。

这真是昂贵的抽象成本。大类中包含了小类，小类又包含了细分类型，而类型最后还要用类型系统描述。

构建抽象的成本

回过头来看，我们构建模型的目的又在哪里呢？为了一次次的日常交流，还是为了更好的知识传承？

最后，回到我们跑歪的标题上来，一个理想的专家在精通自己的领域之后，能快速触类旁通。就好比是一个学霸，便是一个 “学习/考试” 方面的 “专家”。