第一次听说费曼学习法的时候我正在为一件事头疼项目里新引入了一个模块文档看了三天视频刷了两天代码还是写不出来。后来有人跟我说别光看讲给别人听。就这么一句话我整个人通透了不少。费曼学习法和写代码放在一起是我最近几年摸索下来最实用的组合拳。它不是什么玄学核心就是四步选定概念、尝试讲解、发现卡壳、回头补漏再简化。这些年我在实际项目中用这套方法啃过新语言、拆过老代码、应付过各种层出不穷的新框架也帮不少新人从“看得懂”跨到“写得动”。这篇文章就从实际操作角度把这套方法的落地步骤、环境配置、AI时代下的取舍还有我踩过的坑掰开揉碎说一说。这篇东西适合谁刚入门不知道怎么上手的新手、写了一阵子总感觉没长进的初中级开发者以及想在AI时代守住基本功的工程师都可以参考。接下来我不讲空理论全部按实操走。1. 费曼学习法的底层逻辑为什么放到编程里格外好使1.1 费曼四步翻译成程序员听得懂的话费曼学习法常被概括成四步很多人把它当鸡汤听其实它就是一个符合认知规律的学习闭环。我用写代码的场景重新翻译了一遍大家感受一下。选定概念挑一个具体的知识点别贪多。比如“C语言里怎么给字符串补零”这算一个点。别一上来就定“C语言标准库全攻略”那不是一个点是一整片森林学不完也讲不清。讲给别人听写代码最好的“讲”的方式有两种一种是真正讲给同事听另一种是写注释、写博客、录个小视频讲给自己。很多人忽略后一种其实后一种试错成本更低也更适合社恐。你不必真的找一个听众打开编辑器写一段带着详细注释的代码就是一次完整的讲解。发现卡壳讲到一半突然讲不下去了恭喜这才是最值钱的时刻。那个卡住的地方就是你的知识盲区。比如你讲字符串格式化讲到sprintf的格式化占位符和参数类型怎么匹配突然说不清楚“长度匹配”到底是怎么发生的这就是盲区。回头补漏再简化拿着盲区回去查文档、看源码、做实验弄明白之后再用你自己的话重新讲一遍这次要求讲得更简单。如果能用一句话让一个外行听懂你是真的学会了而不是以为自己学会了。这个四步在任何学习场景都适用但放到写代码里格外好使因为编程本身就是一个“边学边输出”的过程和费曼法的核心精神天然契合。1.2 写代码是天然的输出式学习为什么编程和费曼学习法特别搭因为编程本身就是输出。你读再多的技术文章不如亲手跑通一个小程序来得实在。大脑的记忆机制决定了只有经过主动回忆和重构的信息才更容易变成长期记忆。写代码就是这个“主动回忆”的过程。我第一次明显感觉到这种威力是学Python的时候。当时看了很多教程list、dict、tuple这些概念都懂但真要写个脚本处理数据还是卡住。后来换了个方法不看了直接给自己定了一个费曼式任务把这三种常用容器的区别用一段代码演示出来再配上文字解释讲给一个完全不懂编程的朋友听。结果为了把dict的哈希特性讲明白我硬是去翻了底层实现回来又反复改代码那一次学到的深度比我之前闷头看一星期教程都深。这个例子说明一个道理输出的过程会逼着你把模糊的地方变清楚。你没法向别人讲清楚一个你自己都不理解的概念所以一旦开始输出你的理解程度就藏不住了。1.3 输出倒逼输入形成一个正反馈很多人的学习状态是“假性学习”视频看了、文章收藏了、代码复制跑了感觉学到了其实知识还是作者的不是你的。费曼学习法把逻辑倒过来了先不追求输入先尝试输出。你一旦开始输出马上就会发现哪个地方没搞懂然后带着明确的问题去补输入效率完全不一样。这就好比考试前先把卷子发了你自然知道该复习哪一章而不是翻开课本从头看到尾看了50页还没看到重点。在写代码里这个逻辑具体可以变成这样先给自己一个明确的小目标比如“用C写一段代码把0:41:0.0这个字符串转成0000:41:0.0”然后试着动手写。写的时候会暴露很多问题怎么找到第一个冒号的位置补零补几位分隔符怎么处理输入不合法怎么办这些问题就是你补课的方向。解决一个你就前进一点而且每解决一个你都会特别有成就感。这种正反馈一旦建立起来你就不需要靠意志力逼自己学习了因为学到东西本身就会让你舒服。2. 实操方法论怎么把费曼法落到每天的代码里2.1 从模仿到重构费曼式拆解一段示例代码很多人写代码是照着网上现成的代码抄抄完自己也讲不清每一行是干嘛的。这种状态很危险因为换个需求稍微变一变你就不会了。费曼式的做法是找一段代码先运行看效果然后把代码遮住用自己的话把它重写一遍最后和你原来看的版本对比看看差在哪。用一个真实的小例子。假设需求是“写一段C代码将字符串0:41:0.0转换为0000:41:0.0”简单的实现思路是先找到第一个冒号的位置把前面的部分补零到4位然后拼接后面的部分。很多新手的第一反应是去网上搜“C语言补零”的代码复制过来跑通了就觉得会了。但用费曼法你要做的是第一不急着复制先口头描述你要做什么。描述的过程就是“讲给别人听”。如果你发现自己说不清楚“不足4位怎么补”说明这个点没掌握回去查函数库或者C标准手册把strchr、memcpy、sprintf这些函数用明白。第二自己写一版。写完拿边界条件测一下比如输入是“1:00:00.0”时输出应该是“0001:00:00.0”如果输入是“00:00:00.0”输出应该不变。如果输出不对说明边界没处理好这里就是一个学习的契机。第三把你的代码和参考版本放在一起逐行解释每一行的作用。解释不清楚的地方就是下次要补课的地方。这个流程看着简单但它会逼你理解每一行代码背后的“为什么”而不是停留在“能跑就行”。2.2 用费曼法啃一个新框架以搭建个人RAG为例热搜词里有一条“写代码搭建个人rag更新博客”这个场景特别适合做费曼学习法的练习对象。RAG检索增强生成现在很火很多朋友一看到这个缩写就头皮发麻觉得是很高级的东西。其实别被名字吓住它无非就是给模型配了一个外挂的资料库回答问题时先检索资料库里的相关内容再基于这些内容生成答案。假设你想用RAG来更新和管理自己的博客第一步先别急着看框架文档先问自己一个问题如果用一句话向别人解释清楚我要搭的东西是什么我当时是这么说的让博客的每篇文章变成可搜索的片段用户提问时系统先找到这些片段里最相关的内容再让大模型据此写答案。这句话讲清楚了后面的技术路线就清晰了。然后你选一个工具链比如LangChain或LlamaIndex配合向量数据库。这时候就可以用费曼法了每学一个概念比如embedding、向量检索、chunking都用自己的话讲一遍并且用一个最小实验去验证它。有些概念你以为懂了一试就露馅。比如chunking如果你只是听说了要把长文本切成小块但切多大、块与块之间要不要重叠、中文和英文的切法有什么不同这些光靠看是看不出门道的。必须亲自动手跑一遍再试着给别人讲。讲着讲着细节就出来了哪些参数影响检索质量哪些策略适合中文博客都会变得清楚。2.3 学会“讲给昨天的自己听”写博客和录讲解视频的技巧费曼学习法里最经典的动作是“讲解”放在写代码的场景里我觉得最有效的两个实践是写博客和录讲解视频哪怕只录给自己看都算数。写博客的一个实用技巧是不要搞宏大叙事就写一个很小的点。比如“如何在VSCode里让C语言代码提示生效”或者“WSL Ubuntu下让代码字体更接近macOS体验”。别小看这些看似很细的问题能把它讲清楚本身就意味着你踩过坑、研究过、验证过。这比写一篇泛泛的“XX语言入门”有价值得多也更符合费曼学习法“一次讲透一个概念”的原则。录讲解视频也很有用。我发现一个规律很多bug在你边写代码边说话的时候自己就暴露了。原因是说话的过程强迫你一行一行地审视自己的逻辑那些靠着肌肉记忆敲出来的代码在你的嘴跟不上手的时候问题就出现了。这就是程序员版的“橡皮鸭调试法”但费曼学习法把它提炼成了一种主动的输出训练。录的时候不一定要多长的时长每次三十分钟到一个小时就够了关键是把一个点讲透。我自己的习惯是录完之后回头看一遍重点看自己在哪里卡壳了那个卡壳点就是下次要深入学习的方向。2.4 边界情况处理费曼法在调试中的“盲区排查”调试的时候费曼法也有一个很好用的变形把代码的执行过程从头到尾“讲”一遍。比如你写了一个函数处理文本首尾相连、转小写、过滤空字符串。可能跑通了一个正常输入但没考虑到空字符串的情况。用费曼法的思路你可以模拟一个“面试官”角色不断问自己如果输入为空呢如果字符串里有大写呢如果末尾没有标点怎么首尾相连如果全部是空字符串呢每问一个边界问题就是逼自己去检查代码里那些没考虑到的分支。很多隐藏bug就是这么被问出来的。这种方法比单纯用调试器翻来覆去地看代码效率高因为它是主动的、结构化的思考而不是被动地盯着一堆变量发呆。我经常带新人用这个方法查bug效果特别明显。让新手把代码的执行路径讲一遍讲到一半他往往自己就跳起来说“我知道了这里漏了一个判断”。这个从“讲不清”到“突然通了”的过程就是费曼学习法在调试场景里的价值。3. 环境与工具让费曼法的“输出”过程更顺畅3.1 VSCode与WSL在Linux环境下写代码的几个配置要点有些读者问到“WSL Ubuntu写代码最推荐的字体”这个问题的背后其实是想在Windows上复制macOS的开发体验。我用了一段时间的WSL之后比较确定的解决方案是这样的把Windows Terminal和VSCode的字体都设置成支持连字的等宽字体比如JetBrains Mono或者Cascadia Code然后把字号调成14开启字体连字整体观感会非常接近macOS上的体验。配置上可以留意这几点在VSCode的settings.json里设置“editor.fontFamily”为“JetBrains Mono”把“editor.fontLigatures”设为true。终端字体建议和编辑器保持一致这样你在终端里编译输出的内容和编辑器里的代码看起来是同一种风格。WSL下编译C语言装好build-essential就行不到万不得已不要折腾复杂的交叉编译。这些环境工作看着和学习方法没直接关系但其实影响很大。环境顺了你才乐意多写、多讲、多输出费曼学习法的“输出”环节才能真正跑起来。很多人学不下去不是方法问题是环境问题。界面难看、字体发虚、代码提示动不动就没了光是这些就能耗尽你所有的学习热情。3.2 代码提示不是万能的一个真实的报错场景热搜词里有一条“vscode写c没有代码提示”。这个坑我遇到过而且困扰了挺久。后来发现VSCode对C语言的智能感知依赖C/C扩展和includePath设置。如果你的项目没有正确配置includePath那么即便装了扩展代码提示也经常是空的。这个问题的深层问题其实是很多人习惯了IDE写代码时到处弹提示一旦没有提示就写不下去。从费曼学习法的角度看这是好事因为提示相当于一个“拐杖”它替代了你本该自己记住的API知识。平时你可以依赖它但在学习阶段不妨偶尔关掉提示逼自己默写函数签名写不出来的地方就是盲区再去查去补。等你能在一分钟内无提示写出常用函数那些基础就不再依赖环境了。还有一个读者问过为什么在VSCode里写Lua脚本每行代码都被一个框框住。这通常不是代码问题而是编辑器开启了缩进参考线或者行高亮可以在设置里搜索“indent guides”或“highlight active line”调整。这类看似琐碎的配置问题其实也适合用费曼法来学习——试着向别人解释“为什么会有这个框”你会顺便搞懂编辑器的渲染机制。3.3 代码托管与版本管理gitee上放代码的正确姿势热搜词里有“如何把已经写好的代码文件放到gitee里”这个操作本身不难但背后的版本管理意识值得讲一下。放到gitee上的代码本质上就是你的“输出物”是费曼学习法里“讲给别人的成果”。我建议即使是个人练习项目也要养成提交到远程仓库的习惯。因为查看历史记录、回滚、分支管理本身就是一种复盘可以看到自己代码的演化过程。具体步骤可以这样在gitee上创建仓库拿到仓库地址。这一步注意别勾选“初始化仓库”避免产生冲突。本地进入项目目录执行git init把当前目录变成Git仓库。执行git add .把文件加入暂存区再执行git commit -m first commit提交。执行git remote add origin 仓库地址然后git push -u origin master推送。这些命令写出来可能很多人都会但真正坚持做的人不多。我的体会是养成提交的习惯后你再回头看一个月之前写的代码那些“当时觉得天衣无缝、现在不忍直视”的瞬间恰恰是水平提高的最直接证明。这也是费曼学习法中“回顾”这个环节最自然的落地方式——不是靠记忆而是靠版本记录去看到自己的成长轨迹。3.4 Python代码在哪写环境选择背后的学习方法热搜词里“python代码在哪里写”这个问题对新手来说可能很纠结。我的建议很简单写Python不要纠结编辑器先装一个解释器再打开任何一个文本编辑器直接写.py文件用命令行跑起来然后再慢慢转移到VSCode。这么说的原因在于Python的核心是解释器环境配置的复杂度越低越容易保持学习的节奏。如果你一上来就折腾anaconda、虚拟环境、IDE插件很可能还没开始写第一行代码就已经被环境劝退了。从费曼学习法的角度环境的复杂度会严重干扰“输出”的动机。环境越简单你越愿意多写写出东西来了才有东西可以“讲给别人听”。很多人学编程死在了环境配置这一步其实挺可惜的。先写起来哪怕用最简单的记事本把Hello World跑通再一点一点加条件判断、循环、函数每一步都验证一下每一步都试着讲给自己听这才是最快的路径。4. AI时代的费曼学习法工程师会不会被替代4.1 AI辅助编程下能力反而更重要热搜词里有一条很扎眼“ai抢走写代码工作谁来培养工程师”。这个问题其实触到了很多人的焦虑。我自己用AI写代码也有一段时间了包括让AI辅助写小函数、生成测试用例、甚至做代码review。但我的感受是AI能把效率放大很多但没办法替代你的判断力。比如AI给的代码可能是错的或者给出的方案不适合你的场景。如果你没有足够的底子去判断直接照单全收反而会引入很难察觉的问题。费曼学习法在AI时代反而更有价值了原因很简单AI可以帮你把代码写出来但如果你没有能力把代码讲清楚你连“它写得好不好”都没法判断。我们不妨把AI当成一个学伴它负责输出代码你负责把关。把关的过程就是一个费曼式的训练你问自己这段代码为什么这么写有没有更简单的方案边界情况处理好了吗这些问题恰好需要清晰的头脑来回答。没有费曼式的思考习惯你连提问都不知道从哪里问起。4.2 codex、springai等工具辅助下怎么用费曼法学得更深现在AI编程工具很多比如codex还有springai这类把AI能力整合到应用里的框架。很多人会问有了这些工具我还需要学写代码吗我的答案是工具替代的是重复劳动替代不了理解。这就好比你用计算器不代表你不懂数学但你如果连基本运算规则都不知道算错的时候你根本发现不了。一个可操作的建议是“先想清楚再让AI动手”。用费曼学习法的逻辑你先用自己的话把需求描述清楚包括输入、输出、边界条件。这一步你描述得越好AI输出的质量就越高。描述不清楚的时候别急着甩给AI先把盲区补上。这个过程其实就是费曼学习法的第一步和第二步选定概念、尝试讲出来。另一个建议是让AI给你出题你来解题。比如让AI生成一段代码并要求你解释每一行的作用然后你用自己的话复述再让AI挑毛病。这就像请了一个随时在线的私教而且他不会不耐烦。这不代表你偷懒反而是一种更高效的学习方式因为你始终站在主动输出的一方。4.3 从写代码到评审代码工程师能力的下一步AI自动生成测试用例、自动做代码review这些在热搜词里被称为“harness工程化”本质上是用工程化的方式把AI的能力嵌入开发流程。在这个趋势下工程师的核心技能正在从“写”向“审”迁移。我自己做代码review时最常问的是“为什么”。这段代码为什么这么写为什么用这个数据结构不用那个为什么没有考虑并发为什么这里不做空值判断这些问题AI不一定能替你回答需要你对系统有整体的理解。而“整体理解”恰恰是费曼学习法反复训练出来的能力——因为系统的完整逻辑你都能讲清楚才能指出某个局部哪里不对。所以我这几年一直跟团队里的人说别只练“写”要多练“讲”。你要能把一段代码从需求到实现从头到尾讲明白你才有资格说自己是工程师而不是代码翻译机。AI会抢走那些只会复制粘贴、讲不清代码逻辑、遇到问题就抱怨工具的人的工作但它抢不走真正理解系统、能清晰表达复杂逻辑的人的工作。5. 实操心得与避坑经验最后分享几个我在实践费曼学习法和写代码过程中踩过的坑以及总结出来的心得。这些经验有些是教训换来的希望你能避开。第一别贪多。费曼学习法最怕一次讲一大堆讲着讲着就变成背诵了。我一直给自己定一个规矩一次只讲一个小点这个小点能用一个小时的实践讲明白就已经很好了。比如“怎么写C代码给字符串补零”严格说起来花三十分钟把边界情况和不同实现讲清楚就算完成了一次高质量的学习。贪多嚼不烂这句话在费曼学习法里是铁律。第二讲不出口不等于不会。有时候你心里明明懂但表达不出来这可能是措辞问题不一定是理解问题。这时候我的建议是换一种输出方式。代码这东西除了说话还能画图、写注释、画流程图总能找到适合自己的表达方式。关键是别因为一次表达不畅就否定自己觉得“我可能不适合编程”。多试几种表达方式总能找到一个顺手的。第三坚持“代码留在仓库里”原则。很多人学编程的时候喜欢在本地写完就跑既不提交也不记录过两天再来看就完全不认识了。我一直用的一个笨办法是每次学到一个新东西就用一个最小demo把它记录到gitee仓库里哪怕代码只有几行也是一个可复现的成果。这个习惯比任何付费课程都有用。第四AI不是敌人但也不能全信。我让AI生成的代码默认持怀疑态度尤其是涉及边界情况、性能、安全的部分一定会自己看懂再合入。判断AI代码好坏的标准还是你对这个领域的理解深度而深度只能靠费曼式的输出一点点积累。费曼学习法和写代码结合说到底就是把“看懂”变成“能讲”把“能跑”变成“能复现”。这个过程不轻松但每跑通一个知识点那种踏实的成就感比刷一百条教程视频都实在。我现在每次遇到新东西第一反应依然是尝试把它讲明白可能是写进博客、可能是录一小段视频也可能是直接拉着同事到白板前说一通。你也试试说不定会跟我一样上瘾。