🤔 咋高效 Vibe Coding 一个产品呢

过去我想要 Vibe Coding一个新app的时候，脑子里想到的是：打开 AI，描述一句需求，然后让它一路把产品写出来。 现实通常不是很顺利，但真实做产品时很容易翻车。因为 AI 最擅长的是执行，不是替你想清楚产品。你没想清楚的地方，它不会停下来等你，它会自己补。补得对，那是运气；补得不对，就是返工。 更高效的做法是什么呢🤔 Total TypeScript 创始人Matt Pocock 的一套 agent skills，里面有一个很值得普通产品创作者借鉴的工作流：不要一上来就写代码，而是先把 AI 当成一个会“拷打你”的产品合伙人。 第一步，是让 AI 拷打作者。 这里的“拷打”不是挑刺，而是持续追问：这个功能给谁用？解决什么问题？什么算成功？哪些情况不做？用户走到某一步失败了怎么办？有没有边界条件？有没有和现有功能冲突？ 很多产品需求最开始都是模糊的。比如“我要一个会员系统”，听起来很清楚，但其实里面藏着一堆问题：会员有几种等级？按月还是按年？过期后数据怎么处理？支付失败怎么办？管理员能不能手动调整？老用户怎么迁移？ 如果这些问题不先讲清楚，AI 后面写得越快，偏得也越快。所以 Matt 这套思路的第一件事，不是让 agent 开工，而是让它和你达成共识。 第二步，是把共识写成 spec 文档。 这里有一个很重要的点：文档里不要塞具体代码。 很多人写技术文档喜欢把文件路径、函数名、代码片段都写进去，看起来很专业，但对长期迭代反而危险。因为产品文档和代码工程的变化速度不一样。今天代码结构是这样，明天重构以后就变了。如果 spec 里绑定了太多具体代码细节，文档很快就会过期，最后变成误导 AI 的旧地图。 更好的 spec 应该记录的是：问题是什么、解决方案是什么、用户故事是什么、哪些决策已经确认、哪些事情不做、应该从哪些公开行为来验证功能。 也就是说，spec 记录“我们要做什么”和“为什么这么做”，而不是提前规定“代码必须长什么样”。 第三步，是根据 spec 实施，但改变传统开发顺序。 很多 AI 写全栈功能时，会自然走一条常规路线： database → backend → frontend 先改数据库，再写接口，最后做界面。 这在人类工程师手里不一定错，但在 agent 手里很容易变成“横向开发”：数据库改了一堆，后端写了一堆，前端还没接起来，直到最后才发现整个功能跑不通。 Matt 这套思路更强调“功能原子化”的开发方式。不是按技术层分块，而是按用户可验证的小功能切片。 比如不要这样拆：

1. 设计数据库
2. 写所有 API
3. 做所有页面 而是这样拆：
4. 用户能创建一个最小会员
5. 用户能看到会员状态
6. 用户能续费
7. 用户过期后能看到正确提示 每一片都尽量是端到端的：有必要的数据、有必要的接口、有必要的界面、有对应测试。这样每完成一小片，产品就多一个真实可验证的能力。 第四步，是用 TDD 引导 agent 写代码。 TDD 简单说就是：先写一个会失败的测试，再写刚好让测试通过的代码。 这对 AI 特别重要。因为 AI 写代码时最大的问题不是“不会写”，而是“写太多、写偏、写完没反馈”。TDD 给它一个很明确的反馈回路：这个行为现在不成立，先让它成立。 而且测试不应该测试内部实现，比如“某个 service 被调用了几次”。更好的测试应该验证用户或调用方真正关心的行为，比如“用户创建会员后，可以在账户页看到会员状态”。 这会逼着 agent 少做空想，多做可验证的产品行为。 最后一步，是让 agent 自己做 code review。 实现完成后，不要马上结束。让 agent 再切换到 review 视角，检查两件事： 第一，代码质量是否过关，比如有没有明显坏味道、重复逻辑、边界情况缺失、测试不足。 第二，是否真的符合最初的 spec。很多 bug 不是代码写烂了，而是代码写得很认真，但做的不是你原本想要的东西。 所以这个流程其实不是“让 AI 更快写代码”，而是让 AI 更少写错代码。 它的完整链路可以概括成： 先拷打需求 → 达成共识 → 写 spec → 拆成端到端的小功能 → 用 TDD 一片一片实现 → 最后 code review 这套方法对非专业开发者尤其有用。因为我们最缺的通常不是“写代码能力”，而是把一个模糊想法变成清晰产品定义的能力。 Vibe Coding 真正高效的方式，不是把方向盘完全交给 AI，而是让 AI 在每一步都帮你降低不确定性。 先问清楚，再写下来；先验证一小片，再继续下一片；先让行为跑通，再谈代码优雅。 这可能才是普通人用 AI 做自己产品时，最接近“靠谱”的工作流。