行业洞察:通用型 AI 为何难以满足测试需求?

NI 杰出工程师 Alejandro Barreto 一针见血地指出，通用大模型的训练数据主要来自 GitHub等开放平台，但涉及计量学、系统设计以及硬件规格等专业内容的数据却十分有限。而测试工程师每天接触的大量知识，往往属于企业内部积累的专有经验，从未出现在公开训练数据中。

因此，当一个通用 AI 工具自信满满地生成了一段忽略硬件限制的代码，或者需要经过多轮修改才能勉强投入使用时，它并不是“失灵”了，而是在按照设计运行。它所做的，只是基于有限训练数据预测最有可能出现的答案。但在关键测试场景中，“看起来合理”远远不够。

所有 AI 工具都可能出现“幻觉”或产生错误。无论是让大模型帮你润色邮件，还是总结世界杯赛程，这类任务即使出错，带来的影响通常也微乎其微。然而，在测试与测量领域，情况完全不同。一个错误的建议，可能导致：

• 浪费宝贵的工程开发时间

• 损坏昂贵的测试设备

• 使测试结果失去可信度

• 带来潜在的安全风险

因此，仅仅追求准确率是不够的。工程师需要的是能够理解仪器、工作流程以及工程约束条件的 AI，而不是单纯依赖互联网统计规律进行推断的工具。真正的区别不在于 AI 能否生成答案，而在于它是否具备足够的行业知识和工程背景的理解，从而生成值得信赖的答案。

从本质上讲，大语言模型（LLM）只做一件事：预测下一个词。无论是一段回答、一段代码，还是一次分析，本质上都来自一个庞大而高效的模式匹配系统，它根据历史数据预测接下来最可能出现的文本内容。

要让一个“下一个词预测器”真正成为能够完成工作的工具，还需要额外的一层能力，这通常被称为智能代理框架（Agentic Harness）。其工作方式如下：

1. 模型提出一个行动建议

2. 代理框架执行该行动

3. 将执行结果反馈给模型

4. 模型根据新信息决定下一步操作

正是这一循环机制，而非模型本身，让聊天机器人具备了编写代码、验证结果、自我纠错以及持续迭代的能力。但即便拥有完善的代理框架，如果缺乏专业领域知识，模型依然难以输出可靠结果。这也正是专用 AI 与通用 AI 分道扬镳的地方。

当测试与测量相关的知识库被引入模型时，AI 获得了训练数据中原本不存在的上下文信息。此时，它不再只能生成“通用代码”，而能够了解仪器的通道数量限制、采样率要求以及系统约束条件，从而给出更贴近实际需求的解决方案。

这正是 NI Nigel™ AI所采用的方法。Nigel 并没有从零构建一个全新的大模型，而是在现有通用大模型基础上，叠加了测试测量领域所需的：

• 专业知识库

• Agent 智能代理能力

• 工程验证逻辑

因此，即使底层模型未来发生变化，用户体验依然能够保持一致，因为真正属于测试工程领域的专业智能，存在于更高层的能力体系中。

如今，代码生成无疑是 AI 在测试领域最直观的应用场景。但实际上，它只是整个测试流程中的一环。在将重要工作交给 AI 之前，工具必须先赢得工程师的信任。大多数通用 AI 被设计成“乐于助人”的助手，却并非“承担责任”的工程伙伴。而对于身处关键任务场景或受监管行业中的测试工程师来说，标准显然更高。那么，一个真正值得采用的 AI 工具，至少应满足以下五项基本要求：

1. 覆盖完整测试流程

需求分析、系统设计、测试方案制定、故障调试以及结果报告，才是测试工程师投入时间最多的环节。优秀的 AI 工具应覆盖整个测试生命周期，而不仅仅停留在代码生成阶段。

2. 能够验证自身输出

AI 不应把错误检查完全留给工程师。在交付结果之前，它应该主动依据工程标准进行验证，尽可能在源头发现问题，而非让风险流入后续环节。

3. 保护企业数据安全

用户需要清楚了解：

• 数据存储在哪里

• 传输和存储过程中如何受到保护

• 输入内容是否会被用于训练第三方模型

对于企业级应用而言，数据安全绝非可选项，而是基本要求。

4. 能够按照需求灵活部署

云端部署固然方便，但并非所有场景都适用。当安全、保密或合规要求不允许数据离开企业环境时，AI 工具应能够部署于本地或私有基础设施中，而不是强迫用户将数据上传至外部平台。

5. 能够持续学习与成长

AI 的价值不会停留在首次使用。真正优秀的工具能够接入企业自身的数据源，学习组织内部的设计规范、开发模式和团队习惯，并随着使用不断优化输出结果。换句话说，它会越来越懂你的团队。

AI 正在快速发展，而它在测试领域的作用也将不断扩大。那些既保持高标准要求、又愿意积极尝试新技术的工程师，往往能够获得最大的价值。当 AI 不再只是响应组织要求而被动使用的工具，而是能够帮助工程师完成更具挑战性、更具创新性的工作时，它的真正价值才会得以体现。而这，正是测试未来的发展方向。

关注“恩艾NI知道”

知道那些你想知道的NI事

在看点一下