利用 Codex 快速开发 App,满足精细需求

十多年前，我就想过自己做一个 iOS App。

真正把它做出来，是最近的事。而且这次我几乎没有先去啃 Swift，也没有先看 Xcode 文档。我做的事情更简单：把需求说清楚，然后让 Codex 去把工程一点点搭起来。

需求从哪来

我之前已经做过一个网页版应用，用来管理我个人的藏书。功能本身没有问题，但它部署在 Cloudflare 的技术栈上，每次登录和鉴权都很麻烦，尤其在某些网络环境下，体验会非常差。我一时也没找到一个顺手的办法，把整套东西平滑迁回国内。

所以我换了一个思路：既然我真正需要的是一个自己随手就能用的工具，那不如直接做成 iPhone 上的 App。

这件事我其实想了很多年。过去一直没做，不是因为完全没需求，而是因为门槛太高。

第一，iOS 开发的资料太多，而且更新很快。你刚理解一套东西，新的写法可能又来了。第二，它对硬件有门槛。很多年前我想做的时候，连 MacBook 都没有，根本谈不上开始。

后来微信小程序出来，门槛确实低了很多。我曾经花了两天时间看文档，做过一个聚会时用来计分的小程序。功能是实现了，但我自己其实并不怎么参加聚会，身边玩这类游戏的朋友也没有稳定需求，所以那个东西只用了一两次，就自然停在那里了。

参加工作之后，我买了自己的 MacBook Pro。那时我重新冒出一个念头：要不要认真做一个 iOS App。

原因也很直接。市面上很多同类应用做得实在太差。要么广告多得离谱，要么开发者做着做着就跑路了，最后连自己的数据都拿不回来。最好的办法还是自己做一个。

现在和当年不一样的地方在于，AI 出现了。

这次我刚好订阅了 Pro 模型，token 额度也够，于是就想试试看：今天的 AI，到底能不能帮我把一个真正能用的 iOS 应用从零搭出来。

这次到底怎么做

AI 给我这种完全没接触过 iOS 开发的人一句最直接的建议，那就是先用官方工具把一个能跑起来的最小 App 做出来，然后再决定你到底是要自己慢慢学，还是先把产品做出来。到 2026 年，这条起步路线仍然很清楚：Mac、Xcode、Swift、SwiftUI。

我这次采取的模式很激进，也很省力：我负责提需求，具体实现基本都交给 Codex。

整个过程中，我没有逐行去读代码，但我会不断改需求、改边界、改架构方向。项目的结构也在这个过程中改了好几轮。最后出来的效果，我很满意。

更关键的是，我让它额外生成了一份写给初学者的说明文档，放在仓库根目录。那份文档不是给我抄代码用的，而是帮我理解整个工程到底是怎么搭起来的，文件放在哪里，为什么要这样组织，而不是那样组织。对于同样的需求，是否有其他的解决方案，为什么选择了现在这种。

借用我喜欢的一位公众号主，数字生命阿兹克的问题：要解决什么？最直接的路径是什么？从零设计会怎么做？

读完文档之后，我大概理解了这个仓库的框架，但没有沉到过细的技术细节里。

换句话说，这次最有价值的地方不是「AI 帮我写了代码」，而是它让我可以先把产品做出来，再反过来理解工程。

我给 Codex 的需求是怎么一步步收紧的

一开始，我给的要求并不复杂：根据已经上线的 Web App，读取 Home-library 仓库中的文件，在当前仓库里搭一个功能类似的 iOS 应用。不增加额外功能，只保留原来仓库已经有的能力。数据存储先用 iCloud 和 Apple 官方推荐的方式，因为这个应用最多就是两个人使用，不需要为了未来想象中的复杂场景，先把系统做得很重。

同时，我还要求它在根目录里维护 plan.md 和 log.md。前者写计划并实时更新，后者在完成一个小功能之后就记录本次修改。AI一开始的思路是本地优先，在本地文件中维护文件夹，作为数据来源。

但项目很快就进入第二轮。

我发现我并不想继续用 iCloud Drive 那种文件共享思路，于是我直接把要求改掉：我要换成 CloudKit 数据库，整个存储和同步逻辑都需要重写。另一位用户应该可以在同步仓库的界面里选择加入别人的仓库，输入我在应用里生成的一组账号密码，然后直接访问并修改同一个仓库。

这一步之后，我又继续把边界收紧。

历史记录要被转成新的 CloudKit 数据，保持数据干净。项目以后看起来应该像一开始就是现在这套数据结构，而不是背着一堆旧逻辑继续往前拖。书籍字段以后还可能继续改，甚至继续加字段，所以数据模型也得为这种变化留出空间。

到了更后面，需求已经变得非常具体：

1. 这个应用只服务一个家庭里对藏书的管理。
2. 主要使用设备是 iPhone。
3. 图书信息改成手动录入。
4. 不再做扫码获取 ISBN。
5. 不再做通过 ISBN 搜索图书。
6. 封面需要直接从 iPhone 上传。
7. 去掉 macOS 端，只保留 iPhone 版。

我后来回头看，真正起作用的不是我会不会写代码，而是我有没有把这些要求说到足够具体。需求越具体，Codex 给出来的结果就越像一个真正能用的产品，而不是一个「看上去差不多」的演示工程。

它最后交出来的东西，为什么让我满意

当应用真正跑在我自己手机上的那一刻，成就感非常强。

一方面，这是我很多年前就想做的事情。另一方面，我这次确实看到了另一种工作方式：我不需要先把所有技术细节都吃透，才有资格开始。我可以先把需求弄清楚，把边界讲明白，把一轮轮修改做作记录，然后再用文档反过来理解工程。

当然，坑还是有的。

第一，苹果开发者账号不是你付完钱就立刻能用。一般来说，付款之后还要再等一段时间，通常接近 24 小时。等审核通过，收到第二封邮件之后，相关能力才算真正启用。

第二，关于 iCloud 相关工程，这个项目一开始走的是最小开发结构，同步之类的能力也都直接走 iCloud，没有再额外搭一个后端。对于我当下这个两人使用的场景，这样做是够的，但它也意味着很多选择其实是 Apple 生态预先替你规定好的。

第三，实机测试这件事一定要早点做。把手头的 iPhone 升到最新版，用数据线和 Mac 连起来之后，就可以直接在自己的手机上测试。很多「感觉差不多了」的问题，只有到了真机上才会暴露出来。

最后还有一个很具体的小坑：从 App Store 安装应用的时候，Typeless 这个软件会和 Touch ID 产生冲突。所以平时要安装东西，记得先把 Typeless 退出。

最后

这次做完之后，我反而更确定了一件事：对很多个人工具来说，最稀缺的已经不是把代码敲出来，而是把需求说清楚。

只要需求足够具体，边界足够明确，AI 真的能把很多过去高门槛的事情，变成今天就可以落地的东西。