为什么AI写不了嵌入式代码?|Enterprise Harness Engineering(四)

Linkloud 引言

大多数人聊 AI 写代码，聊的都是软件，GitHub Copilot、Claude Code、Cursor，光标在屏幕上跑，几秒钟出一个函数，全程在数字世界里，AI 天然就能操作。

但如果你是一家硬件公司，会发现问题来了。

AI 怎么给芯片刷固件？怎么控制示波器测频率？怎么在产线上自动跑 100 项测试？这就是硬件公司做 AI 化的独特困境：AI 和真实世界之间有一道物理隔离，没有 API 可调，没有 JSON 可返回，只有一堆硬件设备在等人手动操作。

前三篇我们拆了 Enterprise Harness Engineering 的整体框架、SRE 全链路自动化、软件产研 9 步闭环。本篇是系列里最硬核的一篇，也是积加科技这家硬件 AI 公司最独特的地方：他们自研了四套平台，开发了一个叫 devium-cli 的东西，把示波器、综测仪、摄像头模组、产线设备全都 API 化了。

AI 可以通过这条通路控制物理世界。原来一周的 WiFi 调参，现在 Agent 自动跑几十轮，人去睡觉就行。

专栏介绍

《Enterprise Harness Engineering》系列文章

作者：陈敬敏— EPFL（瑞士洛桑联邦理工学院）数学博士，前阿里巴巴 P9 资深算法专家，现任积加科技 CTO。

积加科技（AddX.ai）：积加科技（addx.ai）是全球领先的硬件 AI 公司，以多模态世界模型在视觉 AI 硬件上的应用为核心产品。建立在视觉记忆 Agent、视觉 Token 构造和压缩、垂直模态大模型等技术的基础上，addx.ai 构建了以真实世界视频为输入的高效推理平台，其产品和 AI 增值服务涵盖自然观察、家庭智能、运动健康等众多场景，满足全球数百万用户的需求。

AI 怎么控制示波器？怎么给芯片刷固件？怎么在产线上跑 100 项测试？

这是硬件公司做 AI 化的独特挑战，也是 Enterprise Harness Engineering 区别于纯软件公司的关键差异化。我们的答案是：软硬件统一——硬件测试和软件测试使用同一套框架和同一套可观测性基础设施。

PART 01

硬件产研的独特挑战

软件产研的闭环是：写代码 → 跑测试 → 看结果 → 修改 → 再跑。整个循环在几秒到几分钟内完成，AI 能完全自主执行。

硬件产研的闭环天然更长、更复杂：

固件编译
需要远程 build server 或 Docker 容器，跨平台编译（MIPS/ARM/RISC-V），编译一次几分钟到几十分钟
仪器操作
需要物理连接示波器、频谱仪、综测仪，手动操作采集数据
参数调优
改参数 → 刷固件 → 仪器测量 → 记录数据 → 分析 → 再改，一轮 30 分钟，可能需要几十轮
产线测试
100 个测试项 = 100 套代码，每加一个测试项都要写新代码

每一个环节都涉及物理设备，AI 不能像操作 API 那样直接操作。Harness Engineering 在硬件场景的核心任务是：在 AI 和物理世界之间架一座桥。

PART 02

四大自研平台：桥梁的基础

我们构建了四个自研平台，覆盖硬件产品从设计到量产的全生命周期：

1. 统一上位机平台（Device Cloud Host）：插件化接入一切设备

问题：IoT 设备协议碎片化严重——串口、TCP、USB、SCPI、HTTP，每种设备一套控制代码。传统上位机程序硬编码设备类型，每接入一种新设备需要改 6+ 个文件。

解法：构建插件化的统一上位机平台。新设备接入只需一组文件——plugin.yaml（声明协议和匹配规则）+ detector.py（识别逻辑）+ actions.py（操作方法）。框架自动完成设备发现、协议适配、API 生成。

插件架构的核心设计：

三层漏斗式设备发现
声明式匹配（plugin.yaml，80% 设备零 I/O 识别）→ 被动指纹分析（并行，不干扰设备）→ 主动探测（独占连接，最后手段）。消除插件间干扰。
@action 装饰器
→ SSOT 自动生成：插件定义一次 @action 方法，框架自动生成 REST API 端点 + CLI 子命令 + Web UI 面板。一处定义，三处可用。
AI-First 设计
devium-cli 默认 JSON 输出（AI 是主要消费者）、无交互式 prompt（破坏性操作用 -confirm）、结构化错误输出（AI 可精确重试）。
热加载
watchdog 监听 plugins/ 目录，新增/删除/修改插件运行时生效，无需重启。
错误隔离 + 指数退避
插件异常不影响其他设备，连续失败 3 次自动 disable → 1min 重试 → 5min → 30min。

复合设备支持：一台 Camera 可能有 SOC 串口 + MCU 串口 + relay 按键组合。插件的 discover() 方法编排跨口识别，将多个物理端口组合为一个逻辑设备。

两种运行模式：

cluster 模式
设备自动注册到云端平台，纳入团队共享的统一调度，CI 可远程使用
local 模式
不上报，仅本地 CLI 可用，适合个人开发调试

2. 自动化测试平台（Device Cloud）：设备云化 + BDD 测试引擎

问题：产测、软测、硬测三条线各自独立——产测用 Factory App、软测用 Appium、硬测靠手动。设备资源不共享，日志不互通。

解法：将所有设备云化，用 Behave（BDD）作为统一测试引擎，通过上位机插件控制设备：

Behave Feature 文件（声明式测试场景）  → device-cloud-client 解析资源需求    → device-cloud-server CSP 引擎最优匹配分配设备      → device-cloud-host 锁定设备，执行插件 action        → 结果 + 日志 → ReportPortal

通用 BDD 步骤——一组步骤定义覆盖所有插件的 action，不需要为每种设备写步骤代码：

Scenario: 验证示波器测量  Given 设备组包含以下设备| 设备     | 类型          | 条件                       || {示波器} | OSCILLOSCOPE  | manufacturer:$eq:KEYSIGHT  |  When 执行设备 "{示波器}" 的 "measure" 操作| 参数    | 值   |    | channel | 1    || type    | FREQ |  Then 操作结果中 "value" 大于 "0"

核心突破：

声明式资源请求
$eq、$ge、$in、$regex 等运算符匹配设备属性，CSP 引擎秒级最优分配
五源日志聚合
手机/SOC/MCU/脚本/附件 → UUID 统一关联 → ReportPortal
Session 管理
会话（日志）和设备锁定（资源）正交设计——Session 永久可 resume，设备锁定有超时防遗忘

3. 物模型平台：所有设备定义的 Single Source of Truth

问题：设备型号、物模型定义、工厂配置散落在多个系统中，缺乏统一数据源。

解法：基于 Matter 标准建立物模型 SSOT。所有设备型号的定义和工厂部署文件都从一个平台生成和分发——产测平台读取部署配置，自动化测试平台获取设备注册信息，前端 App 拿产品型号。一个源头，全链路消费。

4. 产测平台（Factory App）：Config over Code

问题：产线测试 100 个测试项 = 100 套代码。每加一个测试项都要写一套专门的代码，改一个协议字段可能要翻十几个文件。而且测试参数（阈值、规格）硬编码在代码里，换一个产品型号就要改代码重新部署。

解法：Config over Code — 所有测试操作的流程本质上都是拼请求 → 发送 → 接收 → 判定，区别只在参数。将"写代码"变成"填 YAML 配置表"：1 套通用执行引擎 + 1 张能力矩阵 YAML。引擎按 resource_kind 自动路由到设备、仪器或云端 API，上层格式完全统一。

能力矩阵机制：测试用例不硬编码参数，而是声明"我需要设备的哪些属性"，平台从物模型（SSOT）动态加载具体参数值：

Scenario: 检查摄像头分辨率  Given 测试对象 CAMERA 物模型有以下属性列表| 属性code      || resolution    || white_balance |  When 我将摄像头对准测试图表  Then 输出图像分辨率应为预期值

同一份测试代码，自动适配不同的产品型号——Model-A、Model-B、Model-C 各自从物模型读取自己的分辨率规格。新产品上线不改代码，只改配置。

分层架构让不同角色各司其职：

平台内建 20 个 Skill，覆盖能力矩阵编写、测试用例迁移、仪器接入、失败分析、GUI 自动化、部署文件生成等产测全流程。

远程仪器共享：研发在上海可以远程使用深圳工厂的测试仪器——通过 P2P 连接控制远端 DeviceHost，无需购买或搬运昂贵的测试设备。

PART 03

AI 如何操控物理设备

devium-cli 是 AI 与物理世界之间的桥梁。人和 AI 使用同一套工具——BSP 工程师通过 devium-cli 直连上位机操作设备和仪器，Agent 通过相同的 CLI 接口实现自动化。

devium devices                                    # 列出所有已识别设备devium device dso-001 measure --channel 1 --type FREQ  # 执行示波器测量devium session start "WiFi 调参"# 创建调试会话（日志自动上报 ReportPortal）devium device cam-001 connect                      # 锁定设备

关键设计：不给 AI 造一套独立的控制接口，而是让 AI 和人共用同一条通路。插件的 @action 方法定义一次，CLI 命令和 REST API 自动生成——AI 通过 CLI 调用，等同于人手动操作，但更快、不会疲倦、记录完整。

PART 04

实战场景

场景 1：WiFi 调参 → 从几十轮手动到 AI 自动迭代

旧方式：射频工程师手动修改参数 → 编译固件 → 烧录设备 → 用综测仪测量 → 手抄数据 → 分析 → 再调。一轮 30 分钟，调完可能需要几十轮。一周的工作。

现在：Agent 通过 devium-cli 控制设备修改参数 → 刷入固件 → 控制综测仪/频谱仪自动测量 → 分析测量数据，决定下一轮参数方向 → 自动循环直到指标达标。

图像调参（ISP tuning）同理：Agent 控制设备切换场景 → 仪器采集图像数据 → 分析画质指标 → 调整 ISP 参数 → 下一轮。AI 不知疲倦，可以连续跑几十轮，而且每轮的记录完整可追溯。

场景 2：固件编译 → 一句话触发

旧方式：登录远程 build server → SSH → 切分支 → init 子模块 → 配置工具链 → 运行 total_build.sh → 等 → 下载产物。

现在：说"帮我编译 main 分支的固件"→ Agent 调 firmware-build → SSH 到远程 server（带 Agent 转发）→ 子模块初始化 → 依赖检查 → 选择编译变体（完整/仅 release/仅应用/仅 MCU）→ 编译 → 验证产物 → scp 下载。支持多 SOC 平台（MIPS/ARM/RISC-V）。

场景 3：产测仪器接入 → 从 1 天到 2 小时

旧方式：电子工程师要接入一台新的 Keysight 示波器 → 手动写仪器驱动 → 手动写协议文档 → 手动配置能力矩阵 → 手动测试。1 天。

现在：说"接入新的 Keysight 示波器"→ Agent 引导填写通信参数和命令列表 → 自动生成标准协议文档 → 按 7 步标准流程生成驱动代码 + 能力矩阵 YAML + smoke Feature → 本地验证 → 提交 MR。2 小时。

场景 4：产线失败分析 → AI 读日志定位根因

产线某个测试项连续失败 → Agent 调产测平台的 analyze-test-failure Skill → 自动读取 Behave 测试日志 + DeviceHost 通信日志 + 设备日志 → 关联五源日志 → 定位根因（例如 MCU 固件版本不匹配）→ 生成根因报告 + 修复建议。

场景 5：嵌入式代码 CI → SonarQube 增量扫描

嵌入式仓库没有 CI pipeline → 说"给这个仓库加 CI"→ Agent 调 embed-ci-setup → 自动生成 .gitlab-ci.yml + ci/sonar-analysis-embed.yml → 配置 SonarQube C 语言增量扫描 → MR 触发 → 扫描结果反馈到 MR 评论。从零到有，10 分钟。

PART 05

统一可观测性：

软硬件共享同一套框架

硬件 Harness 最重要的架构决策是：硬件测试和软件测试使用同一套框架和同一套可观测性基础设施。

三者共享同一套上位机程序（device-cloud-host）、同一套日志聚合（ReportPortal）、同一套监控（Grafana/Prometheus）。

意义：Agent 在任何场景下都能用相同的方式获取数据、分析问题、生成报告。不需要为硬件测试单独建一套 AI 体系——它天然就是统一体系的一部分。

PART 06

关键设计决策

1. Config over Code — 降低 Skill 化的门槛

产测平台用"能力矩阵 YAML"替代了"每个测试写一套代码"的模式。这意味着 AI 生成测试项的成本从"写代码 + 调试 + 部署"变成了"填一份 YAML 配置"——Agent 天然擅长的事。

2. 声明式测试 DSL — 让 AI 能读懂测试

BDD（Behavior-Driven Development）格式的测试用例是自然语言描述：

Scenario: 验证设备 WiFi 连接  Given 设备已上电  When 发送 WiFi 扫描指令  Then 应返回至少 1 个可用网络

AI 能直接读懂和生成这样的测试用例，不需要理解底层协议细节。

3. Everything as Code — 硬件也不例外

固件编译用 Bazel + Docker，不手动操作；仪器配置用 YAML，不手动调节面板；产线部署用配置文件，不手动上传。硬件研发的每一个环节都代码化，AI 才有闭环。

PART 07

结语

硬件产研是 Enterprise Harness Engineering 中最具挑战性的方向，因为它要在 AI 和物理世界之间架桥。

但也是最能体现"Enterprise"价值的方向，当软件测试和硬件测试共享同一套框架，当 AI 通过同一个 devium-cli 操控所有设备和仪器，硬件公司就不再是 AI 化的"特殊情况"，而是统一体系的一部分。

四大自研平台（上位机 + Device Cloud + 物模型 + Factory App）+ devium-cli + 统一可观测性 = 硬件公司的 Harness。有了这个 Harness，AI 就能像操作 API 一样操作物理设备——从固件编译到仪器调参到产线测试，全链路闭环。

💡敬敏将 Enterprise Harness Engineering 的 Skill 开源到了GitHub，欢迎大家使用和反馈：

https://github.com/addxai/enterprise-harness-engineering

END

往期回顾

为AI构建企业的技术与组织骨架｜Enterprise Harness Engineering（一）

2026-04-19

为什么你的SRE还在凌晨被电话吵醒？｜Enterprise Harness Engineering（二）

2026-04-26