不要为了积累知识而阅读。要为了解决问题而阅读。
大多数工程阅读清单都侧重于知识积累。而现代工程奖励的是解决瓶颈的能力。
最近，一位初级工程师向我展示了一份“工程师必读的 10 本书”清单。它看起来和十年前的清单没什么两样，依然基于那个陈旧的假设。
这个假设认为，读过足够多的书就能让你成为一名更好的工程师。但高绩效团队并不是这样学习的。
最优秀的工程师会围绕“约束条件”来制定学习计划。
标准的阅读清单假设所有知识都有价值。但实际上，工程价值取决于具体的上下文（context）。
• 面临数据库问题的后端工程师不需要一本关于敏捷开发（Agile）的书。 • 在 AI 推理（inference）上花费过高的团队不需要一本泛泛而谈的工艺手册。 • 面临延迟问题的初创公司不需要领导力框架。
这些人需要的是针对眼前特定瓶颈的解决方案。阅读清单追求的是完整性，而工程奖励的是相关性。
数据库和网络等基础知识仍然重要。但仅靠这些已经不够了。
现代系统带来了新的约束。AI 推理成本就是一个典型的例子。传统的清单很少涵盖这些问题。
挑战不再仅仅是编写正确的软件，而是如何在概率性组件（probabilistic components）之上构建可靠的系统。
过去，工程师处理的是确定性系统（deterministic systems）。相同的输入会产生相同的输出。
如今，系统的行为变得不同了。一个提示词（prompt）可能会给出不同的响应；一个智能体（agent）可能会采取不同的路径；模型升级可能会在你不改动代码的情况下改变行为。
新的问题在于： • 你如何评估质量？ • 你如何应对这些变化？
这些不是极端情况（edge cases），而是日常的工程任务。
优秀的工程师不会从头到尾地阅读。他们是为了理解“机制”而阅读。他们发现瓶颈，识别机制，然后只学习他们需要的部分。
• 如果延迟很高，研究批处理（batching）。 • 如果上下文（context）有问题，研究检索（retrieval）。 • 如果智能体（agents）失效，研究评估（evaluation）。
这将学习与生产直接联系起来。知识由此成为了杠杆。
使用这个学习循环：
- 识别瓶颈。
- 寻找针对该问题的特定资源。
- 应用解决方案。
停止试图读完一份阅读清单。开始尝试改进系统。
在读下一本书之前，先问问自己：我系统中最大的约束是什么？
是延迟、成本、可靠性，还是可观测性？
去寻找能攻克该瓶颈的资源。工程学不是一场阅读比赛，而是一门解决约束问题的专业。
系统决定了你下一步该学什么。