Vibe Coding 做 App：先让 AI 画一张信息架构图

想到一个功能，就让 AI 立刻加上去，做单页网页时往往还能应付。可一旦变成 App，十几个页面、同一页面的不同状态、多个入口和返回路径会一起出现。功能虽然加上了，产品却可能越来越难用。

这篇教程以视频中的猫咪叫声手帐 App CATALK 为例，带你把产品需求整理成一张可维护的“页面地图”，再让 AI 按这张地图推进设计和开发。你需要准备自己的产品需求文档（PRD）；完成后，将得到页面层级、导航规则、状态清单和待确认问题。

这里说的信息架构，是在画原型、做 UI 和写代码之前，先把有哪些页面、每页归在哪里、页面之间怎么走写清楚。它可以直接写在 PRD 中，用缩进的文字列出结构，再补上几条规则，不必先学绘图工具。

如果你做的是个人网站、简历或一个简单的单页小工具，可以省去完整的信息架构梳理。如果产品涉及多个底栏页面、连续操作流程，以及空数据、多数据等不同状态，先梳理会更有价值。

视频中的 CATALK 就属于后一种：用户先添加猫咪，再录下叫声、裁剪、打标签，最后回到手帐查看记录。开发时不仅要决定“做什么功能”，还要决定这些功能分别出现在哪里。

先从用户打开 App 后能看到的入口开始，向下列出页面。CATALK 的主要结构可以分为以下几类：

图中展示的是视频用于讲解的主要结构，完整产品还有其他子页。“录一声”是底栏入口，录音页是它承载的界面；图中把入口与操作界面分别画出，是为了说明后续流程，不代表必须创建两个独立页面。

以录音为例，主流程是：录音 → 裁剪多余声音 → 打标签、选择是哪只猫 → 保存记录。把顺序写出来，AI 才能知道下一步应该去哪，而不是每加一个功能就临时决定入口。

只有页面名称还不够。相同的页面结构，可以因为导航和状态处理不同，产生完全不同的使用体验。

写清底栏什么时候出现

CATALK 在 PRD 中约定了两条规则：

1. 底栏只出现在三个一级页面。进入裁剪、打标签、设置子页，或打开弹出页时，底栏不显示。
2. 还没有猫咪时隐藏底栏，首页保留“添加猫咪”的入口，引导用户先建立猫咪资料。

这是这个产品的设计选择。梳理自己的 App 时，也要把对应规则写出来，避免不同页面各自决定底栏的行为。

同一页面，按数据情况列出状态

首页不能只画“数据齐全”的一种样子。视频提到需要考虑：没有猫咪、有猫但没有记录、只有一只猫、有多只猫等情况。

这张对照图展示了没有猫、一只猫和多只猫的界面；“有猫但没有记录”还应作为单独的状态写入清单。状态清单会成为后续线框图和 UI 设计的依据，帮助你检查是否漏画。

一个弹出页，可能有多个入口

“添加猫咪”可以从首页、打标签第一步，以及“设置 → 管理猫咪”打开。梳理时，要逐个入口说明：从哪里来、关闭或完成后回到哪里，以及要带什么信息过去。

例如，在打标签时临时添加猫咪，PRD 还约定添加后自动选中新猫咪。这个结果必须写进规则，不能只写“打开添加猫咪弹窗”。至于在设置中新增猫咪后，首页是否切到新猫咪，则是视频后续回测中被 AI 提出的待确认问题。

视频口播把首页添加入口说成左上角，源 PRD 和场景标注为右上角。实际梳理时以产品界面与确认后的 PRD 为准。

信息架构的另一个作用，是让不同页面遵守同一套约定。视频用了两个具体例子。

选猫只在打标签时做

如果录音页和打标签页都能选猫，而且分别保存默认值，就容易发生前一页显示 A 猫、后一页默认 B 猫的问题。

CATALK 的处理方式是：录音页不显示、不选择猫咪；到打标签页的“是哪只猫”这一步再选，必选且不预选。即使只有一只猫，也需要用户自己点选。

切换当前猫咪，与筛选记录分开

首页上方的猫咪头像负责切换当前查看的猫咪；想查看所有猫咪的记录，则在时间线旁使用筛选按钮。这两种操作的作用不同，要分别定义，避免一个入口同时承担两个含糊的含义。

把这些约定放进 PRD，AI 在改动相关页面时就有共同依据。开启新对话或换一个 AI 接手时，也应让它先读取这份文档，不能假定它已经知道所有历史决定。

你不需要独自把所有结构手工列完。先把已有的产品需求文档交给 AI，让它生成第一版信息架构，再由你检查和拍板。

下面保留视频最终场景中的完整提示词。工程记录显示，它来自录屏输入框，并已把原输入中的“返回回到哪”修正为“返回到哪”。

这是我的产品需求文档。先别写代码，帮我画一份这个 App 的信息架构。

要求如下：
1. 用文字按层级列出所有页面，标清楚哪些是底栏上的一级页面、哪些是点进去的二级页面、哪些是从下面弹出来的页面；
2. 写清楚每个页面从哪进、返回到哪、会带着什么信息过去（比如当前选中的是哪一项）；
3. 写清楚底栏在哪些页面出现、哪些页面藏起来；
4. 列出每个页面有几种状态，比如还没有数据、数据很多、出错的时候分别显示什么。

画完先给我看，我确认了再往下做。

发送时附上自己的 PRD，或明确告诉 AI 去读取哪个文档。这里的任务是整理结构，先拿到可审阅的结果，再进入设计和编码。

视频作者把 CATALK 的 PRD 和上述提示词交给一个新的 AI 对话做回测。这一次，AI 给出的主要结构与原方案基本一致：三个底栏页面、录音到裁剪和打标签的流程，以及弹出页的分类都对应上了；还把页面入口、返回路径和状态整理成表格。

更有用的是，AI 反问了 12 个需要作者决定的问题。其中包括：裁剪和打标签时是否隐藏底栏，以及在设置中新增猫咪后，首页是否自动切换过去。

这些问题是本次回测的结果，并不意味着每次使用提示词都会得到同样的输出。对已经写在 PRD 中的规则，要检查 AI 是否正确读到；对确实没定的行为，由你做决定，再回写文档。

刚开始不必一次消化所有细节。按视频的建议，先确认页面结构和底栏规则，再逐步补齐每个页面的状态。可以按这个顺序审阅：

1. 主要入口是否合理，现有功能有没有遗漏或重复。
2. 主流程能否走通，返回和关闭是否有明确目的地。
3. 底栏显示规则是否一致，有没有自相矛盾的约定。
4. 把 AI 标出的待确认问题逐项决定，再补充状态和传递的信息。

审阅的产物是一份你已经确认的页面地图，以及还需要继续讨论的问题清单。

确认后，把信息架构保存到 PRD。后续画低保真原型、线框图和 UI 时，从这里提取需要设计的页面与状态；增加功能时，也先确定它在地图上的位置。

视频展示的项目规则文件中，有这样一条约定，可以作为你的工作流参考：

新功能、改交互、改流程：先改 PRD（新编号或对应小节），把改动告诉用户，确认后再写代码。

每增加一个页面，先回答四个问题：挂在哪一层、从哪来、返回到哪、底栏显不显示。

你可以直接用自己的产品做一遍：准备 PRD，发送提示词，确认页面结构与底栏规则，把未定问题补齐，然后保存回 PRD。之后每次迭代，都先更新这份共同依据，再推进设计和开发。