什么是Skill系统
在使用AI编码助手（如Cursor、Claude Code等）进行嵌入式开发时，我们经常遇到以下问题：
- AI在需求不明确时自行"幻想"实现
- 只看报错文件就开始修Bug，忽略了调用链上下文
- 没有例程或数据手册就编写硬件驱动
- 覆盖用户已有未提交的修改
- BSP、middleware、app分层混乱
xiaozhi-esp32-dev项目提出了一套Skill系统，通过规则文档+Hook脚本的方式，约束AI在ESP-IDF嵌入式开发中的行为。
架构设计
text
app / main 业务流程编排
↓
middleware 能力抽象、状态管理、策略封装
↓
bsp 外设驱动、板级硬件适配
↓
esp-idf drivers 底层外设接口
任何新代码都必须先判断归属层级，再编写实现。这种分层架构确保了代码的可维护性和可扩展性。
两层规则体系
1. 确定性Hooks（脚本强制执行）
通过Node.js脚本实现，100%强制执行，不依赖AI判断：
| 触发时机 | 脚本 | 行为 |
|---|---|---|
| 写文件前 | git-status-check.js | 工作区有未提交修改时阻止操作 |
| 写文件后 | post-edit-reminder.js | 提醒检查CMake/Kconfig/README |
| 任务完成时 | stop-check.js | 提醒回复须包含变更清单和commit建议 |
2. 行为准则（AI智能判断）
以下规则依赖AI理解和上下文判断：
- 需求与Bug上下文阅读：不只看报错文件，必须同步查看调用链、配置文件、构建系统和组件初始化逻辑
- 需求不明确阻断：缺少硬件型号、接口、例程等关键信息时，必须先提问，禁止幻想实现
- 新硬件资料确认：编写驱动前必须确认例程或数据手册是否充分，缺则停止实现
实际应用示例
Bug修复流程
text
1. 阅读报错信息
2. 向上追溯调用链
3. 检查相关配置文件
4. 确认构建系统状态
5. 编写修复代码
6. 运行验证
7. 说明变更范围
新硬件驱动开发
text
1. 确认硬件型号和接口
2. 查找官方例程或数据手册
3. 确定代码归属层级（BSP/middleware/app）
4. 编写驱动代码
5. 更新Kconfig配置
6. 更新CMake依赖
7. 更新README文档
项目结构
text
xiaozhi-esp32-dev/
├── SKILL.md # Skill主入口
├── README.md # 项目说明
├── hooks/ # Hook脚本
│ ├── git-status-check.js
│ ├── post-edit-reminder.js
│ └── stop-check.js
└── docs/ # 22个详细规则文档
├── 01-git-status-check.md
├── 02-code-reading-principles.md
├── 03-superpowers-collaboration.md
└── ...
禁止行为
- 不检查Git状态就修改代码
- 只阅读单个文件就开始修复Bug
- 需求不明确时自行幻想实现
- 没有硬件资料就写驱动
- 把BSP和middleware混在一起
- 覆盖用户已有未提交修改
总结
Skill系统为AI编码助手提供了明确的行为约束，让AI在嵌入式开发中更加可靠。通过规则文档+Hook脚本的组合，既保证了强制性规则的执行，又保留了AI在复杂场景下的判断能力。
对于从事ESP32或其他嵌入式开发的团队，这套思路值得借鉴。
评论 (0)