一、当模型能力越来越强，嵌入式开发正在发生真正的变化

这一年，一个很明显的变化是：

越来越多嵌入式工程师，开始认真使用 AI 了。

以前大家讨论 AI，大多还是停留在：“帮我生成一段代码”。

但现在已经开始有人一边开着 VSCode，一边让 Claude Code 接 OpenOCD，用 MCP 接入 GDB 和 RTT，再让 Agent 自动完成 build、flash 和 monitor。

第一次意识到：原来嵌入式，也能进入 Agent Workflow。

但真正值得关注的变化，其实并不是“AI 已经会写 MCU 代码”了，而是越来越多人开始意识到：嵌入式真正困难的地方，从来不是代码生成，而是系统为什么没有真正跑起来。

因为和 Web 开发不同，嵌入式开发的大部分问题，其实都发生在“运行之后”。Web AI 之所以进步很快，一个很重要的原因是它天然拥有完整反馈链：页面错了，AI 可以直接看到；日志报错了，AI 可以自动读取；运行失败了，它还能继续 retry 和修复。所以它很容易形成“生成 → 运行 → 观察 → 修复”的闭环。

但嵌入式不是这样。

很多时候，代码已经编译通过，甚至已经成功烧录，但接下来发生的事情，AI 是完全“看不见”的。它不知道板子有没有真正启动，不知道 RTT 为什么没有输出，也不知道为什么某个 DMA 配置会偶发异常。很多复杂问题甚至只会在特定时序、特定中断状态或者特定频率下出现。

因为这些信息，大多数时候根本不在代码里。

它们存在于寄存器、调用栈、RTT、UART、Memory Map，以及各种运行态硬件行为之中。而这也是为什么，现在很多 AI 虽然已经很擅长“写 MCU 代码”，却依然很难真正进入嵌入式调试。因为它缺少的并不是生成能力，而是运行态感知能力。

换句话说，AI 现在已经能参与“编码”，但还很难真正参与“调试”。而嵌入式开发最耗时间的部分，恰恰是后者。

直到今天，大量嵌入式开发仍然停留在一种非常传统的循环里：写代码、编译、烧录、观察现象、读取日志、猜测根因、再重新验证。工程师大量时间其实都消耗在等待、重复验证和经验排障上。很多时候，一个问题真正困难的地方甚至不是“如何修复”，而是“如何知道问题到底发生在哪里”。

所以后来我们开始重新思考一件事：如果 AI 想真正进入嵌入式开发，它真正需要接入的，到底是什么？

我们最后得到的答案是：不是更强的代码补全，而是整个运行态调试链路。

---

二、从代码生成到运行态调试：如何设计一个真正能参与硬件调试的Agent

Agent 不应该只停留在“源码理解”阶段，而是需要真正参与整个调试链路，包括 build、flash、debug、observe，以及后续的分析与复盘。

 

 

首先，Agent 会读取完整工程上下文，包括源码、构建脚本、平台配置、调试配置以及历史调试记录。随后，它会对当前问题进行意图判断：是构建失败、烧录异常、运行崩溃、串口无输出，还是某种偶发性的运行时故障。不同问题，会进入不同的调试路径。

 

在进入调试流程后，Agent 会先完成第一轮基础验证。例如确认 build 是否成功、产物是否正确生成、芯片是否真正完成烧录、调试器是否正常连接、目标设备是否进入运行状态。这一步的核心目标，是先验证“系统是否真正跑起来”。

随后，Agent 会进入 debug 会话。

在这一阶段，它会读取调用栈、断点状态、变量信息、寄存器快照以及异常状态，并结合 SVD、Memory Map 和调试配置，对当前运行态建立结构化上下文。与此同时，observe 链路也会同步启动，用于持续读取 RTT、UART 等运行日志，并分析异常输出、事件顺序以及状态变化。

 

 

除了传统日志和寄存器信息之外，我们还在调试链路中加入了波形可视化能力。

 

因为很多嵌入式问题，本质上是“时序问题”。

例如 SPI 通信异常、PWM 输出不稳定、UART 波特率漂移、DMA 触发顺序错误、中断抢占异常，这些问题仅靠文本日志往往很难真正定位。工程师最终还是需要回到波形、时序和信号变化本身。

所以在我们的设计里，Agent 不只是读取“文本信息”，还会结合波形数据进行分析。它能够把运行过程中采集到的关键状态、事件和信号变化进行可视化，并结合上下文理解波形异常与系统行为之间的关系。

 

换句话说，AI 不再只是“看代码”和“看日志”。

它开始真正“观察硬件”。

如果你也在尝试让 AI 真正参与嵌入式开发，

欢迎来一起体验我们正在构建的这套运行态调试 Agent！

工具使用入口：

Probes仓库

Probes工具入口

如何更好的使用AI开发嵌入式