把抽屉里那块 GTR4 翻出来的时候我本来只是想给它换个表盘。结果表盘商店里翻来翻去都是那几个风格倒是我每天最需要的一个小功能——番茄钟——要么没有要么做成手机上那种满屏按钮的简化版根本没法在手腕上用。于是念头就歪了我自己给它写一个。这个“自己写”不是拿现成的 App 塞进去而是在 Zepp OS 上从零做一个手表小程序而且整个过程靠的是 AI coding。整个过程下来最大的收获不是产出了一个能用的番茄代办 App而是验证了一个挺实用的工作流一块两三年前的老表一个懂点编程但完全没接触过手表开发的人靠着 AI coding 一样能把想法变成戴在手腕上的应用。你不需要先啃完官方文档也不需要是个前端高手只需要知道怎么把需求拆清楚、怎么把 AI 的幻觉拉回正轨。这篇文章想把这条完整的路线记录下来从开发环境、数据设计、计时逻辑到 AI 翻车实录和真机安装全部是这次实操里真实发生过的东西。1. 旧表新用为什么我想在 GTR4 上自己写个番茄钟1.1 从抽屉里翻出来的 GTR4到底还能干点什么GTR4 是一款两三年前发布的智能手表1.43 英寸圆形 AMOLED 屏幕独立的 GPS很长的续航还有两个实体按键和一个线性震动马达。放在今天它的智能功能确实不算新了但作为一块表基础素质依然优秀屏幕够亮、震动够干脆、充一次电能顶一周多。它最大的问题不是硬件不行而是应用商店里的东西太少表盘翻来覆去就那么几套官方应用也就那几个。我重新激活它之后发现它跑的系统是 Zepp OS这套系统最大的特点是允许开发者安装第三方小程序而且开发语言以 JavaScript 为主不需要像开发别的表那样搞一套专门的环境。也就是说只要你愿意写代码这块旧表就可以具备任何你想象中的应用场景。当时我在手机应用商店里翻番茄钟翻到的要么是订阅制的要么是功能堆得密密麻麻的要么根本不支持自定义。手表上更惨系统自带的应用里压根没有番茄钟这个概念。与其等官方更新不如自己动手。这大概是所有“旧设备二次生命”故事里最有说服力的一点设备本身没有坏只是没有适合它的应用。而 Zepp OS 给了普通用户一个自己做应用的机会这是它比同价位手表更值得折腾的地方。1.2 为什么番茄钟必须长在手腕上说来也怪手机上番茄钟应用多得很但我一直没有坚持用下来。原因也很简单番茄钟的核心是“开始一段不被打扰的专注时间”可手机本身就是最大的打扰源。开个番茄钟锁屏放一边屏幕一亮你总会忍不住瞄一眼通知一瞄就可能滑走了。手机上的番茄钟在提醒你专注的同时还在给你推送消息这本身就是矛盾的。手表不一样。它的屏幕小信息密度低抬腕只能看到“当前剩余时间”和“当前要做的事”没有社交软件、没有信息流、没有短视频入口。番茄钟开始之后你把手机丢在另一个房间计时、进度、提醒全部由手腕上的震动和表盘完成。到了 25 分钟手表震一下告诉你“该休息了”你抬手看看下一个待办是什么继续干活就行全程不需要碰手机。所以这个需求的本质不是“我要一个计时器”而是“我要一套能让我放下手机的专注仪式”。手表上的番茄钟恰恰把手机从整个流程中踢了出去。这个感受很难用截图传达戴上之后才明白为什么番茄钟一定要长在手腕上。1.3 AI coding 到底帮了什么忙说老实话我写 JavaScript 的经验有一些但完全没碰过 Zepp OS 开发。这套系统的 API、页面结构、生命周期、打包方式对我来说全是新的。如果按照传统路线我得先花两个晚上看文档再照着官方模板改半天才能跑通一个 hello world。但这次我全程用的是 AI coding也就是通过对话让 AI 帮忙生成代码、修 bug、解释报错。我负责的部分是需求拆解、数据设计、边界条件、真机验证。AI 负责的部分是页面布局代码生成、API 调用草稿、样式换算、把日志报错翻译成人话。这个分工不是一开始就定的而是做了几个页面之后自然形成的。AI 在陌生平台上的第一版代码大概能跑通 60% 到 70%剩下那部分不能用绝大多数不是逻辑问题而是它根本不熟悉 Zepp OS 的 API。后面我会详细说怎么喂上下文、怎么改错这是 AI coding 能不能用好的关键。2. 开发环境搭建Zepp OS 应用与 AI 的第一次配合2.1 开启开发者模式准备一个最小的运行环境开发手表 App 之前先得让手表和设备进入开发者模式。不同固件版本的入口略有差异但思路是一样的手表端在“设置”里找到“关于”连续点击版本号若干下会弹出一个开发者模式开启的提示手机端在 Zepp App 里找到开发者入口开启后才能通过手机往手表安装本地应用。这一步卡了我一阵子因为入口藏得比较深后来我直接在 App 里搜“开发者”三个字才找到。环境方面电脑上需要安装 Zepp OS 的 CLI 工具。我用的是 npm 安装方式npm install -g zeppos/zeppos-cli安装完成之后创建一个项目模板zeppos create它会生成一个带 hello world 的脚手架工程。我第一次跑成功之后做的第一件事不是自己去看代码而是把这个模板工程的关键文件丢给 AI让它先读一遍再跟它说“我们要在这个基础上做一个番茄钟应用”。这个习惯在后面帮了大忙AI 只有见过真实的工程结构写出来的代码才不至于跑偏。模拟器我也装了。Zepp OS 的模拟器可以单独下载不过我后来发现手表真机就在手边插上充电线就能调试大部分时间我直接跑真机。模拟器适合先验证视觉布局真机适合验证震动、息屏、续航这些模拟器给不了的真实感受。2.2 让 AI 从零生成一个手表 App 的正确姿势很多人用 AI 写代码上来就是一句“帮我写个番茄钟 App”然后拿到代码不知所措。在手表小程序这个场景里这么问基本必翻车因为 AI 不知道 Zepp OS 是什么只会按它最熟悉的微信小程序或者网页应用来写。它给你写出wx.setStorage的时候你根本跑都跑不起来。我摸索出一套提示词结构效果稳定很多第一句交代平台和限制目标平台是 Zepp OS 2.x 手表小程序用 JavaScript不能用浏览器 API不能使用可能存在的外部依赖只允许使用提供的模板工程中出现的模块。第二段是背景把一个最小可运行工程的代码贴进去告诉 AI“这是官方模板所有接口调用请参考这里的写法”。第三段是交互描述首页显示一个大号倒计时数字上方显示当前待办标题下方有开始、暂停、重置三个按钮待办页可以添加新待办、勾选完成、删除待办每次点击开始要记录一条番茄钟完成记录。第四段是约束页面切换不要动画点击区域要大于多少像素字体要尽量大适配低分辨率屏幕。关键点在于让 AI “先读模板再写代码”而不是让它凭印象发挥。我在几次翻车之后发现只要我事先把模板代码贴给它它生成的第一版代码能跑通的比例就会高很多。它会把模板里那些正确的 API 导入语句、生命周期写法复用到新代码里张冠李戴的概率大幅下降。2.3 降低 AI 幻觉的几个操作细节AI 写代码最大的问题不是不会写而是“一本正经地编造 API”。它可能写出一个看起来逻辑完备、但方法名在 Zepp OS 里根本不存在的函数。我踩过几次坑之后总结出几个很实用的操作细节。细节一先让 AI 列接口清单再写代码。在我描述完需求之后我会加一句“先列出你打算使用的所有 API 名称和来源模块等确认之后再写代码”。这一步能帮我把 AI 的幻觉扼杀在摇篮里如果它列出来的接口在官方文档里根本不存在我会直接把文档对应段落贴给它告诉它“项目中不存在这个方法你只能用文档中出现的接口”。细节二每次只生成一个页面或一个模块。让 AI 一口气生成整个应用结果往往是每个页面都有小缺陷改起来互相牵连。我改成“先写首页计时器跑通之后再写待办页最后写存储模块”每一步都有清晰的验收标准出了 bug 也知道是哪个文件的问题。细节三把模拟器或真机的报错原样贴回去不要自己概括。我一开始习惯把报错理解成一句话再告诉 AI比如“它说存储出问题了”效果很差。后来我直接复制完整日志附带相关的代码块让 AI 自己分析。AI 读原始日志的能力比读二手转述强得多这和跟同事协作是反过来的。3. 番茄代办 App 的核心实现从数据设计到计时逻辑3.1 数据模型先想清楚待办、计时与记录的存储设计写手表应用之前我先把要存的东西全部列了一遍。这个 App 需要的数据大概有四类待办列表、当前选中的待办、番茄钟完成记录、用户设置。Zepp OS 提供的是一个键值对存储模块读写方式接近Storage.get(key)和Storage.set(key, value)没有本地数据库所以所有结构化数据都得序列化成 JSON 之后存进去。我的键设计如下todos_v1待办数组每一项包含{ id, title, done, createdAt }对应一个待办事项。currentTodoId当前选中的待办 ID计时结束时方便记录“刚才专注的是哪件事”。focusRecords番茄钟记录数组每一项包含{ todoId, todoTitle, startTs, durationMin }。settings包含工作分钟数、休息分钟数、每日目标等配置。这个设计看起来简单但有一个坑手表存储空间很有限如果每条番茄记录都无脑追加早晚有一天写满。所以我在写入focusRecords时做了两个限制只保留最近 30 条记录超过就把最老的覆盖掉每条记录的durationMin只在重新开始时更新不做秒级写入。这样既保证统计功能有数据可用又不会让存储模块成为性能瓶颈。选 kv 而不是数据库还有一个原因读写频率低。番茄钟的典型使用场景是几十分钟才写一次存储压根用不到事务和索引。用最简单的存储模型反而更不容易出错。3.2 页面结构大数字、大按钮和一只手能操作的单手流手表不是手机屏幕小、触控精度差交互逻辑必须做减法。我最终保留了三个页面首页、待办页、新增页。首页是核心占据 90% 的使用时间。首页上半部分是一个显示剩余分钟和秒的大数字字号恨不得撑满半块表盘大数字下方一行小字显示当前正在专注的待办标题再往下是两个大按钮左侧“开始/暂停”右侧“重置”。整个页面只有一个动作路径选中一个待办点开始抬腕看进度震动结束。新增待办不需要常驻首页全部收进待办页避免误触。AI 一开始生成的 UI 是手机上常见的“标题栏 列表 底部按钮”结构字体小、按钮窄我戴到手腕上试了一下根本点不准。改版时我只提了一个要求所有可点击区域最小 40 像素时间数字用一个专用的巨大字体其他文字全部退居次要位置。手表应用的设计原则和手机完全是两码事手机上讲究信息层级丰富手表上只讲究“抬手三秒内看清关键信息”做不到这一点功能再全也没用。3.3 计时状态机与息屏恢复这步是全场最关键的坑手表应用和浏览器应用最大的区别在于屏幕一熄JS 定时器基本会被系统挂起。如果像网页里那样写一个setInterval每秒减 1那么息屏一分钟再抬腕倒计时就落后了整整一分钟。这大概是手表端番茄钟最容易翻车的点也是 AI 完全没概念的地方。我的方案分三层。第一层不依赖定时器累计而是保存“目标结束时间戳”。开始按钮按下时计算endAt Date.now() workMinutes * 60000把endAt写进存储。第二层页面在每次显示时也就是生命周期回调触发的时刻用Date.now()重算剩余秒数。第三层屏幕可见期间才做秒级刷新刷新只负责更新 UI不再参与计时判断。核心逻辑简化下来是这样的function computeRemainingSec() { const endAt getSetting(endAt); return Math.max(0, Math.round((endAt - Date.now()) / 1000)); }倒计时状态机也不复杂总共四个状态空闲、专注中、休息中、已完成。所有状态迁移都收进一个统一的函数处理function go(state) { currentState state; setSetting(state, state); if (state focus) { setSetting(endAt, Date.now() workMin * 60000); } render(); }这里最关键的一行是setSetting(state, state)。手表应用随时可能被系统杀掉如果把状态只放在内存里用户抬腕一看它可能已经悄悄退回了空闲状态。每次状态迁移都持久化重启之后才能恢复现场。AI 最初写的版本没有这一行导致我直接锁屏再抬腕番茄钟就变成“已结束”。这个坑修了我整整一个晚上也是整篇文章里含金量最高的一课。4. AI Coding 翻车实录与排坑方法4.1 翻车场景一API 张冠李戴第一次跑番茄钟首页的时候AI 生成了一段存储代码用了Storage.setValue(todos, todos)我放到模拟器一跑直接报错“setValue is not a function”。查了下文档Zepp OS 里这个模块的接口叫set而不是setValue。还有一个更典型的错误它曾经给我写过wx.setStorageSync这是微信小程序的 API在手表上自然不存在。这类错误最好解决因为思路很简单把官方文档相关段落直接贴进对话附上一句“这个运行环境不是微信小程序不是 React Native是 Zepp OS只允许使用文档里出现的接口”。AI 看到真实文档之后极少会再犯同样的错误。真正的坑是它下次写新功能时可能又犯类似问题所以我每次新开一个文件时都会重复一遍这个“平台约束”声明宁可啰嗦也不放松。4.2 翻车场景二跨页面数据不同步AI 写待办页的时候习惯性地在页面内部定义一个数组变量来存待办列表点击“新增”后推一条进去。看起来没问题但切到首页再切回来新增的待办消失了因为页面重新加载时变量被重置根本没写进存储。这个问题的根源是 AI 把网页应用里“全局变量即共享”的思维带过来了。手表页面之间的数据同步必须通过存储模块来做。我的解决办法是抽了一个统一的 store 模块所有页面对待办的读写都走它页面内部不再自己维护数据import { Storage } from zos/storage; const TODO_KEY todos_v1; let cache null; export function getTodos() { if (!cache) { cache JSON.parse(Storage.get(TODO_KEY, [])); } return cache; } export function setTodos(next) { cache next; Storage.set(TODO_KEY, JSON.stringify(next)); }改完之后待办的新增、勾选、删除全部通过这个模块完成。这个决策属于典型的系统设计问题AI 不会主动想到需要人来拍板。这也是我反复强调“AI 擅长写代码不擅长做架构”的原因。4.3 翻车场景三AI 连续改错时的正确拉法有一次我很想让首页的数字更大一点改成“每 5 秒刷新一次大字”的需求。结果 AI 连着改了三次每次看起来都在认真修但一跑就崩。第一次改了字体变量把渲染函数里一个参数拼错了第二次改了布局把整个数字区域的宽度算错第三次最离谱直接把倒计时归零了。后来我意识到问题在于我把需求描述得太宽泛“让数字更大”这个指令 AI 可以发挥的空间太大。它改的时候会波及到无关代码。于是我换了个策略直接贴出formatTime这个函数的完整代码然后说“只允许修改这个函数内部不要动其他文件”。这次它一次就改对了。这个经验非常实用AI 连续改错时先不要继续加需求而是把问题收敛到一个函数、一个文件、一个变量的范围内把上下文收到最窄再让它动手。给 AI 越大的自由度它越容易在无意中破坏现有逻辑给它明确的边界它反而能稳定发挥。5. 上手腕实测打包、安装与日常使用感受5.1 从模拟器到真机安装一个自己写的 App模拟器上跑通之后下一步就是打包安装到真机。Zepp OS 的 CLI 工具提供了构建命令生成一个后缀名为 zpk 的安装包。安装路径一般是通过手机上的 Zepp App 的开发者模式选择“安装本地应用”然后选中这个 zpk 文件。我第一次装的时候找这个入口找了十分钟最后是在 App 设置页里搜“开发者”三个字才搜出来的。不同版本入口名字会不一样找不到就别硬找直接搜关键词。装好之后手表应用列表里会出现一个默认图标的程序名字是我在项目配置里写的。首次打开它时系统会提示申请振动权限这个一定要同意因为番茄钟的完成提醒全靠震动没有震动就没有存在感。应用安装完成并不代表万事大吉我第一次真机运行时才发现模拟器里显示正常的动画真机上有明显的掉帧于是又把页面切换动画全部关掉了。模拟器永远代替不了真机这句话在手表开发里尤其正确。5.2 五十次番茄钟之后续航、跟手度与摘不下来的理由装好之后我连续用了两周跑了五十多个番茄钟。先说续航。GTR4 本身的底子就好平时用一周多一充我的番茄钟 App 不打 GPS、不联网、不做疯狂刷新只在抬腕亮屏时渲染一下数字、到时间震一下对续航的影响微乎其微。两周用下来充电频率和之前基本一致没有明显感知。再说跟手度。手表触控屏的灵敏度比手机差一截按钮做小了真的会点不到旁边去。我把所有按钮的点击区域加大之后操作成功率明显提升误触情况几乎消失。最舒服的一点是抬腕看进度屏幕一亮的瞬间剩余分钟数已经按新的时间戳算好了不需要等待刷新这个体验是手机番茄钟给不了的。戴了两周之后我觉得这块表摘不下来的理由也很简单手机番茄钟需要你主动打开 App、保持屏幕常亮、忍受通知干扰而手表番茄钟只留下了一个动作——开始剩下的都由震动和表盘接住了。专注这件事并没有因为它戴在手上而变得神奇但它确实被简化到了没法再简单的程度。5.3 可以继续往深里做的几个方向这个番茄代办 App 目前的功能已经满足日常使用了但我心里已经列了一串想加的东西。统计页是第一个想做的。现在focusRecords里累计了几十条记录但手表上没有页面展示数据白白躺着。我可以按天、按周聚合专注时长用表格或简单柱状图呈现这样每周日晚抬腕看一眼就能知道这周的工作节奏。每日目标也值得加。如果设定“今天完成 6 个番茄”那么每完成一个表盘上就能看到进度环在收拢直到目标达成后震动庆祝一下。这个机制对习惯养成很有帮助它会让你在下午四点多的时候觉得“还差两个番茄不如再开一轮”。还有一个方向是跟通知联动。Zepp OS 支持消息推送手机来通知时手机会震。现在我的处理方式是专注模式开启后手机直接进勿扰但有些消息又不想错过。后续可以做一个配置项专注期间只放行特定应用的通知其余全部静默休息时再统一提醒。这个需求很有真实价值做起来也不复杂只是需要在手表端和手机端两头都要改逻辑。最后就算这块表真的要退役这套代码本身也是有价值的。把数据模型和计时逻辑打包成一个模板将来换别的 Zepp OS 设备时只需要调整页面尺寸和图标设计重新构建一下就能继续用。旧设备会淘汰但写过东西的经验和处理问题的思路不会。我在实际使用中最深的一点体会是AI coding 并不是“我要什么它给我什么”的魔法它更擅长的是把已经很明确的指令翻译成代码的执行层工作。系统边界、状态迁移、数据一致性这些真正决定应用能不能长期稳定运行的架构决策依然得靠人来想清楚。但反过来讲一个能把需求拆得足够清晰、愿意逐字核对文档边界的人配上 AI coding 之后产出效率比过去手写提升了一倍还不止。几天前还躺在抽屉里吃灰的一块旧表现在每天陪我完成七八个番茄钟这种满足感大概就是技术折腾最原始的动力。
把抽屉里那块 GTR4 翻出来的时候我本来只是想给它换个表盘。结果表盘商店里翻来翻去都是那几个风格倒是我每天最需要的一个小功能——番茄钟——要么没有要么做成手机上那种满屏按钮的简化版根本没法在手腕上用。于是念头就歪了我自己给它写一个。这个“自己写”不是拿现成的 App 塞进去而是在 Zepp OS 上从零做一个手表小程序而且整个过程靠的是 AI coding。整个过程下来最大的收获不是产出了一个能用的番茄代办 App而是验证了一个挺实用的工作流一块两三年前的老表一个懂点编程但完全没接触过手表开发的人靠着 AI coding 一样能把想法变成戴在手腕上的应用。你不需要先啃完官方文档也不需要是个前端高手只需要知道怎么把需求拆清楚、怎么把 AI 的幻觉拉回正轨。这篇文章想把这条完整的路线记录下来从开发环境、数据设计、计时逻辑到 AI 翻车实录和真机安装全部是这次实操里真实发生过的东西。1. 旧表新用为什么我想在 GTR4 上自己写个番茄钟1.1 从抽屉里翻出来的 GTR4到底还能干点什么GTR4 是一款两三年前发布的智能手表1.43 英寸圆形 AMOLED 屏幕独立的 GPS很长的续航还有两个实体按键和一个线性震动马达。放在今天它的智能功能确实不算新了但作为一块表基础素质依然优秀屏幕够亮、震动够干脆、充一次电能顶一周多。它最大的问题不是硬件不行而是应用商店里的东西太少表盘翻来覆去就那么几套官方应用也就那几个。我重新激活它之后发现它跑的系统是 Zepp OS这套系统最大的特点是允许开发者安装第三方小程序而且开发语言以 JavaScript 为主不需要像开发别的表那样搞一套专门的环境。也就是说只要你愿意写代码这块旧表就可以具备任何你想象中的应用场景。当时我在手机应用商店里翻番茄钟翻到的要么是订阅制的要么是功能堆得密密麻麻的要么根本不支持自定义。手表上更惨系统自带的应用里压根没有番茄钟这个概念。与其等官方更新不如自己动手。这大概是所有“旧设备二次生命”故事里最有说服力的一点设备本身没有坏只是没有适合它的应用。而 Zepp OS 给了普通用户一个自己做应用的机会这是它比同价位手表更值得折腾的地方。1.2 为什么番茄钟必须长在手腕上说来也怪手机上番茄钟应用多得很但我一直没有坚持用下来。原因也很简单番茄钟的核心是“开始一段不被打扰的专注时间”可手机本身就是最大的打扰源。开个番茄钟锁屏放一边屏幕一亮你总会忍不住瞄一眼通知一瞄就可能滑走了。手机上的番茄钟在提醒你专注的同时还在给你推送消息这本身就是矛盾的。手表不一样。它的屏幕小信息密度低抬腕只能看到“当前剩余时间”和“当前要做的事”没有社交软件、没有信息流、没有短视频入口。番茄钟开始之后你把手机丢在另一个房间计时、进度、提醒全部由手腕上的震动和表盘完成。到了 25 分钟手表震一下告诉你“该休息了”你抬手看看下一个待办是什么继续干活就行全程不需要碰手机。所以这个需求的本质不是“我要一个计时器”而是“我要一套能让我放下手机的专注仪式”。手表上的番茄钟恰恰把手机从整个流程中踢了出去。这个感受很难用截图传达戴上之后才明白为什么番茄钟一定要长在手腕上。1.3 AI coding 到底帮了什么忙说老实话我写 JavaScript 的经验有一些但完全没碰过 Zepp OS 开发。这套系统的 API、页面结构、生命周期、打包方式对我来说全是新的。如果按照传统路线我得先花两个晚上看文档再照着官方模板改半天才能跑通一个 hello world。但这次我全程用的是 AI coding也就是通过对话让 AI 帮忙生成代码、修 bug、解释报错。我负责的部分是需求拆解、数据设计、边界条件、真机验证。AI 负责的部分是页面布局代码生成、API 调用草稿、样式换算、把日志报错翻译成人话。这个分工不是一开始就定的而是做了几个页面之后自然形成的。AI 在陌生平台上的第一版代码大概能跑通 60% 到 70%剩下那部分不能用绝大多数不是逻辑问题而是它根本不熟悉 Zepp OS 的 API。后面我会详细说怎么喂上下文、怎么改错这是 AI coding 能不能用好的关键。2. 开发环境搭建Zepp OS 应用与 AI 的第一次配合2.1 开启开发者模式准备一个最小的运行环境开发手表 App 之前先得让手表和设备进入开发者模式。不同固件版本的入口略有差异但思路是一样的手表端在“设置”里找到“关于”连续点击版本号若干下会弹出一个开发者模式开启的提示手机端在 Zepp App 里找到开发者入口开启后才能通过手机往手表安装本地应用。这一步卡了我一阵子因为入口藏得比较深后来我直接在 App 里搜“开发者”三个字才找到。环境方面电脑上需要安装 Zepp OS 的 CLI 工具。我用的是 npm 安装方式npm install -g zeppos/zeppos-cli安装完成之后创建一个项目模板zeppos create它会生成一个带 hello world 的脚手架工程。我第一次跑成功之后做的第一件事不是自己去看代码而是把这个模板工程的关键文件丢给 AI让它先读一遍再跟它说“我们要在这个基础上做一个番茄钟应用”。这个习惯在后面帮了大忙AI 只有见过真实的工程结构写出来的代码才不至于跑偏。模拟器我也装了。Zepp OS 的模拟器可以单独下载不过我后来发现手表真机就在手边插上充电线就能调试大部分时间我直接跑真机。模拟器适合先验证视觉布局真机适合验证震动、息屏、续航这些模拟器给不了的真实感受。2.2 让 AI 从零生成一个手表 App 的正确姿势很多人用 AI 写代码上来就是一句“帮我写个番茄钟 App”然后拿到代码不知所措。在手表小程序这个场景里这么问基本必翻车因为 AI 不知道 Zepp OS 是什么只会按它最熟悉的微信小程序或者网页应用来写。它给你写出wx.setStorage的时候你根本跑都跑不起来。我摸索出一套提示词结构效果稳定很多第一句交代平台和限制目标平台是 Zepp OS 2.x 手表小程序用 JavaScript不能用浏览器 API不能使用可能存在的外部依赖只允许使用提供的模板工程中出现的模块。第二段是背景把一个最小可运行工程的代码贴进去告诉 AI“这是官方模板所有接口调用请参考这里的写法”。第三段是交互描述首页显示一个大号倒计时数字上方显示当前待办标题下方有开始、暂停、重置三个按钮待办页可以添加新待办、勾选完成、删除待办每次点击开始要记录一条番茄钟完成记录。第四段是约束页面切换不要动画点击区域要大于多少像素字体要尽量大适配低分辨率屏幕。关键点在于让 AI “先读模板再写代码”而不是让它凭印象发挥。我在几次翻车之后发现只要我事先把模板代码贴给它它生成的第一版代码能跑通的比例就会高很多。它会把模板里那些正确的 API 导入语句、生命周期写法复用到新代码里张冠李戴的概率大幅下降。2.3 降低 AI 幻觉的几个操作细节AI 写代码最大的问题不是不会写而是“一本正经地编造 API”。它可能写出一个看起来逻辑完备、但方法名在 Zepp OS 里根本不存在的函数。我踩过几次坑之后总结出几个很实用的操作细节。细节一先让 AI 列接口清单再写代码。在我描述完需求之后我会加一句“先列出你打算使用的所有 API 名称和来源模块等确认之后再写代码”。这一步能帮我把 AI 的幻觉扼杀在摇篮里如果它列出来的接口在官方文档里根本不存在我会直接把文档对应段落贴给它告诉它“项目中不存在这个方法你只能用文档中出现的接口”。细节二每次只生成一个页面或一个模块。让 AI 一口气生成整个应用结果往往是每个页面都有小缺陷改起来互相牵连。我改成“先写首页计时器跑通之后再写待办页最后写存储模块”每一步都有清晰的验收标准出了 bug 也知道是哪个文件的问题。细节三把模拟器或真机的报错原样贴回去不要自己概括。我一开始习惯把报错理解成一句话再告诉 AI比如“它说存储出问题了”效果很差。后来我直接复制完整日志附带相关的代码块让 AI 自己分析。AI 读原始日志的能力比读二手转述强得多这和跟同事协作是反过来的。3. 番茄代办 App 的核心实现从数据设计到计时逻辑3.1 数据模型先想清楚待办、计时与记录的存储设计写手表应用之前我先把要存的东西全部列了一遍。这个 App 需要的数据大概有四类待办列表、当前选中的待办、番茄钟完成记录、用户设置。Zepp OS 提供的是一个键值对存储模块读写方式接近Storage.get(key)和Storage.set(key, value)没有本地数据库所以所有结构化数据都得序列化成 JSON 之后存进去。我的键设计如下todos_v1待办数组每一项包含{ id, title, done, createdAt }对应一个待办事项。currentTodoId当前选中的待办 ID计时结束时方便记录“刚才专注的是哪件事”。focusRecords番茄钟记录数组每一项包含{ todoId, todoTitle, startTs, durationMin }。settings包含工作分钟数、休息分钟数、每日目标等配置。这个设计看起来简单但有一个坑手表存储空间很有限如果每条番茄记录都无脑追加早晚有一天写满。所以我在写入focusRecords时做了两个限制只保留最近 30 条记录超过就把最老的覆盖掉每条记录的durationMin只在重新开始时更新不做秒级写入。这样既保证统计功能有数据可用又不会让存储模块成为性能瓶颈。选 kv 而不是数据库还有一个原因读写频率低。番茄钟的典型使用场景是几十分钟才写一次存储压根用不到事务和索引。用最简单的存储模型反而更不容易出错。3.2 页面结构大数字、大按钮和一只手能操作的单手流手表不是手机屏幕小、触控精度差交互逻辑必须做减法。我最终保留了三个页面首页、待办页、新增页。首页是核心占据 90% 的使用时间。首页上半部分是一个显示剩余分钟和秒的大数字字号恨不得撑满半块表盘大数字下方一行小字显示当前正在专注的待办标题再往下是两个大按钮左侧“开始/暂停”右侧“重置”。整个页面只有一个动作路径选中一个待办点开始抬腕看进度震动结束。新增待办不需要常驻首页全部收进待办页避免误触。AI 一开始生成的 UI 是手机上常见的“标题栏 列表 底部按钮”结构字体小、按钮窄我戴到手腕上试了一下根本点不准。改版时我只提了一个要求所有可点击区域最小 40 像素时间数字用一个专用的巨大字体其他文字全部退居次要位置。手表应用的设计原则和手机完全是两码事手机上讲究信息层级丰富手表上只讲究“抬手三秒内看清关键信息”做不到这一点功能再全也没用。3.3 计时状态机与息屏恢复这步是全场最关键的坑手表应用和浏览器应用最大的区别在于屏幕一熄JS 定时器基本会被系统挂起。如果像网页里那样写一个setInterval每秒减 1那么息屏一分钟再抬腕倒计时就落后了整整一分钟。这大概是手表端番茄钟最容易翻车的点也是 AI 完全没概念的地方。我的方案分三层。第一层不依赖定时器累计而是保存“目标结束时间戳”。开始按钮按下时计算endAt Date.now() workMinutes * 60000把endAt写进存储。第二层页面在每次显示时也就是生命周期回调触发的时刻用Date.now()重算剩余秒数。第三层屏幕可见期间才做秒级刷新刷新只负责更新 UI不再参与计时判断。核心逻辑简化下来是这样的function computeRemainingSec() { const endAt getSetting(endAt); return Math.max(0, Math.round((endAt - Date.now()) / 1000)); }倒计时状态机也不复杂总共四个状态空闲、专注中、休息中、已完成。所有状态迁移都收进一个统一的函数处理function go(state) { currentState state; setSetting(state, state); if (state focus) { setSetting(endAt, Date.now() workMin * 60000); } render(); }这里最关键的一行是setSetting(state, state)。手表应用随时可能被系统杀掉如果把状态只放在内存里用户抬腕一看它可能已经悄悄退回了空闲状态。每次状态迁移都持久化重启之后才能恢复现场。AI 最初写的版本没有这一行导致我直接锁屏再抬腕番茄钟就变成“已结束”。这个坑修了我整整一个晚上也是整篇文章里含金量最高的一课。4. AI Coding 翻车实录与排坑方法4.1 翻车场景一API 张冠李戴第一次跑番茄钟首页的时候AI 生成了一段存储代码用了Storage.setValue(todos, todos)我放到模拟器一跑直接报错“setValue is not a function”。查了下文档Zepp OS 里这个模块的接口叫set而不是setValue。还有一个更典型的错误它曾经给我写过wx.setStorageSync这是微信小程序的 API在手表上自然不存在。这类错误最好解决因为思路很简单把官方文档相关段落直接贴进对话附上一句“这个运行环境不是微信小程序不是 React Native是 Zepp OS只允许使用文档里出现的接口”。AI 看到真实文档之后极少会再犯同样的错误。真正的坑是它下次写新功能时可能又犯类似问题所以我每次新开一个文件时都会重复一遍这个“平台约束”声明宁可啰嗦也不放松。4.2 翻车场景二跨页面数据不同步AI 写待办页的时候习惯性地在页面内部定义一个数组变量来存待办列表点击“新增”后推一条进去。看起来没问题但切到首页再切回来新增的待办消失了因为页面重新加载时变量被重置根本没写进存储。这个问题的根源是 AI 把网页应用里“全局变量即共享”的思维带过来了。手表页面之间的数据同步必须通过存储模块来做。我的解决办法是抽了一个统一的 store 模块所有页面对待办的读写都走它页面内部不再自己维护数据import { Storage } from zos/storage; const TODO_KEY todos_v1; let cache null; export function getTodos() { if (!cache) { cache JSON.parse(Storage.get(TODO_KEY, [])); } return cache; } export function setTodos(next) { cache next; Storage.set(TODO_KEY, JSON.stringify(next)); }改完之后待办的新增、勾选、删除全部通过这个模块完成。这个决策属于典型的系统设计问题AI 不会主动想到需要人来拍板。这也是我反复强调“AI 擅长写代码不擅长做架构”的原因。4.3 翻车场景三AI 连续改错时的正确拉法有一次我很想让首页的数字更大一点改成“每 5 秒刷新一次大字”的需求。结果 AI 连着改了三次每次看起来都在认真修但一跑就崩。第一次改了字体变量把渲染函数里一个参数拼错了第二次改了布局把整个数字区域的宽度算错第三次最离谱直接把倒计时归零了。后来我意识到问题在于我把需求描述得太宽泛“让数字更大”这个指令 AI 可以发挥的空间太大。它改的时候会波及到无关代码。于是我换了个策略直接贴出formatTime这个函数的完整代码然后说“只允许修改这个函数内部不要动其他文件”。这次它一次就改对了。这个经验非常实用AI 连续改错时先不要继续加需求而是把问题收敛到一个函数、一个文件、一个变量的范围内把上下文收到最窄再让它动手。给 AI 越大的自由度它越容易在无意中破坏现有逻辑给它明确的边界它反而能稳定发挥。5. 上手腕实测打包、安装与日常使用感受5.1 从模拟器到真机安装一个自己写的 App模拟器上跑通之后下一步就是打包安装到真机。Zepp OS 的 CLI 工具提供了构建命令生成一个后缀名为 zpk 的安装包。安装路径一般是通过手机上的 Zepp App 的开发者模式选择“安装本地应用”然后选中这个 zpk 文件。我第一次装的时候找这个入口找了十分钟最后是在 App 设置页里搜“开发者”三个字才搜出来的。不同版本入口名字会不一样找不到就别硬找直接搜关键词。装好之后手表应用列表里会出现一个默认图标的程序名字是我在项目配置里写的。首次打开它时系统会提示申请振动权限这个一定要同意因为番茄钟的完成提醒全靠震动没有震动就没有存在感。应用安装完成并不代表万事大吉我第一次真机运行时才发现模拟器里显示正常的动画真机上有明显的掉帧于是又把页面切换动画全部关掉了。模拟器永远代替不了真机这句话在手表开发里尤其正确。5.2 五十次番茄钟之后续航、跟手度与摘不下来的理由装好之后我连续用了两周跑了五十多个番茄钟。先说续航。GTR4 本身的底子就好平时用一周多一充我的番茄钟 App 不打 GPS、不联网、不做疯狂刷新只在抬腕亮屏时渲染一下数字、到时间震一下对续航的影响微乎其微。两周用下来充电频率和之前基本一致没有明显感知。再说跟手度。手表触控屏的灵敏度比手机差一截按钮做小了真的会点不到旁边去。我把所有按钮的点击区域加大之后操作成功率明显提升误触情况几乎消失。最舒服的一点是抬腕看进度屏幕一亮的瞬间剩余分钟数已经按新的时间戳算好了不需要等待刷新这个体验是手机番茄钟给不了的。戴了两周之后我觉得这块表摘不下来的理由也很简单手机番茄钟需要你主动打开 App、保持屏幕常亮、忍受通知干扰而手表番茄钟只留下了一个动作——开始剩下的都由震动和表盘接住了。专注这件事并没有因为它戴在手上而变得神奇但它确实被简化到了没法再简单的程度。5.3 可以继续往深里做的几个方向这个番茄代办 App 目前的功能已经满足日常使用了但我心里已经列了一串想加的东西。统计页是第一个想做的。现在focusRecords里累计了几十条记录但手表上没有页面展示数据白白躺着。我可以按天、按周聚合专注时长用表格或简单柱状图呈现这样每周日晚抬腕看一眼就能知道这周的工作节奏。每日目标也值得加。如果设定“今天完成 6 个番茄”那么每完成一个表盘上就能看到进度环在收拢直到目标达成后震动庆祝一下。这个机制对习惯养成很有帮助它会让你在下午四点多的时候觉得“还差两个番茄不如再开一轮”。还有一个方向是跟通知联动。Zepp OS 支持消息推送手机来通知时手机会震。现在我的处理方式是专注模式开启后手机直接进勿扰但有些消息又不想错过。后续可以做一个配置项专注期间只放行特定应用的通知其余全部静默休息时再统一提醒。这个需求很有真实价值做起来也不复杂只是需要在手表端和手机端两头都要改逻辑。最后就算这块表真的要退役这套代码本身也是有价值的。把数据模型和计时逻辑打包成一个模板将来换别的 Zepp OS 设备时只需要调整页面尺寸和图标设计重新构建一下就能继续用。旧设备会淘汰但写过东西的经验和处理问题的思路不会。我在实际使用中最深的一点体会是AI coding 并不是“我要什么它给我什么”的魔法它更擅长的是把已经很明确的指令翻译成代码的执行层工作。系统边界、状态迁移、数据一致性这些真正决定应用能不能长期稳定运行的架构决策依然得靠人来想清楚。但反过来讲一个能把需求拆得足够清晰、愿意逐字核对文档边界的人配上 AI coding 之后产出效率比过去手写提升了一倍还不止。几天前还躺在抽屉里吃灰的一块旧表现在每天陪我完成七八个番茄钟这种满足感大概就是技术折腾最原始的动力。
