AI 时代的学习心法

要点

  • 先说最容易引起争议的一句
  • 如果执行层面可以更多交给 AI，那什么东西必须牢牢抓在自己手里
  • 如果你希望这门专栏真正内化成自己的能力，那你之后看每一篇文章，都不要只看「代码怎么写」，而要重点问下面几个问题
  • 如果把话再讲透一点，未来最稀缺的开发能力，并不是「能把代码写出来」
  • 最后给你一个我认为最适合这门专栏的学习方式

内容

1. 概述

如果你已经在 AI 时代写过一段时间代码，你大概率会有一种很矛盾的感受。

一方面，你会觉得现在的开发效率比过去高太多了。一个想法刚冒出来，AI 就能迅速补出原型、生成接口、拼出页面、填上样板代码，甚至还能顺手把报错一起修掉。很多以前要查半天资料、翻一堆文档、试很多次才能落下来的东西，现在几轮对话就能推到一个可运行的状态。

但另一方面，你又会越来越焦虑。因为你很难判断：自己到底是真的变强了，还是只是借着 AI 的能力把事情推过去了。你会开始担心，一旦没有 AI，自己是不是又回到原地；你也会担心，自己是不是只学会了「会提需求」，却没有真正建立工程上的判断力。

这篇文章就是专门回答这个问题的。

我想先把一个核心观点摆在最前面：

  1. 在 AI 编程时代，执行层面，我们应该充分信任 AI；
  2. 但在架构层面、抽象层面、系统边界层面，你必须比过去更清醒、更主动

这个观念，会直接决定你后面怎么学习这门专栏

如果你把 AI 只当成一个「更快的搜索引擎」，那你依然会被大量细节困住，学习过程仍然会很重；如果你把 AI 当成「一个完全替你思考的黑盒」，那你很快又会失去对系统的控制力。真正有效的方式是：把执行交给 AI，把判断留给自己。

而这门专栏，本质上就是帮助你把「判断能力」逐步搭起来的一个过程。

因此，这本专栏，开篇跟大家分享的是最核心、最重要的完整的项目架构，而不是拘泥于知识细节的实现。

2. 先建立一个新的学习分工

过去我们学编程，默认路径通常是这样的：

  1. 自己读文档
  2. 自己写第一版代码
  3. 自己查错
  4. 自己重构
  5. 最后才慢慢理解为什么要这么设计

这条路径在过去是一种常规的学习路径，我们亲手把每一步都走完，这样的感觉很踏实，然后你才能知道系统到底是怎么工作的。

但到了今天，这条路径已经不再是最优路径。

现在更合理的方式，应该变成：

  1. 自己先定义目标
  2. 自己先判断系统边界
  3. 让 AI 快速完成执行层面的铺设
  4. 自己重点检查结构是否合理
  5. 再围绕关键节点做深入理解

这背后有一个很重要的变化：

学习的重点，不再是「我能不能手写出全部细节」，而是「我能不能判断哪些细节值得我亲自理解」。

这就是 AI 时代最重要的学习心法之一：不要平均用力

很多人用 AI 时最容易犯的错误，就是仍然沿用过去的学习习惯：每个小 API 都要自己死记，每个参数都要自己抠，每个工具都想先完全理解再动手。结果就是，明明已经进入了一个高杠杆时代，却还在用低杠杆的方式学习。

真正高效的学习，不是把所有东西都学得一样细，而是先把系统中的「关键层」抓出来。

比如在这门专栏里：

  • LangChain 的某个 API 具体叫什么名字，没有那么重要
  • 一个 Runnable 的参数细节，也没必要一上来全部死记
  • 某个库的边缘配置，AI 随时都能补

但下面这些东西就非常重要：

  • 为什么一个 AI 应用需要「记忆」
  • 为什么要做「状态管理」
  • 为什么「工具调用」和「流程编排」不能混成一团
  • 为什么单 Agent 到多 Agent 的演进，本质上是系统复杂度变化，而不是「高级感升级」
  • 为什么一个看似能跑的 Demo，离真正能上线的产品，中间还隔着可观测性、灰度验证、部署、数据一致性等工程层

这些问题，才是真正值得你花时间啃透的部分。

3. 执行层面，为什么要充分信任 AI

先说最容易引起争议的一句：

在执行层面，你应该充分信任 AI。

这里的「信任」，不是盲信，也不是把脑子关掉，而是你要承认一个现实：在大量实现型任务上，AI 的产出速度和试错速度，已经明显优于人类手工推进。

什么叫执行层面？

你可以把它理解成那些「有明确目标、可快速验证、出错成本可控」的工作，例如：

  • 根据接口定义补一份请求封装
  • 按照既定样式把组件拼出来
  • 根据现有结构生成一段表单逻辑
  • 按照已有模式补测试
  • 依据报错堆栈排查明显的类型问题
  • 按照已有风格补一个路由、layout、页面骨架

这类工作有一个共同特点：判断空间相对有限，验证路径相对清晰。

只要你知道自己要什么，AI 往往可以更快地交付第一版。

很多人不愿意承认这一点，是因为心里还有一个旧信念：只有自己一行一行敲出来的代码，才算「真的会」。

这个信念在今天已经不成立了。

因为工程世界里，真正昂贵的不是「把代码敲出来」，而是：

  • 知道该做什么
  • 知道不该做什么
  • 知道哪里要快，哪里要稳
  • 知道哪一层可以妥协，哪一层不能出错

如果 AI 能帮你把「敲代码」这件事显著加速，那你应该高兴，因为这意味着你终于有更多预算去做那些更重要的判断。

换句话说：

AI 不是在削弱你的价值，而是在逼着你的价值往更高层移动

所以在这门专栏里，你需要有种新的学习姿势：

  • 第一版实现，可以先交给 AI
  • 某个局部代码，不必从零手写
  • 某个小工具，先跑起来再说

但这并不意味着你「什么都不用懂」。它只是意味着，你不需要再把时间平均撒在所有执行细节上。

4. 架构思维，必须牢牢抓在手里

如果执行层面可以更多交给 AI，那什么东西必须牢牢抓在自己手里？

答案是：架构思维。

这里的架构，不是那种只有 CTO 才关心的「宏大词汇」，也不是画几张框图就叫架构。对个人开发者来说，架构思维首先是一种组织复杂度的能力。

你要知道：

  • 这个系统要分几层
  • 哪些能力该独立出来
  • 数据从哪里来，到哪里去
  • 状态在哪一层维护
  • 工具调用和业务逻辑如何解耦
  • 同一类责任应不应该放在同一个节点里
  • 一段代码是临时可跑，还是长期可维护

这些问题 AI 可以给你建议，但最后拍板的人必须是你自己。

因为 AI 很擅长「局部最优」，但它并不天然等于「全局最优」。

举个很现实的例子：

假设你要做一个 AI 电子伴侣：

  • 它要记住用户的长期偏好
  • 它要根据当前对话做情绪判断
  • 它要能够调用天气、日程、搜索等工具
  • 它还要在多轮对话中维持状态

AI 可以很快给你生成一堆代码，但如果你自己没有架构意识，很容易把这些能力全部堆进一个大 Prompt、一个大 Agent、一个大函数里。短期看起来也许能跑，但一旦需求继续加深，系统马上就会变得非常难改。

真正决定系统能不能长期演进的，不是 AI 有没有帮你补出一段函数，而是你有没有先想清楚：

  • 什么是上下文召回
  • 什么是工具调用
  • 什么是流程编排
  • 什么是状态管理
  • 它们彼此之间的边界应该如何划分

这也正是本专栏的核心价值所在。

本专栏不是在教你「怎么背几个 AI 框架的 API」。

本专栏真正要建立的是：你对 AI 应用系统结构的判断能力

5. 以后看每一篇文章，都要问这几个问题

如果你希望这门专栏真正内化成自己的能力，那你之后看每一篇文章，都不要只看「代码怎么写」，而要重点问下面几个问题：

5.1 这一篇文章解决的是哪一层问题

有些文章在讲能力边界，比如记忆、工具调用、编排；

有些文章在讲工程承载，比如部署、观测、Tracing、灰度；

有些文章在讲系统演进，比如从单 Agent 到多 Agent、从简单对话到复杂状态流转。

你要先学会判断：这篇文章是在解决「局部实现问题」，还是在解决「系统结构问题」。

因为这会决定你应该如何吸收它。

局部实现问题，可以更多依赖 AI 帮你补全，学习时就可以快速跳过

系统结构问题，你必须亲自想明白。

5.2 这一层和上下游是什么关系

真正的理解从来不是理解孤立概念，而是理解关系。

比如你学「记忆系统」，不能只知道向量库怎么查；你还要知道：

  • 它在整体链路里的触发时机是什么
  • 它和当前对话上下文怎么配合
  • 它查出来的东西如何进入生成环节
  • 它什么时候会污染结果

再比如你学「流程编排」，不能只知道图节点怎么连；你还要知道：

  • 状态对象为什么要这么设计
  • 哪些字段应该在节点间传递
  • 哪些步骤是串行，哪些可以并行
  • 失败后从哪里恢复最合理

一旦你开始这样看问题，你就不再只是「学一个知识点」，而是在建立系统级视角。

5.3 哪部分值得自己深挖，哪部分交给 AI

这是整门专栏里最实用的学习能力。

不是所有内容都值得你花同样多时间。

你要学会做一个取舍：

  • 能快速验证的实现，交给 AI
  • 会影响系统边界的判断，自己深挖
  • 与框架版本强相关的细节，不死记
  • 跨框架都成立的抽象，重点掌握

比如一个 Hook 的具体参数你忘了，AI 可以随时补；

但为什么这里需要 Hook，而不是一个全局状态容器，这种判断要靠你自己建立。

6. AI 时代真正稀缺的，不是写代码，而是做判断

如果把话再讲透一点，未来最稀缺的开发能力，并不是「能把代码写出来」。

因为纯执行工作正在快速被压缩。

真正会越来越值钱的，是下面这些能力：

  • 把模糊问题说清楚
  • 把复杂系统拆成可管理的层次
  • 为一个系统设计合理边界
  • 在多个方案之间做取舍
  • 能快速识别哪里是伪复杂，哪里是真复杂
  • 知道什么时候该追求速度，什么时候必须优先稳定性

这些能力不会因为 AI 变强而贬值，反而会因为 AI 足够强而被进一步放大。

因为当所有人都能快速生成代码时，真正拉开差距的就不是“谁写得更快”，而是“谁判断得更准”。

这也是为什么我会建议你在学习本专栏时，始终把重心放在“系统判断力”上。

你可以不要求自己第一遍就把所有代码都手写出来。

你也不用焦虑某一段样板代码不是自己敲的。

但你一定要反复追问：

  • 这个设计为什么成立？
  • 它解决的是哪一层问题？
  • 如果需求再扩大一倍，哪里会先出问题？
  • 如果我要把它做成真正上线的产品，我下一步应该补什么？

一旦你开始这样思考，你的成长速度会远远超过那种只盯着 API 和语法细节的学习方式。

7. 这门专栏最适合怎样学习

最后给你一个我认为最适合这门专栏的学习方式：

7.1 第一遍：先建立地图

第一遍不要追求全部细节吃透。

你更应该做的是建立地图。

也就是先搞清楚：

  • AI 应用整体由哪些层组成
  • 每一层主要解决什么问题
  • 每一篇文章在整个体系里处于什么位置

这一步的目标不是成为专家，而是先让自己知道「全貌是什么」。

7.2 第二遍：围绕关键节点深挖

有了全貌之后，再挑最关键的节点深入，例如：

比如：

  • 为什么记忆系统会成为 AI 应用的核心基础设施
  • 为什么 LangGraph 更适合处理复杂流程
  • 为什么可观测性不是锦上添花，而是线上系统的生命线

这一步，你就可以借助 AI 辅助自己做笔记、总结、补案例，但核心判断要由你自己来完成。

7.3 第三遍：边做边学

等你真的开始做项目时，这门专栏会进入第三种学习状态：边做边学。

这时候你会发现，很多原本觉得抽象的概念，都会突然变得具体。

你会知道为什么一个系统不能把所有能力全堆在一个 Agent 上；

你会知道为什么状态对象一旦没设计好，后面图就越来越难接；

你会知道为什么没有指标和 tracing，线上出了问题根本无从下手。

而这时候，AI 最好的用法不是代替你思考，而是帮你把那些“已经判断清楚”的事情加速落下来。

8. 总结：把 AI 当成执行合伙人，把自己训练成系统设计者

如果把这篇文章压缩成一句最重要的话，那就是：

把 AI 当成执行合伙人，而不是学习替代品；把自己训练成系统设计者，而不是细节搬运工。

你当然可以继续去研究实现细节。

你当然也应该知道一套系统最终是怎么跑起来的。

但在 AI 时代，更重要的是先抓住决定系统质量上限的那部分能力。

对这门专栏来说，那部分能力就是：

  • 对 AI 应用结构的理解
  • 对复杂系统边界的判断
  • 对工程化落地路径的把握

只要这根主线抓住了，后面的记忆、工具、编排、状态、部署、观测、验证，都会逐渐被你串成一个完整体系。

而如果这根主线没抓住，你就算看了很多文章、抄了很多代码，也很容易停留在“知道一些点，但连不成系统”的阶段。

所以，把这篇文章放在最前面，不是为了给你灌鸡汤，而是为了先帮你校准学习姿势：

实现交给 AI，理解留给自己；细节可以借力，结构必须亲自掌握。

接下来阅读本专栏时，你可以不断回到这条主线：

  • 这一篇是在补哪一层能力？
  • 这一层为什么存在？
  • 它和整个 AI 应用系统是什么关系？

只要你始终带着这种问题意识往下读，这门专栏给你的就不只是几个知识点，而是一套在 AI 时代依然足够稳定、足够长期的学习与建构方法