我在 2023 年底给 LangChain 提了一个 PR，是修复一个中文文档处理时的 tokenizer 问题，代码加起来 50 行不到。那个 PR 被一个 Maintainer review，他指出了两个我没想到的边界情况，修改了两次才合并。那次 review 的收获，比我自己瞎写一个月代码学到的东西更多。

策略三：技术写作——把学到的东西写出来

写作是学习的最好方式，因为写作会逼你把模糊的理解变成清晰的表达。

很多东西，你以为自己懂，直到你坐下来写，才发现有很多细节没搞清楚。写作的过程，就是把这些细节一个个填补的过程。

而且写出来的东西，会吸引到和你有共同兴趣的人，这些人会带来新的刺激和想法。

我在最低谷的那三个月，是从重新开始写作里找回感觉的。那时候我强迫自己每周写一篇，写什么都行，但必须是我真正学到或者想到的东西，不是凑数。

写了一个月之后，有读者给我发私信，说我的一篇踩坑记录帮他解决了一个困扰很久的问题，那个私信让我感受到：我做的事情是有意义的。这种感受，是在公司工作里很少能得到的。

策略四：在工作里主动寻找学习机会

这是最难的策略，因为它需要你主动争取，而不是被动等待。

在工作里找学习机会，有几个具体的做法：

主动接复杂需求。 当有一个没人想做的复杂需求（比如性能优化、系统迁移、新技术引入），主动举手。复杂的事情有成长，简单的事情只有消耗。

做小范围的技术改进。 工作里的代码不是都是不可改变的。找一个小的、影响范围有限的地方，用你想试的技术或者模式去改进它，然后观察结果。不需要征得所有人同意，找一个可以小范围实验的地方。

主动 review 别人的代码，并认真思考。 Code review 不只是检查错误，而是理解别人解决问题的方式，思考有没有更好的方法。这是很多工程师浪费的一个学习机会。

参与技术决策的讨论。 如果团队在做技术选型，不要只做旁观者。查资料，形成自己的判断，在讨论里表达出来，即便你不是最终决策者。

识别工作中真正的学习机会

有一个问题我经常被问：在工作里怎么找到能成长的机会？

我的判断框架是这样的：

第一问：这件事你做完之后，能不能解释给别人听？

如果做完了，你说不清楚做了什么、为什么这么做、遇到了什么问题、怎么解决的——说明这件事没有真正的学习发生，你只是机械执行了。

能讲清楚的工作，才是真正在学的工作。

第二问：这件事做完，你的下一件类似的事会不会做得更好？

如果这件事做完，下次遇到类似的还是一样茫然，说明这件事没有迁移价值。

有学习价值的工作，做完之后会让你对这类问题有新的理解和方法。

第三问：这件事有没有你没见过的问题？

完全熟悉的工作，做起来很流畅，但没有成长。有没见过的问题的工作，做的过程会有摩擦、会不舒服，但摩擦的地方就是成长的地方。

什么时候应该换工作

这是个很具体的问题，我想给一个不模糊的答案。

应该考虑换工作的信号：

连续 6 个月，你在工作中没有接触过任何新东西，而且你已经尝试了主动寻找机会，没有结果
团队的技术水平和氛围，明显低于你现在的水平，没有人能在技术上对你有挑战和启发
公司的 AI 战略（或技术战略）和你的发展方向完全背道而驰，而且这个局面不会改变
你已经有超过一年没有在工作里产出任何让你觉得自豪的东西
你的薪资增速明显低于市场，而你已经尝试内部谈判，没有结果

不应该因为这些原因换工作：

某个项目让你很烦——项目有起伏，一个烂项目不代表公司整体方向不对
某个同事让你很烦——人际摩擦在哪里都有，换公司不一定解决
只是因为听说别的公司薪资高——薪资固然重要，但换到一个技术氛围差的高薪岗位，长期来说并不合算
觉得"待太久了该换换了"——换工作是有成本的，一个让你持续成长的环境，没有必要因为待了几年就离开

构建属于自己的学习体系

在讲完维持热情的策略之后，我想再深入一层：维持热情的本质，是建立一套能让自己持续学习的系统，而不是靠意志力硬撑。

选题输入系统

学习的前提是知道"学什么"。我现在的信息输入体系是这样的：

RSS 订阅：订阅十几个高质量的技术博客（Lilian Weng、Simon Willison 等），每周固定阅读，不是刷信息流而是主动消化
Paper 追踪：用 Semantic Scholar 的邮件订阅，追踪几个核心关键词（RAG、LLM evaluation、agent），每周有新论文摘要
工作观察：在工作里主动记录"让我困惑超过 5 分钟的问题"，这些问题就是学习选题的来源

这三个来源加在一起，每周能给我提供 5-10 个值得深入的方向，我从里面挑 1-2 个真正感兴趣的，投入时间研究。

实践转化系统

光看不做，热情会快速消散。我对自己的要求是：每读完一篇论文或者学完一个新概念，必须写一段代码验证它。

不需要写完整的项目，100 行能验证核心想法的代码就够。写代码的过程，会暴露理解上的盲点，也会让"知道"变成"真的会了"。

# 我用来快速实验新想法的模板代码结构
# 简单但够用

import os
from typing import Any

def experiment(config: dict) -> Any:
    """
    每次学到新东西，用这个模板快速跑一个实验
    config 里放实验参数，方便对比不同配置
    """
    # 1. 初始化
    setup = config.get('setup', {})
    
    # 2. 运行核心逻辑
    result = run_core_logic(setup)
    
    # 3. 记录结果
    log_result(config, result)
    
    return result

def run_core_logic(setup: dict) -> Any:
    # 这里放你要验证的核心代码
    pass

def log_result(config: dict, result: Any) -> None:
    """把实验配置和结果记录下来，方便后续比较"""
    import json
    from datetime import datetime
    
    log = {
        "timestamp": datetime.now().isoformat(),
        "config": config,
        "result": str(result)  # 简单序列化
    }
    
    with open("experiment_log.jsonl", "a") as f:
        f.write(json.dumps(log, ensure_ascii=False) + "\n")

输出反馈系统

输出（写文章、做分享）不只是给别人的，也是给自己的——它是一个强制检验理解深度的机制。

如果你学了一个东西，写出来的文章让别人看不懂，或者写的过程中发现自己讲不清楚，说明你还没真正懂。这个反馈比自我感觉"懂了"更可靠。

写出来，还有一个额外的好处：它会吸引有共同兴趣的人来和你讨论，这些讨论会把你的理解推得更深。

这三个系统——输入、实践、输出——形成一个闭环。进入这个闭环之后，学习会有自驱力，不需要每天给自己打鸡血。

一件可以现在就做的事

热情的维持，不是等到"有了时间"再做。那个"有了时间"的时刻不会来。

如果你现在感觉热情在流失，今天可以做一件具体的事：把你最近遇到的一个有意思的技术问题，用 500 字写下来。 不需要解决方案，只是把问题描述清楚，把你的困惑写清楚。

这个简单的动作，会帮你重新激活对问题的好奇心。

我自己在状态不好的时候，会这样强迫自己：打开一个空文档，把今天工作里遇到的任何一件让我想了超过 5 分钟的事写下来。大多数时候，写下来的过程，就会触发新的想法，就会有想继续探索的冲动。

好奇心是热情的燃料。把它点燃的方式，是让自己主动接触不确定性，而不是等它自己燃起来。