AI Coding 5 个月，成功上架一个 iOS App｜从原型、代码到备案上架的全流程复盘总结

去年 12 月，我用 Cursor，开始做一个 iOS App，用来重温那些埋在微信读书里、划完就再没打开过的高亮书摘。

5 个月后，它正式上架到 App Store，取名「Booko」。

An image to describe post

从画产品原型、建 Xcode 项目，到配置 GitHub、定设计规范，最后注册域名、备案上架，这一路走下来，每一步都是我的第一次。

这些第一次，值得记下来，给所有想用 AI 写 App 的人做个参考。

更重要的是，当写代码已经变成不再稀缺的能力，我们该怎么让自己做出来的东西，不沦为没有灵魂的「AI Slop」（AI 生成垃圾）。

这两年 AI 进化得太快，每过半年，AI Coding 的门槛就大幅下降。这不只是说大模型能力在变强，也包括 Codex、Claude Code、Cursor 这些产品在设计和易用性上的进步，让写代码这件事，变得越来越简单。

甚至连一向封闭的微信读书，都开放了自己的 Skill。

我是这些变化的受益者。正是因为它们，我才能在过去半年里，做出一款设计还算精美、功能也算完整的 App。

一、源起

第一次想开发 Booko 这样的 App，是在 2023 年。当时我在想，为什么微信读书不能像 flomo 一样，把划线笔记做成一个能随时重温的小组件。

阅读时划的线，不该被埋没在微信读书、Apple 图书或 Kindle 里。划完的高亮笔记，跟自己的想法一样，应该重新被打开、被欣赏、被重温。

只是当时 AI 还停留在问答阶段，Cursor 和 Windsurf 都还没出现在我的视野里，我也没有信心和时间从头学 Swift 和 SwiftUI 来手写 App。

2024 年，我在 X 看到开发者 Randy 做了一款叫「笔记伴侣」的产品，这款产品的思路就是我想做的 App，而且我还参加了内测，可惜 UI 不是我想要的风格。

而 UI 恰恰是我最在意的，我一直关注着 Craft 和谜底黑胶这两个设计精美的 App，也希望自己能做出一个独具匠心的产品。这个愿望像一颗种子，埋在心里。

直到 2025 年，Agent 和 AI Coding 突飞猛进。我不断刷到 Claude Code 和 Sonnet 的消息：它们不再是只会写几行代码的辅助工具，而是能像真实的工程师一样，理解整个项目、自己查文档、修 Bug，甚至直接搭出完整的 App 架构。

看到这种级别的代码能力，我觉得时机已到。

只是在 2025 年底，用 Claude Code 的门槛对我来说还很高：要学终端操作，还要买中转站的 API。所以到 12 月，我就先用门槛更低的 Cursor 来画原型。

二、成形

1、技术选型

用 Cursor 画的第一版原型是 HTML，在浏览器就能看，但要做成真正的 iOS App，绕不开 Xcode。刚上手时，必须先弄懂 2 件事：

怎么建项目。写 iOS App 不能随便建个空文件夹。得先在 Xcode 里建项目，生成目录和 .xcodeproj 文件，配好 Bundle Identifier 和 Team，再用 Cursor 打开写代码。
AI 是怎么修改文件的。代码文件就像 Markdown 笔记，存在 Finder 的文件夹里。AI 就是对着文件夹里的文件操作。如果把 Cursor 比作 Obsidian，代码文件就像是一篇篇笔记。只要你用过 Obsidian 这个应用，就能很快理解 Cursor 和 Codex 是怎么在这些本地文件夹里修改代码的。

弄懂这些后，更重要的决定是：用哪种编程语言？做不做账号体系？接不接后端？

说到前端和后端，我也是近两年才分清：

前端是用户看得见、能直接操作的部分，比如浏览器里的网页、手机 App 的界面。它负责展示内容、响应点击、输入等操作，并把请求发送给后端。
后端是支撑产品运行的系统，用户通常看不见。它一般包括服务器、数据库、鉴权和业务逻辑：服务器负责运行代码，数据库负责保存数据，鉴权负责判断用户身份和权限，业务逻辑负责处理具体规则，比如登录、保存内容、创建订单、权限判断等。

考虑到 Booko 只有我一个人开发，短期也不做安卓。所以我一开始就决定：不做账号体系，不接后端，写原生的 iOS App，直接用 Swift 和 SwiftUI，以及数据全走本地，加上 iCloud 同步。

虽然不做后端，但我也不敢随便让 AI 写代码，怕踩坑。所以元旦假期，我花了 400 多，购买了纯想的独立开发课程——VibeCoding 强制爱计划（如果你也准备购买这门课程，可以用我的邀请码：98SK3G获得 9 折优惠，我也会因此赚取到分销佣金）

这门课程一共 6 节，一开始我只快速刷了 3 节课，记录下了 3 个关键点：GitHub、MVVM 架构和设计规范。

我先解决的是 GitHub 代码管理的问题。以前怕改坏代码，我只敢在本地不断复制新的文件夹。后来在 GitHub 建好私人仓库，再让 AI 帮忙指导连上本地代码文件夹后，每次改动提交到 GitHub 都有记录，随时能回退，不需要再手动备份了。

因为只有我一个人开发，我的代码就直接推到 Main 主分支，只有在前期尝试各种 UI 效果时，用过新建分支做实验，分支的改动对代码主体没有影响。

如果你对 Git 和 GitHub 都不太了解也没有关系，只要给 Codex 和 Claude Code 配好权限，它们就能自动帮你提交代码、切分支，可以边用边了解。

配置好了 GitHub，加上明确了用 Swift 和 SwiftUI 做原生 App，并以 MVVM 架构打底，技术方案确定好了。

2、界面布局

技术方案定好后，接下来就是做界面布局。

界面布局是由产品的定位推导出来的。 Booko 的核心，是一张精美的笔记卡片，能把划线漂亮地呈现出来，也能对应回每本书。此外还需要一个管理设置的地方。于是「书架」、「浏览」和「我」这 3 个 Tab 就出现了。

最关键的动作是「导入」。我把它放在全局，常驻在 Tab 上。就像 X 和即刻的发帖入口一样，随时都能用。

在书架和浏览之间，还需要一个过渡：书籍详情页。点开书架上的一本书，进入书籍笔记列表；再点某条笔记，就跳到浏览页去重温。

An image to describe post

和 flomo 一样，这些笔记也该在小组件里呈现。于是我加了小组件，并且借鉴 Cubox，支持在小组件上直接随机跳转，以及分享导出图片。

An image to describe post

3、UI 设计

把界面框架搭好不算难，真正磨人的是 UI 设计。

一开始，我不想用书籍封面，想用文件夹或卡片盒这些更新颖的设计。但它们一来难画，二来和「书」的关联太弱。

绕了一大圈，还是回到了封面。我尝试过立体封面、带书脊的封面，折腾到最后发现大道至简。最原始的平面封面，加一点圆角、阴影和描边就足够好。

An image to describe post

浏览页也重构了好几版：锯齿邮票、拟物、撞色……但要么看久了会腻，要么大片色彩和导航栏冲突严重。最后我学 Craft，支持上传背景图和切换字体，默认提供两种样式。它就像皮肤，具备扩展性，以后可以慢慢加。

An image to describe post

兜兜转转，界面回到了最简单的样子，但是我也藏了一些细节：

书架封面会自动取色。如果封面比例不匹配，空白处会用相近的颜色来填补；

点进书籍详情页，整个页面会自动适配这本书的主色调。这个设计来自谜底黑胶，后来 iOS 26.4 的 Apple Music 也做了同样的处理。

定好这 3 个核心页面的设计，加上核心色、描边和阴影等细节，整理成设计规范，App 就算完成了 80%。剩下的 20%，就是把功能实现好。

做 Booko 时我发现，想让 AI 写的 App 好看，不要变成烂大街的 AI 蓝紫色，最省心的做法是：配色尽量简单，直接用 SwiftUI 原生组件和 SF Symbols 图标。

我走过一段弯路。一开始想做液态玻璃效果，让 AI 自己写代码画，怎么调都不对。后来才发现，Booko 里这种玻璃感不需要自己画复杂效果，直接用系统的 SwiftUI Material，再加很轻的描边、阴影和高光，就已经足够接近想要的质感。

但怎么让 AI 准确调用原生组件？关键是描述准确，对它「说行话」。

你要知道什么是 Sheet，什么是 Menu，什么是 ToolBar 等等。

只有叫对名字，AI 才能听懂需求。这些在 Apple 的 Human Interface Guidelines 里有写。小红书上也有不少分享专业术语的帖子，刷到了可以收藏备用。

An image to describe post

4、停滞

到了 2 月，Booko 的 UI 原型基本定好。但从春节到 3 月上旬，自己测的时候，总觉得满眼都是 Bug。比如，想让底部 Tab 和顶部返回按钮跟着主题色切换，怎么也写不对。

技术卡壳，加上自我怀疑：这东西有商业空间吗？受众会不会太窄？我停下 AI Coding，停滞了一个多月。

3 月，我看陈其钢的《隐者山河》，读《源泉》，又和 Claude 聊自己的思维习惯。我慢慢意识到：我总是把欣赏的目光留给外部产品，对自己的东西却带着严厉的审判。而且每解锁一个成就，就立马奔向下一个。

意识到这点后，我先把严厉的自我审查放一边。既然第一版的目的只是把想法做出来，那就先别管后续的商业化问题，先做出来才能看到后续增长的结果。

于是，重新让 Claude Code 直接参考成熟产品的代码，把最影响用户体验的问题慢慢修好。（到这个阶段，我开始用 Claude Code 的桌面 GUI，用 Opus 4.5 解决了很多之前解决不了的 UI 细节问题。）

刚好那阵子，我在小红书和公众号发了几张截图，都有上千浏览，不少人求内测，真实的用户反馈，推着我继续往前走。

到了 3 月底，产品基本成形，功能也能正常用了。但我依然谨慎，对数据存储和 iCloud 同步不放心，没敢直接开启内测。

三、上架

1、优化数据架构

3 月底到 4 月初，我做了很多测试，不断让 AI 扮演资深数据架构师，假设有 10 万用户，一遍遍地优化数据存储。改到最后，代码架构和最初设定的 MVVM 已经不太一样了，但 AI 告诉我这是更加健壮的架构。

之后我去注册了 Apple 个人开发者账号。提前在小红书做过功课：

Apple ID 姓名要和真实姓名一致（可以用拼音）
注册时不要更换设备。

第二天，账号就顺利通过了审核。

接着是构建版本，邀请好友内测。整个 4 月，我也是有空就让 AI 继续检查数据和 iCloud 的稳定性，并做好了 App Store 的配图。

2、上架和备案

五一假期，我开始准备上架。先让 AI 检查审核可能碰到的问题，用 Notion AI 写好隐私政策和服务条款，最后把 CloudKit 从开发环境推到生产环境。

5 月 8 日，我正式把 Booko 提交给 Apple 审核，出乎意料，第二天就通过了。但是国区 App Store 卡了审核，要求提供 ICP 备案。

上架前我反复跟 AI 确认过，Booko 是本地应用，没有账号体系，也不做分发，理应不用备案。但是 Apple 审核一刀切，没有备案就不让直接上架。

我去小红书看经验贴，去申诉豁免也得花好几天的时间，为了一劳永逸，决定直接申请备案。

去阿里云买了域名和小型服务器，花了不到 150 块。

填写备案信息时绕了点弯路：我看到需要绑定域名，就以为得先给官网备案，才能给 App 备案。刚好那几天网站备案系统出问题，卡了两三天。后来联系客服才弄明白，App 备案填的域名不需要能访问，直接提交就行。

这里有个小经验：不管是提交 App Store 还是 ICP 备案，我都让 AI 帮我写了一段防卡审的备注。重点强调 Booko 没有账号体系、纯本地运行、无内容分发，数据仅通过 iCloud 同步，开发者无法获取。

这招似乎是管用的，App Store 和 ICP 备案都一次性顺利通过了。

3、意外之喜

虽然 Booko 拿到 ICP 备案后，就顺利在国区 App Store 上架了，但我没有急着宣传。

因为不管是从微信读书，还是从苹果图书，导入高亮划线到 Booko，书籍封面都是缺失的，需要用户手动上传才行。

这对我来说，产品不能算完整，体验很割裂。

原计划是接入外部 API 来抓取封面。没想到 5 月，微信读书突然开放了官方 Skill。我立刻用它做了一个网页版的 Booko Board，用户输入密钥就能拉取书籍和划线，体验非常顺畅。

随后的一周，我花了几个小时把微信读书 Skill 接入了 Booko。这样一来，手动传封面的问题终于解决了，Booko 的第一个完整形态也终于诞生了。

四、增长

我还没正经为 Booko 做过增长。目前只发了 4 篇小红书，同步到了公众号。

一来业余时间有限，二来我不想将就，发些粗糙的内容。

所以最近在研究，怎么快速给 Booko 做些好看的演示视频。为了做带壳演示，我把我之前收集的几个工具试了一遍，最后发现最好用的还是 Screen Studio。

简单对比一下这几个工具：

Screen Studio：录制和剪辑都很强。缺点是得用数据线把 iPhone 连到 Mac 录屏，然后再套壳剪辑。
Bezel：和 Screen Studio 一样要连数据线录制，没有必要单独用。
Rotato：能套壳，能做 3D 旋转效果，但不能分割编辑，定位不一样。
Matte：唯一能直接导入手机录屏并套壳的，背景有图案可选。虽然说在做 3D 效果，但目前的分割编辑功能和快捷键，还不如 Screen Studio 完整。

一句话总结：想边录边剪选 Screen Studio，想偷懒直接导入录屏选 Matte，想做 3D 效果选 Rotato。

在增长这条路上，还有很多要尝试的。等拿到阶段性结果，再来分享。