纯靠 vibe coding 做项目，卡过几次以后，你是不是也打算先去补补编程，好歹能看懂代码？
我劝你先打住。一想到自己不懂代码就心里发虚，这念头很正常，但这条路，很可能从第一步就走反了。
一天一个 vibe coding 小技巧。今天就聊这个很多人都拧巴的问题：到底还用不用先去学代码。
一、先把话说准：不用学写代码，不等于什么都不用懂
先给你个明确态度：为了 vibe coding，专门跑去学编程语法、学代码怎么写——真没必要。
你想想 vibe coding 是干嘛的？
它的本意，就是让你不用懂代码，用大白话指挥 AI 替你写。
结果你反手一头扎进代码里，这不等于又爬回了那道 AI 本来就要帮你跨过去的坎吗？
AI 出现，图的就是把「写代码」这道门槛给抹平。你不去吃这个红利，反倒自己费劲爬回墙里头，图什么呢？
但这话，有一半人会听岔。
不用学写代码，不等于什么都不用懂。
你可以不会写前端，但你必须知道前端到底在管什么。
你可以不会设计数据库，但你必须知道数据为什么不能随便动。
你可以不会部署，但你必须知道「我自己电脑上能打开」和「用户能访问」，根本是两回事。
这两件事，差得远。
一个是让你掌握「代码具体怎么写出来」，另一个是让你搞清楚「这东西大概怎么运转、哪儿最容易出事」。
前者，AI 已经替你扛了。
后者谁也替不了你。因为最后拍板的那个人是你。
二、你是哪种人，决定的不是学不学，是学到多深
「要不要学代码」这个问题吵到今天还没完，是因为大家回答它的时候都漏了一个前提：你学它，是为了什么。
来看两种最常见的人。
第一种，你手上有个想法，想赶紧做出来，先试试到底有没有人用。
那你更不该去碰代码。
你缺的不是代码，是时间。
一个想法的窗口期就那么长，你花三五个月啃语法，等你能写出第一个页面，这事可能已经有人做出来上线了。
第二种，你是想转行，或者想把这件事变成以后吃饭的本事。
按老规矩，这时候该劝你「那你就老老实实从头学」了。
但我要说句可能不太受欢迎的实话：深度学代码这条路，今天的性价比是崩的。
你先别急着反驳，我说的不是它没用。
它有用。崩掉的是另一样东西——稀缺性。
你以前能靠代码吃饭，很大一部分原因不是这门手艺本身有多神圣，而是会写的人少。你会写，你就是门槛，你就能接活。
现在这道门槛被抹平了。
你辛苦学三个月写出来的那些东西，AI 几秒钟就写完了，而且比大多数人写得还规整。
这不是我一个人的感觉，是有数的。
今年四月，谷歌 CEO 皮查伊在 Google Cloud Next 大会上公布：谷歌所有新增代码里，75% 是 AI 生成、再由工程师审核通过的。
你看看这条线是怎么走的：2024 年 10 月 25%，去年秋天 50%，到今年四月，75%。
一年半，翻了三倍。
微软那边，纳德拉去年四月也说过，自家部分项目里 20% 到 30% 的代码是 AI 写的。
所谓「稀缺性被抹平」，不是一件将来会发生的事。是在过去这一年半里，已经发生完了。
那它替不掉的是什么？
是判断力。
需求想不想得清，方案对不对，出了事知道往哪儿查，交出去的东西敢不敢负责。
而这几样，恰恰都不是学语法能学出来的。
它们是做项目做出来的，是被同一类问题坑过几回，才慢慢长出来的。
还有一组更反直觉的数字，对你比上面那些更有用。
去年七月，一家叫 METR 的研究机构做了一次随机对照实验。
他们找来 16 个资深开源开发者，在各自维护了好几年的项目里做 246 个真实任务，每个任务随机决定允不允许用 AI。
开工之前，这些人预测 AI 能让自己快 24%。
做完之后，他们认为自己确实快了 20%。
实际测出来：慢了 19%。
看走眼的还不只是他们。实验之前，经济学家和机器学习专家给出的预测是快 38% 到 39%。
慢在哪儿了？
省下来的敲代码时间是真省了。但全被另外几件事吃回去了：审查 AI 交出来的东西、反复改提示词、等它跑完，还有等待过程里那些干耗着的空档。
你可能会说，那这不正说明还是得自己会写吗？
恰恰相反。
这十六个人写代码的本事一点问题都没有，他们是各自项目里最熟的那批人。
他们输在了别的地方——瓶颈已经从「写」挪到了「判断和驾驭」上。而这一样，他们没练过。
最要命的是最后那笔账：以为自己快了 20%，实际慢了 19%，中间差了将近四十个百分点。
这四十个百分点，就是「会用」和「以为自己会用」之间的距离。
不过这组数字有保质期。
它测的是 2025 年上半年的 AI。今年二月 METR 又发了一轮新的，换上更新的模型、人数扩到五十多个，这回原来那批人里，已经测出加速了。
所以别把「AI 让人变慢」记成铁律，工具确实在往前走。
但那四十个百分点的落差，不会因为模型变强就自动消失。
它量的从来不是 AI 快不快，而是你对自己的判断准不准。
而这份准头，学语法是量不出来的。
所以两种人的区别，从来不是一个不用学、一个得回去学代码。
是同样这些东西，第一种人学到够把自己的想法做出来就行；第二种人得学到能对别人的项目负责。
差的是深度和项目量，不是换一条路。
再说得直白一点：你要是真想入这行，最快的路不是先报个班学三个月语法，而是现在就开始用 AI 做项目，一个接一个做，把坑一个个踩过来。
我知道这话听着不太像正经建议。
那你换个角度想：一个学了三个月语法、一个项目都没做完的人，和一个用 AI 做完了五个项目、每个都真上线过、每个都出过事故的人，你会把活交给谁？
至于第一个项目该挑什么，上一集专门讲过：想法可以大，但第一版必须小到能真正走完，只服务一个用户，只跑通一条核心流程。
没看过的，可以翻回去补。
当然我也得把话说全：如果你的目标是进大厂当一名正式程序员，那是另一条路，该考的东西还是会考，这一篇管不了你。
但如果你想的是自己做产品、自己接单，或者在现在的岗位上多一项拿得出手的本事，那我上面这些话就是认真说的。
三、「浅浅学一下，至少能看懂报错」——这是最大的一个误区
不管你是上面哪一种，这会儿心里可能都还留着一条退路：那我不学那么深，就学一点点，至少学到能看懂代码，行不行？
那我得告诉你，这事没你想的那么容易。
看懂代码，从来不是背几个语法、上几节课就行的。
它靠的是长年累月做项目、踩坑，一点一点沉淀出来的经验。
那再退一步呢？
「我不用学那么深，浅浅学一点，至少能看懂报错，总行了吧？」
想法很美好，但这可能是整篇里最大的一个误区。
因为程序的报错，是千奇百怪的。
同一句报错，可能是这个地方的问题，也可能是完全另一处牵连出来的；有时候它指着的那一行，根本就不是真正出错的地方。
我跟你说个可能有点颠覆的事实：一个专业程序员，也不可能把每一条报错都说清楚到底为什么。
那他凭什么解决得那么快？
不是因为他「看懂」了，而是因为他知道方向。
同样一条报错甩到他面前，他心里立刻会冒出来：这类问题一般出在哪几个地方、先从哪儿开始查、哪几个方向可以直接排除掉。
他干的事是缩小范围，不是读答案。
那这份方向感，又是从哪儿来的？
是他做过很多个产品、踩过很多套技术栈、被同一类问题反复坑过之后，一点点攒出来的。
这东西，没有任何一条速成的路。
你「浅浅学一下」，最多能认出报错里那几个英文单词，可你依然不知道该往哪儿查。
而「往哪儿查」，才是真正值钱的那部分。
所以，一个刚上手、又没有技术背景的新人，指望速成看懂报错，既不现实，也真没那个必要。
这条追赶，你追不上，其实也不用追。
换个角度想，你真正需要的，从来就不是「自己能看懂报错」。
你需要的，是能让 AI 把这条报错讲明白，再判断它到底修对了没有、有没有在糊弄你。
它讲的你要是还听不懂，就让它换成大白话重讲一遍，讲到你能听懂为止。
这件事，不需要几年经验。
四、方向一：学一点 UI 设计
你要是愿意花心思学东西，我举双手赞成。只不过方向得对，不然全是白花的时间。
我给你三个方向，先说第一个：学一点 UI 设计。
很多人用 AI 做东西，最头疼的就是：怎么 AI 写出来的界面，总是又丑、又不对味？
这事，你大概率会怪 AI 不行。
但更多时候，问题出在你自己身上——你根本没把「想要什么样子」讲清楚。
你心里只有一个模糊的「好看」，可「好看」这俩字，对 AI 来说什么都不是。
你要的，和你说出来的，对不上，它只能靠猜。
学一点 UI 设计，救的就是这个。
它会让你知道一些专业的说法：什么叫留白，什么叫层级，什么叫主色调，什么风格叫扁平，毛玻璃那种半透明质感叫玻璃拟态。
举个最直接的对比。
以前你会说：「这个页面做好看点。」
这句话对 AI 来说，几乎等于什么都没说。
学完之后你会说：「主色调用深蓝，卡片之间的留白再大一点，标题和正文的字号拉开层级，整体走扁平风格，不要加阴影。」
同样一件事，后面这句它能直接照着做，前面那句它只能靠猜。
学 UI 还有第二个好处，很多人没想到：它让你有能力判断结果好不好。
AI 交出一个页面，你不能只有一句「感觉怪怪的」。
你得说得出哪儿怪——是间距不匀，是层级没拉开，还是颜色用太多了。
你说得出来，它才改得动。
这部分入门不难，花点时间就能摸着门道。
但我也得说句实在的：这顶多是让你能把界面说清楚、看明白。
真正能做出又好看又好用的设计，背后靠的是审美、经验和想法，不是学几个术语就能速成的。
五、方向二：搞懂 AI 到底是怎么工作的
第二个方向，花点时间搞明白一件事：你天天使唤的这个 AI，到底是怎么干活的。
这个不用学多深，抓住一个核心事实就够了。
大模型干的事，本质上只有一件——根据你给它的上下文，一个词一个词地往下生成。
注意，是「生成」，不是「查询」，更不是「知道」。
它不是从某个数据库里翻出一个正确答案交给你，而是根据前面的内容，算出接下来最像样的一段话。
大部分时候这段话是对的，因为它见过海量正确的例子。
可一旦碰到它没见过、或者见得不够多的东西，它照样会生成——生成一段读起来一样通顺、一样自信，实际上却是编出来的东西。
这就是大家常说的「一本正经胡说八道」。
它不是坏了，这是它的工作方式决定的。
那你可能要问：它明明能读我的文件、能联网、能敲命令，还能记住我上次说过的话，这些又怎么算？
关键就在这儿——这些本事，都不是模型自己长出来的。
它们是外面那套系统，一层一层给它接上去的。
读文件、联网、执行命令，是工具接上去的。
记住项目信息和历史对话，是记忆系统喂进去的。
长期守规矩，是规则文件加上去的。
按一套专业流程干活，是 skill 装上去的。所谓 skill，就是别人把一套做事流程打包好，让 AI 照着走。
模型本身，只是坐在正中间那个「根据上下文往下生成」的核心。
想通这一层，四条最实用的边界就自己冒出来了。
它能执行，不等于它理解你的项目。命令跑通了，方向可能整个是错的。
它有记忆，不等于它永远不忘。记忆是外挂的，就有装不下、丢东西的时候。
它有规则，不等于它永远不违反。规则只是塞进上下文里的一段文字，不一定每次都塞得进去，更不是一道锁死的程序。
它能给出答案，更不等于这个答案已经被验证过。它负责生成，不负责保真。
这四句话，才是这个方向真正的收获。
因为它们直接决定了一件事：你什么时候可以放手让 AI 干，什么时候必须停下来跟它要证据。
改个小样式、调一段文案，放手让它做，错了你一眼就看得见。
可一旦碰到数据、权限、支付、上线这些地方，就绝不能只听它一句「已经处理好了」，必须让它把依据和验证结果一起交出来。
你越清楚这些边界，就越不容易走极端。
不会把它当成一个无所不能的神，一出错就失望地说「AI 也不过如此」。
也不会因为它编过一次，就再也不敢用了。
它就是个能力很强、但脾气很明确的干活伙伴。
你摸清了它的脾气，才使唤得动它。
六、方向三：学会把一个项目「讲清楚」
第三个，也是最值钱的一个：练会把一个项目，从头到尾讲清楚。
这里头有两层。
第一层，是运行逻辑。
用户从打开你的东西，到真正用起来，整个流程是怎么一步步走的；这中间又需要哪些功能、哪些数据。
第二层再往深走一点：这个产品到底靠什么留住人？它解决了谁的什么麻烦？
假设你要做一个帮小区业主报修的小工具。
运行逻辑这条线，你得能这么讲出来：
业主打开页面，先选自己住哪一栋、哪一户；
拍一张照片，写一句坏了什么；
点提交，物业那边收到一条新工单；
物业修完点完成，业主收到一条通知。
这条线一讲完，AI 立刻就知道该做几个页面、要存哪些数据、谁能看到什么。
这就叫把运行逻辑讲顺了。
而第二层，是接着追问一句：这东西凭什么有人用？
业主原来是打电话报修，打完之后不知道有没有人管、什么时候来。
所以你这个工具真正解决的，根本不是「报修」，而是「报完之后心里没底」。
那反过来，最该做好的就不是表单多漂亮，而是那条进度通知。
你看，第二层想清楚了，第一层的重点也跟着变了。
这就是产品思维在干的事。
它让你不只是「有一个点子」，而是能把这个点子，讲成一个 AI 照着就能做、做出来还真立得住的东西。
七、这三样，各管一件不同的事
你发现没有：这三个方向，没有一个是让你去学写代码的。
学 UI，管的是「说得准」。你能准确描述你要的界面，也能判断它给的到底好不好。
搞懂 AI，管的是「信得对」。你知道什么时候可以放手，什么时候必须要证据。
学产品，管的是「想得清」。给谁用、解决什么问题、核心流程怎么走。
说得准、信得对、想得清。
三件不同的事，缺哪一样，都会在不同的地方翻车。
只会说、不会判断，AI 一忽悠你就信；
只会判断、说不清楚，它根本不知道你要什么；
前两样都有、产品却没想明白，那就是做得又快又好，方向全错。
还有开头说的那点技术底子：前端在管什么，数据为什么不能随便动，本地能打开不等于用户能访问。
这些不用你会写，但你心里得有数。它们托着上面那三样。
八、最后
所以，回到开头那个纠结：用 vibe coding 做东西，还用不用先去学代码？
我的答案是：真不用。
你只是想把手上那个想法做出来，不用。
你想转行、想靠它吃饭，也不用。你缺的不是语法，是判断力，而判断力只能靠项目量喂出来。
写代码这份苦活累活，AI 已经替你扛下来了。你再一头扎回去，又慢又难，还白白错过了 AI 给普通人的这份红利。
但也千万别听成「什么都不用学」。
你不用学代码怎么写，但界面得说得准，AI 得信得对，产品得想得清。
这三样，才是你真正该花时间的地方。
你的目标，从来就不是把自己熬成一个程序员。
而是它交出来的东西，你能看出哪儿不对，也说得出该往哪儿改。
最后再补一句，是 METR 那十六个人替你花钱买来的教训。
这件事没有资历豁免。写了很多年代码的人，照样会以为自己快了 20%。
想知道自己到底行不行，最靠得住的办法只有一个：真做项目，真上线，真出一次事。
