芯耀
与非AI
712
1. 为什么嵌入式需要一份“专用”的审查清单？
先问大家一个问题：你让 AI 帮你 review 一段嵌入式 C 代码，它是不是经常给你这样的反馈——
“变量命名可以更清晰”“注释可以更完整”“建议把长函数拆分成几个小函数”……
这些建议对吗？对。有用吗？有，但优先级不对。
嵌入式系统最怕的是什么？
所以，嵌入式代码审查需要一份专用的 Checklist——告诉 AI：先看会不会出事，风格建议往后放。
2. 嵌入式 AI 代码审查 Checklist
下面这份清单，分六个维度，按优先级从高到低排列。
2.1 第一优先级：正确性缺陷（发现即报告）
这类问题一旦存在，系统几乎一定会出问题。AI 审查时，只要有 50% 的怀疑就应该报告。
内存安全：
并发与同步：
整数与边界：
错误处理：
2.2 第二优先级：嵌入式专属风险
这类问题在通用软件中不常见，但在嵌入式领域是高频事故源。
2.3 第三优先级：实时性风险
2.4 第四优先级：编码规范与风格
重要提醒：这一优先级的优先级最低。 先确保不出事，再追求好看。
2.5 第五优先级：AI 生成代码专项检查
如果代码是由 AI 生成的，还需要额外检查：
2.6 第六优先级：审查时的通用原则
3. 把这些审查要点制作成 Skill
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）？
- [ ] 是否存在硬编码的密码、密钥或魔数？
- [ ] 硬件相关注释是否准确？
## 输出格式
- **严重问题**（必须修复）：正确性缺陷
- 🟠 **高风险**（强烈建议修复）：嵌入式专属风险
- 🟡 **中风险**（建议修复）：实时性问题
- 🟢 **低风险/建议**：风格和规范问题
## 审查原则
- 理解代码的硬件上下文（芯片型号、外设资源、编译配置）
- 建立“软件逻辑 ↔ 硬件约束”的双向映射
- 对可疑代码实施“双重校验”：静态分析 + 逻辑推理
4. 总结
嵌入式代码审查，正确性 > 稳定性 > 实时性 > 风格。把这个优先级刻进 AI 的工作规则里，可以大大提高审查效率。
阅读全文
