起因
AI 编程已经成为主流。Claude Code、Codex、Cursor——这些工具让"写代码"这件事变得越来越不需要人类亲自动手。一个自然的问题浮出水面：如果 AI 都能写了，我们还要学什么？怎么学？
我把这个问题抛给了 Claude Fable 5，得到了一个让我很有共鸣的回答。记录在这里，推荐给所有正在思考这个问题的人。
变化的核心：从记忆到理解
AI 能写代码，但它写的是你已经想清楚的东西。你没想清楚，AI 给你的就是看起来能跑但解决错问题的代码。
所以学习的核心转变了：
从"记忆语法和 API" → 转向"建立心智模型"
不是说语法不重要了，而是它不再是瓶颈。瓶颈变成了：你能不能准确描述你要什么，以及你能不能判断 AI 给的东西对不对。
以 LangChain 为例
不再需要的
- 背
LLMChain怎么初始化、PromptTemplate的参数是什么 - 记住每个类的方法签名
- 手写样板代码
这些交给 AI 就行。
还是需要的，甚至更重要
1. 搞清楚它解决什么问题
LangChain 存在的意义是什么？它在抽象什么？它的核心组件（Chain、Agent、Memory、Retrieval、Tool）各自的职责边界在哪里？这些概念为什么这样划分而不是另一种划分法？
理解这层，你才能判断"这个任务该用 LangChain 还是直接调 API"，以及"AI 给我生成的这段代码，架构上合不合理"。
2. 能读懂并批判 AI 生成的代码
AI 写的代码不能照单全收。它可能用了过时的 API、选了错误的组件、忽略了生产环境的边界情况。学习目标从"能写"变成"能审"——你是代码的评审者，AI 是初级程序员。
3. 深入调试一次
找一个真实的出错案例，别让 AI 直接帮你改。自己打断点、读报错栈、翻源码。这一次手动调试带来的理解，比读十篇教程都扎实。
框架在出错的时候才会让你真正理解它的内部逻辑。
4. 理解权衡
为什么 LangGraph 出来了？LangChain 解决了什么、又引入了什么新问题？这些取舍的背后是什么工程判断？
这是 AI 答不好的问题，需要你主动去对比、思考。
新的学习流程
概念优先 → 用 AI 生成 → 亲手拆解 → 主动打破 → 复盘判断第一步：看官方文档的"概念"部分，不是 Quick Start
先理解框架的设计哲学和核心抽象，再去看用法。很多人跳过这步，导致用了很久却不知道自己在用哪一层。
第二步：让 AI 帮你写一个你已经理解的东西
不是"帮我写一个 RAG 应用"，而是"我已经知道 RAG 的流程是：文档切片→embedding→向量存储→检索→组装 prompt，帮我用 LangChain 实现这个流程"。
你对问题的理解越清晰，AI 输出的质量越高，你也更容易发现它的错误。
第三步：读生成的代码，提问
逐行问自己：这行在做什么？为什么这样而不是那样？如果改成另一种写法会怎样？
不懂的地方继续问 AI，但要追问"为什么"，不只是"是什么"。
第四步：故意破坏
改一个关键参数，删一个组件，换一种数据格式，看它怎么出错。
出错的时候系统暴露自己的内部结构，这比一切正常时学得快得多。
第五步：问自己"这个框架值得用吗"
这是最高阶的判断。LangChain 在某些场景下确实被很多人认为过度封装。你能做出这个判断，说明你真正掌握了它而不是只会调用它。
新的衡量标准
以后衡量一个人技术水平的，不再是"会不会写代码"，而是：
- 能不能提出正确的问题
- 能不能判断 AI 给的答案对不对
这本质上要求更深的理解，不是更浅的理解。
学得浅，AI 给什么你用什么，出了问题完全不知道从哪下手。学得深，你把 AI 当工具，而不是依赖它。
我的感悟
这场对话让我重新审视了自己的学习方式。过去追求"会用"，现在应该追求"理解为什么这样用"。AI 降低了编码的门槛，但同时抬高了真正有价值的能力的标准——系统思维、架构判断、问题定义。
工具在变强，人需要站得更高。不是站在代码层面，而是站在决策层面。
与其焦虑 AI 会不会取代你，不如想想：你能不能成为那个告诉 AI 该做什么的人？
