开篇 / 第 1 章

放下三个误解

在学任何技巧之前，先把三个错误想法从脑子里拆掉。 它们不会让你少学一点，反而会让你多努力三倍却效果更差。

预计阅读

12 分钟

前置

无，从这一页开始

关键词

判断权、需求、方法

读完这一章，你能

• 把“判断 AI 做得好不好”拆成自己管的部分和可以交给 AI 的部分；
• 用一句话解释为什么 AI 越强，说清需求越重要；
• 判断一个任务适不适合“不读代码、只看行为”地做。

误解一：「我不懂代码，所以我判断不了 AI 做得好不好」

这是最要命的一个，因为它会让你放弃所有判断权，变成 AI 说什么就信什么。

我们先把"判断"拆开。你其实有两种完全不同的判断要做：

看出关键了吗？左边那三件事，AI 比你更没资格判断，因为只有你脑子里有"我要什么"这个标准。 它做得对不对，最终只有你知道。

而右边那三件事——代码写得好不好、安不安全、以后好不好改——你可以不学，但你不能不管。 办法不是自己学会读代码，而是让 AI 换一个身份来审查 AI。 这个技巧叫"让 AI 审 AI"，第 5 章会详细讲。

误解二：「AI 越来越强，我就越来越不需要方法」

AI 变强，确实会让一部分技巧失效。但有一件事不会失效，反而会变得更关键：

你描述需求的能力，会成为唯一的瓶颈。

想象你请了一支全世界最强的装修队。你说"随便弄弄，好看就行"。 三个月后你回来，看见一个金光闪闪的欧式宫廷风客厅——他们做得极其出色，完全达到了"好看"的标准。 但你要的是日式极简。

问题不在装修队。对方能力越强，"你说清楚"的价值就越高，因为一旦跑偏， 他们跑得越快、跑得越远、纠错成本越高。

误解三：「vibe coding 就是随便说说」

这个词是 Andrej Karpathy 在 2025 年初提出的，原话是"完全交给感觉"、"忘记代码的存在"。 听起来很随意——但它的原始定义里有一个非常关键的限定：

Vibe coding 是一种工作方式：用户接受 AI 写的代码，但不做人工审查。 diff（改动内容）被当成不透明的——重要的是程序行为对不对，而不是里面写了什么。

注意，它讲的是一种"审查方式上的取舍"，不是"随便说、随便信"。 这个取舍的账是这么算的：

• 你省掉的：读代码。而这通常是人机协作里最慢的一步。
• 你付出的：行为以外的东西你全都没查——一个被写进日志的密码、一个没处理到的边界情况、 一个悄悄算错的数据，都会直接上线。

所以它划出了一条清晰的适用范围：失败代价小的代码，这么干才划算。

还有一个最容易被忽略的点：vibe coding 的账，是延迟结算的。

整份教程的目标，就是让你拿到第一天的爽，同时不滑到第四格。

那正确的姿势是什么？

不是"完全不 vibe"（那就丧失了 AI 最大的效率优势），也不是"闭眼 vibe"（那就滑向第四格）。 正确的做法是换一套检查手段：

三句话带走

1. 你判断行为，AI 判断代码。分工不同，不是能力不足。
2. AI 越强，“说清楚”越值钱，因为一旦跑偏，它跑得越快、越远。
3. vibe coding 是一种明确取舍：省掉读代码，代价是行为以外的错误全不设防。只适用于失败代价小的场合。

自测：三个问题

你完全不会读代码，怎么判断 AI 做的登录页能不能用？

用行为验收：输入正确账号能不能进、输错会不会提示、刷新后还在不在、换一台设备会怎样。 你不需要看懂密码是怎么加密的，但你要亲手把这些路径走一遍。

为什么“AI 更强了，所以不用学方法”是反的？

因为能力越强，跑偏时造成的破坏越大。装修队越专业，你越要把“日式极简”说清楚， 否则他们只是更快地做出一个你不想要的东西。

什么情况下不该“纯 vibe”，必须有人逐行看过？

涉及别人的账号、支付、隐私数据，或者要给别人长期使用的正式产品。 还有会删数据、覆盖原文件的一次性脚本——代价太大，至少先让 AI 说明要做什么，你点头再执行。

动手 10 分钟

写下你最近想做的一个小工具，只回答三个问题：

1. 谁会用？只有你自己，还是别人也要用？
2. 最坏情况下，它出错会造成什么后果？丢数据、丢钱，还是只是难看？
3. 它要活多久？一次性用完就扔，还是要用一年？

然后对照上面的矩阵，看它落在哪一格。落在右上角（长期 + 代价大）的，先不要纯 vibe。

如果你看到 X，大概率是 Y

• AI 总说“你说得对” → 它可能只是在顺着你。让它复述一遍你的需求，看它是不是真的理解。
• 功能越加越乱 → 你没有定义“什么算做完”。先写验收标准，再让它动手。
• “先做出来再说” → 如果这件事涉及真实用户的数据或钱，先停下来补检查。