AI时代，工程师的学习方式已经过时了

有一个观察让我最近想了很久身边那些学得最快的工程师在 AI 工具普及之后并没有变得更快——反而有些人感觉越来越焦虑越来越难以判断自己到底学没学会一件事。问题不在于他们不努力而在于他们的学习方式是为一个已经不存在的时代设计的。传统学习路径是为信息稀缺时代设计的工程师这个职业过去二十年的主流学习路径大概是这样的看官方文档 → 跟着教程敲代码 → 做一个小项目 → 遇到 Bug 去 Stack Overflow 找答案 → 写博客总结 → 重复。这套流程在本质上是在解决一个问题信息获取成本高。你需要知道去哪找答案需要会筛选信息需要把零散知识拼成体系。写博客的价值也在于此——把知识外化出来是对抗遗忘的一种机制。但现在呢信息获取的成本已经趋近于零。你随手问 Claude 一句帮我解释一下 Kotlin 协程的调度机制得到的答案质量可能比你花两小时翻文档还高。Stack Overflow 的流量在持续下滑不是因为问题减少了而是因为人们已经不需要去那里找答案了。信息稀缺的时代结束了。但很多工程师还在用信息稀缺时代的工具和逻辑来学习这就是问题所在。AI 加速了会用和理解之间的鸿沟有一个现象值得警惕AI 工具让工程师在表面上能做到的事情飞速扩展但深层的理解速度并没有同步提升。有个很形象的类比用导航开了十年车的人某天手机没电扔在家里发现自己完全不知道该走哪条路。你以为自己会了其实是工具替你记住了。AI 写代码这件事跟这个一模一样。举个具体例子。让 Claude Code 帮你写一段 Android 的 WorkManager 代码它可以在 30 秒内给出一段能跑的、符合最佳实践的实现。你 copy 过去跑通了问题解决了。这当然很好。但如果下周你需要调试一个 WorkManager 在特定设备上失败的 Bug需要理解 Doze 模式和电池优化对 Worker 调度的影响——这时候你会发现你其实根本不知道这段代码是怎么工作的。更麻烦的是你甚至可能不知道自己不知道。因为你用过它感觉上掌握了但实际上只是借助 AI 完成了一次任务。这个鸿沟在过去也存在复制 Stack Overflow 代码的人很多但 AI 把它放大了几十倍——因为 AI 可以给你几乎所有问题的可运行答案覆盖范围比 Stack Overflow 大得多速度也快得多。结果就是工程师的能力边界感知变得模糊了。你以为自己懂的其实是 AI 帮你做到的。这不一定是坏事但你得清醒地知道这一点。学习的本质从未改变要建立能迁移的心智模型这不是说要抵制 AI那是反智行为。而是说在 AI 大量替代了信息检索和代码生成之后工程师的学习目标需要重新锚定。真正有价值的学习成果是能迁移的心智模型而不是记住具体的 API。什么叫心智模型比如你真正理解了事件循环Event Loop的机制那你不管是在 JavaScript、Kotlin 协程、还是 Python asyncio 里都能快速建立直觉什么东西会阻塞什么是并发什么是并行哪里可能有竞态条件。具体 API 可以查这个底层直觉不能靠查。比如你真正理解了局部性原理Locality你就能在 CPU Cache、数据库索引、Android View 的 RecyclerView 复用策略里看到同一个东西对性能问题有跨域的嗅觉。这类心智模型AI 不会帮你自动建立。它可以帮你验证、举例、纠偏——但构建过程需要你自己完成。AI 时代工程师应该怎么学给出几个具体的、可操作的改变。① 用 AI 做苏格拉底式追问而不是直接取答案当你不理解一个东西时不要直接让 AI 给你解释。先自己说出你的当前理解然后让 AI 告诉你哪里是错的为什么是错的。这个过程比被动接受答案有效得多。举个例子你想搞懂 Kotlin Flow 的背压机制可以这样问具体长这样我的理解是Flow 的背压是通过挂起suspend来实现的 当下游处理不过来时上游的 emit 会自动挂起等待。 这个理解有什么不准确的地方什么情况下这个机制会失效这种问法强迫你先构建一个假设然后用 AI 来验证和修正而不是大脑空着等着被填充。主动建构 vs 被动接收认知留存率差距可以达到3-5倍。② 把 AI 当 pair programmer但你必须是 driverPair programming 里有 driver 和 navigator 两个角色。Driver 负责打字Navigator 负责方向和思路。跟 AI 协作时你永远要是 driver——你决定要做什么、为什么这么做AI 是帮你执行和验证的 navigator。一旦你让 AI 来决定做什么你就降级成了一个 code reviewer而且还是个对代码不够了解的 reviewer。这是最糟糕的状态。具体操作上在让 AI 写代码之前先写一段伪代码或者注释描述你的思路。举个具体例子// 我的思路 // 1. 用 StateFlow 保存 UI 状态避免 LiveData 的 null 问题 // 2. 在 ViewModel 里用 viewModelScope 启动协程生命周期绑定 // 3. 错误状态单独处理不混入 data class // 帮我按照这个思路实现 UserProfileViewModel // 如果思路有问题先告诉我哪里不对这样做的好处即使 AI 写了代码你至少对应该是什么样的有预期review 会更有效而且你的思路本身也在接受验证。③ 用教学测试代替写博客写博客的本质价值是费曼技巧——把东西教给别人才知道自己到底懂没懂。但写博客成本高、反馈慢。替代方案写可以独立运行的教学测试。比如你学了 Kotlin 协程的CoroutineContext不要去写Kotlin协程上下文详解而是写一组注释详尽的单元测试。大概长这个样子class CoroutineContextLearningTest { /** * 验证子协程会继承父协程的 CoroutineContext * 但 Job 对象不继承每个协程有自己的 Job */ Test fun child coroutine inherits parent context but not job() runTest { val parentJob coroutineContext[Job] var childJob: Job? null var childDispatcher: CoroutineDispatcher? null val child launch(Dispatchers.IO) { childJob coroutineContext[Job] childDispatcher coroutineContext[CoroutineDispatcher] } child.join() // Job 不同是独立的 assertNotSame(parentJob, childJob) // Dispatcher 继承自父除非显式覆盖但这里覆盖成了 IO assertEquals(Dispatchers.IO, childDispatcher) } /** * 验证withContext 切换 Dispatcher 不会创建新协程 * 只是切换了执行线程协程本身是同一个 */ Test fun withContext switches dispatcher without creating new coroutine() runTest { val outerCoroutineId coroutineContext[Job].hashCode() var innerCoroutineId: Int -1 withContext(Dispatchers.IO) { innerCoroutineId coroutineContext[Job].hashCode() } // 同一个协程Job 相同 assertEquals(outerCoroutineId, innerCoroutineId) } }这些测试是你真正理解之后才能写出来的。它们可运行、可验证、可作为以后的参考比一篇博客文章的价值高得多——你三个月后翻出来直接能跑而不是要重新阅读。④ 选择有阻力的学习路径认知科学里有个概念叫合意困难Desirable Difficulties——学习时适度的阻力反而会增强记忆和理解因为你的大脑需要努力提取和重构信息。AI 的问题是它把所有阻力都消除了。你遇到问题0.5 秒内就有答案没有任何困难。这在短期内极其爽但长期来看你在用提取强度换遗忘速度。就像健身房里用助力机器代替自由器械——动作完成了肌肉没有真正受力。一个反直觉但有效的做法先自己解题再去看 AI 答案。即使你花了 20 分钟也没做出来这 20 分钟不是浪费的——它建立了你大脑里对这个问题的挂钩让你之后看到答案时理解更深、记得更久。具体可以• 面对新技术先自己设计一个 API 或架构方案再去看官方设计对比差异• 修 Bug 时给自己设一个不许用 AI 提示的 15 分钟先穷尽自己的排查思路• 读源码时先猜实现再翻代码验证而不是一上来就让 AI 总结源码⑤ 把精力放在 AI 不擅长的地方AI 非常擅长把已知的代码模式翻译成新的形式、解释现有概念、生成符合规范的样板代码、找低级语法错误。AI 不擅长截至目前理解你的业务上下文和历史债务、做涉及人的判断比如这个需求值不值得做、在真正的新领域里给出有创造性的方案、对系统整体感的把握。工程师应该把更多学习精力投入到 AI 不擅长的这些地方。系统设计、工程判断、跨域连接、沟通与需求分析——这些能力的培养AI 没法替代你也没法帮你走捷径。关于学习焦虑这件事值得单独说一下。很多工程师现在有一种弥漫性的焦虑新工具太多跟不上AI 发展太快不知道该学什么感觉什么都会一点但什么都不深。这种焦虑的本质是把知道和理解混为一谈同时把技术宽度当成了安全感的来源。现实是在 AI 工具普及之后知道的价值在迅速贬值。能让 AI 帮你检索和整合的知识本质上已经不是你的核心竞争力了。真正的安全感来自于一些很难被复制的东西你对一个系统的深度直觉、你在特定领域积累的判断力、你理解人和业务的能力。这些东西跟你学了多少新技术、装了多少 AI 工具关系不大跟你在真实问题上花了多少心力密切相关。学少一点学深一点选你真正在用的东西深入下去——这是我目前觉得最不会后悔的方向。一些反直觉的结论把上面说的浓缩成几个不那么主流的判断你可以拿来跟自己的经验对照•用 AI 写代码的效率 ≠ 学习效率。生产效率提升是真实的但学习效果可能为负。两件事要分开管理。•技术宽度正在被 AI 平权。你会五门语言AI 也会。宽度已经不再是护城河深度才是。•写博客的价值已经从输出内容变成了建立思考习惯。为了 SEO 或影响力而写的博客价值在下降为了整理自己思路而写的私人笔记价值在上升。•最好的 AI 协作是 AI 帮你更快地犯错和纠错而不是帮你跳过犯错的过程。犯错是学习的核心机制AI 不应该把它消除而应该加速它。•学习路径上的速度感越强可能越危险。两天学会了 XXX的感觉在 AI 时代要打个大问号——你是真的学会了还是 AI 帮你完成了下一步值得想的问题最后留一个问题你上一次真正卡住是什么时候不是指 AI 给了错误答案、你去找了正确答案那种卡。是指你在一个问题上想了很久翻了很多资料还是不确定答案最后做了一个判断事后还在反复验证那种卡。如果你想不起来或者上一次是很久以前——那可能说明你的学习过程已经太顺滑了。顺滑不一定是好事。值得探索的方向能不能设计一套专属于自己的AI 辅助 刻意练习学习系统不是拒绝 AI而是把 AI 的能力嵌入到有意识的学习框架里。这个问题没有通用答案但每个工程师都值得认真想一想。如果这篇文章对你有帮助欢迎转发给同在思考这些问题的工程师朋友。