乐于分享
好东西不私藏
当前位置：夜雨聆风 > 技术教程 > 软件教程 > AI Skill 第一篇:什么是 AI Skill?为什么 AI 辅助工程和 Project Velocity 都需要它?

AI Skill 第一篇:什么是 AI Skill?为什么 AI 辅助工程和 Project Velocity 都需要它?

当前时间： 2026-05-06 13:45:26 更新时间： 2026-05-06 分类：软件教程 评论(0)

AI Skill 第一篇:什么是 AI Skill?为什么 AI 辅助工程和 Project Velocity 都需要它?

最近我一直在思考一个问题：

当 AI Agent 越来越强，Codex、Claude Code、Antigravity、OpenCode 这些工具都可以读代码、改代码、运行命令、协助调试时，工程师下一步应该做什么？

我的答案不是：

继续写更多 Prompt。

而是：

把真实工程经验沉淀成 AI Skills。

这也是我接下来准备为 Project Velocity 做的一件事：

不是简单让 AI 帮我写代码，
而是一步一步为 Project Velocity 设计一套工程 Skills，
让 AI Agent 真正理解一个 AIoT 系统是如何从 MCU 节点、通信协议、边缘网关、云平台，到测试验证和工程交付一步一步完成的。

一、什么是 AI Skill？

很多人一听到 Skill，会以为它只是一个更复杂的 Prompt。

其实不是。

在工程项目中，一个真正有用的 AI Skill，至少应该包含六个部分：

第一，任务目标。
这个 Skill 到底要解决什么问题？

第二，输入文件。
AI Agent 需要读取哪些资料？比如原理图、Pinout、配置文件、代码、日志、协议文档。

第三，执行步骤。
AI Agent 应该按照什么顺序完成任务？先看硬件，还是先改代码？先查配置，还是先看日志？

第四，工程规则。
哪些文件可以修改？哪些文件不能乱动？哪些地方必须保持兼容？哪些地方需要人工确认？

第五，输出模板。
最后应该输出代码、文档、测试步骤、修改说明，还是问题分析报告？

第六，验证方法。
如何证明这个结果是对的？是编译通过，还是串口日志正确？是 CAN 报文正常，还是云端 Dashboard 能看到数据？

所以，AI Skill 不是一句话：

“帮我写一个 STM32 程序。”

真正的 Skill 更像这样：

“请基于 STM32F103 的硬件连接、Zephyr board 配置、设备树 overlay、prj.conf、CANopen 对象字典和测试日志，生成或修改一个可构建、可烧录、可验证的 Zephyr 节点程序，并输出测试步骤和验证结果。”

这才是工程场景中真正有价值的 AI Skill。

二、Skill 和 Prompt 有什么区别？

Prompt 更像一次性的指令。

Skill 更像可复用的工程能力。

比如，一个 Prompt 可以这样写：

“帮我写一段 CAN 通信代码。”

AI 很可能马上生成一段代码。

看起来很快。

但问题是：

这段代码适合哪个 MCU？
CAN 波特率是多少？
是裸 CAN，还是 CANopen？
使用哪个 Node ID？
发送过程数据对象（TPDO） 和 接收过程数据对象（RPDO） 如何定义？
这个节点和边缘网关如何通信？
代码写完以后如何测试？
如果编译失败，应该先查 main.c，还是先查设备树和 prj.conf？

这些问题，如果每次都靠临时 Prompt 补充，效率很低，也很容易漏掉关键边界。

Skill 的作用，就是把这些上下文固定下来。

它告诉 AI Agent：

这个项目是什么；
这个模块负责什么；
输入文件在哪里；
工程边界是什么；
修改顺序是什么；
如何验证结果；
如何输出交付文档。

所以，Prompt 关注的是：

这一次让 AI 做什么。

Skill 关注的是：

以后类似任务，AI 应该怎么做。

三、为什么 Project Velocity 需要 AI Skills？

Project Velocity 不是一个简单的软件项目。

它是一个端到端的 AIoT 工程系统。

在这个系统中，底层有：

  • STM32F103；

  • Zephyr RTOS；

  • 传感器；

  • 执行器；

  • CAN / CANopen 通信。

边缘侧有：

  • RK3588 Linux Gateway；

  • MQTT；

  • OPC UA；

  • 本地缓存；

  • 日志管理；

  • 边缘侧数据处理和 AI 推理。

云端有：

  • ThingsBoard；

  • Telemetry；

  • RPC 控制；

  • Dashboard；

  • 告警规则；

  • 数据存储和查询。

这不是一个“让 AI 写几段代码”就能完成的项目。

它涉及真实硬件、真实协议、真实部署、真实调试和真实交付。

如果只让 AI Agent “帮我写代码”，它很容易进入一种状态：

代码很多，
解释很漂亮，
但系统跑不起来。

这就是我之前反复提到的 Vibe Coding 问题。

Vibe Coding 的特点是：

AI 写得很快，
人看得很爽，
但一到真实硬件、真实协议、真实测试，就开始暴露问题。

而 Project Velocity 要做的不是 Vibe Coding。

它要做的是：

AI-Assisted Engineering。

也就是让 AI 进入真实工程流程，但工程边界、系统架构、测试标准和交付责任，仍然由工程师定义。

四、AI Agent 需要的不只是代码上下文

很多人使用 AI Coding Agent 时，习惯把代码仓库交给 AI，然后说：

“帮我实现这个功能。”

在 Web 项目里，这样有时候可以工作。

但在嵌入式和 AIoT 项目中，这远远不够。

因为 AI Agent 需要理解的不只是代码。

它还需要理解：

硬件是怎么连接的；
哪个 GPIO 接了传感器；
哪个 UART 被占用；
CAN 收发器接在哪个控制器上；
Zephyr 的设备树有没有启用外设；
prj.conf 有没有打开对应的驱动和协议栈；
CANopen 对象字典如何定义；
Edge Gateway 如何解析节点数据；
MQTT Topic 如何映射到云端；
ThingsBoard Dashboard 如何显示遥测数据；
RPC 命令如何从云端返回到 MCU 节点。

这些内容不一定都在代码里。

它们可能分布在：

  • 原理图；

  • Pinout 图片；

  • Excel 表格；

  • PDF 数据手册；

  • Markdown 文档；

  • build log；

  • serial log；

  • CAN 抓包；

  • MQTT 调试记录；

  • ThingsBoard 配置截图。

如果不把这些资料整理成 AI 可以理解的结构化输入，AI Agent 就很难真正理解工程。

这也是为什么 Project Velocity 需要 Skills。

五、Project Velocity 可以设计哪些 AI Skills？

我计划从最底层开始，一层一层为 Project Velocity 设计 AI Skills。

1. STM32 Zephyr Node Skill

这是第一个 Skill。

它帮助 AI Agent 理解 MCU 节点，包括：

  • STM32F103；

  • Zephyr RTOS；

  • GPIO / ADC / I2C / SPI / UART；

  • 设备树 overlay；

  • prj.conf；

  • main.c；

  • 传感器采集；

  • CANopen 通信；

  • 构建、烧录和串口调试。

这个 Skill 的重点是：

AI Agent 不能只看 main.c。

它必须同时理解硬件、配置、驱动、构建和测试。

2. Communication Protocol Skill

这个 Skill 让 AI Agent 理解 Project Velocity 的通信链路。

包括：

  • CAN；

  • CANopen；

  • TPDO；

  • RPDO；

  • MQTT；

  • OPC UA；

  • Edge 与 Cloud 之间的数据映射。

它的重点不是简单解释协议概念，而是帮助 AI Agent 生成一致、可测试、可追踪的协议映射。

3. Edge Gateway Skill

这个 Skill 面向 RK3588 边缘网关。

它需要处理：

  • Linux 服务；

  • systemd；

  • CANopen 到 MQTT 的桥接；

  • OPC UA 接入；

  • 本地日志；

  • 断网缓存；

  • 异常恢复；

  • 本地 AI 推理；

  • 边缘侧部署。

边缘网关不是简单的数据转发器。

它是 AIoT 系统中非常关键的一层。

4. Cloud & ThingsBoard Skill

这个 Skill 让 AI Agent 理解云端数据闭环。

包括：

  • 设备接入；

  • Access Token；

  • Telemetry；

  • Attribute；

  • RPC；

  • Dashboard；

  • Alarm；

  • 数据保存和查询。

它的目标是让 AI Agent 不仅能写上报代码，还能帮助设计云端展示、控制和验证流程。

5. Test & Validation Skill

这是从 Vibe Coding 走向 AI-Assisted Engineering 的关键。

AI Agent 不应该只输出代码。

它还应该输出：

  • 测试计划；

  • 测试命令；

  • 预期结果；

  • 判断标准；

  • 日志分析；

  • 问题定位报告；

  • 可交付证据。

工程不是“写完就结束”。

工程必须证明系统真的工作。

6. Documentation Skill

这个 Skill 负责把工程过程沉淀成文档。

包括：

  • README；

  • 接口说明；

  • 调试记录；

  • 测试报告；

  • 已知问题；

  • 版本变化；

  • 交付说明。

文档不是项目结束后的补充工作。

在 AI-Assisted Engineering 中，文档本身就是 AI Agent 的长期记忆。

六、从 Prompt 到 Skill，是工程师角色的变化

过去，我们习惯问：

AI 会不会写代码？

现在，我更关心另一个问题：

工程师能不能把自己的经验，变成 AI 可以复用的 Skill？

因为 AI Agent 本身越来越强。

但如果没有工程上下文，它只能根据概率生成答案。

在真实 AIoT 项目中，AI 需要知道：

这个硬件能不能这样用；
这个协议能不能这样映射；
这个配置会不会导致编译失败；
这个修改会不会影响已有功能；
这个测试结果能不能证明系统可用；
这个输出能不能交付给客户或团队。

这些判断，来自工程经验。

而 Skill，就是把工程经验结构化、模块化、可复用地交给 AI Agent。

这也是我理解的 AI-Assisted Engineering：

不是让 AI 取代工程师，
而是让工程师学会管理 AI、训练 AI、约束 AI、验证 AI，
最终把 AI 变成真正可用的工程助手。

七、下一步：从 STM32 Zephyr Node Skill 开始

接下来，我会从 Project Velocity 的最底层开始，设计第一个具体 Skill：

STM32 Zephyr Node Skill。

这个 Skill 的目标不是让 AI Agent 写一个简单的 LED blink 程序。

而是让它理解一个真实 AIoT 节点：

  • 使用什么 MCU；

  • 使用什么开发板；

  • 使用什么传感器；

  • 使用什么 CAN 收发器；

  • 使用 Zephyr 哪些配置；

  • 如何定义设备树；

  • 如何配置 prj.conf；

  • 如何编写 main.c；

  • 如何构建；

  • 如何烧录；

  • 如何通过串口和 CAN 报文验证；

  • 如何继续接入 Edge Gateway 和 ThingsBoard。

这才是 Project Velocity 的起点。

不是让 AI 生成一堆看起来不错的代码。

而是让 AI Agent 逐步进入真实工程系统。

一句话点评

AI Skill 不是更长的 Prompt，而是工程师把经验、边界、流程和验证方法沉淀给 AI Agent 的方式。

结语

未来真正强大的工程师，不一定是每天写最多代码的人。

而是能够把复杂工程拆解清楚，把知识结构化，把流程标准化，并把这些能力交给 AI Agent 的人。

从这个角度看，Project Velocity 不只是一个 AIoT 项目。

它也是一次尝试：

如何从 Vibe Coding 走向 AI-Assisted Engineering；
如何从一次性 Prompt 走向可复用 Skill；
如何把 AI Agent 从“会聊天的助手”，训练成“懂工程的伙伴”。

下一篇，我们从第一个 Skill 开始，进行实践：

如何设计 Project Velocity 的 STM32 Zephyr Node Skill？