一、聲明及前言

小編作為一名一線MCU系統(tǒng)應(yīng)用工程師，既從事MCU底層驅(qū)動開發(fā)，也涉足MCU應(yīng)用層開發(fā)。早在 2022 年就開始嘗試使用 OpenAI 推出的 ChatGPT-3.5 輔助進行編程。隨著近年來 AI 大模型的指數(shù)級發(fā)展，我深切感受到：AI輔助MCU程序開發(fā)的時代已經(jīng)到來，且不可逆轉(zhuǎn)。無論我們選擇擁抱、亦或是忽視甚至拒絕，都無法改變AI輔助編程席卷整個編程領(lǐng)域的事實。與其被動應(yīng)對，不如主動掌握這一強大工具。

二、什么是生成式AI? 一個MCU軟件開發(fā)者的視角

簡單來說，就是"會幫你寫代碼的聊天機器人"。想象一下，你有一個經(jīng)驗豐富的同事：

他看過無數(shù)代碼和技術(shù)文檔，熟悉各種軟件技術(shù)棧，了解常見的嵌入式開發(fā)模式和最佳實踐

24小時在線，隨時可以幫你寫代碼、解釋問題、提供建議

沒有“他”之前,我們可能是這樣工作的:

現(xiàn)在有了AI:

比如說，按傳統(tǒng)方式你需要為一個新的 MCU 編寫 SPI 驅(qū)動：

那么使用AI，會變成這樣子：

如果你之前從未使用過生成式AI(下文簡稱AI)輔助編程，看到這里可能會欣喜若狂，但我得先潑一盆冷水：要記住，AI也不是萬能的。

AI的答案無法保證正確：甚至無法保證生成的代碼能夠編譯通過。AI 給出的答案會犯錯，絕不可 100%相信。在嵌入式編程領(lǐng)域，這點尤其突出。

AI不了解你的具體硬件環(huán)境：嵌入式程序不同于 PC 上運行的通用高級語言程序，受硬件資源限制極大——不同 MCU 型號的 Flash、RAM、外設(shè)都不一樣。如果不能將這些信息準確告知 AI，基本無法指望它一次生成可用代碼。

AI不能替代測試：因為和硬件緊密相關(guān),AI生成的嵌入式代碼在大部分情況下還需要由人類開發(fā)者搭設(shè)的硬件平臺自行測試驗證和調(diào)試。

AI就像一個非常博學(xué)但經(jīng)常會出錯的編程助手。用好了能大幅提升效率，但最終的代碼質(zhì)量把控還是要靠我們自己。

題外話: 我覺的微軟的AI編程助手 Copliot 名字起的不錯: AI就像你的副駕駛,它可以幫你完成很多工作,但永遠無法替代你。

三、大模型背景及主流工具介紹

3.1 主流大模型介紹

基于小編實際使用經(jīng)驗，以下幾個大模型在輔助編程開發(fā)場景中表現(xiàn)突出:

1. Claude 4。5 Sonnet(Anthropic): 新一代混合推理模型，在長時自主運行、工具使用和復(fù)雜任務(wù)處理上顯著提升，具備更強的代碼生成與多步驟推理能力，支持超大規(guī)模上下文。

2. Claude Opus(Anthropic): 目前最強大的模型。它在復(fù)雜問題解決方面表現(xiàn)卓越，特別適合驅(qū)動前沿 AIAgent系統(tǒng)。

3. GPT-5(OpenAI): OpenAI的強大模型，在推理能力和處理速度上實現(xiàn)顯著提升。

4. Grok 4(xAI ): 具備多智能體推理架構(gòu)、博士級全領(lǐng)域?qū)I(yè)能力。

還有一些其他大模型，如DeepSeek、Llama、Kimi等同樣優(yōu)秀，但基于實際使用經(jīng)驗和開發(fā)效率考慮，上述4個模型在MCU開發(fā)場景中表現(xiàn)更為突出。不過AI模型的性能隨著各家迭代日新月異，建議開發(fā)者保持關(guān)注并適時調(diào)整工具選擇。另外, 評測大模型在各個專業(yè)領(lǐng)域的能力有很多基準測試, 如HumanEval, MBPP等。一些第三方網(wǎng)站如人主頁 - DataLearnerAI等也提供了最新的基于各種測試標準的大模型排行榜:

3.2 Agent：會自己干活的AI

上節(jié)所描述的各個大模型實際上都是"發(fā)動機"，提供核心的理解和生成能力。但面對復(fù)雜的編程開發(fā)環(huán)境時，單獨使用它們效率較低：你在網(wǎng)頁版ChatGPT里問問題，需要手動復(fù)制代碼、粘貼、等待回復(fù)、再復(fù)制回編輯器、檢查編譯調(diào)試……Agent就是用來解決這個問題的——它是一個會自己干活的AI。

3.3 主流AI輔助編程工具

目前，基于AI的輔助編程已經(jīng)發(fā)展出了多種Agent工具和集成方案，早已不局限于直接跟大模型"聊天"的對話模式。這些工具主要分為兩個陣營：

第一陣營：VS Code插件派

代表：GitHub Copilot、Cody、Continue、Augment, 他們是VS Code的一個插件。插件市場安裝后即可使用

優(yōu)勢：保留你的VS Code配置、快捷鍵、其他插件，可時裝多個，按需切換

第二陣營：獨立IDE派(VS Code衍生產(chǎn)品)

代表：Cursor、TRAE: 基于VS Code源碼深度定制，提供與VS Code并行的完整IDE體驗環(huán)境

優(yōu)勢：獨家的AI助手功能深度集成，用戶界面深度優(yōu)化，AI界面更個性化，用戶體驗更好

3.4 如何選擇

目前的AI輔助編程工具主要支持VS Code生態(tài)，尚未直接集成到MCUXpresso、Keil、IAR等傳統(tǒng)嵌入式IDE中。這反映了一個現(xiàn)實：通用編程工具的發(fā)展速度往往快于專業(yè)領(lǐng)域編程工具。

方案一：完全遷移到VS Code: VS Code憑借強大的插件系統(tǒng)，目前已經(jīng)可以承擔(dān)幾乎所有NXP MCU編程IDE的功能, 目前, NXP官方開發(fā)的MCUXpresso for VSCode插件幾乎就是把MCUXpresso IDE"搬到"了VS Code上。MCUXpresso for VS Code插件提供了完整的編輯、編譯、下載、調(diào)試功能。

方案二：如果你暫時不想完全遷移,也可以繼續(xù)使用原來的IDE,只是把VS Code當(dāng)作一個帶AI功能的超級編輯器。

方案三: 不使用VS Code或者VS Code衍生品,直接和AI“聊天”式輔助編程,或者使用獨立的App產(chǎn)品(如Monica,Kimi) 等, 或者直接使用各大AI平臺提供的web頁面, 這其實也是不錯的選擇。

四、體驗-基于NXP FRDM-MCXA346+VS Code Copliot插件

本節(jié)將基于NXP FRDM-MCXA346硬件平臺，使用VS Code+ GitHub Copilot插件作為開發(fā)環(huán)境，帶你完成一次AI輔助編程的初體驗。

4.1 準備工作

硬件平臺：FRDM-MCXA346 開發(fā)板

開發(fā)環(huán)境：VS Code+ GitHub Copilot插件

SDK獲取: 關(guān)于FRDM-MCXA346的入門指南及SDK下載，請參考：Getting Started with FRDM-MCXA346 | NXP Semiconductors.

本節(jié)內(nèi)容不綁定特定IDE。無論你使用Keil、IAR還是MCUXpresso，都可以跟隨本教程——我們只是將VSCode作為一個帶AI助手功能的"超級編輯器"使用。開發(fā)過程中的編譯、下載、調(diào)試等功能，仍可以使用你熟悉的工具鏈完成。

4.2 快速上手

假設(shè)你已經(jīng)：

下載了FRDM-MCXA346的SDK并運行過SDK中 HelloWorld示例,熟悉基本的硬件連接

下載并使用過VS Code

4.2.1 第一步：安裝GitHub Copilot插件

在VS Code擴展市場中搜索并安裝以下兩個插件：

GitHub Copilot - 核心代碼生成引擎

GitHub Copilot Chat - 對話式交互界面

4.2.2 第二步：導(dǎo)入項目

將MCUXpresso Config Tool生成的工程源代碼目錄直接拖拽進VS Code，并使用快捷鍵 Ctrl+Alt+I 呼出Copilot聊天框

4.2.3 第三步：開始使用

就這么簡單, 你已經(jīng)完成了所有設(shè)置。現(xiàn)在可以隨心所欲地使用AI輔助編程了。關(guān)于Copilot插件的詳細使用指南，可以查看官方教程文檔：Getting started with GitHub Copilot · GitHub

4.3 實戰(zhàn)演示

讓我們嘗試一個簡單的任務(wù)，看看Copilot回答的如何。使用默認的Agent模式（Auto Mode自動選擇大模型）

向AI提問：

可以看到，Copilot基本完成了任務(wù)。雖然不能一次性完美編譯通過并運行，但AI給出了一個八九不離十的答案——只需人工稍加檢查或少量修改，代碼基本可用。這為程序開發(fā)節(jié)省了大量時間。

Copilot支持多種工作模式，并可對接多種大模型。你可以慢慢探索這些功能：

Chat模式：對話式問答，適合咨詢和學(xué)習(xí)

Agent模式：自主完成復(fù)雜任務(wù)，可自動調(diào)用本地工具改寫代碼

Edit模式：直接在代碼中進行AI輔助編輯

Inline模式：實時代碼補全，像"智能提示"的超級版

通過這個簡單的體驗，你可能已經(jīng)感受到AI輔助編程的強大。接下來的章節(jié)，我們將分享一些實戰(zhàn)經(jīng)驗，幫助你更高效地使用AI輔助MCU開發(fā)。

五、經(jīng)驗分享

在我使用AI編程開發(fā)中，我總結(jié)了幾條經(jīng)驗，借此機會和大家分享。

5.1 迭代式驗證思維：像調(diào)試電路一樣使用AI編程

為什么不能把問題一次性丟給 AI，期待它給出一個相對完美的答案，一次搞定整個問題。想象你在調(diào)試一個復(fù)雜電路：如果整個電路不工作，你會怎么做？

錯誤做法：盯著整個電路圖，試圖一眼看出所有問題

正確做法：用示波器一級一級測試，從電源開始，逐步驗證每個模塊

AI編程也是同樣道理。不要指望一次性讓AI生成100%完美的解決方案,這是不可能的。 你需要分步迭代完成。

5.1.1 舉例

UART+DMA完成串口數(shù)據(jù)不定長接收: 這是MCU編程中常見的業(yè)務(wù)場景，幾乎所有的使用到串口的產(chǎn)品程序中都需要這樣的功能實現(xiàn)。 如果一次性的將這個任務(wù)讓AI去做,多半不能得到很好的結(jié)果。

你需要將任務(wù)分解: 比如上面任務(wù)可以分解為：

如果能將任務(wù)分解并一項一項的交給AI去幫你完成,且每一步輸出的結(jié)果都你都驗證通過了,那么這樣做的成功率比一次性讓AI完成要高得多。

一個好的分步策略應(yīng)該是:

5.1.2 為什么這樣更有效？

1）降低復(fù)雜度: 復(fù)雜問題 = 多個簡單問題的排列組合, 讓AI處理簡單問題的成功率遠高于復(fù)雜問題

2）間接建立了上下文: 每次成功的代碼都成為下次的"參考答案", AI逐漸理解你的編程習(xí)慣和項目特點, 像培養(yǎng)默契，越來越順手

3）快速定位問題: 如果某一步出錯，你立即知道問題在哪,不用在一大堆代碼里找bug,修改成本低，AI重新生成的代碼量小,這樣避免AI自己完全推翻自己之前的結(jié)果

5.2 用AI發(fā)現(xiàn)可能的“輪子”

一個合格的軟件工程師，要知道采用別人已經(jīng)寫好的，被長期證明運行無誤的源代碼，作為自己開發(fā)新產(chǎn)品的工具，而不是自己去實現(xiàn)每一個功能。這樣，才能把精力集中在解決前人未解決的問題上，而不是做低水平的重復(fù)。我們平時工作所遇到的編程任務(wù)，其中很大一部分可能早已有了標準、高效的解決方法。所以如果遇到一個問題，可以嘗試問自己，我需要的功能（組件/函數(shù)）是不是已經(jīng)有了相對成熟的方案，可以嘗試去問AI類似的問題，也許會有意想不到的新發(fā)現(xiàn)。

5.2.1 舉例

假設(shè)你在MCU項目中需要通過串口接收和解析用戶命令：

傳統(tǒng)做法：

不如換一種思路：

這樣你就發(fā)現(xiàn)一些成熟的組件來實現(xiàn)這個任務(wù), 大可不必從零開始寫命令行解析組件。

5.2.2 為什么這樣更有效？

1. 代碼更健壯：代碼經(jīng)過大量項目實戰(zhàn)驗證，邊界條件處理完善

2. 維護成本低：基于標準接口，以及豐富的文檔, 后續(xù)擴展容易

通過AI發(fā)現(xiàn)這些"輪子"，你不僅節(jié)省了開發(fā)時間，更重要的是獲得了更高質(zhì)量、更安全的解決方案。

5.3 重視提示詞和上下文語料

提示詞（Prompt）就是你給 AI 的任務(wù)說明書，而上下文語料則是你提供的項目背景及參考資料。說明書寫得越清楚、背景資料越完整，AI 就越能給出符合需求的代碼。提示詞的質(zhì)量直接決定了 AI 輸出的質(zhì)量。

5.3.1 舉例1

假設(shè)你需要為MCU實現(xiàn)一個按鍵防抖功能?？纯床煌崾驹~帶來的差異：

糟糕的提示詞:

AI可能給你一個"通用"但不實用的代碼框架：不知道用在什么平臺、不清楚是輪詢還是中斷方式、防抖時間是多少、要支持幾個按鍵。。。

比較好的提示詞:

好的提示詞需要盡量詳細、規(guī)范地描述任務(wù)要求的所有約束信息，編寫 AI 提示詞也有章可循。以下是一個好提示詞的幾個重要要素：

另外,目前大多數(shù)主流AI輔助編程軟件都有提示詞優(yōu)化選項,可以幫你優(yōu)化你的提示詞。

上下文可以看作是提示詞的拓展和參考資料。 他提供了更加豐富的參考信息。 在嵌入式開發(fā)中，上下文語料可以包括：芯片數(shù)據(jù)手冊關(guān)鍵章節(jié)、原理圖、引腳配置表、時鐘樹配置, SDK的API文檔、相關(guān)源文件,頭文件等等。

5.3.2 舉例2

沒有上下文語料:

提供充分上下文語料：

除此之外,還可以結(jié)合之前提出的“迭代式驗證”思想, 漸進式提供,即不要一次性扔給AI一堆文件,而是分步驟,分層提供:

同時，要記得AI非常擅長“照貓畫虎”，如果你有類似的代碼，提供給AI作為參考：

這樣AI會使用相同的命名規(guī)范、保持一致的錯誤處理方式、遵循相同的注釋風(fēng)格、匹配現(xiàn)有的架構(gòu)模式。

5.3.3 為什么這樣更有效?

AI不是"搜索引擎"，而是"概率預(yù)測器", 很多人誤以為AI像搜索引擎一樣，在龐大的代碼庫中"查找"答案。實際上，AI是基于概率預(yù)測下一個最可能出現(xiàn)的詞（token)

想象一個填空題：

人類工程師會填"防抖"或者“消抖”，因為我們理解了上下文。AI也是類似的原理，但它是通過訓(xùn)練時見過的海量代碼和文檔，學(xué)會了"在什么樣的上下文中，什么樣的代碼最可能出現(xiàn)"。AI生成的每一個字符都依賴于前面的所有內(nèi)容（提示詞+上下文語料+之前的AI輸出文本）。你提供的信息越精確，AI預(yù)測出"正確答案"的概率就越高。

提示詞和上下文語料的作用,相當(dāng)于縮小“解空間”, 編程問題的解決方案有無數(shù)種。比如"實現(xiàn)一個延時函數(shù)"，可以是：

空循環(huán)延時

定時器延時

系統(tǒng)節(jié)拍延時

DMA+定時器的零CPU占用延時

當(dāng)你只說"寫個延時函數(shù)"，AI面對的是一個巨大的"解空間"，它只能給出最通用（往往也是最不適用）的答案。

但當(dāng)你說：

你實際上做了三件事：

1.縮小解空間：明確了要用FreeRTOS的API，排除了其他方案

2.提供約束條件：精確到ms、非阻塞、低功耗，這些都是"過濾器"

3.給出應(yīng)用場景：周期性采集，AI會考慮相關(guān)的最佳實踐

此時AI面對的是一個小得多的"解空間"，預(yù)測出正確答案的概率大大提高。投入時間寫好提示詞和準備上下文，能節(jié)省數(shù)倍的調(diào)試時間。

5.4 代碼片段比文字描述更有效

AI理解代碼的能力一般會超過自然語言。這基于編程語言本身的優(yōu)勢——它比人類語言更精確、無歧義。

5.4.1 舉例

在與AI的對話中，一段5行的代碼片段往往比500字的文字描述更有價值。

5.5 比較適用于AI完成的工作

了解AI的能力邊界——知道什么能做、什么不能做，才能最大化工具價值。

5.5.1 通用算法實現(xiàn)

標準通信協(xié)議（Modbus、CAN解析、JSON處理）

經(jīng)典算法（CRC/校驗和、濾波器、PID控制）

數(shù)據(jù)結(jié)構(gòu)（環(huán)形緩沖區(qū)、鏈表、狀態(tài)機）

字符串處理（命令解析、格式轉(zhuǎn)換）

為什么？ 這些都是"公共知識"，在AI的訓(xùn)練集中有海量樣本。

例如：

如果在GitHub上能搜到100+個類似實現(xiàn)，AI就能做得很好；如果只能在芯片手冊里找到，就需要你提供詳細上下文。

5.5.2 代碼審查與優(yōu)化

AI對已有代碼的分析能力往往超過生成能力。這是因為"理解"相比"創(chuàng)造" 相當(dāng)于已經(jīng)提供了十分豐富的上下文語料。

AI能發(fā)現(xiàn)的典型問題：(實際上并不一定合理,需要人工檢查)

AI會像經(jīng)驗豐富的代碼審查員一樣，逐項給出分析報告。

5.5.3 文檔生成

AI也十分擅長幫你處理很多”臟話累活”, 比如文檔生成:

例子1: 自動生成Doxygen注釋：

例子2: 生成模塊級文檔：

核心原則：AI在"信息充分"的領(lǐng)域表現(xiàn)優(yōu)秀，在"硬件特定"的領(lǐng)域需要人類的專業(yè)判斷和把關(guān)。把AI當(dāng)作"初級工程師+資深審查員"的組合來使用，而不是期待它成為"嵌入式底層專家"。

從功能上說: AI比較適合上層應(yīng)用,”通用知識(比如一個常用協(xié)議的實現(xiàn),CRC校驗的軟件計算等)”, 而不太擅長于非常底層的MCU 驅(qū)動代碼編寫,尤其是新MCU的寄存器級別的代碼生成。 這很容易理解, 用于訓(xùn)練AI的訓(xùn)練集肯定更多的來自于“公共代碼”, MCU的底層驅(qū)動很少被訓(xùn)練。

對已有代碼進行優(yōu)化: AI更擅長對已經(jīng)存在的代碼(你喂給AI的上下文)進行檢查,優(yōu)化,檢查錯誤。增加注釋等。 這相當(dāng)于前面說的,你已經(jīng)提供了相關(guān)性極高的上下文語料。

輔助調(diào)試: AI擅長于錯誤日志分析, 編譯錯誤檢查,前提是把報錯的代碼片段和報錯日志喂給AI。

文檔生成: AI擅長于對已有代碼添加注釋,生成文檔?？梢怨?jié)約大量時間在一些“臟活累活上。

六、總結(jié)

下表列出來了關(guān)于給出提示詞和上下文語料過程中需要注意的點:

AI的能力邊界:

AI擅長的：

實現(xiàn)你已經(jīng)想清楚的東西（算法、協(xié)議、數(shù)據(jù)結(jié)構(gòu)）

發(fā)現(xiàn)你沒注意到的問題（代碼審查、邊界條件、語法,拼寫檢查等）

完成“臟活累活”（注釋、文檔、重復(fù)勞動）

AI不擅長的：

替你思考系統(tǒng)架構(gòu)

理解物理(硬件)世界:電路調(diào)試,架構(gòu)級功耗優(yōu)化,系統(tǒng)級性能約束等,因為這些任務(wù)往往不能用精確的代碼去描述

為嵌入式系統(tǒng)因地制宜或非常有個性的內(nèi)存管理模式，AI還是更擅長在PC上多見的內(nèi)存“套路”

可以預(yù)見,未來AI在嵌入式輔助編程領(lǐng)域的發(fā)展趨勢:

AI會更懂嵌入式：能理解芯片手冊、識別硬件原理圖、分析示波器波形

工具會更智能：從"代碼補全"進化到"需求實現(xiàn)"，你說要什么功能，AI自己規(guī)劃、編碼、測試(目前已經(jīng)初現(xiàn)端倪)

成本會更低：現(xiàn)在還需要付費訂閱，未來可能像搜索引擎一樣成為基礎(chǔ)設(shè)施

可能出現(xiàn)專門針對嵌入式的AI模型，訓(xùn)練集包含大量芯片手冊、應(yīng)用筆記、硬件設(shè)計

多模態(tài)交互會成為現(xiàn)實：你畫個時序圖、拍張電路板照片，AI就能生成驅(qū)動代碼

但是, 嵌入式中硬件調(diào)試、性能優(yōu)化、功耗優(yōu)化等類似任務(wù) -- 這些需要深度理解物理世界的工作，短期內(nèi)AI還無法完全替代人類。 AI只是讓我們能更快地把想法變成代碼。真正的價值，還是在于你想清楚了要做什么，以及為什么這樣做，對問題本質(zhì)的理解能力，才是工程師最寶貴的財富。