1. 从“andrej-karpathy-skills”这个标题说起：它到底在指什么
第一次看到“andrej-karpathy-skills”这个标题，很多人会愣一下。它不像一个具体的项目名，也不像某个库或框架的正式命名，更像是一个标签、一个合集、或者一份能力清单。我个人的理解是：它指向的是一类以Andrej Karpathy公开分享的内容为线索，去梳理和提炼“一个真正能打的AI工程从业者应该具备哪些技能”的知识整理项目。换句话说，标题本身不是重点，重点是它背后代表的那套能力体系。
Andrej Karpathy在AI圈子里是个绕不开的名字。他做过计算机视觉、深度学习框架、自动驾驶感知、大模型训练，还长期在公开场合做教学式分享。他的内容有个很鲜明的特点：不堆公式，不炫术语，而是把复杂系统拆成能动手复现的模块。所以当有人用“skills”来命名和他相关的内容时，我第一反应是：这不是在讲某个具体技术，而是在讲一套“从零到能干活”的能力地图。
这类内容适合谁？我认为有三类人最该关注。第一类是刚入门的AI学习者，学了一堆课程但不知道下一步该练什么；第二类是有一定基础但工程能力偏弱的算法同学，模型能跑通，但一到数据管道、训练稳定性、部署推理就卡壳；第三类是跨领域转过来的工程师，代码能力不差，但对AI项目的完整生命周期缺乏体感。这三类人的共同痛点是：知识碎片化，不知道哪些技能是真正重要的，哪些只是看起来重要。
我见过太多人把时间花在追新模型、追新框架上，结果连一个完整的数据集清洗流程都写不扎实。也见过有人能把Transformer的公式推得明明白白，但让他写一个带缓存、带断点续训、带日志监控的训练脚本，就无从下手。这就是“skills”这个词的价值所在——它提醒我们，AI工程不是单点知识，而是一组相互咬合的能力。
所以这篇内容，我不打算去复述某个具体教程，而是围绕这个标题所指向的能力体系，结合我自己在多个AI项目中的实操经验，把“一个合格的AI工程从业者到底该练哪些技能、怎么练、练到什么程度算过关”这件事讲透。关键词会自然融入，包括模型训练、数据处理、工程化、调试、部署、实验管理这些核心环节。无论你是刚起步还是已经做过几个项目，都能从中找到可以立刻上手练的东西。
2. 技能地图的第一层：数据与实验基础设施
2.1 为什么数据管道能力比模型调参更值得先练
很多人入门AI的第一反应是去学模型结构，去看论文，去复现SOTA。但我在实际项目里观察到的一个规律是：一个项目能不能成，八成取决于数据，一成取决于模型选型，剩下一成取决于调参和运气。这个比例可能因任务而异，但数据的重要性怎么强调都不过分。
Andrej Karpathy在多次分享中都提到过类似的观点：他在实际工作中花在数据上的时间远超花在模型上的时间。这不是因为他不会调模型，而是因为数据决定了模型的上限。你用一个有标签噪声、分布偏移、类别不平衡的数据集去训一个再先进的模型，结果也不会好。反过来，一个干净、覆盖充分、标注一致的数据集，哪怕用相对简单的模型，也能拿到可用的结果。
所以第一层技能，我建议从数据管道开始练。具体包括：原始数据的读取与解析、缺失值和异常值的处理、类别不平衡的应对、训练集验证集测试集的划分策略、数据增强的合理使用、以及数据版本管理。这些听起来不酷，但它们是地基。
我自己的做法是，每接一个新任务，先不碰模型，而是花一两天写一个数据探查脚本。这个脚本要能回答几个问题：每个类别的样本量是多少？有没有重复样本？标签分布是否合理？图像或文本的长度分布如何？有没有明显的脏数据？这个脚本我会反复用，后来干脆整理成一个模板，换数据集时只改路径和字段名。
提示：数据探查脚本不要写成一次性的。把它当成项目资产来维护，每次换数据集都能复用，长期看节省的时间非常可观。
2.2 实验管理：别让“上次那个结果”变成玄学
第二个容易被忽视的基础设施是实验管理。我见过太多人做实验的方式是：改一版代码，跑一次，看眼结果，再改一版，跑一次。跑了几十次之后，问他哪一版最好，他只能凭记忆说“好像第三版不错”。这是灾难性的工作方式。
实验管理要解决的核心问题是：每一次实验的配置、代码版本、数据版本、输出指标、模型权重，都要能被追溯和复现。工具层面，轻量级可以用配置文件加日志目录的约定，重量级可以用专门的实验跟踪工具。但工具不是关键，关键是习惯。
我的习惯是：每个实验一个独立目录，目录名包含日期和简短描述；目录里必须有config文件、训练日志、评估结果、以及最终模型权重；config文件里记录所有超参数和数据路径；训练日志里记录每个epoch的loss和指标。这样一周后回头看，我能清楚知道每个实验做了什么，哪个值得继续。
这个习惯看起来笨，但它带来的复现能力是巨大的。当你需要向别人解释“为什么选这个方案”时，你能拿出完整的证据链，而不是一句“我试过，这个好”。
2.3 版本控制不只是代码，还包括数据和模型
版本控制这块，代码用Git是常识。但数据和模型的版本控制，很多人就忽略了。数据变了，模型结果就变了，如果你不记录数据版本，实验就无法复现。模型权重也一样，训了十几个checkpoint，最后用哪个，得有记录。
我的做法是：数据用哈希值或版本号标记，在config里引用；模型权重按实验目录存放，命名包含epoch和指标；如果团队协作，用一个共享的存储位置加清单文件来管理。不需要一开始就上很重的工具，但要有这个意识。
这一层技能练到什么程度算过关？我的标准是：给你一个全新的数据集和一个空项目目录，你能在半天内搭出一个可复用的数据加载和实验管理骨架，并且这个骨架能支撑后续至少二十次实验而不混乱。达到这个标准，你就已经超过很多只会调模型的人了。
3. 技能地图的第二层：模型训练与调试的硬功夫
3.1 从“能跑通”到“能训好”之间隔着什么
让一个模型跑通，和让一个模型训好，是两件完全不同的事。跑通只需要代码没bug、维度对得上、损失能下降。训好则需要你理解训练动力学：学习率怎么设、batch size怎么选、正则化怎么加、什么时候该早停、梯度爆炸或消失怎么判断和处理。
我见过不少项目，代码跑通了，loss也在降，但最终指标就是上不去。这时候问题往往不在模型结构，而在训练细节。比如学习率太大导致在最优解附近震荡，或者太小导致收敛太慢；比如batch size和learning rate没有协同调整；比如没有用warmup导致训练初期不稳定；比如数据增强太激进导致训练分布和测试分布差距过大。
这些细节，Andrej Karpathy在教学中经常用很直观的方式讲。比如他把训练比作下山，学习率就是步长，步长太大容易跨过山谷，步长太小走到天黑还没到底。这个类比虽然简化，但抓住了核心。
我的经验是，训练调试要养成“先小后大”的习惯。先用一个小数据集、小模型、少epoch跑通全流程，确认没有低级错误，再逐步放大。很多人一上来就用全量数据和最大模型，结果一个bug要等几小时才能发现，效率极低。
3.2 损失曲线会说话，但你要会听
损失曲线是训练过程中最重要的诊断工具。但很多人只看最终值，不看形状。实际上，曲线的形状能告诉你很多信息。
训练loss下降但验证loss上升，这是过拟合的典型信号，需要考虑加正则化、加数据、或者减小模型。训练loss和验证loss都下降但很慢，可能是学习率偏小或者模型容量不足。训练loss震荡剧烈，可能是学习率偏大或者batch size偏小。训练loss突然变成NaN，可能是梯度爆炸或者数值不稳定。
我习惯在训练脚本里加一个自动记录和绘制曲线的模块，每个epoch结束就更新图。这样不用等训练结束就能判断趋势。如果发现异常，可以及时中断调整，而不是浪费几个小时。
还有一个细节：验证集的选择。验证集要能代表测试集的分布，否则你根据验证集做的所有决策都可能过拟合到验证集上。我通常会从训练数据里划出一部分做验证，同时保留一个完全不碰的测试集，只在最后评估时用一次。
3.3 超参数搜索：别把它变成碰运气
超参数搜索是很多人头疼的环节。网格搜索太慢，随机搜索靠运气，贝叶斯优化又需要额外工具。我的建议是：先用手动加经验缩小范围，再用自动化工具精调。
具体来说，先根据任务类型和模型规模，确定学习率、batch size、权重衰减这几个关键参数的大致范围。比如Transformer类模型，学习率通常在1e-4到1e-3之间，batch size根据显存尽量大。然后在这个范围内做几次手动实验，观察趋势。最后如果还需要精调，再用自动化工具在缩小后的范围里搜索。
这里有个经验：不要同时调太多参数。一次只调一两个，固定其他，否则你无法判断是哪个参数起了作用。我见过有人一次改五个参数，结果好了不知道为啥好，坏了不知道为啥坏，这种实验没有积累价值。
3.4 梯度问题：看不见但致命
梯度相关的bug是最难查的，因为它们往往不报错，只是让训练效果变差。梯度爆炸表现为loss突然变大或变NaN，梯度消失表现为loss几乎不降。判断方法很简单：在训练循环里加一行代码，打印梯度的范数。如果范数持续增大，就是爆炸；如果范数接近零，就是消失。
应对梯度爆炸，常用方法是梯度裁剪，把梯度的范数限制在一个阈值内。应对梯度消失，可以检查激活函数是否合适、是否用了残差连接、归一化层是否到位。这些手段在主流模型里都有标准做法，但你要知道它们为什么存在，才能在出问题时想到去用。
我自己的检查清单是：新模型第一次训练时，一定打印梯度范数、激活值分布、以及每层输出的均值和方差。这三个指标能覆盖大部分数值稳定性问题。确认正常后，再关掉这些打印，进入正式训练。
4. 技能地图的第三层：从训练到部署的工程化能力
4.1 模型导出与推理优化：训练好只是开始
模型训练完，指标好看，这只是完成了前半程。后半程是把它变成能对外提供服务的东西。这里的第一步是模型导出。不同框架有不同的导出格式，导出时要注意算子兼容性、输入输出形状、以及是否包含后处理逻辑。
导出之后是推理优化。训练时我们关心的是梯度、显存、收敛速度；推理时关心的是延迟、吞吐、内存占用。这两个目标经常冲突。比如训练时用大batch提高效率，推理时可能batch=1才能满足延迟要求。训练时用float32保证精度，推理时可能要用float16或int8来加速。
我的做法是：先跑通一个最朴素的推理版本，测出基线延迟和吞吐，然后逐步优化。优化手段包括：算子融合、量化、剪枝、以及使用专门的推理引擎。每做一步优化，都要重新测指标，确认精度下降在可接受范围内。
这里有个坑：训练时的预处理和后处理逻辑，在推理时容易漏掉或写错。比如图像归一化的均值方差、文本tokenizer的配置、输出解码的方式。这些细节不一致，会导致推理结果和评估结果对不上。我的习惯是把预处理和后处理写成独立模块，训练和推理共用同一份代码，避免不一致。
4.2 服务化：让模型真正被用起来
模型导出并优化后，下一步是服务化。最简单的做法是写一个HTTP接口，接收请求，调用模型，返回结果。但生产环境要考虑的更多：并发请求怎么处理、超时怎么设置、错误怎么返回、日志怎么记录、监控怎么做。
我通常会用一个轻量级的Web框架搭服务，模型加载在启动时完成，请求处理时只做推理。并发方面，如果模型不大，可以用多线程；如果模型大，可能需要多进程或者专门的推理服务框架。超时和错误处理要明确，不能让一个坏请求拖垮整个服务。
监控是容易被忽略的。至少要记录：请求量、延迟分布、错误率、以及模型输出的基本统计。这些数据能帮你在出问题时快速定位。比如延迟突然升高，可能是某个请求的输入特别大，也可能是资源被其他进程占了。
4.3 持续迭代：部署不是终点
模型上线后，工作并没有结束。真实世界的数据分布会变化，用户行为会变化，模型效果会衰减。所以需要持续监控和迭代。
我的做法是：上线时留一个小的流量做影子模式，新模型和旧模型同时跑，对比结果。确认新模型不差后，再逐步切流量。同时收集线上数据，定期和训练数据对比，看分布有没有偏移。如果偏移明显，就需要重新训练。
重新训练不是简单地把新数据加进去再跑一遍。要考虑：新数据的标注质量、类别分布是否变化、是否需要调整采样策略、以及旧模型的知识是否需要保留。这些都需要实验来验证。
这一层技能练到什么程度算过关？我的标准是：你能独立把一个训练好的模型，从导出、优化、服务化到上线监控，完整走一遍，并且能处理过程中出现的常见问题。达到这个标准，你就具备了AI工程的核心竞争力。
5. 那些没人明说但很重要的软技能
5.1 读代码和读论文是两种不同的能力
AI领域信息更新快，读论文是必备技能。但很多人忽略了读代码的能力。论文告诉你思路，代码告诉你实现细节。很多论文里的技巧，在代码里才有完整的体现。
我读代码的习惯是：先跑通，再打断点，看数据怎么流动。不要一上来就逐行读，那样容易迷失。先看入口，看主流程，看关键模块的输入输出，然后再深入细节。遇到不懂的地方，打印中间结果，用实际数据来理解。
Andrej Karpathy的代码有个特点：结构清晰，注释到位，适合学习。我建议初学者找几个他的小项目，从头到尾读一遍，自己复现一遍。这个过程比看十篇论文都有用。
5.2 写文档和写博客：输出倒逼输入
我有个习惯：每做完一个项目，写一份内部文档，记录做了什么、为什么这么做、遇到了什么问题、怎么解决的。这份文档不一定要给别人看，但写的过程能帮我理清思路。
更进一步，可以把一些通用性的经验写成博客。写博客的好处是，你会被迫把模糊的理解变得清晰。如果你讲不清楚一个概念，说明你还没真正理解它。而且写出来的东西，过段时间回头看，能发现自己当时的认知局限。
5.3 时间管理和优先级：AI项目最容易失控的地方
AI项目有个特点：不确定性高。你不知道一个想法能不能work，不知道要调多久，不知道数据够不够。这种不确定性容易导致时间失控。
我的应对方法是：把大目标拆成小里程碑，每个里程碑有明确的验收标准和时间盒。比如“本周完成数据管道搭建，能跑通一个baseline”，而不是“本周把模型训好”。时间盒到了，如果没完成，就评估是继续还是调整方向。这样能避免在一个方向上无限投入。
另外，要接受“大部分实验会失败”这个事实。我自己的经验是，十个想法里能有一个work就不错了。所以不要对单个实验抱太大期望，快速试错，快速迭代。
6. 怎么用这份技能地图规划自己的学习路径
6.1 不同起点的切入方式
如果你是完全新手，我建议从数据管道和实验管理开始。先找一个简单的公开数据集，写一个完整的数据加载和预处理流程，再搭一个最小的训练脚本，跑通一个简单模型。这个过程中你会遇到各种环境问题、路径问题、维度问题，解决它们就是最好的入门。
如果你有一定基础但工程能力弱，我建议从训练调试和模型部署入手。找一个你之前训过的模型，重新审视训练过程，看损失曲线，调学习率，加正则化，观察变化。然后把模型导出，写一个简单的推理服务，测延迟和吞吐。这个过程能帮你补上工程化的短板。
如果你是跨领域转过来的，代码能力不差，我建议直接从完整项目入手。选一个你感兴趣的任务，从数据到部署走一遍。不要追求SOTA，追求完整。完整走一遍之后，你对AI工程的理解会完全不同。
6.2 练习项目的选择标准
练习项目不要选太难的，也不要选太简单的。太难的会让你卡在数据或算力上，太简单的学不到东西。我的标准是：数据能拿到、算力能支撑、任务有明确的评估指标、并且和你目标方向相关。
比如你想做计算机视觉，可以从图像分类开始，用一个小型数据集，训一个中等规模的模型，走完整个流程。然后逐步增加难度：换更大的数据集、试不同的模型、加数据增强、做模型集成、最后部署。
每个项目结束后，写一份复盘：哪些做得好、哪些可以改进、下次遇到类似问题怎么处理。这份复盘是你自己的经验库，比任何教程都珍贵。
6.3 避免的常见误区
第一个误区是“收藏即学会”。看到好文章、好课程、好项目，收藏了就觉得学到了。实际上，不动手，收藏再多也没用。我的建议是，看到有用的东西，立刻找一个最小可执行的例子跑一遍，哪怕只是跑通一个函数。
第二个误区是“追求最新”。AI领域每天都有新东西，但基础的东西变化很慢。数据管道、训练调试、部署监控这些技能，五年前和现在核心逻辑没变。把基础打牢，新东西学起来很快。
第三个误区是“单打独斗”。AI项目涉及的东西太多，一个人很难全精通。找到可以交流的人，分享你的问题，也帮别人解决问题。很多时候，别人的一句话能省你几天时间。
6.4 一个可执行的九十天计划
如果你想把这份技能地图落地，我给你一个九十天的参考计划。第一个月，专注数据和实验管理，完成一个完整的数据管道和实验框架，跑通至少五个实验并做好记录。第二个月，专注训练调试，针对一个任务，系统性地调学习率、batch size、正则化，记录每次变化的影响，找到最优配置。第三个月，专注部署，把第二个月训好的模型导出、优化、服务化，写一个简单的客户端调用，测延迟和吞吐，并做一次完整的复盘。
这个计划不轻松，但走完一遍，你对AI工程的理解会从“知道”变成“做过”。而“做过”这件事，在AI领域里，比什么都重要。
我在实际带人的过程中发现，那些成长最快的人，不是最聪明的，而是最愿意动手、最愿意记录、最愿意复盘的人。技能地图只是地图，路要自己走。希望这份梳理能帮你少走一些弯路，把时间花在真正重要的能力上。
