1. 為什么嵌入式開發(fā)需要引入AI協(xié)同1.1 從手寫寄存器到對話式生成的轉(zhuǎn)變做STM32開發(fā)的朋友大概都有這種體會一個中等復雜度的項目光是初始化代碼就能耗掉大半天。時鐘樹配置、GPIO模式、外設參數(shù)、中斷優(yōu)先級每一項都要翻參考手冊對著寄存器位域一個字段一個字段地摳。等這些底層代碼寫完真正跟業(yè)務邏輯相關的部分反而沒剩多少精力了。我剛開始接觸STM32那會兒習慣的做法是找一份標準外設庫或者HAL庫的例程復制過來改改引腳號和時鐘參數(shù)。這個方法在項目初期確實省事但問題也很明顯——例程和實際需求之間總有偏差改著改著就亂了最后連自己都不確定某個外設到底配沒配對。后來CubeMX出來了圖形化配置確實解決了一部分問題但生成的代碼框架和實際業(yè)務邏輯之間仍然需要大量手工銜接。AI編程助手的出現(xiàn)讓這個流程有了新的可能性。它不是要替代CubeMX或者參考手冊而是在我知道要做什么和代碼寫出來之間加了一層自然語言的橋梁。你可以直接描述需求比如用TIM2的通道1輸出一個1kHz、占空比可調(diào)的PWM波AI會幫你生成對應的初始化代碼和占空比設置函數(shù)。這比翻手冊查寄存器快得多也比復制例程再改要可靠。但這里有個關鍵前提你得知道自己在說什么。AI不是魔法它生成的東西對不對取決于你的描述是否準確以及你是否有能力驗證輸出結果。所以這篇文章要講的不是如何讓AI幫你寫代碼這么簡單而是如何建立一套可靠的AI協(xié)同開發(fā)流程讓AI真正成為嵌入式開發(fā)中的有效生產(chǎn)力而不是一個制造bug的源頭。1.2 AI協(xié)同開發(fā)適合什么樣的STM32項目不是所有STM32項目都適合用AI來協(xié)同。我自己的經(jīng)驗是以下幾種場景收益最明顯外設驅(qū)動開發(fā)。比如你要用SPI驅(qū)動一塊屏幕、用I2C讀取傳感器、用ADC采集模擬量。這些外設的初始化流程相對固定AI對這類代碼的生成質(zhì)量很高因為訓練數(shù)據(jù)里有大量類似的實現(xiàn)。你只需要把引腳分配、時鐘頻率、工作模式說清楚生成的代碼基本可以直接用。通信協(xié)議實現(xiàn)。比如Modbus RTU、CANopen、自定義的串口協(xié)議解析。這類代碼有明確的幀格式和狀態(tài)機邏輯AI能幫你快速搭出框架你只需要在關鍵的回調(diào)函數(shù)里填充業(yè)務邏輯。算法移植與優(yōu)化。比如把PC上驗證過的PID控制算法、濾波器、數(shù)據(jù)擬合方法移植到STM32上。AI可以幫你處理定點化、數(shù)據(jù)類型轉(zhuǎn)換、內(nèi)存對齊這些瑣碎但容易出錯的事情。調(diào)試與排錯。遇到HardFault、外設不工作、通信丟包這些問題時把錯誤現(xiàn)象和關鍵代碼貼給AI它往往能給出幾個排查方向。雖然不一定直接命中但能幫你打開思路。反過來以下幾種情況我建議謹慎使用AI對實時性要求極高的中斷服務程序、涉及硬件時序精確控制的底層代碼、安全相關的關鍵邏輯。這些地方AI生成的代碼需要你逐行審查審查的時間可能比自己寫還長。1.3 建立正確的AI協(xié)同心態(tài)我見過兩種極端。一種是完全不信AI覺得它生成的代碼都是垃圾碰都不碰。另一種是過度依賴AI給什么就用什么出了問題再回頭找AI問。這兩種都走不遠。正確的心態(tài)應該是把AI當成一個知識面很廣但缺乏項目上下文的助手。它知道很多通用的編程模式和API用法但它不知道你的板子上LED接在哪個引腳、你的傳感器是什么型號、你的項目對功耗有什么要求。所以你的工作是把這些上下文準確地傳遞給它然后對它給出的結果做工程判斷。這個判斷能力才是嵌入式工程師的核心價值。AI可以幫你寫代碼但它不能替你決定這個代碼在你的系統(tǒng)里能不能跑、跑得穩(wěn)不穩(wěn)。接下來的章節(jié)我會把整個協(xié)同流程拆開從需求描述到代碼驗證每一步都講清楚該怎么做、為什么這么做。2. 需求描述把模糊想法翻譯成AI能理解的語言2.1 描述外設需求時必須說清楚的五個要素很多人跟AI對話時習慣說幫我寫一個串口發(fā)送的代碼然后AI給出一段基于HAL庫的UART發(fā)送函數(shù)。這段代碼能不能用大概率不能直接用因為缺少關鍵信息。要讓AI生成可用的代碼你的描述里至少要包含以下五個要素第一芯片型號和庫類型。STM32F103和STM32H743的外設差異很大標準外設庫和HAL庫的API也完全不同。我通常會在對話開始時先說明我用的是STM32F407基于HAL庫開發(fā)環(huán)境是STM32CubeIDE這樣后續(xù)所有對話都在這個上下文里進行。第二外設實例和引腳分配。是USART1還是USART2TX和RX分別接在哪個引腳有沒有用重映射這些信息必須明確。比如USART2TX接PA2RX接PA3波特率1152008位數(shù)據(jù)位1位停止位無校驗。第三工作模式。串口是只發(fā)送還是收發(fā)都要是中斷模式、DMA模式還是輪詢模式PWM是邊沿對齊還是中心對齊ADC是單次轉(zhuǎn)換還是連續(xù)轉(zhuǎn)換這些模式選擇直接影響代碼結構。第四時鐘配置。系統(tǒng)主頻是多少外設掛在哪條總線上比如系統(tǒng)時鐘168MHzAPB1時鐘42MHzAPB2時鐘84MHz。這個信息決定了波特率寄存器的計算值是否正確。第五業(yè)務邏輯的邊界。你希望AI生成到什么程度是只生成初始化代碼還是包括發(fā)送函數(shù)、接收中斷回調(diào)、錯誤處理我一般會明確說生成初始化函數(shù)和一個阻塞式發(fā)送函數(shù)接收用中斷在回調(diào)里把數(shù)據(jù)存入環(huán)形緩沖區(qū)。把這五個要素說清楚AI生成的代碼可用性會大幅提升。下面是一個我常用的描述模板芯片STM32F407ZGT6HAL庫CubeIDE環(huán)境。系統(tǒng)時鐘168MHzAPB1為42MHzAPB2為84MHz。使用USART2TXPA2RXPA3波特率1152008N1收發(fā)均開啟。接收使用中斷模式每收到一個字節(jié)觸發(fā)回調(diào)在回調(diào)中將數(shù)據(jù)寫入一個256字節(jié)的環(huán)形緩沖區(qū)。發(fā)送使用阻塞方式提供一個發(fā)送指定長度數(shù)據(jù)的函數(shù)。請生成初始化代碼和收發(fā)函數(shù)。2.2 用輸入-處理-輸出框架描述業(yè)務邏輯外設配置說清楚之后下一步是描述業(yè)務邏輯。嵌入式開發(fā)中的業(yè)務邏輯往往涉及狀態(tài)機、數(shù)據(jù)處理、時序控制直接說幫我寫一個控制電機的代碼太模糊了。我習慣用輸入-處理-輸出的框架來組織描述。以用PID控制直流電機轉(zhuǎn)速為例。輸入是什么編碼器脈沖數(shù)、目標轉(zhuǎn)速、采樣周期。處理是什么計算當前轉(zhuǎn)速、執(zhí)行PID運算、更新PWM占空比。輸出是什么PWM比較寄存器的值。把這三點說清楚AI就能生成一個結構清晰的框架。再比如用狀態(tài)機解析自定義串口協(xié)議。輸入是環(huán)形緩沖區(qū)里的字節(jié)流處理是按照幀頭、長度、命令字、數(shù)據(jù)、校驗和的順序逐字節(jié)解析輸出是解析完成后的命令對象。你可以進一步說明狀態(tài)機的狀態(tài)劃分等待幀頭、接收長度、接收數(shù)據(jù)、校驗、完成。AI會根據(jù)這些信息生成對應的switch-case結構。這種描述方式的好處是它強迫你把邏輯想清楚再開口。很多時候描述不清楚不是因為AI理解不了而是因為你自己還沒想明白。我有個習慣在跟AI對話之前先在紙上把輸入、處理、輸出三欄列出來填不出來的地方就是邏輯還沒理順的地方。2.3 描述中必須避免的三種模糊表達有三種表達方式我踩過坑這里列出來供你參考。第一種是幫我優(yōu)化一下這段代碼。AI不知道你的優(yōu)化目標是什么——是速度、是內(nèi)存、是可讀性、還是功耗不同的目標對應完全不同的優(yōu)化策略。正確的說法是這段ADC采樣代碼在168MHz主頻下執(zhí)行時間約20微秒我希望降到10微秒以內(nèi)請給出優(yōu)化方案。第二種是這個功能用哪個外設實現(xiàn)。這種問法太開放AI可能給你列出三四種方案每種都講一遍但你真正需要的是針對你具體約束條件的建議。更好的問法是我需要輸出4路獨立的PWM波頻率1kHz到10kHz可調(diào)死區(qū)時間可配置芯片是STM32F407請推薦外設方案并說明理由。第三種是代碼有問題幫我看看。沒有錯誤現(xiàn)象、沒有關鍵代碼、沒有調(diào)試信息AI只能靠猜。有效的排錯描述應該包含預期行為是什么、實際現(xiàn)象是什么、已經(jīng)排除了哪些可能、相關的代碼片段和寄存器狀態(tài)。3. 代碼生成從對話到可編譯工程的完整鏈路3.1 分階段生成而不是一次性要完整工程我剛開始用AI寫STM32代碼時總想一次性讓它生成整個工程的代碼。結果往往是生成了一大堆文件但編譯報錯幾十個改起來比重寫還麻煩。后來我調(diào)整了策略把生成過程分成幾個階段每個階段只做一件事驗證通過再進入下一階段。第一階段生成外設初始化代碼。只要求AI生成MX_xxx_Init()函數(shù)包括時鐘使能、GPIO配置、外設參數(shù)配置。生成后先編譯確認沒有語法錯誤和未定義引用。第二階段生成基礎讀寫函數(shù)。比如串口的發(fā)送接收、SPI的讀寫、I2C的寄存器讀寫。這些函數(shù)是后續(xù)業(yè)務邏輯的基礎必須先保證它們能正常工作。第三階段生成業(yè)務邏輯框架。在基礎函數(shù)驗證通過后再讓AI生成狀態(tài)機、數(shù)據(jù)處理、控制算法等業(yè)務代碼。第四階段生成調(diào)試輔助代碼。比如打印調(diào)試信息的函數(shù)、斷言宏、錯誤處理回調(diào)。這種分階段的方式有個明顯好處每一階段的問題范圍是可控的。如果第一階段編譯不過那問題肯定在初始化代碼里不會牽扯到業(yè)務邏輯。如果第三階段運行異常但前兩階段已經(jīng)驗證過那排查范圍就縮小了很多。3.2 讓AI生成代碼時必須附帶的驗證代碼AI生成的代碼不能拿來就用必須驗證。但驗證也需要寫代碼這部分代碼同樣可以讓AI生成。我通常會在要求生成功能代碼的同時要求AI附帶一段驗證代碼。比如讓AI生成PWM初始化代碼時我會追加一句同時生成一個測試函數(shù)讓PWM占空比從0%線性增加到100%每步延時100ms循環(huán)執(zhí)行。這樣燒錄后就能用示波器或者LED亮度變化來直觀判斷PWM是否正常工作。再比如讓AI生成串口接收中斷代碼時我會要求同時生成一個回環(huán)測試函數(shù)將接收到的數(shù)據(jù)原樣發(fā)送回去。這樣用串口助手發(fā)送數(shù)據(jù)就能驗證收發(fā)是否正常。這些驗證代碼本身不復雜但如果沒有它們你就得自己想辦法構造測試條件反而更費時間。而且驗證代碼寫多了之后你會發(fā)現(xiàn)很多驗證邏輯是通用的可以積累成自己的測試代碼庫。3.3 處理AI生成代碼中的常見問題AI生成的STM32代碼有幾個高頻問題我?guī)缀趺看味紩龅竭@里總結一下處理經(jīng)驗。問題一HAL庫函數(shù)返回值未檢查。AI生成的代碼經(jīng)常直接調(diào)用HAL_UART_Transmit()而不檢查返回值。在正式產(chǎn)品中這可能導致錯誤被忽略。我的做法是要求AI所有HAL庫函數(shù)調(diào)用都必須檢查返回值出錯時調(diào)用錯誤處理函數(shù)。問題二中斷優(yōu)先級配置缺失。AI生成的初始化代碼有時會遺漏HAL_NVIC_SetPriority()和HAL_NVIC_EnableIRQ()。如果用到中斷這兩句必須手動補上。我通常會在描述中明確要求配置中斷優(yōu)先級并使能中斷。問題三時鐘使能遺漏。某些外設的時鐘使能容易被AI忽略比如GPIO端口的時鐘、DMA控制器的時鐘。生成代碼后我會對照參考手冊的時鐘樹圖逐個檢查。問題四數(shù)據(jù)類型不匹配。AI有時會用int來存儲應該用uint16_t的變量在32位MCU上可能沒問題但移植到16位MCU上就會出問題。我一般要求AI所有變量使用stdint.h中的明確寬度類型。問題五魔法數(shù)字。AI生成的代碼里經(jīng)常出現(xiàn)沒有解釋的數(shù)字比如htim2.Init.Prescaler 83。雖然計算結果可能正確但可讀性差。我會要求AI所有配置參數(shù)用宏定義或注釋說明來源。下面是一個經(jīng)過我修正的PWM初始化代碼示例展示了上述要求的落實方式/* TIM2 PWM初始化用于驅(qū)動LED亮度調(diào)節(jié) * 系統(tǒng)時鐘84MHzAPB1定時器時鐘84MHz * PWM頻率 84MHz / ((Prescaler1) * (Period1)) * 目標頻率1kHz取Prescaler83Period999 * 實際頻率 84MHz / (84 * 1000) 1kHz */ #define PWM_PRESCALER 83U #define PWM_PERIOD 999U TIM_HandleTypeDef htim2; void MX_TIM2_Init(void) { TIM_OC_InitTypeDef sConfigOC {0}; htim2.Instance TIM2; htim2.Init.Prescaler PWM_PRESCALER; htim2.Init.CounterMode TIM_COUNTERMODE_UP; htim2.Init.Period PWM_PERIOD; htim2.Init.ClockDivision TIM_CLOCKDIVISION_DIV1; htim2.Init.AutoReloadPreload TIM_AUTORELOAD_PRELOAD_ENABLE; if (HAL_TIM_PWM_Init(htim2) ! HAL_OK) { Error_Handler(); } sConfigOC.OCMode TIM_OCMODE_PWM1; sConfigOC.Pulse 0; sConfigOC.OCPolarity TIM_OCPOLARITY_HIGH; sConfigOC.OCFastMode TIM_OCFAST_DISABLE; if (HAL_TIM_PWM_ConfigChannel(htim2, sConfigOC, TIM_CHANNEL_1) ! HAL_OK) { Error_Handler(); } HAL_TIM_MspPostInit(htim2); }這段代碼里宏定義說明了參數(shù)來源注釋解釋了頻率計算公式返回值都做了檢查。這些細節(jié)看起來瑣碎但在項目后期調(diào)試時能省很多事。4. 驗證與調(diào)試AI協(xié)同流程中最容易被忽視的環(huán)節(jié)4.1 編譯通過不等于功能正確這是我最想強調(diào)的一點。AI生成的代碼編譯通過只說明語法沒問題不代表邏輯正確。我見過太多次編譯零警告但運行完全不對的情況。舉個真實的例子。有一次我讓AI生成一個SPI讀取傳感器的代碼編譯很順利但讀出來的數(shù)據(jù)始終是0xFF。排查了半天才發(fā)現(xiàn)AI生成的代碼里SPI的時鐘極性配置反了。這個錯誤編譯器發(fā)現(xiàn)不了因為SPI_POLARITY_HIGH和SPI_POLARITY_LOW都是合法的枚舉值。所以編譯通過之后必須進行功能驗證。驗證的方法取決于外設類型GPIO用萬用表或LED看電平串口用串口助手看數(shù)據(jù)SPI/I2C用邏輯分析儀看波形ADC用已知電壓源看讀數(shù)定時器用示波器看輸出頻率。沒有這些工具怎么辦那就用最原始的方法——點燈。把關鍵狀態(tài)用LED表示出來雖然效率低但至少能判斷程序有沒有跑到預期的位置。4.2 用邏輯分析儀驗證通信時序?qū)τ赟PI、I2C、UART這類通信外設邏輯分析儀是最有效的驗證工具。我一般會先用AI生成一段最簡單的通信代碼比如發(fā)送一個固定的字節(jié)序列然后用邏輯分析儀抓波形對照傳感器的數(shù)據(jù)手冊檢查時序。檢查的重點包括時鐘頻率是否匹配、數(shù)據(jù)在時鐘的哪個邊沿采樣、片選信號的建立和保持時間、起始和停止條件是否符合協(xié)議。這些參數(shù)在AI生成的代碼里往往是以宏定義或結構體字段的形式存在的你需要把它們和數(shù)據(jù)手冊上的時序圖對應起來。如果手頭沒有邏輯分析儀也可以用示波器的雙通道模式看時鐘和數(shù)據(jù)線的關系。雖然不如邏輯分析儀方便但至少能看出頻率和相位對不對。4.3 建立修改-驗證的快速迭代循環(huán)AI協(xié)同開發(fā)的核心優(yōu)勢是迭代速度快但這個優(yōu)勢只有在驗證流程足夠快的時候才能體現(xiàn)出來。如果每次修改代碼后都要等幾分鐘燒錄、再手動觸發(fā)測試條件那迭代速度就快不起來。我的做法是盡量把驗證自動化。比如串口通信的驗證我會寫一個簡單的Python腳本通過USB轉(zhuǎn)串口發(fā)送測試數(shù)據(jù)并檢查返回結果。這樣每次修改代碼后只需要燒錄然后運行腳本幾秒鐘就能知道結果。對于沒有通信接口的場景我會用定時器觸發(fā)的方式讓測試自動循環(huán)執(zhí)行。比如PWM測試讓占空比自動從0到100%循環(huán)變化這樣燒錄后只需要用示波器觀察不需要手動干預。這個快速迭代循環(huán)建立起來之后AI協(xié)同開發(fā)的效率優(yōu)勢才能真正發(fā)揮出來。你可以快速嘗試不同的實現(xiàn)方案讓AI生成代碼燒錄驗證根據(jù)結果調(diào)整描述再生成再驗證。一個外設的驅(qū)動代碼往往幾輪迭代就能調(diào)到可用狀態(tài)。5. 把AI協(xié)同融入日常開發(fā)流5.1 建立個人提示詞模板庫跟AI對話的次數(shù)多了之后你會發(fā)現(xiàn)某些描述方式效果特別好某些描述方式AI總是理解偏。把這些有效的描述方式整理成模板下次遇到類似需求直接套用能省不少時間。我的模板庫按外設類型分類每個模板包含固定的上下文說明和可變的參數(shù)占位符。比如UART的模板是這樣的芯片[型號][庫類型][開發(fā)環(huán)境]。系統(tǒng)時鐘[頻率]APB[1/2]時鐘[頻率]。使用[USARTx]TX[引腳]RX[引腳]波特率[數(shù)值][數(shù)據(jù)位][停止位][校驗位]。接收使用[中斷/DMA/輪詢]模式發(fā)送使用[阻塞/中斷/DMA]方式。請生成初始化代碼和收發(fā)函數(shù)所有HAL調(diào)用檢查返回值中斷優(yōu)先級配置為[數(shù)值]。用的時候把方括號里的內(nèi)容替換成實際值就行。這個模板我用了大半年生成的代碼一次通過率明顯比隨意描述要高。5.2 代碼審查中重點關注AI容易出錯的地方AI生成的代碼在審查時我會重點看幾個地方。這些是AI的高頻出錯點也是人工審查價值最大的地方。中斷服務函數(shù)。AI生成的中斷服務函數(shù)有時會遺漏清除中斷標志位的操作或者清除的順序不對。這個錯誤在運行時表現(xiàn)為中斷反復觸發(fā)程序卡死在中斷里。審查時要對照參考手冊確認標志位的清除時機。DMA配置。DMA的傳輸方向、數(shù)據(jù)寬度、地址增量模式這些參數(shù)AI有時會配錯。特別是外設地址和數(shù)據(jù)地址的增量設置配反了會導致數(shù)據(jù)錯位。審查時要對照參考手冊的DMA請求映射表逐個確認。時鐘配置。AI生成的時鐘配置代碼有時會忽略某些外設的時鐘分頻設置導致實際時鐘頻率和預期不符。審查時要用CubeMX或者手動計算驗證一遍。堆棧大小。如果AI生成的代碼里使用了較大的局部數(shù)組或者遞歸調(diào)用要檢查啟動文件里的堆棧大小是否足夠。這個錯誤在編譯時發(fā)現(xiàn)不了運行時表現(xiàn)為HardFault。5.3 什么情況下應該放棄AI生成改為手寫雖然我是AI協(xié)同開發(fā)的積極實踐者但有些情況下我會果斷放棄AI直接手寫代碼。時序要求嚴格的底層驅(qū)動。比如軟件模擬的單總線協(xié)議、精確到微秒的脈沖控制。這些代碼對指令周期都有要求AI生成的代碼往往有多余的函數(shù)調(diào)用和分支判斷時序?qū)Σ簧稀０踩嚓P的關鍵邏輯。比如看門狗喂狗、電源管理、故障保護。這些代碼一旦出錯后果嚴重我寧愿自己寫然后反復審查。AI反復生成都不對的場景。有時候AI對某個特定外設或者特定芯片的支持不好生成的代碼改了幾輪還是不對。這時候繼續(xù)跟AI糾纏就是浪費時間不如自己翻手冊寫。需要深度優(yōu)化的熱點代碼。AI生成的代碼通常以可讀性優(yōu)先在性能上不是最優(yōu)的。如果某段代碼是系統(tǒng)的性能瓶頸需要手工優(yōu)化指令序列和內(nèi)存訪問模式這時候AI幫不上太多忙。判斷標準其實很簡單如果審查和修改AI生成代碼的時間超過了自己寫的時間那就應該自己寫。AI是工具不是目的。6. 幾個讓我印象深刻的協(xié)同開發(fā)實例6.1 用AI快速搭建Modbus RTU從機框架有一次需要在一個STM32F103項目上實現(xiàn)Modbus RTU從機功能。之前沒做過Modbus對協(xié)議細節(jié)不太熟。我的做法是先讓AI解釋Modbus RTU的幀格式和狀態(tài)機邏輯然后讓它生成一個從機框架。AI給出的框架包括串口接收中斷將字節(jié)存入緩沖區(qū)主循環(huán)中調(diào)用解析函數(shù)解析函數(shù)按照地址域、功能碼、數(shù)據(jù)域、CRC的順序逐段處理。框架里還包含了CRC16的計算函數(shù)和幾個常用功能碼03讀保持寄存器、06寫單個寄存器、16寫多個寄存器的處理函數(shù)。我拿到框架后主要做了三件事一是把寄存器映射表改成項目實際需要的變量二是調(diào)整了超時判斷的邏輯AI給的超時時間太長三是在功能碼處理函數(shù)里加入了參數(shù)范圍檢查。整個Modbus從機功能從開始到調(diào)通大概用了半天時間。如果完全自己寫光是把協(xié)議文檔看明白就得花不少時間。這個例子里AI的價值在于它幫我跳過了學習協(xié)議細節(jié)的階段直接給出了一個可運行的框架。我只需要在這個框架上做項目相關的適配而不需要從零理解Modbus的每一個字節(jié)。6.2 排查HardFault時AI給出的排查路徑HardFault是STM32開發(fā)中最讓人頭疼的問題之一。有一次我遇到一個偶發(fā)的HardFault大概運行幾十分鐘才出現(xiàn)一次用調(diào)試器很難捕捉。我把現(xiàn)象描述給AI程序運行一段時間后進入HardFault_Handler不固定時間不固定位置已經(jīng)排除了數(shù)組越界和空指針。AI給出了幾條排查路徑檢查堆棧溢出、檢查中斷優(yōu)先級配置、檢查DMA訪問越界、檢查未對齊的內(nèi)存訪問。我按照這個路徑逐一排查最后發(fā)現(xiàn)是DMA傳輸?shù)哪繕司彌_區(qū)大小設置錯了偶爾會寫越界覆蓋了相鄰的變量。這個問題如果靠我自己想可能要花更長時間才能定位。AI的價值在于它提供了一個系統(tǒng)的排查清單避免了我只盯著自己懷疑的方向而忽略其他可能。6.3 一個AI幫倒忙的教訓也有翻車的時候。有一次我讓AI幫忙優(yōu)化一段ADC采樣的代碼要求提高采樣速度。AI給出的方案是去掉所有的返回值檢查、用寄存器直接操作替代HAL庫函數(shù)、把采樣循環(huán)展開。代碼確實快了但運行一段時間后偶爾會讀到異常值。排查后發(fā)現(xiàn)AI去掉返回值檢查的同時也去掉了一個必要的狀態(tài)等待循環(huán)。ADC轉(zhuǎn)換完成標志還沒置位就讀取數(shù)據(jù)寄存器讀到的自然是無效值。這個教訓讓我明白AI的優(yōu)化建議必須結合具體的硬件行為來評估。它知道怎么讓代碼跑得更快但它不知道ADC轉(zhuǎn)換需要時間這個物理約束。后來我在要求AI優(yōu)化代碼時會明確加上不能改變硬件操作的時序要求這個約束條件。7. 協(xié)同流程的邊界與個人體會7.1 AI能幫你到什么程度經(jīng)過一年多的實踐我對AI在STM32開發(fā)中的能力邊界有了比較清晰的認識。AI最擅長的是模式化的代碼生成。外設初始化、通信協(xié)議框架、數(shù)據(jù)處理算法、狀態(tài)機結構這些有固定模式的代碼AI生成的質(zhì)量和速度都很好。它相當于一個熟悉各種常見實現(xiàn)的助手能快速給出一個可用的起點。AI也能做代碼審查和排錯建議。把代碼貼給它它能指出一些明顯的錯誤和潛在的風險點。雖然不一定全面但作為人工審查的補充是有價值的。AI還能做知識查詢和方案對比。比如STM32F4和STM32H7的SPI外設有什么區(qū)別、用DMA和用中斷實現(xiàn)串口接收各有什么優(yōu)缺點這類問題AI能給出比較全面的回答省去了翻論壇和文檔的時間。7.2 AI目前還做不好的事情AI做不好的事情也很明確。它不理解你的硬件。你的板子上有什么外設、引腳怎么接的、傳感器是什么型號這些它都不知道。你必須把這些信息準確地告訴它它才能生成有用的代碼。它不理解你的項目約束。你的項目對功耗、成本、實時性、可靠性有什么要求這些它也不知道。它生成的代碼可能在功能上正確但在你的項目約束下不可用。它不能替代調(diào)試。代碼燒進去不跑AI幫不了你。它只能根據(jù)你描述的現(xiàn)象給出排查方向但實際的調(diào)試工作——接示波器、看波形、讀寄存器、單步跟蹤——還是得你自己來。7.3 我現(xiàn)在的日常協(xié)同流程最后分享一下我現(xiàn)在的工作流程供你參考。接到一個新需求先花十分鐘想清楚外設配置和業(yè)務邏輯用輸入-處理-輸出框架在紙上列出來。然后打開AI對話用模板化的描述讓AI生成初始化代碼和基礎函數(shù)。編譯通過后用驗證代碼做基本功能測試?；A功能沒問題了再讓AI生成業(yè)務邏輯框架。業(yè)務邏輯調(diào)通后做一輪代碼審查重點看中斷、DMA、時鐘、堆棧這幾個地方。審查通過后再讓AI幫忙寫一些邊界測試和異常處理的代碼。整個流程里AI承擔了大概60%到70%的代碼量但關鍵的決策、驗證、調(diào)試、優(yōu)化還是我自己來做。這個比例我覺得比較健康——既享受了AI帶來的效率提升又沒有把工程判斷的責任交給AI。嵌入式開發(fā)說到底是一門跟硬件打交道的手藝AI可以幫你寫代碼但它不能替你理解硬件。把AI當成一個知識面廣、手速快、但需要你把關的助手這個定位我覺得是最務實的。