嵌入式工程师用 AI Agent，到底卡在哪里？

最近跟几位嵌软朋友聊下来，我发现，其实大家都已经知道 Coding Agent 这回事。

CubeMX、Keil、ESP-IDF 都能打开，网页里也能问 ChatGPT、通义，但如果一落到日常开发工作里面，Coding Agent 多半还停在补全，或者停在网页聊天框里。

大伙对于古法编程的那点焦虑还在。

让人更扎心的，我觉得是另一件事：交叉编译、烧录、串口回读，这些工具链，很多嵌入式工程师还没真正喂给Agent。

你让它写驱动，它能写，你让它解释报错，它也能解释。可真正要让Agent进入开发闭环，往往还得你自己点锤子、自己盯日志、自己按下载。

会问，不等于接得进工程，关于这一点，我是越聊越有感的。

所以今天这篇，我想跟大伙聊一下：嵌入式工程师用 AI Agent，你到底卡在哪一个环节？

我们先来定一下边界，不然后面容易聊歪，今天咱们聊的不是做端侧AI的那一个方向。

不讲板上 NPU，不讲 Cube.AI / eIQ，也不讲把 AI大模型塞进 MCU 里跑推理。那是另一条赛道，值得单独再另外聊。

今天我们要讲的是：Coding Agent 怎样进入你的日常开发工作流。

需求澄清、写代码、本地编译、烧录上板、调试回读、补文档，再到轻量 CI。

工具尽量无关。Keil 也好，CubeIDE 也好，IDF 也好，思路其实都是同一个方向。

哪些环节可以先交给 Coding Agent 来试，哪些动作必须人工审核，这条线，我觉得，才是大多数传统嵌软工程师现在用得上的。

初学者和应届生也一样，先别被端侧模型名词吓住，先把工作流喂起来。

那为什么现在值得试一试？

通用开发者那边，Coding Agent 已经挺日常了，编辑器里改源码文件、跑命令、盯构建，正在变成标配。

嵌入式这边，采用意愿其实不低，很多人已经在用网页对话，或者 Copilot 这类补全工具了。

但真正缺的，我个人觉得不是再去证明「AI 有用」，而是缺一套跨工具、能落地的接法。

厂商自带助手，往往锁在自家生态里（好用是好用，出了生态就难办），社区 MCP、IDE 侧协议，又还偏新，教程和治理都滞后。

窗口，我觉得是卡在这儿：谁先把「需求 → 代码 → 编译烧录 → 调试 → 文档 → 轻量 CI」接清楚，谁就先少跑那几趟来回。

前几天我写过一篇，大致就是这个判断：把闭环接上，正在变成下一场胜负手！

可以翻一翻：《嵌入式Coding Agent，已经开始替你点编译和烧录了。》

今天这篇不展开工具细节，只想先了解清楚：你每天比较耗时间的，到底是哪一环？

比如写外设初始化，还是对着一长串编译报错干瞪眼，还是烧完板子发现串口没回读。

我也见过另一种卡住：不是不会问 AI大模型，而是问完之后，结果接不回本机的项目工程。

两边来回复制粘贴，效率看起来高，实际上闭环一直断着~（这点有点反直觉，但挺常见的。）

对齐完卡点，接下来这几条，我觉得可以直接拿走用，先说可以放手尝试的。

本地构建、读编译日志、按报错改语法和头文件路径，这类动作，Coding Agent 上手成本低，翻车代价也相对可控。

你如果还是不放心，也可以先只让Agent读工程、解释报错，如果遇到需要碰硬件的动作，全部留给工程师这边进行处理。

再来说说必须工程师进行把关的部分。

目标芯片选错、下载算法配错、量产板或客户板误刷，还有 mass erase，这些代价，Coding Agent 是不会给工程师背锅的，板上偶发死机、时序毛刺、示波器和 bring-up，也是一样。

所以，工程师仍然要设计Agent的决策闸门：工具链入口写清楚，破坏性动作要确认，失败了怎么回滚。

这些东西，得你自己先想明白，然后再喂进项目的上下文里。

编译过了，不等于板上就对了；Coding Agent 说测过了，也不等于独立门禁过了，这一点，我是特别认同的。

行动上，我建议别一上来就给Agent全开烧录权限，先要想清楚，现在让你你比较头疼的，到底是哪一环。

然后挑一块非关键板块，先给Agent接入「编译 → 读日志」这一小段，烧录权限可以往后放一放。安全一点，慢一点，反而走得稳。

别急着让Agent完全自主接管你的工作流，先证明Agent能顺利接上工程，然后闭环！（我自己也是这么劝身边朋友的。）

这篇文章，已经把边界/闭环，以及工程师审核的相关裸机价，都都说清楚了。

想跟各位嵌入式老铁探讨一下：你现在嵌入式开发工作用 AI Agent，卡得比较狠的，是哪一步？

-END-