先说一个可能有点反直觉的观察:当你真正开始用 AI 写东西,你敲键盘的时间会大幅减少,但你需要想清楚的时间反而变多了。
这就是 vibe coding 的核心。它经常被误解成「让 AI 替你打字,你就能不懂技术也做出软件」——好像是一条偷懒的捷径。真做过一阵你就会发现,恰恰相反:它把工作里最省力的那部分(把已经想好的逻辑翻译成代码)交给了机器,而把最费脑的那部分(到底要什么、怎样才算对)牢牢留给了你。
角色变了,不是工具变了
传统写代码,你同时扮演三个角色:决定做什么的人、把它翻译成代码的人、检查它对不对的人。三件事在你脑子里几乎是连在一起的,以至于你很少意识到它们是三件不同的事。
Vibe coding 把中间那个角色外包了出去。于是另外两个角色突然被放大——它们本来藏在打字的节奏里,现在暴露在聚光灯下:
- 决定做什么。AI 不会替你决定产品该长什么样、这个边界情况该怎么处理、两个方案该选哪个。它只会把你说出口的东西做出来。你想得有多清楚,它就能做得有多准。
- 检查它对不对。AI 会非常自信地交给你一个看起来完全正确、实际上错了的东西。判断「这到底对不对」的责任,一点没减,反而更重了——因为你没有亲手写过每一行,不能再靠「我记得我是怎么写的」来兜底。
会用 vibe coding 的人和不会用的人,差距不在于谁的 prompt 写得花哨,而在于谁更清楚自己要什么、谁更知道该在哪里踩刹车。
为什么「说清楚」这么难
因为我们平时说话是极度依赖上下文的。你对同事说「把这个订单的钱退了」,他知道要判断订单状态、要不要通知用户、退款走原路还是余额、并发怎么处理——这些你都没说,但他会补。
AI 也会补,但它补的是最常见的那种做法,不一定是你这个场景里对的那种做法。它没有在你的项目里泡过三个月,不知道你上周刚因为某个坑栽过跟头。所以 vibe coding 里最值钱的技能,是把那些「不言自明」的东西重新变成明说的。
这不是让你写更长的 prompt。是让你在开口之前,先逼自己把一件事想到底:成功长什么样?哪些情况必须处理?哪些我其实还没想清楚、需要先问一问?这个思考过程,以前藏在你边写边改的手感里;现在它被拎到了前面。
它不会让你不必懂技术
市面上最大的误导,是把 vibe coding 说成「不懂代码也能做软件」。短期确实能唬住人——一个下午做出个能点的原型,谁都会兴奋。但只要东西稍微复杂一点、开始有真实用户、开始有钱经手,你就会撞上那堵墙:
AI 交给你一个方案,你看不出它哪里有隐患。它说「已经处理好了」,你没有能力判断这句话是真是假。等到出了事——数据错了、钱算错了、用户进不来——你甚至不知道该从哪里查起。
所以更准确的说法是:vibe coding 降低了动手的门槛,但没有降低判断的门槛。你依然需要懂足够多的技术,来看懂 AI 在做什么、来问出对的问题、来在它出错时闻到不对的味道。区别只是,你不再需要记住每个 API 的参数顺序了。
那它到底好在哪
说了这么多「它不是什么」,也得说说它真正的价值——那是实打实的:
- 想法到实物的距离被压缩了。过去一个念头要变成能跑的东西,中间隔着大量枯燥的翻译工作,很多想法就死在了「懒得写」上。现在这段距离短到,你可以把「要不要试试」变成「先做出来看看」。
- 你能同时推进更多事。把清晰的任务交出去之后,你可以去想下一个问题,而不是卡在当前这段代码的语法上。注意力从「怎么写」挪回了「做什么」。
- 它逼你成为一个更好的思考者。这点最容易被忽略。因为你必须把需求说清楚才能得到好结果,久而久之,你会习惯性地把每件事都想得更透。这个习惯的收益,远远超出写代码本身。
一句话
如果要我把 vibe coding 浓缩成一句话:你负责想清楚要什么、并为结果负责,机器负责把它做出来。
它没有让编程消失,只是把编程里最有价值的部分,还给了你。后面几篇,我会具体讲「怎么把需求说成 AI 能照着做的规格」,以及「什么时候能信它、什么时候必须自己核」——那两件事,才是把这套方法真正用好的关键。