說實(shí)話接觸AI編程工具一年多真正用進(jìn)嵌入式項(xiàng)目之后我最大的感受是這行當(dāng)?shù)拈_發(fā)范式該變了。不是說要丟掉C語言、丟掉調(diào)試器而是從“一個(gè)人趴在代碼里摳每一個(gè)字節(jié)”慢慢轉(zhuǎn)向“人定義規(guī)則和邊界AI去填那些重復(fù)的模式化代碼”。這篇是這個(gè)系列的第二篇我想認(rèn)真聊聊面向AI協(xié)同的嵌入式軟件開發(fā)范式——不吹A(chǔ)I多神也不無腦貶低就說清楚這套協(xié)作流程里什么該交給AI什么必須攥在自己手里以及具體到代碼層面怎么落地、怎么驗(yàn)證、怎么避免翻車。我最早接觸這個(gè)范式是因?yàn)橐粋€(gè)UART DMA驅(qū)動(dòng)的需求。當(dāng)時(shí)把需求丟給AI生成的第一版代碼邏輯看著完全沒問題結(jié)果燒到板子上接收的數(shù)據(jù)隔三差五就亂一個(gè)字節(jié)。排查了整整兩天最后發(fā)現(xiàn)是DMA描述符鏈表在Cache一致性上沒有做處理。這個(gè)事給了我一個(gè)特別重要的教訓(xùn)AI能幫你寫出80%的代碼但剩下那20%的硬件邊界知識(shí)如果自己心里沒數(shù)AI生成的代碼就是一顆定時(shí)炸彈。所以從這個(gè)案例開始我一直在琢磨到底怎么跟AI協(xié)作才靠譜——后來慢慢總結(jié)出了一套方法論就是今天要聊的“面向AI協(xié)同的嵌入式軟件開發(fā)范式”。1. 開發(fā)范式轉(zhuǎn)變從人肉編碼到“意圖工程師”1.1 傳統(tǒng)嵌入式開發(fā)模式的困局干嵌入式這些年最常見的開發(fā)流程是看芯片手冊(cè)、翻參考代碼、寫驅(qū)動(dòng)、燒錄、調(diào)bug。一個(gè)稍有經(jīng)驗(yàn)的工程師大量時(shí)間其實(shí)花在“搬運(yùn)”上——把數(shù)據(jù)手冊(cè)里的寄存器操作翻譯成C代碼把廠商庫函數(shù)拼接到自己的工程里把以前項(xiàng)目里類似模塊的代碼拷過來改改。真正需要?jiǎng)幽X子設(shè)計(jì)的部分可能只占兩到三成。這種模式本身沒什么問題但它有一個(gè)致命弱點(diǎn)效率天花板太明顯。芯片手冊(cè)上千頁寄存器描述密密麻麻如果你接手的是一顆不太熟悉的新型號(hào)光是把基礎(chǔ)外設(shè)的點(diǎn)燈、串口、I2C調(diào)通可能就得耗掉一兩個(gè)星期。而這其中真正有技術(shù)含量的是“為什么這么配置”以及“配置后硬件會(huì)怎么表現(xiàn)”而不是“哪一行代碼該寫到哪個(gè)寄存器”。更麻煩的是嵌入式軟件的調(diào)試往往是串行的。代碼量越大編譯燒錄的反饋周期越長(zhǎng)人肉排查的問題鏈路越深效率越低。尤其是在帶著硬件時(shí)序、中斷嵌套、低功耗切換這類問題的時(shí)候你要是還要分心去寫那些“模板化”的初始化代碼精力根本不夠用。1.2 AI協(xié)同范式的核心人管意圖AI管實(shí)現(xiàn)那AI進(jìn)來之后能改變什么說白了就是把上面那些“搬運(yùn)”工作接走讓人把時(shí)間留給真正需要判斷力和硬件認(rèn)知的部分。我現(xiàn)在的日常工作方式是這樣的我負(fù)責(zé)梳理功能需求、硬件約束、邊界條件和驗(yàn)收標(biāo)準(zhǔn)AI負(fù)責(zé)根據(jù)我給的約束生成具體的代碼實(shí)現(xiàn)包括驅(qū)動(dòng)初始化、狀態(tài)轉(zhuǎn)移、數(shù)據(jù)處理、協(xié)議解析這類模式化內(nèi)容我做review和驗(yàn)證確認(rèn)AI產(chǎn)出的東西在硬件上真實(shí)可用而不是只對(duì)邏輯抽象負(fù)責(zé)。這個(gè)分工的本質(zhì)是把工程師的角色從“人肉編碼器”升級(jí)成了“意圖工程師”。你不必再親自記住UART外設(shè)每一比特位的配置含義但你得知道“波特率是否支持分頻整數(shù)”、“FIFO中斷閾值怎么選會(huì)影響實(shí)時(shí)性”、“DMA描述符的Cache一致性誰來維護(hù)”這類問題。有人可能會(huì)說“這不就是把活推給AI自己還得懂底層嗎”對(duì)恰恰是這樣。AI協(xié)同不是讓你變懶而是讓你把認(rèn)知從代碼層級(jí)往上提一層。你不需要背代碼但必須知道代碼敲下去之后硬件的真實(shí)行為。1.3 人機(jī)分工邊界一線嵌入式場(chǎng)景經(jīng)驗(yàn)總結(jié)說得再具體一點(diǎn)我把當(dāng)前跟AI協(xié)作時(shí)比較舒服的分工邊界整理成了一張表這也是我在多個(gè)項(xiàng)目里反復(fù)試出來的結(jié)果交給AI做的必須自己做或嚴(yán)格審核的外設(shè)驅(qū)動(dòng)的初始化模板代碼硬件時(shí)序與信號(hào)完整性判斷協(xié)議棧的狀態(tài)機(jī)實(shí)現(xiàn)有明確狀態(tài)表和事件表中斷優(yōu)先級(jí)與臨界區(qū)設(shè)計(jì)寄存器讀寫封裝、HAL層樣板函數(shù)低功耗模式切換的完整路徑單元測(cè)試樁代碼、Mock外設(shè)生成內(nèi)存布局、鏈接腳本、啟動(dòng)文件數(shù)據(jù)解析、校驗(yàn)算法、環(huán)形緩沖區(qū)實(shí)現(xiàn)實(shí)時(shí)性預(yù)算和任務(wù)調(diào)度策略配套腳本燒錄、批量改配置、日志分析安全完整性等級(jí)SIL/ASIL相關(guān)邏輯數(shù)據(jù)手冊(cè)內(nèi)容的摘要與要點(diǎn)提取OTA升級(jí)的加簽、驗(yàn)簽、回滾機(jī)制這張表的邏輯很直接凡是在“給定輸入就能推出正確輸出”的范疇內(nèi)AI可以做得又快又好凡是依賴現(xiàn)場(chǎng)感知、硬件狀態(tài)、異常流程和隱性知識(shí)的部分短期內(nèi)AI都不太靠譜需要人來兜底。這不是能力歧視而是基于工具本質(zhì)的判斷——AI沒有親手摸過你的板子它不知道你那個(gè)電源紋波有多大也不知道你那顆芯片的勘誤手冊(cè)里寫了哪些坑。2. 狀態(tài)機(jī)與分層抽象AI協(xié)同時(shí)代最值錢的“舊武器”2.1 為什么AI代碼最容易在“隱式狀態(tài)”上翻車AI寫代碼有個(gè)特點(diǎn)它擅長(zhǎng)生成“看起來很有邏輯”的代碼但邏輯正確不等于狀態(tài)正確。嵌入式系統(tǒng)里大量bug都出在隱式狀態(tài)上——你看著代碼的if-else寫得很清楚但運(yùn)行時(shí)的執(zhí)行路徑卻不是你想象的那樣。比如一個(gè)多事件的按鍵掃描模塊直接用flag變量的置位和清除來表達(dá)狀態(tài)變化長(zhǎng)按、短按、雙擊混在一起狀態(tài)多了之后AI很容易生成那種“局部正確、整體混亂”的代碼。原因也不難理解。大語言模型本身就是基于概率推斷的它看到你的上下文里有一堆中斷標(biāo)志位和回調(diào)函數(shù)就會(huì)按最常見的方式去拼接。如果顯式地告訴它“這里必須用狀態(tài)機(jī)來組織”它反而能生成結(jié)構(gòu)清晰、邊界分明的代碼。所以在我現(xiàn)在的項(xiàng)目里凡是邏輯復(fù)雜度可能膨脹的模塊我都會(huì)先做狀態(tài)建模再讓AI在這個(gè)模型框架內(nèi)填充實(shí)現(xiàn)。這么做不僅讓人和AI之間有了一本“共同語言說明書”也把模塊的復(fù)雜度收斂在一個(gè)可驗(yàn)證的范圍內(nèi)。2.2 從狀態(tài)建模開始收斂并發(fā)復(fù)雜度可能有讀者不是特別熟悉狀態(tài)機(jī)在嵌入式里的用法我簡(jiǎn)單展開一下。所謂狀態(tài)建模就是把一個(gè)模塊的所有運(yùn)行模式列出來定義清楚每個(gè)模式下能處理哪些事件、處理完會(huì)跳到哪個(gè)狀態(tài)。通常包括三個(gè)要素狀態(tài)、事件、轉(zhuǎn)移條件。舉一個(gè)多方傳輸協(xié)議的典型例子假設(shè)我們要實(shí)現(xiàn)一個(gè)MODBUS從站協(xié)議解析器。狀態(tài)就可以定義為空閑、等待地址、接收數(shù)據(jù)、校驗(yàn)、響應(yīng)發(fā)送、出錯(cuò)恢復(fù)。事件就是收到字節(jié)、地址匹配、校驗(yàn)失敗、發(fā)送完成。轉(zhuǎn)移條件則決定了狀態(tài)之間怎么跳。傳統(tǒng)開發(fā)里很多人會(huì)直接開寫用一堆if-else把協(xié)議邏輯揉在一起。但一旦出問題排查起來非常痛苦因?yàn)檫\(yùn)行時(shí)你根本不知道當(dāng)前是哪個(gè)階段只能靠打斷點(diǎn)看變量。而先做狀態(tài)建模再編碼最大的好處是邏輯變成了一張可查的二維表哪一步該做什么一目了然。這個(gè)好處在AI協(xié)同時(shí)代被放大了因?yàn)槟憧梢灾苯影褷顟B(tài)表喂給AI讓它生成一個(gè)表驅(qū)動(dòng)的執(zhí)行引擎正確率比讓它憑空去寫高一大截。下面這是我常用的狀態(tài)轉(zhuǎn)移表描述方式也是喂給AI的輸入形式之一當(dāng)前狀態(tài)事件動(dòng)作下一狀態(tài)IDLEFRAME_START清空接收緩沖啟動(dòng)幀超時(shí)定時(shí)器RECEIVINGRECEIVINGBYTE_RECEIVED寫入緩沖更新校驗(yàn)和RECEIVINGRECEIVINGFRAME_TIMEOUT丟棄緩沖記錄錯(cuò)誤計(jì)數(shù)IDLERECEIVINGLENGTH_MATCH計(jì)算并比對(duì)校驗(yàn)值CHECK_SUMCHECK_SUMCHECK_OK觸發(fā)應(yīng)用層回調(diào)RESPONDCHECK_SUMCHECK_ERR丟棄緩沖記錄錯(cuò)誤計(jì)數(shù)IDLERESPONDSEND_DONE重置發(fā)送狀態(tài)IDLE我給AI的指令往往只有一句話“基于下面這張狀態(tài)轉(zhuǎn)移表用C語言生成一個(gè)表驅(qū)動(dòng)的狀態(tài)機(jī)執(zhí)行器狀態(tài)枚舉、事件枚舉、轉(zhuǎn)移表要在代碼中顯式定義?！鄙沙鰜淼拇a只要表格本身是對(duì)的邏輯基本不會(huì)跑偏。2.3 狀態(tài)機(jī)模型如何反哺AI代碼審查狀態(tài)建模還有一個(gè)隱藏好處它天然提供了一套驗(yàn)證標(biāo)準(zhǔn)。AI生成完代碼你不需要一行行讀c文件去摳邏輯你只需要對(duì)照狀態(tài)表測(cè)幾個(gè)關(guān)鍵路徑正常流程、異常分支、邊界事件。這個(gè)做法大大降低了review的成本。我自己的習(xí)慣是拿到AI生成的代碼之后先看三個(gè)地方狀態(tài)枚舉是否和表里完全一一對(duì)應(yīng)有沒有多余的“發(fā)明創(chuàng)造”事件驅(qū)動(dòng)的入口是否統(tǒng)一是不是所有外部輸入都收斂到了同一個(gè)事件分發(fā)機(jī)制上每個(gè)case分支是否都有明確的下一狀態(tài)不允許出現(xiàn)fall-through和隱式狀態(tài)殘留。這三點(diǎn)看完基本能判斷AI是不是真的理解了你給的狀態(tài)表還是只是生成了一個(gè)貌似正確的空殼。如果這三點(diǎn)都過關(guān)再往下看具體動(dòng)作代碼的硬件相關(guān)部分。2.4 硬件抽象層HAL邊界的意義除了狀態(tài)機(jī)第二個(gè)對(duì)AI協(xié)同特別有意義的“舊武器”是分層抽象。如果你拿到一個(gè)沒有分層的裸工程所有代碼直接操作寄存器文件之間互相#include那AI改起來就是一場(chǎng)災(zāi)難。它無法知道修改這個(gè)文件會(huì)不會(huì)影響另一個(gè)文件里的宏定義也無從判斷該把新代碼放在哪個(gè)層級(jí)。所以在面向AI協(xié)同的開發(fā)范式里我會(huì)強(qiáng)制把工程按“應(yīng)用層—協(xié)議層—HAL—寄存器映射”四層拆開。AI生成代碼時(shí)明確限定它的作用域在某一層里。比如讓它生成一個(gè)I2C EEPROM的驅(qū)動(dòng)我會(huì)先告訴它“HAL層接口是i2c_master_transmit(uint16_t dev_addr, uint8_t *buf, uint16_t len)”并限定它只能調(diào)用這個(gè)函數(shù)接口不允許直接操作寄存器。這樣一來AI只能在接口約束的范圍內(nèi)發(fā)揮生成代碼的硬件耦合風(fēng)險(xiǎn)會(huì)小很多。這個(gè)做法的本質(zhì)是用人的架構(gòu)能力把AI的“發(fā)揮空間”框在安全邊界內(nèi)。你在邊界上花的心思越多AI在邊界內(nèi)犯錯(cuò)的概率就越低。3. 提示詞工程在嵌入式領(lǐng)域不是玄學(xué)3.1 很多人的提示詞方式根本沒法讓AI干活現(xiàn)在AI編程工具不少很多嵌入式工程師也試過。但大部分人遇到的問題是“AI生成的代碼看著行一跑就廢。”于是得出一個(gè)結(jié)論AI寫不了嵌入式代碼。我先說個(gè)可能有點(diǎn)扎心的判斷很多時(shí)候不是AI不行是提示詞給得太糊弄了。你要是只丟一句“幫我寫一個(gè)CAN驅(qū)動(dòng)”AI只能根據(jù)它訓(xùn)練數(shù)據(jù)里的“平均印象”去猜你的芯片型號(hào)、你的時(shí)鐘樹、你的幀格式標(biāo)準(zhǔn)、你的中斷使用習(xí)慣。它猜對(duì)了是運(yùn)氣猜錯(cuò)了才是常態(tài)。我見過最夸張的案例同事讓AI“生成一個(gè)ESP32的藍(lán)牙配網(wǎng)代碼”AI給了他一套樂鑫官方示例的簡(jiǎn)化版?？粗稽c(diǎn)錯(cuò)沒有結(jié)果編譯出來的固件體積超了Flash限額。原因在于他沒告訴AI這個(gè)項(xiàng)目用的還是老款ESP32芯片、Flash只有4MB而且分區(qū)表里已經(jīng)塞了大量OTA資源。AI不知道這些硬件和系統(tǒng)約束自然會(huì)按“最大兼容性”的默認(rèn)方案來。3.2 嵌入式AI提示詞的六個(gè)必要信息經(jīng)過大半年反復(fù)調(diào)整我現(xiàn)在給AI提需求時(shí)固定會(huì)包含六個(gè)維度的信息。你可以把這個(gè)當(dāng)成一個(gè)模板來用角色與目標(biāo)告訴AI你希望它扮演什么要做什么事。比如“你是一個(gè)有十年經(jīng)驗(yàn)的嵌入式軟件工程師擅長(zhǎng)STM32H7系列的外設(shè)驅(qū)動(dòng)開發(fā)?！庇布h(huán)境芯片型號(hào)、開發(fā)板、外設(shè)掛接方式、時(shí)鐘頻率、引腳分配。越詳細(xì)越好不確定的寧可多寫也不要漏。接口契約給出現(xiàn)有的函數(shù)接口、頭文件、數(shù)據(jù)結(jié)構(gòu)定義明確“只能調(diào)用哪些接口”“不能訪問哪些資源”。功能需求描述輸入是什么、要做什么處理、輸出是什么。這里用“如果收到X就做Y”這類判斷句式比“處理數(shù)據(jù)”這種模糊描述強(qiáng)無數(shù)倍。約束清單內(nèi)存限制、實(shí)時(shí)性要求、不可用的庫函數(shù)、編碼規(guī)范比如MISRA C子集、可移植性要求。驗(yàn)收標(biāo)準(zhǔn)給出什么樣的測(cè)試用例、什么樣的輸出結(jié)果算通過。把這個(gè)寫清楚AI會(huì)主動(dòng)往可驗(yàn)證的方向靠。舉個(gè)實(shí)際例子我要讓AI寫一個(gè)軟件定時(shí)器模塊提示詞大概長(zhǎng)這樣角色你是一名嵌入式軟件工程師負(fù)責(zé)基于C語言的RTOS應(yīng)用層開發(fā)。 硬件環(huán)境Cortex-M4核心主頻168MHz有硬件SysTick系統(tǒng)時(shí)基1ms。 接口契約只能使用stdint.h、stdbool.h禁止使用動(dòng)態(tài)內(nèi)存malloc已有的接口是void systick_isr_cb(void)由中斷每1ms調(diào)用一次。 功能需求實(shí)現(xiàn)一個(gè)軟件定時(shí)器模塊支持創(chuàng)建定時(shí)器、啟動(dòng)、停止、查詢剩余時(shí)間回調(diào)函數(shù)在systick中斷上下文中執(zhí)行回調(diào)不允許阻塞。 約束清單定時(shí)器實(shí)例上限為32個(gè)內(nèi)存用靜態(tài)數(shù)組分配不支持刪除定時(shí)器可復(fù)用回調(diào)執(zhí)行時(shí)間不超過10us。 驗(yàn)收標(biāo)準(zhǔn)提供完整的timer.c和timer.h以及一組host端測(cè)試用例驗(yàn)證定時(shí)器在正常、重復(fù)啟動(dòng)、邊界時(shí)間三種場(chǎng)景下行為正確。你看這樣給出來的需求AI生成的東西和“幫我寫一個(gè)定時(shí)器”完全不是一個(gè)水平線。3.3 上下文窗口不夠用怎么辦用“接口契約文件”壓縮信息有人會(huì)說“芯片手冊(cè)那么厚我哪能每次提示詞里都寫那么細(xì)”這就要提到另一個(gè)經(jīng)驗(yàn)建立工程級(jí)的“接口契約文件”。我現(xiàn)在的做法是在每個(gè)嵌入式工程里放一個(gè)docs/contract.md文件里面寫清楚了芯片型號(hào)、編譯工具鏈版本、鏈接腳本位置所有封裝的HAL層函數(shù)原型及簡(jiǎn)要說明引腳復(fù)用表哪根PIN連到哪個(gè)外設(shè)全局狀態(tài)枚舉和關(guān)鍵數(shù)據(jù)結(jié)構(gòu)定義內(nèi)存區(qū)域劃分RAM、Flash、NoInit段等團(tuán)隊(duì)編碼規(guī)范的核心條目。寫提示詞的時(shí)候我只需要在開頭注明“請(qǐng)先閱讀項(xiàng)目根目錄下的docs/contract.md所有代碼必須遵循其中定義的接口和約束”AI就能自動(dòng)去讀取并組織上下文。相當(dāng)于你把整個(gè)項(xiàng)目的核心信息壓縮進(jìn)了一個(gè)文件AI拿到這個(gè)壓縮包后生成的代碼會(huì)明顯更貼合你的工程。這個(gè)方法最大的價(jià)值是你不需要每次復(fù)制粘貼一堆重復(fù)信息也不需要依賴AI那有限的上下文窗口去記憶全文而是把契約變成一個(gè)可以反復(fù)引用的錨點(diǎn)。我實(shí)測(cè)下來加入契約文件后AI生成代碼的一次性通過率至少翻了一倍。3.4 生成之后的“反Prompt”讓AI自己Review自己還有一個(gè)小技巧很多人不知道AI生成的代碼完成之后不要急著拿板子燒先讓它做一輪自審。你可以追加一句請(qǐng)以硬件工程師的視角審視這份代碼著重檢查1) 中斷安全2) 臨界區(qū)保護(hù)3) volatile使用場(chǎng)景4) 內(nèi)存對(duì)齊5) 異常分支處理。如果有問題列出問題清單和修改建議不要直接給完整修改后的代碼。這一步看起來簡(jiǎn)單但效果出奇地好。因?yàn)锳I在“發(fā)現(xiàn)問題”模式下會(huì)調(diào)用它訓(xùn)練數(shù)據(jù)里的那些常見bug模式庫找出它自己剛才生成代碼里的遺漏。我遇到過好幾次AI自己指出“該處臨界區(qū)未關(guān)中斷”或“該變量缺少volatile修飾”被我確認(rèn)后確實(shí)需要修改。這等于用AI的自我校驗(yàn)把一部分隱性bug在編譯前就消滅掉了。4. 從“編譯通過”到“硬件跑通”三級(jí)驗(yàn)證閉環(huán)不能省4.1 為什么編譯通過是最低標(biāo)準(zhǔn)而不是驗(yàn)收標(biāo)準(zhǔn)很多人用AI寫代碼最開心的一瞬間是“編譯零錯(cuò)誤”。但對(duì)嵌入式開發(fā)來說編譯通過連及格線都算不上。嵌入式代碼的驗(yàn)證是分層的編譯通過只能證明語法正確、符號(hào)引用正確它證明不了運(yùn)行時(shí)行為正確更證明不了硬件配合正確。舉一個(gè)我真實(shí)遇到過的場(chǎng)景AI給一個(gè)低功耗管理模塊生成了代碼編譯零錯(cuò)誤零警告結(jié)果板子燒進(jìn)去一進(jìn)sleep就醒不過來。最后仔細(xì)排查發(fā)現(xiàn)AI在進(jìn)入低功耗模式前沒有正確配置RTC鬧鐘中斷喚醒而是把一個(gè)外部GPIO中斷配置成了喚醒源但那個(gè)引腳上根本沒有接信號(hào)。這種問題編譯期絕對(duì)不會(huì)報(bào)錯(cuò)甚至靜態(tài)分析也不一定抓得出來因?yàn)檎Z法、邏輯都是通的它只是和硬件實(shí)際連接不匹配。所以我現(xiàn)在要求自己團(tuán)隊(duì)里的開發(fā)流程必須要過三級(jí)驗(yàn)證閉環(huán)。4.2 第一級(jí)編譯與靜態(tài)分析第一級(jí)是編譯加靜態(tài)分析。編譯沒什么好說的把警告當(dāng)成錯(cuò)誤來對(duì)待寧可多花時(shí)間消除警告也不要留著隱患進(jìn)下一級(jí)。對(duì)于AI生成的代碼這一步尤其重要因?yàn)锳I經(jīng)常生成一些類型寬度不匹配、隱式轉(zhuǎn)換、未使用的變量之類的代碼這些在編譯期就有跡可循。靜態(tài)分析工具我常用的有cppcheck和PC-Lint。在嵌入式場(chǎng)景里我會(huì)額外打開這些規(guī)則未初始化變量、數(shù)組越界、空指針解引用、switch缺少default、變量聲明遮蔽、隱式類型轉(zhuǎn)換。每一條都是在硬件上排查起來非常痛苦的bug類型。實(shí)測(cè)下來AI生成的代碼在第一次過靜態(tài)分析時(shí)平均能查出四到五個(gè)中等級(jí)別以上的問題其中最常見的是未初始化變量和隱式轉(zhuǎn)換。4.3 第二級(jí)Host端單元測(cè)試第二級(jí)是Host端單元測(cè)試。這一步很多非嵌入式的開發(fā)者可能不熟悉它的核心思路是把不依賴具體硬件的邏輯代碼從嵌入式工程中抽出來放到PC上用測(cè)試框架跑。相當(dāng)于在硬件還沒準(zhǔn)備好之前先用軟件的方式驗(yàn)證邏輯正確性。我會(huì)把需要驗(yàn)證的模塊設(shè)計(jì)成不直接操作寄存器而是調(diào)用HAL層接口的模式然后寫一份Mock的HAL實(shí)現(xiàn)在PC上模擬外設(shè)行為?？蚣芪彝扑]Ceedling加Unity這個(gè)組合在嵌入式圈子里用得比較多支持自動(dòng)生成測(cè)試樁也支持直接編譯運(yùn)行。舉個(gè)實(shí)際例子我之前讓AI寫了一個(gè)環(huán)形緩沖區(qū)模塊以及一個(gè)基于該緩沖區(qū)的串口命令解析器。我把這兩個(gè)文件抽出來后在Host端寫了測(cè)試用例模擬了“連續(xù)塞入一幀完整數(shù)據(jù)”“數(shù)據(jù)中間插入錯(cuò)誤字節(jié)”“緩沖區(qū)溢出時(shí)寫入”三種場(chǎng)景AI生成的代碼在第二種場(chǎng)景下就暴露了一個(gè)問題錯(cuò)誤字節(jié)之后它沒有復(fù)位解析狀態(tài)導(dǎo)致后續(xù)所有命令解析全部錯(cuò)位。這個(gè)bug如果直接燒到板子上你得用串口調(diào)試助手反復(fù)發(fā)數(shù)據(jù)、看打印才能定位到在Host端測(cè)試用例里它跑一遍就能蹦出來。4.4 第三級(jí)硬件在環(huán)驗(yàn)證三級(jí)驗(yàn)證的最后一環(huán)是回到真實(shí)的芯片上跑。這一環(huán)AI幫不了太多它沒有自己的示波器、邏輯分析儀和JTAG調(diào)試器。但AI可以為這一環(huán)做不少配合工作比如生成測(cè)試腳本、生成自動(dòng)化燒錄的命令行腳本、甚至幫你把日志輸出格式整理成方便解析的JSON結(jié)構(gòu)。硬件驗(yàn)證階段我自己會(huì)重點(diǎn)盯幾個(gè)板上容易翻車的點(diǎn)外設(shè)初始化序列是否正確特別是時(shí)鐘樹和GPIO復(fù)用中斷服務(wù)程序的執(zhí)行時(shí)間和嵌套行為DMA和Cache一致性如果芯片帶Cache低功耗模式切換后的時(shí)鐘恢復(fù)Flash寫操作的等待周期和電源電壓波動(dòng)。每跑一條測(cè)試用例我會(huì)把結(jié)果喂回給AI讓它根據(jù)日志分析可能的原因。這等于讓AI參與硬件調(diào)試的“推理環(huán)節(jié)”但最終的判斷和修改決定我會(huì)自己做一遍確認(rèn)。這里分享一個(gè)排查DMA亂數(shù)據(jù)的完整鏈路也算是對(duì)開頭那個(gè)案例的復(fù)盤。當(dāng)時(shí)的現(xiàn)象是UART DMA接收的數(shù)據(jù)偶發(fā)錯(cuò)位。我先把問題現(xiàn)象和HAL層初始化代碼喂給AIAI列了五個(gè)可能原因GPIO復(fù)用配置錯(cuò)誤、DMA通道配置錯(cuò)誤、緩存一致性問題、FIFO溢出、中斷優(yōu)先級(jí)沖突導(dǎo)致丟數(shù)據(jù)。然后我去檢查硬件GPIO復(fù)用配置和手冊(cè)一致DMA通道請(qǐng)求映射對(duì)得上排除前兩個(gè)。剩下三個(gè)里緩存一致性是最可疑的——芯片帶CacheDMA是私有的CPU寫的描述符數(shù)據(jù)還留在Cache里沒回寫內(nèi)存DMA就直接去內(nèi)存里讀了讀到的是舊數(shù)據(jù)。我回過去讓AI在DMA描述符初始化后加一條Cache Clean操作同時(shí)把接收緩沖區(qū)的Cache Invalidate配置好問題就消失了。這個(gè)過程AI負(fù)責(zé)的是知識(shí)檢索和假設(shè)生成我負(fù)責(zé)的是硬件確認(rèn)和最終決策兩邊配合著來效率明顯比一個(gè)人悶頭查高。5. AI在嵌入式里的翻車現(xiàn)場(chǎng)能力邊界與識(shí)別方法5.1 寄存器地址和芯片手冊(cè)AI幻覺的重災(zāi)區(qū)聊完驗(yàn)證閉環(huán)我想花點(diǎn)篇幅講一講AI在嵌入式領(lǐng)域的常見翻車點(diǎn)。如果說有一個(gè)最需要警覺的領(lǐng)域就是“寄存器地址、芯片手冊(cè)細(xì)節(jié)、勘誤表信息”這類高度精確的內(nèi)容。大語言模型本質(zhì)上是一個(gè)概率圖譜它知道“這個(gè)芯片的I2C外設(shè)通常有配置寄存器、數(shù)據(jù)寄存器、狀態(tài)寄存器”但它不保證它給出的地址偏移是這顆具體芯片對(duì)應(yīng)手冊(cè)里的真實(shí)值。我碰過一次特別離譜的情況讓AI生成一個(gè)新系列MCU的ADC驅(qū)動(dòng)AI直接使用了它訓(xùn)練數(shù)據(jù)中“最接近”的另一個(gè)系列芯片的寄存器布局。兩個(gè)系列的外設(shè)模塊名字一樣但寄存器地址偏移差了整整8個(gè)字節(jié)。結(jié)果就是寄存器讀寫表面上沒有觸發(fā)HardFault但采樣值永遠(yuǎn)不對(duì)。這類問題的隱蔽性在于它不會(huì)崩潰它只是靜默地產(chǎn)生錯(cuò)誤數(shù)據(jù)。所以我總結(jié)了一條鐵律凡是涉及具體寄存器地址、位域定義、時(shí)鐘樹參數(shù)的內(nèi)容都必須回到官方頭文件和數(shù)據(jù)手冊(cè)去核對(duì)。AI生成的這些信息只能當(dāng)“檢索線索”用不能當(dāng)“事實(shí)依據(jù)”。5.2 排查實(shí)例AI幫忙改低功耗改完設(shè)備睡死再分享一個(gè)排查鏈路比較有代表性的案例。當(dāng)時(shí)我們要給一個(gè)傳感器節(jié)點(diǎn)做低功耗優(yōu)化我讓AI基于現(xiàn)有的外設(shè)初始化代碼生成一套“進(jìn)入睡眠-定時(shí)喚醒-恢復(fù)工作”的流程。AI很快就給了一套代碼進(jìn)入sleep前關(guān)掉外設(shè)時(shí)鐘把GPIO全部設(shè)為低功耗狀態(tài)然后配置RTC鬧鐘喚醒。代碼燒進(jìn)去之后設(shè)備確實(shí)進(jìn)去了低功耗但怎么都醒不過來。用調(diào)試器連上去看發(fā)現(xiàn)CPU停在WFI指令里RTC中斷確實(shí)觸發(fā)了但中斷處理程序從頭到尾沒有執(zhí)行到用戶回調(diào)。當(dāng)時(shí)我一步步排查的鏈路是這樣的先懷疑RTC中斷沒有使能查NVIC配置沒問題再懷疑RTC鬧鐘比較值不對(duì)對(duì)照手冊(cè)算了一下配置正確然后懷疑中斷標(biāo)志位沒有清除但手測(cè)時(shí)中斷標(biāo)志位是置位的最后看啟動(dòng)文件里的中斷向量表發(fā)現(xiàn)AI生成的代碼在關(guān)閉外設(shè)時(shí)鐘時(shí)把RTC所在的備份域時(shí)鐘也關(guān)了RTC中斷標(biāo)志位雖然置位但內(nèi)核無法響應(yīng)該中斷源的pending請(qǐng)求。問題根因就是RTC依賴備份域供電和時(shí)鐘進(jìn)入低功耗前不應(yīng)該關(guān)閉它的時(shí)鐘源反而要確保LSI或者LSE仍在運(yùn)行。AI是按“關(guān)閉不用的外設(shè)時(shí)鐘”這個(gè)通用優(yōu)化原則去做的但它沒有真正理解這顆芯片備份域的特殊性。這個(gè)案例再次驗(yàn)證了我前面說的AI擅長(zhǎng)綜合“常規(guī)做法”但不擅長(zhǎng)理解“這顆芯片的特殊情況”后者只能靠人來把關(guān)。5.3 怎么識(shí)別“優(yōu)雅地錯(cuò)誤”的AI代碼AI生成代碼最讓人頭疼的一點(diǎn)是它的錯(cuò)誤往往是“優(yōu)雅的”——不是明顯缺了分號(hào)、少了頭文件那種低級(jí)錯(cuò)誤而是邏輯自洽、風(fēng)格統(tǒng)一、但概念理解錯(cuò)誤。舉個(gè)例子AI生成一個(gè)I2C讀寫函數(shù)函數(shù)名、參數(shù)、返回值設(shè)計(jì)得都很專業(yè)但它在讀操作時(shí)長(zhǎng)尾的NACK處理上可能漏了一個(gè)總線釋放步驟導(dǎo)致連續(xù)讀取時(shí)通訊卡死。這種錯(cuò)誤靜態(tài)檢查查不出來單元測(cè)試不一定覆蓋到只有硬件在環(huán)測(cè)試才會(huì)暴露。我自己識(shí)別這種“優(yōu)雅錯(cuò)誤”的方法是看AI生成代碼里的“隱含假設(shè)”。比如它默認(rèn)外設(shè)時(shí)鐘已經(jīng)開啟、默認(rèn)中斷已經(jīng)配置、默認(rèn)引腳功能已經(jīng)復(fù)用好。在傳統(tǒng)人寫代碼里這些假設(shè)會(huì)暴露在“這個(gè)函數(shù)只負(fù)責(zé)A不負(fù)責(zé)B”的注釋和設(shè)計(jì)里但AI生成的代碼往往會(huì)把這些預(yù)設(shè)寫得很含蓄甚至隱藏在一個(gè)參數(shù)默認(rèn)值里。所以review的時(shí)候我會(huì)專門找這類“假設(shè)點(diǎn)”逐個(gè)確認(rèn)在真實(shí)工程里是否成立。5.4 應(yīng)對(duì)策略讓AI拿出證據(jù)鏈針對(duì)這種問題我的另一個(gè)習(xí)慣是要求AI給出“證據(jù)鏈”。比如讓AI寫一段涉及芯片功能的代碼時(shí)我會(huì)在提示詞里加一句請(qǐng)?jiān)诖a注釋中標(biāo)注每個(gè)關(guān)鍵配置的依據(jù)具體到數(shù)據(jù)手冊(cè)章節(jié)號(hào)或頭文件中的宏定義名稱。加了這句話之后AI的行為會(huì)有明顯變化。它不再憑空給出一個(gè)神秘的寄存器值而是會(huì)明確標(biāo)注“這里取0x23是因?yàn)閰⒖际謨?cè)第xx節(jié)推薦的啟動(dòng)時(shí)序”或者“這個(gè)枚舉值來自device.h中的xxx宏”?？吹竭@種依據(jù)我就能快速去對(duì)照手冊(cè)和官方頭文件核實(shí)真?zhèn)?。這比AI直接給出一段看起來完美無缺的代碼要安全得多。6. 從個(gè)人習(xí)慣到團(tuán)隊(duì)流程AI協(xié)同開發(fā)范式落地建議6.1 工程組織上的建議AI產(chǎn)物要有清晰邊界如果只是在個(gè)人項(xiàng)目里偶爾用AI那前面的內(nèi)容已經(jīng)足夠。但如果你想在團(tuán)隊(duì)里推行這套開發(fā)范式工程組織的設(shè)計(jì)就要跟上。我的第一個(gè)建議是在代碼倉庫里為AI生成的代碼打上明確的標(biāo)記既要在文件頭注釋里寫清楚“本文件由AI輔助生成review人xxx”也要在目錄結(jié)構(gòu)上有所區(qū)分比如用ai_generated/或者module/gen/之類的路徑單獨(dú)管理。這么做不是為了“甩鍋”或者“貼標(biāo)簽”而是為了讓review機(jī)制真正有效。AI生成的代碼和人類寫的代碼在審查時(shí)的關(guān)注點(diǎn)是不同的。人類寫的代碼你可能擔(dān)心算法邏輯有沒有想清楚AI生成的代碼你更擔(dān)心它有沒有誤解硬件約束、有沒有引入隱式假設(shè)。如果review的人不知道這段代碼是AI生成的他很可能按人類代碼的審查習(xí)慣草草掃過反而漏掉AI特有的問題。6.2 提交規(guī)范與AI痕跡管理第二個(gè)建議是在Git提交信息里明確標(biāo)注AI參與的程度。我們團(tuán)隊(duì)約定了幾種標(biāo)簽[AI生成]完全由AI生成的模塊人工review后合入[AI輔助]人類主要編寫AI負(fù)責(zé)補(bǔ)全、優(yōu)化部分代碼[AI審查]代碼由人類編寫AI參與了邏輯審查或找錯(cuò)。標(biāo)簽的意義在于建立數(shù)據(jù)積累。跑幾個(gè)迭代之后你可以回看這些數(shù)據(jù)統(tǒng)計(jì)一下AI生成代碼的缺陷率、返工率從而判斷哪些任務(wù)適合繼續(xù)交給AI哪些任務(wù)必須收回人來寫。沒有標(biāo)簽這些復(fù)盤數(shù)據(jù)就是一筆糊涂賬。6.3 個(gè)人工作流參考一個(gè)完整的AI協(xié)同開發(fā)周期如果你剛開始嘗試這種模式我建議先從一個(gè)低風(fēng)險(xiǎn)的小模塊練手比如一個(gè)命令行解析器、一個(gè)軟件定時(shí)器、一個(gè)CRC校驗(yàn)單元。我自己的完整流程大概是這樣的第一步先花十分鐘梳理需求把狀態(tài)、接口、約束寫清楚形成一份簡(jiǎn)潔的設(shè)計(jì)說明。這個(gè)環(huán)節(jié)不碰代碼但決定了后面AI生成代碼的質(zhì)量上限。第二步把設(shè)計(jì)說明整理成提示詞結(jié)合工程的contract.md一起發(fā)給AI要求它生成代碼和對(duì)應(yīng)的Host端單元測(cè)試。第三步拿到代碼后先過靜態(tài)分析再在Host端跑測(cè)試用例。這一步能解決大部分邏輯層面的問題。第四步把驗(yàn)證過的代碼合入工程燒錄到目標(biāo)板用真實(shí)的硬件外設(shè)跑通關(guān)鍵用例特別注意那些Host端測(cè)不到的中斷時(shí)序、Cache一致性、DMA交互問題。第五步把硬件測(cè)試的結(jié)果和遇到的問題反饋給AI讓它給出修復(fù)建議或追加測(cè)試用例形成一個(gè)“人-機(jī)-硬件”三方的閉環(huán)迭代。6.4 團(tuán)隊(duì)推行AI協(xié)同容易遇到的三個(gè)阻力最后說說團(tuán)隊(duì)落地時(shí)最常遇到的阻力。第一個(gè)是抵觸心理——“AI寫出來的代碼我不放心還不如自己寫”。這種想法可以理解但建議團(tuán)隊(duì)里先在小范圍做實(shí)驗(yàn)選一個(gè)非關(guān)鍵模塊跑一遍上述流程拿數(shù)據(jù)說話。看到“AI生成基礎(chǔ)驅(qū)動(dòng)框架人做硬件驗(yàn)證”的組合能把開發(fā)周期壓縮一半之后抵觸情緒會(huì)自然緩解。第二個(gè)阻力是“AI生成的代碼風(fēng)格不統(tǒng)一”。這個(gè)問題可以通過一個(gè)強(qiáng)有力的contract.md來緩解里面明確寫出命名規(guī)則、注釋規(guī)范、錯(cuò)誤處理方式、模塊接口風(fēng)格。我實(shí)測(cè)下來只要約束給得足夠具體AI生成的代碼風(fēng)格可以做到和團(tuán)隊(duì)人類代碼基本一致。第三個(gè)阻力是“review壓力變大”。AI生成的代碼量通常比人寫得多動(dòng)不動(dòng)就給你鋪一整個(gè)文件的代碼看著就頭疼。我的解決方案是要求AI按函數(shù)粒度交付先交付接口聲明和空實(shí)現(xiàn)逐個(gè)函數(shù)填充。這樣review可以聚焦在核心邏輯和硬件交互點(diǎn)上而不是被一片代碼淹沒。說在最后AI協(xié)同范式的下一步我自己用下來的感受是AI協(xié)同帶給嵌入式開發(fā)的最大價(jià)值不是“幫你把活干完”而是“幫你把活干得更有譜”。它會(huì)逼著你把需求想清楚、把接口定義明白、把驗(yàn)證標(biāo)準(zhǔn)寫具體——這些原本就是優(yōu)秀嵌入式工程師應(yīng)該具備的能力只是以前被大量重復(fù)編碼掩蓋了。如果你正在觀望要不要在嵌入式項(xiàng)目里引入AI我的建議是別一上來就往產(chǎn)品代碼里塞。先挑一個(gè)周末找一個(gè)功能邊界清晰的模塊按照前言里那套狀態(tài)建模、契約文件、提示詞模板、三級(jí)驗(yàn)證的流程走一遍。等你習(xí)慣了“先定義清楚再讓AI填充”的工作方式你會(huì)發(fā)現(xiàn)自己對(duì)項(xiàng)目的理解反而比以前更深了因?yàn)槟憬K于有精力去關(guān)注那些真正決定系統(tǒng)成敗的硬件細(xì)節(jié)了。我下一篇文章打算聊一聊具體工具鏈的搭配包括編輯器里的AI插件、命令行輔助工具、以及怎么把它們組織成一條順手的工作流。如果你也在嵌入式項(xiàng)目里折騰AI歡迎在評(píng)論區(qū)聊聊你踩過的坑。