纯靠 vibe coding 做项目，最容易把人劝退的，不是 AI 不会写，而是项目没做出来，人先被一轮轮返工耗没了信心。
不是代码写不动，是你一上来就想搞个大的：前端、后端、管理后台一次配齐，登录、支付、会员和权限全上。
AI 当然敢接，很快就能甩出一大堆页面和文件。可越往后，越改越乱——项目看着越大，离真正能用反而越远。
一天一个 vibe coding 小技巧。没有技术背景的人，为什么我一直建议先从小项目开始？这一篇就讲清楚。
一、大项目真正难的，从来不只是代码多
AI 写代码的速度很快，很容易让人产生一种错觉。
只要 AI 写得够快，大项目和小项目好像也没多大差别。
可一个大项目，真正难的从来不只是多写一大堆代码。
它其实是一连串互相咬在一起的决定。
产品给谁用，先解决哪个问题，用户从哪里进来，又要经过哪些步骤才能完成一件事。
不同的人能看到什么、能修改什么，数据存在哪里，一个功能改了以后会不会影响另一个功能。
页面怎么设计，异常情况怎么处理，做完以后怎么测试，又怎么真正交给用户使用。
代码只是把这些决定变成程序。
AI 可以替你完成大量实现，却不能凭空知道你心里真正想要的答案。
你没有说清楚的地方，它就只能自己猜。
项目越大，需要猜的地方越多。
前面一个决定猜错了，后面的页面、数据和功能，可能全都跟着建立在错误的前提上。
等你终于发现问题，往往已经不是改一句话、换一个按钮，而是前面一大片都得重新来。
所以对一个刚开始 vibe coding 的人来说，大项目最可怕的地方，不是 AI 写不动。
而是你还没有能力判断，它到底在哪一步已经走偏了。
二、规则管得住 AI，管不了产品
一套清楚的规则，确实能让 AI 稳很多。
它可以约束 AI 不要乱改文件，不要到处打补丁，做完以后必须拿出测试和证据。
但规则管的是 AI 应该怎么干活，不能替你决定产品本身应该怎么走。
如果你不是产品经理，也不是 UI 设计师，更不是专业技术人员，你刚开始缺少的，其实是三种不同的经验。
第一种，是产品认知。
你要慢慢学会判断：这个东西到底给谁用，解决的是什么问题，用户为什么愿意留下来，第一版什么必须有，什么现在根本不用做。
第二种，是产品流转。
也就是一个人打开你的产品以后，第一步做什么，下一步去哪里，什么时候需要输入信息，最后怎样拿到结果。
这条线如果你自己都没有想顺，AI 做出来的页面再多，也只是一些互相连不起来的零件。
第三种，是项目工程化的思维。
这个词听着很技术，其实说白了，就是不能只盯着眼前这个功能能不能跑。
你还得慢慢意识到：代码要有稳定的结构，数据不能随便改，重要修改要留退路，做完要测试，上线以后还要能继续维护。
这些能力，很难靠看几篇教程一次补齐。
它们必须在一个个真实项目里，碰到问题、解决问题，再回头总结，才会慢慢长出来。
三、小项目不是玩具，而是你的练习场
所以我说的从小项目开始，不是让你永远只做一些没用的小玩具。
真正适合练手的小项目，首先得解决一个真实问题。
可以是帮你批量整理文件的小脚本，也可以是记录某一类信息的小工具，还可以是替你省掉一段重复劳动的简单页面。
它不一定复杂，但要有头有尾。
谁在用，解决什么问题，从哪里开始，到什么结果算完成，都能说清楚。
判断一个项目够不够小，也不要只数它有几个页面。
有些项目看着只有三五个页面，背后却同时塞着多种用户、复杂权限、支付和一大串互相影响的流程。
这种项目对新人来说，一样很大。
真正的小，是只服务一个主要用户，只解决一个具体问题，只跑通一条核心流程。
范围小了，你才有机会把一条完整的开发过程，从头到尾走完一遍。
而只有真的走完一遍，你才摸得到那些光看教程永远学不到的东西。
AI 喜欢在哪些地方偷懒。
什么要求只说一遍，它转头就忘。
哪些规矩，必须白纸黑字长期写下来。
以及最要紧的那一条：什么叫「页面能打开」，什么才叫「这条功能真的跑通了」。
这两句话听着像一回事，中间差着十万八千里，也最容易被当成「做完了」。
这些认识，才是你以后驾驭大项目真正的底气。
而且小项目还有一个特别重要的作用：先让你爽一把。
当一个完全由你提出、由你指挥 AI 做出来的东西，真的在电脑上跑起来，甚至开始替你解决问题，那种成就感非常直接。
你会第一次真正相信：原来我不是只能看别人用 AI，我自己也能把东西做出来。
先尝到一次完成的甜头，比一上来困在一个永远做不完的大项目里，更容易让你走下去。
四、大想法不用放弃，但要先切出最值钱的一小块
但从小项目开始，并不意味着要把真正有价值的商业想法先放到一边。
如果你手里已经有一个很好的商业想法，你的第一个小项目，完全可以直接从它里面切出来。
只切最能证明它价值的那一小块。
以前没有技术团队，一个普通人脑子里有了产品想法，往往只能先找人开发。
想把一个商业产品完整做出来，普通人得先掏一笔不低的开发成本。
更麻烦的是，钱花出去之前，你根本不知道市场到底要不要这个东西。
先押上真金白银，再去赌一个从没验证过的想法——这就是过去普通人做产品，最大的那道坎。
AI 真正给普通人带来的机会，就是把第一次验证想法的成本，狠狠压了下来。
但说到这儿，得先纠正一个几乎人人都理解反了的词：MVP。
MVP，最小可行产品。
大部分人一听「最小」，脑子里想的是：把正式产品的功能砍掉一大半，先做个简配版上线。
不对。
MVP 根本不是一个「功能少一点的产品」。
它是一次实验。
你心里那个想法，本质上是一个还没被验证的假设——你假设某一群人，有某一个麻烦，并且愿意用你这个办法来解决。
MVP 要干的唯一一件事，就是用最小的代价，把这个假设验证一次。
所以判断你的 MVP 做得对不对，从来不是看它做了几个功能，而是看一句话：
它能不能让你尽快知道，这个想法到底成不成立。
顺着这个标准，什么该做、什么不该做，一下就清楚了。
登录、注册、个人中心、后台管理，这些每个产品都有的东西，一个都证明不了你的假设，第一版能不做就不做。
而那件最能证明价值的核心事，必须让用户从头到尾亲手做完一次。
这里还得再分清一样东西：产品原型。
如果你现阶段只是拿给投资人、拿给合作方看，先做一版能完整演示想法的原型，完全可以。
但你自己心里得有数——
能演示，只能证明这个想法别人看得懂。
真实用户愿意用、愿意留下来，甚至愿意掏钱，才叫这个想法真的被验证过。
这两样都有用，但它们绝不是同一份证据。
很多人做完一个漂亮原型，收了一圈「这个想法不错」，就以为自己验证过了。
其实到那一刻为止，一个真实用户都还没有。
等市场真的有人愿意用，或者投资人已经看见了商业价值，你再找专业的产品、设计和技术人员，把它做成真正能长期运营的产品。
到那时，这一版代码能不能继续用，反而不是最重要的。
更值钱的是，你已经验证了方向，还留下了真实的页面、流程、用户反馈和产品边界。
专业团队接手的，不再只是你脑子里一句模糊的想法，而是一个已经能被看见、被讨论、被验证的东西。
所以真正要缩小的，从来不是你的野心。
而是你第一次拿来验证野心的范围。
五、反复重做很正常，但每一轮都要留下东西
这一篇说的是更前面一步——别让项目一开始就大到，三天两头只能推倒。
即便范围收小了，来来回回折腾几次，对完全没有技术背景的人来说，仍然很正常。
这里说的折腾，也不一定每次都是把整个项目删掉重来。
更多时候，是产品范围、页面流程和技术结构，一轮一轮往回改。项目越复杂，不确定的地方越多，往回改的次数就越多。
别说刚上手的新人。
就算是专业程序员，第一次拿到 AI，也不一定马上知道该怎么跟它配合。
我自己最开始用 AI 做项目，就推翻过两三次。
第一次翻，是因为我根本没想清楚这东西给谁用。功能想到哪儿加到哪儿，AI 也照单全收，做到一半我自己都说不出这产品到底解决什么问题，只能停。
第二次翻，是我学乖了，需求想清楚了，可我没管地基。前面几个页面写得挺顺，等功能一多，AI 开始改这儿坏那儿，我又看不懂它到底动了什么，最后还是推倒。
第三次才做成。做对的其实就两件事：动手之前先把要做什么写下来，以及先让 AI 把骨架搭好，再往里加功能。
你看，前两次翻掉的代码，一行都没留下。
但那两条经验，我到今天还在用。
所以一次没做成，真不代表你没有这方面的能力。
很多时候，你只是刚刚通过这次失败，知道了哪些需求必须提前讲清楚。
也知道了哪些结构必须先搭好，哪些规矩不写下来，AI 就会反复犯。
不过，正常返工，不等于可以闭着眼睛重复返工。
如果每一次重来，都只是重新开个文件夹，把同样一句需求再发给 AI，那不是积累。
你只是期待这一次它突然变聪明，本质上还是在碰运气。
真正有价值的重来，每一轮都应该留下三样东西。
第一，留下更清楚的产品认知。
这一次到底为什么做偏了，哪个功能其实不需要，哪条用户流程之前没有想通，下一次要把边界收在哪里。
第二，留下更有效的 AI 规则。
它这次为什么失控，哪类修改总爱顺手乱动，哪条规矩以后每一个项目都该守。
第三，留下一个稳定的过程。
什么时候先讨论，什么时候再开发，做到哪一步要测试。
哪些关键版本要保存，出了问题又从哪里退回来。
只要这些东西留下来了，哪怕代码真的推翻了，你也不是回到原点。
你的页面可以重做，项目文件可以重建，但你对产品和 AI 的认识已经往前走了一大截。
下一次至少不会再从同一个坑里起步。
六、最适合新人的路线，是一次只增加一点难度
没有必须立刻验证的商业想法，就先找一个自己真的用得上的小需求。
第一个项目的目标，不是赚钱，也不是证明自己能做出多大的系统。
它只负责一件事：让你完整走过一次从想法到成品的全过程。
做完第一个，再做第二个。
第二个可以比第一个多一点数据，多一个页面，或者多一段需要认真设计的流程。
一次只增加一种难度，不要一下又把所有复杂东西塞回来。
如果你已经有一个很想验证的大想法，也不用先绕出去练几个月。
直接问自己：这个产品最核心的价值到底是什么？
如果只能让用户完成一件事，哪一件事最能证明这个想法成立？
先把这一件事切出来，让它成为你的第一个小项目。
等这一小块跑通，你再决定下一块该加什么。
判断它有没有真的跑通，别只看 AI 说没说「完成」，也别只看页面能不能打开。
有两件事必须同时发生。
第一，你要能亲手从头走完那条核心流程，拿到你预期的那个结果。
第二，AI 要说清楚它做了哪些检查、拿出了什么证据。
嫌每次都要想怎么问麻烦，就把下面这句存下来，每做完一块直接发给它：
「这一块我要验收。请告诉我三件事：核心流程是哪几步、我从哪里开始能亲手走一遍；你跑了哪些测试，分别是通过还是失败；还有哪些情况你根本没有验证过。不要只回复『已完成』。」
它给的内容你看不懂，就让它用大白话重讲一遍，直到你自己能判断这件事到底完没完成。
确认完了，再留下一份稳定版本，以及这一轮总结出来的新规则，然后才继续加下一块。
这样走，你既没有放弃大目标，也不会让大目标在第一步就把自己压垮。
七、最后
别拿第一个项目，去证明自己能不能做出一个大产品。
先让它帮你学会：怎么把产品想清楚，怎么和 AI 配合，怎么把一件小事真正做完。
反复修改不可怕，推翻重来也不可怕。
真正可怕的是，你在一个远远超过自己当前能力的项目里反复消耗，最后把对 AI、对项目、甚至对自己的信心，一起耗光。
所以，你的想法可以很大。
要缩小的从来不是你的野心，而是你第一次拿来验证野心的范围。
每走完一个小项目，你都会多认识一点产品，多摸清一点 AI，也多沉淀一套属于自己的方法。
等这些一层一层攒起来，那个曾经压在你面前的庞然大物，就只是一条你已经知道该怎么走完的路。
