几年前，我在整理电脑桌面时发现：无论是口头交流后留下的便签、备忘录中的提醒，还是聊天软件与邮件里的待办任务——这些大事小事都零散地藏在电子世界的角落里，不经常整理的话，等需要时往往难以找到。

加上人脑能记住的东西并不多，所以每次切换到别的设备，就意味着换到了下一个场景，一不留神就可能忘记了重要的事情。我当时就在想：「如果有一款真正理解我工作节奏的 GTD 软件，能在手机、平板、电脑间顺畅衔接，还能自动排定优先级，该多好。」

一次算不上成功的尝试

那时，我下定决心利用手边的电脑，打开文档自学开发。起初选择了当时颇为流行的 Swift 语言，并结合 CoreData 与 CloudKit 构建原型。然而，随着实践的深入，我发现即便是编写一个 GTD 软件的 demo，也比想象中要困难得多。

首先是任务结构的复杂性。情境、优先级、开始与截止时间、提醒时点、重复规则、延期与搁置等设定，乃至时区差异——这些因素彼此交织、相互影响，稍有不慎就可能产生冲突，使任务定义变得异常困难，这就让在开发阶段里各种焦头烂额。

其次就是后台限制，在当时只能有前台切换和很短的后台窗口才能允许。所以要真正理解我的工作节奏，就必须依赖本地 AI 助手的支持。可惜当时的本地 AI 助手更多只是噱头，除了最基本的自然语言解析外，无法实现诸如根据优先级自动排序、综合考虑到期与开始时间、预计用时、能量状态、场景（地点或日历窗口）等复杂因素的功能。

最后就是多端的一致性，在还没有 SwiftUI 的年代，想要完整调用不同的平台的风格，就要编写和其他平台完全不一样的代码。在当时我设想的是，在电脑上收集、平板上规划、手机上点击完成的这样的连续互通体验，也就意味着需要同时开发 3 个平台。对于我这样的用生活间隙开发的开发者而言，极大加重了我负担。

最后，在开发热情过去以后，我也放下了自己开发一个 GTD 软件的执念。

进入一个全新的开发世界

在鸿蒙开始宣传「分布式系统架构」和「多端统一开发」的时候我是完全不信的，毕竟谁不知道「一处开发，到处 Debug」这样的说法呢。但还是抱着看看的心态在搜索框里输入了「鸿蒙开发」，哪知道这真的让我打开了新世界的大门。

Stage 模型中的开发语言 ArkTS 是 TypeScript 的超集，也就是说如果有写过 JavaScript 的话，学习 ArkTS 语法就几乎没有别的学习门槛；但多了静态类型检查和并发模型，从而更适合构建高性能、复杂交互的软件。加上它天然支持声明式 UI，配合状态管理系统，能够让开发者以更直观的方式描述界面与逻辑的关系，避免繁琐的命令式更新流程，直接让界面与数据始终保持同步。

有了这个底以后，我又对开发提起了兴趣，从 Git 仓库里找出了曾经写的代码，准备重新用 ArkTS 开发。当然，安装 DevEco Studio 的过程意外顺利，很轻松地就打开了新世界的开发大门。

从 0 搭起 FlowList 的骨架

为了不重蹈覆辙，我决定从最坚实的地基开始搭建。一个清晰、可扩展的架构，才是软件能不断开发的关键。于是，我将整个应用的核心拆分为三个模块：TaskStore、FocusTimer 和 SyncService。

首先就是 TaskStore，也就是整个软件的数据存储模块。它是整个系统的数据中枢，负责管理和持久化所有任务信息。我采用了关系型数据库方案，通过 SQLite 组件实现本地数据的高效读写。而在多设备之间的同步上，ArkTS 提供的 distributedDataObject 大大简化了开发工作。借助分布式数据对象的自动同步机制，我可以让电脑上新增的任务在手机端即时出现，无需额外编写冲突合并或版本控制逻辑。这样，即便频繁切换设备，任务状态也能始终保持一致。

其次就是一个可靠的计时中心 FocusTimer，为了帮助用户更好地聚焦于任务，我在应用中集成了一个番茄钟系统。通过 BackgroundTaskManager 注册后台计时任务，确保在锁屏状态下计时仍然精准可靠。同时，借助 NotificationExtension，我实现了跨设备的专注提醒——当手机上的计时结束时，电脑端也能同步弹出通知，让专注状态自然地延续到不同设备。

如果说 TaskStore 是「记忆」，那么 SyncService 负责协调多设备之间的数据同步与刷新。除了依赖云端同步，我还利用分布式数据框架（DDF）监听状态变更，以 AppEvents.emit('kvChanged', Date.now()); 事件作为触发点，将任务更新实时广播给其他设备。

在过去，实现这样的多端同步需要我自行搭建服务器、编写网络请求、处理鉴权逻辑。而现在，这些复杂的流程已经被系统级的分布式能力所取代——只需调用 API，就能获得稳定、低延迟的多设备协同体验。

让任务管理变得更主动的「智能化」

在重构过程中，我接触到了 ArkTS 里的 Natural Language Kit。出于好奇，我尝试用它为我的 Demo 增加一个 AI 任务助手。在最初的尝试中，我把这个能力简单地嵌入到任务输入框的后端逻辑中。当用户输入一段自然语言，Natural Language Kit 就会自动完成意图识别与实体抽取。

后续我在翻阅文档的时候还看到了 Intents Kit，这也是最让我惊讶的能力之一。与 Natural Language Kit 不同，InsightIntent 不是简单语义理解工具，而是承担了「系统级联动」的角色——它让应用的智能行为得以延伸至系统层面。我可以向系统共享特定意图数据，并定义相应的开放 API（跳转入口）。系统的意图框架会基于用户的行为模式学习这些数据的规律，并在「合适的时间、合适的场景」中触发推荐。

我目前正尝试在 GTD Demo 中借助这一机制，加强用户体验。这样，用户在 Natural Language Kit 的协助下频繁创建某类任务（例如「每日回顾」或「晨间计划」）时，我可以通过 InsightIntent 向系统共享这些规律性任务的数据。这样，系统可能会在每天早上 8 点左右，在负一屏、控制中心或智慧卡片中主动推荐「开始每日回顾」，用户点击后即可直接进入我的应用里。

更有趣的是，我发现 InsightIntent 并不局限于时间触发。系统还能学习用户的场景行为，比如当识别用户每次靠近公司时都会打开「工作」清单，从而会在在用户抵达该地点时主动推荐相关任务。这种智能化的机制让任务管理迈向更近的一步。

未来，我还计划在本地集成昇思推理框架服务或 Neural Network 运行时服务，通过端侧小模型实现更高层次的智能化任务规划。这一模型将结合用户的健康数据（如睡眠、运动、心率等）与固定日程信息，动态分析「可用精力」与「可用时间」之间的关系，从而为任务分配提供更符合用户当下状态的建议。

例如，在检测到用户睡眠不足或心率偏高的情况下，我们可以自动调整当天的任务优先级，推迟高强度或需要高度集中注意力的任务；而在用户状态良好、时间窗口充裕时，则优先安排需要深度思考的项目。这样一来，也许任务规划将不再只是基于时间管理的机械分配，而是能逐步进化为「以人本身为中心」的感知式计划系统。

一次开发，多端部署

写完了软件基础的逻辑，下面我重要准备开始动手写相关的 UI 部分了。我在项目初期就依然秉持了要支持手机、平板与电脑的远大目标。虽然理论上，鸿蒙可以「一次开发，多端部署」，但我还是做好了心理准备，觉得这无非是将曾经为三个平台写三套代码的痛苦，转化成无数个 if-else 这样的这么。

结果，实际工作量远比预期更小。ArkUI 将分辨率、自适应布局、交互模式、权限机制等设备与平台差异，统一抽象为底层接口，使我无需在业务逻辑中手动编写判断逻辑。借助框架提供的响应式布局、组件属性与能力检测 API，界面能够自动完成适配。于是，我的开发思路从「为电脑写一个界面、再为平板写一个」转变为「设计一个可随空间大小自由伸缩的界面」，这也恰好和目前的网页设计思路对应起来，整个设计流程还是很丝滑的。

我首先利用鸿蒙提供的 BreakpointSystem 定义了几个关键的屏幕宽度断点，比如 sc（小屏，手机）、mc（中屏，平板）、lc（大屏，电脑）。然后，通过一个全局监听的状态变量来获取当前的断点类型:

@StorageLink('currentBreakpoint') currentBreakpoint: string = 'sc';

const breakpointSystem = new BreakpointSystem();
mediaQuery.matchMediaSync(`(width>=${breakpointSystem.getBreakpoint('mc')})`, (matches) => {
  this.currentBreakpoint = matches ? 'mc' : 'sc';
});

有了这个 currentBreakpoint 状态，界面的适配就变得像搭积木一样直观。在主界面的 build 函数中，我不再写死布局，而是根据状态进行动态组合：

这意味着，我的 TaskListComponent（任务列表组件）和 DetailViewComponent（详情视图组件），无需任何修改，就能同时运行在所有平台上。我需要做的，仅仅是：在小屏幕上，只显示列表；在稍大的屏幕上，用一个 Row 容器将它们并排摆放，并按 4:6 的比例分配宽度。

在电脑端，我甚至可以更进一步，用一个三栏布局来呈现：左侧是项目栏，中间是任务列表，右侧是任务细节、笔记区和番茄计时按钮。而实现这一切，也只是在最外层布局加一个相关判断的判断而已。整个多端适配过程，我只花了一周左右的时间。而且大部分精力都花在思考不同设备上最佳的交互模式，而不是在编写冗余的平台特定代码上。当我在笔记本和 MatePad 之间无缝切换 FlowList，看着界面元素如流水般自动重组时，那种感觉真的很奇妙。

当然在适配多端的同时，我也对 UI 简单地打磨了下，比如通过单独调整贝塞尔曲线实现的回弹效果可以让 UI 具有别样的风格。我还计划未来通过 SpringMotion 模拟了真实的物理惯性，让列表的滑动既跟手又富有生命力，打造特殊的视觉风格。

尾声

这五个月的开发旅程，让我真正理解了鸿蒙的独特意义。它不只是一个操作系统，更像是一层「统一生态的底层运行时」。在这个体系里，开发者不必再依赖第三方云服务，也无需为多端同步额外编写逻辑——系统本身就能让不同设备之间自然地共享状态、同步任务、延续体验。

这种「多端即一体」的设计理念，对于 GTD 这类强调连续性与协同的应用而言，几乎是一次范式转变。当我在电脑上规划任务、在平板上展开执行、再到手机上轻轻打卡完成时，我不再觉得自己是在「不同设备上操作同一个应用」，而更像是始终身处于同一条时间流中，只是偶尔切换了观察的视角。

在鸿蒙的分布式架构下，设备间的边界被柔化，应用的生命周期也不再局限于单一终端。它让开发者重新思考——任务管理软件不必只是被动的记录工具，而可以成为贯穿生活各处的智能伙伴。而对我而言，这段经历也让我重新找回了最初写下那句想法的心情：「如果有一款真正理解我工作节奏的 GTD 软件，那该多好。」

最后的最后，我也希望我能有耐心完整打磨完我目前的这个半成品，并希望能早日上架。