NI如何把AI带进测试测量工作流

薛启鑫表示，测试工程正在变得越来越复杂。

过去，一些测试任务可能只需要测量单个器件或一种物理量；现在，一套测试系统往往需要同时处理电压、电流、温度、压力、振动等多种信号，并完成持续采集、同步、融合和分析。被测对象也从单个器件逐渐扩展到子系统，甚至更加复杂的完整系统。

与此同时，随着AI开始提高产品开发和设计效率，测试与验证也需要同步提速，否则就可能成为整个研发周期中的新瓶颈。

但测试效率并不能单纯依靠“更快地写代码”来解决。一套完整的测试流程通常从需求分析和测试规划开始，之后还涉及系统架构设计、软硬件选型、程序开发、系统调试、部署运行，以及后续的数据分析和报告生成。代码只是其中的一部分。

更重要的是，测试程序最终面对的并不是一个纯软件环境，而是真实的仪器、传感器和被测对象。即便程序逻辑完全正确，只要量程、采样率、输入模式、触发条件、接线方式或者执行时序存在偏差，最终得到的测试结果仍然可能是错误的。

这也解释了为什么NI并不希望把Nigel做成一个单纯的“LabVIEW Copilot”。如果AI只负责把自然语言转换成代码，它改善的仍然只是测试开发中的一个局部环节。

测试测量真正缺的往往不是一段“正确的代码”，而是代码背后的工程环境，AI自身也要知道这段代码运行在怎样的测试系统里，这个和通用大语言模型完全不同。

例如询问一个通用大模型，如何使用NI-DAQmx完成模拟电压连续采集，它通常可以给出完整的程序流程：创建通道、配置采样时钟、启动任务、循环读取数据，最后释放资源。公开文档、GitHub代码以及互联网上大量开发资料，已经让今天的大模型掌握了相当丰富的通用知识。

可一旦进入真实项目，工程师面对的信息远不止这些。

当前电脑连接了什么仪器，设备名称和通道是什么，信号范围多大，项目已经采用了怎样的程序架构，哪些VI来自历史代码，哪些参数由前一代工程师留下，这些信息通常不会出现在大模型的训练数据里。很多测试经验和数据甚至只存在于企业内部，从未形成公开资料。

因此，同样是“模拟电压采集”，通用模型能够回答怎样搭建一套典型系统，却很难知道工程师眼前这套系统应如何搭建。

所以，测试测量领域的AI需要的知识至少有两个层面：一层是测试测量的专业知识；另一层则是工程上下文，另外，值得一提的是，这其中的工程上下文还比一般软件开发多了一层“物理上下文”。

在研讨会中，薛启鑫用一套LabVIEW国际象棋程序演示了项目上下文环境。这套程序包含大量子VI和较复杂的调用关系，Nigel读取整个项目后，可以梳理主控结构、棋局引擎以及不同VI之间的关系，再进一步进入单个VI分析内部逻辑，并发现其中未连接的端口。

国际象棋只是一个方便展示的项目，但类似场景在测试行业很常见。很多产线和实验室的测试程序拥有很长的生命周期，一套系统运行数年后，可能经历仪器替换、程序修改和人员交接。工程师接手项目时，第一件事往往不是重新建立一个VI，而是先弄清楚现有程序结构和调用关系，这也是Nigel首先尝试解决的问题。

软件之外还有硬件。NI同时拥有软件、硬件和测试数据入口，因此具备把更多工程上下文直接提供给AI的基础。研讨会现场虽然没有连接真实数据采集设备，但在NI MAX中配置了仿真设备。Nigel能够读取当前系统中的设备，并识别其仿真状态；当用户随后要求生成采集程序时，这些硬件信息便可以直接进入代码生成过程。

知道工程师正在做什么之后，Nigel下一步要解决的是执行。

LabVIEW 2026 Q3最大的变化，就是Nigel开始从过去的Advisor进一步进入Author角色。工程师不再只是询问某个函数怎么用、程序应该如何修改，而是可以直接通过自然语言要求Nigel创建VI。

Nigel的代码生成流程图示意

在研讨会中，薛启鑫共演示了三段代码生成案例。

第一个案例，用户只知道需要连续采集大约±10V的模拟电压，并实时显示波形，但并不了解采样率、每次读取点数等参数应该如何设置，手边也没有真实DAQ硬件，只在NI MAX中建立了一台仿真设备。

Nigel首先分析用户的真实需求，判断需要建立一个能够独立运行、连续采集并实时显示电压波形的VI，再结合当前设备环境补充一组常见配置，之后调用LabVIEW Coding Agent进入程序生成。

这一过程并非简单地让大模型“凭空写代码”。Coding Agent会结合LabVIEW已有范例、当前项目、已有VI以及此前对话中的信息确定实现路径，再调用相应函数和驱动VI完成程序构建和基础检查。

这里也体现了LabVIEW代码生成与常见文本代码生成之间的区别。

LabVIEW采用G语言和图形化数据流编程，程序框图本身就是源代码。Nigel生成一个VI，需要直接创建函数、子VI、循环等节点，并通过连线建立数据关系。

以连续模拟电压采集为例，它不仅需要建立NI-DAQmx通道、配置采样时序、循环读取数据并处理停止和错误流程，还要同步生成前面板上的通道选择、采样率、波形图等控件。

因此，Nigel生成的并不是一段孤立代码，而是一个包含程序结构、参数配置、用户界面和硬件信息的完整VI。

NI在研讨会中也展示了当前LabVIEW Coding Agent的边界。

第二个案例，是一个热力图VI在用户拖动阈值滑块时存在明显卡顿。Nigel分析程序后认为，界面响应和耗时的数据处理耦合在一起，因此建议把程序改造成生产者—消费者架构。

这是LabVIEW中很典型的一种程序结构。负责接收界面操作或者采集数据的循环作为“生产者”，快速把任务或者数据送入Queue；另一个“消费者”循环负责完成耗时计算。两部分并行运行，可以避免热力图计算长时间占用程序响应过程。

Nigel给出的架构判断没有太大问题，真正困难的是把它实现出来。

理想情况下，生产者应该使用Event Structure。只有当滑块数值真正发生变化时，程序才产生相应事件，再把新数据送给消费者。但在当前版本中，Coding Agent还无法可靠完成所需要的Event Structure生成。

于是Nigel给出了两种方案：保留Event Structure，由工程师按照建议手动完成；或者改成定时轮询的生产者循环，让Nigel直接生成。

演示最终采用了第二种方案。轮询也能实现功能，但它需要不断检查滑块状态。检查太频繁会增加CPU负担，间隔太长又会影响响应速度，与事件驱动并不完全等价。

这个Demo更能说明Nigel目前所处的位置，它已经能够阅读已有程序、判断性能问题、提出新的软件架构，并在现有能力范围内重构代码；但当理想方案超出当前Coding Agent的生成范围时，最终判断仍然需要工程师完成。

如果Nigel的能力停留在生成VI，那么它最终仍然只是一个更强的开发助手。

NI下一步正在尝试把AI继续向测试工作流的前端和后端延伸。

研讨会中的第三项演示，就是从客户发送的测试需求邮件开始。

邮件里混合了硬件、信号采集、通信接口、软件功能和测试判据等内容。传统流程下，工程师需要先整理需求，判断哪些条件已经确定、哪些地方存在歧义，然后才能进入系统设计和开发。

Nigel读取邮件以后，先把内容整理成不同类别的测试需求，并发现其中两处关于阈值告警的描述互相矛盾，提醒工程师需要先和客户确认。

随后，它又检查本地硬件环境，找到已经配置好的仿真设备，再基于这台设备建立模拟电压采集和2.5V阈值告警VI。

这一次，AI介入的起点已经提前到了代码之前。当输入从“创建一个模拟采集VI”变成“完成这项客户测试需求”时，AI所处理的对象也从代码任务升级成了测试任务。它先理解需求、发现冲突，再查看现有硬件，最后进入程序开发。这和前面那条从Prompt直接创建VI的路径相比，已经向完整测试流程又进了一步。

Nigel的现状和未来路线图

NI把Nigel的发展概括为Advisor、Author和Agent三个阶段。

Advisor主要提供知识和建议；Author开始直接完成具体任务；Agent则需要进一步理解更高层的测试目标，自行判断需要调用哪些工具、经过哪些步骤，并在不同软件、硬件和数据之间保持连续的工程上下文。

薛启鑫在研讨会中也提到，未来Agent希望逐渐覆盖从测试需求到测试完成的完整工作流。届时，工程师给出的指令可能不再是“创建一个VI”，而是直接描述需要完成怎样的测试。

这也是NI平台型产品布局在AI时代可能产生的新价值。LabVIEW负责测量和控制程序开发，TestStand负责自动化测试序列，InstrumentStudio面向仪器配置，FlexLogger承担配置式物理量测量，SystemLink管理测试系统和测试数据；软件之外，NI还拥有DAQ、PXI和仪器等硬件入口。

如果Nigel能够逐渐打通这些工具，AI面对的就不再是一个孤立的软件窗口，而是一套完整的测试环境。从这个角度看，LabVIEW 2026 Q3加入VI生成，可以看作一个明确的起点：Nigel开始从回答“应该怎么做”，走向“直接帮工程师做”。

对于测试测量行业来说，这件事的重要性要远大于生成VI或者其他代码。