夜雨聆风用 Codex 开发一个简单 iOS App：从 SwiftUI 界面到模拟器调试
核心问题：AI 能不能辅助 iOS 开发？｜实践产出：一个 SwiftUI 小 App 原型
图 1微信公众号横屏封面图：Codex + SwiftUI + 模拟器调试。
一、为什么选择“SwiftUI 小 App”作为第一站？
过去学习 iOS 开发，普通人最容易卡在三个地方：不知道从哪里开始建项目，不知道 SwiftUI 代码应该怎么拆，不知道 Xcode 报错到底在说什么。Codex 的价值并不是把开发者变成“只会按按钮的人”，而是把一个原本需要反复查文档、读错误、改代码的过程，压缩成“描述目标、生成最小版本、运行验证、继续迭代”的闭环。官方文档把 Codex 定位为可在 App、IDE、CLI 或云端使用的编码智能体；在本教程里，我们把它落到最具体的场景：做一个可以在模拟器中运行的 SwiftUI 小 App 原型。
本文不追求一次性做出能上架 App Store 的完整产品，而是追求可学习、可验证、可复用。你会看到 Codex 如何帮我们完成界面草图、SwiftUI 状态、按钮交互、Xcode 编译、模拟器调试与错误修复。最后得到的原型叫 HabitFlow，是一个“每日习惯计数器”：它显示今日目标、已完成次数、进度条、加一按钮和重置按钮。这个小 App 足够简单，却覆盖了 iOS 入门开发中最核心的闭环。
答案先放在前面：AI 可以辅助 iOS 开发，但它更像一个会读项目、会写代码、会解释错误、会执行局部改动的协作伙伴，而不是完全替代你的工程负责人。你仍然需要判断需求是否合理、代码是否可维护、界面是否符合产品目标，以及每次修改是否通过真实运行验证。
图 2Codex 辅助 iOS 开发的完整闭环：需求、代码、运行、反馈、保存。
SwiftUI 适合入门，是因为它把界面和状态放在同一套声明式语法里。你不用一开始就理解 UIKit 的生命周期、Storyboard 的约束系统和复杂的委托模式。只要理解“状态改变，界面重新渲染”，就能做出按钮、文本、列表、卡片、进度条等常见界面。对于 Codex 来说，这也意味着任务边界更清晰：我们可以把生成目标限制在 ContentView.swift 里，让它先完成最小可运行版本，再逐步拆分组件。
本教程选择“习惯计数器”，原因很简单：它有真实产品意味，又不会被复杂后端拖住。一个能运行的原型至少包含四个元素：界面布局、状态变量、按钮交互、视觉反馈。只要这四个元素跑通，你就已经理解了 AI 辅助 iOS 开发的最小模式。后续你可以把它扩展成卡路里记录、游泳训练打卡、学习计时、HRV 压力记录等更贴近自己长期项目的应用。
Codex 官方文档提示，Codex 可以在项目目录中读取文件、运行命令并写入改动；也建议在任务前后使用 Git checkpoint，方便回退。把这条原则用于 iOS 项目，就意味着：不要让 Codex 一次性重写整个工程，而要让它先读项目结构，再只改一个文件，运行后再继续。
二、准备环境：Xcode、Codex 与一个干净工程
准备工作只需要三件事。第一，Mac 上安装 Xcode，并确认可以打开 iOS Simulator。第二，安装 Codex App、IDE 扩展或 CLI。官方快速开始页说明，Codex 可通过 App、IDE Extension、CLI 或云端使用；桌面 App 支持 macOS 与 Windows，CLI 支持 macOS、Windows 和 Linux。对 iOS 开发者来说，最自然的方式是 Xcode + Codex App 或 Xcode + 终端 CLI，因为 Xcode 负责工程与模拟器，Codex 负责读写代码和解释错误。
第三，创建一个最小 SwiftUI 工程。打开 Xcode，选择 File - New - Project，模板选择 iOS App，Product Name 填 HabitFlow，Interface 选择 SwiftUI，Language 选择 Swift。创建后先不要急着改代码，点击运行按钮，确认默认的 Hello World 可以在 iPhone 模拟器里启动。这个动作很重要，因为它把问题范围缩小了：如果默认工程都跑不起来，那问题在 Xcode、模拟器或开发者环境；如果默认工程能跑，后续报错才更可能来自我们的 SwiftUI 代码。
如果你使用 Codex CLI，可以在工程目录中运行 codex 并登录。官方 CLI 页面说明，Codex CLI 是本地终端里的编码智能体，可以读取、修改并运行所选目录中的代码。对于初学者，我建议先让 Codex 只解释项目结构，再让它生成代码；不要一上来就要求它“做一个完整 App”。
# 在工程目录中启动 Codex CLI（示例） cd ~/Developer/HabitFlow codex # 第一次运行会提示登录：可使用 ChatGPT 账号或 OpenAI API key。
下面这个选择表可以帮助你决定用哪种 Codex 入口。
入口 | 适合场景 | 优点 | 注意事项 |
Codex App | 跨项目、并行线程、审查改动 | 界面集中，适合管理多个任务 | 仍要人工审查 diff |
IDE 扩展 | 在编辑器中选中文件或片段 | 上下文自动带入，适合局部修改 | Xcode 原生支持有限，常与 VS Code 辅助使用 |
CLI | 终端、脚本、工程目录内开发 | 本地读写文件，适合开发者 | 需理解命令行与 Git |
Cloud | 远程仓库、并行任务 | 适合 GitHub 代码库与异步任务 | iOS 模拟器调试仍更适合本机 |
三、第一条 Prompt：先让 Codex 理解项目
很多人使用 AI 写代码失败，不是因为模型不会写，而是因为任务描述太模糊。对 Codex 来说，好的 Prompt 应该包含背景、目标、限制和验证方式。官方提示词文档也强调，Codex 的效果取决于你的指令质量；当它可以验证自己的工作时，输出质量会更高；复杂任务也更适合拆成更小的步骤。
在我们的工程中，第一条 Prompt 不应该是“帮我做一个 App”，而应该是“请阅读当前 SwiftUI 工程结构，告诉我关键文件作用，并提出一个只修改 ContentView.swift 的最小实现计划”。这样做有两个好处：第一，让 Codex 先建立上下文；第二，让它给出计划，你可以审查计划是否安全。
你可以直接复制下面这条 Prompt。它的重点是限制改动范围，不允许引入第三方库，并要求提供验证方式。
图 3高质量 Prompt 的四段式结构：背景、目标、限制、验证。
我正在学习 iOS SwiftUI 开发，当前目录是一个 Xcode 新建的 iOS App 工程，项目名 HabitFlow。 请先阅读项目结构，说明 HabitFlowApp.swift、ContentView.swift、Assets.xcassets 分别负责什么。 接着给出一个最小实现计划：只修改 ContentView.swift，不引入第三方库，做一个“每日习惯计数器”原型。 功能包括：标题、今日目标、已完成次数、进度条、+1 按钮、重置按钮。 请先不要修改文件，先输出计划和你准备改动的 SwiftUI 组件。
如果 Codex 的计划里出现“新建很多文件”“引入数据库”“接入网络服务”，你应该把它拉回最小范围。初学阶段最重要的是跑通闭环，不是堆功能。你可以继续追问：“请把第一版控制在 100 行以内，只用 @State，不用 AppStorage，不做数据持久化。”这样能显著降低错误概率。
当你确认计划合理后，再发送第二条 Prompt，让 Codex 实施第一版代码。这个过程体现了 AI 辅助开发的核心方法：先计划，再执行；先小步，再迭代；先可运行，再美化。
四、让 Codex 生成第一版 ContentView.swift
第二条 Prompt 可以要求 Codex 直接修改 ContentView.swift。注意，我们仍然保留限制条件：只修改一个文件、使用 SwiftUI、不要引入外部依赖、代码要能在 iPhone 模拟器里运行。这样的任务非常适合 Codex，因为它可以读当前文件、替换内容，并给出修改摘要。
下面是一版可以作为目标的 SwiftUI 代码。你不一定需要手动复制它，可以让 Codex 生成；我把它放在文章里，是为了让你理解最终原型由哪些部分组成。
import SwiftUI struct ContentView: View { @State private var completedCount: Int = 3 private let totalGoal: Int = 5 private var progress: Double { Double(completedCount) / Double(totalGoal) } var body: some View { ZStack { LinearGradient( colors: [Color.blue.opacity(0.20), Color.indigo.opacity(0.10)], startPoint: .topLeading, endPoint: .bottomTrailing ) .ignoresSafeArea() VStack(spacing: 24) { Text("HabitFlow") .font(.largeTitle.bold()) VStack(spacing: 16) { Text("今日完成") .font(.headline) .foregroundStyle(.secondary) Text("\(completedCount) / \(totalGoal)") .font(.system(size: 56, weight: .bold, design: .rounded)) ProgressView(value: progress) .tint(.blue) Text(progress >= 1 ? "目标达成，继续保持！" : "再完成一次，离目标更近。") .font(.subheadline) .foregroundStyle(.secondary) } .padding(28) .background(.white.opacity(0.86)) .clipShape(RoundedRectangle(cornerRadius: 28)) .shadow(radius: 12, y: 8) Button("完成一次 +1") { if completedCount < totalGoal { completedCount += 1 } } .buttonStyle(.borderedProminent) Button("重置") { completedCount = 0 } .buttonStyle(.bordered) } .padding() } } } #Preview { ContentView() }
这段代码虽然短，但已经包含 SwiftUI 的几个关键知识点：@State 负责本地状态，progress 负责把完成次数转换为进度，ZStack 用于背景，VStack 用于纵向布局，ProgressView 用于显示进度，Button 用于触发状态变化。更重要的是，它没有引入数据库、网络或复杂架构，适合作为初学者的第一个可运行原型。
这里也能看出 Codex 的优势：它可以在几秒钟内把需求转成代码，并帮你解释每个组件的作用。但你不能因为代码看起来完整就停止验证。iOS 开发的真相是：能编译、能预览、能在模拟器里点按钮，才算真正完成第一轮。
图 4HabitFlow 原型：卡片、进度条、按钮和状态反馈构成最小 App。
五、Xcode 验证：Build、Preview、Simulator
第一轮验证建议分三步。第一步是 Build。点击 Xcode 顶部的运行按钮或使用 Command + B，确认工程可以编译。Build 通过只能说明语法和依赖没有明显问题，不代表界面一定好看，也不代表交互一定正确。
第二步是 Preview。打开 ContentView.swift，查看右侧 SwiftUI Preview。如果预览不刷新，可以点击 Resume；如果依旧失败，先阅读错误信息，不要盲目重启。Preview 常见问题包括：宏语法不兼容、View 名称不一致、代码中引用了不存在的组件。
第三步是 Simulator。选择 iPhone 15 或其他模拟器，点击运行。启动后点击“完成一次 +1”，观察数字是否从 3/5 变成 4/5，再点击重置，观察是否回到 0/5。这个动作看似简单，却验证了状态绑定、按钮事件、进度条刷新和界面布局。
图 5在 Xcode 中同时关注文件结构、SwiftUI 代码、Preview 与模拟器运行。
我建议你把验证结果也告诉 Codex，而不是只在成功时继续。如果 Build 成功但界面不理想，可以说：“功能已跑通，但按钮太小，卡片层次不明显，请只优化 UI，不改变状态逻辑。”如果 Preview 报错，则复制完整错误日志，不要只说“报错了”。
六、出现报错时，怎样让 Codex 修复？
初学 iOS 开发几乎一定会遇到报错。AI 辅助开发最实用的地方，不是“永远不犯错”，而是“犯错后能快速定位”。你需要做的是把 Xcode 的错误信息、相关代码片段、你的预期行为一起交给 Codex。不要只发一句“为什么运行不了”，这会让它猜测太多。
比如 Xcode 提示 Cannot find HabitSummaryCard in scope，通常说明代码引用了一个不存在的组件。你可以让 Codex 做最小修复：要么把组件补上，要么把引用改回普通 VStack。关键是要求它解释原因，并说明验证方式。
图 6调试闭环：复制错误日志，要求最小修复，再重新 Build 和 Simulator 验证。
Xcode 报错：Cannot find HabitSummaryCard in scope。 请根据当前 ContentView.swift 做最小修复： 1. 不要重写整个文件； 2. 不要新增第三方依赖； 3. 解释这个错误为什么发生； 4. 给出修复后的关键代码； 5. 告诉我重新验证时应该看哪三个结果。
这种 Prompt 的价值在于把 Codex 从“自由创作”限制到“工程修复”。它不会为了修复一个小错误而重写整个 App，也不会引入新的复杂度。对初学者而言，这种修复模式比一次性生成完整项目更重要，因为真实开发大多数时间都花在小问题的定位和修补上。
如果 Codex 给出的修复仍然失败，你可以继续追加：“这是新的错误日志，请比较上一次改动，只修改导致该错误的最小位置。”在多轮调试中，记得每次都保存可运行版本。官方文档也建议在 Codex 修改代码前后使用 Git checkpoint，原因正是为了随时回退。
七、把原型升级一步：从能用到好用
第一版跑通后，可以让 Codex 做一轮 UI 优化，但仍然要保持边界。你可以要求它保持功能不变，只调整视觉层次：背景渐变、卡片圆角、按钮样式、字体大小、间距和提示文案。这个阶段非常适合用“截图 + 描述”的方式工作：把模拟器截图给 Codex，告诉它哪里不满意，例如“卡片太靠上”“按钮层级不明显”“文字对比度不足”。
需要注意的是，UI 优化也要验证。SwiftUI 很容易因为不同屏幕尺寸、动态字体、深色模式而出现布局问题。因此你可以让 Codex 增加简单的 Preview 组合，例如预览 iPhone SE 和 iPhone 15 Pro 两种尺寸；或者要求它解释哪些参数控制间距、圆角和阴影，方便你手动微调。
如果要加入数据持久化，下一步可以把 @State 升级为 @AppStorage。这样完成次数会保存在本地，即使关闭 App 再打开也不会丢失。这个升级只需要几行代码，但它引入了新的概念，所以应该作为第二阶段任务，而不是第一版就加入。
// 第二阶段可选：用 AppStorage 保存完成次数 @AppStorage("completedCount") private var completedCount: Int = 0 // 这样 App 重启后，completedCount 仍然保留。
除了持久化，还可以继续扩展为“多习惯列表”“每日提醒”“统计图表”“HealthKit 数据读取”。但扩展前必须问自己一个问题：当前最小版本是否已经稳定？AI 辅助开发最容易犯的错误，是在基础还不稳时不断加功能，最后项目变成一堆无法维护的代码。
一个成熟的迭代节奏应该是：每次只加一个功能，每次都说明验收标准，每次都在模拟器里验证，每次都提交 Git。Codex 可以加速这个过程，但不能替你做产品判断。
八、AI 能不能辅助 iOS 开发？我的结论
经过这个小项目，可以给出比较明确的结论：AI 可以辅助 iOS 开发，而且非常适合帮助普通人跨过“第一版跑起来”的门槛。它能帮你把需求翻译成 SwiftUI 代码，能解释 Xcode 报错，能给出调试步骤，能根据反馈做局部修改。对初学者来说，它相当于一位随时在旁边的助教。
但 AI 辅助不等于完全自动化。iOS 开发仍然有很多需要人工判断的部分：交互是否符合用户直觉，代码是否适合长期维护，命名是否清晰，状态管理是否会在功能增长后失控，App Store 审核所需的隐私说明是否准确。Codex 能提高速度，但你仍然是产品负责人和质量负责人。
最推荐的学习方法，是把 Codex 当作“工程化练习伙伴”。你先提出目标，它给计划；你审查计划，它改代码；你运行模拟器，它根据错误继续修复；你用 Git 保存可运行版本。这个循环跑得越多，你越能理解 SwiftUI，而不是只得到一份看不懂的代码。
如果你已经有自己的 App 想法，比如卡路里倒计时、游泳训练记录、HRV 压力分析、学习计划打卡，都可以从这个 HabitFlow 模板出发。先做一个只有一个页面的小原型，再逐步加入数据、图表、通知和云同步。不要急着追求完整，先追求可运行。
九、可直接复制的 Codex 任务清单
为了方便你实践，下面给出一组可以直接复制到 Codex 的任务清单。建议按顺序执行，不要一次性全部发送。
□ 阅读当前 Xcode SwiftUI 工程，解释关键文件作用，不修改代码。
□ 只修改 ContentView.swift，生成一个 HabitFlow 习惯计数器最小版本。
□ 解释 @State、ProgressView、Button 在这段代码中的作用。
□ 根据 Xcode 报错做最小修复，不重写整个文件。
□ 保持功能不变，优化界面层次和按钮样式。
□ 加入 @AppStorage 保存完成次数，并说明如何验证。
□ 生成一份 README，写明运行环境、功能说明、验证步骤和后续计划。
十、参考资料
OpenAI Developers：Codex Quickstart。官方说明 Codex 可在 App、IDE、CLI 或云端使用，并包含安装、登录、选择项目、发送第一条消息等流程。
OpenAI Developers：Codex App。官方说明 Codex App 是面向 Codex 线程的桌面工作台，支持 worktree、Git、自动化与并行线程。
OpenAI Developers：Codex CLI。官方说明 CLI 可以在本地终端中读取、修改并运行所选目录中的代码。
OpenAI Developers：Codex Prompting。官方强调 Prompt 应包含可验证步骤，复杂任务应拆分为小任务，并给出上下文。
