给Hermes写了第一个Skill

PDF扔进去，寄存器地址自动出来

第3篇写了一半的时候，顺手让AI创建了一个查询芯片寄存器的Skill。这篇说说创建的过程和实际效果。

一、每天重复的问题

第3篇写的是让Hermes帮忙查芯片手册。写那篇文章的过程中，我反复用到三个芯片的寄存器信息：SH367309的过充保护、N32L406的ADC采样率、HC32L170的系统时钟。每次都要说一遍完整的指令：「帮我查一下SH367309过充保护寄存器的地址」。

我发现一件事：我在重复问同样的问题。同一个PDF、同一个章节、同一个寄存器——昨天问了今天又问。Hermes每次都要从头处理一遍，我也每次都要把指令完整说一遍。

之前在飞书上看过Hermes有一个叫Skill的功能，说是可以把常用操作写成固定流程，以后遇到同类任务直接走流程，不用每次从零开始。我当时没当回事，觉得「先把手头的用了再说」。

后来有一天整理笔记的时候又看到这个功能说明，想了一下，试试吧。

二、让AI帮忙建一个

我说先创建一个叫bms-register-lookup的Skill，用来查BMS项目里三个芯片的寄存器地址。AI那边有一个叫skill_manage的工具，直接帮我生成了Skill文件。

Skill就是一个Markdown文件，长这样：前面是一段YAML格式的描述——名字叫什么、什么时候触发、属于什么分类。后面是正文——遇到这个任务应该怎么做。

Skill的核心就三件事：

什么情况下触发（收到「查一下 SH367309 过充保护」这种话）

触发之后做什么（找对应PDF → LiteParse解析 → 定位寄存器章节）

最终输出什么（寄存器地址 + 位定义）

我一开始担心写Skill要写代码。后来发现完全不是那么回事——Skill定义的是「流程」而不是「代码」。你告诉Hermes遇到这类问题按什么步骤来处理，它自己会去调用相应的工具来完成每一步。不需要写一行Python。

从决定要建到这个Skill文件落地，前前后后不到十分钟。大部分时间花在想清楚上面那三件事。想清楚了，AI生成文件就是几秒钟的事。

三、Skill建好之后

Skill建好之后我试了一下触发逻辑——输入「查一下SH367309 过充保护」，Hermes确认加载了bms-register-lookup这个Skill，说明匹配上了。目前完整的解析流程还没跑通，因为PDF存在我的Windows开发机上，需要通过SSH同步到服务器。但骨架已经搭好了，配好路径就能用。

另外我发现Skill有一个意料之外的好处：以后换新芯片，不需要重新写一个Skill。只需要在文件里的芯片列表表格中加一行——芯片名、PDF文件名、主要用途。Hermes会按新行的逻辑来处理。不像以前每次换芯片都要重新学一遍它的手册结构。

目前这个Skill支持三个芯片：SH367309（BMS AFE，过充过放保护）、N32L406（主控MCU，ADC和系统时钟）、HC32L170（辅控MCU，GPIO和UART）。每个芯片的常用寄存器地址我都列在了Skill的速查表里。

四、好的和不好的

不好的：

Skill的触发条件需要自己设计——太灵活的任务不适合写成固定流程，硬写反而束手束脚。

Skill目前是本地文件，没有好用的管理界面，多了之后靠文件名识别，不太方便。

扫描版PDF（不是文字版）LiteParse处理不了，这种PDF上Skill帮不上忙。

好的：

一次建好，以后不用重复说同样的指令。

Skill文件可以分享给团队，大家一起用同一套查询方式。

以后换新芯片，在表格里加一行就行，不需要重新写逻辑。

对比一下：

五、适合谁看

如果你已经用Hermes帮你查手册了，但发现每天在重复发同样的指令——可以试试建一个Skill。不需要会写代码，跟AI描述一下你想让它记住什么，它就能帮你生成。

如果你刚装完Hermes，觉得它跟普通的AI聊天没区别——Skill机制是它跟纯对话最大的不同。它不是每次都从零想怎么回答，而是遇到同类问题时知道该怎么做。

下篇预告：让Hermes连上Windows服务器，不只查手册。是直接在Keil工程里搜驱动代码、找函数定义、定位bug。讲怎么让Hermes通过SSH管C盘里的源码。

豫见嵌入式 · AI + 嵌入式开发