本文全部描述后续规划和技术取舍，不代表云服务、账号系统或移动端已经实现。
先问跨设备要解决什么
如果跨设备的目的只是出门时看一眼今天的任务，那么只读展示与完整编辑是两个不同规模的问题。如果手机也可以新增、修改和完成任务，就必须定义多端同时操作时的结果。先明确操作范围，才能讨论技术选择。
现阶段牛马日记仍以 Windows 本地工作台为核心。多设备同步、统一用户系统、Web/PWA、Android、鸿蒙与 iOS 均属于规划方向，没有上线时间承诺。
文件复制并不等于数据同步
把两个设备各自修改过的 SQLite 文件互相覆盖，会丢掉其中一边的修改。一个数据库文件的更新时间，也无法回答里面哪条任务被改过。
更可靠的讨论单位是记录：稳定 ID、修改版本、删除标记，以及必要的操作历史。即便补齐这些字段，冲突仍需要规则。例如一端把任务改为完成，另一端修改了描述，可以考虑字段合并；两端同时修改同一段工作记录，则更适合保留双方内容并提示处理。
这些只是方案讨论，当前数据结构不会因为本文自动发生变化。
离线是正常状态，不是错误状态
本地优先意味着断网时依然能读取和编辑。网络恢复后，需要有一个可观察的同步状态：哪些变更已发送、哪些失败、哪些等待处理。不能仅仅显示一个不断旋转的图标。
重试还需要幂等性。同一个变更发送两次，不能生成两条任务。设备时间也可能不同，因此不能把客户端时间戳当作绝对可靠的胜负判据。
AI 日报与同步是两条独立链路
生成日报并不天然需要云同步全部数据。用户可以选择一段记录、检查即将发送的内容，再请求生成草稿。这样能先明确输入范围，也方便在模型输出错误时回到原始事实。
关于这条链路的边界，另见AI 日报输入设计笔记。本文不会把它写成已经上线的功能。
下一步的判断标准
长期任务和周期任务是否符合实际使用习惯，本地备份能否可靠恢复，错误提示是否说得清楚，这些基础问题仍然值得先处理。只有本地体验稳定之后，跨设备才有一个值得扩展的基础。
规划可以开阔，交付必须具体。每个阶段都应说明实现范围、验收环境与剩余限制，而不是把路线图画成已完成功能清单。