用 AI 写代码已经不是什么新鲜事尤其是 vibe coding 流行以后你只要把需求说清楚从 Cursor 到各种 AI Agent都能很快给你生成一个能跑、能部署、甚至还能发到线上展示的项目。但我最近在带项目、改代码、面试候选人的过程中越来越频繁地撞到同一个现象功能全对代码也跑得通你问他这段代码是怎么实现的他讲不出个所以然。你让他不借助 AI 把核心函数重写一遍他会愣很久。这不是个例而是 vibe coding 时代一个很典型的“幻觉式掌握”AI 帮你写完了代码你产生了“我已经会了”的错觉实际上你没有参与构建过程也没有在关键决策点上留下记忆。要治这个问题我最近用得最顺的思路就是 build-to-learn——不是让 AI 替你写完而是把 AI 当作补全盲区的协作工具用“构建”代替“观看”。这篇文章会先拆清楚幻觉式掌握为什么会出现再给出一套可以照着执行的 build-to-learn 学习路径最后附上我自己验证时会做的几个测试。这个主题适合什么人看一句话你已经在用 AI 写代码但心里隐隐发虚担心再过半年自己的基本功没有增长反而越来越依赖 AI。也适合刚入行的朋友——你在别人都在刷 AI 生成项目时更需要一个能让自己真的学到东西的节奏。下面按我实际总结的顺序拆开讲。1. 先别急着怪 AI幻觉式掌握到底长什么样1.1 什么是 vibe coding 时代的幻觉式掌握Vibe coding 这个说法指的是一种“顺着感觉写代码”的开发方式。你不需要把每行语法背熟只要把需求描述给 AIAI 用示例代码、补全、自动生成帮你把项目搭出来。相比过去从 0 到 1 敲每个字符这种方式确实快尤其适合做原型验证、个人小工具、内容站、数据展示页。问题不在速度而在学习感知。“幻觉式掌握”是我自己给一个现象起的描述你反复使用 AI 编程AI 生成代码时你看起来都看懂了运行结果也正常但你实际上没有掌握。就像读书时看例题答案看完觉得很容易合上书自己做却不知道第一步怎么写。AI 时代把这种“看懂假象”放大了无数倍。我见过最典型的一句话是“代码确实不是我写的但我说得清这是干什么的。”问题就在这“说得清这是干什么”和“能独立写出来、改出来、调试出来”中间隔着一整条开发能力链。1.2 三种最常见的表现我平时观察同事、学员和开源项目贡献者的状态大概可以归纳成三类。第一类是“验收式开发”。打开 AI 编程工具输入需求点生成运行通过然后点击部署。整个过程中真正的人类动作只有“描述需求”和“验收结果”。你可能花了一下午让 AI 做了一个完整的博客站但问到你数据库连接池为什么这么配、权限校验放在哪一层你只能凭着模糊印象说“应该是在中间件里吧”。第二类是“报错转交式调试”。程序一报错不是看日志、定位变量、检查类型而是直接把整段报错复制给 AI等它给你一个新版本。这样做效率很高但代价是你永远没有练习过如何从堆栈里提取信息。等到 AI 也给不出答案的时候你连排查的起点都找不到。第三类是“名词式理解”。能说出来用的什么框架、什么模式也可以告诉你这个函数大概做什么但一旦换一个输入形式、换一种边界条件代码就不能正常工作。因为你不清楚每一行在数据流里到底起什么作用只会背概念。1.3 和以前“抄代码”有什么本质区别以前的程序员在早期也很喜欢抄代码从博客里复制一段改改跑了。但那个时代抄代码有一个隐藏的学习过程你得先找到代码文件复制进编辑器手动装依赖运行报错后自己去查是什么问题。也就是说即使你是“抄”中间也有一大段构建和排错动作。现在的 AI 编程把这些动作压缩掉了。AI 不是给你一段示例代码而是直接帮你把整个项目逻辑、异常处理、目录结构全部生成好。你跳过了学习者最该经历的那些坑。所以把“幻觉式掌握”简单理解成“偷懒”不太准确它更多是工具演进之后学习回路被绕过的结果。到这里结论已经比较清楚了不是 AI 不能用而是你在使用 AI 时没有设计学习动作。build-to-learn 的思路就是把这些动作重新放回流程里。2. 为什么你感觉学了很多一关对话框却一片空白2.1 学习依赖反馈回路AI 把反馈拿走了先扯一点认知层面的东西不复杂。人类学习一件技能核心不是“看会”而是“预测、出错、纠正、记住”这个循环。你写代码时脑子里会预测“这个变量应该这样接”运行后可能报错然后你查一下意识到原来是类型不对你就形成了记忆。这个过程不需要刻意背诵卡过壳的位置自然记得牢。用 AI 写代码时预测环节不是没有而是变成了“AI 预测、你验证”。你提前把错误处理掉自己不需要在错误点上停留于是记忆就很难落下来。这就是为什么你会觉得“学了很多”但关掉 AI 后一片空白你没有在关键节点上产生认知冲突也就没有形成长期记忆。2.2 注意力被放到验收而不是构建人在做一件复杂事情时注意力是有限的。你在 vibe coding 状态里注意力会自然放在“结果对不对、界面像不像、能不能跑”这些验收指标上。这是产品经理视角不是开发者视角。开发者视角需要关注的是数据从哪来、函数怎么拆、异常怎么兜、接口怎么设计、后续怎么扩展。这些在 AI 生成代码时都被隐藏了。你看到的是一个漂亮的结果而不是一堆需要自己做取舍的决策点。2.3 记忆缺少锚点没有经过卡壳、权衡和推翻记忆不是一个单独的仓库它是附着在情境里的。你在一个项目里真正记住的往往是那些让你卡住两个小时、最后通过两三版实验才解决的问题。AI 把这些问题都解决了记忆就没有锚点可以挂靠。举个例子。我自己早期学 Python 时印象最深的是列表和字典的区别不是在文档里看会的而是写了一个小工具把一个列表当成字典用结果反复报 key 不存在调了很久才明白。这个错误我到现在都会记得。如果当时我让 AI 直接生成我可能只知道“字典可以用 key 取值”但永远不会知道为什么直接取会报错。2.4 工具越好用避坑能力越难养成还有一点很多人没意识到AI 编程工具越智能越擅长帮你避坑你的避坑能力就越难养成。生成代码时AI 会主动帮你处理好空值、默认参数、异常捕获这些经验如果在过去需要你踩坑才能获得现在连坑都看不到。这不是说 AI 做错了而是说你在学习阶段太依赖“无坑环境”会导致你把“工具稳定”误当成“自己稳定”。等到没有 AI 或者 AI 能力不足的时候真实世界的问题马上就会露出来。所以 build-to-learn 里有一件事非常重要主动给自己制造一些“我不让 AI 处理”的环节让真实的卡壳、报错、思考重新出现。这不是倒退而是为了建立更可靠的能力底座。3. build-to-learn 的核心把“看结果”改成“参与构建”3.1 一句话原则AI 是协作者不是代写我先给一个总原则用 AI 做开发时把它当成一个经验丰富但时不时会出错的结对程序员而不是“按一下就给代码的代写工具”。协作者的特点是你把方案讲给它听它补充细节你给它一个骨架它填肌肉它给你代码你还要审查、修改、测试。代写则完全相反——你把需求丢进去等它交作业。这个心态差别决定了学习结果的天壤之别。同样是让 AI 生成一个 Python 文件重命名工具代写心态下你做的是“复制运行、成功收工”协作心态下你会先自己列出输入、处理、输出三个部分再让 AI 补全不会写的函数最后逐行确认这个 glob 匹配的是什么这个 os.rename 参数顺序对吗如果不做备份重命名失败会不会丢文件3.2 最小回路拆解、骨架、补全、审查、复述、改造我建议把 build-to-learn 落实到一条可执行的最小回路里拆解用自己的话把需求拆成功能点写成注释或伪代码。骨架先自己写出函数名、参数、主流程不会的留空。补全让 AI 补全留空部分或者让 AI 提出一种实现方式。审查逐段阅读 AI 返回的代码标出不确定的地方。复述关掉 AI 回答用自己的话把每段逻辑讲一遍。改造给项目加一个新需求逼自己进入 AI 生成的代码里改逻辑。这六步看着简单但每一步都在练习“构建”而不是“验收”。尤其是最后一步改造非常重要。如果你只能让 AI 生成代码却不能往里加一个功能说明你根本没有掌握这套代码的组织方式。3.3 每段生成代码都要做“三个对应”我审查 AI 代码时会强制自己完成三个对应缺一个都不会放进项目里。第一个是结构与命名对应。AI 生成的文件名、类名、函数名和数据结构是什么你要能在大脑中画出一张图谁调用谁谁持有数据谁负责输出。第二个是输入输出对应。每一个函数接收什么类型、输出什么类型边界情况怎么处理。比如一个 CSV 清洗函数如果某一列全部为空它会不会崩如果文件编码不是 UTF-8会不会乱码。第三个是异常路径对应。正常流程能跑不算完还要看 AI 代码对错误路径的处理是否合理。日志有没有报错是否可读失败后会不会残留半成品文件。这三个对应做完你才算真正“看过”了这段代码。否则就只是“扫过”。3.4 用“复述输出”检验是否真的学会一个我自己屡试不爽的方法每次让 AI 写完一段代码先别急着收工把那一段清屏打开一个空白文件用自己的话重新写一遍。不需要一模一样可以把变量名换掉、把 AI 的复杂写法简化但逻辑顺序和关键边界参数必须有。如果你能写出来说明这段代码已经变成你的。如果你只能写个开头就卡住说明之前只是“看懂了结果”而不是“理解了实现”。卡住也没关系这正是该回去补的位置。回去查看 AI 的代码把卡住的点圈出来然后再次清屏重写直到能顺畅完成。我在带新人时把这叫“复述输出检验”比做十道练习题都管用。因为代码是生成出来的你唯一能确认自己学会的方式就是你亲手再产出一遍。注意向 AI 提问时尽量把问题描述成“我在实现一个什么东西某个环节不确定怎么写”而不是“帮我做一个完整功能”。前者是协作后者是代写。4. 实操模板从后端小工具开始练习 build-to-learn4.1 选一个会让你卡住的题目不要选 AI 全能跑通的题开始练习 build-to-learn题目选择很重要。不要选九九乘法表、hello world也别一上来就选“做一个完整商城”。前者太简单AI 生成的代码一看就完没有构建深度后者太复杂你会因为看不懂全貌直接退回“验收模式”。我比较推荐选一类“有真实边界条件”的小工具。举几个例子Python 写的批量文件重命名工具要求支持前缀、序号、扩展名过滤。读取 CSV 文件做简单的数据清洗和统计输出汇总结果。把一段 C 语言里的快速排序实现改成支持自定义比较函数。写一个命令行配置管理器读取 ini 或 JSON支持默认值。这些题目都不大但包含输入输出、异常处理、参数选择足够逼出真实的构建过程。4.2 先自己写骨架不会的地方留注释拿到题目后不要直接打开 AI 工具。先在编辑器里新建一个文件写下你自己的骨架。比如文件重命名工具你至少可以写出def batch_rename(directory, prefix, start0, extensionsNone): # 1. 获取目录下所有文件 # 2. 过滤扩展名 # 3. 生成新文件名 # 4. 重命名考虑重名冲突 pass if __name__ __main__: batch_rename(./testdir, prefixbackup_, start1, extensions[.txt])这一步的价值很大。你在自己写骨架时必须想清楚参数有哪些、主流程分几步。很多以为自己“会一点 Python”的人就是卡在这一步拿不准不知道要不要加参数、不知道用哪个标准库函数。这些不确定之处就是接下来要问 AI 的地方。4.3 让 AI 补全“不会的那部分”而不是整段重写有了骨架你向 AI 提出的问题就具体了。你可以问“在 Python 里如何安全地遍历目录文件并避免重名覆盖请给出标准库实现。”这时 AI 会给你 os.listdir、os.path.join、os.rename 这些知识点你可以结合骨架理解。不建议的提问是“帮我写一个批量重命名工具。”这样 AI 会返回一个完整程序你的大脑很容易进入验收模式。对比一下同样是在学文件重命名前一种提问方式是“我在实现一个我自己设计的工具只是某个环节不会”后一种提问方式是“你来完成一个工具”。前者的学习精度高很多。4.4 审查和改造给 AI 代码增加需求AI 补全之后进入审查环节。我给自己的要求是把所有不确定的变量、函数、参数都查一遍。比如 os.rename 和 shutil.move 有什么区别如果目标文件已存在会怎样Windows 和 Linux 路径分割符有差异吗这些内容不一定都要写进项目但你要能回答。然后强制自己加入一个新需求。比如原版本只对 .txt 文件重命名我要求改成还可以对 .jpg 中的文件名加日期前缀。这时候你必须进入 AI 生成的代码里修改。看起来只是加一个分支但它逼你去理解现有的处理流程是怎么组织文件的新增逻辑该插在哪一层。这一步是真正“建立所有权”的时刻。代码经过你手改过才不再是“AI 的作品”而是你的工具。4.5 验证不是“能跑就行”要看边界和日志工具做完验证方式也不能停留在“运行不报错”。我一般会构造三组用例正常用例一个目录下有一批文件传入参数全部正确重命名。边界用例空目录、文件名包含空格、文件已经被占用、目标重名。错误用例目录不存在、权限不足、扩展名参数为空。在这些用例里你可能会看到 AI 生成代码的缺陷。比如它没有处理重名覆盖或者遇到权限错误直接退出而没有任何日志。这些缺陷都是很好的学习素材比单纯让 AI 生成 100 行完美代码有用得多。因为你终于可以练习“从现象推到原因”这是 vibe coding 最缺乏的一环。5. 判断自己是不是真学会了四个可复现的测试5.1 空屏测验第一个测试最简单关闭所有 AI 工具和已生成的代码打开一个空白编辑器只保留需求描述。给你 15 分钟写一个能完成核心功能的版本。如果你能写出来说明核心逻辑已经在你脑子里。如果只能写几行就停下说明你之前的工作主要是“识别和验收”没有进入程序性记忆。这个测验不需要很复杂针对你最近让 AI 写过的那个小项目就好。我自己每次学一个新库或者新的框架写法都会做一次空屏测验。测验不是一次就能过的很多时候我得做两三遍才会觉得“这个库我真的会用”。关键是这个测验会直接告诉你哪里学得不够不需要别人来点评。5.2 断链测试不看 AI 回答能不能解释“为什么”第二个测试我管它叫“断链测试”。翻出你让 AI 生成过的某段代码选一个函数遮蔽下面三行你自己补全。然后不是问“会写吗”而是问“为什么这里要这样写”。举例来说AI 在快速排序代码里写了return quick_sort(left) [pivot] quick_sort(right)。你可以问自己为什么 pivot 要放中间如果数组里有重复元素这个写法会出什么问题改成原地快排要注意什么能答上这些说明你的理解不是靠背框架而是真的明白了分区思想。5.3 埋 bug 测试主动给 AI 生成的代码制造错误这个测试尤其适合有工作经验、需要带团队的人。把 AI 生成的代码复制一份在其中埋入两三个 bug。可以修改将改成把end写错一个边界让浅拷贝变成共享引用把资源释放语句注释掉然后把代码交给另一个人让他们在不运行的情况下 review 出来。要是没人找得到说明代码的可读性本身就有问题如果只有你自己能快速定位说明你对这段代码的控制力还是可以的。反过来如果你根本不敢埋 bug因为埋进去后连自己都修不回来那就要回到第 3 节的“复述输出”流程把 AI 代码中你还不能改的地方单独拎出来练。5.4 讲给别人听测试最后是费曼式验证。找一个朋友最好也是写代码的给他讲清楚这个工具的整体设计、关键函数、边界处理。如果他问到“为什么这里用字典而不是列表”“为什么需要备份原文件”你能直接回答而不是说“AI 写的”。讲题环节往往能暴露出很多“以为自己知道但讲不清”的细节。我的经验是准备讲这个过程本身比实际讲更重要。因为你会主动去查那些以前忽略的角落比如某个全局变量何时被修改、某个函数是否有副作用。讲一遍之后你会发现自己对项目的熟悉程度高了一大截。这四个测试不是每一项都必须在学一个小项目时全做。我自己通常这样做学一个新知识点用空屏测验和断链测试熟悉一个项目后做埋 bug 测试进入团队合作或写教程时做讲解测试。你完全可以按需选择但至少要有意识地去验证一下而不是靠“感觉学会了”来判断。6. 不同基础的人AI 参与度应该不一样6.1 完全零基础先少用 AI把调试循环建立起来如果你是刚接触编程我的建议可能会和大部分人相反前几周尽量少用 AI 写代码。你可以用 AI 解释报错、推荐学习资源但不要让它直接给你完整程序。原因很简单零基础阶段最重要的不是写出复杂的项目而是建立“编写—报错—定位—修复”这个基本循环。你自己犯一个语法错误、看一次堆栈、改一次缩进比 AI 帮你写完十个功能都有价值。一旦这个循环建立不起来后面学什么都会觉得浮在表面。更具体的做法是先手写练习快速排序、文件读写、基本的列表和字典操作遇到不会的查文档实在卡住再问 AI。等你能独立完成 50 行以内的小程序再开始让 AI 参与更大项目。6.2 会写基础代码但经验少AI 是结对程序员如果你已经有语言基础能写基本逻辑但不熟悉某个框架或工程实践这时候可以像结对编程一样使用 AI。你负责写整体结构和业务逻辑AI 负责补全你不熟悉的样板代码或者提供一种新思路。这个阶段的重点是对照拿到 AI 的代码后要刻意去比较它和你自己的写法有什么不同。比如同样做一个数据库连接AI 可能用了连接池你可能用了最基本的方式。这时候你去查连接池的文档看它解决了什么问题就能把“AI 为什么这样写”变成你自己的一份经验。不建议直接大量生成几十个文件的项目。文件一多你很容易失去对全貌的控制又回到只看结果的状态。6.3 有工作经验用 AI 做方案对比和代码审查工作几年之后写普通业务代码基本不是问题。这个阶段AI 的价值不在“帮你写”而在“帮你提供方案选择和审查视角”。我会让 AI 做一个功能的两种实现一种偏性能一种偏可维护性然后我自己比较差异再决定怎么落到项目里。这个阶段学习的是“取舍能力”。比如很多人喜欢讨论 Python 量化交易策略代码、C 语言文件读写、SQL 代码排版工具这些都可以让 AI 给出实现思路但最终由你判断它是否符合项目的技术和业务约束。还要提醒一点工作阶段的代码要走正常的代码评审流程。AI 生成的代码不代表合格仍然需要跑测试、看静态检查、让同事 review。把 AI 内容当作“第一版草稿”你作为工程负责人要对最终质量负责。6.4 用一个表格总结参与方式这里给一个我自己常用来划分 AI 参与度的表格也方便你对照自己当前的状态。阶段建议的 AI 参与方式学习重点最容易踩的坑零基础解释报错、推荐资料不写完整程序语法基础、调试循环、代码感让 AI 代写代码跳过基础有基础补全不熟悉的库用法、结对编程框架思维、结构对照、边界处理整段生成又整段复制工作几年方案对比、代码审查、性能分析架构取舍、工程规范、可维护性只验收结果不做质量把控把 AI 当成一个工具而不是身份替代是每个阶段都要记住的边界。工具越强你自己越要清楚哪些动作必须亲自做。7. 实测中容易踩的坑也一起说7.1 “能跑”不等于“懂”这是我反复跟身边的人讲的一句话。vibe coding 让代码能跑的门槛降到了接近零但“能跑”只是程序员的起点不是终点。你还要能解释、能改、能调、能删、能在它出错时快速定位。一个很常见的场景AI 生成的代码在理想环境下运行成功但一旦输入格式稍微变化、并发量上来、网络抖动问题就出现了。如果你在欣赏“运行成功”的绿屏状态而不是去检查代码的脆弱点那你不是在用 AI 写代码只是在使用一个黑盒。7.2 报错不要直接丢给 AI我现在对项目的硬性要求是遇到报错至少自己看三分钟日志把报错位置圈出来再决定是否问 AI。你不需要每次都能自己解决但必须知道报错在哪个文件哪一行涉及什么变量。这决定了你是在“调试”还是在“转交”。如果确实要把报错发给 AI也建议附上你已分析出的信息比如“我怀疑是上一行对 None 调用了方法因为 data 可能为空”。这样得到的回复会更针对性而且你也会在对比中学会自己怎么排查。遇到报错时先自己看三分钟日志把报错文件、行号和怀疑原因写下来再决定是否问 AI。这个习惯对长期学习非常重要。7.3 不要批量生成之后一次性 review有些人喜欢让 AI 一次性生成十个函数然后花十分钟从头到尾读完。这不是有效的审查方式。一次处理一个函数文件完成“三个对应”之后再进入下一个。尤其是在 batch 任务里一旦你从整体扫过一遍大脑会自动忽略大量细节。我通常会让 AI 每次只生成一个模块然后我用 20 分钟消化它。虽然慢但这才是 build-to-learn 该有的节奏。7.4 依赖版本和运行环境差异AI 不一定能帮你避全AI 生成代码时往往会给出“最通用”的写法但实际环境中依赖版本、系统差异、权限问题都会影响运行。比如 C 语言代码在 Windows 和 Linux 下的文件路径处理、Python 里 pandas 的版本差异。这些并不是 AI 不会写而是它看不到你的运行环境。所以项目里只要有依赖就要自己检查 requirements 或 package.json确认版本。跑通之后再在自己的机器上做一轮最小验证而不是只看 AI 在云端演示的结果。8. 把 build-to-learn 变成一种长期习惯8.1 每周给自己留一个“纯构建时间”光读这篇文章不会有明显效果真正起作用的是把 build-to-learn 变成每周都能执行的节奏。我建议你每周找一个固定时间比如周末上午选一个小项目或一个小知识点在完全不依赖 AI 的情况下先写 30 分钟。写不出来没关系但要真实地感受到哪里卡住那些卡点就是你未来学习的方向。之后再用 AI 辅助补全做一对一对比。这样一周一练一个月下来你会明显感觉到自己不再只是“看懂代码”而是能独立完成不少事。8.2 项目复盘时用这份清单每次完成一个学习型项目可以按下面几条做一个简短复盘我在哪里卡住了为什么卡住AI 帮了我哪一部分我自己独立做的是哪一部分这段代码里有没有“我讲不清但 AI 写出来”的逻辑如果再来一遍我能不看 AI 答案重写吗下一步学什么能让这次的盲区缩小把复盘结果写下来不需要很长五六行也可以。关键是把模糊的“学到了”变成具体的项目记录。8.3 工具会继续变学习能力才是长期资产最后说点个人判断。AI 编程工具会越来越强从一个函数补全到一个 Agent 直接完成任务中间的距离会越来越短。但对你个人来说真正有长期价值的不是你能让 AI 生成多炫的项目而是你能否独立思考、拆解需求、定位问题、评估方案以及在没有外部帮助时也能完成核心交付。build-to-learn 不是一个反 AI 的方法。相反它是把 AI 放进正确位置的方法让 AI 帮你走得更快但不替你把路走完。你会的东西越多AI 对你的帮助就越大而你越是什么都不想学工具只会进一步放大你的空缺。到这里不需要再总结多少理论核心就一句话如果代码是 AI 写的你的学习不能停在“它跑通了”。你要通过构建、复述、改造、测试把那些 AI 替你完成的动作拿回来一部分。长期来看这部分拿回来的能力才是你在这个快速变化的开发环境里最靠得住的东西。