第一个 vibe coding 项目：MVP 切多小才不会烂尾

vibe coding 时代，第一个项目烂尾的概率高得吓人。我看过太多这样的剧本：第一天热血沸腾，觉得"AI 这么强，做个大东西"，列出 40 项功能清单；第一周搭架子、选技术栈、跟 AI 争论架构；第三周，热情耗尽，仓库归档，吃灰。复盘时当事人总说"AI 还是不够强"。错。AI 够强了，是你的范围太大了。第一个 vibe coding 项目的死因，十个里有九个叫"范围失控"，只有一个叫"技术不行"。

这篇文章讲 MVP 怎么切：一个反面案例告诉你"大"是怎么杀死项目的，一个"一周可演示"原则给你一条硬标准，四把切功能的刀教你动手，以及五个烂尾预警信号。目标只有一个：让你的第一个项目，做完，而不是做大。

反面案例："AI 版 Notion + Slack"的第三周

小林（化名）是我在 vibe coding 社群认识的朋友，程序员出身，第一次用 AI 做独立产品。他的想法是"团队知识库 + AI 问答 + 任务管理"三合一——用他自己的话说，"Notion 太重、Slack 太散，我要做个 AI 原生的 all-in-one"。功能清单列了 42 项：多工作区、权限管理、实时协作、AI 总结、全文搜索、移动端适配……

第一周，他让 AI 搭 Next.js + 数据库 + 认证体系。光是"登录、注册、忘记密码、邮箱验证、OAuth"这一套，就返工了四次——不是 AI 写不对，而是他一边做一边改需求。第二周进入权限管理：角色、分组、分享链接有效期……做到一半他发现，核心的"AI 问答"功能一行没写。第三周，他打开项目，看着 60 多个文件、跑不起来的本地环境，默默点了归档。用他的话说："我花了三周，给 AI 打了一份三周的工，最后连个能给人看的东西都没有。"

有意思的是，程序员出身的人更容易犯"范围太大"的错。为什么？因为"这个我会做"的错觉——登录系统我会、权限我会、实时协作我大概也会，于是每个功能看起来都是"顺手的事"。但在 vibe coding 里，"会做"不等于"值得做"。你的时间（和 agent 的上下文）是 MVP 最稀缺的资源，要全部押在"用户愿意为什么付费"的那一个点上。非程序员反而没这个包袱——他们只关心"能不能演示"，这恰恰是正确的直觉。

看看小林那 42 项清单里的典型条目，你就知道问题在哪："深色模式""多语言（中英）""操作日志审计""API 开放平台""移动端 PWA"。注意，这些没有一个是错的——它们全是"以后"的正确，"现在"的错误。第一个项目的清单里，凡是"有了更好"的功能，都是范围刺客。检验方法：假设明天就要演示，这个功能缺了会不会让演示垮掉？不会，就进"以后清单"。小林的 42 项里，能通过这道测试的不超过 5 项。

对比另一个故事：同社群的阿哲，想法是"简历一键排版"——上传 Word 简历，AI 优化措辞并套进一套好看的模板，导出 PDF。就这一个功能。他第一天用 AI 搭出上传页，第二天调简历解析，第四天接模板渲染，第六天上线。没有用户系统（链接即分享）、没有支付（先免费）、没有移动端适配（桌面端先行）。上线当天发到两个社群，拿了 200 多个注册，其中 30 人留了邮箱说"愿意付费"。阿哲的总结只有一句："小林做了三周的'产品'，我做了六天的' demo'——但我的 demo 有用户，他的产品只有代码。"

"一周可演示"原则：你的 MVP 硬标准

从这两个故事里，我提炼出一条硬标准，叫"一周可演示"原则：你的 MVP 范围，必须小到"7 天内能做出一个可演示的版本"。注意定义——

• 可演示，意味着"不懂技术的朋友能亲手点一遍核心流程"。不是"我跟你讲，它以后能怎样"，而是"你点这个按钮，看，它真的干了那件事"。小林第三周的东西讲不清，阿哲第六天的东西不用讲。
• 7 天，是热情的半衰期，也是反馈的起点。第一个项目最大的敌人不是竞品，是你自己的热情衰减。7 天内没有正反馈（有人用、有人夸、有人提需求），第 8 天你打开编辑器的意愿会断崖式下跌。而一旦有人用了，反馈会推着你走完剩下的路。
• 如果 7 天做不完，范围砍一半，再砍一半。这是原则里最反直觉的一句。多数人听到后的反应是"那还剩什么？"——答案是：只剩那个"让用户眼睛一亮"的核心动作。阿哲砍掉了用户系统、支付、移动端，剩下的"上传→变好看→导出"三步，恰恰是全部价值。

怎么判断"可演示"达标？三个检查项：第一，60 秒录屏能讲清。打开录屏，从进页面到核心动作完成，60 秒内讲完——讲不完说明路径太长。第二，断开你本人。把链接发给朋友，不做任何讲解，看他能不能自己走完流程——需要你讲解的 demo，不是可演示。第三，有"哇"时刻。演示里必须有一个让对方眼睛一亮的瞬间（阿哲的是"Word 扔进去，排版精美的 PDF 出来"）。没有"哇"时刻的 MVP，范围可能没问题，但方向有问题。

这条原则还有个技术层面的理由：agent 的上下文窗口和你的注意力都是有限资源。范围越大，agent 越要在"记住全局"和"写好局部"之间挣扎，返工率指数级上升。小范围 = agent 全程在线 = 一次做对的概率大增。切范围不是妥协，是给 AI 创造"能赢"的战场。

切功能的四把刀

原则有了，怎么动手切？四把刀，从快到慢：

• 第一刀：只留一条用户路径。画出你的核心流程：用户从哪进、点什么、得到什么。只保留这条路径上的功能，其他全部进"以后再说"清单。登录？如果 demo 不需要，先砍掉，用"链接即访问"代替。个人中心？砍。设置页？砍。阿哲的路径是"上传→排版→导出"，三步之外一律没有。
• 第二刀：砍掉所有"顺便"。"顺便做个管理后台""顺便支持深色模式""顺便加个英文版"——每个"顺便"都是一到三天的工期，三个"顺便"就是一周没了。判断标准：这个功能砍掉后，核心演示还成立吗？成立就砍。记住，MVP 的敌人不是"功能太少"，是"核心不亮"。
• 第三刀：用现成服务代替自研。认证用 Clerk 或 Auth0，支付用 Stripe Checkout（ hosted 页面，不用自己写），数据库用 Supabase，部署用 Vercel。Vibe coding 时代，"自己写"是最后选项。每一项自研都是 agent 的上下文负担和你的 debug 负担。能买就买，能租就租——你的第一个项目的目标是验证想法，不是练技术。
• 第四刀：先假后真（Wizard of Oz）。演示阶段，大量"后端逻辑"可以用假数据代替：推荐算法先 hardcode 三条写死的结果，AI 总结先调一次把结果缓存起来，复杂报表先做一张静态图。用户点的是"效果"，不是"架构"。等有人愿意为效果付费，再把假的换成真的。先证明"有人要"，再证明"我能做"——顺序不能反。

第五把刀（赠送）：时间盒。给每个功能定一个"死线"：比如"登录功能最多 4 小时"。时间一到，没做完就砍掉或换更糙的方案——用 magic link 代替密码体系，用单文件 SQLite 代替 Postgres。时间盒的本质是用时间预算倒逼范围决策，避免"再给我两天就好"的无底洞。记住：第一个项目里，没有"差两天"的功能，只有"不该做"的功能。

烂尾预警：出现这五个信号，立刻停下来砍范围

项目进行中，如果出现以下任何一个信号，说明范围已经失控，停下来砍范围比继续写代码重要十倍：

• 信号一：第三天了，你还在搭架子，没见到界面。健康的 MVP 第一天就该有界面（哪怕很丑）。如果三天都在配环境、选库、写配置文件，说明你在"准备做事"而不是"做事"——让 AI 先吐出一个能跑的丑界面，架子后面再收拾。
• 信号二：功能清单超过 10 项。数一下你的 todo list，超过 10 项基本等于"这个月做不完"。把清单按"砍掉后演示还成立吗"重排，只留前 3 项。
• 信号三：你需要"顺便"学一个新技术。"顺便学一下 WebSocket""这个得用一下向量数据库"——第一个项目的技术栈必须是你的舒适区 + AI 的舒适区。任何"学习成本"都是范围膨胀的伪装。
• 信号四：你开始跟 AI 争论架构。当你花半小时跟 agent 争论"该用 REST 还是 tRPC"，说明项目已经复杂到"值得争论"的程度——而 MVP 不该值得争论。能跑就行，架构是第二个月的事。
• 信号五：一周过去了，还没人看过你的 demo。这是最致命的。MVP 的存在意义就是被看、被用、被吐槽。如果一周了你还在"再打磨一下再给人看"，打磨的不是产品，是你的拖延症。发出去，丑也发。

真到要砍的时候，最难的不是"砍什么"，是"下得去手"。给你三句砍范围的话术，对自己说：第一句："这个功能有一百个用户时会需要，但我现在有零个。"第二句："演示那天，没人会问'为什么没有管理后台'。"第三句："砍掉的功能不是死了，是排队了——等有人付费再叫号。"范围管理的本质是跟自己的贪心谈判，这三句话是你的谈判底稿。

还有一个很多人忽略的维度：第一个项目要不要"公开构建"（build in public）？我的建议是：要，但只公开 demo，不公开代码。每天发一条 60 秒演示视频，你会被迫保持"可演示"状态——这本身就是最强的范围约束：没人想看你配了三天环境，大家想看的是"点一下，动了"。公开构建的本质，是用社交压力替代自律。更实际的好处是，你的第一批用户往往就藏在观众里——阿哲的 200 个注册，一半来自他每天发的构建视频。演示即营销，范围即内容。每天 60 秒，一年就是 365 个"可演示"的证据——这比任何简历都硬。记住：观众要的是"进展"，不是"完美"。

我的观点：vibe coding 时代，范围管理比编码能力重要十倍。

传统开发时代，瓶颈是"写代码慢"，所以大家比拼技术深度。Vibe coding 把"写代码"变成了廉价资源，瓶颈转移到了"决定做什么、不做什么"。AI 可以一晚上给你 2000 行代码，但它不会告诉你"这 2000 行里有 1500 行是不该存在的"。这个判断，只能你来做。

所以第一个 vibe coding 项目的真正目标，不是"做出一个产品"，而是完整地走完"想法→demo→有人用→迭代"这个循环一次。循环走完了，你才算真正学会了 vibe coding——后面做多大的项目，用的都是同一套肌肉。小林后来重整旗鼓，把那个 all-in-one 砍成只剩"AI 会议纪要"一个功能，9 天上线，拿到了第一批 50 个用户。他的感慨是："早知道切这么小能成，我那三周在忙什么？"

小林的"AI 会议纪要"为什么成了？因为他终于理解了：第一个项目要验证的不是"AI 有多强"，而是"我能不能把一件事做完"。"做完"带来的正反馈（用户、收入、信心），是第二个、第三个项目的燃料。做大做小是策略问题，做完做不完是生死问题。

再补充一个视角：为什么"一周可演示"对 AI 特别有效？因为 agent 是"短跑选手"——上下文窗口之内，它越专注质量越高；项目一旦拖过两周，早期的决策开始被遗忘，返工吞噬一切。小步快跑不是方法论，是 agent 的生理结构决定的。顺着它的天性做事，别逆着来。

最后留一个今晚就能做的练习：把你想做的项目写成一句话，再列出"演示那天，用户能亲手点的三个动作"。如果列不出，说明范围还是太大；如果列得出，恭喜你——你的 MVP 已经切好了，剩下的就是让 AI 开工。记住：第一个项目的目标不是"做大"，是"做完"。