我的学习方法：笔记、代码、项目和复盘，一个都别装

我为什么写学习方法

学 Python 和 AI 的过程中，我最怕的不是某个知识点难。

难可以慢慢啃。真正麻烦的是：我感觉自己学了很多，但它们没有变成自己的能力。

这种情况太常见了。

• 概念记住了，换个问题就不会用了。
• 代码写过，报错时开始沉默。
• 项目跑通了，让自己讲架构又讲不清楚。
• 新词记了一堆，但不知道它们在项目里到底解决什么问题。

这种学习状态很像健身只买装备。

鞋有了，手套有了，训练计划也排好了，甚至连蛋白粉都研究过了。结果真正开始练的时候，发现自己连热身都不稳定。

所以我不想把这个系列写成“知识点整理”。

如果只是把现成结论按章节重新排列，最后得到的仍然是一堆没有经过验证的信息。看起来很完整，遇到实际问题时却不一定能用。

我更想用一种能沉淀能力的方法来学：

笔记 + 代码 + 项目 + 复盘

这四个词看起来朴素，但很抗用。

这一篇的核心理解

我的学习方法可以概括成一句话：

每个知识点都要经过“理解、运行、连接、复盘”四步，才算真正学过。

对应到具体动作，就是：

• 用笔记把概念讲清楚。
• 用代码把概念跑起来。
• 用项目把知识点串起来。
• 用复盘把经验沉淀下来。

这四步缺一块，学习都会变形。

只有笔记，没有代码，容易变成纸面理解。说起来头头是道，一运行全是红字。

只有代码，没有笔记，容易跑通了但说不清。今天能跑，明天忘了为什么这么写。

只有零散练习，没有项目，容易不知道真实场景怎么组合。

只有项目，没有复盘，容易做完就算。下一次遇到同样的问题，再完整踩一遍。

我不想让学习停在“接触过”。我更想让每个阶段都留下可验证的东西：

一篇能讲清楚的笔记
一段能运行的代码
一个能复盘的小项目
一个下次还能用的经验

第一步：用笔记把概念讲清楚

我写笔记的目标，不是把现成定义完整复制下来。

搬运定义这件事，剪贴板做得比我专业。

我真正要做的是：把自己理解的部分讲清楚，把卡住的地方写出来，把这个知识点和后面的项目联系起来。

一篇合格的学习笔记，至少要回答四个问题：

• 这个东西解决什么问题？
• 我之前为什么不理解？
• 它最小可用的例子是什么？
• 它和后面的大模型项目有什么关系？

比如学习 Python 文件操作。

如果只是记录 open()、read()、write() 的语法，当然有用，但还不够。

我更应该追问：

• 为什么 AI 项目里经常要读文件？
• 文档加载和文件操作是什么关系？
• 文本编码错误为什么会影响知识库构建？
• 如果文件读取失败，程序应该怎么处理？

这样写出来的笔记，才不是孤立知识点，而是通向后面项目能力的一块砖。

我会尽量避免写成这种形式：

Python 文件操作包括打开文件、读取文件、写入文件、关闭文件。

这当然正确，但正确得有点安静。

我更希望写成这种形式：

我一开始以为文件操作只是基础语法，后来做知识库问答时才发现，
文档读取、编码处理、异常捕获和路径管理，都会直接影响 RAG 项目的稳定性。

这两种写法的区别在于：前者是知识罗列，后者是学习成长。

我需要的是后者。

第二步：用代码把概念跑起来

只写笔记不够。

技术概念停留在文字里时往往很温顺，一写代码就会露出真实面目。

路径不对、环境不对、依赖没装、数据格式不对、接口返回不符合预期，这些问题不会出现在纯概念学习里。

它们只会在你满怀信心运行代码时出现。

所以每个关键知识点，我都会尽量配一个最小代码例子。

最小例子的原则是：

• 尽量短。
• 能独立运行。
• 只说明一个核心问题。
• 输入和输出明确。
• 报错时容易定位。

比如学习函数时，不需要一上来写复杂项目，可以先写一个和 Prompt 有关系的小函数：

def build_prompt(question: str, context: str) -> str:
    return f"请根据以下资料回答问题：\n{context}\n\n问题：{question}"


prompt = build_prompt(
    question="Python 为什么适合学习 AI？",
    context="Python 语法简单，AI 生态完整，适合数据处理和模型调用。"
)

print(prompt)

这个例子很小，甚至有点朴素。

但它把 Python 函数和后面的大模型 Prompt 连接起来了。

这就是我希望采用的写法：基础知识不孤立讲，而是尽量和后续 AI 应用建立连接。

学函数，不只是为了会定义函数。

学函数，是为了后面能封装模型调用、检索流程、工具执行和异常处理。

第三步：用项目把知识点串起来

零散知识学多了之后，很容易产生一种错觉：

每个点我好像都懂，但放在一起我就不太懂了。

这很正常。

因为真实项目考的不是单个知识点，而是组合能力。

一个 RAG 项目里，可能同时需要：

• Python 基础语法
• 文件读取
• 文本清洗
• 文档切分
• Embedding
• 向量数据库
• Prompt 设计
• 大模型 API
• 输出解析
• Web 接口
• 异常处理
• 日志和配置

单独看每个点都不算吓人。

但放在一起，项目就开始露出真实脾气。

文档读错，后面全错。

切分不合理，检索效果差。

Prompt 没写清，模型开始自由发挥。

输出没校验，前端收到一段看似认真但格式全乱的内容。

所以我会在每个大的学习阶段后，安排一个小项目或项目复盘。

比如：

• 学完 Python 基础后，做一个文件批处理脚本。
• 学完 MySQL 后，做一个简单的数据查询工具。
• 学完 Pandas 后，做一个数据清洗小案例。
• 学完机器学习后，做一个分类或预测小项目。
• 学完 RAG 后，做一个本地资料问答系统。
• 学完 Agent 后，做一个能调用工具完成任务的小应用。

项目不一定大，但必须完整。

完整的意思是：

有输入
有处理流程
有输出
有异常处理
有复盘

一个小而完整的项目，比一个巨大但讲不清的项目更适合学习。

第四步：用复盘把经验沉淀下来

我以前很容易忽略复盘。

一个项目跑通之后，第一反应通常是：终于结束了，赶紧进入下一个。

后来发现，这样很亏。

因为项目里真正有价值的东西，往往不是最后跑通的那一刻，而是中间那些问题：

• 为什么一开始的方案不行？
• 哪个 bug 花了最多时间？
• 哪个概念理解错了？
• 哪个配置容易遗漏？
• 哪段代码后面应该重构？
• 如果重新做一次，会怎么设计？

这些东西如果不写下来，很快就会消失。

然后下一次再遇到类似问题，大脑会非常自然地说：

这个坑我好像见过。

但具体怎么解决，忘了。

所以每个项目复盘，我会固定写：

• 我为什么做这个项目？
• 项目要解决什么问题？
• 整体架构是什么？
• 核心流程是什么？
• 关键实现有哪些？
• 遇到了哪些问题？
• 我学到了什么？
• 如果重做一次，我会怎么改？

复盘的目标不是证明自己做得完美。

正好相反，复盘要允许自己不完美。它记录的是能力怎么长出来的，而不是把项目包装成从第一天起就设计英明。

真实项目通常不是这样。

真实项目更像：

先想一个方案
跑起来
发现问题
改
又发现问题
再改
最后终于得到一个能解释清楚的版本

复盘就是把这个过程留下来。

我的学习闭环

把上面四步合在一起，我的学习闭环是：

明确目标
-> 提炼问题
-> 写笔记
-> 跑最小例子
-> 做阶段项目
-> 复盘问题
-> 回到下一阶段

这里最关键的是“提炼问题”。

如果只是按照现成的知识顺序往前推进，很容易把“接触过”误当成“掌握了”。内容积累了不少，却不一定知道自己缺什么，也不知道哪一部分能解决当前问题。

如果每一阶段都先问“我现在缺什么能力”，学习就会更有方向。

比如：

• 我写不出稳定脚本，所以补 Python 基础。
• 我不会在服务器上跑代码，所以补 Linux。
• 我不理解数据如何存取，所以补 MySQL。
• 我不知道模型如何学习，所以补机器学习。
• 我不会处理文本，所以补 NLP。
• 我只会聊天不会做应用，所以学 RAG。
• 我想让模型调用工具完成任务，所以学 Agent。
• 我想让模型适应特定任务，所以理解微调。

这样每个知识点都有位置。

位置很重要。

没有位置的知识，容易变成收藏夹里的装饰品。

我踩过的坑

第一个坑，是只积累知识点。

记录得越多，越容易产生“我正在进步”的感觉。但真正有效的学习需要输出和验证。至少要写出一篇自己的解释，或者跑通一个最小例子。

第二个坑，是代码照搬后不再改。

代码原样运行一遍，只能说明它在当前条件下可以工作。真正理解通常发生在我试着改参数、改输入、改结构、处理报错的时候。

第三个坑，是项目只追求跑通。

跑通只是第一步。能不能讲清楚架构，能不能解释为什么这么设计，能不能说出缺点和改进方向，才决定这个项目有没有转化成能力。

第四个坑，是复盘只写结果，不写过程。

如果复盘里只有“完成了某项目，实现了某功能”，价值不大。真正值得记录的是中间的判断、错误、修正和认知变化。

第五个坑，是把学习计划写得太完美。

计划写得越精致，越容易产生一种已经完成了一半的错觉。但计划不是产出，执行才是。

学习计划的价值，不在于排版多漂亮，而在于它能不能让我今天动手写一点、跑一点、复盘一点。

和大模型项目的关系

大模型项目尤其需要这种学习方法。

因为大模型应用不是单纯学习一个框架就够了。它通常涉及：

• 业务需求理解
• 数据准备
• 文档处理
• 模型调用
• Prompt 设计
• 检索增强
• 工具调用
• 状态管理
• 异常处理
• 成本和性能
• 评估和优化

这些能力无法靠记住概念一次性获得，只能在笔记、代码、项目和复盘中逐步形成。

比如学 RAG，如果理解只停留在定义上，可能会觉得它就是“检索 + 生成”。

但真正做项目时会遇到很多细节：

• 文档怎么切？
• Chunk 多大合适？
• Embedding 模型怎么选？
• 检索结果不准怎么办？
• 上下文太长怎么办？
• 回答没有引用怎么办？
• 模型胡说怎么办？

这些问题只有在代码和项目里才会变得具体。

Agent 也是一样。

只从定义出发，它像是一个会自己完成任务的智能系统。真正做起来，会发现它经常需要你认真处理工具定义、状态流转、失败重试、输出校验和日志追踪。

模型负责智能，开发者负责让智能别乱跑。

这句话听起来不浪漫，但很接近真实项目。

小结

我的学习方法很简单：

笔记负责讲清楚
代码负责跑起来
项目负责串起来
复盘负责留下来

这套方法不追求最快，但追求扎实。

我希望这个系列最后留下的不只是几十篇文章，而是一条清晰的成长轨迹：

从会写一点 Python
到能理解数据和模型
再到能做 RAG、Agent 和大模型项目

如果每一篇文章都能让我比上一篇多一个可验证的能力，这个系列就有价值。

学习不是表演进度，项目也不是展示术语。

能跑通，能讲清，能复盘，才算真的往前走了一步。