Vibe Coding 做 App：一次有效迭代的六步闭环

很多新手做 Vibe Coding，还在沿用和 AI 聊天的方式：想到一句就丢给 AI 一句，这里改个颜色，那里加个按钮，这个 bug 修一下。

结果不是改了这里，就是坏了那里，越改越乱。这一版到底做了什么，自己都说不清；过几天再打开，下一版也不知道从哪开始。

这一篇以作者自己做的 App CATALK（记录猫咪叫声的软件，已上架 App Store）为例，讲一次完整的迭代闭环怎么做。作者把它分成了六步：

1. 发现需求
2. 提出方向
3. 让 AI 给方案
4. 选择并修正
5. 落入文档
6. 开发和测试

注意，最后一步才是开发。

很多人做迭代，想到一个点子马上丢给 AI，冒出来一个就开干一个。发现需求不是想到就做，而是先把需求攒起来，建一个需求池。

需求一般来自三个方面：

1. 自己用的时候发现的：改进点，或者产品的 bug。没错，修 bug 也算需求；
2. 产品构想：作为产品设计者对下一步的设想，比如云存储、多设备同步、付费点设计，或者你觉得自己有个天才的想法；
3. 开发中和 AI 讨论出来的。

不管点子是什么、从哪来，冒出来时都先不急着做，统一记进一个项目文件里，这就是你的需求池。

在 CATALK 里，需求池是 TODO.md。它有一个规矩：所有新想法都只记在这一个地方，写清楚是什么问题、在哪发现的、哪天记的。

TODO.md 的「迭代方向」一节开头就写着：新想法只记在这里，这是想法和候选功能的唯一入口。

提示词①：记下一个需求

想到一个点子时，先别让 AI 开始干活，这样跟它说：

记录一个问题：（你发现的问题或想法）
把它记进 TODO 的需求池，写清楚是什么问题、在哪发现的、哪天记的。先不要改代码，也不用现在解决。

发现需求不是想到就做，而是先进需求池。需求池和版本目标的更多细节，可以看 有了新点子要不要马上做。

开新版本时，不是把需求池里的全做了。既然是池子，就要挑。用什么标准挑？版本目标。有了目标，需求才有重要程度和优先级。

比如 CATALK 2.1 只解决一件事：让记录更方便。

有了目标，就能让 AI 把项目现状读一遍，按目标列出候选。做 2.1 时，作者开工只说了一句话：

检查一下当前版本还有哪些待排队的修正或者需求。

AI 就按「方便记录」这个目标，列了 8 个候选。

只回「做 / 不做」是不够的

AI 列完候选，很多人只回两个字：做，或者不做。这样 AI 只拿到一个结论，不知道你为什么这么选。作者的习惯是：每一个决定都带一个理由。

比如当时 AI 建议给 CATALK 加一个快捷入口：在主屏幕长按图标就能直接开始录制。作者说这个不做，理由是：自己平时在小区里遇到流浪猫，第一反应是快速打开手机的录像，而不是打开 CATALK。

就这一句话，快捷入口被砍掉了，重点也跟着挪到另一件事上：把相册里已经拍好的视频处理得更好用。

一个需求为什么做、为什么不做，一定要想清楚再开工。这个理由，就是产品的方向。

方向定了，接下来是具体怎么做。新手在这里容易走两个极端：

• 甩手掌柜：直接让 AI 改代码，不满意再改，越改越乱；
• 事必躬亲：每个细节都自己定，按钮多大、什么颜色、文字怎么写，想到最后自己都整不会了。

根据作者的经验，细节问题，AI 往往想得比人更全面；但产品方向，只有你自己知道。正确的分工是：你给方向，AI 推细节。

同一个方向，出三个方案

作者的做法是：只说清楚要做个什么东西、大概包含哪些内容，不让 AI 直接动手，而是在同一个方向上给出三个不同的方案，每个方案都写清楚为什么这么设计。

三个摆在一起，好坏一比就出来了，你自己到底想要什么也会跟着想清楚；每个方案都带着理由，选的时候就知道自己在取舍什么。

例子：录音流程第 ③ 步「补充信息」

2.1 时，作者想把记录流程的第三步从「写一个场景」改成「补充更多信息」。跟 AI 说的只是一个方向：这一步要放封面、视频片段和场景，页面具体怎么排拿不准，先出几个设计稿对比一下，不要急着改。

AI 给了三个方案：

除了三个方案，AI 还在下面列了一张表，把这个页面要面对的问题都抛了出来：没有视频的记录怎么办？点场景快捷词会不会把已经写好的字覆盖掉？每个方案分别怎么解决？

这些细节作者一开始根本没想到，但现在不用自己去想，只要看，然后选。

提示词②：让 AI 出三个方案

我想做（一个什么功能 / 页面），它大概要包含：（列出几项内容）。
先不要写代码。在这个方向上给我出 3 个不同的方案，做成能直接看的设计稿HTML，放在一起对比。
每个方案写清楚：为什么这么设计、好处是什么、代价是什么。
最后列出这个功能要面对的问题，每个方案分别怎么解决这个问题

这样既能让你参与到产品设计里，又不用从头去想按钮多大、颜色放什么、文字怎么写。方向和最后拍板的权力在你手上，细节由 AI 补全。

AI 出了几套方案，接下来要选。注意：这时的方案代表的是一种方向，而不是最终定稿。所以不要直接跟 AI 说「就按这个来」。

正确的做法分两步：

1. 第一轮先选方向，而不是选成品。选一个符合需求、看着顺眼的，它可能有些小问题；
2. 之后让 AI 多改几轮。每一轮只改一两处，说清楚改哪里、改成什么样、为什么改。一定要精准反馈。

例子：信息补充页

AI 第一版给了三套组合，作者选中其中一套布局。布局没问题，但信息太多，显得很拥挤。于是作者指出：提示文字有点多，有一句话出现了两次，一处在大标题下面，一处在输入框里，只要保留一个地方就行。

之后每一轮，作者都只说一两个问题，比如「标题挪到卡片上方」「字数放进输入框里」。前后一共改了 6 版才定稿。

例子：底部菜单「看着有点乱」

底部更换封面的菜单，三个选项明明已经居中对齐，看着还是有点乱。这时不能跟 AI 说「给我改整齐一点」，而是要找到核心原因：文字长度不一样。让它都改成四个字的选项就可以了。

反馈越具体，AI 越容易做出你想要的结果。

方案定了，很多人就直接说「那你开始写代码吧」。刚定下来的东西全留在聊天记录里，换一个窗口或者多聊几轮，AI 就开始混乱。

正确的做法是：定下来一条，就让 AI 写进 PRD 文档，再照着 PRD 去开发。靠文档驱动 AI 开发，把记忆留在文档里。

提示词③：先写进 PRD

把刚才定下来的写进 PRD，每条都写上为什么这么定，不做的也写上原因。
先不要写代码，先改完文档和我确认。

PRD 就是产品需求文档，是一份跟着产品版本走的动态文档。比如前面那条「不论视频长短，流程都一样」的决定，就以日期加理由的形式写在 CATALK 的 PRD 里：

这样，所有迭代讨论在本地都有一个固定的位置。尤其是做较大改动、需要跨对话工作时，也能确保和最初讨论出来的东西一致。为什么要把讨论落成文档，可以看 AI 的记忆该存在文档里，而不是对话里。

到了第六步，才轮到 AI 写代码。但千万不要 AI 说「写完了」就当功能做完了，那只代表代码写完了。功能是不是真的能用，得靠测试。

所以开发时，作者让 AI 一边写一边测，做完再把还没验证的地方列出来，写进项目的进度文件。

CATALK 开发时，AI 做了一套完整的测试用例，让程序把页面自动点一遍，每次开发新功能都跑一次全流程测试。比如 App 会自己合成一段 90 秒的测试视频，在 12 秒、47 秒、75 秒各放一声猫叫，用来走真实的选视频路径。

收尾时，AI 还列了一份还没验证的清单：自动测试做不到、需要在真机上用几分钟真实视频测一遍的项目。这些都写进了项目说明，等作者去测。

到这一步，一次版本迭代的所有步骤才算告一段落，才是一次真正的有效迭代。全流程测试的具体做法，可以看 让 AI 当测试工程师。

再过一遍六步：

不要觉得麻烦。你会发现前五步都不是在写代码，而是在思考和留档，为开发做准备。

一句话做个小 demo、一个简单单页，没有问题。但如果想做一个真正能用的产品，就得把想法细化成方案，把方案做成文档，再用文档推动 AI 开发。这样做出来的东西，每一处都经过你的思考，有明确的想法，也能追溯回去。

每一步里「人」该做什么判断，可以接着看 AI 这么强了，人还能干什么。