如何搭建嵌入式软件工程师的专属Harness?

作为一名资深的嵌入式菜鸟，先来盘点一下，我们嵌入式工程师每天都在干啥。

（1）Coding写bug的时候，翻开几百页的参考手册，找一个寄存器的位域定义（找到的时候眼睛已经花了）。

（2）手写 CMock 的 mock 头文件和测试用例（一个模块十几个 case，写到怀疑人生）。

（3）编译报错一头雾水，逐条丢进搜索引擎（有时候搜出来的答案还是错的）。

（4）老大分配的各种杂活。。。

毫无疑问，这些活儿都有一些共同点：重复、枯燥，但又不能不做，更关键的是，它们恰好是 AI 最擅长的事。

如果各位老铁有了解过AI Agent，相信都知道Agent Harness是什么，也明白了Harness对于Agent的重要性。

说到 Harness，很多人第一反应是"测试脚手架"。

但我个人觉得，这个词本意是"挽具"，就是套在马身上帮它拉车的那套装备。

放到我们这里，Harness 不必局限于跑测试，它可以是套在你工作流外面、帮你跑得更省力的那套 AI 工具体系。

今天就来聊聊，怎么给嵌入式日常工作搭建一套专属的Agent Harness。

一、让 AI 帮你"读"数据手册

实不相瞒，我之前配置一个 USART 波特率，要在 RM0090 参考手册里翻半天。

先找波特率公式，再查时钟树确认 PCLK 频率，最后手算 USARTDIV 的尾数和小数部分，填到 BRR 寄存器里。

现在我的做法是：把参考手册 PDF 喂给 AI，直接问"STM32F407 的 USART2 配 9600 波特率，PCLK1 是 42MHz，BRR 该写多少？"

AI Agent不光给了答案，还附上了计算过程：

// STM32F407 USART2, PCLK1 = 42MHz, 目标波特率 9600// USARTDIV = 42MHz / (16 × 9600) = 273.4375// 尾数 = 273, 小数 = 0.4375 × 16 = 7// BRR = (273 << 4) | 7 = 0x1117// 参考手册 RM0090 §30.6.3, 误差 0.00%USART2->BRR = 0x1117;

好家伙，连参考手册的章节号和误差都标出来了。这比我自己翻 PDF 快了不止一个量级。

当然，AI 给的东西不能照单全收。

我后来确实回查了手册第 30 章的波特率表，数值对得上才放心用。（要是 AI 幻觉了一个不存在的寄存器位，直接烧进去，板子冒烟了算谁的？）

二、AI 生成测试用例和 mock

在自测之前，要写单元测试用例，这件事，道理谁都懂，但要是落地到实处，我相信很多老铁会打退堂鼓，主要是 mock 和 case 太磨人了。

我现在的做法是：把被测函数的源码丢给 AI，让它帮我生成 Unity 测试用例。比如这个温度传感器读取函数：

/* sensor.c — 读取温度原始值并转换为摄氏度 */int16_tsensor_read_temp(uint8_t raw){    if (raw == 0xFF) return SENSOR_ERR;  // 传感器故障    return (int16_t)(raw * 0.5f - 20);   // 线性转换}

AI 生成的测试用例覆盖了正常值、边界值和异常值：

/* test_sensor.c — AI 生成的测试用例（经人工审核） */void test_sensor_normal_value(void) {    // raw=100 → 100×0.5-20 = 30℃    TEST_ASSERT_EQUAL(30, sensor_read_temp(100));}void test_sensor_boundary_zero(void) {    // raw=0 → 0×0.5-20 = -20℃（最低温度）    TEST_ASSERT_EQUAL(-20, sensor_read_temp(0));}void test_sensor_error_condition(void) {    // raw=0xFF → 传感器故障，返回错误码    TEST_ASSERT_EQUAL(SENSOR_ERR, sensor_read_temp(0xFF));}

三组 case，正常值和异常情况都覆盖了，我拿到测试用例之后，只需要微调一下注释和命名，基本就能直接跑了。（省下来的时间，不香么？）

三、AI 当"编译报错翻译官"

交叉编译的报错信息，说实话，有时候看得人脑壳疼。尤其是链接阶段的 undefined reference，报了一大坨，真正的原因可能就藏在中间某一行。

我的做法很朴素：把编译 log 直接贴给 AI，让它帮我定位根因。

比如这个经典的链接错误，出现在传感器模块的初始化函数里：

arm-none-eabi-ld: sensor.o: in function `sensor_init':  sensor.c:(.text+0x1c): undefined reference to `HAL_I2C_Master_Receive'

AI 一眼就看出来了：你的传感器模块初始化时要走 I2C 读数据，但 HAL_I2C 的库文件没链接进去。

要么在 CMakeLists 里把 HAL_I2C 的 .c 文件加到源文件列表，要么在 CMock 里把 HAL_I2C_Master_Receive mock 掉。

两条路都行，看你是在跑真硬件测试还是纯逻辑测试。

这种问题以前我要翻半天 Makefile，现在几秒钟就搞定了。嗐~

但有一说一，咱在用AI Agent之前，有三条红线必须守住。

（1）涉密代码脱敏。固件是公司的核心 IP，别傻乎乎把整份源码丢给云端 AI。要么用本地部署的模型，要么把敏感的协议格式、密钥算法这些先脱敏。

（2）生成代码过编译 + 资源检查。AI 可能给你一段逻辑没问题的代码，但 Flash 超了或者栈溢出了，这些它不管，你得自己验。

（3）寄存器配置和 RTOS API 不轻信。AI 幻觉起寄存器来脸不红心不跳，一个不存在的位域定义它能编得有模有样。拿到手的配置，回查手册，这一步偷不得懒。

搭这套 AI Harness，说白了就是把体力活丢给 AI，自己腾出脑子去想真正要紧的事。

从读手册到写测试再到编译排错，这三件Harness我目前都已经用上了，确实省了不少时间。

后面我还想试试，让 AI 扮演"暴躁的代码审查员"来挑刺，到时候再和大家分享~

各位老铁，周末愉快啦~

-END-

你还在古法编程？超过90%的嵌入式工程师，都在用Agent参与开发工作了！

实测了一下，瑞芯微的“低功耗录像技术”，确实是有点东西！

本来就是嵌入式菜鸟，现在更菜了！