1. 为什么我要给一块旧手表写个番茄钟手里有块华米Amazfit GTR4戴了两年多屏幕没划痕、电池还能撑一周就是系统自带的应用市场里翻来覆去就那么几个表盘和运动记录工具。我平时写代码、写稿子最常用的工作法是番茄工作法手机上装了好几个番茄钟App但每次都要掏手机、解锁、点开App一套动作下来注意力已经散了。手表就在手腕上抬腕就能看为什么不能直接在手表上跑一个番茄钟加待办清单这个念头冒出来之后我先去应用市场搜了一圈发现针对这个型号的第三方番茄钟几乎没有要么是功能极其简陋的计时器要么是必须配合手机端使用的半成品。于是我就想干脆自己写一个。正好那段时间在深度使用AI coding工具就想试试看能不能靠AI辅助把整个开发流程压缩到几天之内完成。这篇文章记录的就是整个从零到一的过程怎么摸清这块手表的开发能力边界、怎么用AI coding工具快速生成可用的代码骨架、怎么处理手表端特有的交互限制、以及最后怎么把App装进手表里跑起来。如果你手里也有一块闲置的智能手表或者你是个想尝试穿戴设备开发的程序员这篇内容应该能帮你省下不少摸索的时间。需要提前说明的是我不是专业的穿戴设备开发者之前主要做Web和移动端对嵌入式系统只有粗浅了解。所以整个过程中踩的坑不少有些地方甚至是绕了远路才找到正确方向。但正因为如此这些经验对同样是非专业背景的开发者来说可能更有参考价值。2. 摸清Amazfit GTR4的开发能力边界2.1 这块表到底能跑什么类型的应用在动手写代码之前我花了整整一个周末研究这块手表的系统架构。Amazfit GTR4运行的是Zepp OS这是华米自家的一套轻量级操作系统底层基于RTOS实时操作系统而不是像Wear OS那样的完整Android系统。这个区别非常关键因为它直接决定了你能用什么语言写应用、能调用哪些系统能力。Zepp OS的应用开发主要使用JavaScript配合一套名为Zepp OS SDK的框架。官方提供了两种应用类型一种是小程序Mini App运行在手表本地可以访问传感器、屏幕、振动马达等硬件另一种是表盘Watch Face专门用于显示时间和自定义表盘界面。我要做的番茄钟加待办清单显然属于小程序范畴。这里有个容易混淆的点Zepp OS的小程序虽然用JavaScript写但它并不是跑在浏览器环境里而是跑在一个精简的JavaScript引擎上。这意味着你不能用DOM操作、不能用大部分Node.js的API、也不能直接引入npm上的任意包。所有能用的API都被限制在SDK提供的范围内比如zos/ui用于界面渲染、zos/sensor用于传感器访问、zos/storage用于本地数据存储。我一开始没意识到这个限制试图引入一个常用的日期处理库结果发现根本跑不起来。后来查文档才知道Zepp OS的JavaScript引擎只支持ES6的一个子集很多现代JavaScript特性都用不了。这个教训让我明白在嵌入式环境里写代码首先要做的是确认能力边界而不是急着写业务逻辑。2.2 开发环境搭建中最容易卡住的三个地方搭建开发环境的过程比我预想的要曲折。官方推荐使用Zepp OS开发者工具这是一个基于VS Code的插件安装之后可以创建项目模板、模拟器调试、打包上传。听起来很顺畅但实际操作中有三个地方特别容易卡住。第一个是Node.js版本兼容问题。Zepp OS的构建工具链对Node.js版本有要求我本地装的是比较新的版本结果构建时报了一堆模块找不到的错误。后来降级到官方文档推荐的LTS版本才解决。这个坑很隐蔽因为错误信息不会直接告诉你Node版本不对而是报一些看起来像依赖缺失的错。第二个是模拟器的连接问题。Zepp OS开发者工具自带一个手表模拟器可以在电脑上预览应用效果。但模拟器启动后有时候IDE识别不到设备需要手动在设置里指定模拟器的端口。我第一次遇到这个问题时反复重启IDE和模拟器都没用最后在官方论坛的一个角落里找到答案需要在开发者工具的设置里把设备连接方式从自动改成手动然后填入模拟器监听的端口号。第三个是真机调试的授权流程。要把应用装到真实的手表上需要先在手表端开启开发者模式然后在手机端的Zepp App里绑定开发者账号最后通过WiFi或蓝牙把电脑和手表连起来。这个流程涉及手表、手机、电脑三个设备任何一步出错都会导致连接失败。我建议在开始写代码之前就把这个流程跑通否则等你写完代码发现装不进去会很打击积极性。2.3 屏幕尺寸和交互方式带来的设计约束Amazfit GTR4的屏幕是1.43英寸的AMOLED圆屏分辨率466×466像素。这个尺寸放在手表上算大的但和手机屏幕比起来还是小得可怜。更关键的是手表的交互方式和手机完全不同没有键盘、没有多点触控手势、主要靠点击和滑动。这意味着我在设计番茄钟界面时必须遵循几个原则。第一信息层级要极简。一个屏幕上最多显示两到三个核心信息比如剩余时间、当前任务名称、开始/暂停按钮。第二按钮要大。手指在圆屏上点击的精度很低按钮的点击区域至少要占屏幕宽度的三分之一以上。第三避免滚动列表。手表上滚动列表的体验很差待办清单最好用分页或者卡片切换的方式呈现而不是长列表。我在设计待办清单界面时最初想做一个可以上下滚动的列表每个任务一行。结果在模拟器上测试时发现滚动操作经常误触而且圆屏的边缘区域显示内容会被裁切。后来改成了一次只显示一个任务卡片左右滑动切换体验好了很多。这个改动虽然增加了代码复杂度但对手表端的使用体验来说是必要的。3. 用AI coding工具生成代码骨架的实操过程3.1 我是怎么向AI描述需求的用AI coding工具写代码最关键的一步不是写代码本身而是怎么把需求描述清楚。我试过几种不同的描述方式发现效果差异很大。最开始我写的是很笼统的提示比如帮我写一个Zepp OS的番茄钟应用。AI给出的代码结构很完整但细节全是错的用了不存在的API、界面布局完全不符合手表屏幕尺寸、没有考虑Zepp OS的模块导入方式。这是因为AI的训练数据里Zepp OS相关的代码本来就少它只能根据通用的JavaScript知识来推测。后来我调整了策略把需求拆成多个小步骤每一步都给出明确的约束条件。比如第一步只让AI生成一个显示倒计时的界面并且明确告诉它使用zos/ui的TEXT组件、屏幕分辨率是466×466、文字要居中显示、字号用px单位而不是rem。这样AI生成的代码就靠谱多了。我总结出一个有效的提示结构平台约束 功能描述 具体API 输出格式。举个例子我实际使用的一个提示是这样的平台Zepp OS 小程序使用 zos/ui 和 zos/sensor 功能创建一个番茄钟计时器页面包含以下元素 1. 一个显示剩余时间的文本格式为 MM:SS 2. 一个开始/暂停按钮 3. 一个重置按钮 约束 - 屏幕分辨率 466x466 - 所有按钮点击区域高度不小于 80px - 使用 zos/storage 保存计时状态 - 不要使用任何浏览器 API 输出完整的 page.js 和 page.ui 文件用这种结构化的提示AI生成的代码一次通过率明显提高。当然还是需要人工检查和调整但至少骨架是对的省去了大量查文档的时间。3.2 AI生成的代码哪些能直接用哪些必须重写在实际操作中我发现AI生成的代码大概可以分为三类。第一类是可以直接用的主要是界面布局和基础逻辑。比如番茄钟的倒计时逻辑、按钮的点击事件绑定、简单的数据存储读写这些代码AI写得基本没问题我只需要微调一下参数就行。这部分大概占整个项目代码量的百分之四十左右。第二类是需要大幅修改的主要是涉及Zepp OS特有API的部分。AI经常会把不同版本的API混在一起用或者用一些看起来合理但实际上不存在的方法。比如它曾经生成过hmUI.showToast()这样的调用但Zepp OS里根本没有这个API正确的做法是使用zos/ui里的showToast方法。这类问题需要我对照官方文档逐个修正。第三类是完全不能用的主要是涉及系统底层交互的部分。比如AI试图用setInterval来实现计时但Zepp OS的JavaScript引擎对定时器的支持有限长时间运行会出问题。正确的做法是使用系统提供的setTimeout配合时间戳计算或者使用传感器的事件回调来驱动更新。这类问题不是AI的错而是训练数据里缺少这方面的经验只能靠人工重写。我的建议是把AI当成一个写代码很快但不太了解具体平台的初级开发者。它能帮你快速产出大量代码但你必须对平台有足够的了解才能判断哪些代码能用、哪些要改、哪些要重写。3.3 用AI辅助调试的几种有效姿势代码写完之后调试是另一个大头。AI coding工具在调试阶段也能帮上忙但用法和写代码不太一样。最有效的一种用法是把错误信息直接丢给AI。Zepp OS的报错信息有时候很模糊比如undefined is not a function不告诉你具体是哪一行、哪个函数。这时候我会把完整的错误堆栈、相关的代码片段、以及我期望的行为一起发给AI让它帮我分析可能的原因。AI通常会给出几个可能的方向我再逐个排查。另一种用法是让AI帮我写测试用例。Zepp OS的模拟器可以运行应用但手动测试很费时间。我让AI根据我的业务逻辑生成了一些测试场景比如计时到零时应该触发振动、暂停后重新开始应该从暂停的时间点继续、切换任务时应该保存当前进度。然后我在模拟器里逐个验证这些场景发现问题再针对性修复。还有一种用法是让AI解释它自己生成的代码。有时候AI生成的代码能跑但我不太理解它的逻辑担心后面改出问题。这时候我会让AI逐行解释代码的作用特别是那些涉及状态管理和异步操作的部分。这个习惯帮我避免了好几次潜在的bug。4. 番茄钟核心逻辑的实现细节4.1 计时器为什么不能用setInterval这是我在整个项目里踩的最大的一个坑。最开始我用setInterval来实现倒计时每秒更新一次界面上的时间显示。在模拟器上跑的时候一切正常但装到真机上之后发现计时越来越慢十分钟的番茄钟实际跑了将近十二分钟。原因在于Zepp OS的JavaScript引擎对定时器的精度支持很差。setInterval在桌面浏览器里可以做到毫秒级精度但在资源受限的嵌入式环境里定时器的触发会被系统调度、传感器事件、屏幕刷新等因素干扰导致实际间隔比设定的要长。而且应用进入后台之后定时器可能被完全挂起等你再打开时时间已经错乱了。正确的做法是用时间戳来计算剩余时间而不是依赖定时器的累加。具体来说在开始计时的时候记录一个startTime然后每次界面刷新时用当前时间 - startTime来算出已经过去的时间再用总时长减去它得到剩余时间。这样即使定时器有延迟显示的时间也是准确的。但这里还有一个问题如果应用进入后台JavaScript引擎可能完全停止运行等你回到前台时当前时间已经跳了一大截。所以还需要在应用恢复前台时重新计算一次剩余时间并且判断是否已经超时。我在代码里加了一个onShow回调每次页面显示时都重新同步一次时间状态。// 核心计时逻辑示意 let startTime 0; let totalDuration 25 * 60 * 1000; // 25分钟 let remainingTime totalDuration; let isRunning false; function startTimer() { startTime Date.now(); isRunning true; } function getRemainingTime() { if (!isRunning) return remainingTime; const elapsed Date.now() - startTime; const remaining totalDuration - elapsed; return remaining 0 ? remaining : 0; } function pauseTimer() { remainingTime getRemainingTime(); isRunning false; }这段代码看起来简单但背后的逻辑是经过好几次失败才定下来的。关键点在于永远不要相信定时器的累加结果一切以时间戳为准。4.2 待办清单的数据结构设计待办清单看起来简单但要在手表上跑得流畅数据结构的设计很讲究。我最初的设计是一个对象数组每个对象包含任务名称、完成状态、创建时间等字段。这个设计在任务数量少的时候没问题但当任务超过二十个之后每次读写都要遍历整个数组在手表上会有明显的卡顿。后来我改成了两个独立的存储键一个存储任务列表的索引另一个存储每个任务的详细内容。索引是一个简单的字符串数组只包含任务ID详细内容按ID分别存储。这样读取任务列表时只需要读索引查看具体任务时再按需读取详情减少了单次读写的数据量。存储方案用的是zos/storage提供的键值对接口。这个接口的读写速度在手表上还算可以但有一个限制单个键值的大小不能超过一定字节数。我测试下来大概在4KB左右就会出问题。所以任务名称不能太长我限制在二十个字符以内超出部分截断显示。还有一个细节是数据的持久化时机。手表应用随时可能被系统回收所以每次数据变更都要立即写入存储不能等到页面关闭时再统一保存。我在每个修改操作后面都加了存储写入虽然增加了IO次数但保证了数据不会丢失。4.3 振动提醒的触发条件和参数调整番茄钟的核心功能之一是时间到了要提醒。手表上最直接的提醒方式就是振动。Zepp OS提供了振动马达的控制接口可以设置振动模式和时长。我最初设置的振动模式是长振一次时长500毫秒。但在实际使用中发现这个提醒太弱了有时候专注工作的时候根本感觉不到。后来改成短振三次每次200毫秒间隔300毫秒感觉明显多了。但新的问题又来了如果连续完成多个番茄钟频繁振动会很烦人。最终的方案是根据场景区分振动模式。番茄钟结束时用短振三次提醒你该休息了休息结束时用长振一次提醒你该继续工作了如果用户手动暂停或重置不振动。这样区分之后使用体验好了很多。振动强度的参数在Zepp OS里是可以调整的但文档里没有明确说明取值范围。我通过反复测试发现强度值在0到100之间超过100会被截断。默认强度大概是50左右我调到了80感觉比较合适。这个参数因人而异建议在自己的手表上多试几次。5. 手表端特有的交互难题与解决方案5.1 圆屏边缘的内容裁切问题Amazfit GTR4是圆屏这意味着屏幕的四个角实际上是弧形的靠近边缘的内容会被裁切。这个问题在方形屏幕上不存在但在圆屏上必须专门处理。我最初设计界面时按照方形屏幕的思维把内容铺满整个466×466的区域。结果在真机上测试时发现屏幕四角的文字和按钮都被切掉了一部分。特别是待办清单里的任务名称如果比较长两端的字就会消失。解决方案是定义一个安全区域。经过测量圆屏的有效显示区域大概是一个直径420像素的圆。所有重要内容都必须放在这个圆内边缘留出至少23像素的边距。对于确实需要靠近边缘的元素比如背景装饰可以超出安全区域但文字和可点击元素绝对不能。在代码里我定义了几个常量来管理布局const SCREEN_WIDTH 466; const SCREEN_HEIGHT 466; const SAFE_MARGIN 40; const CONTENT_WIDTH SCREEN_WIDTH - SAFE_MARGIN * 2; const CONTENT_HEIGHT SCREEN_HEIGHT - SAFE_MARGIN * 2;所有界面元素的坐标都基于这些常量来计算而不是硬编码具体的像素值。这样即使以后适配其他尺寸的圆屏手表也只需要改这几个常量就行。5.2 点击热区与误触的平衡手表屏幕小手指点击的精度低这是所有手表应用开发者都要面对的问题。我在设计按钮时最初按照视觉大小来设置点击区域结果发现很多用户包括我自己经常点不中。后来我学到一个原则视觉大小可以小但点击热区必须大。比如一个视觉上看起来只有60像素高的按钮实际的可点击区域可以扩展到100像素甚至更大。在Zepp OS里可以通过给按钮组件设置透明的padding来实现这一点。但热区也不能无限扩大否则相邻的按钮会互相干扰。我的经验是两个相邻按钮的热区之间至少留出20像素的间隔否则用户想点A却点到了B体验会很差。还有一个细节是避免在屏幕边缘放置可点击元素。圆屏的边缘区域不仅显示会被裁切触摸检测也不够灵敏。我最初把返回按钮放在了屏幕左上角结果经常点不中。后来移到了屏幕底部中央点击成功率明显提高。5.3 页面切换时的状态保持番茄钟应用通常有两个页面计时页面和待办清单页面。用户可能正在计时的时候切换到清单页面查看任务然后再切回来。这时候计时状态必须保持不能因为页面切换就重置了。Zepp OS的页面切换机制和Web开发不太一样。每个页面是一个独立的JavaScript模块页面切换时上一个页面的状态默认会被销毁。要实现状态保持需要把共享状态存储在页面模块之外比如放在一个单独的store.js文件里或者使用全局的getApp()对象来管理。我采用的是一个简单的全局状态管理方案创建一个state.js模块导出一个包含所有共享状态的对象。每个页面在加载时从这个模块读取状态在状态变更时写回这个模块。这样即使页面被销毁重建状态也不会丢失。但这里有一个坑全局状态在应用被系统回收后也会丢失。所以关键状态还是需要持久化到存储里。我的做法是双写内存里保留一份用于快速读取存储里保留一份用于持久化。应用启动时先从存储里恢复状态然后再开始正常运行。6. 从模拟器到真机的部署踩坑记录6.1 模拟器上跑通不代表真机能跑这是所有嵌入式开发都会遇到的问题但在Zepp OS上尤其明显。模拟器毕竟是在电脑上运行的性能比手表强得多而且模拟器不会模拟所有的硬件行为。我在模拟器上测试的时候一切都很流畅界面切换顺滑、计时准确、振动正常模拟器用声音代替振动。但装到真机上之后问题一个接一个冒出来。第一个问题是界面渲染延迟。在模拟器上页面切换几乎是瞬间完成的但在真机上从点击按钮到新页面完全显示出来大概有半秒到一秒的延迟。这个延迟在模拟器上完全感觉不到但在真机上很明显。后来我加了一个加载动画在页面切换时显示一个转圈的效果让用户知道系统正在响应。第二个问题是内存限制。模拟器对内存几乎没有限制但手表上的可用内存很有限。我最初在页面里加载了比较大的图片资源在模拟器上没问题在真机上直接导致应用崩溃。后来把所有图片都压缩到了很小的尺寸并且尽量用代码绘制简单的图形来代替图片。第三个问题是传感器数据的差异。模拟器里的传感器数据是模拟的和真实传感器有差异。比如抬腕检测模拟器里可以通过按钮触发但真机上需要真实的加速度传感器数据。我在这块调试了很久最后发现是传感器的采样频率设置得太高导致功耗过大系统自动降频了。6.2 应用签名和安装的完整流程把应用装到真机上需要经过签名和安装两个步骤。这个过程官方文档写得比较简略我实际操作时遇到了不少问题。签名需要使用开发者证书。在Zepp OS开发者工具里可以生成一个自签名证书用于开发和测试。生成证书时需要填写一些信息比如组织名称、证书有效期等。这些信息可以随便填但有效期建议设置长一点否则过期后需要重新签名。签名完成后会生成一个.zab格式的安装包。这个包需要通过手机端的Zepp App安装到手表上。具体流程是先把.zab文件传到手机上然后在Zepp App的开发者模式里选择安装本地应用选中这个文件等待安装完成。这里有几个容易出问题的地方。第一手机和手表必须保持连接安装过程中如果蓝牙断开安装会失败。第二手表的存储空间要足够如果手表里已经装了很多应用可能会因为空间不足而安装失败。第三安装后应用不会自动出现在应用列表里需要在手表的应用管理里手动启用。我第一次安装时因为手表存储空间不足反复失败了好几次。后来删掉了几个不常用的表盘和应用才安装成功。建议在安装前先检查一下手表的可用空间。6.3 真机调试时的日志查看方法真机调试时查看日志是一个挑战。模拟器里的日志可以直接在IDE的控制台看到但真机上的日志需要通过其他方式获取。Zepp OS提供了一种方式在手表端开启日志输出然后通过手机端的Zepp App查看。具体操作是在手表的开发者选项里打开日志记录然后在Zepp App的开发者模式里选择查看日志。日志会以文本形式显示在手机屏幕上。但这个方式有几个限制。第一日志的刷新不是实时的需要手动下拉刷新。第二日志的容量有限如果输出太多旧的日志会被覆盖。第三日志的格式比较原始没有颜色区分和级别过滤。我的做法是在关键位置输出带标记的日志比如用[TIMER]、[STORAGE]、[UI]这样的前缀来区分不同模块的日志。这样在手机上看日志时可以快速定位到相关部分。另外我会把重要的状态变化都输出到日志里比如计时开始、计时暂停、任务切换等方便排查问题。7. 实际使用中的体验优化与功能迭代7.1 番茄钟时长自定义的实现最初我做的番茄钟是固定25分钟这是番茄工作法的标准时长。但实际使用中我发现不同任务需要的专注时长不一样。写代码可能需要45分钟才能进入心流状态而回复邮件可能15分钟就够了。所以后来我加了自定义时长的功能。在手表上输入数字是个麻烦事没有键盘只能用加减按钮来调整。我的设计是在设置页面里用两个大按钮来增加和减少时长每次调整5分钟范围从5分钟到60分钟。当前选中的时长用大号字体显示在屏幕中央调整时会有振动反馈。这个功能的实现本身不复杂但有一个细节需要注意调整时长时如果正在计时应该怎么处理。我的方案是如果计时正在进行调整时长会先暂停计时然后重置到新的时长需要用户手动重新开始。这样虽然多了一步操作但避免了计时状态混乱的问题。7.2 待办事项与番茄钟的关联单独一个番茄钟其实用处有限真正有价值的是把番茄钟和待办事项关联起来。我的做法是每个待办事项可以关联一个或多个番茄钟完成一个番茄钟后对应事项的进度会增加。在数据结构上每个任务除了名称和完成状态还增加了estimatedPomodoros预计需要的番茄钟数量和completedPomodoros已完成的番茄钟数量两个字段。在计时页面会显示当前任务名称和进度比如写项目文档 2/4。这个关联功能看起来简单但实现时有一个难点怎么判断一个番茄钟属于哪个任务。我的方案是在开始计时前让用户从待办清单里选择一个任务作为当前任务。如果用户没有选择就默认是一个自由番茄钟不关联任何任务。这个选择界面做得很轻量就是一个简单的列表点击即选中。实际使用下来这个功能对提升专注度很有帮助。因为你知道这个番茄钟是在为某个具体任务服务而不是漫无目的地计时心理上会更有动力。7.3 数据统计与回顾功能的取舍我最初想做一个完整的数据统计功能记录每天完成了多少个番茄钟、每个任务花了多少时间、一周的趋势图等等。但在手表上实现这些功能面临几个现实问题。首先是屏幕太小显示不了复杂的图表。其次是存储空间有限长时间的数据积累会占用大量空间。最后是操作不便在手表上查看统计报告体验很差。所以最后我做了取舍只保留最核心的统计功能即今日完成的番茄钟数量和本周的每日完成数量。今日数量用数字直接显示在计时页面底部本周数据用一个简单的柱状图显示每根柱子代表一天高度代表完成数量。这个柱状图用代码绘制不依赖图片资源占用的存储空间也很小。历史数据的清理策略是只保留最近四周的数据更早的数据自动删除。这样既能看到近期的趋势又不会让存储空间无限增长。8. 关于AI coding辅助嵌入式开发的一些个人体会整个项目做下来我对AI coding在嵌入式开发中的定位有了更清晰的认识。它确实能大幅提升开发效率特别是在写业务逻辑和界面布局这些套路化的代码时AI生成的速度比我自己写要快好几倍。但在涉及平台特有API、硬件交互、性能优化这些领域AI的帮助就很有限了甚至有时候会给出误导性的建议。我的经验是把AI当成一个知识面很广但不够深入的助手。它知道很多通用的编程模式和最佳实践但对具体平台的细节了解不够。所以正确的用法是让AI负责它擅长的部分你自己负责它不擅长的部分。具体来说AI适合做代码骨架生成、常见逻辑实现、错误信息分析你适合做平台API验证、性能调优、真机测试。另外AI coding工具在调试阶段的帮助往往被低估。很多人只用它来写代码但实际上它在分析错误、解释代码、生成测试用例方面也很强。特别是当你遇到一个不熟悉的报错时把错误信息丢给AI它往往能给出几个可能的排查方向比你自己盲目搜索要高效得多。还有一个体会是不要指望AI一次生成完美的代码。我的做法是让AI先生成一个能跑的最小版本然后在这个基础上逐步迭代。每次迭代只改一个地方改完立即测试。这样虽然看起来慢但实际上比一次性生成一大堆代码然后慢慢调试要快得多。因为当代码量大了之后定位问题的难度会指数级上升。最后说一个比较实际的建议如果你也想用手表做点自己的小工具不要一上来就追求功能完整。先做一个最简单能跑的版本比如就一个倒计时功能把它装到手表上跑起来感受一下整个流程。然后再逐步添加功能每加一个就测试一个。这样你会在每个阶段都有成就感而不是被一大堆问题压得喘不过气。我在做完这个番茄钟之后又陆续给手表写了几个小工具比如喝水提醒、久坐提醒、简单的记账本。每个工具都不复杂但组合起来这块旧手表就变成了一个真正符合我个人需求的工作助手。这大概就是自己动手写应用的最大乐趣你不需要迁就别人的设计完全可以按照自己的习惯来定制。