在嵌入式开发中，代码审查远不只是检查命名规范、缩进风格或函数是否过长。
一段看起来完全正常的 C/C++ 代码，放到 MCU、RTOS、驱动或嵌入式 Linux 环境中，可能隐藏着更危险的问题：
- 中断与主循环共享变量，却没有正确处理可见性与并发问题；
- DMA 缓冲区没有处理 Cache 一致性，导致“偶现数据异常”；
- 等待硬件状态没有超时机制，设备异常后永久卡死；
- 在中断上下文调用阻塞函数，引发系统调度异常；
- 动态内存长期运行产生碎片，设备数月后随机崩溃；
- 高优先级任务被低优先级任务间接阻塞，实时性逐渐失控。
传统代码审查依赖工程师经验，而普通 AI 提示词又存在一个问题：每次都要重新告诉 AI“重点检查什么”。
于是，一个更适合工程化开发的思路出现了：
把嵌入式开发中长期积累的经验、规范和故障案例，封装成可重复调用的 Skill。
这样做的本质，不是让 AI “记住更多规则”，而是把一次性的 Prompt，升级为一个稳定、可复用、可维护的工程工作流。
一、为什么普通 Prompt 不够用？
假设每次代码审查都输入：
帮我审查当前代码，重点检查：
1. 中断和主循环共享变量
2. DMA 缓冲区
3. Cache 一致性
4. RTOS 任
