共计 2893 个字符，预计需要花费 8 分钟才能阅读完成。
作为一名长期跟踪 AI 技术的开发者，我一直想亲手尝试用 AI 工具来构建一个真正的应用。在成功使用 Claude Code 开发了线材管理应用的 iPhone 版和 Mac 版之后，我决定挑战为 Apple Watch 打造一个简化版本。这个决定开启了一段意想不到的开发旅程，也让我对 AI 编程协作有了全新的认识。
David Gewirtz / Elyse Betters Picaro / ZDNET
David Gewirtz/ZDNET 截图
我原以为将现有应用适配到 Apple Watch 会是顺理成章的事，但很快发现这比想象中复杂得多。问题的核心在于想象力——如何从丰富的功能中筛选出最核心的部分，并将其适配到苹果那块最小的屏幕上，这成了一个相当棘手的难题。
从原型到崩溃：Apple Watch 开发的初步挑战
我们确实在约两小时内就完成了界面的主体设计与初步实现，但这只是一个用于验证可行性的原型。很快问题浮现：测试数据在 Xcode 模拟器上无法正常运行。当应用被部署到实体手表，并尝试与 iPhone 应用中已积累的 120 多条数据记录协同工作时，监控应用性能的 Xcode 进程甚至出现了短暂崩溃。
David Gewirtz/ZDNET 截图
是时候重新开始了。这次经历让我意识到，Apple Watch 应用开发与 iPhone 或 Mac 开发有着本质的不同。
减法设计的艺术：与 Claude Code 确定核心功能
开发 iPhone 和 Mac 应用时，我们对最终产品的功能有清晰的蓝图。但对于 Apple Watch，适配方案一开始是模糊的。显而易见，NFC 扫描和拍照功能无法在手表上实现。那么，哪些功能至关重要？哪些可以舍弃？开发 Apple Watch 应用，本质上是一场“减法设计”。
这让我想起了米开朗基罗阐述雕塑创作的理念。这位艺术大师曾说：雕像本就存在于大理石之中，他的工作只是剔除多余的石料，使其显现。这正是 Apple Watch 应用开发的核心精神。应用的本体存在于 iPhone，我们需要做的，是通过代码的精简，让它在微型屏幕上焕发生机。
这次，我首先咨询了 Claude Code。输入的提示是：“需要开发一个 Apple Watch 应用。它必然是 iOS 应用的极简子集，需排除 NFC 和拍照功能。请结合项目用途，提出适合 Apple Watch 的功能方案。”
Claude 的表现可圈可点，尽管它最初的一些想法略显激进——例如提议在表盘复杂功能上显示剩余线材量。考虑到我们有数百个线轴，这并非一个实用的功能。我们既没有配备，也不需要能智能追踪单个线轴余量的方案。我们只是在必要时手动更新数据库中的近似百分比数据，这可能是整个应用中最次要的功能。
在突破了 Claude 对复杂功能的执念后，我们开始讨论实际使用场景。用户希望通过手表查看任意一台 3D 打印机当前装载的线材；在未携带手机进入实验室时，仅凭 Apple Watch 就能记录线轴的位置变更；并能快速检索项目规划所需的颜色与材料库存。
最终，我们敲定了手表应用的核心功能集：
- 按材料、颜色、供应商浏览和筛选线轴
- 查看线轴详情与当前分配状态
- 在线轴库与存储位置之间移动线轴
- 将线轴标记为“已完成”
- 浏览设备、存储位置与颜色库
- 实现手机、Mac 与手表之间的动态数据同步
相应地，我们决定舍弃以下功能：
- 基于 NFC 的快速移动生产流程
- NFC 标签的读写
- 线轴的创建、编辑与删除
- 设备与存储位置的管理
- 参考数据（供应商、颜色、材料等）的管理
- 已完成线轴的统计查看与恢复
- 数据备份与恢复
- 设置与工具模块
- iOS 快捷指令集成
功能集确定后，我将具体的应用构建任务交给了 Claude Code。
迭代与调试：AI 编程的实际工作流程
初始版本使用测试数据，并通过 Xcode 内置的模拟器进行验证。
David Gewirtz/ZDNET 截图
早期版本的主屏幕缺失了设备按钮。线轴列表功能被标注为“库存”，并设置了一个无效的筛选按钮。
David Gewirtz/ZDNET 截图
当线轴功能最终调试成功时，应用会显示线轴使用百分比，有时还会附带供应商名称。
David Gewirtz/ZDNET 截图
随后，Claude 试图将显示的线轴数量限制为前 25 个。我强调，应用的核心价值在于能够查看完整的线轴列表。经过沟通，Claude 最终移除了这个限制。
David Gewirtz/ZDNET 截图
当时，无论是人工智能还是我，都未意识到这个改动将暂时引发一个致命问题。
应对硬件现实：Apple Watch 的性能限制与解决方案
最终，所有界面都实现了正常运作。我曾希望能在手表上查看每个线轴的照片。但照片文件体积庞大，会占用可观的设备存储空间。
虽然 Apple Watch Series 9 配备了 1GB 运行内存和 64GB 存储空间，但这些资源需要与设备上运行的所有应用共享。将数百张照片同步至手表，很可能导致（也确实导致了）设备内存缓冲区过载。
据 Claude 解释，Apple Watch 的 iCloud 同步机制会一次性下载数据结构中的所有内容。在现有架构下，无法实现按需单张照片获取。
Claude 提议全面重构所有应用以支持此功能，但根据长期经验，为微小收益进行大规模改动往往会导致代码混乱甚至系统崩溃。因此，我与 Claude 就此问题进行了深入探讨——方式与和人类程序员协作无异。
David Gewirtz/ZDNET 截图
我们最终决定对主数据结构进行拆分：在保持其他数据一致性的前提下，让 iPhone 和 Mac 版本的数据结构包含照片引用，而 Watch 版本则完全排除照片数据。Claude Code 实施该方案后，一个真正可正常运行的 Apple Watch 应用终于诞生了。
AI 编程协作：更像搭档，而非工具
相较于开发 iPhone 或 Mac 版本，Watch 应用的开发过程更凸显了与 Claude Code 的“协作”特性。我咨询它的意见，采纳合理的建议方案，测试实施效果，在方案偏离轨道或无效时进行修正，并通过持续的互动对话来迭代优化。
尽管 Watch 应用是体量最小的版本（或许正因如此），使其达到可用状态所耗费的心力反而超过了前两个版本。核心挑战在于：既要保持原始应用架构的完整，又要构建一个完全契合手表设备物理与性能限制的专属版本。
正如之前所体会到的，借助人工智能回归编程，无需传统逐行编码所需的大量上下文切换时间。因此，我能够利用每次 20 分钟左右的片段化时间投入工作并取得可见进展，而不必专门分配数日时间来重新熟悉整个复杂的代码架构。
我对最终实现的 Watch 版本相当满意，并已将其整合到日常的 3D 打印项目工作流中。根据项目规模估算，若采用传统手动编码方式开发这样一个应用，可能需要 6 到 8 周的有效工时，且这些时间往往会分散在长达半年的周末里。
但使用 Claude Code 后，实际的核心开发时间总计约 12 小时，分散在三周内完成。最初两小时就看到一个可运行应用原型所带来的兴奋感，驱动着我在后续时间里持续将其优化调整至理想状态。
虽然我曾手动开发过 iPhone 和 Mac 应用，但这是首次构建 Apple Watch 应用。与 Claude 协作开发首款 Apple Watch 应用的经历，无疑是一次提升生产力的成功实践。它感觉不像自动化，更像是一场与一位反应迅速、知识渊博的编程搭档之间的高效对话。
