一、与前两个项目最大的不同

扩展和内容项目做完就能用，App 做完还要过一道门（第 14.3 节）。 这道门带来两个后果：发布节奏不由你定；前面每一步都得经得起回看。 所以 iOS 上图快不值钱，图稳才值钱。

二、一个 App 的身子骨

App/ 放入口；Screens/ 一屏一个文件；Components/ 放反复出现的小块。 Models/ 放数据长什么样；Services/ 放存取数据和调接口这类活。 这样分的唯一目的：改哪一屏就只动哪个文件——它才不会牵一发而动全身。

三、开发顺序五步

① 一屏空白界面 → ② 把数据摆上去 → ③ 能点得动 → ④ 数据能存下来 → ⑤ 换成真数据。 每一步都有一个能在屏幕上验证的结果——这是这条顺序唯一的筛选标准。 跟第 12.3 节给扩展搭骨架、第 9.4 节做周报助手是同一套：先跑通最小的一条路，再加零件。

四、什么时候该停下来

iOS 项目最容易失控的地方是界面：它占 5% 的功能，吃 30% 的注意力（第 9.5 节）。 停下来的判据：这个界面改动，会不会让某段逻辑重写？会，就先别改。 记住顺序：先能跑通，再好看——倒过来做的项目，通常两样都得不到。

五、动手 Demo：一个 iOS App 的身子骨

下面把五类目录与它们各自放什么、以及五步开发顺序排开。

TH([u"目录", u"放什么"], [22, 52])
T([u"Screens/", u"一屏一个文件，**改哪一屏就只动哪个文件**"],
  [22, 52])
T([u"Services/", u"存取数据、调接口这类跟界面无关的活"],
  [22, 52])

实跑输出：

--------------------------------------------------------------------
一个 iOS App 的身子骨
--------------------------------------------------------------------

用 AI 写 iOS App，**先让它把骨架搭对**，再往里填功能：

  目录            放什么
  ---------------------------------------------------------
  App/            入口——窗口、启动后先看到哪一屏
  Screens/        一屏一个文件，**改哪一屏就只动哪个文件**
  Components/     按钮、卡片这类反复出现的小块
  Models/         数据长什么样
  Services/       存取数据、调接口这类跟界面无关的活

开发顺序也跟着这个走，**每一步都要能在屏幕上看见**：

  步骤               做完你能看到什么
  ----------------------------------------------------
  ① 一屏空白界面     模拟器跑起来，看到一行字
  ② 把数据摆上去     文字或图片从固定的假数据里读出来
  ③ 能点得动         按一下有反应，屏幕上的状态会变
  ④ 数据能存下来     退出重进，上次的状态还在
  ⑤ 换成真的数据     假数据换成真实来源，界面不用改

五步的共同点：**每一步都有一个能在屏幕上验证的结果**。

这条顺序，跟第 12.3 节给扩展搭骨架、第 9.4 节做周报助手是同一套——
**先跑通最小的一条路，再加零件**。

五步顺序的共同点：每一步都有一个能在屏幕上验证的结果。 先跑通最小的一条路，再加零件——跟前面两个项目是同一套做法。

30 秒实验

1. 把你想做的那个东西，画成三到四屏，每屏写一句话说明它干什么。
2. 挑最中间那一屏，只做它，只做到能看见——先把这条最短的路走通。

常见误区

1. 从界面开始做。界面占 5% 的功能，吃 30% 的注意力——先跑通再好看。
2. 一次把五步都想清楚再动手。每一步都要能看见结果，看不见就不算做完。

• ☐ 下一节（14.3 App Store上架）

相关笔记

• Phase 1：项目初始化 — 先搭骨架再填功能
• Phase 2：正式开发（最耗时但也最有成就感的部分） — 切一小步、跑一遍、收尾
• Phase 3：美化界面 — 界面为什么最容易吃时间
• 🧡 Claude Code橙皮书 · 索引