嵌入式工程师怎么用AI提效?说说我常用的几个方法

最近有一些人问我，嵌入式工程师如何用AI提效？

对于这种新工具，其实我也是草班出身，都是边学边干。

只是我自己也是做了将近10年工程师，然后做了opc 6年，可能对行业，对应用场景，相对工程师高强度研发工作来说，有更多的时间去思考和实践，也有更多时间研究AI。

说真的，研究AI真的很费时间，一天一个新工具，今天颠覆这个，明天那个又炸裂了。

以前被这种节奏带着走，感觉人都快被吸光了，根本学不完。

我是用了两年多的AI，早期用网页版对话框让它帮我写程序，各大主流大模型都有订阅，前前后后烧了几千块。

单模型每月消耗3亿左右token。

其实真正具备生产力的，也就这么1,2个，今天我直接带大家一步到位，少踩坑。

先说工具层面啊，这个成本最高，比如说订阅成本，还有花时间去用，一个个试出来。

写代码的话，有条件的直接Claude code+claude opus4.6，或者sonnet4.6，现在主流第一个是官方订阅，第二个是用中转API。

两个都有共同特点，很贵，订阅相对便宜一些，但是对咱不友好，动不动就不让用，中转用起来最省事，但一定要找到靠谱的，有些可能是套壳，或者乱扣量的，我试过一个问了几个问题，没了几刀，就不敢用了。

如果没条件的可以上Claude code+GLM5模型，不过写代码，像深入一点的，涉及到行业算法的，有参考也很难调出来。

早期在网页版对话框的时候，我是一直用gemini，感觉能力不比claude差多少，而且基本可以理解成无限使用。

但是现在像claude code这种Ai Agent，网页版的基本不用，他们的cli太拉胯了就没用了。

还有就是codex，之前网上评价很高，我用下来感觉不咋滴，很慢，质量也一般般，可能是没有深度用来做完整项目代码的原因。

所以如果你用来写代码，我感觉直接claude code+ide，或者codex+ide就够了。

有些ide开订阅也能用上claude之类的模型，我也开过，但是总是感觉怪怪的，没有在claude code上输出的质量高。

再说说自己之前写代码日常使用上面。

嵌入式的代码跟硬件绑得太死，平台杂、外设多、时序约束严，目前让AI生成代码然后自己debug，还是不行。

这不是AI不行，是嵌入式本身就不好自动生成，而且没有硬件数据闭环，Debug起来变量太多。

但是有几个场景，我是经常在用的。

丢一段代码问它这段在干什么

这是我用得最多的场景。

看不熟悉的项目，或者看别人写的模块，代码量一大就容易看丢。尤其是函数套函数、状态机嵌条件判断那种，读一遍脑子里全是碎片，拼不出全貌。

我的做法很直接：把关键函数或者一个模块的代码整段丢给AI，问它三个问题。这段代码在干什么？主流程是什么？有什么边界情况？

大部分时候它的回答是靠谱的。模块之间的调用关系、数据流方向、状态转换逻辑，它给你梳理得比你自己从头看快不少。

但也有它不行的地方。它理解的只是代码本身的逻辑，不知道这段代码在整个系统里扮演什么角色。比如它会告诉你这个函数在检测超时，但它不知道这个超时值是为了兼容某个通信芯片的时序偏差。这种属于设计经验。

所以用法是这样的：先用AI快速搭一个认知框架，再自己往里填硬件和业务上下文。不是让AI替你看代码，是让它先帮你画一张地图，你拿着地图去找细节，路还是要自己走的。

把错误现象描述给它，让它列可能原因

调试的时候，有时候一个问题卡了很久找不到原因，脑子里的排查思路已经用完了。

这时候我会做一件事：把错误现象尽可能详细地描述给AI。什么条件下出现，出现时系统是什么状态，但是有时候问题描述起来很抽象，我的做法是把现象数据化，比如说可以用串口数据把相关值打印，然后喂给AI，这样不至于鸡同鸭讲，你讲你的，它说它的，完全不在一个频道上联调，能把你搞到想砸键盘。

它给的答案不一定对，但很多时候会给我一些我没想到的角度。

但局限也很明显。它不了解你的硬件环境。信号完整性、板级走线、电源纹波，这些物理层面的东西它完全不知道。

所以它列的原因是从代码逻辑出发的猜测，不是从实际硬件出发的诊断。

纯软件的问题它能帮上忙，涉及到时序、信号干扰的，还得靠示波器和逻辑分析仪。

用法是：自己想不到方向的时候，拿它当一个有经验的同事来问。不一定对，但能拓宽排查思路。

让它对比两个版本的代码差异

这个场景很具体，但用好了能省不少时间。

项目迭代的时候，经常需要知道某个版本改了什么。尤其别人改的代码，你接手后要快速理解他改了哪些地方、为什么改。

它的总结大部分是准确的。参数值从A改成了B，它会告诉你。新增了一个条件分支，它会梳理出新的判断逻辑。

不准确的地方在于为什么改。一个参数从100改成200，可能看不出来是为了修复某个客户现场的特殊工况。这种业务背景还是得问改代码的人，或者告诉AI。

用它生成函数文档初稿

写文档这件事，在嵌入式团队里一直是个老大难问题。不是工程师不想写，是写了也没人看，不写又不行。但有些文档确实有必要，比如对外接口说明、模块功能描述、参数含义。

我的做法是让AI根据代码自动生成一份文档初稿。函数功能描述、参数说明、返回值、调用关系，这些它都能从代码里提取出来，格式也帮你排好。

生成的初稿大概能用到70%到80%。函数做了什么事、参数是什么类型、返回什么值，这些基本准确。

剩下20%到30%需要你自己补。补什么？业务背景。比如为什么这个参数的范围是0到255而不是0到100。这个函数在什么场景下会被调用。调用顺序不对会有什么后果。这些是代码里看不出来的东西，是人的经验。

但就算只帮你生成70%，也比从零写快5倍以上。改一份现成的初稿和面对一个空白文档，那个心理压力完全不一样。

这几个用法，核心逻辑就一句话：让AI做它能做的，人补它做不了的。

AI擅长什么？从已有信息里提取、整理、对比、总结。代码里写了什么，它能梳理出来。两个版本改了什么，它能对比出来。一段逻辑在干什么，它能解释出来。

AI不擅长什么？理解代码之外的上下文。硬件约束、业务背景、历史决策、客户特殊要求，这些信息不在代码里，在人的脑子里。

所以AI在嵌入式的价值，不是替你干活。是帮你省掉重复性高的工作，省下来的时间花在需要你判断的事情上。

有AI相关问题欢迎加我微信交流：603311638