费曼学习法×编程：五步吃透代码，AI时代更值钱

费曼学习法在写代码这件事上效果比大多数人想得要好。我见过太多工程师专栏刷了几百篇GitHub上项目 star 了一堆可真坐到屏幕前面对一个空白文件连一个像样的函数都要憋半天。原因很简单看懂了不等于会了。费曼学习法说如果你不能用最简单的话把事情讲清楚说明你还没真正理解它。这句话放到编程这个行当里能救你无数次。今天这篇是“费曼学习法与写代码”系列的第 5 篇我会把前几篇讲过的理念收敛成五个可以立刻上手的动作然后结合目前最热门的 AI 写代码工具、嵌入式开发、云开发这些场景聊一聊在工具越来越强的时代为什么费曼这一套东西反而更值钱。适合谁给自己安排学习路线的初级工程师写了两三年代码但总觉得没长进的中间层以及天天带新人的技术 leader都能从中拿到一些能落地的东西。1. 费曼学习法用在写代码上为什么效率出奇地高1.1 代码是天然的费曼训练场费曼学习法听上去很玄其实拆开就四步选一个概念、把它讲给一个完全不懂的人听、发现自己讲不清楚的地方、回去重新学。这个循环本来是用来学物理、学数学的但代码比物理和数学更适合这套方法原因是代码有个极其苛刻的裁判编译器。你说你理解了物理里的“力”那可以聊上三天三夜谁也没法立刻证明你哪里错了。但你说你理解了一段代码那好把逻辑讲给我听然后跑一遍。只要有一个边界条件没想到、一个指针指错了地方、一个状态机漏了分支程序立刻用崩溃或者错误结果给你颜色看。这种即时反馈是费曼学习法最需要的每一步“以为懂了”都会被事实无情拆穿。我用这个思路复盘过自己写过的所有小项目最深的感受是代码是极少数的“你骗不了它”的领域。你学历史可以背个大概学数学可以记个思路但写代码讲不出来就是写不出来编译不过就是编译不过。所以如果你真想练自己的理解能力写代码是最好的训练场没有之一。1.2 看懂与讲懂之间隔着一整个知识盲区很多人有这种体验看一份开源代码注释都看明白了每行什么意思也能说个七八分但你把窗口关掉让他自己实现同样的功能他憋半天写不出来。这种“看懂假象”在职场上太常见了。我以前带过一个新人让他看一下我们项目里的消息队列模块第二天问看得怎么样他说“看懂了没什么问题”。我说行那你把这段代码的设计思路讲给我听听不用讲很细就把消息是怎么从生产者到消费者的流程讲清楚。结果他开始讲不到三分钟就卡住了磕磕绊绊地说“这里有块逻辑我当时没细看”。这就是典型的看懂不等于讲懂。讲懂比看懂高一个层级。你要讲清楚一段代码至少得知道它解决什么问题、为什么选这种数据结构、异常情况下怎么处理、为什么这里锁粒度这么设计。每一层都是知识盲区的探测器。我写这个系列最核心的观点就一句话不要问自己“这段代码看懂了吗”而要问自己“这段代码我能给别人讲明白吗”。能讲明白才算真正吸收。2. “写代码5”的五步法把知识焊死在脑子里“写代码5”这个系列写到第 5 篇我干脆把费曼学习法落地成五个写代码的动作。这五个动作不是理论是我自己实际在项目里反复用、反复验证过的。每一步都有明确产出做完之后你对一段代码的理解深度会明显不一样。2.1 第一步先复述需求而不是抢着写大多数工程师接到需求的第一反应是打开编辑器开始写代码这其实是误区。费曼学习法要求先用自己的话把需求复述一遍确认你理解了问题本身。复述不是对着产品文档念一遍而是把“输入、输出、边界条件、异常情况”用一句话概括出来。举个例子产品说“给用户加一个积分过期提醒”你如果直接做大概率会漏掉很多细节。但如果你复述成“每天扫描一次所有用户积分找出三天内要过期的积分给用户发一条站内信同一用户同一批次只发一次”你会发现边界条件自动浮出水面什么叫“同一批次”要不要考虑用户已读站内信发送失败要不要重试这一步的作用是把“模糊的需求”变成“可验证的命题”。我自己每次在写代码之前都会先在文档或者聊天框里写一段“我的理解”写完之后再动手。这个习惯帮我挡掉了至少一半因为需求理解偏差产生的返工。2.2 第二步拆到每个函数、每行都能讲明白拿到一段代码不管是自己写的还是别人写的不要停留在“整体上它做了一件什么事”要一层层拆下去。我的做法是按函数拆先讲清楚每个函数的职责再按语句拆每一行都要能回答“为什么这里要这样写”。这一步听起来繁重但实际操作的时候可以用一个很直接的方法给代码加中文注释。注意不是翻译代码而是写“意图注释”。比如看到if (retryCount MAX_RETRY)不要注释“如果重试次数小于最大值”而要写“这里限制最多重试 5 次防止雪崩”。这两种注释的信息量完全不一样后者要求你真的理解这行代码在全局设计里扮演的角色。我在做代码评审的时候经常用这招。如果我发现一个工程师的 PR 里全是“翻译型注释”基本可以判断他对这段代码的理解还停留在表面。真正理解代码的人写出来的注释会告诉你“为什么”而不是“是什么”。2.3 第三步用最朴素的方式简化重写费曼学习法里有一句名言如果你不能把它讲简单说明你还没理解它。对应到代码上就是“如果你不能把它写简单说明你还没理解它”。很多初学者看到别人用了设计模式、用了高阶函数、用了复杂的泛型就觉得高大上恨不得全抄过来。但费曼这一步要求你做相反的事丢掉所有花哨的技巧用最基础、最朴素的语法重新实现一遍同样的功能。能用 for 循环就不用迭代器能用普通函数就不用类能不引入第三方库就不引入。比如你学了一个用 Redis 做分布式锁的代码里面涉及 Lua 脚本、连接池、过期时间续期很复杂。你用费曼三步走一遍之后应该能写一个“只有锁和释放锁”的极简版本。虽然生产环境不能这么写但你写完这个极简版本你才真正明白分布式锁的本质是什么后面再去理解 Lua 脚本、续期机制就顺理成章了。朴素的版本就像是你用自己的话复述了一遍知识。它的价值不在于能上线而在于帮你确认你已经把核心逻辑内化了。2.4 第四步关掉参考默写还原这一步最痛苦但效果也最猛。方法是把原始代码盖住打开一个空编辑器凭记忆从头实现一遍。不要小看这个动作它和你“照着抄一遍”有本质区别。照着抄的时候手在动脑子可以完全休眠。但默写的时候你的大脑被迫启动“检索模式”每一步都要回忆“这个函数叫什么来着”“这里为什么要有这个参数”“异常处理放在哪个位置”。每一次卡住都是你知识地图上一个真实的缺口。默写的时候卡住的地方就是你真正需要重新看一遍的地方。我自己学一个新框架的时候会故意“虐”自己看完官方文档和第 1 个 demo 后不写笔记、不保存代码过两个小时直接默写。第一次默写 C 语言里的链表操作我卡在“头节点要怎么处理”上那一刻我才意识到之前我根本没理解链表哨兵节点的意义。后来我把那个地方反复看了三遍才彻底过关。2.5 第五步复盘差异找出真正的盲点默写完之后把你写的代码和原始代码放到一起对比。这一步别只比功能比格式要重点问自己三个问题第一我写的功能是不是和原来等价第二如果不等价差异是因为我记错了还是因为我对需求理解偏了第三哪些地方我用了和原作者完全不同的写法谁的更好为什么很多人做到第四步就停了觉得能默写出来就是会了。其实不然。默写出来可能只是短期记忆而复盘差异才是把短期记忆转化成长期理解的必经之路。举个例子我默写一个排序算法虽然功能对了但写成了冒泡排序而原代码是快速排序。这时候如果只是“功能等价”就放过自己那你就错过了学习快排思想的绝佳机会。复盘的意义就是把你的方案和更优的方案放在一起盯着差异看十秒钟那种“原来还能这样”的感觉比你看十遍教程都管用。3. AI协助写代码的时代费曼学习法反而更值钱现在写代码的环境已经和五年前完全不同。Qwen Code、Codex、DeepSeek、Kimi 这些工具都能在几秒钟内生成一大段像模像样的代码。于是很多人开始问既然 AI 都能写了我还有必要费劲去学吗我的回答是更要学而且要更扎实地学。AI 时代最危险的一批人不是不会写代码的人而是只会复制粘贴代码却看不懂代码的人。他们没有成长的根基只会在工具迭代中被反复重置。3.1 AI只给你结果不给你理解AI 生成的代码相当于一个经验丰富的同事把代码写好递给你但它不会告诉你“为什么这么写”。你拿到手能跑、能出结果表面看任务完成了但你的能力其实没有变化。下一回换个场景你依然写不出来依然要去求 AI。我用一个类比解释这件事AI 写代码就像别人把菜做好端到你面前你确实吃饱了但你要想自己会做这道菜总得知道里面放了什么调料、火候怎么控制、为什么先炒蒜再放菜。费曼学习法的核心作用就是逼着你把 AI 给的“菜”拆解清楚尝出每一味调料最终自己也能做出一盘来。所以我的建议从来不是“抵制 AI”而是“用 AI 辅助学习”。让 AI 给你一个初版然后你按照费曼五步法走一遍复述需求、拆解代码、简化重写、默写还原、复盘差异。等你能把 AI 写的代码讲得明明白白了这段代码才真正对你产生了价值。3.2 用费曼四步质检AI代码别当复制粘贴工AI 生成的代码并不是天然正确的它经常会一本正经地胡说八道。我自己的经验是用费曼学习法的思路去给 AI 代码做质检比直接信任结果可靠得多。具体怎么做拿到 AI 生成的代码之后先别急着运行试着给自己讲一遍“这段代码每一步在干什么”。讲的过程中你大概率会发现几个可疑点这里用的库到底存不存在这个函数签名和文档里写的一样吗这个超时时间设置得合理吗一旦发现讲不通的地方那就是你应该去查证的地方。我遇到过最典型的例子是让 AI 生成一段定时任务代码它给了一个网上很少见的三方库还说“这是一个常用的定时任务库”。我按照费曼步骤一想完全讲不出这个库的底层机制于是去查了一下发现这个库三年前就停止维护了而且有已知 bug。如果我当时直接复制粘贴后果不堪设想。AI 的价值在于提供候选方案而你的理解力才是最终质检员。3.3 当AI代码遇到具体工具问题时怎么用费曼自救现在网上搜“写代码”相关的问题有一半都是工具问题比如“VSCode 写 C 没有代码提示”“Eclipse 写代码的时候文本模糊匹配”“VS ESP-IDF 怎么搭建 ESP32 代码环境”。这些问题的共同点是工具本身的坑遮住了代码逻辑的视线让新手卡在一个非常低级的位置。遇到这种问题费曼学习法同样能帮上忙。核心思路是先把问题讲清楚再动手解决。很多人一看到没有代码提示第一反应是“换个 IDE”换了之后还是一堆问题。这时候应该做的是把“为什么没有提示”这件事讲给自己听是没有安装 C/C 扩展是 workspace 没打开正确的文件夹还是 compile_commands.json 没生成把问题拆解开每一步都问一个“为什么”通常答案自己就浮出来了。比如 VSCode 写 C 没有代码提示大多数情况是 IntelliSense 引擎不知道你的头文件在哪里。你光看解决方案“配置 includePath”是记不住的但如果你理解了“代码提示需要一个头文件索引而索引路径需要人工告诉它”下次就永远不会被这个问题卡住。这就是费曼学习法在工具问题上的应用不要背解决方案要理解问题背后的机制。4. 实战拆解我用费曼学习法“吃掉”了一个ESP32模块讲完理论我拿一个真实的硬件开发场景走一遍费曼五步法。这个案例是我自己调试过的用 VS Code ESP-IDF 搭建 ESP32-WROVER Module 的开发环境实现 DHT11 温湿度传感器数据读取。希望能给做嵌入式的朋友一些参考。4.1 从AI生成到真正掌握中间只隔了一层讲解一开始我图省事直接让 AI 生成了一段读取 DHT11 的代码。它给得很完整头文件、GPIO 配置、时序函数全都有。我在 ESP32-WROVER 开发板上烧录之后串口确实打印出了温湿度数据。这一刻如果我只是想“完成任务”这个模块就算写完了。但我知道如果我关上这个工程下一回让我写一个读取其他传感器比如 DS18B20的代码我一定还是两眼一抹黑。于是我开始用费曼法走进这段代码第一步复述需求——DHT11 是单总线协议一根数据线既要发送命令又要读数据必须严格按时序操作。第二步拆解——发现函数里最核心的两个函数一个是拉低总线发起始信号一个是读取 40 bit 数据。当我尝试解释“为什么读数据时要先拉高再延时 20 微秒”时我卡住了。卡住的那一刻我很高兴因为我知道盲区在哪。于是我翻出 DHT11 的数据手册把时序图逐像素看了一遍终于理解了那位“AI 同事”写的每一行延时背后的硬件逻辑。4.2 现场实操DHT11温湿度读取的费曼五步走我把这次实操的五个步骤贴出来给大家做个模板。第一步复述需求。我的复述是DHT11 通过一根 GPIO 线通信主机先拉低总线至少 18ms 发送起始信号然后释放总线DHT11 会回一个低电平响应接着输出 40 bit 数据湿度整数、湿度小数、温度整数、温度小数、校验和。这个复述完成了我知道代码要解决的核心问题是“时序”。第二步拆解讲解。我把 AI 生成的代码拆成三段起始信号段、读取响应段、数据接收段。每一段都用中文注释写清楚“这段在等什么、为什么要等这么久”。这一步我发现了问题数据接收段的位读取函数里有一个非常短的延时注释写的是“调整时序”我当时根本讲不清楚这个延时的作用。第三步简化重写。我删掉所有调试打印甚至删掉错误处理只保留了最核心的“发起始信号 读 40 bit”的骨架用最朴素的gpio_set_level和gpio_get_level写了一遍。简化之后我反而看懂了整条数据链路的走向。第四步默写还原。我把 AI 的代码和简化版本全部关掉重新写了一遍 DHT11 的读取流程。这一步我卡在了校验和的计算上说明我之前对“校验和等于前四个字节累加的低 8 位”这句话并没有真正吸收。第五步复盘差异。对比之后我发现AI 生成的代码里有一个delayMicroseconds(40)的时序参数而数据手册上推荐的是 20 微秒左右我的简化版用了手册值实际运行也正常。这让我意识到 AI 给的参数未必是最优的最终决定权还是在你对数据手册的理解上。4.3 实战中踩过的坑引脚、时序和版本依赖这次实战还踩了不少坑值得单独拎出来说。第一个坑是引脚映射。AI 代码默认用的是 GPIO4但我手上的 ESP32-WROVER Module 板子DHT11 实际接在 GPIO18。代码烧进去没反应我用费曼的思路问自己“为什么没反应”排查了半天才定位到电路连接上。这个教训是AI 只会按照提示词写逻辑它不知道你的硬件长什么样动手之前先对照原理图把引脚映射核对一遍。第二个坑是 ESP-IDF 的版本依赖。AI 生成的代码用的是旧版的esp_timer接口而我的 ESP-IDF 是 v5.x不少 API 已经废弃了编译直接报错。这种问题光靠 AI 根本解决不了你必须理解“定时器接口在新版本里换成了什么、为什么要换”。我把官方 migration guide 翻出来看了一遍才算把这个问题彻底解决。第三个坑是时序精度。DHT11 对时序要求不算变态但如果你用vTaskDelay来做微秒级延时任务是可能被调度器打断的导致时序错乱。费曼法帮我想清楚了一个问题为什么这里用忙等待而不是让出 CPU。因为微秒级的时序精度不能依赖任务调度必须用 CPU 空转。这种理解AI 不会主动告诉你但你自己弄明白之后比记 100 个 API 都管用。5. 不同场景下的费曼适配并非所有人都在写CRUD费曼学习法不是一套死板的流程到了不同领域重点会不一样。我结合目前网上搜得比较热的几个写代码场景聊聊怎么把“讲清楚”这个核心动作适配进去。5.1 嵌入式开发的费曼重点讲清楚时序和寄存器很多做嵌入式的朋友说现在嵌入式开发全靠 AI 写代码。我觉得 AI 能帮的只是“把寄存器配置写成代码”这个动作真正决定代码能不能跑通的是你对硬件机制的理解。所以在嵌入式领域费曼学习法的重点不是“讲清楚这个函数调用了什么”而是“讲清楚这个信号在硬件层面是怎么走的、这个寄存器为什么是这个值”。比如你要驱动一个 I2C 设备与其背代码不如试着把一个完整的数据传输过程讲给别人听主机怎么发起开始信号、设备地址怎么匹配、ACK 信号从哪来、寄存器地址怎么指定。如果你能对着时序图把这些讲明白I2C 的代码怎么都能写出来。如果你讲不明白今天靠 AI 生成了 I2C明天遇到 SPI、UART、PWM你还是得继续求 AI。寄存器也一样。我看到很多初学者的代码里某个外设功能就是“抄了一堆寄存器值”问他为什么是0x3F他答不上来。用费曼法解决这个问题的动作是打开数据手册找到寄存器描述把每一位的含义讲给自己听。这个过程很枯燥但每讲明白一位你就多掌握了一份真正的底层能力。5.2 小程序云开发不写后端也要讲清数据流现在小程序云开发很流行很多人觉得“云开发是不是就不用写后端代码了”。从操作上看确实省了很多后端事项你不用自己部署服务器了但这不意味着你可以不理解数据流向。你至少要把这些问题讲清楚数据存到哪个集合、权限怎么控制、云函数什么时候触发、前端如何订阅数据更新。我用费曼法指导过一个小白朋友他要做一个小程序用云开发存用户头像和昵称。他自己照着文档稀里糊涂写好了但当我问他“你的数据读写权限是怎么设置的为什么别的小程序也能读到你的数据”时他完全懵了。这就是云开发隐藏的深坑不用写后端所以你容易忽略“数据安全的职责依然在你身上”。处理方式很简单让他把“用户打开小程序 → 微信登录 → 调用云函数 → 把用户信息写入数据库”这条链路从头到尾跟一个完全不懂小程序的人讲一遍。讲到权限那一步他自己发现了问题数据的权限配置过于开放。不写后端代码不等于不用理解后端逻辑这句话在云开发场景下尤其重要。5.3 设计图转前端、产品经理指导开发本质都是讲清楚现在网上还有一个高频需求Figma 设计图转成 AI 前端代码。很多产品经理也想学这个技能。我的看法是AI 可以把设计图变成 HTML/CSS 代码但你真要让页面符合产品逻辑至少要能讲清楚“这个按钮点了之后会发生什么”和“这个状态在什么时候展示”。产品经理用费曼思维指导程序员写代码其实也是同一个道理。不是让产品经理去学 Java 或者 C而是要求程序员能把实现逻辑讲清楚同时产品经理也能把自己的需求逻辑讲清楚。我听一个团队分享过他们的经验每周五下午让程序员不写代码只做一件事把本周写的功能讲给产品经理和另外一个程序员听讲不清楚就是没写完。这个流程本质上就是费曼学习法在团队协作中的落地。前端领域也一样。AI 能生成一个看起来很精致的按钮但按钮按下之后的 loading 状态、请求失败提示、数据为空占位这些逻辑 AI 不一定能替你考虑周全。你需要站在产品的角度把整个交互流程讲清楚。能讲清楚的人AI 是你的效率放大器讲不清楚的人AI 只会帮你把错误快速放大。