Vibe Coding 做 iOS App：从想法到验收的五步开发法

只对 AI 说一句“帮我做一个 App”，通常不足以把产品做成自己想要的样子。随着页面和功能增加，你还需要决定用户是谁、第一版做什么、界面长什么样，以及怎样判断做得对不对。

本教程按视频中 CATALK 猫咪叫声日记本的开发过程，把工作拆成五步：想清楚 → 写 PRD → 定设计 → 开发 → 验收。每一步都有具体产物，下一步可以接着使用。

视频采用的开发环境是 Mac、Xcode 和 Claude Code，原生工程使用 SwiftUI；上架环节还涉及苹果开发者账号。本文聚焦这套开发方法，环境安装、费用和完整上架操作不在本期展开。

“我想做一个记录猫叫的 App”只是一个念头。动手之前，先把下面四个问题写成具体答案。

这里的“十秒内”是案例的设计目标，并非这篇教程测得的性能数据。它的意义是给后面的设计和开发一个可以对照的方向。

还要加一个容易被忽略的问题：第一版不做什么？

视频作者把社区、猫语翻译、云存储分享都放进了不做清单。第一版只保留一条核心路径：录一声猫叫，打一个标签，以后回来回看。其他好点子先记下来，留给以后的版本。

把四个问题的答案和不做清单整理成一段文字。这就是下一步交给 AI 的输入；它既说明产品要实现什么，也约束 AI 不要顺手扩展出一堆新功能。

PRD 是产品需求文档，可以把它理解为 App 的开发说明书。它要写清楚有哪些页面、每页能做什么、点击按钮后发生什么。

不用从空白文档开始。把第一步的答案和不做清单一起交给 AI，再使用视频场景中的提示词：

我想做一个这样的 iPhone APP（附：四个问题的回答 + 不做清单）

1. 先不要写代码，帮我把它补成一个完整的产品需求文档 PRD；
2. 写清楚有哪些页面、每个页面的功能和规则；
3. 第一版只做核心功能，其他的想法单独列出来，不要开发；
4. 有拿不准的地方，先向我提问，我来决定。

AI 写出第一版后，重点处理它拿不准的问题。例如，删除记录要不要二次确认？只有一只猫时，要不要跳过选猫？这些取舍要由你决定，并写回 PRD。

视频中的 PRD 从版本定位和设计原则开始，再写信息架构和各页面的具体规则：

• 设计原则：为了“记录要快”，规定从打开 App 到保存一条记录，最多不能超过五步。这是该项目的要求，不是所有 App 的统一标准。
• 信息架构：像一棵树一样，列出页面、归属关系和入口。
• 页面规则：打标签时，每次只问一个问题——哪只猫、什么意思、什么场景；前两步选完后自动进入下一步。

把规则写到具体行为，AI 实现时就有据可依。完成这一步的标志，是你已经确认了第一版范围、主要页面和关键规则；未确定的部分也被明确列了出来。

PRD 主要定义功能，视觉设计还要进一步确定。视频把这一部分拆成三个连续的产物：设计简报 → 能点的 HTML 样板 → 设计规范。

先写一份简短的设计简报

简报是写给 AI 的设计需求，先讲清三件事：整体感觉、颜色、有哪些页面。还可以写明不希望它长什么样。

CATALK 的方向是：像一本放在床头、写满猫咪日常的手帐，温暖、有点俏皮，但安静不吵闹；避免做成专业录音软件或社交 App。颜色包括奶油底、焦糖橙、珊瑚、薄荷和深棕文字。

这份简报中的气质和颜色属于 CATALK 的选择。换成自己的产品时，要从目标用户和使用场景出发，重新确定这些内容。

路线 A：先生成概念图，再复刻成 HTML

如果你正在使用的 AI 工具支持生图，可以把用途、整体感觉、品牌色和首页内容写进提示词，请它并列展示三个不同方向，方便比较。

视频演示了像素复古、纸质手帐和原生柔和三个首页方向，最终选中纸质手帐。

工程中没有独立保存这一步的完整生图提示词，因此这里保留视频讲到的输入要素，不把它们扩写成所谓的完整原文。选中方向后，再逐页生成录音、裁剪、打标签等核心页面。视频给出的追加句可以直接复用：

沿用刚才选中的风格，配色、字体、圆角、图标完全一致。

概念图仍然是一张图片，文字可能有误，交互和细节也需要进一步验证。接着把概念图交给 AI，使用下面的提示词做网页样板：

参考这张概念图，用 HTML 做一个首页的样板：

1. 尽量还原配图里面的配色、字体、卡片、按钮；
2. 数据先用假的，不用真实功能；
3. 拿不准的地方（比如头像怎么放、指纹的深浅），做成可以切换、可以调节的选项。

上面保留源场景提示词的“指纹”原字。结合画面里的“纸纹纹理”调节项，这里实际是在讨论纸张纹理；用于自己的项目时，可把它改成“纸纹的深浅”。

网页样板的作用是把视觉选择变成能查看、能调整、能点击验证的界面。此时用假数据即可，不必提前接入真实业务。

路线 B：用参考截图，直接做 HTML

如果所用工具不能生图，也可以直接跳过概念图。准备喜欢的 App 或网页截图，连同 PRD 和设计简报一起交给 AI：

参考这几张截图的风格，根据 PRD 和设计简报，用 HTML 做一个首页的样板：

1. 风格和配色按照简报来；
2. 数据先用假的，不接真实功能；
3. 做两到三个不同的方向，放在一起让我挑一下。

不满意，就直接继续提意见，改到你顺眼为止。

两条路线最后都要得到一个你满意的 HTML 样板。先确定方向，再把具体不满意的地方逐项反馈，直到可以作为后续页面的参照。

把定稿样板整理成设计规范

不要只把设计决定留在对话里。把样板和规则保存在项目中，后续开启新对话、换 AI 接手时，让它先读取同一份规范。

根据定稿的 HTML 样板，整理一份这个 APP 的设计规范：

1. 颜色、字体、字号、间距、圆角、阴影，都写成具体的数值；
2. 按钮、卡片、标签这些组件长什么样、什么时候用，都要写清楚；
3. 写清楚哪些东西不能用；
4. 以后做新的页面，必须先读这份规范。

图中可以看到，规范不只是“看起来温暖”这样的描述，还规定了主按钮的使用数量、字体分工，以及撕边、纸纹等具体参数。字体名称以源规范中的“中文用文楷，数字用系统字体”为准，视频口播的名称有误。

完成后，把 PRD、定稿样板和设计规范放到项目中，让后续开发有明确参照。每个新页面仍需要检查是否遵守规范；保存一份文档本身并不等于自动保证视觉一致。

视频作者让 Claude Code 新建 SwiftUI 原生工程，把 PRD 和设计稿交给它，一页一页实现。每做完一页，就在 Xcode 模拟器中运行，自己上手点击，再反馈具体问题。

这一环节的关键，是把“看着不顺”说明白。CATALK 最早的打标签页把选猫、选标签、写场景全部放在一页，信息堆得太多，场景区域还被挤出去了，使用时很容易遗漏。

作者试用后提出的改法是：拆成三段，每次只问一个问题，选完再进入下一步。源场景中的流程为“选猫 → 选标签 → 场景（可跳过）”。

把这个过程用于自己的项目，可以按下面的顺序推进：

1. 让 AI 按已确认的 PRD 和设计规范实现一个页面或一段流程。
2. 在模拟器中亲自使用，描述卡在哪里、哪里容易误解、哪里看不到。
3. 把确认后的改法写进 PRD，形成明确的产品规则。
4. 让 AI 修改实现，再重新走一遍相关流程。

例如，“这个页面不好用”不够具体；“选猫、标签和场景堆在一屏，场景被挤出可视区域；改成每次只问一个问题，前两步选完自动前进”就能成为可执行的需求。

视频作者报告，这个案例从新建工程到提交审核用了两天。这是他在该项目上的经历，不是采用这套方法后的统一工期。

App 能运行，还要确认用户能完成目标。先照着真实使用路径走一次。CATALK 的核心路径是：添加一只猫 → 录一声 → 裁剪、打标签 → 保存 → 回到首页。

检查时不仅看按钮能不能点，还要看最后有没有得到想要的结果：记录是否保存、标签是否正确、回到首页后是否能找到它。这些是根据视频核心路径整理的验收重点。

把重复检查交给自动化测试

每次改代码都从头手动点一遍会很累。视频作者让 AI 编写了自动化测试脚本，用来打开 App、逐步点击并检查结果，每次改动后再运行。

工程里展示的是测试代码画面，没有测试执行过程或完整通过报告，因此这篇教程不把它当作“已经证明所有功能正确”的证据。实际使用时，应让 AI 根据自己的核心流程编写测试，并检查真实运行结果。测试也只覆盖写进去的行为。

体验取舍需要你亲自判断

功能测试之外，还要检查一些体验问题：

• “下一步”按钮居中还是左对齐，更容易理解和操作？
• 进入下一步时，页面滑动方向是否符合用户预期？
• 保存新记录回到首页，是否需要高亮，让用户知道刚才保存成功了？

这些取舍不能只靠“测试通过”来决定。你可以让 AI 协助检查，但仍要自己使用，再把确认后的行为写回需求；规则明确后，其中一部分也可以转成后续测试。

验收之后，再进入上架阶段

视频最后概述了上架动作：通过 Xcode 打包上传，到苹果后台填写介绍、上传截图、提交审核。它没有展示完整配置和提交流程，所以这里保留为开发之后的下一阶段，不把几行概述当成完整上架指南，也不沿用“两天出结果”作为审核时限承诺。

到这一步，你应当已经有：确认过的需求、可复用的设计规范、能运行的 App，以及经过检查的核心流程。之后再增加功能时，继续按“更新文档 → 实现 → 试用与测试”的顺序迭代。