一款iPhone提词器应用已通过苹果的审核，在App Store正式上架，而整个应用都是用Anthropic的命令行AI编程工具Claude Code开发的。界面设计、构建、测试、图片素材以及App Store提交，全部通过这一工具完成。不过，这一切并非出自某个神奇的提示词。这款应用前后用了215次提示词、120次提交，一次做一个部分，每次改动后都在真机上检查。最值得关注的经验，与其说是AI写代码有多快，不如说是围绕它的反馈循环：在真实硬件上测试；遇到顽固的bug时，去收集数据，而不是继续让AI猜测。
这款应用能做什么
这款产品是一款提词器，也就是让说话者一边看着镜头一边读稿的工具。它源于对现有提词器应用的不满：这些应用往往界面杂乱、控件太小，或者文字离镜头太远，难以保持自然的眼神交流。解决办法是把阅读线放在前置摄像头开孔的正旁边，这样观看成片的人会觉得说话者正直视着自己。
主要功能如下：
- 编写或导入讲稿，让文字在固定的阅读线下方滚动
- 调整字体、行距、边距和滚动速度，并可自定义文字主题
- 为玻璃提词器支架翻转显示
- 使用前置或后置摄像头录制
- 用硬件遥控器控制播放
- 通过Apple Watch配套应用开始、暂停和调整速度
- 所有内容都保存在设备上，无需账号，不用云存储，也没有分析或遥测功能
不是一条提示词，而是持续协作
| 指标 | 数值 |
|---|---|
| 发给Claude Code的提示词 | 215次 |
| Git提交 | 120次 |
| 自动化UI测试 | 25项 |
| Apple Developer Program费用 | 每年$99 |
一款要经受App Store审核的精致消费级应用，不太可能靠一条提示词就生成出来。这个项目把Claude Code当作持续对话中的工程伙伴：做好一个组件，立刻测试这次改动，再进入下一个。指望一次请求就得到可以发布的成品，看来并不现实。
在真实iPhone上形成闭环
整个工作流程的核心，是一个从终端驱动的自动循环。每当Claude Code修改代码，都会执行同样的步骤：
- Claude Code编辑源代码。
- 用xcodebuild编译应用。
- 用xcrun devicectl把构建好的应用安装到已连接的iPhone上。
- 在手机上启动应用，以便立即亲手试用这次改动。
既然Mac上的iOS模拟器就在手边，为什么还要这么麻烦？因为对这类应用来说，最要紧的东西恰恰被模拟器掩盖了。触控区域是否够大、触觉反馈是否合适、讲稿读起来是否舒服、眼神交流的角度是否到位，只有把手机拿在手里才能判断。后文会提到，模拟器还掩盖了一个严重的性能bug。
这个项目揭示了一个更普遍的经验：AI编程智能体，也就是能自行编辑代码、运行命令并推进任务的AI，接入持续的构建与部署循环时，似乎远比被当作只会返回代码的文本生成工具更有用。
▲ 真机构建与测试循环
在苹果的规范内直接用代码设计
这个项目跳过了先在Figma里做界面原型、再用Swift重新实现的常规流程，而是直接在Claude Code中使用苹果设计套件里的标准组件来设计界面。坚持使用标准iOS组件，成了一种有益的约束：应用用起来原生而统一，也无需从零打造一套自定义设计系统。
把细节做好仍然花了好几轮。控件必须在不断变化的摄像头背景上、在竖屏和横屏状态下，以及在Dynamic Island周围，都保持清晰易读、便于操作。
人的作用也在这里显现出来。Claude Code会写出你要求的任何代码，但它本身似乎并不具备品味或判断力。设计感、批判性的审视以及清晰的架构约束，都必须由人来提供。对于新手引导、设置菜单和导航这类常见却棘手的模式，做法是先借助一个可检索真实应用界面和流程的资料库，研究已上线的应用如何处理，然后再写提示词。
模拟器从未暴露的卡死问题
开发过程中，在iPhone上点击打开一份讲稿，应用就会完全卡死。而在模拟器里，同样的操作运行流畅，毫无延迟。
Claude Code最初的回应是猜测。其中一种推测把问题归咎于TextKit的同步布局渲染，但没有一种猜测解决了问题。扭转局面的是证据。Claude Code编写了一个自定义性能记录器，把它加入应用，并用devicectl从已连接的iPhone上取出运行日志。
日志让原因一目了然：提词器界面在51.1秒内被重新创建了11,645次。界面每次初始化时都会保存默认外观设置；这次保存使SwiftUI的一个数据查询失效，查询变化又重建了界面，而重建后的界面再次保存默认设置。打破这个循环后，卡死问题彻底消失。
这个经验很可能不只适用于这款应用。当AI智能体对一个bug反复给出错误解释时，不要再让它接着猜。让它在代码中加入有针对性的诊断日志，然后去看设备实际报告了什么。
▲ 诊断日志揪出的无尽重建循环
用测试发现被改坏的地方
随着功能增加，一处改动可能会悄悄破坏另一处。为防范这类回归问题，Claude Code生成了一套共25项的自动化UI测试，覆盖讲稿的创建、重命名、排序和显示调整。
事实证明，这套测试不可或缺。后来一次修改讲稿保存方式的改动，让删除和重命名流程中的13项测试同时失败，由此很容易就找到了根本原因。修复之后，25项测试再次全部通过。不过，测试全部通过并不能证明应用没有bug，涉及摄像头硬件、传感器或设备实际旋转的部分尤其如此。
通过App Store审核
要分发应用，需要加入Apple Developer Program，费用为每年$99。之后，Claude Code承担了大部分发布工作：制作发布版本，针对多种模拟屏幕尺寸生成营销截图，并起草产品介绍文字。
第一次提交因Guideline 2.1（Information Needed）被拒。苹果要求提供一段能实际运行的演示视频，并详细说明应用的使用方式及其依赖的外部组件，以便了解硬件权限和遥控功能。
上传这段演示视频时又碰了壁。屏幕录像是一个399MB的HEVC文件，对App Store Connect来说太大，编码格式也不被接受。Claude Code编写并运行了一条ffmpeg命令，把视频缩小并转换为广泛支持的视频格式H.264，文件随之降到7.4MB。苹果接受了这个文件，随后批准了1.0版本，应用正式上线。
| 阶段 | 结果 |
|---|---|
| 首次提交 | 因Guideline 2.1被拒，被要求提供演示视频和说明 |
| 上传演示视频 | 399MB的HEVC录像被拒收 |
| ffmpeg转换 | 7.4MB的H.264文件被接受 |
| 最终结果 | 1.0版本获批并上线 |
可以借鉴的做法
从这个项目可以看出，只要指挥它的人把需求定得具体，并在真机上严格测试，Claude Code就能大幅缩短从设计构想到正式软件之间的距离。如果想用自己的iPhone应用尝试同样的做法，可以从这里开始：
- 先搭建真机循环。让智能体用xcodebuild编译、用xcrun devicectl安装，使每次改动都落到真实的iPhone上。
- 直接在代码中使用苹果的标准组件进行设计；对于新手引导或设置这类复杂界面，先研究真实应用的流程，再写提示词。
- 当智能体对bug的判断屡屡落空时，让它加入诊断日志，并从设备上取出日志。
- 尽早编写自动化UI测试，这样在修改数据保存等共用逻辑时，回归问题能立刻暴露出来。
- 提交给App Review的演示视频要编码为H.264，并压缩到上传上限以下。
品味和最终判断仍由负责的人掌握。如果把AI编程智能体当作在紧密的构建与测试循环中协作的伙伴，而不是一键生成应用的工具，它似乎能帮助一个人把完整的原生应用发布到App Store。