DT代码生成这个词我第一次是在一个产线数字孪生项目的复盘会上听到的。当时我们刚把三千多个点位从现场设备里“搬”进系统两个工程师花掉了将近六周其中八成时间在做重复劳动照着 Excel 点位表一行行敲配置、改字段名、对单位、调字节序。所谓“基于AI的DT代码生成”说白了就是把这六周里最枯燥的那部分交给模型让DTDigital Twin数字孪生从数据模型定义、采集适配配置到上层绑定的一整套代码从结构化资料里自动长出来。它不是一个能一键生成整套孪生系统的魔法按钮而是一条“资料清洗—中间表示—受约束生成—自动校验—人工兜底”的流水线。这篇东西适合正在做设备接入、工业数据平台、三维可视化绑定的同行看也适合刚接触大模型落地、想找一个边界清晰场景的开发者参考。踩过的坑我都写进去了包括几个当时查了两天才定位到的问题。1. DT代码生成到底在生成什么拆开一个数字孪生体的四层代码1.1 那个让我决定折腾这件事的六周先把这个项目的痛点讲透不然没法说清楚为什么要用模型。那条产线有十一台设备包括两台注塑机、三台机械手、一套视觉检测、四台辅助设备。甲方给的资料是十一份 Excel 点位表格式各不相同有的第一行是大标题真正的表头在第三行有的把地址写成40001这种带偏移的写法有的写成0x0000单位一栏一半写着“℃”一半写着“摄氏度”还有两台设备的压力单位是 bar另外两台是 MPa。我们当时的做法是两个人分工一个人负责数据模型定义JSON 或 YAML 形式的属性、事件、服务另一个人负责采集适配协议地址、数据类型、采集周期、缩放因子。六周里有大量的时间花在互相校对以及发现“原来这台设备的地址是从 1 开始数的”这种返工上。真正让我下定决心的不是“AI 好厉害”这种情绪而是我发现这活儿的结构极其规整输入是表格中间是一份结构化的点位定义输出是高度模板化的代码。规整、重复、有明确校验标准——这三条凑齐了就是模型最该接手的场景。反过来说如果你手上的活儿每次都长得不一样、判断依据靠经验、错了也没法自动检测那拿模型硬套基本是给自己找麻烦。1.2 四层代码只有两层适合交给模型我们把一个孪生体拆成四层先说清楚每层生成的是什么后面才好谈边界。层级生成物特征适合模型接手的程度数据模型层属性、事件、服务的定义文件YAML/JSON结构规整字段名可枚举高几乎可以全自动采集适配层协议地址映射、数据类型转换、缩放与质量码强规则但对字节序、偏移极敏感中高必须强校验同步与计算层点位到模型属性的映射、聚合、阈值告警有工艺语义需要人确认中建议只生成骨架应用与绑定层前端组件配置、三维构件与属性绑定、API 路由依赖具体前端框架和场景约定低到中建议模板渲染为主数据模型层和采集适配层是收益最大、风险最可控的两块。为什么因为这两层的正确性可以被机械验证——字段是不是在 schema 里、地址是不是落在设备地址空间内、数据类型和寄存器宽度是不是匹配。同步与计算层涉及工艺比如“这台机器的综合效率怎么算”这种知识在老师傅脑子里模型编出来的公式看着像模像样但大概率不对。应用绑定层则高度依赖你们自己的前端约定除非你有一批现成的样例可检索否则让模型自由发挥出来的配置基本没法用。1.3 一句话划清边界模型做决策模板做输出这是我在第二个迭代才想明白的事也是整篇文章最想传达的一个观点。第一版我们让模型直接吐 Python 采集代码结果生成的东西能跑但风格五花八门有的用同步阻塞、有的自己造了个重试装饰器、有的把日志打成 print代码评审根本没法过。后来改成模型只输出一份结构化的“决策结果”哪些点位、什么类型、什么地址、什么缩放、什么语义标签真正的代码由模板引擎渲染。这个改动带来的直接好处是模型的输出空间从“任意文本”收缩成了“受 schema 约束的 JSON”错了能立刻定位到具体字段而不是在一百行代码里靠肉眼找。注意凡是能用结构化中间结果表达的就不要让模型直接写代码。模型的自由度每增加一档你的校验成本就要增加三档。2. 输入决定上限把Excel点位表洗成模型能确认的中间表示2.1 直接丢原始表格给大模型是最贵的偷懒我们试过最省事的做法把 Excel 转成 CSV整段塞进提示词让模型输出数据模型 YAML。结果是三个阶段性的灾难。第一阶段模型很热心地“帮我们补全”了一些它认为应该有的字段比如给温度点位加了个alarm_high数值是它自己猜的 80。第二阶段面对 3000 行的表上下文放不下模型开始只处理前一部分后面直接编。第三阶段同一个点位在不同批次生成里名字不一样temp_inlet和inlet_temp混着来导致后面的映射全乱。根本原因在于原始表格里混杂了三类信息事实地址、数据类型、约定字段命名、单位写法、噪声合并单元格、多余的空行、批注。模型没法区分这三者它会一视同仁地当成“需要理解的内容”。所以正确顺序是先做清洗把事实抽干净把约定固化成规则把噪声扔掉剩下的才喂给模型。2.2 三级清洗字段归一、单位对齐、语义打标第一级是字段归一。把十一份表的表头映射到一套标准列名上这一步我建议手动配映射表不要交给模型猜。因为表头就那么几十种人工配一次能用很久而且错了能立刻发现。我们的标准列是point_name、raw_address、data_type、unit、range_min、range_max、sample_ms、remark。第二级是单位对齐。建立一个单位字典把“摄氏度”“℃”“C”统一成Cel把“兆帕”“MPa”“mpa”统一成MPa同时记录每个点位的工程换算系数。这里有个细节容易被忽略单位统一和量程换算是两件事。单位统一只是改标签量程换算要改数据。比如原始量程是 0–1.6 MPa我们内部统一用 kPa那缩放系数就是 1000这个系数必须显式记录在中间结果里不能指望下游代码去猜。第三级是语义打标也是最值钱的一步。给每个点位打上一个稳定的语义标签比如Temperature.Inlet、Pressure.Hydraulic、State.Running这样上层做聚合、告警、看板的时候才能跨设备复用逻辑。打标可以半自动先按点位名的关键词规则打一遍命中率大概六七成剩下的交给模型让它从一份固定的标签清单里选而不是自由生成。2.3 我们最后固化的IR结构清洗完的产物我把它叫 IR中间表示。这个东西是整个流水线的地基值得认真设计一次。下面是我们最后稳定下来的精简版本字段不多但够用{ device: { device_id: LINE_A_PRESS_01, device_type: injection_machine, protocol: modbus_tcp, endpoint: {host: 10.0.0.21, port: 502, unit_id: 1}, address_base: 1, byte_order: big }, points: [ { point_id: barrel_temp_1, semantic_tag: Temperature.Barrel, source: {area: holding_register, address: 40001, width: 1}, data_type: int16, unit: Cel, scale: 0.1, offset: 0, range: {min: 0, max: 450}, sample_ms: 1000, quality_rule: range_check }, { point_id: inject_pressure, semantic_tag: Pressure.Injection, source: {area: holding_register, address: 40010, width: 2}, data_type: float32, word_order: low_high, unit: MPa, scale: 1.0, offset: 0, range: {min: 0, max: 200}, sample_ms: 500, quality_rule: range_check } ], relations: [ {type: feeds, from: LINE_A_PRESS_01, to: LINE_A_ROBOT_01} ] }这份 IR 有两个设计取舍值得说。一是把address_base放在设备层而不是点位层因为一台设备内部地址基数是一致的放到点位层会产生大量冗余也容易改漏。二是显式保留word_order32 位浮点在某些设备上是高字在前某些是低字在前这个字段不写清楚后面一定会有人踩坑而这类错误表现为“数值乱跳”排查成本极高。3. 生成链路的四个关键环节检索、决策、渲染、断言3.1 先检索相似设备模板再让模型做局部决策纯靠提示词让模型从头理解一台注塑机效果远不如给它看三台已经做好的同类设备配置。我们的做法是建一个小型的模板库按device_type 关键点位特征做向里检索取出最相似的 2–3 份历史配置作为少样本示例。这个库不需要很花哨一开始就是几十个 JSON 文件加一个简单的向量索引甚至先用关键词匹配都能跑。检索这一步的价值在于把大部分决策变成“照抄加微调”。模型看到一份同类设备的完整配置它需要做的只是替换设备号、调整地址段、增删个别点位。这比让它从零发明字段名要稳得多。实测下来加了检索之后字段名不一致的问题从“经常出现”降到“偶尔出现”而且出现的那种基本是我们模板库里没有的新设备类型。检索的匹配键要选对。我们一开始只按设备类型匹配结果把一台小型机的配置拿去给了大型机点位数量差了五倍模型开始瞎编缺失的点位。后来匹配键改成“设备类型 点位数区间 关键语义标签集合”效果明显好了。3.2 采集适配层的生成细节最容易翻车采集适配层要处理的东西比看起来多得多。我在实践里总结出四个必查项每一个都曾经让我们返工寄存器宽度与数据类型的匹配。int16占 1 个寄存器int32和float32占 2 个float64占 4 个。这不只是生成时要写对width还要检查地址有没有“越界重叠”——如果40010是 float32 占了两格那下一个点位就不能从40011开始。字节序与字序是两回事。字节序是寄存器内部的顺序字序是两个寄存器之间的顺序。这两个都错了数值不对只错一个数值可能是另一个完全无关的数。我们要求 IR 里两者都显式写出生成时禁止使用默认值。缩放与偏移的表达顺序。是(raw * scale) offset还是(raw offset) * scale不同平台的约定不一样。这个必须在生成前定死写进模板注释里不然接手的人根本看不出来。质量码的判定逻辑。点位超量程、通讯超时、设备返回异常码这三种情况都应该产生“数据不可信”的质量位。很多生成出来的配置只做了超量程判断丢包的时候值会保持上一次的数字看板上看着一切正常实际上数据早就停了。这个坑我们踩过后面会详细说。# 采集适配层的渲染模板片段Jinja2 风格示意 POINT_DEF - point_id: {{ p.point_id }} tag: {{ p.semantic_tag }} read: func: {{ func_map[p.source.area] }} address: {{ p.source.address - device.address_base }} count: {{ p.source.width }} decode: type: {{ p.data_type }} byte_order: {{ device.byte_order }} {%- if p.word_order %} word_order: {{ p.word_order }} {%- endif %} scale: {{ p.scale }} offset: {{ p.offset }} quality: rule: {{ p.quality_rule }} range: [{{ p.range.min }}, {{ p.range.max }}] 注意模板里那个address - device.address_base。这块逻辑绝对不能交给模型心算也不要指望它每次都算对。把偏移修正放进模板是成本最低的正确性保障。3.3 三维绑定与前端配置的生成边界前端绑定这块我建议各位保守一点。我们最初的设想是根据设备类型自动生成三维构件和属性的绑定关系实际上这条路走得很痛苦。原因是三维模型里的构件命名、层级结构、坐标约定全都是项目现场临时定的没有跨项目通用性。后来我们收缩了范围只让模型生成两样东西一是属性面板的字段配置哪些属性显示、分组、单位、精度、是否只读二是告警列表的列定义。这两样结构简单、可枚举生成出来人扫一眼就知道对不对。三维构件绑定改成半自动先生成一份候选绑定表列出“构件名 → 可能对应的点位”由人来确认。这份候选表的价值在于它能覆盖掉七八成的明显对应关系人只需要处理剩下的疑难杂症比从零开始点选快得多。3.4 三层断言Schema、语义、冒烟生成完不校验等于没生成。我们的校验分三层逐层收紧。第一层是结构校验。用 JSON Schema 检查字段有没有缺、类型对不对、枚举值在不在范围内。这一层能把绝大部分“模型自由发挥”挡在门外。第二层是语义断言。这层是手写的规则比如所有点位的地址区间不能重叠scale不能为 0range.min必须小于range.max同一个设备内point_id不能重复semantic_tag必须来自受控词表。这一层抓的是“结构合法但业务上荒谬”的问题比如模型给你生成一个量程 0 到 0 的温度点位。第三层是冒烟测试。拿生成的配置去连一台模拟设备我们用协议模拟器起一个本地服务填上同样的地址和数值读一遍看数值是不是落在量程内、质量码是不是正常。这一层最慢但也最能抓住隐性错误。我们后来把它做成了只跑前 20 个点位的小样本几十秒就能出结果。提示三层校验的顺序不要反。先跑便宜的结构再跑贵的冒烟。把冒烟放前面一天也跑不了几轮。4. 把模型关进笼子Schema约束、少样本挑选与失败回灌4.1 用JSON Schema和AST做双重闸门Schema 约束的写法有几个实操要点。第一尽量用enum收敛取值范围比如data_type只允许int16/int32/float32/float64/bool这几项模型就没法发明double或者real。第二用required明确必填尤其是word_order、scale这种容易被省略的字段。第三用additionalProperties: false禁止模型加戏这一条非常关键我们第一版没加结果模型给我们塞了一堆description、note、alias之类的字段把后续解析搞得很乱。如果需要模型生成代码而不是配置比如某些平台只接受 Python 脚本形式的采集插件那就要加上 AST 校验。做法是解析生成的代码遍历语法树检查它有没有引入白名单之外的模块、有没有调用禁止的函数、有没有动态执行字符串。这一层听着重其实用几十行代码就能实现比事后人工评审便宜。import ast ALLOWED_IMPORTS {struct, time, logging, typing} BANNED_CALLS {eval, exec, compile, __import__} def check_generated_code(src: str) - list[str]: problems [] tree ast.parse(src) for node in ast.walk(tree): if isinstance(node, ast.Import): for alias in node.names: if alias.name.split(.)[0] not in ALLOWED_IMPORTS: problems.append(f非法导入: {alias.name}) elif isinstance(node, ast.Call): fn node.func name getattr(fn, id, None) or getattr(fn, attr, None) if name in BANNED_CALLS: problems.append(f禁用调用: {name}) return problems4.2 少样本示例不是越多越好这一点我吃过亏。一开始觉得示例多点总没错一次塞了八个历史配置进提示词结果模型开始把不同设备的点位混在一起生成了一份“缝合怪”配置。后来测下来两到三个高度相似的示例效果最好。相似度比数量重要得多。挑选示例还有个小技巧优先选那些“结构上有变化”的示例比如一份点位很密集、一份有很多跨类型点位这样模型能见到边界情况。如果三份示例长得几乎一样对模型的帮助还不如只放一份。另外示例里的字段值要真实感足够。我们曾经为了脱敏把示例里的设备号全改成DEV_001结果模型生成的配置里也全是DEV_001还理直气壮地说“参考了示例中的命名约定”。所以示例里要有真实形态的 ID只要不是敏感信息就行。4.3 编译错误回灌与重试的止损线生成失败是常态关键是失败之后怎么办。我们的做法是把校验错误信息结构化回灌给模型再试一次。比如“第 12 个点位地址 40010 与第 11 个点位 40011 冲突”这条信息比“生成有误”有用一百倍。但重试必须有止损线。我们的设置是最多两轮两轮还不行就走人工。原因很实际模型在同一个错误上反复摔跤的时候往往说明是输入信息本身有问题比如原始表格里那个地址就是错的再试十轮也没用只是浪费时间和额度。人工介入的时候我们会把两轮的错误记录一并附上人一看就知道卡在哪。5. 五个真实翻车现场与它们的排查路径5.1 单位缩放错位数据看着正常曲线缓慢漂移这个坑最阴。现场投运三天后发现注塑机的料筒温度曲线和其他同型号机器比总是高一点点而且越跑差距越大。一开始怀疑是传感器老化换了探头还是一样。排查路径是先用模拟器给设备灌入固定值 100原始寄存器值看平台显示多少。显示 10.0说明缩放系数多了一个 0.1。回头看 IR那台设备的点位表里单位写的是“0.1℃”清洗脚本把“0.1”当成了单位文本同时又保留了原文里的scale: 1两个信息打架最后合成的时候乘了两次。修复方案是清洗阶段加一条断言如果单位里出现数字就单独抽出来作为缩放系数并且把这条记录标记为“需人工确认”。这条断言后面又抓出了七八个类似情况全都藏在“单位”和“量程”两列的备注里。5.2 模型自造字段名Schema校验过了运行时炸了有一次生成一批配置Schema 全过冒烟也过了但上线之后部分点位读不到。查了半天发现模型给某些点位生成了semantic_tag之外还自造了一个alias_tag而下游的绑定程序读的是alias_tag优先——这个逻辑是我们自己写的本意是支持别名结果被模型的“好心”激活了。教训是Schema 里必须禁止额外字段同时下游代码不要设计“多个字段任选其一”的模糊读取逻辑。5.3 寄存器地址重叠批量生成时的静默覆盖批量生成最容易出的问题是地址冲突。我们有一次生成了四百多个点位其中两组设备的地址段有交叠原因是那两台设备用了不同的地址基数一台从 0 开始一台从 1 开始而清洗脚本把两台设备的点位塞进了同一个批次基数信息丢了。生成出来看着没问题采集的时候后写的点位覆盖了前面的导致十几个温度点位显示同一个数值。排查方法很土但有效把所有点位的[address, address width)区间画出来排序看有没有交叠。这个检查后来写进了语义断言成了每次生成的标配。5.4 长表截断第1800行之后的数据凭空消失三千个点位一次性提交超出上下文长度模型收到了截断的信号但没有明确报错它只是“礼貌地”少生成了一部分。最坑的是生成的 JSON 结构完整——它把最后几个点位补全了中间那段直接跳过去了。人眼扫一遍根本发现不了因为点位名都是连续的。解决办法是分批 对账。按设备分批每批不超过 200 个点位生成完之后用一份“点位清单指纹”点位 ID 的哈希集合对账应到多少、实到多少缺一个都报警。这个对账脚本二十行代码救了我们不止一次。5.5 代码“看起来能跑”缺了时间戳解析生成的采集插件在模拟器上跑得好好的接真机之后所有点位的时间戳都成了 1970 年。原因是那台设备返回的报文里时间戳是本地时间格式的字符串需要按设备时区解析而模型按“通用做法”生成了 Unix 时间戳解析。这类问题的共性是模型的知识是通用的现场的约定是特殊的两者的差异不在语法层面在语义层面静态检查抓不到。我们的应对是给每类协议维护一份“现场约定清单”里面记着时间戳格式、心跳间隔、异常码含义这些容易被通用做法带偏的点。生成时把清单作为约束条件传进去生成后由人快速对照一遍。6. 怎么衡量这套东西到底有没有用评估集与落地节奏6.1 四个指标看生成质量不做量化很容易陷入“感觉快了”的自我安慰。我们最后盯的是这四个指标定义我们的实测参考区间字段级准确率生成字段与人工基线一致的比例90% 上下语义标签拖后腿地址正确率地址、宽度、字序全对的比例95% 以上前提是 IR 干净一次通过率三层校验一次全过的批次占比六到七成随模板库增长提升人工修正行数评审时人改动的字段数从最初的三百多降到几十第一版我们最看重“生成速度”后来发现速度根本不是瓶颈——评审和返工才是。人工修正行数这个指标虽然土但最能反映真实收益。当它降到几十行的时候说明流程真的顺了。6.2 先从一条三十个点位的窄链路开始如果有人想复制这套东西我的建议是别一上来就搞全厂。挑一台设备、三十个点位、一种协议把清洗、IR、生成、校验、评审整条链路跑通跑通的标准是“生成的配置不改一行就能上线采集”。这条窄链路的投入大概是一到两周但它能暴露出你所有流程设计上的问题。窄链路的另一个好处是能建立第一批金标准样本。这三十个点位的正确配置就是你的第一个模板后面所有同类设备都能从它这里检索。我们的模板库是这么长起来的先有一台然后三台然后十几台到后面新设备接入的时候检索出来的示例已经非常贴脸了。6.3 人工修正要沉淀成回归用例这条是我个人最看重的经验。每次评审时人改了什么都要记下来然后把这些修正反向变成校验规则或者回归用例。比如人发现“这台设备的压力点位需要保留两位小数”那就把精度要求写进对应设备类型的规则里比如人改了某个地址那这个点位的正确值就进回归集下次生成必须一致。这么做的复利效应很明显三个月之后我们的语义断言从二十几条长到了一百多条每一条都是踩过的坑。新人接手的时候不用听我讲历史跑一遍回归集就知道哪些地方不能碰。最后分享一个实操里的小体会。这套东西真正的价值不在于省掉多少敲键盘的时间而在于它逼着我们把“点位表里到底哪些信息是事实、哪些是约定、哪些是噪声”这件事彻底想清楚了。在没有AI的时候这些混乱被人的经验和加班消化掉了看不见一旦要交给机器所有模糊地带都必须显式化。我们做完这一轮之后即使把AI拿掉接入流程本身也比以前规范得多——这可能是比生成速度更值钱的收获。
DT代码生成这个词我第一次是在一个产线数字孪生项目的复盘会上听到的。当时我们刚把三千多个点位从现场设备里“搬”进系统两个工程师花掉了将近六周其中八成时间在做重复劳动照着 Excel 点位表一行行敲配置、改字段名、对单位、调字节序。所谓“基于AI的DT代码生成”说白了就是把这六周里最枯燥的那部分交给模型让DTDigital Twin数字孪生从数据模型定义、采集适配配置到上层绑定的一整套代码从结构化资料里自动长出来。它不是一个能一键生成整套孪生系统的魔法按钮而是一条“资料清洗—中间表示—受约束生成—自动校验—人工兜底”的流水线。这篇东西适合正在做设备接入、工业数据平台、三维可视化绑定的同行看也适合刚接触大模型落地、想找一个边界清晰场景的开发者参考。踩过的坑我都写进去了包括几个当时查了两天才定位到的问题。1. DT代码生成到底在生成什么拆开一个数字孪生体的四层代码1.1 那个让我决定折腾这件事的六周先把这个项目的痛点讲透不然没法说清楚为什么要用模型。那条产线有十一台设备包括两台注塑机、三台机械手、一套视觉检测、四台辅助设备。甲方给的资料是十一份 Excel 点位表格式各不相同有的第一行是大标题真正的表头在第三行有的把地址写成40001这种带偏移的写法有的写成0x0000单位一栏一半写着“℃”一半写着“摄氏度”还有两台设备的压力单位是 bar另外两台是 MPa。我们当时的做法是两个人分工一个人负责数据模型定义JSON 或 YAML 形式的属性、事件、服务另一个人负责采集适配协议地址、数据类型、采集周期、缩放因子。六周里有大量的时间花在互相校对以及发现“原来这台设备的地址是从 1 开始数的”这种返工上。真正让我下定决心的不是“AI 好厉害”这种情绪而是我发现这活儿的结构极其规整输入是表格中间是一份结构化的点位定义输出是高度模板化的代码。规整、重复、有明确校验标准——这三条凑齐了就是模型最该接手的场景。反过来说如果你手上的活儿每次都长得不一样、判断依据靠经验、错了也没法自动检测那拿模型硬套基本是给自己找麻烦。1.2 四层代码只有两层适合交给模型我们把一个孪生体拆成四层先说清楚每层生成的是什么后面才好谈边界。层级生成物特征适合模型接手的程度数据模型层属性、事件、服务的定义文件YAML/JSON结构规整字段名可枚举高几乎可以全自动采集适配层协议地址映射、数据类型转换、缩放与质量码强规则但对字节序、偏移极敏感中高必须强校验同步与计算层点位到模型属性的映射、聚合、阈值告警有工艺语义需要人确认中建议只生成骨架应用与绑定层前端组件配置、三维构件与属性绑定、API 路由依赖具体前端框架和场景约定低到中建议模板渲染为主数据模型层和采集适配层是收益最大、风险最可控的两块。为什么因为这两层的正确性可以被机械验证——字段是不是在 schema 里、地址是不是落在设备地址空间内、数据类型和寄存器宽度是不是匹配。同步与计算层涉及工艺比如“这台机器的综合效率怎么算”这种知识在老师傅脑子里模型编出来的公式看着像模像样但大概率不对。应用绑定层则高度依赖你们自己的前端约定除非你有一批现成的样例可检索否则让模型自由发挥出来的配置基本没法用。1.3 一句话划清边界模型做决策模板做输出这是我在第二个迭代才想明白的事也是整篇文章最想传达的一个观点。第一版我们让模型直接吐 Python 采集代码结果生成的东西能跑但风格五花八门有的用同步阻塞、有的自己造了个重试装饰器、有的把日志打成 print代码评审根本没法过。后来改成模型只输出一份结构化的“决策结果”哪些点位、什么类型、什么地址、什么缩放、什么语义标签真正的代码由模板引擎渲染。这个改动带来的直接好处是模型的输出空间从“任意文本”收缩成了“受 schema 约束的 JSON”错了能立刻定位到具体字段而不是在一百行代码里靠肉眼找。注意凡是能用结构化中间结果表达的就不要让模型直接写代码。模型的自由度每增加一档你的校验成本就要增加三档。2. 输入决定上限把Excel点位表洗成模型能确认的中间表示2.1 直接丢原始表格给大模型是最贵的偷懒我们试过最省事的做法把 Excel 转成 CSV整段塞进提示词让模型输出数据模型 YAML。结果是三个阶段性的灾难。第一阶段模型很热心地“帮我们补全”了一些它认为应该有的字段比如给温度点位加了个alarm_high数值是它自己猜的 80。第二阶段面对 3000 行的表上下文放不下模型开始只处理前一部分后面直接编。第三阶段同一个点位在不同批次生成里名字不一样temp_inlet和inlet_temp混着来导致后面的映射全乱。根本原因在于原始表格里混杂了三类信息事实地址、数据类型、约定字段命名、单位写法、噪声合并单元格、多余的空行、批注。模型没法区分这三者它会一视同仁地当成“需要理解的内容”。所以正确顺序是先做清洗把事实抽干净把约定固化成规则把噪声扔掉剩下的才喂给模型。2.2 三级清洗字段归一、单位对齐、语义打标第一级是字段归一。把十一份表的表头映射到一套标准列名上这一步我建议手动配映射表不要交给模型猜。因为表头就那么几十种人工配一次能用很久而且错了能立刻发现。我们的标准列是point_name、raw_address、data_type、unit、range_min、range_max、sample_ms、remark。第二级是单位对齐。建立一个单位字典把“摄氏度”“℃”“C”统一成Cel把“兆帕”“MPa”“mpa”统一成MPa同时记录每个点位的工程换算系数。这里有个细节容易被忽略单位统一和量程换算是两件事。单位统一只是改标签量程换算要改数据。比如原始量程是 0–1.6 MPa我们内部统一用 kPa那缩放系数就是 1000这个系数必须显式记录在中间结果里不能指望下游代码去猜。第三级是语义打标也是最值钱的一步。给每个点位打上一个稳定的语义标签比如Temperature.Inlet、Pressure.Hydraulic、State.Running这样上层做聚合、告警、看板的时候才能跨设备复用逻辑。打标可以半自动先按点位名的关键词规则打一遍命中率大概六七成剩下的交给模型让它从一份固定的标签清单里选而不是自由生成。2.3 我们最后固化的IR结构清洗完的产物我把它叫 IR中间表示。这个东西是整个流水线的地基值得认真设计一次。下面是我们最后稳定下来的精简版本字段不多但够用{ device: { device_id: LINE_A_PRESS_01, device_type: injection_machine, protocol: modbus_tcp, endpoint: {host: 10.0.0.21, port: 502, unit_id: 1}, address_base: 1, byte_order: big }, points: [ { point_id: barrel_temp_1, semantic_tag: Temperature.Barrel, source: {area: holding_register, address: 40001, width: 1}, data_type: int16, unit: Cel, scale: 0.1, offset: 0, range: {min: 0, max: 450}, sample_ms: 1000, quality_rule: range_check }, { point_id: inject_pressure, semantic_tag: Pressure.Injection, source: {area: holding_register, address: 40010, width: 2}, data_type: float32, word_order: low_high, unit: MPa, scale: 1.0, offset: 0, range: {min: 0, max: 200}, sample_ms: 500, quality_rule: range_check } ], relations: [ {type: feeds, from: LINE_A_PRESS_01, to: LINE_A_ROBOT_01} ] }这份 IR 有两个设计取舍值得说。一是把address_base放在设备层而不是点位层因为一台设备内部地址基数是一致的放到点位层会产生大量冗余也容易改漏。二是显式保留word_order32 位浮点在某些设备上是高字在前某些是低字在前这个字段不写清楚后面一定会有人踩坑而这类错误表现为“数值乱跳”排查成本极高。3. 生成链路的四个关键环节检索、决策、渲染、断言3.1 先检索相似设备模板再让模型做局部决策纯靠提示词让模型从头理解一台注塑机效果远不如给它看三台已经做好的同类设备配置。我们的做法是建一个小型的模板库按device_type 关键点位特征做向里检索取出最相似的 2–3 份历史配置作为少样本示例。这个库不需要很花哨一开始就是几十个 JSON 文件加一个简单的向量索引甚至先用关键词匹配都能跑。检索这一步的价值在于把大部分决策变成“照抄加微调”。模型看到一份同类设备的完整配置它需要做的只是替换设备号、调整地址段、增删个别点位。这比让它从零发明字段名要稳得多。实测下来加了检索之后字段名不一致的问题从“经常出现”降到“偶尔出现”而且出现的那种基本是我们模板库里没有的新设备类型。检索的匹配键要选对。我们一开始只按设备类型匹配结果把一台小型机的配置拿去给了大型机点位数量差了五倍模型开始瞎编缺失的点位。后来匹配键改成“设备类型 点位数区间 关键语义标签集合”效果明显好了。3.2 采集适配层的生成细节最容易翻车采集适配层要处理的东西比看起来多得多。我在实践里总结出四个必查项每一个都曾经让我们返工寄存器宽度与数据类型的匹配。int16占 1 个寄存器int32和float32占 2 个float64占 4 个。这不只是生成时要写对width还要检查地址有没有“越界重叠”——如果40010是 float32 占了两格那下一个点位就不能从40011开始。字节序与字序是两回事。字节序是寄存器内部的顺序字序是两个寄存器之间的顺序。这两个都错了数值不对只错一个数值可能是另一个完全无关的数。我们要求 IR 里两者都显式写出生成时禁止使用默认值。缩放与偏移的表达顺序。是(raw * scale) offset还是(raw offset) * scale不同平台的约定不一样。这个必须在生成前定死写进模板注释里不然接手的人根本看不出来。质量码的判定逻辑。点位超量程、通讯超时、设备返回异常码这三种情况都应该产生“数据不可信”的质量位。很多生成出来的配置只做了超量程判断丢包的时候值会保持上一次的数字看板上看着一切正常实际上数据早就停了。这个坑我们踩过后面会详细说。# 采集适配层的渲染模板片段Jinja2 风格示意 POINT_DEF - point_id: {{ p.point_id }} tag: {{ p.semantic_tag }} read: func: {{ func_map[p.source.area] }} address: {{ p.source.address - device.address_base }} count: {{ p.source.width }} decode: type: {{ p.data_type }} byte_order: {{ device.byte_order }} {%- if p.word_order %} word_order: {{ p.word_order }} {%- endif %} scale: {{ p.scale }} offset: {{ p.offset }} quality: rule: {{ p.quality_rule }} range: [{{ p.range.min }}, {{ p.range.max }}] 注意模板里那个address - device.address_base。这块逻辑绝对不能交给模型心算也不要指望它每次都算对。把偏移修正放进模板是成本最低的正确性保障。3.3 三维绑定与前端配置的生成边界前端绑定这块我建议各位保守一点。我们最初的设想是根据设备类型自动生成三维构件和属性的绑定关系实际上这条路走得很痛苦。原因是三维模型里的构件命名、层级结构、坐标约定全都是项目现场临时定的没有跨项目通用性。后来我们收缩了范围只让模型生成两样东西一是属性面板的字段配置哪些属性显示、分组、单位、精度、是否只读二是告警列表的列定义。这两样结构简单、可枚举生成出来人扫一眼就知道对不对。三维构件绑定改成半自动先生成一份候选绑定表列出“构件名 → 可能对应的点位”由人来确认。这份候选表的价值在于它能覆盖掉七八成的明显对应关系人只需要处理剩下的疑难杂症比从零开始点选快得多。3.4 三层断言Schema、语义、冒烟生成完不校验等于没生成。我们的校验分三层逐层收紧。第一层是结构校验。用 JSON Schema 检查字段有没有缺、类型对不对、枚举值在不在范围内。这一层能把绝大部分“模型自由发挥”挡在门外。第二层是语义断言。这层是手写的规则比如所有点位的地址区间不能重叠scale不能为 0range.min必须小于range.max同一个设备内point_id不能重复semantic_tag必须来自受控词表。这一层抓的是“结构合法但业务上荒谬”的问题比如模型给你生成一个量程 0 到 0 的温度点位。第三层是冒烟测试。拿生成的配置去连一台模拟设备我们用协议模拟器起一个本地服务填上同样的地址和数值读一遍看数值是不是落在量程内、质量码是不是正常。这一层最慢但也最能抓住隐性错误。我们后来把它做成了只跑前 20 个点位的小样本几十秒就能出结果。提示三层校验的顺序不要反。先跑便宜的结构再跑贵的冒烟。把冒烟放前面一天也跑不了几轮。4. 把模型关进笼子Schema约束、少样本挑选与失败回灌4.1 用JSON Schema和AST做双重闸门Schema 约束的写法有几个实操要点。第一尽量用enum收敛取值范围比如data_type只允许int16/int32/float32/float64/bool这几项模型就没法发明double或者real。第二用required明确必填尤其是word_order、scale这种容易被省略的字段。第三用additionalProperties: false禁止模型加戏这一条非常关键我们第一版没加结果模型给我们塞了一堆description、note、alias之类的字段把后续解析搞得很乱。如果需要模型生成代码而不是配置比如某些平台只接受 Python 脚本形式的采集插件那就要加上 AST 校验。做法是解析生成的代码遍历语法树检查它有没有引入白名单之外的模块、有没有调用禁止的函数、有没有动态执行字符串。这一层听着重其实用几十行代码就能实现比事后人工评审便宜。import ast ALLOWED_IMPORTS {struct, time, logging, typing} BANNED_CALLS {eval, exec, compile, __import__} def check_generated_code(src: str) - list[str]: problems [] tree ast.parse(src) for node in ast.walk(tree): if isinstance(node, ast.Import): for alias in node.names: if alias.name.split(.)[0] not in ALLOWED_IMPORTS: problems.append(f非法导入: {alias.name}) elif isinstance(node, ast.Call): fn node.func name getattr(fn, id, None) or getattr(fn, attr, None) if name in BANNED_CALLS: problems.append(f禁用调用: {name}) return problems4.2 少样本示例不是越多越好这一点我吃过亏。一开始觉得示例多点总没错一次塞了八个历史配置进提示词结果模型开始把不同设备的点位混在一起生成了一份“缝合怪”配置。后来测下来两到三个高度相似的示例效果最好。相似度比数量重要得多。挑选示例还有个小技巧优先选那些“结构上有变化”的示例比如一份点位很密集、一份有很多跨类型点位这样模型能见到边界情况。如果三份示例长得几乎一样对模型的帮助还不如只放一份。另外示例里的字段值要真实感足够。我们曾经为了脱敏把示例里的设备号全改成DEV_001结果模型生成的配置里也全是DEV_001还理直气壮地说“参考了示例中的命名约定”。所以示例里要有真实形态的 ID只要不是敏感信息就行。4.3 编译错误回灌与重试的止损线生成失败是常态关键是失败之后怎么办。我们的做法是把校验错误信息结构化回灌给模型再试一次。比如“第 12 个点位地址 40010 与第 11 个点位 40011 冲突”这条信息比“生成有误”有用一百倍。但重试必须有止损线。我们的设置是最多两轮两轮还不行就走人工。原因很实际模型在同一个错误上反复摔跤的时候往往说明是输入信息本身有问题比如原始表格里那个地址就是错的再试十轮也没用只是浪费时间和额度。人工介入的时候我们会把两轮的错误记录一并附上人一看就知道卡在哪。5. 五个真实翻车现场与它们的排查路径5.1 单位缩放错位数据看着正常曲线缓慢漂移这个坑最阴。现场投运三天后发现注塑机的料筒温度曲线和其他同型号机器比总是高一点点而且越跑差距越大。一开始怀疑是传感器老化换了探头还是一样。排查路径是先用模拟器给设备灌入固定值 100原始寄存器值看平台显示多少。显示 10.0说明缩放系数多了一个 0.1。回头看 IR那台设备的点位表里单位写的是“0.1℃”清洗脚本把“0.1”当成了单位文本同时又保留了原文里的scale: 1两个信息打架最后合成的时候乘了两次。修复方案是清洗阶段加一条断言如果单位里出现数字就单独抽出来作为缩放系数并且把这条记录标记为“需人工确认”。这条断言后面又抓出了七八个类似情况全都藏在“单位”和“量程”两列的备注里。5.2 模型自造字段名Schema校验过了运行时炸了有一次生成一批配置Schema 全过冒烟也过了但上线之后部分点位读不到。查了半天发现模型给某些点位生成了semantic_tag之外还自造了一个alias_tag而下游的绑定程序读的是alias_tag优先——这个逻辑是我们自己写的本意是支持别名结果被模型的“好心”激活了。教训是Schema 里必须禁止额外字段同时下游代码不要设计“多个字段任选其一”的模糊读取逻辑。5.3 寄存器地址重叠批量生成时的静默覆盖批量生成最容易出的问题是地址冲突。我们有一次生成了四百多个点位其中两组设备的地址段有交叠原因是那两台设备用了不同的地址基数一台从 0 开始一台从 1 开始而清洗脚本把两台设备的点位塞进了同一个批次基数信息丢了。生成出来看着没问题采集的时候后写的点位覆盖了前面的导致十几个温度点位显示同一个数值。排查方法很土但有效把所有点位的[address, address width)区间画出来排序看有没有交叠。这个检查后来写进了语义断言成了每次生成的标配。5.4 长表截断第1800行之后的数据凭空消失三千个点位一次性提交超出上下文长度模型收到了截断的信号但没有明确报错它只是“礼貌地”少生成了一部分。最坑的是生成的 JSON 结构完整——它把最后几个点位补全了中间那段直接跳过去了。人眼扫一遍根本发现不了因为点位名都是连续的。解决办法是分批 对账。按设备分批每批不超过 200 个点位生成完之后用一份“点位清单指纹”点位 ID 的哈希集合对账应到多少、实到多少缺一个都报警。这个对账脚本二十行代码救了我们不止一次。5.5 代码“看起来能跑”缺了时间戳解析生成的采集插件在模拟器上跑得好好的接真机之后所有点位的时间戳都成了 1970 年。原因是那台设备返回的报文里时间戳是本地时间格式的字符串需要按设备时区解析而模型按“通用做法”生成了 Unix 时间戳解析。这类问题的共性是模型的知识是通用的现场的约定是特殊的两者的差异不在语法层面在语义层面静态检查抓不到。我们的应对是给每类协议维护一份“现场约定清单”里面记着时间戳格式、心跳间隔、异常码含义这些容易被通用做法带偏的点。生成时把清单作为约束条件传进去生成后由人快速对照一遍。6. 怎么衡量这套东西到底有没有用评估集与落地节奏6.1 四个指标看生成质量不做量化很容易陷入“感觉快了”的自我安慰。我们最后盯的是这四个指标定义我们的实测参考区间字段级准确率生成字段与人工基线一致的比例90% 上下语义标签拖后腿地址正确率地址、宽度、字序全对的比例95% 以上前提是 IR 干净一次通过率三层校验一次全过的批次占比六到七成随模板库增长提升人工修正行数评审时人改动的字段数从最初的三百多降到几十第一版我们最看重“生成速度”后来发现速度根本不是瓶颈——评审和返工才是。人工修正行数这个指标虽然土但最能反映真实收益。当它降到几十行的时候说明流程真的顺了。6.2 先从一条三十个点位的窄链路开始如果有人想复制这套东西我的建议是别一上来就搞全厂。挑一台设备、三十个点位、一种协议把清洗、IR、生成、校验、评审整条链路跑通跑通的标准是“生成的配置不改一行就能上线采集”。这条窄链路的投入大概是一到两周但它能暴露出你所有流程设计上的问题。窄链路的另一个好处是能建立第一批金标准样本。这三十个点位的正确配置就是你的第一个模板后面所有同类设备都能从它这里检索。我们的模板库是这么长起来的先有一台然后三台然后十几台到后面新设备接入的时候检索出来的示例已经非常贴脸了。6.3 人工修正要沉淀成回归用例这条是我个人最看重的经验。每次评审时人改了什么都要记下来然后把这些修正反向变成校验规则或者回归用例。比如人发现“这台设备的压力点位需要保留两位小数”那就把精度要求写进对应设备类型的规则里比如人改了某个地址那这个点位的正确值就进回归集下次生成必须一致。这么做的复利效应很明显三个月之后我们的语义断言从二十几条长到了一百多条每一条都是踩过的坑。新人接手的时候不用听我讲历史跑一遍回归集就知道哪些地方不能碰。最后分享一个实操里的小体会。这套东西真正的价值不在于省掉多少敲键盘的时间而在于它逼着我们把“点位表里到底哪些信息是事实、哪些是约定、哪些是噪声”这件事彻底想清楚了。在没有AI的时候这些混乱被人的经验和加班消化掉了看不见一旦要交给机器所有模糊地带都必须显式化。我们做完这一轮之后即使把AI拿掉接入流程本身也比以前规范得多——这可能是比生成速度更值钱的收获。
