前一篇，我介绍了 Project Velocity 的 STM32 Zephyr Node Skill 中，如何为传感器和执行器设计 AI Skill。

包括：

温度传感器；
温湿度传感器；
LED 开关；
4x4 矩阵键盘；
DC Motor 软启动；
红外发射与接收；
RFID RC522 I2C 读卡模块。

这些 Skill 解决的是一个问题：

STM32 节点如何感知世界？
STM32 节点如何控制设备？

但是，一个真正的 AIoT 系统，光有传感器和执行器还不够。

因为传感器采到的数据，必须可靠地发出去。
云端或网关下发的命令，必须安全地进来。
节点出现异常，必须能被发现。
现场出了问题，必须能调试、复现、定位。

所以，STM32 Zephyr Node Skill 的下一层，就是 系统通信 Skill。

一、为什么系统通信也需要 Skill？

很多人做嵌入式项目时，容易把通信协议当成“接口代码”。

比如：

“帮我写一个 CAN 接收。”
“帮我写一个 Modbus RTU。”
“帮我打印一些 debug log。”
“帮我加一个 watchdog。”

这些看起来都是小功能。

但在真实工程里，它们决定的是系统能不能稳定运行。

通信协议不是简单收发数据，而是要回答：

帧格式是什么？
谁发给谁？
周期是多少？
超时怎么办？
非法帧怎么办？
状态如何同步？
故障如何恢复？
日志如何定位问题？
现场如何验证？

如果这些问题没有写清楚，AI Coding Agent 很容易写出“能跑一次”的代码，却写不出“能长期运行”的系统。

这就是为什么 Project Velocity 需要系统通信 Skill。

二、系统通信 Skill 和传感器 Skill 有什么不同？

传感器和执行器 Skill 关注的是：

硬件连接
GPIO / ADC / PWM / I2C
设备状态
遥测数据
动作控制

系统通信 Skill 关注的是：

协议帧
状态同步
错误处理
超时恢复
调试验证
系统可靠性

前者解决“设备能不能动”。

后者解决“系统能不能长期可靠地协同工作”。

在 AIoT 系统里，这两层缺一不可。

三、建议的系统通信 Skill 目录结构

在上一篇的基础上，STM32 Zephyr Node Skill 可以继续扩展成下面这样：

stm32_zephyr_node_skill/
├── README.md
├── inputs/
│   ├── board_photo_back.jpg
│   ├── board_photo_front.jpg
│   ├── hardware_constraints.md
│   ├── jumper_setting.md
│   ├── stm32f103_board_pinout.md
│   ├── stm32f103_chip_pin_definition.md
│   ├── stm32f103_schematic.md
│   └── swd_connection.md
│
└── skills/
    ├── 00-stm32-zephyr-node-skill-index.md
    │
    ├── 01-stm32-lm35-temperature-sensor-skill.md
    ├── 02-stm32-temperature-humidity-sensor-skill.md
    ├── 03-stm32-pc13-led-switch-control-skill.md
    ├── 04-stm32-4x4-matrix-keypad-input-skill.md
    ├── 05-stm32-dc-motor-soft-start-control-skill.md
    ├── 06-stm32-infrared-transmitter-receiver-skill.md
    ├── 07-stm32-rfid-rc522-i2c-telemetry-skill.md
    │
    ├── 08-stm32-canopen-communication-skill.md
    ├── 09-stm32-modbus-rtu-rs485-skill.md
    ├── 10-stm32-debug-log-trace-skill.md
    ├── 11-stm32-heartbeat-watchdog-safety-skill.md
    ├── 12-stm32-firmware-build-flash-skill.md
    └── 13-stm32-uart-rtt-verification-skill.md

这里前 7 个是传感器和执行器 Skill。

从第 8 个开始，就是系统通信和验证 Skill。

这一步很关键。

因为 AI Agent 不能只会写业务功能代码，还必须理解：

怎么通信；
怎么同步；
怎么验证；
怎么调试；
怎么恢复；
怎么交付。

四、Project Velocity 的系统通信 Skill

下面是我计划为 Project Velocity 设计的几个系统通信 Skill。

1. CANopen Skill

第一个是 CANopen Skill。

严格来说，Project Velocity 当前可以先从 CAN synchronization and safety 做起，再逐步扩展到完整 CANopen。

CANopen Skill 要解决的问题不是“收一个 CAN 帧”这么简单，而是：

节点 ID 是什么？
对象字典怎么定义？
TPDO(发送过程数据对象) 发送哪些状态？
RPDO(接收过程数据对象) 接收哪些命令？
Heartbeat 怎么发？
Node guarding 或 heartbeat timeout 怎么处理？
异常状态如何进入 safe mode？

在 STM32 Zephyr 节点里，CAN 通信至少需要定义：

CAN bitrate
CAN ID 分配
命令帧
状态帧
Heartbeat 帧
错误帧处理
超时策略
恢复策略

例如，Project Velocity 的 STM32 节点需要和 Gateway 交换状态与命令。

可以定义：

TPDO: STM32 -> Gateway
    temperature
    humidity
    keypad
    motor status
    RFID UID
    heartbeat

RPDO: Gateway -> STM32
    LED control
    motor speed
    motor direction
    LCD text
    IR command
    lock command

CANopen Skill 里必须告诉 AI：

不要随便定义 CAN ID；
不要随便改变对象字典；
不要忽略 timeout；
不要把 malformed frame 当正常命令执行；
不要在中断里做复杂逻辑；
通信失败时要进入安全状态。

推荐信息模型：

can_node_id
can_bus_ready
can_last_rx_ms
can_last_tx_ms
can_heartbeat_alive
can_error_count
can_rx_frame_count
can_tx_frame_count
can_status

推荐遥测字段：

can_status
can_heartbeat_alive
can_error_count
can_last_rx_ms
can_last_tx_ms

CANopen Skill 的核心不是“会收发”，而是“会同步状态”。

2. Modbus over RS485 Skill

第二个是 Modbus over RS485 Skill。

在工业现场，Modbus RTU 仍然非常常见。

它简单、稳定、容易和 PLC、网关、测试工具对接。

但是 Modbus over RS485 也有很多工程细节：

波特率是多少？
数据位、校验位、停止位是什么？
设备地址是什么？
寄存器怎么映射？
RS485 方向控制怎么做？
CRC 如何校验？
超时如何处理？
非法功能码怎么办？

Modbus Skill 的核心，是寄存器表。

AI Agent 必须知道：

哪些是输入寄存器；
哪些是保持寄存器；
哪些是只读；
哪些是可写；
写入之后如何影响系统状态；
非法写入如何拒绝。

例如：

Input Registers:
    temperature
    humidity
    keypad
    rfid_uid
    motor_effective_speed
    heartbeat_counter

Holding Registers:
    led_control
    motor_target_speed
    motor_direction
    lock_control
    lcd_text_buffer

这里最容易出错的是：

AI 只写了 Modbus 收发，却没有设计寄存器语义。

这会导致 Gateway、STM32、Dashboard 三边理解不一致。

所以 Modbus over RS485 Skill 必须包含：

寄存器地址表
数据类型
缩放比例
读写权限
默认值
错误码
超时策略
测试方法

推荐信息模型：

modbus_slave_id
modbus_baudrate
modbus_rx_count
modbus_tx_count
modbus_crc_error_count
modbus_exception_count
modbus_status

Modbus Skill 的重点，不是“实现协议栈”，而是“定义稳定的工业数据接口”。

3. Debug / Log / Trace Skill

第三个是 Debug / Log / Trace Skill。

很多嵌入式系统不是死在功能上，而是死在“出了问题不知道为什么”。

所以 Debug / Log / Trace 不是可有可无的辅助功能，而是工程交付的一部分。

这个 Skill 要告诉 AI：

哪些事件必须记录；
哪些日志不能太频繁；
哪些错误需要带上下文；
哪些状态需要 trace；
现场如何抓日志；
CI 如何验证日志关键字。

在 Project Velocity 里，至少应该记录：

系统启动
Zephyr boot
线程启动
CAN 初始化
I2C 初始化
Modbus 初始化
传感器读取失败
电机状态变化
红外发送 / 接收
RFID 读卡
Heartbeat timeout
Watchdog reset
RPC command
安全状态切换

日志不能只是：

error
failed
ok

而应该包含：

模块名
错误码
当前状态
关键参数
时间戳
恢复动作

例如：

[CAN] heartbeat timeout, enter safe mode
[MOTOR] direction change requested, ramping to zero
[RFID] i2c read failed, status=bus_error
[MODBUS] crc error, frame ignored

推荐信息模型：

debug_level
log_backend
trace_enabled
last_error_code
last_error_module
last_error_timestamp

Debug Skill 的价值是：

让 AI Agent 不只是写代码，也知道如何留下证据。

4. Heartbeat / Watchdog Skill

第四个是 Heartbeat / Watchdog Skill。

这是系统可靠性的底线。

Heartbeat 解决的是：

对方还活着吗？
通信链路还正常吗？
状态是不是过期了？

Watchdog 解决的是：

系统卡死怎么办？
线程不再运行怎么办？
控制逻辑失效怎么办？

在 Project Velocity 里，Heartbeat / Watchdog Skill 至少要定义：

heartbeat source
heartbeat period
heartbeat timeout
last heartbeat timestamp
safe mode condition
recovery condition
watchdog feeding point
watchdog reset reason

如果 Gateway 定期发送 heartbeat，STM32 收到后要更新 liveness 状态。

如果 heartbeat 超时，STM32 应该进入安全状态：

停止电机；
锁定危险输出；
保留必要状态；
记录 fault；
上报 status；
等待恢复。

如果 heartbeat 恢复，系统不能盲目立刻恢复所有输出。

应该有明确恢复策略：

确认连续收到若干次有效 heartbeat；
清除通信 fault；
保持执行器在安全状态；
等待新的明确控制命令。

推荐信息模型：

heartbeat_alive
heartbeat_last_rx_ms
heartbeat_timeout_ms
watchdog_enabled
watchdog_last_feed_ms
safe_mode_active
safe_mode_reason

这个 Skill 的核心是：

AI 不能只实现“喂狗”，还必须理解“什么时候不能喂狗”。

5. Firmware Build / Flash Skill

第五个是 Firmware Build / Flash Skill。

它看起来不是通信协议，但它是工程闭环的一部分。

因为如果一个项目不能稳定构建、烧录和复现，就不能算真正可交付。

这个 Skill 要告诉 AI：

如何设置 Zephyr 环境；
如何调用 west build；
构建产物在哪里；
如何使用 OpenOCD / CMSIS-DAP 烧录；
如何处理缺少 west、openocd、toolchain 的错误；
如何保证新开发者可以复现同样的二进制输出。

推荐目录和脚本：

sensor_nodes/build_firmware.sh
sensor_nodes/flash.sh
sensor_nodes/flash_pyocd.sh

推荐构建产物：

zephyr.elf
zephyr.hex
zephyr.bin

这个 Skill 的关键不是“告诉 AI 执行一个命令”，而是让 AI 知道：

构建流程必须可重复；
烧录流程必须可验证；
错误信息必须可行动；
输出路径必须确定。

否则，每个开发者都能 build，但每个人 build 出来的东西都不一样。

这不是工程，这是碰运气。

6. UART / RTT Verification Skill

第六个是 UART / RTT Verification Skill。

这是现场调试和自动验证的关键 Skill。

在 STM32 Zephyr 项目里，板子烧录之后，第一件事不是看 Dashboard，而是确认：

系统是否启动；
Zephyr 是否 boot；
关键线程是否运行；
CAN 线程是否启动；
是否出现 fault；
日志输出是否符合预期。

这个 Skill 可以定义验证脚本：

verify_uart.py
verify_rtt.py
verify_firmware_logs.sh

验证内容包括：

串口是否存在；
波特率是否正确；
是否看到 boot marker；
是否看到 system init marker；
是否看到 CAN thread marker；
超时后如何报错；
缺少 marker 时如何列出缺失项。

例如，验证脚本不应该只是打开串口。

它应该返回明确结果：

PASS: all required markers found
FAIL: missing CAN thread startup marker
FAIL: no serial device detected
FAIL: timeout after 30 seconds

这样 AI Agent 不仅能写固件，还能写“验证固件是否真的跑起来”的工具。

这一步非常重要。

因为没有验证脚本的 AI Coding，很容易停留在“代码看起来对”。

而有了验证脚本，才能变成：

代码构建通过；
烧录通过；
启动日志通过；
通信线程通过；
异常路径可见。

这才是 AI-Assisted Engineering。

五、系统通信 Skill 的共同结构

和传感器 Skill 一样，每个系统通信 Skill 也应该有统一结构：

1. Skill purpose
2. Hardware / interface connectivity
3. Protocol model
4. Frame / register / message definition
5. Firmware information model
6. Gateway mapping
7. Error handling rules
8. Timeout and recovery rules
9. Debug / log / trace rules
10. Unit test checklist
11. Manual validation checklist
12. AI agent prompt template

其中最重要的是 4 个模型：

1. 硬件接口模型

例如：

CAN: PB8 / PB9, 500 kbps
RS485: UART TX/RX + DE/RE direction control
UART debug: USB serial or RTT
SWD: flash/debug connection

2. 协议数据模型

例如：

CAN ID
CANopen object dictionary
TPDO / RPDO
Modbus register map
UART log marker
Heartbeat frame

3. 系统状态模型

例如：

can_status
modbus_status
heartbeat_alive
safe_mode_active
last_error_code
watchdog_reset_reason

4. 验证模型

例如：

CAN frame test
Modbus register read/write test
UART boot marker test
RTT log test
heartbeat timeout test
watchdog reset test

没有验证模型的 Skill，不是完整 Skill。

六、通信 Skill 的核心原则

我把系统通信 Skill 的设计原则总结成 6 句话：

协议先于代码；
状态先于变量；
超时先于异常；
日志先于猜测；
验证先于演示；
安全先于功能。

这 6 句话，是我设计 Project Velocity 通信 Skill 的核心。

1. 协议先于代码

不要一上来就让 AI 写 CAN 或 Modbus 代码。

先定义：

帧格式
寄存器表
命令语义
状态语义
错误语义

再写代码。

2. 状态先于变量

不要让 AI 在函数里临时定义一堆变量。

先定义系统状态：

alive
fault
safe_mode
last_rx
last_tx
error_count

这些状态要能被日志、网关、Dashboard 和测试脚本看到。

3. 超时先于异常

通信系统最常见的问题，不是收到错误数据，而是什么都收不到。

所以一定要定义：

多久没收到算超时？
超时后做什么？
恢复条件是什么？

4. 日志先于猜测

现场调试时，最怕一句：

“我不知道它为什么不工作。”

所以 Skill 必须要求 AI 留下日志。

不是随便 printk，而是有结构的 log。

5. 验证先于演示

能在演示现场跑一次，不代表系统可靠。

必须有：

build verify
flash verify
UART / RTT verify
CAN verify
Modbus verify
timeout verify

6. 安全先于功能

如果通信断了，电机不能继续跑。
如果 Gateway 掉线，执行器不能保持危险状态。
如果 Modbus 写入非法值，不能直接执行。
如果 CAN 帧格式不对，必须忽略并记录。

这就是系统通信 Skill 的底线。

七、从传感器 Skill 到系统通信 Skill

前一篇我们讲的是：

传感器和执行器 Skill

它们解决的是：

设备如何被 STM32 感知和控制？

这一篇我们讲的是：

系统通信 Skill

它们解决的是：

STM32 如何成为一个可靠的系统节点？

两者结合起来，Project Velocity 的 STM32 Zephyr Node 才真正完整。

传感器 Skill
    负责采集

执行器 Skill
    负责动作

通信 Skill
    负责同步

Debug Skill
    负责定位

Watchdog Skill
    负责安全

Build / Flash / Verify Skill
    负责交付

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

不是让 AI 写更多代码，
而是让 AI 在工程结构里写正确的代码。

八、结语

Project Velocity 的系统通信 Skill，不是为了把 CAN、Modbus、UART、Watchdog 写成几个孤立模块。

它真正要解决的是：

如何让 STM32 节点在真实 AIoT 系统中稳定运行。

一个节点要进入工业现场，必须回答：

我是谁？
我如何上报？
我如何接收命令？
我如何知道网关还活着？
我如何知道自己出错了？
我如何进入安全状态？
工程师如何调试我？
AI Agent 如何修改我而不破坏系统？

这些问题，靠一句 Prompt 解决不了。

必须靠 Skill。

从 Prompt 到 Skill，
从传感器到通信协议，
从单点功能到系统工程，
这就是 Project Velocity 想验证的 AI-Assisted Engineering 路线。

如果你需要本文提到的系统通信 Skill .md 模板，可以私信我。

下一篇，我会继续结合 Project Velocity，讨论如何把这些 Skill 交给 AI Coding Agent 使用，让它真正参与 STM32 Zephyr Node 的代码实现、测试和验证。