最近跟几个做开发的朋友聊天聊到 vibe coding 的时候大家都有一个挺矛盾的体验AI 生成了一段脚本跑通了功能也正常但让原作者讲一下关键逻辑或者随便改一个需求突然发现自己并不知道从哪里下手。这不是单纯的能力问题更像是一种“幻觉式掌握”——你拿到了“代码跑通”的结果却没有得到“掌握代码”的过程。今天想聊一个听起来有点反着来的思路build-to-learn用构建去学习。在 AI 生成代码越来越便宜的时代它的价值不是帮你写更多代码而是防止你变成只会按回车的人。vibe coding我理解的就是那种依赖 AI 进行开发的模式你描述需求AI 生成代码你负责运行、看结果、再提出修改。它让很多没系统学过前端、脚本、接口的人也能快速做出原型这是效率进步。但它也有一个默认代价代码的生成过程越顺畅你越容易跳过“从问题到方案”的那段推理。于是问题就来了——输出越稳理解越虚。1. 先承认vibe coding 本身不是病但“幻觉式掌握”是明显的副作用1.1 什么是“幻觉式掌握”“幻觉式掌握”不是一个正式术语但用它来形容一种状态很准确你看着 AI 生成的代码时觉得每一步都合理好像完全理解了可真要你去改、去扩展、去给同事讲清楚却发现自己脑子里只有一个大致的印象。就像看完了一本推理小说觉得剧情全懂朋友问你凶手为什么要这么做时你突然语塞。这种状态在 vibe coding 时代很容易出现因为 AI 给你的不只是答案而是一个看起来很完整的答案。一段完整的代码会触发你的“完成感”和“理解感”。可这种理解往往建立在对代码运行结果的信任上而不是对代码内部机制的掌握上。我见过最多的场景是这样的复制了一段示例代码运行成功就把文件收起来。过几天回来需求加了一个判断条件改完发现其他功能坏了。你可能会觉得是运气不好但其实是你第一次运行成功时没有留下任何可操作的心智模型。更典型的是网上那些“示例代码讲解”类项目。比如很多人会去找 Python 画爱心的代码、批量处理文件的脚本、网页小工具源码。复制过来跑通看到效果瞬间很有成就感。可你要是问他“如果想让爱心变大一点改哪个参数”“如果文件里有一行是空的程序会不会崩”他多半答不上来。这就是典型的幻觉式掌握。1.2 为什么“看得懂”不等于“会改”很多时候我们把“看得懂”和“会改”混为一谈。AI 生成的代码通常有清晰的结构、规范的命名所以阅读成本很低。但阅读是线性的你只需要跟随作者的思路修改是非线性的你需要知道哪一行依赖哪一行删掉一个变量会牵动多少地方。这里最关键的差异是“因果关系”。阅读时你看到的是一条已经铺好的路修改时你需要知道每条路为什么修在那里。AI 帮你把路修好了却没帮你修那个“为什么”。另外vibe coding 的交互方式也在加剧这个问题。传统开发里哪怕你复制别人的代码也得自己处理报错、依赖、环境这个过程中你会被迫理解一部分逻辑。而在 vibe coding 里AI 连报错都帮你处理了你只需要在对话框里说“怎么错了”。时间一长你越来越像一个验收员而不是一个能独立修路的人。但不该把锅全甩给 AI。vibe coding 只是一个工具和交互方式它本身没有“让你不学习”的强制作用。真正的问题在于我们把“运行通过”当成了学习目标。想要破解这个问题就得把学习目标重新改成“能解释、能修改、能重建”。2. build-to-learn 的核心从“消费代码”切换到“重建决策路径”2.1 读代码和建代码是两种认知活动如果只是阅读 AI 生成的代码你是在消费一个成品。消费的体验很流畅但不会逼你回答问题。而构建build的过程会强制你面对一堆“选择”和“约束”这个变量要不要存在这个函数拆到什么粒度输入非法时怎么办这些决策如果让 AI 来做你永远不会意识到它们存在。所以 build-to-learn 的核心不是“不让 AI 写代码”而是你要主动回到决策路径上。你不需要从零写所有代码但你至少要亲手重走 AI 走过的关键岔路口。尤其是那些看起来不起眼、实际决定成败的地方。比如说你让 AI 生成一个脚本用来读文件、清洗数据、输出结果。AI 可能一次性给出一段 50 行的代码。你逐行读看到strip()大概知道是去除空格但如果让你自己写你会不会想到要先检查文件编码会不会考虑某一行是空值时怎么处理这些细节阅读时很容易滑过去只有在构建时才会暴露出来。一行代码能运行不代表你理解它一个脚本能出结果不代表你能改它。这个观念一定要先立住后面的方法才有意义。2.2 构建为什么能治“幻觉”构建之所以能治“幻觉式掌握”是因为它强迫你交出一个可见的行为结果。你可以假装读懂了但你无法假装自己解决了报错。你写出来的代码一旦运行系统会立刻告诉你哪里不对。这种“可验证性”是阅读没有的。这也是为什么很多人的经验是“看十遍不如自己写一遍”。不是写一遍效率高而是写一遍的过程包含了一堆你原来没预料到的坑。AI 把坑填了也把学习机会填了。build-to-learn 则要求你主动把某个坑重新挖开看看下面是什么。从工作流来看build-to-learn 并不是让你回到石器时代。它更像是在 AI 生成的代码旁边设定一个“人类重建区”。在这个区域里你关掉自动补全和 AI 助手用编辑器、命令行、搜索引擎亲自把核心逻辑写出来。这个区域里的代码不追求生产级质量只追求一件事让你重新经历一次从问题到方案的推导过程。2.3 一个最小可行闭环拿到项目先重建不先扩展具体怎么做我建议从最小重建开始。你可以选一个已经在跑的小项目最好是 100 到 300 行之间的脚本或小服务。先让 AI 生成一个版本然后做一个动作关掉 AI自己重写这个项目。不是照着抄而是在不打开原文件的情况下根据需求说明重新实现一遍。这个过程可能会很难受因为你已经知道答案了却还要假装不知道。但正是这种“假装不知道”的过程才逼你调用自己的记忆和推理。如果你卡住了可以回去看 AI 代码的某个片段但看完之后要回到自己的文件里继续写。写完以后对比两个版本的差异问自己三个问题为什么 AI 那样写我这样写有什么问题这两个方案分别在什么条件下更好这个过程就是最基础的 build-to-learn 循环。它不需要额外找项目你手上任何一个 AI 帮过忙的小脚本都可以立刻拿来练。提示判断是否掌握的标准不是“运行成功”而是“能否回答为什么”。如果你能解释每个关键代码的存在理由才算开始掌握。3. 把 build-to-learn 变成日常方法的五步循环3.1 选一个“够小但真实”的构建目标第一步是选项目。目标太小比如打印乘法表你很快完成但没有增量目标太大比如重构老项目你会被复杂度淹没。比较理想的目标是你现在工作或学习中真的会用到的、代码量在 30 到 300 行之间、能在一两天内完成、并且有明确成功标准的小功能。比如“把某个目录下所有 Markdown 文件的标题提取出来生成目录”或者“写一个批量重命名文件的脚本”或者“做一个简单网页的登录状态判断”。关键是“真实”你自己会遇到这个需求而不是为了学而造一个假项目。真实需求会带来真实约束真实约束才会逼你思考。3.2 第一遍让 AI 生成但你真的读进去第一遍不是纯 vibe coding。你可以把需求描述给 AI让它生成一个初版。但在验收之前要给自己留出一段时间逐行阅读代码。不是大略扫一眼而是对每一行都能回答“这一行解决什么需求”如果某一行看不懂不要急着让 AI 解释先自己查一查。AI 的解释通常会让你产生“懂了”的错觉但这不是你的能力。你可以用 AI 拿线索但要回到代码里验证线索。一个常用做法是在不理解的地方加一行print或日志观察运行时它到底做了什么。运行结果才是靠谱的证据。很多人在这一步会犯一个错让 AI 一次性给出完整代码而自己只看一个总结。然后跑通以后觉得“已经是我的项目了”。不是的那只是 AI 的项目你只是按了运行键。3.3 第二遍关掉自动补全自己重写核心逻辑读完以后把整个代码文件关掉。新建一个文件凭记忆和理解重写。你可以保留需求说明但不能打开 AI 版本。这一遍的关键不是和 AI 代码一模一样而是达到相同的功能。你会发现很多地方记不住、想不通这很正常。卡住的时候可以打开 AI 代码看 30 秒然后关掉继续写。这样做几次之后你会慢慢把“它为什么会这样写”的因果链建立起来。如果你发现自己完全写不出来那就说明当前代码已经超出你的理解范围了。这时候不要硬写先把代码拆小只看其中一个函数或模块从更小的粒度重新来过。否则你只是在对着一份自己看不懂的答案抄写抄完还是不会。3.4 第三遍故意改坏再修回来这一步很多人会忽略但对消除“幻觉”非常有效。改坏的目的是触发错误然后通过调试把系统重新带回正确状态。你可以试着这样操作把一个变量的初始值改成错误的。把某个函数改成每次都返回空值。删掉异常处理看程序在非法输入下会怎样。加一个新的参数并让它在某个分支生效。每改一次运行一次观察输出和报错。然后追问自己这是哪一个环节导致的如果我想恢复需要改哪里这个练习能快速暴露你对代码的无知因为你预测不到它会出现什么错误。注意不要一次把所有代码都改坏一次只改一个点否则你根本不知道错从何来。3.5 第四遍加一个“教程里没有”的功能最后给项目加一个 AI 原方案里没有的功能。这个功能要小但要涉及输入、输出、状态或界面中的一个环节。加功能比重写更能检验掌握程度因为你必须在已有结构上做出设计决策。比如原来的脚本只处理一个文件你可以改成批量处理整个目录原来统计一个指标你可以增加一个统计维度原来只是展示文本你可以增加一个条件筛选。加功能的过程中你会被迫理解原代码的可扩展点而这恰好是 AI 帮你写代码时不会教你的东西。完成后把整个过程写成一篇笔记用你自己的话解释项目解决什么问题核心数据流是什么哪些地方容易出错为什么这样设计这一步算“教别人”的简化版。写不出来或不顺畅的地方就是你下一次 build-to-learn 的起点。4. 在 AI 工作流里保留“人类控制点”4.1 把 AI 当结对程序员而不是外包build-to-learn 不等于不用 AI。我更建议把它当成一个分工策略AI 负责快速生成实现、补模板代码、做草稿你负责定义问题、审查设计、决定边界。换句话说你应该做那个“提出问题、验收结果、掌握全局”的人。每次和 AI 协作时先在心里画一个控制点清单这个功能的输入从哪里来输出格式要达到什么标准哪些错误必须被拦截哪些行为以后可能会变这些问题不应该由 AI 决定。AI 可以帮你写代码但它不知道你的业务背景、你的用户习惯、你未来三个月的规划。如果这些问题都交给 AI你只是在追逐一个黑盒的结果。4.2 必须自己做决定的三个位置接口、状态、边界在实践里有三个地方特别值得你把控制权拿回来。第一个是接口设计。你的函数接受什么参数、返回什么、用什么数据结构。这决定了别人怎么调用你的代码也决定了后面改动的成本。AI 生成的接口通常能跑但不一定适合你的使用场景。你要检查参数命名、默认值、返回值是否合理。第二个是状态管理。程序里有哪些全局变量哪些状态会跨函数传递有没有可能出现状态不一致AI 生成的代码在小例子里往往没问题但状态一多混乱就会冒出来。你需要亲手理清一遍状态流转。第三个是边界条件。空数组、空文件、null、超时、重复调用、超大输入这些情况 AI 可能会忽略。你要主动为边界写测试或分支。一个程序员是否掌握代码经常就看他能不能把这些“平时不会出现但一旦出现就炸”的地方处理干净。4.3 给自己设置“认知检查点”除了控制点还可以在时间上设置认知检查点。不要连续几小时让 AI 生成代码自己在旁边只按运行。每过一段时间停下来做一次小测试不看代码画出当前系统的流程图给接口写测试用例描述一段数据的完整生命周期。这些检查点不需要很长十分钟就够。但它们的价值在于强制你把“刚才发生了什么”转成“我如何理解它”。如果你发现自己画不出来说明当前代码已经在你的理解之外了。这时候最该做的事不是继续加功能而是回去补基础。有些朋友可能会觉得这样很慢但实际是慢在检查快在返工。你今天省下的是十分钟检查明天赔上的可能是两小时排查。5. 如何判断自己是不是正在“幻觉式掌握”5.1 先做一份自我测试清单很多人不知道自己有没有掉进“幻觉式掌握”因为它在日常操作里并不明显。你可以用一组问题测试自己。如果大部分问题答不上来就要警惕了。如果不打开编辑器你能画清楚这个项目的数据流吗你能指出 AI 生成代码中最可能出 Bug 的一处吗你能解释每个关键函数为什么存在而不是“因为 AI 写了”吗如果需求变成把输入从 JSON 改成 CSV你知道要改动哪几行吗你能在 10 分钟内完成一个小的分支修改并跑通测试吗你能给完全不了解项目的人讲清楚它的架构吗这些问题不是考试而是一种体检。它们判断的不是“你记住没有”而是“你是否拥有一个可以操作的心智模型”。有模型的人遇到新需求会知道影响范围没有模型的人只能东试一下西试一下。5.2 常见异常表现和排查顺序如果你发现自己有“幻觉式掌握”的倾向可以按下面的顺序排查而不是直接否定 AI。先看现象你是不是只会跑通初始用例是不是一改就坏是不是无法解释变量之间的关系再看输入你是否理解当前代码处理的数据结构有没有自己写过样例输入再看环境你清楚依赖、版本、配置项的作用吗如果换个目录或换台机器你能让它跑起来吗再看参数那些看起来无关紧要的默认参数、超时时间、并发数你知道它们为什么存在吗最后看工具边界你选的 AI 工具或模型有没有隐藏限制它生成的代码是不是超出你当前能理解的范围这个顺序的核心是不要一上来就归因于“我太笨”或“AI 太差”。绝大多数问题出在输入理解、环境保障和参数掌控上。先补这些再谈更高层的设计。5.3 从“运行成功”到“真正掌握”的证据判断是否掌握不能只看功能跑没跑通。更可靠的证据是你能成功预判错误。比如你知道如果用户传了一个空列表程序会在哪个函数抛出异常你知道如果网络超时哪个变量会变成空值你知道如果要加一个新功能需要改哪几个文件。另外一个证据是你能在 AI 代码里发现不合理的地方并且说出理由。比如某个函数重复计算、某个错误处理位置不对、某个接口设计对扩展不友好。当你开始对 AI 代码做 code review而不是全盘接受时你就不再是幻觉式掌握了。6. 回到效率与学习的平衡build-to-learn 不是慢而是快在正确的地方6.1 什么时候可以放心 vibe coding我并不是主张所有场景都必须 build-to-learn。有些场景效率优先是完全合理的。比如你只是想快速验证一个想法看看某个流程是否可行你要写一次性脚本用完就扔你只需要临时处理一批数据未来三个月都不会碰或者你在做纯探索性的原型目标是获取反馈而不是产出可维护代码。在这些情况下让 AI 接管大部分编码工作没有任何问题。你的目标本来就是低成本试错不是学习。这时候还逼自己重建反而是浪费。场景建议模式理由一次性验证脚本vibe coding成本最低用完就扔快速原型vibe coding需要尽快拿到反馈学习新框架build-to-learn需要建立心智模型核心业务代码build-to-learn错误代价高必须可控长期维护模块build-to-learn未来要持续修改和扩展6.2 什么时候必须切回 build-to-learn反过来当下面几种场景出现时我建议你主动切回 build-to-learn。代码要放进长期项目里未来会有人维护。这段代码涉及核心业务逻辑错误代价高。你需要向别人解释这段代码的工作方式。你打算在这个领域积累能力而不是只做一次任务。这段代码可能被复用、扩展、调整接口。在这些场景里你最大的成本不是编码时间而是未来的返工和事故成本。用 build-to-learn 多花的一两个小时换来的是对代码的掌控力。这笔账怎么算都很划算。6.3 一个可复用的判断框架最后我把前面的内容收束成一个简单判断框架适合每次让 AI 写代码前问一遍这段代码将来会不会被改要不要给别人讲我是否需要在这个领域变强如果三个问题里有两个“是”就切到 build-to-learn 模式。如果都是“否”大胆用 AI 生成但至少跑一遍测试确认输入输出符合预期。无论哪种模式我都建议你每天留出 15 分钟做“重建练习”把今天 AI 生成的代码段关掉 AI 重写一遍。不需要全部重写一行核心逻辑也可以。这个框架的核心很简单让 AI 做实现但不要让它替代你的判断。build-to-learn 的本质也不是让你回到手工编码时代而是让你在 AI 生成代码的世界里保留一条随时可以独立走通的路。将来 AI 生成的代码肯定会越来越多但真正决定你职业价值的仍然是你脑子里那套可以解释、可以修改、可以重建的理解。如果你最近也发现自己“用 AI 写了很多代码却说不出所以然”不妨就从一个小脚本开始关掉对话窗口重新写一遍。跑通不是终点理解才是。