Felix
返回微信

AI 不只是写代码了——我用 Codex 做完了一个 iOS App

以前我把 AI 当成「帮我写代码的工具」。

直到最近用 Codex 做完了 Songless 的 iOS 版本——一个猜歌游戏的 iOS App，从写第一行 Swift 到点 「Submit for Review」全程让 AI 跑了一遍，我才发现：AI 早就不只是这个角色了。

写这篇不是为了介绍产品。

真正让我想记下来的是——这次开发方式变了。

以前做一个 iOS App，我大概要在十几个工具之间来回切：拆需求、写 SwiftUI、调接口、Xcode 跑构建、配签名、做截图、填 App Store Connect 几十个表单、上传预览图、提交审核……每一步都是一个独立的环境，光是切换上下文就累。

说白了，写代码可能是每天花时间最少的事。

这次不一样。

我把 Codex 当成了一个长期在线的开发搭档。它不只是写代码——它读已有项目、拆任务、写计划、改 SwiftUI、修 API、跑构建、定位 Xcode 报错、整理 App Store 截图，最后还通过 Computer Use 操控浏览器，把 App Store Connect 里的资料填好、预览图传完、审核提交了。

我大概是第一次有这种感觉：

AI 已经不是代码生成器了，它在跨工具完成任务。

这篇就把整个过程记下来——我是怎么用 AI 走完一个 iOS App 从开发到提交审核的全流程。

一、我没让 AI「直接做一个 App」

这是这次最重要的一个判断。

我没有一上来就甩一句：「帮我做一个 iOS App。」

这种提示词太大，AI 会立刻开始自由发挥，最后给你一堆看起来完整、其实跑不起来的代码。

说白了，越是高自由度的提示词，AI 越容易「顺手」补功能、建抽象、改一堆暂时不该改的东西。

我给 Codex 的方式更像工程交接：

  • 网站项目在哪里
  • iOS 项目在哪里
  • 第一版只做什么
  • 明确不做什么
  • 哪些 API 复用
  • 每一步怎么验证

比如第一阶段，我明确告诉它：先做 guest-only MVP，不做登录、不做支付、不做 profile，不重写所有网页功能。

目标只有四件事：稳定请求 Daily 数据、能播放试听、能搜索歌曲、能提交猜测并保存游客进度。

就这四件事。其他全部不做。

AI 最容易犯的错不是写不出代码，是把范围做大。你越不给边界，它越容易「顺手」补功能。

果然，AI 不是越自由越好。

所以我得出的第一条经验：

不要让 AI 先写代码，先让它帮你缩小范围。

二、几个 skill 和插件，组成了一条流水线

这次最关键的不是某一个模型多强，而是几个 skill 和插件组合起来形成了一套工作流。

说白了，单一工具搞不定，组合才行——就像做菜，不是买一把瑞士军刀就能搞定所有菜，切菜刀、炒菜锅、蒸锅各司其职才有用。

Superpowers：给 AI 上纪律

我用 Superpowers 里的几个 skill 来约束开发过程。

writing-plans 用来先写计划。每次进入比较大的任务，比如 iOS 结果分享、排行榜、游客身份同步，我都会让 Codex 先形成计划，而不是直接改代码。

test-driven-development 用在纯逻辑部分。比如分享 payload、challenge API 参数、结果文本这些，不需要启动完整 App 也能先写 smoke test 验证。

systematic-debugging 用在报错时。Xcode 构建失败、接口返回不符合预期、签名出问题，不让 AI 猜原因，先看错误、找证据、再改。

verification-before-completion 用在收尾。每次 Codex 说「完成」之前，都要先跑验证命令——xcodebuild，或者独立的 Swift smoke test。

这些 skill 的价值不是让 AI 更「聪明」，而是让 AI 更守纪律。

Build iOS Apps：真懂 iOS 工程环境

iOS 开发最麻烦的不只是 SwiftUI。

还有 Xcode project、scheme、simulator、build setting、signing、archive、运行调试……

Build iOS Apps 插件让 Codex 真的像一个懂 iOS 工程环境的助手，能围绕 Xcode 项目做构建、运行、检查 simulator 状态，而不是只会「我给你写一段 Swift 代码」。

Songless iOS 的很多验证不是靠肉眼看代码，是真的跑：

DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer \
xcodebuild -project Songless.xcodeproj \
-scheme Songless \
-destination 'generic/platform=iOS Simulator' build

这条命令反复出现。

iOS 开发里，代码「看起来对」没意义，能构建才有意义。

Computer Use：让 AI 自己点按钮

Computer Use 是这次最有意思的部分。

App 开发到最后一定会撞上一大堆浏览器后台操作：开发者账号、App Store Connect、App 信息、隐私选项、版本资料、截图上传、提交审核。

这些事很难纯代码完成，但又极其机械。

我让 Codex 通过 Computer Use 操控浏览器。它能看页面、点按钮、填表单、上传截图、检查哪些字段还没填。

以前这种事必须我自己不停切页面，现在交给 AI 跑，我只负责关键判断。

这是这次感受最明显的变化：

AI 不再只是代码生成器，它在跨工具完成任务。

Browser：眼睛比代码靠谱

Browser 插件主要用于本地页面和网页流程验证。

有些问题不能靠读代码——页面到底打不打得开、截图正不正常、表单流程符不符合预期。Browser 让 Codex 直接打开本地或线上页面看结果，比「我猜它应该可以」靠谱多了。

三、我的实际工作流（5 步）

这次逐渐形成了一套固定流程。

第一步，让 Codex 读代码。 我会明确要求它先看相关文件——网站 API、SwiftUI ViewModel、Xcode 项目配置。不要凭空写。

第二步，让它写计划。 计划里必须包括目标、范围、修改文件、验证方式。尤其要写清楚不做什么。

第三步，小步执行。 一次只做一个闭环。先接 Daily API，再做音频播放，再做搜索，再做提交。不要一次把登录、排行榜、分享都塞进去。

第四步，跑验证。 能用 smoke test 的就写 smoke test。必须构建的就跑 xcodebuild。失败就继续让 Codex 看错误，不要跳过。

第五步，整理上下文。 每做完一个阶段，让 Codex 生成一份 handoff 文档：当前状态、已完成内容、风险、下一步提示词。这样换新会话也不会丢上下文。

这一步特别有用。

AI 开发最大的问题之一是上下文会断，handoff 文档相当于给未来的自己和未来的 AI 留交接单。

四、好用的提示词，长这样

我发现好用的提示词通常不是「帮我实现 X」，而是更工程化：

  • 「先阅读这些文件，不要修改代码。告诉我现有逻辑是什么，风险在哪里。」
  • 「只做 guest-only MVP，不要引入登录、支付、profile。」
  • 「每个改动都要能解释为什么和本任务有关。」
  • 「完成后跑 xcodebuild，失败就根据错误继续修。」
  • 「不要重构无关代码。」
  • 「把这次任务整理成新会话可继续的 handoff。」

这些提示词的核心都是——限制 AI 的自由度。

工程任务里，AI 越清楚边界，产出越稳定。

五、真正麻烦的部分，从来不在 Swift 里

写到这其实只完成了一半。

iOS App 真正麻烦的部分不在 Swift，在代码之外。注册账号、配签名、准备素材、填元数据、提交审核——这些事单独都不难，但加在一起足够让一个独立开发者卡半个月。

独立开发者本来就是一个人扮演一整家公司：既是 CTO，又是 SEO 专员，还得兼任设计师、运营、客服、财务。

说白了，写代码可能是每天花时间最少的事（扎心了）。

这次我刻意把这条线也交给 Codex 走了一遍，顺便摸清楚它的能力边界。

AI 接不了的几步

先说不能做的，省得有人误以为全自动。

Apple ID 双因素验证、支付信息、税务表格，这三件事 Computer Use 帮不了你。

验证码要进你手机、信用卡要你本人确认、W-8BEN（中国大陆开发者填的税表）需要你的真实身份信息。

我的做法：把整个上架流程拆成「AI 可执行」和「我必须在场」两类，前者完全交出去，后者集中在一个时间段里手动处理完，不来回切换。

开发者账号

$99/年。

个人账号当天到几天不等，公司账号要先申请 D-U-N-S 编号，慢的话两周。

如果只是想验证一个想法，个人账号够用。但 App 上架后显示的「开发者名称」是你的本名（中国大陆开发者会显示拼音），介意的话一开始就走公司账号。

注册期间不要干等。Bundle ID 命名、App 图标、截图脚本这些可以并行准备。

Bundle ID 一旦在 App Store Connect 创建就不能改，命名前想清楚（别问我怎么知道的，哈哈哈哈）。

签名与证书

Codex 在这块帮了不少忙，但前提是你用 Automatic Signing。

手动管理 Distribution Certificate 和 Provisioning Profile 仍然是个雷区。常见报错比如 「No signing certificate found」、「Provisioning profile doesn’t include device」——让 Codex 看完整 Xcode 错误日志比让它「猜怎么修」靠谱得多。

经验：第一次配签名时把整个过程录下来，或者让 Codex 写成 handoff，下次换电脑、换证书、加测试设备都用得上。

隐私清单（最容易漏的硬要求）

2024 年起 Apple 强制要求 PrivacyInfo.xcprivacy。

你的 App 哪怕只发了个 HTTP 请求、用了 UserDefaults，都要在这个文件里声明 API 用途。第三方 SDK 也要各自带自己的清单。

这一步 Codex 可以直接帮你扫代码、生成对应条目，比自己对照 Apple 的 API 列表快得多。

但提交前一定要人工核对一遍，错填或漏填会直接被卡审。

同样的还有 App Privacy（隐私营养标签）和 App Tracking Transparency 弹窗——这些是在 App Store Connect 里填的，不是代码里的。

元数据和素材

App Store Connect 里那些输入框，每个都有硬规格：

  • App 名字 30 字符，副标题 30 字符，关键词 100 字符（逗号分隔，不含空格）
  • 描述 4000 字符，但前 3 行最重要——用户在商店看到的就是那 3 行
  • 1024×1024 营销图标不能有 alpha 通道、不能预先圆角
  • 截图：6.7” iPhone 必传，其他尺寸 Apple 会自动适配
  • 隐私政策 URL 必填——没有网站的话，至少要有一个能公开访问的页面

Computer Use 在这一步效率最高。我把所有素材和文案先在本地整理好，让 Codex 按顺序填，缺什么它会停下来问。

TestFlight 是性价比最高的一步

很多独立开发者跳过 TestFlight 直接提交审核，我建议别跳。

内部测试不需要审核，传完构建几分钟就能装到自己手机上。外部测试要过一次 Beta App Review，半天到一天，但能让你在正式提交前先发现 crash、权限弹窗时机不对、后台播放被系统杀掉这些只有真机才暴露的问题。

Songless 这种音乐播放 App，我在 TestFlight 阶段就发现了来电打断后音频不恢复的 bug。

如果直接提交审核，大概率被拒。

审核拒绝里 AI 类项目特别容易踩的

按发生概率排：

Guideline 4.2 最小功能性：AI 容易生成「看起来像 demo」的 App。审核员看到的是功能完整度，不是代码质量。提交前用游客身份完整玩一遍，能玩通才算 MVP。

Guideline 2.1 不完整元数据：缺 demo 账号、缺截图说明、缺联系方式。如果你的 App 有登录，哪怕只是 guest 模式，也建议在审核备注里写清楚审核员怎么进入主要功能。

Guideline 5.1.1 数据收集：请求了权限但没说为什么，或者 Info.plist 里的描述写得太敷衍（「App needs camera」 这种会被拒）。

Sign in with Apple 规则：如果你接了 Google/微信/Facebook 登录，必须同时提供 Apple 登录。这条独立开发者最常忘。

提交之后

审核时间现在普遍 24-48 小时，节假日前后会变长。

被拒了别慌。Resolution Center 里 Apple 会告诉你违反了哪条 Guideline、附上截图。回复时态度坦诚、附补充说明或新截图，大多数问题一次能过。

如果是元数据问题（描述、关键词），改完直接 Resubmit，不需要重新打包构建。如果是代码问题，改完重新 Archive 上传新 build。

加急审核（Expedited Review）一年大约 2 次额度，留着给真正紧急的情况——已上架版本出了严重 bug 要快速修复那种。

六、这次最大的变化

以前我做一个 App，很多精力花在切换上下文上。

一会儿写 SwiftUI，一会儿看网页 API，一会儿查 Xcode 报错，一会儿处理签名，一会儿准备截图，一会儿打开 App Store Connect 填资料……

这次 Codex 把这些碎片串起来了。

它能读项目上下文，也能执行终端命令；能写 Swift，也能跑构建；能总结计划，也能操作浏览器；能做代码任务，也能做提交审核前那些机械流程。

这不代表开发者不重要了。

相反，开发者的工作更像是在定义边界、判断优先级、控制质量。

哪些功能第一版不做，哪些地方必须验证，哪些实现过度设计，哪些报错不能忽略——这些仍然需要人判断。

但目标明确以后，Codex 可以承担大量执行工作。

写在最后

这次让我对 AI 编程的理解变了。

以前我把 AI 当成「帮我写代码的工具」。

现在更像是一个能跨代码、终端、浏览器、文档和后台系统执行任务的开发搭档。

真正有效的方式不是让 AI 一次性生成一个完整 App，而是把它放进一套工程流程里：

  • 先限定范围，再写计划
  • 先读代码，再动手
  • 先小步实现，再验证
  • 先修失败，再继续
  • 最后让它连 App Store Connect 这种非代码流程也一起处理

独立开发者最缺的通常不是想法，是把想法推进到上线的持续执行力。

这次最大的收获是：

AI 已经不只是能帮你写一个函数，它开始能帮你把一个产品从代码推进到提交审核。

果然，变化就变化，AI 时代的变化可能意味着我们能探索的又更多了一些。