「模型在哪一层定义，数据就在哪一层获得自由。」
我与设备打了二十多年交道，从二十年前趴在配电柜里抄 PLC 点位，到今天琢磨让每一台智能仪表"自己说清楚自己是什么"，一路走来最深的感受是：设备接入这件事的开发范式，从来没有停止过演进------从硬编码点表，到组态标签，到云端物模型，再到今天正在发生的「模型即数据」。每一次范式跃迁，都让设备和数据的距离缩短一截，让过去要停机才能做的事，一步步变成一条普通的消息。
我的职业生涯，恰好就是一部微缩的设备接入范式演进史。
一切始于一张点表
一切始于二十年前的配电柜。2001 年我进入工控行业，最早做的项目是二型计量监控、烧结配水、焦炉四大机车这一类工业自动化系统。那个年代接一台设备，第一件事不是写代码，是抄点表------拿着厂家给的 Modbus 寄存器地址表，一个点一个点地核对：40001 是 1#泵的运行状态，40010 是液位，41005 是设定值......然后把这些地址硬编码进程序里，或者做进组态软件的点表里。
点表就是图纸。图纸画错了，改起来是要命的：改一个点位，往往意味着停机、改程序、重新编译、重新下装、重新调试。500 个点的项目，光核对点表就能耗掉一周。那时候我常想：设备明明知道自己有什么，为什么非要人去逐个"翻译"？
这份对"人工翻译设备"的不满，成了我此后二十年穿越数次范式变革的初心。
第一次跃迁：从硬编码点表到组态标签
范式的第一层跃迁，是从硬编码到组态化。我做通用组态软件、嵌入式组态的那几年，最直观的进步是：点表从代码里搬进了图形化的工程文件，变量成了"标签"（Tag），带上了名字、类型、量程、报警限。再后来 OPC 兴起，从 1995 年的 OPC DA 到后来的 OPC UA，设备侧提供了统一的访问接口，我们不用再关心寄存器地址，只要去服务器上"点"标签就行。
这一步的效率提升是实实在在的。但它的局限也很清楚：标签表仍然是工程师的私有资产。它锁在 SCADA 的工程文件里、锁在某个项目的硬盘上，换一套系统、换一个集成商，标签表就要重做一遍。设备换了新版本、多了一个传感器，改的还是那份停机才能动的工程文件。
我当时并没有觉得这有什么问题------全行业都这么干。直到物联网来了，我才看清这层范式的天花板在哪里。
第二次跃迁：从工程师的点表到云端的物模型
第二次范式跃迁，是物联网把"模型"从工程文件搬到了云端。
我是国内最早一批对接阿里云物联网平台的，从 Alink 0.7 版本协议就开始。那时我在阿里云 MVP Tech Show 上讲飞凤平台硬件快速接入，也深度参与了飞凤平台的合作开发------2017 年无锡鸿山小镇那个城市级项目，逼着平台方做统一抽象：一城一网，几百万个感知终端，如果每个设备都要人肉建模，平台根本接不住。物模型（属性、事件、服务三要素）就是被这样"逼"出来的。
我对这套东西是真有感情的。它第一次让"设备的语义"变成了平台级的公共资产：设备在云端定义一次模型，所有应用共享同一份字典。设备接入从"翻译"变成了"注册"。后来的故事很多同行都熟悉了------2018 年 Link Develop、物联网平台更名，2019 年我在 CSDN 写《阿里云的物联网之路》，把这些脉络梳理了一遍。
但也是在这条路上，我先后撞上了这层范式的两堵墙。
第一堵墙是私有化。 前几年我们为某电网做一个抽水蓄能电站项目，生产数据一个字节都不允许出网，整套系统必须私有化部署在业主自己的机房。那一次我们干脆把云端平台整个自建了一遍------从那次交付开始，YFIOs 才真正长成了云边一体的系统。也是在那个项目里我意识到：模型定义在云端，云端在哪，模型的主权就在哪。
第二堵墙是平台退潮。 阿里云物联网平台 2025 年 2 月停止新购、2026 年 7 月对新用户停止服务。一个中心化定义模型的大平台退场，留下的是什么？是几十万台"数据还在传、语义没人认"的设备------物模型还在那个下线了的控制台里，应用却再也查不到那份字典了。云端定义的模型，云停即孤儿。
这两堵墙教会我同一件事：模型中心化在云端，本质上是把最不该托付给别人的东西，托付给了别人。 设备的数据是客户二十年的资产，模型的解释权却系在一家平台的存续上------这个结构在物联网的"慢时代"里，是站不稳的。
第三次跃迁：模型即数据
而最近这一次范式跃迁，我认为是设备接入二十年来最彻底的一场革命------让模型本身变成数据。
什么意思？前两代范式的共同点是：模型是一种"配置"，要么锁在工程文件里，要么锁在云端控制台里，是静态的、需要人去维护的第三类东西。而「模型即数据」把模型变成一条随数据流动的消息：设备（或它身后的网关）自己持有描述文件，上线时把"我是什么、我有哪些变量"作为一条普通的注册消息发上来，云端只是注册中心------收下它、校验它、按版本归档它。
接入动作从"建模"变成了"递交"；变量增删从"工程变更"变成了"一条带版本号的消息"。这不是我的空想，2026 年的业界正在从四个方向同时收敛到这一点：
-
W3C 的 Web of Things（WoT） 今年重新立章，主推 Thing Description 2.0------给每台设备一份标准化的、机器可读的"自我介绍"，甚至开始对接 Physical AI 的用例；
-
OPC 基金会的 UA Edge Translator ，官方教程用一块 200 美元的树莓派，靠上传一份设备描述文件，十分钟就把一台棕地老设备接进 OPC UA 世界------不用人工逐点配置；
-
Schema Registry 的兼容演进规则在数据工程领域已经成熟：加字段带默认值即安全，删字段走两阶段弃用，模型可以像代码一样做版本治理；
-
AAS（资产管理壳） 在欧洲工业界已成生产级基础设施，每个资产一份标准数字铭牌，2026 年 EU 数字产品护照（DPP）开始倒逼所有制造商发布。
四条线索，一个共同点：模型不再是谁的私有配置，而是一份随设备出厂、随数据上网、可注册可检索的公共数据。
打个比方：前两代范式里，设备像一位不识字的工人，进厂要靠班组长（工程师）拿着花名册向厂里登记；「模型即数据」里，设备自带一份身份证，进厂自己刷卡登记，厂里的系统自动认得他是谁、会什么、身体状况如何。花名册式的接入，规模上限是班组长的人数；身份证式的接入，上限才是设备数。
AI 为什么必须站在这一代范式上
有人会问：范式演进是自然规律，为什么说 AI 时代"必须"是模型即数据？
因为 AI 恰好卡在了老范式的死穴上。
这两年 AI coding 的爆发有目共睹，我们也在用 AI 生成组态、生成接入代码。但真用起来就明白：让 AI 生成代码不难，难的是校验它生成得对不对。DORA 2026 的报告把这件事命名为「验证税」------生成越便宜，验证越贵，成本全转移到了审核环节。工业现场更是如此，行业里说得很直白：AI Agent 不能直接写 PLC、必须人在回路；对工控来说，99% 的成功率不叫可靠性，叫灾难。
那 AI 生成什么东西才好验证？答案是声明式的模型文件，而不是命令式的代码。一份物模型定义文件是 JSON：可以被 Schema 校验、可以逐字段 diff、可以回滚、可以在终端模拟器里仿真跑一遍------生成错了，机器和人都看得出来。生成一坨 C# 代码，验证手段就只剩下"读"，正好全额缴纳验证税。
所以 AI 时代的接入链路应该是：AI 读公开的规格（契约）→ 生成声明式模型文件 → 机器校验 + 仿真 → 人确认 → 注册上线。"AI 生成组态，可验证才上线"------AI 的工作止于仿真，上线必须过人这一关。而这条链路的入口，正是一份机器可读的、公开的模型规范。没有它，AI 想帮忙都没有抓手；有了它，AI 的产出天然可仲裁。
这也是我把 YFIOs 的设备数据契约（Data Contract）公开出来的原因：在 AI 时代，协议文档不再是给工程师看的手册，而是给 AI 读的规格面。
工程上，这件事离我们并不远
聊完理念和标准，回到车间地面上。模型即数据落到工程，核心就三件东西：
一是模型帧。 在现有 MQTT 通道上加一个 topic（比如 model/post），retained 消息。网关上线时、模型变更时、断网重连时，把持有的模型定义文件发一帧。遥测帧保持轻量------只带模型版本引用、值、时间戳、质量码；重的语义（单位、量程、说明）留在模型帧里，不随数据重复传输。语义不变的东西，就不该每帧重传。
二是注册中心。 云端收模型帧，做兼容仲裁：加属性带默认值，直接通过；删属性，进弃用窗口，历史数据永不删；改类型，禁止原地改，走新属性加别名迁移。仲裁通过的版本驱动时序库自动物化------以 TDengine 为例，加一个属性就是给超级表 ALTER ADD COLUMN，老消费者读不到新列，不报错、不崩，平滑到无感。
三是网关持有模型。 这一条对我们是天然优势。YFIOs 的 IO 组态、项目模板本来就在网关侧生成和持有------模型即数据不需要设备固件改一行代码，模型帧由网关代发。回看阿里云 TSL 那套"云端定义、下发执行"的结构，正好和它相反：一个是模型主权在云，一个是模型主权在端侧。这不是跟风新概念，是顺着 YFIOs 十几年的纹理长出来的东西。
变量"随时增删"这个需求，最终不是靠一个灵活的数据库实现的，而是靠一套机器可仲裁的演进规则实现的。规则明确了，增删变量就不再是需要工程师周末加班的工程变更，而是注册中心里一条几秒钟处理完的版本消息。
范式会变，数据长存
写到这，想起我当年从 DOS 转 Windows 时的失落------熬夜打磨多年的底层图形能力，仿佛一夜之间没了价值。后来做嵌入式，TinyGUI 轻量图形框架横空出世，才发现旧的积累在新范式里反而成了稀缺品。设备接入这条路也一样：我抄过的每一张点表、对接 Alink 0.7 时踩过的每一个坑、抽水蓄能机房里熬过的每一夜，都在教我同一个道理------
协议是术，模型是道。 二十年里我用的协议换了一茬又一茬：QCPB、Modbus、OPC UA、MQTT......以后还会有新的。术永远在变，但每一次范式跃迁，方向出奇地一致：让设备离数据更近一点，让人工翻译更少一点，让模型的解释权离设备的主人更近一点。点表到标签，是模型从代码里解放出来；标签到物模型，是模型从工程文件里解放出来；物模型到模型即数据，是模型从云端控制台里解放出来------一步步的，都是在给模型松绑。
设备数据是客户二十年的资产，比任何一家平台、任何一种协议都活得长。模型的归宿，终究要回到设备自己身上、回到数据自己身上。平台会停，协议会老，而一份随设备出厂、随数据流动、可校验可追溯的模型------会一直在。
范式会变，数据长存。
相关文档：YFIOs Data Contract 与物模型定义文件规范，见 docs.yfios.net；本文观点的完整工程化版本，见《YFIOs 模型即数据架构设计蓝图 v1.0》。
作者简介：刘洪峰（网名叶帆），北京叶帆易通科技有限公司创始人兼 CEO，多届微软 MVP，阿里云 MVP、华为云 MVP，CSDN 十大 MVB。自 Alink 0.7 起对接阿里云物联网平台，深度参与飞凤平台合作开发；研发 YFIOs 数据组态、YFHMI 画面组态等物联网软硬中间件平台。
相关链接
-
公司官网：www.yfiot.com
-
YFIOs 产品站：www.yfios.net
-
文档站（YFLink 协议 + Data Contract）：docs.yfios.net