Andrej Karpathy 不需要太多介绍。前 Tesla AI 总监、前 OpenAI 创始成员、nanogpt 的作者。他在 AI 圈子里的地位，大概相当于摇滚乐里的 Bob Dylan——不一定每次都唱得最好听，但说的每句话都有人认真听。
最近，有人把 Karpathy 关于「LLM 编程常见陷阱」的观察，整理成了一个 CLAUDE.md 文件，放到 GitHub 上叫 andrej-karpathy-skills。
140,420 个星标，14,414 个 fork，每天涨 2,600 多颗星。
一个纯文本文件，没有一行代码，拿到了这个数据。说明 Karpathy 的洞察力确实值钱。
CLAUDE.md 是什么
简单说，CLAUDE.md 就是你对 Claude Code 说的话——每次开新会话时，Claude 会自动读取项目根目录下的这个文件，把它当成「背景知识」。
你可以用它告诉 Claude：「这个项目用的是什么框架」「代码风格是什么样的」「哪些文件不要碰」。
Karpathy 版本的 CLAUDE.md 做的是另一件事：告诉 Claude（以及使用 Claude 的开发者），在让 LLM 写代码时，哪些事经常出错、应该避免。
核心洞察（提炼版）
虽然这个文件本身是开源的，但它的核心价值不在于文件内容（任何人都可以 fork），而在于 Karpathy 归纳问题的角度。根据社区的讨论和 fork 后的变体，可以总结出几个关键方向：
1. LLM 会「自信地胡说」
这是最经典的问题。你让 LLM 写一个它不熟悉的 API 调用，它会编一个看起来完全合理的函数名和参数。编译的时候才会发现不存在。
Karpathy 的建议是：永远不要让 LLM 凭空生成调用。先让它查文档，再生成代码。
2. 大文件是 LLM 的盲区
把一个 5000 行的文件丢给 LLM 让它修改，它大概率会搞砸。不是因为模型不够聪明，而是因为它需要在这么大的上下文里精确定位修改点——就像让你在图书馆里不借助目录找一页纸。
建议：大文件先拆分，让 LLM 处理小模块，最后再组装。
3. 状态管理是重灾区
LLM 对「当前状态」的理解能力远弱于人类。你让它「接着上次的改继续」，它可能根本不记得上次改了什么。
建议：每次任务都要自包含。不要依赖 LLM 的「记忆」。
4. 测试比代码更重要
让 LLM 写代码时，先让它写测试，再写实现。这样你至少有一个客观标准来判断它写得对不对。
建议：TDD（测试驱动开发）在 AI 编程场景下比以往更有价值。
为什么这个文件能火
14 万星的 CLAUDE.md，火的不是文件本身，而是它背后的东西：
Karpathy 作为顶级 AI 研究者，花了大量时间亲自用 LLM 写代码，然后总结出了这些教训。 这不是理论推演，是实战经验。
在 AI 编程这个领域，大多数「最佳实践」都是工具厂商写的（「用我们的工具就能解决所有问题」）。Karpathy 的不同在于，他是从使用者的角度出发——「我用了这些工具，踩过这些坑，你们别重蹈覆辙。」
这种视角在目前的 AI 编程社区里极度稀缺。
社区的反应
这个项目的 fork 数量（14,414）和 star 数量（140,420）的比例很有意思——大约 10% 的 star 用户选择了 fork。这意味着大量人在基于 Karpathy 的原始版本做自己的定制。
有的 fork 加了特定框架的规则（React、Django、Rust），有的加了团队规范，有的加了语言偏好。
这说明 CLAUDE.md 正在成为一种「可组合的知识载体」——一个人总结经验，所有人受益并迭代。
怎么用
最直接的用法：
- 下载这个 CLAUDE.md
- 放到你的项目根目录
- 根据你的项目做裁剪（不是所有规则都适用于你的场景）
- 用 Claude Code 的时候，它会自动生效
但更有价值的用法是：读一遍，理解每个规则背后的原因，然后写出适合你自己的版本。
Karpathy 的经验是起点，不是终点。
我的想法
这个 CLAUDE.md 最值得学习的地方，不是里面写了什么，而是它揭示了一个趋势：
AI 编程的最佳实践正在从「工具层」下沉到「配置层」。
以前我们学编程，看的是书和教程。现在我们学「怎样让 AI 帮我们编程」，看的是一个 markdown 文件。
这不是降级，是进化。知识正在从长篇大论变成可执行、可组合、可迭代的配置文件。
而 Karpathy 恰好是第一个把这个趋势具象化的人。
主要来源：