目錄

1、不要一上來就讓 AI 寫完整驅(qū)動

2、最適合 AI 的第一類活：讀手冊，整理清單

3、寫代碼時，讓 AI 處理“結(jié)構(gòu)”，不要讓它替你決定“事實”

4、Code review：讓 AI 專門盯嵌入式常見風(fēng)險

5、調(diào)試時，把 AI 當(dāng)“現(xiàn)場記錄整理員”

6、小腳本是 AI 提效最明顯的地方

7、提示詞不用玄學(xué)，講清楚四件事就夠了

8、我現(xiàn)在的實際工作流

9、幾個我會刻意避免的用法

---

這兩年大家都在聊 AI 寫代碼，但嵌入式工程師聽起來多少有點別扭。

因為我們的 bug 不只在屏幕里。板子上電不起來、I2C 偶發(fā) NACK、 DMA 搬了一半數(shù)據(jù)就進 HardFault、低功耗喚醒后外設(shè)狀態(tài)不對，這些問題不是讓 AI 多生成幾行代碼就能解決的。

我自己的感受是：AI 不是“替你寫完整項目”的工具，更像一個反應(yīng)很快的初級同事。它適合幫你查資料、整理思路、寫樣板、做 code review、補 腳本 。最后能不能上板，還是要靠工程師自己對手冊、時序、內(nèi)存和現(xiàn)場現(xiàn)象負(fù)責(zé)。

如果把這個 邊界 想清楚，AI 對嵌入式開發(fā)的效率提升還是很明顯的。

1、不要一上來就讓 AI 寫完整驅(qū)動

很多人第一次用 AI，喜歡直接問：

幫我寫一個 STM32 的 SPI Flash 驅(qū)動。

這種問法大概率會得到一份“看起來挺像”的代碼，但里面可能有幾個問題：

• 芯片型號沒說清楚，AI 會默認(rèn)一個它熟悉的系列；

• HAL、LL、裸寄存器風(fēng)格混在一起；

• 擦除等待、超時、頁邊界處理不完整；

• 忙等待放在了不該阻塞的地方；

• 有些寄存器位甚至是編出來的。

更靠譜的方式是把任務(wù)拆小：

我現(xiàn)在用 STM32G4，工程里用 HAL，不使用動態(tài)內(nèi)存。請只幫我寫 W25Qxx 的頁寫入函數(shù)框架，要求處理頁邊界、超時、錯誤碼返回。底層 SPI 發(fā)送接收函數(shù)已經(jīng)存在，接口如下……

這時 AI 的價值就出來了。它不需要替你決定所有事情，只需要把一段重復(fù)、容易漏邊界的邏輯先鋪出來。你再對照 datasheet 和項目代碼改。

一句話：別讓 AI 當(dāng)主程，讓它先當(dāng)“代碼草稿機”。

2、最適合 AI 的第一類活：讀手冊，整理清單

嵌入式開發(fā)里很耗時間的一件事，是在參考手冊里來回翻。比如配 ADC、CAN、USB、低功耗模式，真正寫代碼前，先要確認(rèn)一堆前置條件。

我現(xiàn)在常用的做法是，把手冊里的相關(guān)段落貼給 AI，然后讓它只做整理，不讓它自由發(fā)揮。

可以這樣問：

下面是某 MCU 參考手冊里關(guān)于 ADC 校準(zhǔn)和啟動流程的段落。
請你整理成初始化檢查清單。
要求：
1. 只使用我提供的內(nèi)容，不要補充手冊里沒有出現(xiàn)的寄存器位；
2. 每一項標(biāo)注“必須做 / 建議做 / 需要結(jié)合項目確認(rèn)”；
3. 如果有不確定的地方，直接寫“需要查手冊確認(rèn)”。

這個提示詞的關(guān)鍵不是“幫我配置 ADC”，而是“整理成檢查清單”。AI 在歸納文字方面很強，但在憑空判斷寄存器細節(jié)時不可靠。

整理出來以后，你再對照手冊確認(rèn)。這樣比自己從頭啃文檔快很多，也不容易漏掉類似“先關(guān) ADC 再校準(zhǔn)”“某個位需要等待硬件清零”這種細節(jié)。

3、寫代碼時，讓 AI 處理“結(jié)構(gòu)”，不要讓它替你決定“事實”

嵌入式代碼里有兩類東西。

一類是結(jié)構(gòu)性的，比如狀態(tài)機、錯誤碼、超時重試、參數(shù)檢查、日志格式、單元測試框架。這些很適合 AI。

另一類是事實性的，比如寄存器定義、時鐘樹、DMA 通道映射、引腳復(fù)用、電氣限制、外設(shè) errata。這些必須由工程師確認(rèn)。

舉個例子，如果要寫一個傳感器采集任務(wù)，我不會讓 AI 直接寫最終代碼。我會讓它先寫狀態(tài)機：

請根據(jù)下面的約束，設(shè)計一個非阻塞傳感器采集狀態(tài)機。

背景：
- MCU: STM32F407
- RTOS: FreeRTOS
- 傳感器通過 I2C 讀取
- 采樣周期 10ms
- 不能在任務(wù)中長時間阻塞
- I2C 底層接口已經(jīng)封裝為 async_read / async_write

請輸出：
1. 狀態(tài)枚舉；
2. 每個狀態(tài)的進入條件和退出條件；
3. 超時和重試策略；
4. C 語言代碼骨架；
5. 需要我人工確認(rèn)的點。

這個問題問完，AI 通常能給出一個還不錯的框架。即使代碼不能直接用，也能幫你把狀態(tài)拆清楚。

尤其是調(diào)試一些“跑一晚上才復(fù)現(xiàn)”的問題時，狀態(tài)機比散落在各處的 if/else 更容易定位。AI 在這類整理工作上，確實能節(jié)省不少腦力。

4、Code review：讓 AI 專門盯嵌入式常見風(fēng)險

AI 做 review 也有用，但不能只問“這段代碼有沒有問題”。這個問題太大，它容易給你一些沒什么價值的建議，比如命名可以更清晰、注釋可以更多。

我更喜歡讓它從幾個固定角度看：

請只從嵌入式軟件風(fēng)險角度審查下面這段 C 代碼。

重點關(guān)注：
1. 中斷上下文是否調(diào)用了不安全函數(shù)；
2. 是否存在數(shù)組越界、整數(shù)溢出、未對齊訪問；
3. 是否有競態(tài)條件或 volatile 使用問題；
4. 是否存在阻塞等待導(dǎo)致實時性變差；
5. 錯誤分支是否會造成資源狀態(tài)不一致。

輸出格式：
- 風(fēng)險等級：高 / 中 / 低
- 觸發(fā)條件
- 可能后果
- 修改建議

這類 review 對老工程尤其有幫助。很多項目里都有一些歷史代碼，大家只敢小心翼翼地改。讓 AI 先掃一遍風(fēng)險點，再由你判斷是否真的要動，可以降低閱讀成本。

我遇到過幾次比較有價值的提醒，比如：

• ISR 里調(diào)用了可能拿鎖的函數(shù)；
• DMA buffer 沒有考慮 cache 一致性；
• 16 位長度字段參與計算時可能溢出；
• 超時計數(shù)用有符號整數(shù)，長時間運行后邊界不清晰；
• 共享變量沒有 volatile，或者只加了 volatile 但沒有解決原子性問題。

這些問題 AI 不一定每次都抓得準(zhǔn)，但它能幫你多一輪視角。工程師最后要做的是判斷，不是照單全收。

5、調(diào)試時，把 AI 當(dāng)“現(xiàn)場記錄整理員”

嵌入式調(diào)試最怕現(xiàn)場信息散。串口日志一堆，F(xiàn)ault 寄存器一組，map 文件一個，調(diào)用棧半截，腦子里還記著剛剛改過哪個宏。

這時 AI 可以幫你整理線索。

比如 HardFault，可以把這些信息丟給它：

• CFSR、HFSR、MMFAR、BFAR；
• PC、LR、SP；
• 反匯編附近幾行；
• map 文件里對應(yīng)地址；
• 最近一次改動；
• 是否開了優(yōu)化、是否用了 FPU、是否有中斷嵌套。

提示詞可以這樣寫：

下面是一次 Cortex-M HardFault 的現(xiàn)場信息。
請不要直接下結(jié)論，先按證據(jù)鏈分析。

請輸出：
1. 每個寄存器值可能代表什么；
2. 當(dāng)前最可能的 3 個方向；
3. 每個方向還需要補充什么信息；
4. 建議我下一步在代碼里加哪些斷點或日志。

這樣得到的結(jié)果通常比“告訴我為什么 HardFault”靠譜。它會先幫你把問題分成幾條線：空指針、棧溢出、非法地址、未對齊訪問、總線錯誤、FPU 上下文等。

真正的結(jié)論還是要靠調(diào)試器和現(xiàn)場復(fù)現(xiàn)，但 AI 能把排查路徑整理得更清楚。

6、小腳本是 AI 提效最明顯的地方

如果只能推薦一個最容易見效的用法，我會推薦：讓 AI 幫你寫腳本。

嵌入式項目里有大量“不是主業(yè)務(wù)，但天天要用”的小工具：

• 解析串口日志，統(tǒng)計錯誤碼出現(xiàn)次數(shù)；
• 從 map 文件里提取 RAM / Flash 占用；
• 批量比較兩個固件版本的符號變化；
• 把寄存器 dump 轉(zhuǎn)成表格；
• 從 Excel 配置表生成 C 頭文件；
• 掃描工程里所有 TODO、FIXME、裸延時和魔法數(shù)字。

這些腳本讓人自己寫也能寫，但經(jīng)常懶得動手。AI 最大的好處是把啟動成本降下來了。

比如你可以直接說：

幫我寫一個 Python 腳本，解析 Keil 生成的 map 文件。
輸出：
1. Flash 總占用；
2. RAM 總占用；
3. 占用最大的前 20 個符號；
4. 結(jié)果保存成 csv。

要求腳本可以通過命令行傳入 map 文件路徑。

這種任務(wù)不涉及硬件事實，反饋也快，跑一下就知道對不對。用 AI 寫腳本，是我認(rèn)為最穩(wěn)的提效方式之一。

7、提示詞不用玄學(xué)，講清楚四件事就夠了

很多文章會把提示詞講得很玄。我的經(jīng)驗是，嵌入式場景里不用復(fù)雜套路，講清楚四件事就夠：

1. 背景：芯片、RTOS、編譯器、代碼風(fēng)格、已有接口；
2. 約束：不能阻塞、不能動態(tài)分配、ISR 限制、內(nèi)存限制；
3. 任務(wù)：只生成框架、只 review、只整理清單、只分析日志；
4. 輸出：表格、diff、檢查項、風(fēng)險等級、待確認(rèn)列表。

我常用的結(jié)尾是這一句：

不確定的地方請明確標(biāo)注“需要人工確認(rèn)”，不要自行假設(shè)。

這句話很重要。因為 AI 最大的問題不是“不知道”，而是“不知道的時候也會說得很順”。

8、我現(xiàn)在的實際工作流

現(xiàn)在我在項目里用 AI，大概是這個流程：

第一步，先自己讀一遍需求和關(guān)鍵手冊，知道問題的大方向。

第二步，把局部上下文給 AI，讓它整理清單、生成骨架或列風(fēng)險點。

第三步，自己對照手冊、工程代碼和硬件設(shè)計確認(rèn)關(guān)鍵事實。

第四步，編譯、靜態(tài)檢查、上板測試。尤其是時序、功耗、異?；謴?fù)，必須實測。

第五步，把這次有用的提示詞和排查過程沉淀下來。下次遇到類似外設(shè)或類似 bug，可以直接復(fù)用。

這個流程不炫，但很實用。AI 負(fù)責(zé)把重復(fù)勞動做快一點，工程師負(fù)責(zé)判斷哪些東西能進代碼庫。

9、幾個我會刻意避免的用法

有些用法看起來省事，實際風(fēng)險很高。

第一，不讓 AI 憑空寫寄存器配置。尤其是小眾 MCU、國產(chǎn)芯片、特定外設(shè)，模型很容易把別的系列經(jīng)驗套過來。

第二，不直接復(fù)制 AI 生成的中斷代碼。ISR 里的阻塞、鎖、日志、內(nèi)存分配，都可能帶來很隱蔽的問題。

第三，不讓 AI 直接改大段歷史代碼。老工程里很多寫法看著奇怪，但可能是為了繞硬件問題、兼容量產(chǎn)版本或規(guī)避 errata。

第四，不把 AI 的解釋當(dāng)結(jié)論。它可以給方向，但不能代替示波器、邏輯分析儀、調(diào)試器和壓力測試。

嵌入式工程師用 AI，最重要的不是“會不會寫提示詞”，而是有沒有邊界感。

讓 AI 幫你讀資料、搭結(jié)構(gòu)、補腳本、查風(fēng)險，它會很好用。讓它替你確認(rèn)寄存器、替你理解硬件、替你背質(zhì)量責(zé)任，那遲早會出問題。

真正有價值的用法，是把 AI 放進原來的工程流程里：需求還是要拆，手冊還是要看，代碼還是要審，板子還是要測。只不過那些重復(fù)、瑣碎、容易分心的部分，可以交給 AI 先跑一遍。

這樣用下來，它不像一個“神奇工具”，更像一個隨叫隨到的工程助手。

它不替你上板，但能讓你更快走到上板那一步。