Python:更强的建模语言

形式化建模语言

在传统信息工程中，工程师使用各种领域专用语言（DSL）精确地描述信息模型，其中以 XML 为基础的各类描述语言最为广泛。

XML 是一种形式化标记语言，但它只完成了语法层面的形式化。具体语义由各应用场合以特定方式自行表达，由此衍生出众多 DSL——真可谓"一种语言，各自表达"。相比早期 Word 文档等私有二进制格式，XML 增加了模型语言的标准化和人类可读性，但它仍是一种以机器为中心的形式化语言，对人类的语义理解并不友好。大概没有多少人有耐心看懂 Word 导出的 XML 格式文档，它依然如天书一般。

XML 语言的优点在于结构化数据的标准化交换。不同的软件能够共享数据，它是语言无关的，不依赖某一种编程语言。为了编写、传输和解析的效率，它被设计得尽可能简洁。

作为一种结构化信息的文本格式，XML 是足够的。事实上，XML 最初就是为描述出版物格式而设计的，后来才延伸到网页等更广泛的应用场景。但作为一种计算机信息模型的描述语言，它是远远不够的。描述计算机信息模型的主要方法是面向对象程序设计语言——类、实例、属性、方法构成了信息模型的基本要素，实例化、继承、派生等能力实现了由简至繁地构建模型，方法则提供了描述模块行为的手段。当代程序设计语言大多具备面向对象的能力（如 C++、Python、C#、Java 等）。因此，在程序设计中使用面向对象语言描述信息模型，当需要与外部交换信息时，再定义一种 XML/JSON 文档格式将内部 OOP 的数据表达出来。不同的表达方式形成了不同的行业专用语言（DSL），在工业自动化领域，比较知名的 DSL 包括 SysML、AML、OPC UA 等。在系统工程领域，有一部分工作就是不同 DSL 之间的转换。

面向对象的建模语言

进入 AI 编程时代，我们期望 AI 大模型能够参与信息模型的生成、验证和代码生成。LLM 的训练数据里，代码（尤其是 Python）的量远大于任何单一数据格式（那些基于 XML 的 DSL）。LLM 的预训练语料中，Python 代码占了相当大比例——LLaMA 的训练数据中代码约占 4.5%，PaLM 中约 5%，而代码里 Python 又是最常见的语言之一。这意味着模型在"读"和"写" Python 时，见过的样本数量远超任何特定的数据序列化格式。模型最擅长生成的，就是训练集中出现最多的格式。Python 和 JSON 都在训练数据里大量出现，但 Python 携带了更丰富的语义信息（类型、约束、逻辑），而 JSON 只是数据而已。实验表明，当任务涉及推理（比如计数、求和、过滤）时，生成代码比直接看 JSON 的准确率高 3% 到 50%。

孔子曰，“己欲立而立人，己欲达而达人”。在 AI 时代，这句话可以转述为"己欲立而立 AI，己欲达而达 AI"——人类容易理解的内容，同样适合 AI 的理解。使用 Python 编写信息模型，更得 AI 的青睐。

除了 LLM 更熟悉程序设计语言（Python）之外，使用程序设计语言作为模型描述语言还有以下几方面的优势：

自动生成模型的能力

首先，我们可以在信息模型中增加动态生成模型的方法，例如根据输出功率的不同确定正常电流的范围、选择不同的减速机等等。

XML 和 JSON 是静态的形式化语言，描述的是固定的信息模块：两个模型只要有一个属性不同，就是不同的描述文件，每一次参数变化都意味着一份新的文件。

Python 则天生是一种生成式语言——它可以根据需求动态地生成不同的信息模型，某些属性可以基于其他属性的取值动态计算和派生。生成式描述语言将模型从一份静态文档变为一套可执行的逻辑，输入参数即可产出对应的实例。这不仅是效率的差异，更是范式的转变。生成式描述语言能够实现：

例如，可以使用程序设计语言直接操作模型，生成验证程序和实例化生成程序。在一个图案上摆放几百个 LED，就可以由 AI 编写一段程序，根据图案的轮廓自动摆放灯珠。

基于 Python 的信息模型中不仅仅是静态模型，还包括了生成、论证、格式转换等额外的方法。利用这些方法，AI 能够更准确、更高效地动态生成信息模型。例如，根据一个设备清单，生成车间里所有设备的管理壳模型。在生成物理模型时，某些属性的设定也可以通过数学、物理和工艺计算之后生成。使用 Python 构建信息模型带来了强大的建模能力和意想不到的效果。

阅读代码的推理能力强于阅读 XML/JSON

Python 原生的模块化和面向对象能力，使构建面向对象的模型更易于阅读和推理。

以 OPC UA 信息模型为例：它使用 XML 语言描述基于图模型（Node-Relationship）的信息模型，在图模型之上再构建对象、变量、方法等语义层。如此复杂的三层架构带来了灵活的模型描述能力，但无论是人类还是 AI，理解和操作的难度都很大。用 Python 描述同样的模型，面向对象的结构天然映射语义层级，可读性和可推理性显著提升。

生成基于模型的应用程序

传统的做法是编写一个运行时程序，对 XML/JSON 的模型进行解析，然后转变为内部的数据格式或执行流程。由于要兼顾所有的应用场景，信息模型的描述语言、生成和解析都变得异常复杂。而使用程序设计语言直接描述信息模型，AI 能够直接生成程序来操作模型。比如，在调试 OPC UA 应用程序时，我们通常使用 UA Expert 软件，配置和操作都很复杂。但现在，我直接让 AI 生成一个专用的 Python OPC UA 客户端程序，短短几行代码即可完成。

实验也表明，LLM 直接输出代码比输出 XML/JSON 数据时的推理能力更强。强制 LLM 输出 JSON 时，模型的推理能力会下降约 10–15%。

同样是处理结构化数据，让 LLM"写代码去处理"比"直接用脑子算"更靠谱。这不是因为代码执行有多快，而是因为生成代码的过程本身就是一种结构化推理——模型被迫把模糊的"感觉"变成精确的、可执行的步骤。

OOP 语言建模减少了大模型的幻觉

人难之事，AI 亦难。千万不要高估 AI 大模型的能力——它与人类一样，你在理解过程中容易犯错的地方，恰恰也是 AI 容易出错的地方。不要幻想丢给它一些数据表（DataSheet）、产品手册、网站地址或 GitHub 代码，通过三言两语的自然语言就能生成一个直接上线运行的软件。这通常会令人失望，因为你提供给 AI 的信息大多数是非结构化的。

而严谨地描述事物的语言就是计算机程序设计语言。人类发明程序设计语言的初衷就是准确无误地描述数据和算法，其基础是逻辑学。

像 Python 这样的 OOP 语言具有很强的结构化数据和算法的描述能力。类定义、派生、实例、数据类型、模块化应用都是为了准确地描述数据结构和算法。因此，用 OOP 语言描述信息模型不仅效率高，而且更准确，没有二义性。

建模的重要性

再举一个嵌入式程序设计的研究实例。

在前面的文章中我们已经指出，嵌入式程序设计要比纯软件开发难许多。因为嵌入式系统要与底层硬件打交道，现代嵌入式处理器芯片非常复杂，加上各种引脚复用、寄存器访问和中断处理，这些内容需要有硬件背景的程序员才能胜任。

有人希望将这些令人头痛的工作交给 AI，让 AI 直接阅读元器件手册，直接编写嵌入式应用程序。我并不主张这种编码方式。元器件手册中的信息是非结构化的，AI 和人一样，容易产生理解错误和遗漏。

ST 公司为 STM32 系列芯片提供了 STM32CubeMX 设计工具，但它不是一个基于模型的设计工具，而且只能通过软件图形界面操作。特别是时钟配置，一不小心就会搞错。这种软件显然不适合 AI 使用。

正确的方式应该是根据具体项目的要求，构建一个硬件平台信息模型，在信息模型的基础上进行软件的开发和迭代。而硬件平台信息模型应该由人类工程师借助 AI 工具来构建——也许由硬件工程师来构建硬件信息模型更为合适。

许多场合下，并不需要更强大的 AI 大模型，也不需要更聪明的智能体，只要将数据、信息整理成模型，就能产生神奇的功效。

OOP 语言建模的缺陷

使用OOP 语言建模也是有缺陷和使用边界的：

XML/JSON 只是模型的静态描述文本，不包含动态的代码。一旦包含了代码就可能存在安全的隐患。既怕他不够灵活，又怕他太灵活而出去闯祸。

OOP 语言描述的模型与程序设计语言有千丝万缕的关系，不是完整和独立的文档。所以不适合交流与传播

不中立，无法成为标准。

一切都不是万能的，关键要用对地方。可以在开发过程中使用OOP 语言描述信息模型，最终生成标准化的文档，例如XML 数据和代码。

同时也只有不断地尝试，才能寻找到AI 时代建模与编程的新范式。

实验：IEC 61499 建模

为了深入研究 Python 语言建模和 AI 代码生成的效果，我做了一个 IEC 61499 功能块建模的实验。

IEC 61499 是分布式控制和监督系统中的功能块标准，是一种分布式系统的建模方法，基本模块是基于事件触发的功能块。应用程序是由多个功能块构成的功能块网络（Function Block Network）。IEC 61499 标准中，功能块类型和功能块网络都是用 XML 语言描述的，能够将功能块转换为运行时中的模块，由运行时解释执行功能块网络。

在我们的实验中，基于 Python 的 class，手工编写了基础的信息模型，包括：

在功能块的类中，我增加了一些动态生成的工具方法：

第一步，为了给 AI 做出示范，我手工编写了几个功能块模型以及一个功能块网络，最后将这些交给了 Claude Code 来生成其他功能块模型和应用程序：

这些方法原本都是组态软件中的菜单操作，现在揉合进了模型中，扩展了 AI 自主操作的能力。

实验结果表明，将开源 IEC 61499 IDE 中的所有功能块类型转换成 Python 类准确无误，能够绘制 SVG，并通过 __repr__() 方法让类的实例化对象能够“自我介绍"，帮助 AI 理解。

第二步，我手工编写了一个功能块网络的示范程序，然后由 AI 编写了一些 IEC 61499 功能块网络（应用程序），获得了满意的效果。这比在 4diac 中拖拽放置方便太多。在 IDE 的图形界面上，构建哪怕一个简单的数字逻辑判断都会把人累坏；一旦需要替换一个功能块，就得重来。图形配置做点小应用还行，做工程实在令人疲惫，而且交流也麻烦，只能靠截图与粘贴。进入 AI 时代，文本反而更加高效。

下一步，我们会继续添加 IEC 61499 中的资源模型、功能块代码生成以及使用 YAML 描述的功能块，同时寻找更多利用 OOP 语言更好地描述信息模型的佐证。

结论