From agi-super-team
Applies Andrej Karpathy's thinking frameworks: build-to-understand learning, software 2.0 paradigm, education democratization, data flywheel design, and minimalist implementation. Activates on 'karpathy' or 'software 2.0' mentions.
How this skill is triggered — by the user, by Claude, or both
Slash command
/agi-super-team:thinking-karpathyThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**一句话定义**:不要通过阅读论文"理解"一个概念,要通过从零构建它来真正理解——只有你能写出来的代码,才是你真正理解的知识。
一句话定义:不要通过阅读论文"理解"一个概念,要通过从零构建它来真正理解——只有你能写出来的代码,才是你真正理解的知识。
适用场景:
执行步骤:
经典案例:Karpathy的"Neural Networks: Zero to Hero"系列——不是给你讲理论,是让你从零用Python构建反向传播、构建GPT。他的"Let's build GPT"视频,从零开始写一个Transformer,每一行代码都有解释。这不是教学,是"构建即理解"哲学的体现。
他的micrograd项目——一个极简的自动微分引擎,只有约150行Python代码,但它让你真正理解PyTorch的autograd底层在做什么。
一句话定义:未来的软件不是人写规则,是人提供数据,神经网络通过优化发现规则——从"编写代码"到"设计优化过程"的范式转换。
适用场景:
执行步骤:
经典案例:Karpathy在Tesla领导Autopilot团队时,把自动驾驶从规则驱动转向数据驱动。原来的方式:工程师写规则"如果检测到车道线就居中行驶"。新方式:用数百万英里的真实驾驶数据训练神经网络,让它自己学会"好司机怎么开车"。
他的经典博客《Software 2.0》指出:越来越多的"代码"不是人类写的,是优化算法发现的。Neural network weights就是Software 2.0的"源代码"。
一句话定义:最复杂的知识也可以用最简单的方式教给最多的人——不是降低标准,是提高教学效率。
适用场景:
执行步骤:
经典案例:Karpathy的YouTube频道——每一个视频都是从零构建一个东西。不是为了教你怎么用PyTorch的API,而是让你理解为什么这些API这样设计。
他离开OpenAI后创办Eureka Labs——目标是"用AI放大每个学生的学习能力",把AI不仅是研究对象,也是教育工具。
一句话定义:在AI系统中,数据不是一次性投入,是持续运转的飞轮——更好的模型→更好的用户体验→更多数据→更好的模型。
适用场景:
执行步骤:
经典案例:Tesla的数据引擎——每一辆Tesla都在采集驾驶数据。当系统不确定时(shadow mode),数据被回传。工程师标注→训练新模型→OTA更新到所有车辆。数百万辆车就是数百万个数据采集器。Karpathy在CVPR 2021的talk详细描述了这个飞轮。
一句话定义:用最少的代码、最少的依赖、最少的抽象表达最核心的思想——如果你不能用100行代码实现一个概念的核心,你还没理解它。
适用场景:
执行步骤:
经典案例:nanoGPT——一个用于训练GPT的最简实现,约300行训练代码、300行模型代码。它不是生产框架,是"理解GPT训练"的工具。Karpathy用它来教学和研究。
minbpe——一个最小化的BPE(Byte Pair Encoding)实现,约100行代码,让你理解tokenizer在做什么。
面对技术问题/学习目标
│
▼
[第1层:问题的本质是什么?]
能用一句话描述吗?如果不行,继续思考。
│
▼
[第2层:从零构建验证]
不要看别人怎么做的,自己先试。
卡住了?好,现在你知道自己不懂什么了。
│
▼
[第3层:Software 1.0 vs 2.0]
这个问题的规则是明确的还是需要从数据中学习的?
│
├─ 规则明确 → Software 1.0(写代码)
│
├─ 规则模糊但有数据 → Software 2.0(训模型)
│
└─ 混合 → 混合架构
│
▼
[第4层:最简实现]
用最少的代码/依赖表达核心逻辑。
300行不够说明你没抓住核心。
│
▼
[第5层:数据飞轮]
如果涉及AI,设计数据采集→标注→训练→部署的闭环。
│
▼
[第6层:教给别人]
如果你不能简单解释,说明你还没真正理解。
写出来、讲出来、代码写出来。
决策原则:
"I've always believed that you understand something only if you can build it from scratch." — 多次演讲和博客中反复出现的核心信念
"The software 2.0 stack is emerging, and neural networks are the new code." — 博客《Software 2.0》,2017年11月
"Data is the new code." — Software 2.0博客及多次演讲中的核心论点
"In Software 2.0, the 'code' is the dataset, and the 'compiler' is the optimizer." — 博客《Software 2.0》中对新范式的精确定义
"The biggest bottleneck in most AI projects is not compute or models — it's data." — 多次演讲和Twitter/X讨论中关于AI工程实践的观点
"I spend most of my time not training models but dealing with data." — Tesla AI Day及多次采访中描述他在Tesla的日常工作
"If you can't explain it simply, you don't understand it well enough." — 引用Einstein的话,并在自己的教学实践中贯彻(多次演讲中提及)
"The best way to learn is to build, and the best way to build is in public." — YouTube频道和GitHub项目体现的实践哲学
## 从零构建学习:[目标概念]
### 目标
- 最终构建物:[描述,如"一个可运行的GPT"]
- 理解目标:[列出需要理解的子概念]
### 递进路径
| 阶段 | 构建物 | 核心概念 | 预计代码量 |
|------|-------|---------|----------|
| 1 | [最简版] | [概念A] | ~50行 |
| 2 | [加复杂度] | [概念B] | ~100行 |
| 3 | [更完整版] | [概念C] | ~200行 |
| 4 | [最终版] | [概念D] | ~500行 |
### 卡点预案
- 如果卡在[概念A]:查[资料X]
- 如果卡在[概念B]:看[示例Y]
### 验证标准
- [ ] 每一阶段都能独立运行
- [ ] 每一行代码都能口头解释为什么存在
- [ ] 能在无注释情况下理解代码逻辑
- [ ] 能向非技术人员解释核心思想
## Software 1.0 vs 2.0 决策:[功能/系统]
### 问题分析
| 维度 | 评估 |
|------|------|
| 规则是否明确可编码? | 是/否/部分 |
| 是否有充足训练数据? | 有/没有/可以采集 |
| 边界条件是否可枚举? | 可以/不可以 |
| 是否需要泛化到未见case? | 需要/不需要 |
| 失败的代价? | 高/中/低 |
### 结论
- Software 1.0部分(规则明确):[描述]
- Software 2.0部分(学习驱动):[描述]
- 混合接口:[描述]
### 数据策略(如适用)
- 数据源:[描述]
- 标注方案:[描述]
- 数据量需求:[估算]
- 飞轮设计:[描述]
## 极简实现审查:[项目]
### 核心抽象
- 这个系统最不可减少的核心是什么?[一句话]
### 依赖审查
| 依赖 | 用途 | 是否必须? | 替代方案 |
|------|------|----------|---------|
| [库A] | [用途] | 是/否 | [替代] |
### 代码统计
- 总行数:[N]
- 核心逻辑行数:[N](去掉空行、注释、boilerplate)
- 文件数:[N]
- 能否合并到更少的文件?[是/否]
### 可读性检验
- [ ] 一个熟悉语言但不熟悉领域的开发者能在30分钟内理解核心逻辑
- [ ] 每个函数/类能用一句话说明其存在理由
- [ ] 没有超过50行的函数
- [ ] 变量命名自解释
### "是否过度工程"检查
- 是否有只被调用一次的抽象层?→ 考虑内联
- 是否有"未来可能需要"的功能?→ 删掉
- 是否有超过2层的继承/组合?→ 简化
### 改进方向
1. [最需要简化的地方]
2. [可以去除的依赖]
3. [可以合并的模块]
何时激活这个skill:
典型触发情境:
❌ 调API不等于理解:Karpathy强烈反对"会用PyTorch就认为自己理解了神经网络"——会用框架和理解原理是完全不同的两件事。
❌ 迷信模型架构而忽视数据:"人们花太多时间讨论模型架构,太少时间讨论数据。"在真实AI项目中,数据工程的ROI远高于模型调参。
❌ 过度工程:如果不需要分布式训练,就不要上分布式。如果不需要复杂的抽象层,就不要加。Karpathy的代码风格是"just enough"。
❌ 不从零构建就评判:不要在一个你从没从零构建过的技术上做架构决策。"Talk is cheap, show me the code."
❌ 只学不教:Karpathy的哲学是"理解的最佳证明是你能教会别人"。如果你不能简单地解释它,你还没有真正理解它。
❌ 把Software 2.0当万能药:不是所有问题都应该用神经网络。规则明确的系统用传统代码更可靠、更可解释、更易调试。
❌ 一次性数据策略:AI系统不是"收集一批数据→训练→部署"。是持续的数据飞轮——采集、标注、训练、部署、监控、迭代。
基于Karpathy博客(karpathy.ai)、YouTube频道、GitHub项目(micrograd/nanoGPT/minbpe)、Software 2.0博客(2017)、Tesla AI Day(2021)、CVPR演讲整理。 最后更新: 2026-04-14
npx claudepluginhub aaaaqwq/agi-super-team --plugin agi-super-teamAdopts Andrej Karpathy's engineering mindset to analyze AI reliability, neural net training, LLM capabilities, and industry trends using distilled mental models and heuristics from his public work.
Simulates Andrej Karpathy's teaching style and expertise for deep learning, LLMs, neural networks, and AI education.
Applies Karpathy's four coding principles: Think Before Coding, Simplicity First, Surgical Changes, and Goal-Driven TDD. Useful for any coding session where methodical, minimal, and test-driven work is desired.