星標公眾號，讓嵌入式知識 “投喂” 不停歇！
先問大家一個問題：你讓 AI 幫你 review 一段嵌入式 C 代碼，它是不是經常給你這樣的反饋——
“變量命名可以更清晰”“注釋可以更完整”“建議把長函數拆分成幾個小函數”……
這些建議對嗎？對。有用嗎？有，但優先級不對。
嵌入式系統最怕的是什么？
所以，嵌入式代碼審查需要一份專用的 Checklist——告訴 AI：先看會不會出事，風格建議往后放。
下面這份清單，分六個維度，按優先級從高到低排列。
這類問題一旦存在，系統幾乎一定會出問題。AI 審查時，只要有 50% 的懷疑就應該報告。
內存安全：
并發與同步：
整數與邊界：
錯誤處理：
這類問題在通用軟件中不常見，但在嵌入式領域是高頻事故源。
重要提醒：這一優先級的優先級最低。 先確保不出事，再追求好看。
如果代碼是由 AI 生成的，還需要額外檢查：
SKILL.md 是 Skill 的入口文件，包含 YAML frontmatter 和核心指令。
下面是一個可以直接用的模板：
---
name: embedded-code-review
description: 嵌入式 C/C++ 代碼審查。用于審查嵌入式Linux、MCU、RTOS、驅動、BSP 相關代碼，重點發現內存安全、并發競態、中斷上下文誤用、DMA/cache 一致性、實時性風險等問題。
---
# 嵌入式 C/C++ 代碼審查 Skill
## 觸發條件
當用戶要求審查嵌入式 C/C++ 代碼、驅動代碼、RTOS 相關代碼、BSP 代碼時自動啟用。
## 核心原則
**先看會不會死機、丟數據、破壞硬件狀態、影響實時性。風格建議往后放。**
## 審查流程
1. **首先**：掃描第一優先級——正確性缺陷（內存安全、并發競態、整數邊界、錯誤處理）
2. **其次**：檢查嵌入式專屬風險（DMA/cache 一致性、動態內存、硬件超時、中斷上下文）
3. **然后**：評估實時性風險（優先級反轉、ISR 長度、阻塞調用）
4. **最后**：給出風格建議（優先級最低）
## 嵌入式專項檢查要點
### ?? 第一優先級：正確性缺陷
- [ ] 是否存在 use-after-free、double-free？
- [ ] 錯誤路徑上是否有資源泄漏（內存、文件描述符、鎖）？
- [ ] 是否存在 NULL 指針解引用？
- [ ] 是否存在緩沖區溢出或數組越界？
- [ ] 是否存在未初始化變量在可達路徑上被使用？
- [ ] 共享狀態是否存在競態條件？
- [ ] 中斷上下文中是否調用了可能阻塞的函數？
- [ ] 長度字段是否先驗證再使用？
- [ ] 整數運算是否存在溢出或截斷？
- [ ] 可能失敗的函數調用是否檢查了返回值？
### ?? 第二優先級：嵌入式專屬風險
- [ ] 是否使用了動態內存分配（malloc/free）？如有，是否有嚴格規范？
- [ ] DMA buffer 是否處理了 cache 一致性？
- [ ] 等待硬件狀態是否有超時機制？
- [ ] 任務間共享變量是否有保護措施？
- [ ] 是否存在忙等（busy-wait）而無合理退出條件？
- [ ] 寄存器操作和硬件交互邏輯是否正確？
### ?? 第三優先級：實時性風險
- [ ] 是否存在優先級反轉風險？
- [ ] 關鍵路徑上是否有不可預測執行時間的操作？
- [ ] 中斷服務程序（ISR）是否足夠短？
### ?? 第四優先級：編碼規范
- [ ] 是否符合團隊編碼風格？
- [ ] 函數圈復雜度是否過高（建議 ≤ 10-15）？
- [ ] 是否存在硬編碼的密碼、密鑰或魔數？
- [ ] 硬件相關注釋是否準確？
## 輸出格式
- ?? **嚴重問題**（必須修復）：正確性缺陷
- ?? **高風險**（強烈建議修復）：嵌入式專屬風險
- ?? **中風險**（建議修復）：實時性問題
- ?? **低風險/建議**：風格和規范問題
## 審查原則
- 理解代碼的硬件上下文（芯片型號、外設資源、編譯配置）
- 建立“軟件邏輯 ? 硬件約束”的雙向映射
- 對可疑代碼實施“雙重校驗”：靜態分析 + 邏輯推理
嵌入式代碼審查，正確性 > 穩定性 > 實時性 > 風格。把這個優先級刻進 AI 的工作規則里，可以大大提高審查效率。
如果這篇文章對你有幫助，歡迎點贊、轉發。
猜你喜歡：
適用于嵌入式的輕量級環緩沖區管理庫！
Git 交互式變基修改commit描述
單例模式：嵌入式全局狀態一致性的守護者
嵌入式領域：Linux 與 RTOS 的巔峰對決！
嵌入式軟件進階指南，一起來進階！
