智能手表项目开发日志 001：先把四个人的工作拆成一条系统链路

先确定我们要交付的是什么

智能手表项目最容易掉进的坑，是把功能列表当成系统方案。温度、计步、NFC、语音、云平台和手机应用每一项都能单独做成 Demo，但如果这些模块没有统一的数据模型和交互入口，最后得到的只是几块互不相干的代码。

所以项目启动时，我先把目标定义成一条完整链路：设备采集数据，设备本地完成判断和显示，数据上报到云端，手机端查看并下发控制，设备再把控制结果反馈回来。这个定义直接决定了后续分工不能只按“一个人做一个传感器”来拆。

四个人，按链路而不是按文件分工

我作为项目负责人，负责总体代码设计、任务协同和关键功能整合。团队工作大致拆成四个方向：硬件和底层驱动、设备端核心业务、云端通信与数据模型、鸿蒙应用原型和交互展示。

这样的分工有一个前提：每个方向必须提前约定输入和输出。比如传感器开发不能只说“能读到温度”，而要明确温度由谁读取、以什么结构传递、谁负责阈值判断、谁负责显示、谁负责上云。否则到了联调阶段，所有人都会认为问题在别人那里。

第一版架构先求能跑通

设备端选择 RK2206 开发板和 OpenHarmony 轻量系统。硬件侧已经提供 LCD、温湿度传感器、加速度计、NFC、语音模块、蜂鸣器、RGB 灯和功能按键，软件侧则采用多个 LiteOS 任务协同运行。

我把设备端划分成三层：驱动层负责 I2C、SPI、UART、GPIO 和 PWM；业务层负责计步、运动状态、门禁状态和报警判断；通信层负责 MQTT 连接、JSON 编解码和云端命令分发。业务层不直接操作网络，网络层也不直接修改 LCD，这个边界让后面的功能叠加变得可控。

最先统一的是状态，而不是页面

项目早期最重要的接口是设备状态结构。当前实现使用 e_iot_data 统一封装时间、温度、步数、运动状态、门禁状态和三类开关状态。

状态模型确定之后，LCD 可以读取它来刷新界面，MQTT 可以读取它来生成属性上报，手机端也可以围绕同一组字段设计页面。云端下发的命令则不直接改变量，而是转换为内部事件，交给业务线程处理。

这套设计没有一开始就引入复杂框架，但解决了最核心的问题：每个模块都知道自己负责什么，也知道怎样和其他模块交接。

阶段结果

启动阶段完成了功能边界、团队分工、设备端任务划分和通信链路设计。下一阶段的重点不再是继续写方案，而是让 RK2206 的传感器、屏幕和执行器先同时稳定工作起来。只有底层设备能够持续输出可靠数据，后面的计步、报警和云端联调才有意义。