一、声明及前言
小编作为一名一线MCU系统应用工程师，既从事MCU底层驱动开发，也涉足MCU应用层开发。早在 2022 年就开始尝试使用 OpenAI 推出的 ChatGPT-3.5 辅助进行编程。随着近年来 AI 大模型的指数级发展，我深切感受到：AI辅助MCU程序开发的时代已经到来，且不可逆转。无论我们选择拥抱、亦或是忽视甚至拒绝，都无法改变AI辅助编程席卷整个编程领域的事实。与其被动应对，不如主动掌握这一强大工具。
二、什么是生成式AI? 一个MCU软件开发者的视角
简单来说，就是"会帮你写代码的聊天机器人"。想象一下，你有一个经验丰富的同事：
他看过无数代码和技术文档，熟悉各种软件技术栈，了解常见的嵌入式开发模式和最佳实践
24小时在线，随时可以帮你写代码、解释问题、提供建议
没有“他”之前,我们可能是这样工作的:
现在有了AI:
比如说，按传统方式你需要为一个新的 MCU 编写 SPI 驱动：
那么使用AI，会变成这样子：
如果你之前从未使用过生成式AI(下文简称AI)辅助编程，看到这里可能会欣喜若狂，但我得先泼一盆冷水：要记住，AI也不是万能的。
AI的答案无法保证正确：甚至无法保证生成的代码能够编译通过。AI 给出的答案会犯错，绝不可 100%相信。在嵌入式编程领域，这点尤其突出。
AI不了解你的具体硬件环境：嵌入式程序不同于 PC 上运行的通用高级语言程序，受硬件资源限制极大——不同 MCU 型号的 Flash、RAM、外设都不一样。如果不能将这些信息准确告知 AI，基本无法指望它一次生成可用代码。
AI不能替代测试：因为和硬件紧密相关,AI生成的嵌入式代码在大部分情况下还需要由人类开发者搭设的硬件平台自行测试验证和调试。
AI就像一个非常博学但经常会出错的编程助手。用好了能大幅提升效率，但最终的代码质量把控还是要靠我们自己。
题外话: 我觉的微软的AI编程助手 Copliot 名字起的不错: AI就像你的副驾驶,它可以帮你完成很多工作,但永远无法替代你。
三、大模型背景及主流工具介绍
3.1 主流大模型介绍
基于小编实际使用经验，以下几个大模型在辅助编程开发场景中表现突出:
1. Claude 4。5 Sonnet(Anthropic): 新一代混合推理模型，在长时自主运行、工具使用和复杂任务处理上显著提升，具备更强的代码生成与多步骤推理能力，支持超大规模上下文。
2. Claude Opus(Anthropic): 目前最强大的模型。它在复杂问题解决方面表现卓越，特别适合驱动前沿 AIAgent系统。
3. GPT-5(OpenAI): OpenAI的强大模型，在推理能力和处理速度上实现显著提升。
4. Grok 4(xAI ): 具备多智能体推理架构、博士级全领域专业能力。
还有一些其他大模型，如DeepSeek、Llama、Kimi等同样优秀，但基于实际使用经验和开发效率考虑，上述4个模型在MCU开发场景中表现更为突出。不过AI模型的性能随着各家迭代日新月异，建议开发者保持关注并适时调整工具选择。另外, 评测大模型在各个专业领域的能力有很多基准测试, 如HumanEval, MBPP等。一些第三方网站如人主页 - DataLearnerAI等也提供了最新的基于各种测试标准的大模型排行榜:
3.2 Agent：会自己干活的AI
上节所描述的各个大模型实际上都是"发动机"，提供核心的理解和生成能力。但面对复杂的编程开发环境时，单独使用它们效率较低：你在网页版ChatGPT里问问题，需要手动复制代码、粘贴、等待回复、再复制回编辑器、检查编译调试……Agent就是用来解决这个问题的——它是一个会自己干活的AI。
3.3 主流AI辅助编程工具
目前，基于AI的辅助编程已经发展出了多种Agent工具和集成方案，早已不局限于直接跟大模型"聊天"的对话模式。这些工具主要分为两个阵营：
第一阵营：VS Code插件派
代表：GitHub Copilot、Cody、Continue、Augment, 他们是VS Code的一个插件。插件市场安装后即可使用
优势：保留你的VS Code配置、快捷键、其他插件，可时装多个，按需切换
第二阵营：独立IDE派(VS Code衍生产品)
代表：Cursor、TRAE: 基于VS Code源码深度定制，提供与VS Code并行的完整IDE体验环境
优势：独家的AI助手功能深度集成，用户界面深度优化，AI界面更个性化，用户体验更好
3.4 如何选择
目前的AI辅助编程工具主要支持VS Code生态，尚未直接集成到MCUXpresso、Keil、IAR等传统嵌入式IDE中。这反映了一个现实：通用编程工具的发展速度往往快于专业领域编程工具。
方案一：完全迁移到VS Code: VS Code凭借强大的插件系统，目前已经可以承担几乎所有NXP MCU编程IDE的功能, 目前, NXP官方开发的MCUXpresso for VSCode插件几乎就是把MCUXpresso IDE"搬到"了VS Code上。MCUXpresso for VS Code插件提供了完整的编辑、编译、下载、调试功能。
方案二：如果你暂时不想完全迁移,也可以继续使用原来的IDE,只是把VS Code当作一个带AI功能的超级编辑器。
方案三: 不使用VS Code或者VS Code衍生品,直接和AI“聊天”式辅助编程,或者使用独立的App产品(如Monica,Kimi) 等, 或者直接使用各大AI平台提供的web页面, 这其实也是不错的选择。
四、体验-基于NXP FRDM-MCXA346+VS Code Copliot插件
本节将基于NXP FRDM-MCXA346硬件平台，使用VS Code+ GitHub Copilot插件作为开发环境，带你完成一次AI辅助编程的初体验。
4.1 准备工作
硬件平台：FRDM-MCXA346 开发板
开发环境：VS Code+ GitHub Copilot插件
SDK获取: 关于FRDM-MCXA346的入门指南及SDK下载，请参考：Getting Started with FRDM-MCXA346 | NXP Semiconductors.
本节内容不绑定特定IDE。无论你使用Keil、IAR还是MCUXpresso，都可以跟随本教程——我们只是将VSCode作为一个带AI助手功能的"超级编辑器"使用。开发过程中的编译、下载、调试等功能，仍可以使用你熟悉的工具链完成。
4.2 快速上手
假设你已经：
下载了FRDM-MCXA346的SDK并运行过SDK中 HelloWorld示例,熟悉基本的硬件连接
下载并使用过VS Code
4.2.1 第一步：安装GitHub Copilot插件
在VS Code扩展市场中搜索并安装以下两个插件：
GitHub Copilot - 核心代码生成引擎
GitHub Copilot Chat - 对话式交互界面
4.2.2 第二步：导入项目
将MCUXpresso Config Tool生成的工程源代码目录直接拖拽进VS Code，并使用快捷键 Ctrl+Alt+I 呼出Copilot聊天框
4.2.3 第三步：开始使用
就这么简单, 你已经完成了所有设置。现在可以随心所欲地使用AI辅助编程了。关于Copilot插件的详细使用指南，可以查看官方教程文档： Getting started with GitHub Copilot · GitHub
4.3 实战演示
让我们尝试一个简单的任务，看看Copilot回答的如何。使用默认的Agent模式（Auto Mode自动选择大模型）
向AI提问：
可以看到，Copilot基本完成了任务。虽然不能一次性完美编译通过并运行，但AI给出了一个八九不离十的答案——只需人工稍加检查或少量修改，代码基本可用。这为程序开发节省了大量时间。
Copilot支持多种工作模式，并可对接多种大模型。你可以慢慢探索这些功能：
Chat模式：对话式问答，适合咨询和学习
Agent模式：自主完成复杂任务，可自动调用本地工具改写代码
Edit模式：直接在代码中进行AI辅助编辑
Inline模式：实时代码补全，像"智能提示"的超级版
通过这个简单的体验，你可能已经感受到AI辅助编程的强大。接下来的章节，我们将分享一些实战经验，帮助你更高效地使用AI辅助MCU开发。
五、经验分享
在我使用AI编程开发中，我总结了几条经验，借此机会和大家分享。
5.1 迭代式验证思维：像调试电路一样使用AI编程
为什么不能把问题一次性丢给 AI，期待它给出一个相对完美的答案，一次搞定整个问题。想象你在调试一个复杂电路：如果整个电路不工作，你会怎么做？
错误做法：盯着整个电路图，试图一眼看出所有问题
正确做法：用示波器一级一级测试，从电源开始，逐步验证每个模块
AI编程也是同样道理。不要指望一次性让AI生成100%完美的解决方案,这是不可能的。 你需要分步迭代完成。
5.1.1 举例
UART+DMA完成串口数据不定长接收: 这是MCU编程中常见的业务场景，几乎所有的使用到串口的产品程序中都需要这样的功能实现。 如果一次性的将这个任务让AI去做,多半不能得到很好的结果。
你需要将任务分解: 比如上面任务可以分解为：
如果能将任务分解并一项一项的交给AI去帮你完成,且每一步输出的结果都你都验证通过了,那么这样做的成功率比一次性让AI完成要高得多。
一个好的分步策略应该是:
5.1.2 为什么这样更有效？
1）降低复杂度: 复杂问题 = 多个简单问题的排列组合, 让AI处理简单问题的成功率远高于复杂问题
2）间接建立了上下文: 每次成功的代码都成为下次的"参考答案", AI逐渐理解你的编程习惯和项目特点, 像培养默契，越来越顺手
3）快速定位问题: 如果某一步出错，你立即知道问题在哪,不用在一大堆代码里找bug,修改成本低，AI重新生成的代码量小,这样避免AI自己完全推翻自己之前的结果
5.2 用AI发现可能的“轮子”
一个合格的软件工程师，要知道采用别人已经写好的，被长期证明运行无误的源代码，作为自己开发新产品的工具，而不是自己去实现每一个功能。这样，才能把精力集中在解决前人未解决的问题上，而不是做低水平的重复。我们平时工作所遇到的编程任务，其中很大一部分可能早已有了标准、高效的解决方法。所以如果遇到一个问题，可以尝试问自己，我需要的功能（组件/函数）是不是已经有了相对成熟的方案，可以尝试去问AI类似的问题，也许会有意想不到的新发现。
5.2.1 举例
假设你在MCU项目中需要通过串口接收和解析用户命令：
传统做法：
不如换一种思路：
这样你就发现一些成熟的组件来实现这个任务, 大可不必从零开始写命令行解析组件。
5.2.2 为什么这样更有效？
1. 代码更健壮：代码经过大量项目实战验证，边界条件处理完善
2. 维护成本低：基于标准接口，以及丰富的文档, 后续扩展容易
通过AI发现这些"轮子"，你不仅节省了开发时间，更重要的是获得了更高质量、更安全的解决方案。
5.3 重视提示词和上下文语料
提示词（Prompt）就是你给 AI 的任务说明书，而上下文语料则是你提供的项目背景及参考资料。说明书写得越清楚、背景资料越完整，AI 就越能给出符合需求的代码。提示词的质量直接决定了 AI 输出的质量。
5.3.1 举例1
假设你需要为MCU实现一个按键防抖功能。看看不同提示词带来的差异：
糟糕的提示词:
AI可能给你一个"通用"但不实用的代码框架：不知道用在什么平台、不清楚是轮询还是中断方式、防抖时间是多少、要支持几个按键。。。
比较好的提示词:
好的提示词需要尽量详细、规范地描述任务要求的所有约束信息，编写 AI 提示词也有章可循。以下是一个好提示词的几个重要要素：
另外,目前大多数主流AI辅助编程软件都有提示词优化选项,可以帮你优化你的提示词。
上下文可以看作是提示词的拓展和参考资料。 他提供了更加丰富的参考信息。 在嵌入式开发中，上下文语料可以包括：芯片数据手册关键章节、原理图、引脚配置表、时钟树配置, SDK的API文档、相关源文件,头文件等等。
5.3.2 举例2
没有上下文语料:
提供充分上下文语料：
除此之外,还可以结合之前提出的“迭代式验证”思想, 渐进式提供,即不要一次性扔给AI一堆文件,而是分步骤,分层提供:
同时，要记得AI非常擅长“照猫画虎”，如果你有类似的代码，提供给AI作为参考：
这样AI会使用相同的命名规范、保持一致的错误处理方式、遵循相同的注释风格、匹配现有的架构模式。
5.3.3 为什么这样更有效?
AI不是"搜索引擎"，而是"概率预测器", 很多人误以为AI像搜索引擎一样，在庞大的代码库中"查找"答案。实际上，AI是基于概率预测下一个最可能出现的词（token)
想象一个填空题：
人类工程师会填"防抖"或者“消抖”，因为我们理解了上下文。AI也是类似的原理，但它是通过训练时见过的海量代码和文档，学会了"在什么样的上下文中，什么样的代码最可能出现"。AI生成的每一个字符都依赖于前面的所有内容（提示词+上下文语料+之前的AI输出文本）。你提供的信息越精确，AI预测出"正确答案"的概率就越高。
提示词和上下文语料的作用,相当于缩小“解空间”, 编程问题的解决方案有无数种。比如"实现一个延时函数"，可以是：
空循环延时
定时器延时
系统节拍延时
DMA+定时器的零CPU占用延时
当你只说"写个延时函数"，AI面对的是一个巨大的"解空间"，它只能给出最通用（往往也是最不适用）的答案。
但当你说：
你实际上做了三件事：
1. 缩小解空间：明确了要用FreeRTOS的API，排除了其他方案
2. 提供约束条件：精确到ms、非阻塞、低功耗，这些都是"过滤器"
3. 给出应用场景：周期性采集，AI会考虑相关的最佳实践
此时AI面对的是一个小得多的"解空间"，预测出正确答案的概率大大提高。投入时间写好提示词和准备上下文，能节省数倍的调试时间。
5.4 代码片段比文字描述更有效
AI理解代码的能力一般会超过自然语言。这基于编程语言本身的优势——它比人类语言更精确、无歧义。
5.4.1 举例
在与AI的对话中，一段5行的代码片段往往比500字的文字描述更有价值。
5.5 比较适用于AI完成的工作
了解AI的能力边界——知道什么能做、什么不能做，才能最大化工具价值。
5.5.1 通用算法实现
标准通信协议（Modbus、CAN解析、JSON处理）
经典算法（CRC/校验和、滤波器、PID控制）
数据结构（环形缓冲区、链表、状态机）
字符串处理（命令解析、格式转换）
为什么？ 这些都是"公共知识"，在AI的训练集中有海量样本。
例如：
如果在GitHub上能搜到100+个类似实现，AI就能做得很好；如果只能在芯片手册里找到，就需要你提供详细上下文。
5.5.2 代码审查与优化
AI对已有代码的分析能力往往超过生成能力。这是因为"理解"相比"创造" 相当于已经提供了十分丰富的上下文语料。
AI能发现的典型问题：(实际上并不一定合理,需要人工检查)
AI会像经验丰富的代码审查员一样，逐项给出分析报告。
5.5.3 文档生成
AI也十分擅长帮你处理很多”脏话累活”, 比如文档生成:
例子1: 自动生成Doxygen注释：
例子2: 生成模块级文档：
核心原则：AI在"信息充分"的领域表现优秀，在"硬件特定"的领域需要人类的专业判断和把关。把AI当作"初级工程师+资深审查员"的组合来使用，而不是期待它成为"嵌入式底层专家"。
从功能上说: AI比较适合上层应用,”通用知识(比如一个常用协议的实现,CRC校验的软件计算等)”, 而不太擅长于非常底层的MCU 驱动代码编写,尤其是新MCU的寄存器级别的代码生成。 这很容易理解, 用于训练AI的训练集肯定更多的来自于“公共代码”, MCU的底层驱动很少被训练。
对已有代码进行优化: AI更擅长对已经存在的代码(你喂给AI的上下文)进行检查,优化,检查错误。增加注释等。 这相当于前面说的,你已经提供了相关性极高的上下文语料。
辅助调试: AI擅长于错误日志分析, 编译错误检查,前提是把报错的代码片段和报错日志喂给AI。
文档生成: AI擅长于对已有代码添加注释,生成文档。可以节约大量时间在一些“脏活累活上。
六、总结
下表列出来了关于给出提示词和上下文语料过程中需要注意的点:
AI的能力边界:
AI擅长的：
实现你已经想清楚的东西（算法、协议、数据结构）
发现你没注意到的问题（代码审查、边界条件、语法,拼写检查等）
完成“脏活累活”（注释、文档、重复劳动）
AI不擅长的：
替你思考系统架构
理解物理(硬件)世界:电路调试,架构级功耗优化,系统级性能约束等,因为这些任务往往不能用精确的代码去描述
为嵌入式系统因地制宜或非常有个性的内存管理模式，AI还是更擅长在PC上多见的内存“套路”
可以预见,未来AI在嵌入式辅助编程领域的发展趋势:
AI会更懂嵌入式：能理解芯片手册、识别硬件原理图、分析示波器波形
工具会更智能：从"代码补全"进化到"需求实现"，你说要什么功能，AI自己规划、编码、测试(目前已经初现端倪)
成本会更低：现在还需要付费订阅，未来可能像搜索引擎一样成为基础设施
可能出现专门针对嵌入式的AI模型，训练集包含大量芯片手册、应用笔记、硬件设计
多模态交互会成为现实：你画个时序图、拍张电路板照片，AI就能生成驱动代码
但是, 嵌入式中硬件调试、性能优化、功耗优化等类似任务 -- 这些需要深度理解物理世界的工作，短期内AI还无法完全替代人类。 AI只是让我们能更快地把想法变成代码。真正的价值，还是在于你想清楚了要做什么，以及为什么这样做，对问题本质的理解能力，才是工程师最宝贵的财富。
来源：恩智浦MCU加油站
免责声明：本文为转载文章，转载此文目的在于传递更多信息，版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题，请联系小编进行处理（联系邮箱：cathy@eetrend.com）。