用 Claude Code 快速交付跨端用药应用

周四 20:40 打开空文件夹，周五约 16:00 提交审核，周一获批。作者用 Claude Code 做出了服药提醒应用 Vzato，覆盖 iPhone、iPad 和 Mac，支持四种语言。但这篇记录最有价值的地方，是那些测试全绿、到了真实生活里却出错的细节。

它提供了一个判断：AI 已经能压缩实现和上架准备的时间，产品该怎样运转、哪些行为可能误导用户，仍要靠人决定。对正在用 AI 做独立产品的程序员，这比「一天写了多少代码」更值得看。

为什么值得做，藏在「吃完药才能吃饭」里

作者试过多款服药提醒应用，仍然遇到几个具体问题：空腹服药后还要手动设置吃饭闹钟；不知道家里剩药够吃多久；半片、四分之一片和滴剂不好记录；不确定是否服过药，可能重复服用。账户、订阅和服务端存储又增加了负担。

Vzato 的起点，是把这些生活细节写成行为规则。

首页只突出当前需要处理的一次服药，提供大号 Taken 按钮，其余安排放在下方。对于需要餐前服用的药，用户点击 Taken 后，应用再安排一条通知。例如设置等待 30 分钟，到时提醒可以吃饭。

库存也不只是一个数字：应用需要根据服药计划推算补药日期，允许用户盘点实际数量，并区分盘点与新增药品。它还支持历史记录、A4 PDF 就医摘要、包装和说明书照片，以及 widgets。

这些功能围绕同一条使用链路展开：该吃什么、是否吃过、吃后要等多久、库存还能撑几天。

应用免费，以 MPL-2.0 开源，没有服务端和账户，通过用户自己的 iCloud 同步。作者认为，单人服药记录引入后端，收益不足以抵消账户、GDPR 和运行成本。这个取舍同时缩小了开发范围。

一个周末能交付，靠的是持续收窄决策

作者报告，从空文件夹到提交约 19 小时，中间有两次睡眠休息，实际坐在电脑前约 11 至 12 小时。产出包括 31 次提交、约 8,000 行 Swift、80 个单元测试及 UI 测试、11 个 TestFlight 构建、脚本生成并上传的 48 张商店截图，以及 Cloudflare 上的静态网站。

这些是作者披露的项目数据，原文没有提供独立核验或人工开发对照。

第一小时没有写代码。作者先让 Claude Code 输出规格和分阶段计划，再讨论名称、许可证、存储和服务端选项。数据模型、当日服药调度、通知、四个主页面和测试先完成，然后依次加入照片、多端布局、同步和 widgets。每阶段都构建并提交。

作者大约写了 100 条提示，多数在做选择。比如工作名 MedRemind 已被其他应用使用，最终改成源自确认按钮含义的 Vzato；存储选择 Core Data，理由是为未来的 CloudKit sharing 留路。这里记录的是他们的技术决策，原文没有展开 Core Data 与 SwiftData 的完整比较。

AI 能持续推进的前提，是关键决定能够在对话之外留下来。

行为变化要在同一次提交里更新规格和 changelog。CLAUDE.md 则固定约束：不引入第三方包、不做分析统计、网络访问仅限 Apple、不预先创建服药记录、库存修改集中到一处，并要求文件带 MPL 头、git 不存秘密。这些约束既减少反复提醒，也限制 AI 随手增加复杂度。

作者还同时使用第二个 agent，以 Astro 制作四种语言的网站、帮助页和隐私政策，要求无 JavaScript、无 cookies、无外部请求。App Store Connect API 承担多语言文案、年龄分级、定价、可用地区、TestFlight 说明和截图上传。演示数据、临时存储、直达页面、Mac 固定窗口尺寸等调试开关，则让截图可以批量生成。

省下来的时间，不只来自写 Swift 更快，也来自把重复操作做成脚本。

测试通过，为什么中午的提醒还是没响

最有说服力的案例发生在周五中午：作者等不到提醒，锁屏没有通知，也没有声音，但测试全部通过。

原因是应用只有在用户点击设置里的按钮时才请求通知权限。按作者的排查结果，没有授权时，通知调度调用仍被接受，系统却不会展示通知。测试验证了已有代码，却没有验证首次使用者能否真正收到提醒。

修复方式是：第一种药有了服药计划就请求权限；提醒关闭时，在 Today 页面显示红色警告。

其他问题也来自真机使用。作者家里有 79 片药、每天吃三片，应用算错了耗尽日期，修复后列表显示「最迟 11 月 7 日补药」。库存输入框会把新数字追加到旧值后。Taken 按钮还允许一键确认四小时后的剂量，容易误操作；后来改成仅提前 30 分钟开放一键确认，更早服用走 Take early… 二次确认，并允许撤销。

帮助文案同样会出错。AI 写了「滑动修改」，实际页面只支持长按；又建议通过库存盘点添加新药盒，但盘点会把它解释成库存差异。这些文字读起来合理，却与真实交互冲突。

问题还延续到了发布之后。TestFlight 暴露两次后台崩溃，都涉及 iCloud 同步期间数据库仍在写入，iOS 终止了应用；第一轮修复只覆盖退出应用，第二次发生在 iCloud 自行启动同步时。使用三天后，作者又发现锁屏提醒有时静默，随后集中出现，于是简化为同一时刻合并通知、少量跟进提醒，然后停止。

测试能证明代码符合已写下的规则，却不能证明规则适合真实生活。

审核也需要补交真机材料。Apple 要求说明用途、受众、外部服务、地区行为和产品监管属性，作者录制了两分半钟的视频。1.0 先获批 iPhone 和 iPad，Mac 随后通过；四天后，1.0.1 又提交审核，增加儿童与动物档案、每隔几天或几个月重复的计划，以及捷克和斯洛伐克药品离线数据库。

我的判断

我认同这套流程里最可迁移的部分：先确定行为，再分阶段实现；每阶段构建；把真实设备使用当成持续反馈来源。对 AI 编程而言，错误需求被迅速实现，往往比语法错误更难发现。

但「周末上架」有明确前提。作者是首位用户，能快速裁决需求；产品采用 Apple 原生技术和个人 iCloud，同步之外没有自建服务；也暂缓了家庭共享等功能。一般团队还有需求协调、权限体系、外部接口和验收流程，不能直接套用这个工期。所谓过去需要几个月晚间时间，也是作者的个人估计，没有对照数据。

更不能把获批当成可靠性证明。通知、后台同步等问题在提交后继续出现，匈牙利语仍待母语者校验。原文也没有给出长期提醒到达率或库存计算的系统性验证结果。

上架准备本身还包括隐私声明、CloudKit schema 从开发环境部署到生产、175 个国家的可用性配置、EU Digital Services Act 经营者身份、支持渠道和公开仓库前的历史审计。AI 可以准备材料，确认材料真实性的人仍是作者。应用声明不属于医疗器械，也不能替代对实际功能边界的审查。

这篇文章证明了一个人能把交付过程压得很短，尚未证明维护成本也同步下降。

能拿来做什么

• 用 Claude Code 做产品前，先写用户动作与系统结果。例如「确认后扣减库存」「撤销后恢复库存」，再要求 AI 给出两三个有取舍的方案，由你选定并写入规格。
• 给前端或移动端项目补上真实使用路径：首次启动、权限拒绝、锁屏、进入后台、重新打开。优先验证用户最终看到了什么，而不是只检查接口是否成功返回。
• 把帮助文案当作待验收功能，逐句对照页面操作。AI 写出的每个手势、入口和操作结果，都要在实际产品里走一遍。
• 在开发中提前准备演示数据、临时存储和固定截图环境，再把重复发布工作脚本化。将省下的时间留给真机使用和发布后的问题修复。