最近在和几个朋友聊AI辅助研发的时候发现一个很有意思的现象大家手里都囤了不少大模型的代码片段但真到自己写项目的时候还是习惯性让模型“帮我写个XX”而不是“按某个特定思路把XX拆开来做”。这让我想起GitHub上那个叫andrej-karpathy-skills的项目名——它最早吸引我的不是代码量而是这个名字背后藏着的逻辑与其零散收藏Karpathy的教程和代码不如把他做事的思路、拆解问题的方式、验证结论的习惯沉淀成一套可以被AI代理直接调用的“技能”。这篇内容我想认真聊一聊这个项目到底在解决什么问题Karpathy风格的技术能力有哪些可以抽象成“技能”以及我实际把这套思路落到AI工作流里之后的体验。适合正在做LLM应用、经常让AI写代码但总觉得差口气的人也适合想把“高手思路”变成“团队可复用资产”的开发者参考。1. 为什么“技能化”比“代码化”更能留住Karpathy的价值我先交代一个背景。之前有段时间我需要快速给团队做内部培训讲Transformer和反向传播手头素材一大把但真正用的时候发现全是零散的笔记、幻灯片、代码仓没有一个现成的东西能“带着人从头到尾把模型训练一遍”。后来我注意到andrej-karpathy-skills这个项目名才意识到问题不在于内容不够多而在于内容没有按“技能”的方式组织。1.1 照抄代码只抄到了“形”没抄到“神”很多人看Karpathy的nanoGPT第一反应是“哦这就是个极简GPT实现”然后复制下来跑个demo就完了。但如果你只是照搬代码你得到的是一个静态结果丢掉的却是他做这个项目时的核心思路怎么切分数据、怎么控制训练曲线、怎么用小规模实验验证大模型的缩放规律。代码是“形”思路是“神”。把代码收进收藏夹等于你拿到了题目的答案却没有拿到解题方法。而技能化要做的事情恰恰是把“解题方法”本身结构化给定目标、约束条件、可用的工具然后一步步推导出方案。这正是Karpathy课程里反复出现的模式。1.2 技能的粒度Karpathy的教学单元天然适合拆成技能Karpathy的zero-to-hero系列每一集都聚焦一个问题域micrograd讲自动微分makemore讲字符级语言模型nanoGPT讲真正的GPT训练。每个主题的颗粒度其实非常适合作为AI代理的“技能包”——它有明确的输入比如“给我一批文本数据”、明确的动作分词、建词表、训练、明确的产出loss曲线的下降、采样文本的输出。这和我平时写AI助手的系统提示词完全不一样。系统提示词往往是“你是一个有用的助手请用专业的方式回答”而技能包更像是一份SOP标准作业程序把“做什么、怎么做、做到什么程度算完成”全都写清楚。Karpathy的东西天然具备这种SOP气质因为他在教学的时候就会刻意地把每一步拆开、说明为什么、然后验证。1.3 先明确这里的“Skills”到底是什么边界需要说明一下我这里讨论的“Skills”不是指某个特定平台的私有格式而是更通用的定义一段结构化的描述文件里面包含了触发条件、执行步骤、验证标准、可能出错的点AI代理在需要的时候可以把它加载进来按里面的流程去工作。andrej-karpathy-skills这个项目给我的启发点就在这里不需要把Karpathy所有东西都塞进一个上下文窗口而是把每个具体能力做成独立文件用到哪个加载哪个。这样做的好处非常实际——上下文更短、错误率更低、每个技能本身可以被单独测试和迭代。2. 深挖技能内核Karpathy工程思维的四块基石如果要给Karpathy式的“技能”画一个能力图谱我不会按课程名去分而是按思维模式去分。因为值得沉淀的不是某个具体模型而是他在面对一个复杂系统时反复使用的分析框架。下面这四块是我认为最核心的。2.1 micrograd自动微分不该是魔法而是几百行代码Karpathy的micrograd只用了大概200行代码就实现了反向传播。很多人觉得这只是个教学玩具但如果你真的把它当成一个“技能”来用价值会完全不一样。它教给你的是不要相信任何“这步由框架自动完成”的黑盒。在实际工程里我遇到过好几次模型loss不降的情况用PyTorch的自动求导根本看不出问题在哪最后是手动把梯度算了一遍才发现是某个op的实现细节不对。这种排查能力恰恰是micrograd训练出来的。把micrograd做成技能我会这样定义目标是让学生/代理能徒手实现一个可用的反向传播步骤是先建立计算图再写前向再写反向验证标准是梯度数值和有限差分法的估计误差小于1e-5。这个标准不是Karpathy在代码里写的但完全符合他的教学风格——数值验证永远比口头解释更有说服力。2.2 minbpeTokenizer里藏着模型能力的边界Karpathy的minbpe项目专门讲BPE分词算法。为什么这个词很重要因为很多LLM应用出现“模型不听话”的情况根因根本不在模型而在分词器。中文字没有空格边界如果tokenizer切出来的词元是碎的后续所有任务都会带病运行。把minbpe作为技能沉淀下来核心不只是实现算法而是建立一种检查习惯拿到语料先做tokenization分析看看词元长度的分布、未登录词的比例、跨语言的切分效果。这些步骤看起来不起眼却决定了模型训练的上限。我在团队里把这套逻辑写成了一个练习清单给定一个语料库先训练一个小的BPE分词器然后手动检查分出来的top50词元是否合理再对比不同词表大小下的编码长度。这个过程做下来你才会理解为什么Karpathy说“分词是语言模型最容易忽略的细节”。2.3 nanoGPT用最小可复现模型理解训练全流程如果说前两个技能还停留在“算法随笔”的层面那nanoGPT就是一个完整的工程项目。它麻雀虽小五脏俱全包含了数据加载、模型定义、训练循环、采样生成、checkpoint保存等一整套流程。真正值得提取成技能的点有两个。第一是可以快速验证想法比如改一个注意力窗口设置、调一下dropout在小数据集上几秒钟就能看到效果第二是训练状态诊断Karpathy在视频里反复强调看loss曲线、看生成文本质量而不是只看精度。我在复现nanoGPT的时候把“训练一个小模型并排查问题”的完整SOP记录了下来先确认数据分配合不合理再检查初始化是否正常然后看梯度范数是否异常最后才是调学习率。这套SOP现在被我直接写进了AI辅助编程的技能库里模型训练类问题都走这条链路比让AI自由发挥稳定得多。2.4 从反向传播到“先让错误足够小”的调试哲学这第四块不是具体的项目而是贯穿Karpathy所有内容里的一种调试哲学先构建一个最小闭环然后让每一层、每个模块的错误都足够小再去验证整个系统的行为。比如训练一个语言模型他会先做一个几十万参数的版本在tiny shakespeare数据上跑确认loss能降、能采样出像样的文本然后才谈扩大规模。这个“先跑通、再加量”的习惯放到任何工程场景都是通用的。把它作为技能来沉淀我会抽象成这样的流程定义最小任务规模搭建最小模型跑通端到端链路记录基线结果逐步增加数据或参数。这五个步骤看起来平平无奇但绝大部分失败的AI辅助编程任务问题都出在一开始就试图一步到位没有先建立一个“足够小的错误系统”。3. 把Karpathy式技能落到AI代理工作流的实操方法理论说得再多不如动手试试。下面这部分是我实际把andrej-karpathy-skills的理念落地到AI协作工作流中的做法。我选了一个真实场景用AI辅助来实现一个微型语言模型的训练和评估并在过程中反复调用Karpathy式的技能文件。3.1 技能文件怎么写目标、上下文、动作、验收标准先说说我用的技能文件结构我参考了不少公开的技能格式结合自己的使用习惯做了简化核心字段就四个name技能的短名称比如train-llm-miniwhen_to_use触发条件什么情况下代理应该加载这个技能steps具体操作步骤尽量写成可检查的动作done验收标准什么时候算任务完成拿train-llm-mini举例触发条件是我需要训练一个小规模语言模型并观察其行为步骤包含数据预处理、构造词表、初始化模型、训练、采样验收标准是训练loss显著下降且生成结果有基本语法结构。为什么不写太长因为AI代理的上下文窗口是有限的超过一定长度之后注意力分布会变得很散反而不利于执行。把技能写短、写准比写全更有用。3.2 一份实际技能拆解示例从数据准备到模型采样我直接贴出这个技能文件的核心内容简化版各位可以感受一下结构# train-llm-mini ## when_to_use 用户要求训练一个从零开始的语言模型或需要排查语言模型训练过程中的不收敛、过拟合、生成质量差等问题。 ## steps 1. 检查数据集统计总字符数、去重后的字符种类、平均句子长度确认数据非空。 2. 构建词表默认按字符级切分标注特殊tokens如果数据集超过5万条考虑BPE。 3. 设置模型参数n_layer/ n_head/ n_embd 优先使用128/4/64这种量级。 4. 初始化模型打印参数量确认与预期规模一致。 5. 配置训练batch_size32, max_iters2000, learning_rate1e-3。 6. 训练并记录loss每500步打印一次loss和采样结果。 7. 诊断与修复如果loss不降先检查数据预处理如果loss出现NaN检查学习率和初始化如果生成重复加大采样温度。 ## done - 训练结束后loss低于1.5在tiny shakespeare数据集上 - 采样生成的文本包含合理的词频统计特征 - 如果任务目标是复现实验需记录所有超参数和最终结果这一段看着简单实际操作的时候价值很大。之前我让AI帮我训练模型它经常是丢给你一段代码就跑完全不解释哪一步需要人工确认。有了这个技能文件AI的每一步都会主动停下来检查数据集规不规范、模型初始化对不对、loss有没有明显下降趋势。等于把Karpathy在课程里的“边做边验证”风格抽了出来。3.3 对比实测有技能和没技能的差异为了验证这套思路有效我做了个非严格但很有意思的对比实验。同样一个任务“帮我用PyTorch训练一个字符级GPT并在小数据集上看看效果”。没有技能文件时AI助手给出的方案往往是一个相对标准的代码结构但它不会主动判断数据规模、不会提醒我注意学习率对收敛的影响直接给完代码就结束了。如果中间出了错我再人工反馈一轮它才继续修。有技能文件时AI会先检查输入数据再按步骤执行每跑完一步都会汇报中间结果最后还会根据loss曲线给出诊断结论。整个过程的可靠性明显更高因为技能文件实际上给AI装了一个“检查清单”。这个差异其实很好解释单轮对话里AI是在自由发挥而技能文件给它提供了领域专家的工作框架。Karpathy的视频里有一句话很贴切不要直接跳到复杂的实现先把最简单的路径走通。技能文件本质就是把这句话工程化。4. 复现Karpathy式技能的完整路径我调通一个小模型的排错记录前面聊了设计思路这节讲一次具体的排错过程。我在复现一个Karpathy风格的最小语言模型时遇到了loss不降的问题。整个过程走下来正好可以说明技能化思维在真实调试里有多重要。4.1 环境准备里最容易忽略的细节我本地的环境是Python 3.11 PyTorch 2.1机器是MacBook Pro M1没有GPU纯CPU训练。按技能文件的步骤数据用的是tiny shakespeare大概1MB的文本。环境准备看着简单其实有个坑M1上PyTorch的MPS后端在部分版本里处理某些op会有精度问题。我第一轮训练时特意做了设备判断如果有MPS就用MPS结果loss曲线出现锯齿抖动。后来我按技能文件里的“如果loss异常检查设备和精度”这一条果断切回CPU抖动立刻消失。这里想提一句Karpathy的代码本身不考虑MPS他默认就是CPU训练。这种“保守选择”在复现阶段反而是最稳妥的因为你是在验证逻辑不是在挤性能。4.2 超参数设置背后的计算逻辑技能文件里建议的是n_embd64, n_head4, n_layer2总参数量大概几十万。很多人会嫌小但这里的计算逻辑是tiny shakespeare的字符集不到100个语义结构并不复杂一个几十万参数的小模型完全有能力拟合它这时候重点是观察训练动态是否正常而不是追求更低loss。我按这个参数跑初始loss大约在4.3左右训练到2000步时降到1.2左右。这个数值范围是合理的说明模型确实学到了统计规律。如果你一上来就用大模型参数比如n_embd768在CPU上可能要跑几小时中途一旦有bug排查成本极高。4.3 一次“loss不降”的完整排查链路事情发生在数据集换成中文语料之后。我手头有一份古诗词数据集大概5万首想看看字符级GPT能不能生成像样的诗句。结果训练到1000步左右loss停在6.2不降了。按照技能文件里的诊断顺序我先检查数据预处理。发现一个问题古诗词里有大量的标点符号和生僻字字符种类多达3000多个。每个字符在softmax里的预测难度完全不一样生僻字的概率权重被稀释导致loss整体偏高。接着我检查了模型初始化。固定随机种子后重新训练loss曲线依然是平的排除初始化问题。最后定位到问题在学习率。技能文件里默认learning_rate1e-3但当我换成3e-4之后loss从6.2降到了5.5左右。原因很简单字符种类变多后梯度分布变稀太大的学习率导致优化过程在高原区来回震荡降不下去。这个排查链路看起来不复杂但它体现的恰恰是技能文件的魅力每一步都对应一个可验证的动作。没有技能文件时我大概率会来回瞎试有了技能文件我只需要按顺序把“数据、初始化、学习率”逐个排除。4.4 修复之后的效果验证修复后的模型在古诗词数据集上跑完3000步loss降到4.8左右。生成的文本虽然语义不通但至少在字符分布上已经接近古诗词的用字习惯比如“山”“水”“风”“月”这些字的出现频率明显变高句式结构也基本稳定在五言或七言。我没有继续调参追求更低的loss因为这里的任务是验证技能文件的可靠性而不是训练一个能写诗的模型。这个过程跑下来我最大的感受是技能化让调试从“碰运气”变成了“走流程”。5. 构建自己的Karpathy式技能包几条真实踩坑经验最后一个部分我想分享几点从零构建技能包的过程中攒下来的经验主要给打算自己动手做类似事情的人参考。5.1 技能不是Prompt模板它必须有验收标准最开始我犯过一个错误把技能文件写得像系统提示词通篇都是“你要考虑”“你应该注意”这种模糊语言。实际用下来效果很差因为AI代理不知道“注意”到什么程度算到位。后来我把每一条都改成可验证的标准。比如不写“注意学习率”而写“固定随机种子跑200步如果loss下降小于0.3则降低学习率重试”。这个改动效果立竿见影AI代理知道什么情况下算失败也知道失败之后该做什么。验收标准才是技能的灵魂没有验收标准的技能文件只是一个更长版本的走心提示词。5.2 单文件别贪大一个技能只解决一个问题我一开始想做一个“全能训练技能”把数据处理、模型训练、调优、评估全塞进一个文件里结果AI代理加载之后经常遗忘前面的步骤执行到中段就开始偏离。后来我把技能拆开prepare-corpus专门负责数据预处理train-mini-llm专门负责训练diagnose-training专门负责排错。每个文件控制在50行以内职责单一。AI代理在实际执行时可以根据当前情况动态加载需要的技能而不是一口气全塞进来。这个思路跟Karpathy做教学项目是一样的micrograd只讲反向传播makemore只讲语言模型的生成原理nanoGPT讲完整训练。每个项目都不大但组合起来就是一套完整的技能树。5.3 技能文件需要版本管理和持续调试最后一点是工程化层面的。技能文件本质上是代码它有自己的bug也需要持续迭代。我现在的做法是把技能文件放在Git仓库里每次修改都提交commit并且在commit message里写清楚改动原因。我遇到过几次很典型的回归问题某次为了让AI生成更有创意的文本我在技能文件里加了一条“采样时温度设为1.5”结果后续所有生成任务都变得语无伦次因为其他任务也加载了这个技能。后来我限制技能的适用范围在when_to_use里强调“仅适用于创意写作任务”问题才消失。这里也推荐一个习惯每个技能文件旁边放一个examples/目录存几个典型的输入输出例子。AI代理加载技能时可以顺便参考例子输出会稳定很多。我个人感觉这个做法比在描述里反复强调“要专业、要准确”有用得多。5.4 从“收藏知识”到“构建系统”这个转变才是关键最后想聊聊心态层面的事。收藏Karpathy的仓库不难难的是把他的知识组织成一套可以在实际工作中反复使用的系统。技能化的过程其实是对已有知识的一次深度加工你逼着自己想清楚每个技能的目标、触发条件、步骤和验收标准这个思考过程本身就很有价值。我现在的工作流里AI代理并不只是“写代码的工具”更像是一个带着领域SOP的执行者。我负责判断方向和验收结果它负责按经过验证的技能路径执行。这个变化很大程度上来自andrej-karpathy-skills这个项目名的启发把高手的隐性经验变成可复用的显性技能。如果你也想尝试构建自己的技能包我的建议很简单挑一个你最近在反复做的事比如“写README”“做代码Review”“训练小模型”试着把它写成一份包含验收标准的技能文件然后用AI代理跑一遍。第一次可能不完美但迭代几次之后你会发现自己正在把最值钱的做事方法慢慢沉淀下来。 
长河君 · 2026/9/12 6:16:31 · 阅读 1.2k Karpathy技能化实践：把高手思路变成AI代理可复用的技能包
最近在和几个朋友聊AI辅助研发的时候发现一个很有意思的现象大家手里都囤了不少大模型的代码片段但真到自己写项目的时候还是习惯性让模型“帮我写个XX”而不是“按某个特定思路把XX拆开来做”。这让我想起GitHub上那个叫andrej-karpathy-skills的项目名——它最早吸引我的不是代码量而是这个名字背后藏着的逻辑与其零散收藏Karpathy的教程和代码不如把他做事的思路、拆解问题的方式、验证结论的习惯沉淀成一套可以被AI代理直接调用的“技能”。这篇内容我想认真聊一聊这个项目到底在解决什么问题Karpathy风格的技术能力有哪些可以抽象成“技能”以及我实际把这套思路落到AI工作流里之后的体验。适合正在做LLM应用、经常让AI写代码但总觉得差口气的人也适合想把“高手思路”变成“团队可复用资产”的开发者参考。1. 为什么“技能化”比“代码化”更能留住Karpathy的价值我先交代一个背景。之前有段时间我需要快速给团队做内部培训讲Transformer和反向传播手头素材一大把但真正用的时候发现全是零散的笔记、幻灯片、代码仓没有一个现成的东西能“带着人从头到尾把模型训练一遍”。后来我注意到andrej-karpathy-skills这个项目名才意识到问题不在于内容不够多而在于内容没有按“技能”的方式组织。1.1 照抄代码只抄到了“形”没抄到“神”很多人看Karpathy的nanoGPT第一反应是“哦这就是个极简GPT实现”然后复制下来跑个demo就完了。但如果你只是照搬代码你得到的是一个静态结果丢掉的却是他做这个项目时的核心思路怎么切分数据、怎么控制训练曲线、怎么用小规模实验验证大模型的缩放规律。代码是“形”思路是“神”。把代码收进收藏夹等于你拿到了题目的答案却没有拿到解题方法。而技能化要做的事情恰恰是把“解题方法”本身结构化给定目标、约束条件、可用的工具然后一步步推导出方案。这正是Karpathy课程里反复出现的模式。1.2 技能的粒度Karpathy的教学单元天然适合拆成技能Karpathy的zero-to-hero系列每一集都聚焦一个问题域micrograd讲自动微分makemore讲字符级语言模型nanoGPT讲真正的GPT训练。每个主题的颗粒度其实非常适合作为AI代理的“技能包”——它有明确的输入比如“给我一批文本数据”、明确的动作分词、建词表、训练、明确的产出loss曲线的下降、采样文本的输出。这和我平时写AI助手的系统提示词完全不一样。系统提示词往往是“你是一个有用的助手请用专业的方式回答”而技能包更像是一份SOP标准作业程序把“做什么、怎么做、做到什么程度算完成”全都写清楚。Karpathy的东西天然具备这种SOP气质因为他在教学的时候就会刻意地把每一步拆开、说明为什么、然后验证。1.3 先明确这里的“Skills”到底是什么边界需要说明一下我这里讨论的“Skills”不是指某个特定平台的私有格式而是更通用的定义一段结构化的描述文件里面包含了触发条件、执行步骤、验证标准、可能出错的点AI代理在需要的时候可以把它加载进来按里面的流程去工作。andrej-karpathy-skills这个项目给我的启发点就在这里不需要把Karpathy所有东西都塞进一个上下文窗口而是把每个具体能力做成独立文件用到哪个加载哪个。这样做的好处非常实际——上下文更短、错误率更低、每个技能本身可以被单独测试和迭代。2. 深挖技能内核Karpathy工程思维的四块基石如果要给Karpathy式的“技能”画一个能力图谱我不会按课程名去分而是按思维模式去分。因为值得沉淀的不是某个具体模型而是他在面对一个复杂系统时反复使用的分析框架。下面这四块是我认为最核心的。2.1 micrograd自动微分不该是魔法而是几百行代码Karpathy的micrograd只用了大概200行代码就实现了反向传播。很多人觉得这只是个教学玩具但如果你真的把它当成一个“技能”来用价值会完全不一样。它教给你的是不要相信任何“这步由框架自动完成”的黑盒。在实际工程里我遇到过好几次模型loss不降的情况用PyTorch的自动求导根本看不出问题在哪最后是手动把梯度算了一遍才发现是某个op的实现细节不对。这种排查能力恰恰是micrograd训练出来的。把micrograd做成技能我会这样定义目标是让学生/代理能徒手实现一个可用的反向传播步骤是先建立计算图再写前向再写反向验证标准是梯度数值和有限差分法的估计误差小于1e-5。这个标准不是Karpathy在代码里写的但完全符合他的教学风格——数值验证永远比口头解释更有说服力。2.2 minbpeTokenizer里藏着模型能力的边界Karpathy的minbpe项目专门讲BPE分词算法。为什么这个词很重要因为很多LLM应用出现“模型不听话”的情况根因根本不在模型而在分词器。中文字没有空格边界如果tokenizer切出来的词元是碎的后续所有任务都会带病运行。把minbpe作为技能沉淀下来核心不只是实现算法而是建立一种检查习惯拿到语料先做tokenization分析看看词元长度的分布、未登录词的比例、跨语言的切分效果。这些步骤看起来不起眼却决定了模型训练的上限。我在团队里把这套逻辑写成了一个练习清单给定一个语料库先训练一个小的BPE分词器然后手动检查分出来的top50词元是否合理再对比不同词表大小下的编码长度。这个过程做下来你才会理解为什么Karpathy说“分词是语言模型最容易忽略的细节”。2.3 nanoGPT用最小可复现模型理解训练全流程如果说前两个技能还停留在“算法随笔”的层面那nanoGPT就是一个完整的工程项目。它麻雀虽小五脏俱全包含了数据加载、模型定义、训练循环、采样生成、checkpoint保存等一整套流程。真正值得提取成技能的点有两个。第一是可以快速验证想法比如改一个注意力窗口设置、调一下dropout在小数据集上几秒钟就能看到效果第二是训练状态诊断Karpathy在视频里反复强调看loss曲线、看生成文本质量而不是只看精度。我在复现nanoGPT的时候把“训练一个小模型并排查问题”的完整SOP记录了下来先确认数据分配合不合理再检查初始化是否正常然后看梯度范数是否异常最后才是调学习率。这套SOP现在被我直接写进了AI辅助编程的技能库里模型训练类问题都走这条链路比让AI自由发挥稳定得多。2.4 从反向传播到“先让错误足够小”的调试哲学这第四块不是具体的项目而是贯穿Karpathy所有内容里的一种调试哲学先构建一个最小闭环然后让每一层、每个模块的错误都足够小再去验证整个系统的行为。比如训练一个语言模型他会先做一个几十万参数的版本在tiny shakespeare数据上跑确认loss能降、能采样出像样的文本然后才谈扩大规模。这个“先跑通、再加量”的习惯放到任何工程场景都是通用的。把它作为技能来沉淀我会抽象成这样的流程定义最小任务规模搭建最小模型跑通端到端链路记录基线结果逐步增加数据或参数。这五个步骤看起来平平无奇但绝大部分失败的AI辅助编程任务问题都出在一开始就试图一步到位没有先建立一个“足够小的错误系统”。3. 把Karpathy式技能落到AI代理工作流的实操方法理论说得再多不如动手试试。下面这部分是我实际把andrej-karpathy-skills的理念落地到AI协作工作流中的做法。我选了一个真实场景用AI辅助来实现一个微型语言模型的训练和评估并在过程中反复调用Karpathy式的技能文件。3.1 技能文件怎么写目标、上下文、动作、验收标准先说说我用的技能文件结构我参考了不少公开的技能格式结合自己的使用习惯做了简化核心字段就四个name技能的短名称比如train-llm-miniwhen_to_use触发条件什么情况下代理应该加载这个技能steps具体操作步骤尽量写成可检查的动作done验收标准什么时候算任务完成拿train-llm-mini举例触发条件是我需要训练一个小规模语言模型并观察其行为步骤包含数据预处理、构造词表、初始化模型、训练、采样验收标准是训练loss显著下降且生成结果有基本语法结构。为什么不写太长因为AI代理的上下文窗口是有限的超过一定长度之后注意力分布会变得很散反而不利于执行。把技能写短、写准比写全更有用。3.2 一份实际技能拆解示例从数据准备到模型采样我直接贴出这个技能文件的核心内容简化版各位可以感受一下结构# train-llm-mini ## when_to_use 用户要求训练一个从零开始的语言模型或需要排查语言模型训练过程中的不收敛、过拟合、生成质量差等问题。 ## steps 1. 检查数据集统计总字符数、去重后的字符种类、平均句子长度确认数据非空。 2. 构建词表默认按字符级切分标注特殊tokens如果数据集超过5万条考虑BPE。 3. 设置模型参数n_layer/ n_head/ n_embd 优先使用128/4/64这种量级。 4. 初始化模型打印参数量确认与预期规模一致。 5. 配置训练batch_size32, max_iters2000, learning_rate1e-3。 6. 训练并记录loss每500步打印一次loss和采样结果。 7. 诊断与修复如果loss不降先检查数据预处理如果loss出现NaN检查学习率和初始化如果生成重复加大采样温度。 ## done - 训练结束后loss低于1.5在tiny shakespeare数据集上 - 采样生成的文本包含合理的词频统计特征 - 如果任务目标是复现实验需记录所有超参数和最终结果这一段看着简单实际操作的时候价值很大。之前我让AI帮我训练模型它经常是丢给你一段代码就跑完全不解释哪一步需要人工确认。有了这个技能文件AI的每一步都会主动停下来检查数据集规不规范、模型初始化对不对、loss有没有明显下降趋势。等于把Karpathy在课程里的“边做边验证”风格抽了出来。3.3 对比实测有技能和没技能的差异为了验证这套思路有效我做了个非严格但很有意思的对比实验。同样一个任务“帮我用PyTorch训练一个字符级GPT并在小数据集上看看效果”。没有技能文件时AI助手给出的方案往往是一个相对标准的代码结构但它不会主动判断数据规模、不会提醒我注意学习率对收敛的影响直接给完代码就结束了。如果中间出了错我再人工反馈一轮它才继续修。有技能文件时AI会先检查输入数据再按步骤执行每跑完一步都会汇报中间结果最后还会根据loss曲线给出诊断结论。整个过程的可靠性明显更高因为技能文件实际上给AI装了一个“检查清单”。这个差异其实很好解释单轮对话里AI是在自由发挥而技能文件给它提供了领域专家的工作框架。Karpathy的视频里有一句话很贴切不要直接跳到复杂的实现先把最简单的路径走通。技能文件本质就是把这句话工程化。4. 复现Karpathy式技能的完整路径我调通一个小模型的排错记录前面聊了设计思路这节讲一次具体的排错过程。我在复现一个Karpathy风格的最小语言模型时遇到了loss不降的问题。整个过程走下来正好可以说明技能化思维在真实调试里有多重要。4.1 环境准备里最容易忽略的细节我本地的环境是Python 3.11 PyTorch 2.1机器是MacBook Pro M1没有GPU纯CPU训练。按技能文件的步骤数据用的是tiny shakespeare大概1MB的文本。环境准备看着简单其实有个坑M1上PyTorch的MPS后端在部分版本里处理某些op会有精度问题。我第一轮训练时特意做了设备判断如果有MPS就用MPS结果loss曲线出现锯齿抖动。后来我按技能文件里的“如果loss异常检查设备和精度”这一条果断切回CPU抖动立刻消失。这里想提一句Karpathy的代码本身不考虑MPS他默认就是CPU训练。这种“保守选择”在复现阶段反而是最稳妥的因为你是在验证逻辑不是在挤性能。4.2 超参数设置背后的计算逻辑技能文件里建议的是n_embd64, n_head4, n_layer2总参数量大概几十万。很多人会嫌小但这里的计算逻辑是tiny shakespeare的字符集不到100个语义结构并不复杂一个几十万参数的小模型完全有能力拟合它这时候重点是观察训练动态是否正常而不是追求更低loss。我按这个参数跑初始loss大约在4.3左右训练到2000步时降到1.2左右。这个数值范围是合理的说明模型确实学到了统计规律。如果你一上来就用大模型参数比如n_embd768在CPU上可能要跑几小时中途一旦有bug排查成本极高。4.3 一次“loss不降”的完整排查链路事情发生在数据集换成中文语料之后。我手头有一份古诗词数据集大概5万首想看看字符级GPT能不能生成像样的诗句。结果训练到1000步左右loss停在6.2不降了。按照技能文件里的诊断顺序我先检查数据预处理。发现一个问题古诗词里有大量的标点符号和生僻字字符种类多达3000多个。每个字符在softmax里的预测难度完全不一样生僻字的概率权重被稀释导致loss整体偏高。接着我检查了模型初始化。固定随机种子后重新训练loss曲线依然是平的排除初始化问题。最后定位到问题在学习率。技能文件里默认learning_rate1e-3但当我换成3e-4之后loss从6.2降到了5.5左右。原因很简单字符种类变多后梯度分布变稀太大的学习率导致优化过程在高原区来回震荡降不下去。这个排查链路看起来不复杂但它体现的恰恰是技能文件的魅力每一步都对应一个可验证的动作。没有技能文件时我大概率会来回瞎试有了技能文件我只需要按顺序把“数据、初始化、学习率”逐个排除。4.4 修复之后的效果验证修复后的模型在古诗词数据集上跑完3000步loss降到4.8左右。生成的文本虽然语义不通但至少在字符分布上已经接近古诗词的用字习惯比如“山”“水”“风”“月”这些字的出现频率明显变高句式结构也基本稳定在五言或七言。我没有继续调参追求更低的loss因为这里的任务是验证技能文件的可靠性而不是训练一个能写诗的模型。这个过程跑下来我最大的感受是技能化让调试从“碰运气”变成了“走流程”。5. 构建自己的Karpathy式技能包几条真实踩坑经验最后一个部分我想分享几点从零构建技能包的过程中攒下来的经验主要给打算自己动手做类似事情的人参考。5.1 技能不是Prompt模板它必须有验收标准最开始我犯过一个错误把技能文件写得像系统提示词通篇都是“你要考虑”“你应该注意”这种模糊语言。实际用下来效果很差因为AI代理不知道“注意”到什么程度算到位。后来我把每一条都改成可验证的标准。比如不写“注意学习率”而写“固定随机种子跑200步如果loss下降小于0.3则降低学习率重试”。这个改动效果立竿见影AI代理知道什么情况下算失败也知道失败之后该做什么。验收标准才是技能的灵魂没有验收标准的技能文件只是一个更长版本的走心提示词。5.2 单文件别贪大一个技能只解决一个问题我一开始想做一个“全能训练技能”把数据处理、模型训练、调优、评估全塞进一个文件里结果AI代理加载之后经常遗忘前面的步骤执行到中段就开始偏离。后来我把技能拆开prepare-corpus专门负责数据预处理train-mini-llm专门负责训练diagnose-training专门负责排错。每个文件控制在50行以内职责单一。AI代理在实际执行时可以根据当前情况动态加载需要的技能而不是一口气全塞进来。这个思路跟Karpathy做教学项目是一样的micrograd只讲反向传播makemore只讲语言模型的生成原理nanoGPT讲完整训练。每个项目都不大但组合起来就是一套完整的技能树。5.3 技能文件需要版本管理和持续调试最后一点是工程化层面的。技能文件本质上是代码它有自己的bug也需要持续迭代。我现在的做法是把技能文件放在Git仓库里每次修改都提交commit并且在commit message里写清楚改动原因。我遇到过几次很典型的回归问题某次为了让AI生成更有创意的文本我在技能文件里加了一条“采样时温度设为1.5”结果后续所有生成任务都变得语无伦次因为其他任务也加载了这个技能。后来我限制技能的适用范围在when_to_use里强调“仅适用于创意写作任务”问题才消失。这里也推荐一个习惯每个技能文件旁边放一个examples/目录存几个典型的输入输出例子。AI代理加载技能时可以顺便参考例子输出会稳定很多。我个人感觉这个做法比在描述里反复强调“要专业、要准确”有用得多。5.4 从“收藏知识”到“构建系统”这个转变才是关键最后想聊聊心态层面的事。收藏Karpathy的仓库不难难的是把他的知识组织成一套可以在实际工作中反复使用的系统。技能化的过程其实是对已有知识的一次深度加工你逼着自己想清楚每个技能的目标、触发条件、步骤和验收标准这个思考过程本身就很有价值。我现在的工作流里AI代理并不只是“写代码的工具”更像是一个带着领域SOP的执行者。我负责判断方向和验收结果它负责按经过验证的技能路径执行。这个变化很大程度上来自andrej-karpathy-skills这个项目名的启发把高手的隐性经验变成可复用的显性技能。如果你也想尝试构建自己的技能包我的建议很简单挑一个你最近在反复做的事比如“写README”“做代码Review”“训练小模型”试着把它写成一份包含验收标准的技能文件然后用AI代理跑一遍。第一次可能不完美但迭代几次之后你会发现自己正在把最值钱的做事方法慢慢沉淀下来。