Skill是什么，嵌入式开发也该开始准备了

刚开始用 AI 写代码的时候，大家更多是让它写一个函数。比如写一个 CRC 校验，写一个环形缓冲区，写一个串口解析函数，或者解释一段 C 语言指针代码。

后来它能看一个源文件，能帮你分析一个模块，能根据已有接口补一套驱动框架，能做一些简单的重构。

到了去年下半年到现在，变化更明显了。

它已经不只是“帮你补几行代码”，而是开始能围绕整个工程工作。你把目录结构、构建方式、关键模块、编码习惯给它，它可以帮你分析工程关系、迁移平台、调整接口、补测试、改文档，甚至生成一套比较完整的新工程骨架。

这就是我觉得有点量变到质变的地方。

以前我们是在和一个“代码补全工具”协作。

现在更像是在和一个“工程助手”协作。

但问题也来了。

如果每次做项目，都要重新告诉 AI：我们驱动怎么写、错误码怎么定义、RTOS 任务怎么检查、寄存器手册怎么整理、代码 review 重点看什么，那效率还是会浪费很多。

所以我觉得，接下来嵌入式工程师需要开始重视一个东西：Skill。

1

Skill 不是玄学，就是可复用的工程经验包

Skill 这个词听起来有点新，但我的理解很简单。

它不是一句提示词，也不是一个万能插件。

它更像是把你反复使用的工程经验、检查清单、脚本、模板、代码规范，整理成一个 AI 可以调用和遵守的能力包。

比如你每次让 AI 写嵌入式 C 代码，都会提醒它：

不要动态分配内存。

中断里不要做阻塞操作。

错误码要统一返回。

所有等待都要有超时。

驱动层不要直接打印日志。

硬件寄存器位不确定时要标注需要查手册。

这些话如果每次都手动输入，就很麻烦。

但如果把它们沉淀成一个 Skill，以后你只要说“按我们的嵌入式驱动开发规则来写”，AI 就应该知道怎么做。

这就是 Skill 的价值。

它让 AI 不只是回答你的问题，而是按照你的工程习惯工作。

2

为什么现在才需要认真考虑 Skill

以前其实也可以写提示词模板。

但那时候 AI 的能力更多停留在局部。你让它写一个函数，提示词写得再好，也主要影响这一小段代码。

现在不一样。

当 AI 开始能理解整个工程，能跨文件修改，能生成目录结构，能整理文档和脚本时，它的输出范围变大了，风险也变大了。

一个函数写得不好，最多局部返工。

一个工程级重构如果没有规则，可能会把接口风格、错误处理、目录边界、构建脚本都改乱。

嵌入式开发尤其明显。

因为嵌入式工程里有很多不能随便发挥的地方。

比如内存很小，不能随便引入动态分配。

比如实时性有要求，不能在关键路径里加入阻塞等待。

比如 ISR 里能做什么、不能做什么，要有明确边界。

比如硬件相关的结论不能靠猜，寄存器位、时序、电气限制必须回到手册。

比如项目里可能有老代码、量产代码、客户定制代码，不是看起来不优雅就可以随便重构。

AI 越强，越需要规则约束。

否则它很容易“热心办坏事”。

Skill 的意义，就是把这些约束提前固化，让 AI 在动手之前就知道边界。

3

嵌入式开发最该准备哪些 Skill

如果从嵌入式日常工作出发，我觉得不用一上来搞得特别复杂。

先从最常重复、最容易漏项、最能节省时间的地方开始。

3.1、驱动开发 Skill

这是最值得先做的一类。

嵌入式项目里写驱动非常常见，但驱动代码又特别容易出现风格不统一的问题。

比如有的驱动返回 0/-1，有的返回枚举错误码。有的等待硬件状态没有超时，有的初始化函数顺序不清楚。有的直接在驱动层打印日志，有的把外设句柄暴露得到处都是。

一个驱动开发 Skill 里，至少应该包含这些规则：

• 初始化、反初始化、读写、控制接口的命名风格；
• 错误码定义方式；
• 超时处理要求；
• 参数检查要求；
• 是否允许阻塞；
• 是否允许动态内存；
• 寄存器位和时序必须人工确认；
• 示例代码需要标注依赖的底层接口。

以后让 AI 写 SPI Flash、I2C 传感器、UART 协议、GPIO 扩展芯片驱动时，就不再是从零开始聊天，而是按同一套驱动规则生成。

这会比单纯说“帮我写一个驱动”靠谱很多。

3.2、RTOS 问题排查 Skill

RTOS 相关问题很适合做成 Skill。

因为这类问题有固定的排查路径，但每次现场信息又不完全一样。

比如任务卡死、队列满、死锁、优先级反转、栈溢出、低功耗唤醒异常、tick 不准，这些都可以整理成检查清单。

一个 RTOS 排查 Skill 可以要求 AI 在分析问题时按顺序输出：

• 已知现象；
• 还缺哪些现场信息；
• 可能方向；
• 每个方向的验证方法；
• 高风险操作提醒；
• 下一步建议加的日志或断点。

这样你把串口日志、任务状态、栈使用情况、最近改动贴进去，AI 就不会一上来拍脑袋说“可能是死锁”，而是先按工程排查流程走。

这对嵌入式调试很重要。

因为很多 bug 不怕难，怕的是一开始方向乱。

3.3、代码审查 Skill

代码审查也很适合沉淀。

AI 做 review 如果没有约束，经常会给一些很泛的建议，比如变量命名可以优化，注释可以增加，函数可以拆分。

这些建议不一定错，但对嵌入式项目来说，优先级不高。

嵌入式代码 review 更应该先看这些问题：

• 指针生命周期；
• 数组越界；
• 整数溢出；
• 中断和主循环共享变量；
• volatile 是否误用；
• ISR 中是否有阻塞、锁、打印；
• 超时是否可靠；
• 错误分支是否释放资源；
• DMA buffer 是否有 cache 一致性问题；
• 栈上是否开了大数组；
• 是否引入了不可控的动态内存。

把这些固化成代码审查 Skill 后，以后你让 AI review 一个模块，它就会更像一个懂嵌入式风险的同事，而不是一个泛泛而谈的代码助手。

3.4、datasheet 整理 Skill

做嵌入式绕不开手册。

但 AI 在手册问题上有一个风险：它有时会根据经验补全，而不是严格根据你提供的资料回答。

所以 datasheet 整理 Skill 的核心，不是让 AI “解释这个芯片怎么用”，而是约束它。

只基于我提供的手册段落。

没有出现的寄存器位不要补。

不确定的地方标注“需要人工确认”。

输出初始化流程、注意事项、必须确认项、风险点。

这类 Skill 对新芯片、新外设、新电源芯片、新传感器都很有用。

它能帮你把几十页资料先整理成检查清单，但不会替你做最终判断。

这个边界一定要留住。

3.5、日志和异常现场分析 Skill

嵌入式调试经常会有一堆现场信息。

串口日志、HardFault 寄存器、PC/LR/SP、map 文件、任务栈、复位原因、异常前后的版本改动。

如果直接把这些丢给 AI 问“为什么挂了”，它很容易给一个看似合理的猜测。

更好的方式，是做一个异常分析 Skill，要求它先整理证据链。

比如：

• 哪些是已知事实；
• 哪些只是猜测；
• 当前最可能的方向；
• 每个方向还需要补充什么数据；
• 下一步建议测什么、打什么日志、设什么断点；
• 哪些操作可能破坏现场。

这类 Skill 的价值，不是一次性找出真因，而是让排查过程不乱。

很多时候，调试效率就是从“不乱”开始提升的。

3.6、项目移植 Skill

项目移植也是一个高频场景。

比如从一个 MCU 换到另一个 MCU，从裸机换到 RTOS，从 Keil 换到 CMake，从 HAL 换 LL，从老 BSP 迁到新 BSP。

这种工作看起来是改代码，实际上更像整理差异。

一个项目移植 Skill 可以要求 AI 先输出：

• 原工程结构；
• 目标平台结构；
• 构建系统差异；
• 启动文件和链接脚本差异；
• 外设初始化差异；
• 中断和时钟差异；
• 需要人工确认的硬件差异；
• 可自动迁移和不能自动迁移的部分。

这样 AI 不会一上来乱改，而是先把迁移边界列出来。

对嵌入式来说，边界比代码更重要。

3.7、测试文档 Skill

最后一个很容易见效的是测试文档。

比如 bring-up checklist、DVT 测试表、版本发布检查表、问题复盘模板。

这些东西写起来不难，但很耗时间，而且格式经常不统一。

把它做成 Skill 后，每次测试完，把原始记录、测试条件、异常现象、修改记录给 AI，它就能按固定格式整理成文档。

这类 Skill 风险比较低，收益很稳定。

尤其是团队协作时，统一模板能减少很多沟通成本。

4

一个好用的 Skill 里面应该有什么

很多人一说 Skill，可能会以为就是写几句提示词。

我觉得不够。

如果真想在工程里稳定使用，它至少要包含四类东西。

第一，使用场景。

什么时候该触发这个 Skill，什么时候不该用。比如驱动开发 Skill 适合写外设驱动骨架，但不适合凭空确认寄存器位。

第二，工程规则。

这部分是核心。包括编码风格、错误处理、内存限制、实时性要求、日志规范、目录结构、接口边界。

第三，检查清单。

AI 很容易把代码写得很顺，但嵌入式开发最怕漏项。检查清单可以强制它在输出最后列出需要确认的地方。

第四，工具脚本和模板。

如果某些工作可以脚本化，就不要每次只靠对话。比如 map 文件分析、日志解析、代码扫描、测试表生成，都可以配合脚本做。

我认为真正好用的 Skill，应该是提示词、文档、脚本、模板的组合。

它不是让 AI 更会聊天，而是让 AI 更会干活。

5

我会怎么开始做

如果现在让我从零开始准备嵌入式 Skill，我不会一口气做很多。

我会先选三个。

第一个是代码审查 Skill。

因为它马上能用，而且风险低。先把嵌入式 C 常见风险整理进去，让 AI 每次 review 都按这些角度看。

第二个是驱动开发 Skill。

因为驱动开发重复度很高。只要把接口风格、错误码、超时、参数检查、手册确认项固化下来，后面生成的代码质量会稳定很多。

第三个是异常分析 Skill。

因为调试最消耗精力。把 HardFault、任务卡死、串口丢包、外设异常这些排查路径沉淀下来，实际价值很大。

等这三个用顺了，再扩展到 datasheet 整理、项目移植、测试文档。

还有一个简单的判断标准：

如果你连续三次把同一套要求复制给 AI，它就值得被做成 Skill。

比如你每次都说“不要动态内存，不要阻塞，中断里不要打印，必须有超时”，那就别再复制了，直接沉淀。

比如你每次都让 AI 按“已知事实、可能原因、验证方法、下一步动作”分析问题，那也应该沉淀。

Skill 不是一次写完的，它应该从日常工作里长出来。

AI 写代码这件事，已经走过了最开始的新鲜阶段。

以前它会写一个函数，我们觉得很厉害。

后来它能分析一个源文件，我们觉得效率提高了。

现在它开始能参与整个工程，能生成、重构、迁移、整理文档，这就不是简单的补全工具了。

能力变强以后，问题也变了。

我们不能只问“AI 能不能帮我写代码”，而要开始问：

我能不能让 AI 按我的工程习惯写代码？

我能不能让 AI 按我的排查方法分析问题？

我能不能把自己重复多年的经验，变成一个团队都能复用的能力？

这就是 Skill 值得关注的原因。

对于嵌入式开发来说，Skill 不应该是一个花哨概念。

它应该是一套很实在的东西：代码规则、检查清单、调试路径、脚本工具、文档模板。

AI 越强，越不能让它随便发挥。

真正有价值的，是让它带着工程边界、团队习惯和验证意识去工作。

以后比拼的，可能不只是“谁更会用 AI”。

而是谁更早把自己的工程方法，沉淀成 AI 可以稳定复用的 Skill。