简仪科技软硬件生态与AI Agent的无缝融合

在测试测量与自动化控制领域，软件开发一直不是一件简单的事。

一个看似普通的数据采集程序，背后往往涉及硬件驱动、通道配置、采样模式、触发逻辑、缓存管理、实时显示、信号分析、异常处理，以及最终的数据记录和报告生成。

随着AI Agent和AI编程工具的发展，一个新的问题出现了：AI会写代码了，但它真的懂测控系统吗？

通用大模型可以生成C#、Python、WinForms、数据库、通信协议等代码，但它并不天然理解某一套具体测控硬件的底层逻辑。这时候，就需要一个连接AI与专业工程知识的桥梁。这个桥梁，就是Skills。

在传统测控开发中，工程师经常需要同时面对：硬件手册、驱动接口、采集流程、触发逻辑、GUI显示、信号分析、数据记录、异常处理等多个环节。

例如，用户提出一个需求：“创建一个连续采集程序，量程±5 V，采样率100 Hz，并实时显示波形和FFT频谱。”

这句话看起来很简单，但真正落地时，工程师需要完成：创建任务、添加通道、设置采样模式、配置采样率、启动任务、读取数据、实时显示、FFT分析、异常处理、停止并释放资源。

如果涉及PXI/PXIe、多板卡同步、触发采集、IEPE传感器、热电偶、动态信号分析等，系统复杂度还会进一步提升。

所以，测控开发真正困难的地方，不只是“代码量大”，而是：它要求软件开发人员同时理解硬件、驱动、信号、时序和工程边界。

AI 编程工具已经可以帮助工程师快速生成代码。但在测控场景中，仅仅“会写代码”还不够。因为测控程序连接的不是虚拟业务系统，而是真实的硬件设备。它面对的是传感器、模拟信号、采样时钟、触发同步、数据缓存、硬件保护和设备状态。如果 AI 不了解这些约束，就可能生成“语法正确，但工程上不可用”的代码。

例如：

AI可能生成不存在的 API；

可能写错量程枚举值；

可能在未启动任务前读取数据；

可能忽略连续采集时的数据缓存；

可能没有处理驱动异常；

可能不理解多设备同步中的主从顺序；

也可能没有考虑硬件安全边界。

因此，测控行业真正需要的AI，不只是一个“代码助手”，而是一个能够理解专业规则的“工程助手”。

Analog Input + Artificial Intelligence：让AI真正进入测控工程现场

Skills，可以理解为一种将专业知识打包成可复用能力的机制。

一个Skill通常包含一个核心文件：

这个文件用于告诉AI：

这个技能适合解决什么问题；

什么时候应该调用它；

应该遵守哪些开发流程；

可以使用哪些 API；

参数和枚举值有哪些合法范围；

哪些调用顺序不能写错；

遇到异常应该如何处理；

有哪些示例代码和工程注意事项。

换句话说，Skill就像是给AI Agent准备的一份：专业工程说明书。

它不是简单的接口列表，也不是普通的文档说明，而是面向AI编程和Agent工作流设计的一种知识封装方式。有了Skill，AI不再完全依赖自己的通用知识去“猜测”代码，而是可以先读取专业规则，再根据用户需求生成更符合工程实际的程序。

需要特别说明的是，Skills并不是某一个AI编程工具的专属概念。无论是在AI IDE、命令行CLI，还是其他支持Agent工作流的AI编程环境中，只要能够读取并理解SKILL.md，就可以使用类似的机制。

也就是说，Skills的核心价值并不在于绑定某一个工具，而在于：把专业知识、工程经验和团队规范，变成 AI 可以读取、理解和复用的知识单元。

这对于测控行业尤其重要。因为测控领域有大量专业性强、重复性高、流程固定、容易出错的开发任务，非常适合通过Skills进行沉淀和复用。

AI生成代码时，最常见的问题之一是“幻觉”。它可能会编造一个不存在的函数，使用一个错误的类名，或者写出一个SDK中根本没有的枚举值。在普通代码中，这类问题可能只是编译失败；但在测控软件中，错误的接口和参数往往会影响整个程序流程。

Skill可以将真实API、合法枚举、参数范围和示例代码明确写入文件中。

例如，当用户说“设置量程为5 V，上升沿触发”时，AI不应该随意写成字符串 “5 V” 或 “Rising”，而应该根据Skill中的映射规则，生成符合SDK定义的枚举值。

这类约束可以显著降低AI的接口幻觉，提高代码一次编译通过的概率。

从“AI 猜接口”变成“AI 按规则生成接口”

测控程序通常具有严格的流程要求。

如果顺序写错，程序可能无法运行，或者运行后得不到正确数据。

Skills的价值，就是把这些硬件工作流固化为标准Pattern。AI在生成程序时，可以按照Skill中定义的流程自动组织代码，从而减少“未启动就读取”“未配置就运行”“异常后没有释放资源”等常见问题。

测控系统并不是纯软件系统。它与真实设备相连，因此必须重视硬件状态和安全边界。

例如，某些采集卡需要在操作前检测连接状态；某些 IEPE 设备需要判断传感器连接是否正常；多板卡同步可能要求先配置从卡，再配置主卡；驱动异常也应该被统一捕获和处理。

这些规则如果只靠AI自己推理，很容易遗漏。但如果写入Skill，就可以成为AI必须遵守的工程约束。

例如，Skill可以要求AI：在驱动调用外层使用 try-catch；优先捕获专用驱动异常；在停止任务时释放资源；在多设备同步时遵守主从卡提交顺序；在关键硬件操作前进行状态检测。

这让AI生成的程序更接近真实工程项目，而不是简单 Demo。

要让AI真正进入测控开发，不能只靠AI本身。它还需要稳定的硬件平台、统一的软件接口、成熟的图形与算法生态，以及可以被AI理解的知识封装。

简仪科技长期围绕测试测量、数据采集、PXI/PXIe、USB、SeeSharpTools、FirmDrive^®、MISD等方向进行软硬件生态建设。

其中，FirmDrive^®提供了标准化的硬件抽象与驱动基础，让不同设备可以通过统一方式调用。

SeeSharpTools提供了图形界面、信号分析、报告生成、通信、数据库等常用能力，使AI在生成测控应用时不需要从零开始搭建所有功能。

而Skills则进一步把这些软件接口、硬件流程和工程规则封装成AI可读取的知识模块。

因此，真正的融合不是简单地“让AI写代码”，而是：硬件平台+软件SDK+工程规则+AI Agent的协同。

在实际开发中，AI+Skills可以将自然语言需求转化为可运行的测控程序。

在传统模式下，工程师需要查阅驱动文档、寻找示例代码、编写采集逻辑、连接GUI 控件、调用 FFT 算法，并处理各种异常。

而在AI+Skills模式下，AI可以先读取对应的Skill，理解采集任务的标准流程、参数设置方式、图表控件用法和异常处理规范，再生成完整的C#程序框架。

这带来的提升不只是“更快写出代码”。更重要的是，它让代码生成过程具备了可重复、可规范、可沉淀的工程基础。

传统开发模式下，工程师需要查阅大量文档，手动理解API、枚举、采样流程和异常处理逻辑。

而在AI+Skills驱动开发模式下，AI可以读取Skill中沉淀的专业规则，并结合SeeSharpTools、FirmDrive^®等软件生态，快速生成符合工程逻辑的程序框架。

这种变化带来的不是简单的“代码自动补全”，而是开发范式的变化。

Skills特别适合那些“专业性强、流程明确、重复出现、需要经验约束”的任务。

相关资料可通过简仪官网www.jytek.com（或点击下方“阅读原文”），下载简仪大全《JYPEDIA》。

GitHub地址：https://github.com/JXISH/SeeSharp-Academy

在该仓库中，可以进一步查看和下载相关示例、开发指南以及Skill.md 文件。

后续，简仪科技也将围绕测控开发继续完善更多方向的Skills，例如：

• 数据采集

• SeeSharpTools 图形界面

• 信号分析

• 报告生成

• 多卡同步

• PXI/PXIe 应用

• C#测控程序开发

• AI Agent 测控工作流

通过这些内容，工程师可以更方便地将AI引入实际测控项目，而不是停留在简单的代码补全阶段。

AI编程的第一阶段，是让AI帮工程师写代码。

AI编程的下一阶段，是让AI理解工程系统本身。

对于测控行业来说，这一点尤其重要。因为测控软件连接的不只是界面和业务逻辑，还连接着真实的硬件、信号、采样、触发、同步和安全边界。

如果没有专业知识约束，AI很容易停留在“生成Demo”的层面；而有了Skills，AI才有机会真正进入工程现场，成为测控开发中的可靠助手。

Skills的意义，就是把测控行业长期积累的专业经验，转化为AI可以读取、理解和复用的知识模块。

未来，工程师可以把更多精力放在需求定义、系统架构、测试目标和创新应用上，而大量重复性的接口调用、流程代码、界面搭建和数据处理工作，则可以交给AI Agent 在Skills的约束下完成。

Skills 不是替代工程师，而是帮助工程师把经验变成可复用的生产力

AI不会自动懂每一个行业。但当我们把行业知识、工程规范和最佳实践沉淀为Skills，AI就可以从一个通用助手，逐步变成专业工程助手。

对于测试测量和自动化控制领域来说，Skills将成为连接AI Agent与真实硬件系统的重要桥梁。

简仪科技也将持续推动SeeSharpTools、FirmDrive^®、MISD、JYPEDIA与AI Agent的结合，让测控开发更开放、更高效、更智能。

让AI真正成为测控工程师的生产力伙伴。

相关阅读