Agent-Skills.md

Agent Skills: Andrej Karpathy 思维框架

蒸馏Andrej Karpathy思维模式的实用框架。当需要构建即理解、AI教育平民化、软件2.0思维式思考时激活。

thinking-frameworkID: aaaaqwq/claude-code-skills/thinking-karpathy

Repository

aaaaqwq/claude-code-skills
aAAaqwqLicense: MIT
7317

Install this agent skill to your local

pnpm dlx add-skill https://github.com/aAAaqwq/AGI-Super-Team/tree/HEAD/skills/thinking-karpathy

Skill Files

Browse the full folder contents for thinking-karpathy.

Download Skill

Loading file tree…

skills/thinking-karpathy/SKILL.md

Skill Metadata

Name
thinking-karpathy
Description
"蒸馏Andrej Karpathy思维模式的实用框架。当需要构建即理解、AI教育平民化、软件2.0思维式思考时激活。"

Andrej Karpathy 思维框架

核心思维模型

模型1：构建即理解（Build to Understand）

一句话定义：不要通过阅读论文"理解"一个概念，要通过从零构建它来真正理解——只有你能写出来的代码，才是你真正理解的知识。

适用场景：

  • 学习新技术/新领域
  • 面试准备——深入理解而非表面记忆
  • 技术教学设计
  • 研究验证——论文读懂了还是没读懂？

执行步骤：

  1. 选择目标概念：一个神经网络架构、一个算法、一个系统
  2. 不看教程，先自己尝试：用你现有的理解，写一个最简实现
  3. 卡住时再查资料：只查你卡住的那一个点，不要看完整教程
  4. 逐步增加复杂度：从最简版本开始，一步步加入真实系统需要的复杂性
  5. 用代码验证直觉：如果你觉得"应该是这样的"，写代码验证
  6. 教别人：如果你能用简单的方式解释给别人听，你才真正理解了

经典案例：Karpathy的"Neural Networks: Zero to Hero"系列——不是给你讲理论，是让你从零用Python构建反向传播、构建GPT。他的"Let's build GPT"视频，从零开始写一个Transformer，每一行代码都有解释。这不是教学，是"构建即理解"哲学的体现。

他的micrograd项目——一个极简的自动微分引擎，只有约150行Python代码，但它让你真正理解PyTorch的autograd底层在做什么。

模型2：软件2.0思维（Software 2.0 Thinking）

一句话定义：未来的软件不是人写规则，是人提供数据，神经网络通过优化发现规则——从"编写代码"到"设计优化过程"的范式转换。

适用场景：

  • 系统架构设计——哪些部分用传统代码，哪些用学习
  • 产品功能设计——规则驱动还是数据驱动
  • 工程团队技能规划

执行步骤：

  1. 识别问题类型：这个问题的规则是明确的（Software 1.0）还是模糊的（Software 2.0）？
  2. Software 1.0（传统编程）：规则明确、逻辑清晰、完全可预测 → 写代码
  3. Software 2.0（学习系统）：规则模糊、数据丰富、需要泛化 → 训练模型
  4. 混合架构：大部分真实系统是1.0和2.0的混合——用1.0做骨架，2.0做智能模块
  5. 数据即代码：在Software 2.0中，数据集就是你的"源代码"——数据质量决定系统质量

经典案例：Karpathy在Tesla领导Autopilot团队时，把自动驾驶从规则驱动转向数据驱动。原来的方式：工程师写规则"如果检测到车道线就居中行驶"。新方式：用数百万英里的真实驾驶数据训练神经网络，让它自己学会"好司机怎么开车"。

他的经典博客《Software 2.0》指出：越来越多的"代码"不是人类写的，是优化算法发现的。Neural network weights就是Software 2.0的"源代码"。

模型3：教育平民化（Democratize Through Education）

一句话定义：最复杂的知识也可以用最简单的方式教给最多的人——不是降低标准，是提高教学效率。

适用场景：

  • 技术内容创作
  • 内部培训设计
  • 开源项目文档
  • 知识传播策略

执行步骤：

  1. 从零假设开始：假设读者/听众对这个领域一无所知
  2. 找一个最小可运行的例子：不是讲完所有理论再动手，是第5分钟就让你看到东西跑起来
  3. 逐层叠加复杂度：每一层都基于上一层，每一层都能独立运行
  4. 可视化一切：能画图就不用公式，能动画就不用静态图
  5. 提供可运行的代码：不是伪代码，是复制粘贴就能跑的真实代码
  6. 承认困惑是正常的：标注"这个部分容易让人困惑"——降低学习焦虑

经典案例：Karpathy的YouTube频道——每一个视频都是从零构建一个东西。不是为了教你怎么用PyTorch的API，而是让你理解为什么这些API这样设计。

他离开OpenAI后创办Eureka Labs——目标是"用AI放大每个学生的学习能力"，把AI不仅是研究对象，也是教育工具。

模型4：数据飞轮思维（Data Flywheel Thinking）

一句话定义：在AI系统中，数据不是一次性投入，是持续运转的飞轮——更好的模型→更好的用户体验→更多数据→更好的模型。

适用场景：

  • AI产品策略
  • 数据采集策略
  • 模型迭代流程
  • 竞争壁垒设计

执行步骤：

  1. 设计数据采集机制：产品使用过程中自动采集什么数据？
  2. 建立标注流水线：采集的数据如何快速、低成本地变成训练数据？
  3. 自动化训练流水线：从新数据到新模型，需要多少人工干预？
  4. 灰度部署：新模型先在部分用户上验证，再全量
  5. 监控数据质量：garbage in = garbage out——数据质量比模型架构更重要
  6. 闭环测量：模型改进是否真的改善了用户指标？

经典案例：Tesla的数据引擎——每一辆Tesla都在采集驾驶数据。当系统不确定时（shadow mode），数据被回传。工程师标注→训练新模型→OTA更新到所有车辆。数百万辆车就是数百万个数据采集器。Karpathy在CVPR 2021的talk详细描述了这个飞轮。

模型5：极简主义实现（Minimalist Implementation）

一句话定义：用最少的代码、最少的依赖、最少的抽象表达最核心的思想——如果你不能用100行代码实现一个概念的核心，你还没理解它。

适用场景：

  • 原型验证
  • 教学演示
  • 代码审查标准
  • 系统设计——避免过度工程

执行步骤：

  1. 找到核心抽象：这个系统最不可减少的核心是什么？
  2. 消除所有"方便"但非必要的抽象：不要提前抽象，不要猜未来需求
  3. 用标准库/最少依赖：能不用第三方库就不用
  4. 一个文件胜过多文件：如果逻辑可以在一个文件内清晰表达，就不要拆
  5. 代码即文档：如果代码需要大量注释才能理解，说明代码不够清晰

经典案例：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层：教给别人]
如果你不能简单解释，说明你还没真正理解。
写出来、讲出来、代码写出来。

决策原则：

  • 代码 > 论文：能写代码验证的就不要只看论文
  • 数据 > 架构：在AI系统中，数据质量的ROI远高于模型架构的ROI
  • 简单 > 正确 > 快速：先让它简单，再让它正确，最后让它快
  • 教学即学习：最好的学习方法是把学到的东西教给别人

经典语录

  1. "I've always believed that you understand something only if you can build it from scratch." — 多次演讲和博客中反复出现的核心信念

  2. "The software 2.0 stack is emerging, and neural networks are the new code." — 博客《Software 2.0》，2017年11月

  3. "Data is the new code." — Software 2.0博客及多次演讲中的核心论点

  4. "In Software 2.0, the 'code' is the dataset, and the 'compiler' is the optimizer." — 博客《Software 2.0》中对新范式的精确定义

  5. "The biggest bottleneck in most AI projects is not compute or models — it's data." — 多次演讲和Twitter/X讨论中关于AI工程实践的观点

  6. "I spend most of my time not training models but dealing with data." — Tesla AI Day及多次采访中描述他在Tesla的日常工作

  7. "If you can't explain it simply, you don't understand it well enough." — 引用Einstein的话，并在自己的教学实践中贯彻（多次演讲中提及）

  8. "The best way to learn is to build, and the best way to build is in public." — YouTube频道和GitHub项目体现的实践哲学

实战模板

模板1：从零构建学习计划

## 从零构建学习：[目标概念]

### 目标
- 最终构建物：[描述，如"一个可运行的GPT"]
- 理解目标：[列出需要理解的子概念]

### 递进路径
| 阶段 | 构建物 | 核心概念 | 预计代码量 |
|------|-------|---------|----------|
| 1 | [最简版] | [概念A] | ~50行 |
| 2 | [加复杂度] | [概念B] | ~100行 |
| 3 | [更完整版] | [概念C] | ~200行 |
| 4 | [最终版] | [概念D] | ~500行 |

### 卡点预案
- 如果卡在[概念A]：查[资料X]
- 如果卡在[概念B]：看[示例Y]

### 验证标准
- [ ] 每一阶段都能独立运行
- [ ] 每一行代码都能口头解释为什么存在
- [ ] 能在无注释情况下理解代码逻辑
- [ ] 能向非技术人员解释核心思想

模板2：Software 1.0 vs 2.0 决策

## Software 1.0 vs 2.0 决策：[功能/系统]

### 问题分析
| 维度 | 评估 |
|------|------|
| 规则是否明确可编码？ | 是/否/部分 |
| 是否有充足训练数据？ | 有/没有/可以采集 |
| 边界条件是否可枚举？ | 可以/不可以 |
| 是否需要泛化到未见case？ | 需要/不需要 |
| 失败的代价？ | 高/中/低 |

### 结论
- Software 1.0部分（规则明确）：[描述]
- Software 2.0部分（学习驱动）：[描述]
- 混合接口：[描述]

### 数据策略（如适用）
- 数据源：[描述]
- 标注方案：[描述]
- 数据量需求：[估算]
- 飞轮设计：[描述]

模板3：极简实现审查

## 极简实现审查：[项目]

### 核心抽象
- 这个系统最不可减少的核心是什么？[一句话]

### 依赖审查
| 依赖 | 用途 | 是否必须？ | 替代方案 |
|------|------|----------|---------|
| [库A] | [用途] | 是/否 | [替代] |

### 代码统计
- 总行数：[N]
- 核心逻辑行数：[N]（去掉空行、注释、boilerplate）
- 文件数：[N]
- 能否合并到更少的文件？[是/否]

### 可读性检验
- [ ] 一个熟悉语言但不熟悉领域的开发者能在30分钟内理解核心逻辑
- [ ] 每个函数/类能用一句话说明其存在理由
- [ ] 没有超过50行的函数
- [ ] 变量命名自解释

### "是否过度工程"检查
- 是否有只被调用一次的抽象层？→ 考虑内联
- 是否有"未来可能需要"的功能？→ 删掉
- 是否有超过2层的继承/组合？→ 简化

### 改进方向
1. [最需要简化的地方]
2. [可以去除的依赖]
3. [可以合并的模块]

应用场景

何时激活这个skill：

  1. 深度学习新技术：当需要深入理解一个AI/ML概念，而不仅仅是调API时
  2. AI系统架构设计：当决定系统的哪些部分用传统代码、哪些用学习系统时
  3. 数据策略设计：当需要设计数据采集、标注、训练的闭环系统时
  4. 技术教学/分享：当需要把复杂技术用简单方式教给别人时
  5. 代码审查：当需要评估代码是否过度工程、是否足够简洁时
  6. 原型验证：当需要快速验证一个AI想法是否可行时
  7. AI产品策略：当设计AI功能的数据飞轮时

典型触发情境：

  • "我读了论文但还是不理解"
  • "这个系统应该用规则还是用学习？"
  • "如何从零开始理解Transformer？"
  • "我们的AI产品缺少数据飞轮"
  • "代码太复杂了，能不能更简单"

反模式

  1. ❌ 调API不等于理解：Karpathy强烈反对"会用PyTorch就认为自己理解了神经网络"——会用框架和理解原理是完全不同的两件事。

  2. ❌ 迷信模型架构而忽视数据："人们花太多时间讨论模型架构，太少时间讨论数据。"在真实AI项目中，数据工程的ROI远高于模型调参。

  3. ❌ 过度工程：如果不需要分布式训练，就不要上分布式。如果不需要复杂的抽象层，就不要加。Karpathy的代码风格是"just enough"。

  4. ❌ 不从零构建就评判：不要在一个你从没从零构建过的技术上做架构决策。"Talk is cheap, show me the code."

  5. ❌ 只学不教：Karpathy的哲学是"理解的最佳证明是你能教会别人"。如果你不能简单地解释它，你还没有真正理解它。

  6. ❌ 把Software 2.0当万能药：不是所有问题都应该用神经网络。规则明确的系统用传统代码更可靠、更可解释、更易调试。

  7. ❌ 一次性数据策略：AI系统不是"收集一批数据→训练→部署"。是持续的数据飞轮——采集、标注、训练、部署、监控、迭代。

基于Karpathy博客（karpathy.ai）、YouTube频道、GitHub项目（micrograd/nanoGPT/minbpe）、Software 2.0博客（2017）、Tesla AI Day（2021）、CVPR演讲整理。 最后更新: 2026-04-14