Vibe Coding 时想到一个点子，要不要马上让 AI 做？

AI 写代码很快，很多人做 Vibe Coding 时想到一个点子就马上让 AI 实现，再想到一个又加上去。结果是功能越加越多，页面越来越挤，产品离最初想做的事越来越远。

问题不在于点子多，而在于缺少一套处理点子的办法：点子怎么管理？哪些该做、哪些不该做？优先级怎么选？

这篇用作者自己已上架的 App CATALK（一个记录猫咪叫声的小工具） 里的一次真实改版来回答。改版对象是「打标签」页，一个点子从出现到上线，会经过四步：

有了一个绝妙的点子，第一反应往往是马上打开 AI 让它去做。作者的做法是：先不急，把它记下来，放进「点子池」。

点子池是一个概念，不是某个工具

点子池不是特定的文件，也不是某个工具。只要能把点子沉淀下来，它就是点子池，备忘录也可以。

在 CATALK 里，点子池就是项目中的 TODO.md。文件里专门有一节写明：

新想法只记在这里，这是想法和候选功能的唯一入口。……决定要做的，写进 PRD §11 并在这里注明编号。

把规矩写进给 AI 看的项目说明

光自己记住还不够。作者把这条规矩也写进了给 AI 看的项目说明 AGENTS.md，在「开工前」一节让 AI 先判断任务属于哪一类：

### 3.2 开工前

1. 先读 README 的「当前状态」「未发布的改动」和「下一步」。
2. 判断任务属于哪一类：
   - 新功能、改交互、改流程：先改 PRD（新编号或对应小节），把改动告诉用户，确认后再写代码。
   - 不改规则的 bug 修复：可以直接改代码，收尾时在 PRD 变更记录补一行。
   - 只是想法、暂时不做：写进 TODO，不动 PRD 和代码。

这样，就算你跟 AI 随口提了一句新想法，它也不会马上去写代码，而是先帮你记下来。

上图是视频中的示意动画，用来说明这条规则想达到的效果，不是一次真实对话的截图。

为什么不让 AI 马上实现

原因一：产品规划需要冷静期。 刚想到点子时，情绪可能盖过它的真实价值。你现在觉得特别激动，冷静下来看，它可能无关紧要；如果直接插队，就会占用优先级更高的事情的资源。

原因二：AI 开发请神容易送神难。 你给 AI 一句话，它噼里啪啦把代码都写完了。万一没做 git 备份，或者工作区不干净、混进了其他文件，想回退的时候就麻烦了。

如果还不熟悉备份和回退，可以先看站内的 Git 存档、回退与分支管理完全指南。

最靠谱的点子来源不是灵光一闪，而是边用边想：用着用着，发现旁边还能做得更好，也就是所谓的「相邻性可能」。

真实场景：打开打标签页，觉得不对劲

CATALK 2.0 快上架时，作者录了一段猫叫准备打标签，一打开这个页面就觉得不对劲。一个页面上从上到下塞了：

1. 录音
2. 选哪只猫
3. 十几个标签，外加一个「自定义」按钮
4. 最下面还有一个场景输入框，但它被挤出了屏幕，要往下滑才能看到

不直接让 AI 改，先截图记录

作者当时没有直接让 AI 去改，而是先截图，把发现的问题记下来。每一条先记三样东西：

• 哪个页面
• 发现了什么问题
• 打算怎么改

针对这个页面，作者记下了三个优化思路（原文记在 PRD 的「5.3 测试反馈」里）：

这些改动都不难，但作者也没有马上让 AI 去做。在「怎么做」之前，还有一个问题：这些事到底该不该做？

前提：一个版本最好只回答一个问题

判断之前先明确这个版本的目标。例如这一版只解决「新用户很快上手」，或者只解决「核心功能足够流畅」。

没有目标，每个点子看起来都挺好，你会哪个都想做。有了版本目标，判断时才有依据。

维度一：和目标有没有关系

有关系的，再继续往下讨论。没关系的，哪怕再有意思，这一版也先放着，留在点子池里以后再看。

维度二：这个点子属于哪一类

作者一般分三类，处理顺序也按这个顺序：

1. 修复体验问题
2. 改进现有功能
3. 增加新功能

为什么修复排第一？因为用户最先感受到的，就是那些用着不顺手的东西。一个功能用起来不顺手，再加 10 个新功能也救不回来。产品设计里经典的 Kano 模型讲的也是这个道理：基本需求没做好之前，惊喜功能没有意义。

维度三：看真实成本，不看好不好做

这是做 Vibe Coding 最容易踩的坑：实现成本不等于真实成本。

• 有些功能做起来容易，不代表用起来容易；
• 反过来，有些功能实现起来又难又复杂，但做好以后用户用起来很轻松。

AI 写代码很快，很多功能看起来几分钟就能做完，你会觉得「反正不费事，加上吧」。但功能上线以后，你要一直维护它、测试它，每次改版都要照顾它，页面上也永远多了一样东西。这就是历史包袱。产品往往就是被一次又一次「反正做起来也容易」带跑偏的。

判断的结果不只有「做」。以「要不要做猫咪社区」为例，作者想得很清楚：肯定不做。

1. 上线社区要另外申请备案。 很多人不知道这一点。
2. 小体量 App 做社区没意义。 社区在用户量足够大时才有意义，体量小的 App 做了也没人说话。
3. 就算热闹起来，也是负担。 用户发内容需要云存储，存储就是成本，文件越多成本越高；还有巨大的内容审核压力，这是产品的安全红线，没有审核人员千万不要碰。

这些不做的点子也要写下来，并把原因写清楚。否则时间久了会忘，说不定哪天又莫名其妙地加上去了。

先说目标

CATALK 是记录猫咪叫声的 App。它在 PRD 设计原则里的第一条是「记录要快」：

1. 记录要快：从打开 App 到保存一条喵语，不超过「录一声 → 停止 → 下一步 → 选标签 → 保存」五步。

视频里作者把它讲成「记录要方便」，并补充了自己的理解：方便不是步骤少，而是符合用户的习惯和直觉。 用户不用想就知道：

• 下一步应该点哪里；
• 哪些是必填的；
• 自己刚才选了什么。

前两个维度：三条都过

• 和目标有没有关系？ 打标签是记录里最核心的一步，三个点子都有关系。
• 属于哪一类？ 三条都是改进现有功能，没有一个是新功能。

前两个维度都过了，真正要取舍的是成本与收益。

第三个维度：打补丁，还是从根上解决

前两个点子看起来都很好做：

• 忘记选猫：把标题改成高亮，字改大一点；
• 头像太大：把头像缩小一点，把场景输入框挤回屏幕。

都是改几行代码的事，但它们都是在那个很长的页面上打补丁。用户为什么会忘记选猫？场景输入框为什么被挤出去？根本原因是一个页面同时问了三个问题：哪只猫？叫声是什么意思？在什么场景下录的？过多的信息分散了用户的注意力，再怎么打补丁、做突出，都改变不了这个事实。

第三个点子「三段式」改动很大，要把整个页面拆开重做，但它从根本上解决了问题：一次只问一件事。

1. 这是哪只猫？
2. 这声猫叫是什么意思？
3. 写场景（可以跳过）

结论：做三段式，前两条被取代

作者最后决定只做三段式。做完之后，每一步只有一个问题，空间足够了，头像不用缩小，第二条也就不用做了；选过的结果会显示在顶部，一眼就能看到选了哪只猫，第一条也被取代了。

同样是优化，实现起来更复杂的点子，反而效率更高，也是最简洁的方案。如果当时想到什么就做什么、图省事去打补丁，页面还是那个长页面，问题依然没有解决。

决定要做以后，才进入「怎么做」。作者没有直接让 AI 改代码，而是先把 PRD 里「打标签（新建喵语）」这一节整个重写，写清楚：

• 顶部固定放什么；
• 选过的结果怎么显示；
• 第一、二、三步各问什么问题；
• 点完之后怎么进入下一步、怎么回退；
• 保存之后在首页怎么高亮提示。

截图是这一节的最终版本，已经包含下文验收后补进去的修改（例如「前进向左、回退向右」）。整理成表格如下，其中三行在录屏里被截断，以「……」表示：

为什么要先写进 PRD

• AI 是照着文档写代码的。 文档写得越清楚，做出来就越接近你脑子里想的画面。
• 新对话不用从头解释。 下次开一个新对话想改这个页面，AI 读一下 PRD，就知道它现在长什么样、为什么是这样。

一句话：写进文档的决定，才是项目真正记住的东西。

还没有 PRD 的话，可以先看 Vibe Coding 项目规划指南。

开发完不等于做完了，还要验收。验收分两部分：

• AI 截图验收：AI 做完后自己截图，对照检查；
• 必须由人完成的部分：自己拿着 App 真实操作一遍。

三段式做完后，作者亲自操作了一遍，发现了 4 个问题（记在 PRD「5.4 三段式测试反馈」里）：

第 1 条里，AI 没有「看不看得清」的概念，它觉得有就行。第 2 条里，点「下一步」时内容往右滑，感觉像在后退；正常来说下一步应该向左滑。

这 4 条都不是 bug，而是不符合人的使用直觉的问题。处理方式是：直接写进 PRD，一起改掉。

改完之后

最新版本对应修复了这四个问题：

1. 步数放大、居中；
2. 前进左滑、回退右滑；
3. 左上角改成带文字的「上一步」；
4. 新保存的那条在首页闪两下。

作者每一轮都保留了改之前、改之后的截图，效果一目了然。

发版说明，只写用户看得懂的话

发版时，更新说明里只写用户能看懂的话：

打标签改为三步：选猫 → 选含义 → 写场景，几秒完成。

1. 先记下来：有了点子先别急着做，冷静一下，放进点子池，写清楚哪个页面、什么问题、打算怎么改。
2. 判断做不做：先定版本目标，再看它和目标有没有关系、属于哪一类、真实成本有多高。别因为好做就去做，有些好做的也不要做。
3. 写进 PRD：决定要做了，就把规则和拍板的决定写清楚，再让 AI 照着写代码。
4. 自己试一遍：做完亲自走一遍，不顺手的地方直接改，确认没问题再发版。

AI 让做一个功能变得越来越容易，但由人来决定要不要做，反而变得更重要。